Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Andi Kleen]

David Mosberger <davidm@xxxxxxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/