tcpdump mailing list archives
Re: About LINKTYPE_LINUX_SLL / LINKTYPE_LINUX_SLL2
From: Guy Harris <gharris () sonic net>
Date: Sat, 14 Jul 2018 18:06:34 -0700
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
Current thread:
- About LINKTYPE_LINUX_SLL / LINKTYPE_LINUX_SLL2 Francois-Xavier Le Bail (Jul 13)
- Re: About LINKTYPE_LINUX_SLL / LINKTYPE_LINUX_SLL2 Denis Ovsienko (Jul 14)
- Re: About LINKTYPE_LINUX_SLL / LINKTYPE_LINUX_SLL2 Guy Harris (Jul 14)