Re: [dpdk-dev] Question about DPDK hugepage fd change

["Wiles, Keith" <keith.wiles@intel.com>]

> On Feb 5, 2019, at 3:27 PM, Iain Barker <iain.barker@oracle.com> wrote:
> 
>> 
>> Would poll work here instead?
> 
> Poll (or epoll) would definitely work - if we controlled the source and compilation of all the libraries that the application links against.
> 
> But an app doesn’t know how the libraries in the OS are implemented. We’d have no way to ensure select() isn’t called by a shared library - the first we would know is when the application randomly failed.
> 
> Seems pretty clear that the newer DPDK library is breaking the requirements of GNU libc to use less than 1024 file descriptors. The previous DPDK design was able to mmap the huge pages without requiring thousands of open file descriptors…

Maybe I do not see the full problem here. If DPDK used poll instead of select it would solve the 1024 problem as poll has a high limit to the number of file descriptors at least that was my assumption. I do not see us sending these file ids to other applications using select. If the fd is sent to another application it must be passed via the kernel an be converted to that process fd value. Did I miss a use case here or just missing the point?
> 
> 

Regards,
Keith