Date: Mon, 16 Jul 2001 16:34:36 -0700 (PDT) From: wpaul@FreeBSD.ORG (Bill Paul) To: rh@matriplex.com (Richard Hodges) Cc: hackers@freebsd.org Subject: Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3 Message-ID: <20010716233436.7C0DB37B407@hub.freebsd.org> In-Reply-To: <Pine.BSF.4.10.10107161550460.38762-100000@mail.matriplex.com> from Richard Hodges at "Jul 16, 2001 03:56:33 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
The OS wants the _payload_ to be aligned on a 32-bit boundary. It tries
to do 32-bit accesses to the IP header, and the NFS code also does 32-bit
accesses when trying to un-XDR NFS requests. In both cases, the code
assumes that the data will be aligned on a 32-bit boundary. On the x86,
the alignment doesn't matter: you can do 32-bit loads and stores from
arbitrary boundaries and the CPU will fake things up for you so that
you won't generate an unaligned access trap, though there will be a slight
performance penalty. But on other CPUs such as the alpha, SPARC, PPC
and (I suspect) the IA-64, unaligned accesses in the kernel generate a
fatal trap and a panic. In user space, an unaligned access may result in
a bus error, unless the OS is kind enough to handle the trap, which I
believe FreeBSD/alpha does.
The problem is that the ethernet frame header is only 14 bytes, which
means when the chip DMAs to a 32-bit or 64-bit aligned buffer, the payload,
which immediately follows the ethernet frame header, ends up on a 16-bit
boundary, which is not what we want. You can fix this in one of two ways:
if the chip allows it, you can offset the RX buffer address by two bytes
and thereby force the payload to be 32-bit aligned, or you can copy the
data to a new buffer with the right alignment. Having the chip do it
for you is obviously the prefered approach. The chips supported by the
fxp, xl, pcn, tl, ste, ti, sk, wx and lge drivers support this. The
latter four are all gigE chipsets.
Now, before any of you armchair geniuses out there start chiming in
with your incredibly brilliant solutions for this problem which you
just made up on the spot, forget it. This issue has been discussed
to death and there's just no easy way around it.
Terry Lambert and Alfred Perlstein, this means you. I mean it. Put
down the keyboard and back away from the computer or *blam!* I'll shoot.
> 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...
Most chips place no restrictions on the alignment of TX buffers. The only
exceptions I know of where the chip API simply doesn't permit it are the
RealTek 8139/if_rl (surprise) and the VIA Rhine I and Rhine II/if_vr.
-Bill
=============================================================================
-Bill Paul (925) 691-2800 | Senior Engineer, Master of Unix-Fu
wpaul@osd.bsdi.com | Wind River Systems
=============================================================================
"I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos
=============================================================================
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?20010716233436.7C0DB37B407>