On Tue, May 2, 2017 at 8:04 AM, chetan loke <loke.che...@gmail.com> wrote: > 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. >
Commit that caused it: https://github.com/torvalds/linux/commit/41a50d621a321b4c15273cc1b5ed41437f4acdfb Reverting that change is what we need. When monitoring aggregated links (example: request going out on one link and response coming in on another) you have to know when to start mining packets for time-interval[s] to report anomalies etc. And the block-retirement was designed such that the kernel would fill those values for the app in the ts_first[/last]_pkt. We have already amortized the cost by doing a bulk wakeup. And if user-space holds on to the block even when it is empty (instead of just using/copying the start/end time interval and releasing the block) then its a bug in your app. And if user-space is lagging behind then you will always run out of buffer space. So I don't buy the entire commit argument of the patch.
