Re: [PATCH]: pcap and zero copy.

[Guy Harris <guy () alum mit edu>]

On Sun, Jan 04, 2004 at 12:02:13PM +0000, Yoann Vandoorselaere wrote:
> - are people interested by the inclusion of this patch ?

Yes, as long as it's done on *all* platforms, and done against the
current CVS version (and doesn't change "pcap_next()" - if
"pcap_next_ex()" can handle this without change, that'd be better). 
I've looked at doing it on other platforms, but haven't had time to work
on it.

Most platforms are either like BPF (a read from the kernel can return
multiple packets) or Linux (a read from the kernel returns only a single
packet).

Note that it would also need to work with the Linux turbopacket stuff
once that gets added to libpcap.  The problem with the turbopacket stuff
is that there's no buffer into which stuff is read from the kernel - the
packets come from a buffer shared with the kernel.  That'd probably
require that a buffer be allocated for each packet and a copy done to
that buffer, which means that the turbopacket stuff would involve *more*
copies (one from skbuff to shared buffer, one from shared buffer to
mallocated buffer, rather than one from skbuff to mallocated buffer with
a "recvfrom()").

The right way to handle that might be to have a way of specifying, at
open time, that packet buffers need to be persistent.  If that's the
case, we probably wouldn't use the turbopacket stuff on Linux.  (It has
been claimed that some libpcap applications depend on parent and child
processes being able to share access to a libpcap descriptor, and that
the turbopacket packet stuff would break that, which is why Phil Wood's
turbopacket patch has an environment variable you have to set in order
to use turbopacket mode; in the long term, I'd like to have a new API
for opening live captures, that allows a number of things to be
specified at open time:

        whether to open for capturing, sending, or capturing and sending
        (so that, on BPF, the device can be opened for reading, writing,
        or reading and writing);

        whether to open in monitor mode for 802.11 devices (to hide the
        rather, umm, *diverse* ways of doing that on different OSes and
        different devices on the *same* OS inside libpcap);

        whether the libpcap descriptor has to be shareable between
        parent and child processes;

        a capture buffer size (BPF doesn't let you set that once you've
        bound to a device);

and possibly some other things.)
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe