On Wed, Apr 07, 2021 at 01:19:09PM +0200, Ilya Maximets wrote: > On 3/26/21 9:18 PM, Ben Pfaff wrote: > > 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. > > Sure. AFAIK, container management systems like kubernetes are tracking > memory consumption and doesn't schedule/create new containers if system > (kubelet daemon on the node) reports memory pressure. So, it should not > be a big concern to run OVS without memory locking. > > In its current form change is not acceptable as it will cause problems > for DPDK users (and, probably, afxdp, but I'm not sure about that).
Consider this dropped. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
