Andrew Gallatin wrote:
> I imagine that this was done to follow alignment constraints on
> non-i386 platforms where having the ip header misaligned is fatal.
> (the tulip is not capable of byte granularity DMA, so you can't
> intentionally misalign the ethernet header & end up with an aligned IP
> header)
This is the reason: the ethernet header is 14 bytes.
> I imagine the i386 should be made an exception. See rev 1.17 of
> sys/dev/nge/if_nge.c
I disagree with this code; the elemenets in the header
are referenced multiple times. If you are doing the
checksum check, you might as well be relocating the data,
as well. The change I would make would be to integrate
the checksum calculation with the m_devget(), to ensure
a single pass, in the case that m_devget() must be used
to get aligned packet payload, and the checksum has not
been offloaded to hardware.
When Bill finishes the Tigon III driver, he will find out
that it does not have the firmware problem the Tigon II
has, and that he can actually leave the checksum offload
active, and still be able to use VLANs (something that you
can not do with the Tigon II without serious changes to
the firmware).
IMO, in the vast majority of cases, it makes sense to do
the m_devget(), even though it looks like you can do the
unaligned access in 2 bus cycles instead of 1, and come
out ahead, for the IP and TCP header elements. This could
be fixed by reducing the references to the elements so
that they are extracted only once, at which point, the
cost breaks even at a 32 byte or larger payload size, and
it is better to do the unaligned references than the copy
(assuming checksum offload, rather than opportunistic copy
at checksum calculation time). Reordering the code to do
it this way is an ...interesting... exercise, since you
have to make some assumptions that may not be valid (e.g.
that it is an IP payload) before you get to the ipinput
code.
In any case, I think it would be useful to turn on the CR
bit that causes unaligned access faults on the 486 and
above Intel processors, as well (this discussion has taken
place before).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message