>>>>> "Pieter" == Pieter Truter <[EMAIL PROTECTED]> writes:
Pieter> To clear things up: I got this explanation from Alexander
Pieter> Shulz: (He had the same problem long ago)
Pieter> On the arm, it is important, that the ip header is on a 32
Pieter> bit boundry.
I would call that a bug, if it is true.
Pieter> My problem was a missing skb_reserve(skb, 2); in the receiver
Pieter> code. The skb is allocated on a 32bit-boundry, the ethernet
Pieter> header is 14 bytes long. This statement moves the ethernet
Pieter> header to byte 2 of the skb, so that the ip-header starts at
Pieter> byte 16, thus 32bit alligned. You must create the skb with 2
Pieter> bytes more of course.
Unfortunately, that solution is not going to work in many cases.
The most obvious reason is that many (probably most) Ethernet DMA
engines require 4-byte aligned receive starting addresses. If you
offset the receive address by 2 bytes, either they will not work at
all or the offset is simply ignored.
Another reason is that, in a more general protocol stack, you cannot
know ahead of time how many bytes of header there are. So you may
find that your "plain old" IP traffic is naturally aligned, but some
random tunneled or bridged case then is forced to an odd boundary.
It is just barely possible to build into protocol stacks an assumption
that everything is aligned to even (multiple of 2) boundaries. That's
about as good as you can do, and to do this you have to refuse PPP
header compression. (Then again, that's wise anyway, it's an absurd
feature.) In general, you have *no* chance of forcing 4 byte
alignment on incoming traffic.
paul
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
