Date: Tue, 17 Jul 2001 09:12:17 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Richard Hodges <rh@matriplex.com> Cc: Bill Paul <wpaul@FreeBSD.ORG>, hackers@FreeBSD.ORG Subject: Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3 Message-ID: <3B5463E1.BE28526C@mindspring.com> References: <Pine.BSF.4.10.10107161550460.38762-100000@mail.matriplex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Richard Hodges wrote: > > On Mon, 16 Jul 2001, Bill Paul wrote: > > > They're "okay." The NatSemi chip has one flaw, which is that RX buffers > > must be aligned on a 64-bit boundary. None of the more expensive NICs have > > this restriction. > > Go ahead and beat me up if you have to :-) But why is there _any_ issue > with RX buffer alignment? I get some mbufs and set the data pointer to > any point I want, or I get a cluster, which is always on a 2k boundary. Because of the ethernet header being 14 bytes instead of 16, and the Alpha requiring aligned access for structure members when the remainder of the packet is cast to IP and TCP headers, respectively. While you can do an unaligned access on x86, it _is_ more expensive, and may result in more bus cycles than you would otherwise spend. Actually, since the 486, it's been possible for us to turn on unaligned access exceptions on the x86. We should probably consider doing this, to ensure better performance, and to avoid the unnecessary bus overhead we eat for unaligned access today... not to mention how it could shake out the drivers. > Now TX buffers are a problem - I have to take what I get and just > "deal with it". If both start address and length need to be aligned, > then I'm pretty much screwed - I have to copy... No, exactly ythe opposite: the TX buffer is _not_ a problem. This is because it's assembled from mbuf's, so you can actually put it on a 16 byte boundary, and index the mbuf into only the forst 14 bytes of the packet for the header. This means that the transmit queue can have mbufs with aligned access, while the receive queue can't, unless the DMA engine can DMA onto an initial odd boundary, or can break up the DMA into a 14 byte part, plus the remainder on a 16 byte boundary. Bill explains this very well in person, as well as in the current commentary in a couple of his drivers, once you understand the issue. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B5463E1.BE28526C>