On Fri, Mar 26, 2021 at 07:52:18PM +0100, Ilya Maximets wrote: > On 3/26/21 7:30 PM, Ben Pfaff wrote: > > From: James Page <[email protected]> > > > > Normally when OVS runs on a server the effective system limit for > > locked memory is unlimited as the ovs-vswitchd runs as the root > > user in the root namespace of the server. > > > > When OVS is run in a non-priviledged container a system limit will > > apply and its possible that this limit will be reached during > > normal operation. > > > > If this occurs unlock all memory and re-attempt (re)allocation of > > memory rather than fail and abort. > > > > If this subsequent attempt also fails abort the process as before. > > > > Signed-off-by: James Page <[email protected]> > > [[email protected] adapted to cover more cases] > > Signed-off-by: Ben Pfaff <[email protected]> > > --- > > Hi, Ben and James. > > I'll repeat here what I said in a comment on github. > > DPDK uses memory locking for mempool pages and it relies on these > pages not being moved or unloaded, because it uses physical addresses > to configure hardware NICs. Also, some DPDK drivers are using memory > locking to lock in memory pages that are used for driver-specific > device I/O. Unlocking any of these pages in runtime will likely crash > the system by NMI if such a page will be moved or swapped without > notifying the device and driver. > > Blindly unlocking all the memory is very dangerous. > > I'd say it's much more safe to just run OVS without passing --mlockall. > Or we need to itroduce a special cmdline flag to allow dynamic unlocking > and also forbid DPDK initialization if this flag enabled. > And all this should be sufficiently documented.
I don't have a dog in this fight. I'll leave it to you and James to figure out the preferred behavior. Patches 1 and 2 may be of interest either way. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
