[dpdk-dev] [PATCH] eal: add option to not store segment fd's

[Thomas Monjalon]

29/03/2019 11:33, Burakov, Anatoly:
> On 29-Mar-19 9:50 AM, David Marchand wrote:
> > On Fri, Feb 22, 2019 at 6:12 PM Anatoly Burakov 
> > <anatoly.burakov at intel.com <mailto:anatoly.burakov at intel.com>> wrote:
> > 
> >     Due to internal glibc limitations [1], DPDK may exhaust internal
> >     file descriptor limits when using smaller page sizes, which results
> >     in inability to use system calls such as select() by user
> >     applications.
> > 
> >     While the problem can be worked around using --single-file-segments
> >     option, it does not work if --legacy-mem mode is also used. Add a
> >     (yet another) EAL flag to disable storing fd's internally. This
> >     will sacrifice compability with Virtio with vhost-backend, but
> >     at least select() and friends will work.
> > 
> >     [1] https://mails.dpdk.org/archives/dev/2019-February/124386.html
> > 
> > 
> > Sorry, I am a bit lost and I never took the time to look in the new 
> > memory allocation system.
> > This gives the impression that we are accumulating workarounds, between 
> > legacy-mem, single-file-segments, now no-seg-fds.
> 
> Yep. I don't like this any more than you do, but i think there are users 
> of all of these, so we can't just drop them willy-nilly. My great hope 
> was that by now everyone would move on to use VFIO so legacy mem 
> wouldn't be needed (the only reason it exists is to provide 
> compatibility for use cases where lots of IOVA-contiguous memory is 
> required, and VFIO cannot be used), but apparently that is too much to 
> ask :/
> 
> > 
> > Iiuc, everything revolves around the need for per page locks.
> > Can you summarize why we need them?
> 
> The short answer is multiprocess. We have to be able to map and unmap 
> pages individually, and for that we need to be sure that we can, in 
> fact, remove a page because no one else uses it. We also need to store 
> fd's because virtio with vhost-user backend needs them to work, because 
> it relies on sharing memory between processes using fd's.

It's a pity adding an option to workaround a limitation of a corner case.
It adds complexity that we will have to support forever,
and it's even not perfect because of vhost.

Might there be another solution?