From owner-freebsd-hackers Mon Jul 16 16:34:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 7C0DB37B407; Mon, 16 Jul 2001 16:34:36 -0700 (PDT) Subject: Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3 In-Reply-To: from Richard Hodges at "Jul 16, 2001 03:56:33 pm" To: rh@matriplex.com (Richard Hodges) Date: Mon, 16 Jul 2001 16:34:36 -0700 (PDT) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010716233436.7C0DB37B407@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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