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