On Jul 13, 2018, at 10:00 AM, Francois-Xavier Le Bail 
<devel.fx.leb...@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

Reply via email to