Re: About LINKTYPE_LINUX_SLL / LINKTYPE_LINUX_SLL2

[Guy Harris <gharris () sonic net>]

On Jul 13, 2018, at 10:00 AM, Francois-Xavier Le Bail <devel.fx.lebail () orange fr> 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