Re: NS83820 2.6.0-test5 driver seems unstable on IA64
From: Andi Kleen
Date: Fri Sep 26 2003 - 23:37:05 EST
On Fri, Sep 26, 2003 at 10:47:12AM -0700, David Mosberger wrote:
> >>>>> On Fri, 26 Sep 2003 19:04:30 +0200, Andi Kleen <ak@xxxxxx> said:
>
> Andi> David Mosberger <davidm@xxxxxxxxxxxxxxxxx> 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
They don't in this case ;-)
See my reply to David Miller for details.
>
> 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.
Hmm, must have missed that sorry. I saw it in Ivan's post only.
> Andi> Fixing the stack to hadle 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.
Good point. So it can be even handled transparently in drivers without
any core stack changes.
Only drawback is that more RX descriptors also usually require
more PCI writes, which can be also very slow. Needs to be benchmarked
carefully if it's a worthy trade-off.
-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/