On Wed, Apr 7, 2021 at 5:45 PM Ben Pfaff <[email protected]> wrote: > 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. >
Apologies for the laggy response - email woes now resolved. I'll raise a review to simply detect execution in a container and stop passing mlockall in this combo _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
