Re: NS83820 2.6.0-test5 driver seems unstable on IA64

David Mosberger
2003-09-26T17:47:16Z

>>>>> On Fri, 26 Sep 2003 19:04:30 +0200, Andi Kleen <ak@muc.de> said:

Andi> David Mosberger <davidm@napali.hpl.hp.com> writes:
>> Why would that be? Slower, yes, but very slow?

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

What are you talking about? Arches that don't like/support unaligned
accesses will certainly have a copy_user() which handles misalignment
just fine. For example, on ia64, the copy will run slightly slower
because of an additional shift in the loop, but that penalty only
shows on fully cached data. If the data is not cached, the copy speed
for aligned vs. misaligned data is virtually the same.

Andi> Use one receive descriptor for the MAC header and another for
Andi> the rest (IP/TCP/payload) In the rest everything is aligned
Andi> and there are no problems with misaligned data types (ignoring
Andi> exceptional cases like broken timestamp options which can be
Andi> handled slowly).

That's what I proposed.

Andi> Fixing the stack to handle separate MAC headers should not be
Andi> that much work, the code is fairly limited. Drawback is that
Andi> it requires bigger changes to the network drivers and maybe
Andi> some special case code for non standard MAC headers.

I suspect you'd be better off just copying the 14 bytes of the
Ethernet header so that the entire packet is contiguous.

--david