On Jul 13, 2018, at 10:00 AM, Francois-Xavier Le Bail
wrote:
> In http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html and
> http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html, there is:
>
> "If there are more than 8 bytes, only the first 8 bytes are present, and if
> there are fewer than 8
> bytes, there are padding bytes after the address to pad the field to 8 bytes."
>
> Does anyone know why the 8 bytes limit ?
Unfortunately, I can't find the emails where DLT_LINUX_SLL/LINKTYPE_LINUX_SLL
was proposed, so I don't know why the limit. Given that there are fields after
it, making it variable-length would be a nuisance (and would break both program
and file binary compatibility).
Furthermore, with the memory-mapped capturing, space has to be reserved in the
memory-mapped buffers for any header we prepend to the packet, which means we
need a maximum header size so that we know how much to reserve, even for
DLT_LINUX_SLL2/LINKTYPE_LINUX_SLL2.
For what it's worth, given that, at least if you don't explicitly additional
extra space, the TPACKET code tries to put the packet data on a 16-byte
boundary (John "LINPACK" McCalpin said, in 2017, "If the data is not aligned on
a 16-Byte boundary, then whenever a store crosses a cache-line boundary there
is typically a stall." at
https://software.intel.com/en-us/forums/intel-isa-extensions/topic/709279). We
should probably make sure the amount we reserve is a multiple of 16; that would
allow us to make the address field larger, if we want to.
> Should we add that the padding is done with '\0' bytes ?
Yes.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
