Re: NS83820 2.6.0-test5 driver seems unstable on IA64

Andi Kleen
2003-09-26T17:05:09Z

David Mosberger <davidm@napali.hpl.hp.com> writes:

> Why would that be? Slower, yes, but very slow?

It depends on your architecture I guess. On K8/x86-64 it isn't that big
a deal (one cycle penalty for unaligned accesses), but if you take an
exception for each unaligned read it will be incredible slow.

Of course the copy in the driver has the same problem, so it's not
much better.

My point was basically that the header access are peanuts compared to
the unaligned copy. It would be much better to optimize the copy than
the header access. The proposal of just copying the header does not
address this. And copying the packet in the driver has the same problem,
so IMHO it's useless.

The solution proposed by Ivan sounds much better. The basic problem
is that the Ethernet header is not a multiple of 4 and that misaligns
everything after it. Use one receive descriptor for the MAC header and
another for the rest (IP/TCP/payload) In the rest everything is aligned and
there are no problems with misaligned data types (ignoring exceptional cases
like broken timestamp options which can be handled slowly). Fixing the
stack to handle separate MAC headers should not be that much work, the
code is fairly limited. Drawback is that it requires bigger changes to the
network drivers and maybe some special case code for non standard MAC
headers.

-Andi