>
> 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.
