tcpdump mailing list archives

Re: TPACKET_V3 timeout bug?


From: Guy Harris <guy () alum mit edu>
Date: Tue, 2 May 2017 20:15:38 -0700

On May 2, 2017, at 10:16 AM, chetan loke <loke.chetan () gmail com> wrote:

Commit that caused it:

https://github.com/torvalds/linux/commit/41a50d621a321b4c15273cc1b5ed41437f4acdfb

Reverting that change is what we need.

As long as you do *not* revert

        https://github.com/torvalds/linux/commit/da413eec729dae5dcb150e2eb34c5e7e5e4e1b49

"packet: Fixed TPACKET V3 to signal poll when block is closed rather than every packet

Make TPACKET_V3 signal poll when block is closed rather than for every
packet. Side effect is that poll will be signaled when block retire
timer expires which didn't previously happen. Issue was visible when
sending packets at a very low frequency such that all blocks are retired
before packets are received by TPACKET_V3. This caused avoidable packet
loss. The fix ensures that the signal is sent when blocks are closed
which covers the normal path where the block is filled as well as the
path where the timer expires. The case where a block is filled without
moving to the next block (ie. all blocks are full) will still cause poll
to be signaled."

The behavior in the commit message exactly what libpcap (and probably at least some other users of TPACKET_V3) need.  
libpcap doesn't care whether empty blocks are passed up (as indicated, "you get woken up when the packet buffer timeout 
expires" is *not* part of libpcap's contract, and code shouldn't depend on that), so, as long as you preserve the 
"signal poll when a block is closed, even if it's an empty block" behavior, libpcap will work fine.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Current thread: