Use newer AIO poll interface ?

[tbarbette]

Linux Kernel just added a new AIO poll interface (see https://lwn.net/Articles/743714/)

The advantage is that one may submit a list of FD to poll on (like poll), but the answers can be consumed without any systemcall, it is basically a queue.

Question is: should we support the new poll?

For DPDK users, this does not apply.

For netmap users I actually wonder what could be leveraged from this API (if it is supported by Netmap?).
For PCAP users, well they are probably not considering speed. But anyway one scope for both cases I can see is :

• We register all fds like usual in the event part of the router driver loop.
• We process the one that directly returned (that will schedule some tasks), and at next turn we look at other events that are now available instead of re-polling.
• If a fd is rescheduled, we submit it at next turn too.

We would avoid some system calls. One win case is, if one device is busy, we do not re-poll for a second idle device at each turn (after processing some packets of the busy device) for nothing. Its fd is still in the AIO queue. While with the current scheme, one would process a burst of packet, poll, process another one, poll, ...
But then with Netmap we need to call poll to flush the packets anyway for the busy device, so it's for PCAP only. And XDP will not use poll either. So this would make PCAP/socket a little better, but who really cares?