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. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
