Re: [tcpdump-workers] TPACKET_V3 timeout bug?

2017-04-15 Thread Andrew Lunn 
On Sat, Apr 15, 2017 at 06:45:36PM -0400, Sowmini Varadhan wrote:
> On (04/15/17 21:40), Andrew Lunn wrote:
> > 
> > In my case, lan3 is up and idle, there are no packets flying around to
> > be captured. So i would expect pcap_next_ex() to exit once a second,
> > with a return value of 0. But it is not, it blocks and stays blocked.
>:
> > Looking at the libpcap source, the 1000ms timeout is being used as
> > part of the setsockopt(3, SOL_PACKET, PACKET_RX_RING, 0xbe9445c0, 28)
> > call, req.tp_retire_blk_tov is set to the timeoutval.
> 
> right, aiui, the retire_blk_tov will only kick in if we have at
> least one frame in a block, but the block is not filled up yet,
> before the req.tp_retire_blk_tov (1s in your case) expires.
> 
> If there are 0 frames pending, we should not be waking up the app,
> so everything seems to be behaving as it should?

Hi Guy

You wrote the TPACKET3 set_poll_timeout() handling. Please could you
have a look at the thread:

https://www.mail-archive.com/netdev@vger.kernel.org/msg163532.html

Do you think this is a kernel problem, libpcap problem, or an
application problem?

Thanks
Andrew
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] TPACKET_V3 timeout bug?

2017-04-15 Thread Guy Harris 
On Apr 15, 2017, at 7:10 PM, Andrew Lunn  wrote:

> Do you think this is a kernel problem, libpcap problem, or an
> application problem?

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 packets have arrived is platform-dependent; code capturing packets should 
neither depend on it doing so or on it not doing so.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers