Guy Harris wrote: > > > What exactly do you mean by an "aligned" packet? > > > uname -sr > FreeBSD 4.1-RELEASE > > man bpf > > ... > > BPF HEADER > The following structure is prepended to each packet returned by read(2): > > ... > > The bh_hdrlen field exists to account for padding between the header and > the link level protocol. The purpose here is to guarantee proper align- > ment of the packet data structures, which is required on alignment sensi- > tive architectures and improves performance on many other architectures. > The packet filter insures that the bpf_hdr and the network layer header > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > will be word aligned. Suitable precautions must be taken when accessing > ^^^^^^^^^^^^^^^^^^^^^ > the link layer protocol fields on alignment restricted machines. (This > isn't a problem on an Ethernet, since the type field is a short falling > on an even offset, and the addresses are probably accessed in a bytewise > fashion). > > Additionally, individual packets are padded so that each starts on a word > boundary. This requires that an application has some knowledge of how to > get from packet to packet. The macro BPF_WORDALIGN is defined in > <net/bpf.h> to facilitate this process. It rounds up its argument to the > nearest word aligned value (where a word is BPF_ALIGNMENT bytes wide). > > > If you mean the sort of obvious superficial business that the link header > > starts on a 2- or 4-byte boundary, > > Nope, he's talking about the *network-layer* header, e.g. the IP header.
Guy, Thanks for the clarification. As a programmer I'm inclined not to rely on any OS-specific promises about structure alignment of external data -- I try to make code more portable than that -- but I can see how there's a slight performance gain, and how this is an issue for someone who wants to take advantage of that. And after all, if that's what the docs claim, it probably ought to behave that way, hmm? -- Jefferson Ogata <[EMAIL PROTECTED]> NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]> - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
