Re: [PATCH] tcpdump -s 0 improvement

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

On Nov 29, 2011, at 7:48 PM, Gianluca Varenni wrote:

> Is there a specific reason why shared memory is implemented in such a way that frame buffers are allocated based on 
> the maximum frame supported frame size (+junk, see 802.11)?

I didn't see any of the discussions about it, but my guess is that the intent was to have a fixed set of slots in the 
buffer, each one associated with a fixed header, so that most of the packet-receive loop can just look at the headers 
and process all "owned by userland" headers and only make a system call when it has to block waiting for new packets to 
arrive.

FreeBSD's shared-memory mechanism:

        
http://www.FreeBSD.org/cgi/man.cgi?query=bpf&apropos=0&sektion=0&manpath=FreeBSD+8.2-RELEASE&arch=default&format=html

buffers packets the same way that the non-shared-memory mechanism does, so there aren't fixed-size slots; there's one 
system call per bufferfull (to wait for the next bufferfull and to rotate the buffers).

I don't know whether anybody's done any performance comparisons to see whether the Linux approach has any advantages 
(e.g., not doing any system calls to read packets if the packets are coming in as fast as userland can process them - 
there will probably still be system calls to *write* the packets...).-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.