Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David Mosberger]

>>>>> 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
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
-
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/