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.
