[tcpdump-workers] What's the correct new API to request pcap_linux to not open an eventfd

Bill Fenner fenner at gmail.com
Fri Jul 1 13:55:30 EDT 2022

On Fri, May 20, 2022 at 6:10 PM Bill Fenner <fenner at gmail.com> wrote:

> On Fri, May 20, 2022 at 12:36 PM Guy Harris <gharris at sonic.net> wrote:
>> If it's putting them in non-blocking mode, and using some
>> select/poll/epoll/etc. mechanism in a single event loop, then the right
>> name for the API is pcap_setnonblock().  There's no need for an eventfd to
>> wake up the blocking poll() if there *is* no blocking poll(), so:
>>         if non-blocking mode is on before pcap_activate() is called, no
>> eventfd should be opened, and poll_breakloop_fd should be set to -1;
>>         if non-blocking mode is turned on after pcap_activate() is
>> called, the eventfd should be closed, and poll_breakloop_fd should be set
>> to -1;
>>         if non-blocking mode is turned *off* afterwards, an eventfd
>> should be opened, and poll_breakloop_fd should be set to it;
>>         if poll_breakloop_fd is -1, the poll() should only wait on the
>> socket FD;
>> so this can be handled without API changes.
> Thank you for the excellent observation, Guy.  It is indeed setting
> non-block before pcap_activate().  I'll work on this plan.

A slight variation of this plan is at

I wrote a test program that doesn't do much, but does demonstrate that the
blocking-ness API on Linux is at least a little weird.  If we set
pcap_nonblock after pcap_create and before pcap_activate, we get -3 - which
I don't get at all, unless, -3 means "you didn't activate the pcap yet".
My naive reading of the Linux pcap_getnonblock code says it'll return the
integer value of a bool, and I don't know how that can be -3.

The sequence ends up being:
pcap_create() -> open eventfd
pcap_setnonblock() -> close eventfd

I didn't want to move the eventfd creation out of pcap_create without
having a deeper understanding of the strangeness around the nonblock API.

I ran 15,645 internal Arista tests using these changes, in an
infrastructure that relies on nonblocking pcap for packet exchange, and
they all passed.  Obviously this doesn't really say much about its general
applicability, and kind of is a no-brainer "when you don't need the eventfd
you don't notice if it's not there", but at least it says that things
aren't drastically broken.


More information about the tcpdump-workers mailing list