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