tcpdump mailing list archives
Re: [PATCH] tcpdump -s 0 improvement
From: "David Laight" <David.Laight () ACULAB COM>
Date: Wed, 30 Nov 2011 17:55:45 -0000
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.
That doesn't preclude the use of variable sized buffers. There are several schemes that could have been used that have much the same logic, but allow variable sized buffers. Perhaps the most obvious way to look at it would be to consider it as a 'transmit' ring from the kernel to user instead of a receive ring. Provided the kernel code knows the length of a frame before it starts copying it to userspace, it could easily allocate a data offset just beyond the previous frame. David - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Current thread:
- [PATCH] tcpdump -s 0 improvement Magnus Gille (Nov 27)
- Re: [PATCH] tcpdump -s 0 improvement Guy Harris (Nov 29)
- Re: [PATCH] tcpdump -s 0 improvement Gianluca Varenni (Nov 29)
- Re: [PATCH] tcpdump -s 0 improvement Guy Harris (Nov 29)
- Re: [PATCH] tcpdump -s 0 improvement David Laight (Nov 30)
- Re: [PATCH] tcpdump -s 0 improvement Guy Harris (Nov 30)
- Re: [PATCH] tcpdump -s 0 improvement Michael Richardson (Nov 30)
- Re: [PATCH] tcpdump -s 0 improvement Gianluca Varenni (Nov 30)
- Re: [PATCH] tcpdump -s 0 improvement Guy Harris (Nov 30)
- Re: [PATCH] tcpdump -s 0 improvement David Laight (Dec 01)
- Re: [PATCH] tcpdump -s 0 improvement Gianluca Varenni (Nov 29)
- Re: [PATCH] tcpdump -s 0 improvement Guy Harris (Nov 29)
- Re: [PATCH] tcpdump -s 0 improvement Guy Harris (Nov 30)