Re: capturing on both interfaces simultaneously

["David Laight" <David.Laight () ACULAB COM>]

> On Dec 12, 2011, at 3:59 AM, David Laight wrote:
>
> > The linux libpcap has a poll() in the 'memory mapped'
> > kernel interface (in order to check for errors).
> > If the application is using poll() this is an unnecessary
> > system call.
>
> The only way libpcap can infer that the application is using 
> poll() is if it has put the pcap_t in non-blocking mode.  
> libpcap used to avoid the poll() in that case, but that was 
> causing applications to loop infinitely chewing up CPU; see 
> the thread that starts at
>
>       http://thread.gmane.org/gmane.network.tcpdump.devel/3937
>
> That poll() is unnecessary in non-blocking mode only if the 
> application isn't expecting libpcap to return errors, and is 
> itself checking for those errors after the poll() call.  That 
> would be the case only if the application knew it had to do 
> that special Linux-specific stuff. 

Perhaps it could be done every 256'th time through.
That would pick up an actual error quite quickly, but
reduce the overhead a lot.

> > I also think that interface could defer freeing the last
> > rx buffer until the request to read another packet.
> > That would avoid the necessity of a buffer copy
> > for applications that don't want to use callbacks.
>
> That strategy was attempted by
>
>       commit 54ef309e921c11a4e80cd7a26d9e25d30c833e14
...

> If you have a change that will eliminate the need for the 
> copy *without* breaking Mike Kershaw's code, please contribute it.-

Is there a sane way I can look a the diff of that commit?

I think it should be enough to set the deferred
  tp_status = TP_STATUS_KERNEL
at the top of pcap_read_linux_mmap() and at the top of the
loop that processes packets.

        David


-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.