Messages in this thread | | | From | David Mosberger <> | Date | Fri, 26 Sep 2003 10:47:12 -0700 | Subject | Re: NS83820 2.6.0-test5 driver seems unstable on IA64 |
| |
>>>>> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |