On Sat, Apr 15, 2017 at 7:41 PM, Guy Harris <g...@alum.mit.edu> wrote: > On Apr 15, 2017, at 7:10 PM, Andrew Lunn <and...@lunn.ch> wrote: > >> Do you think this is a kernel problem, libpcap problem, or an >> application problem? >
Its clearly a kernel regression. If you look at if_packet.h, I have explicitly called out all the cases for the return/status codes. When I first merged the functionality in 3.11(or 3.12 I think) I had the logic in place to retire the block with or without packets in it. I think there was one case where we wouldn't wake up userspace. Someone checked in a fix for that. Now I am not sure the regression happened as part of that bug fix or sometime later. If you diff 3.12 against the latest you will find the regression. Look for prb_retire_rx_blk_timer_expired(). > An application problem. See my response on netdev; the timeout (which is > provided by the kernel's capture mechanism, in most cases) is to make sure > packets don't stay stuck in the kernel's packet buffer for an indefinite > period of time, it's *not* to make sure a thread capturing packets doesn't > stay blocked for an indefinite period of time. Whether the timer goes off > even if no I cannot speak on behalf of user-space wrappers developed around tpacket_v3 but the intention(from the kernel POV) of the block_timer *is* to unblock the capture/user process/thread so that it does NOT stay blocked for an indefinite period of time. The header explicitly specifies that contract. I'm tied up for the next 3 weeks. However I can work on it after that(unless someone else has cycles for it now). Chetan
