From owner-freebsd-hackers Fri Feb 4 0:20:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by builder.freebsd.org (Postfix) with SMTP id 3F835441D; Fri, 4 Feb 2000 00:20:21 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id DAA11089; Fri, 4 Feb 2000 03:24:29 -0500 From: Bill Paul Message-Id: <200002040824.DAA11089@skynet.ctr.columbia.edu> Subject: Re: Suggestions for Gigabit cards for -CURRENT To: ken@kdm.org (Kenneth D. Merry) Date: Fri, 4 Feb 2000 03:24:28 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG In-Reply-To: <20000204002446.A59300@panzer.kdm.org> from "Kenneth D. Merry" at Feb 4, 2000 00:24:46 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2833 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, Kenneth D. Merry had to walk into mine and say: > > Talking of the XMAC II, there's one other thing I forgot to mention earlier. > > The FreeBSD sk driver does jumbo frames, but the SysKonnect drivers don't. > > At least, not yet. The XMAC II's receive FIFO is 8K. By default, the chip > > operates in 'store and forward' mode in order to perform error checking on > > received frames (it has to get the entire frame in the FIFO in order to > > do a CRC on it, I think). This is fine for normal frames, but if you want > > to handle jumbograms larger than 8192 bytes, you have to put the chip into > > 'streaming' mode, otherwise any frame larger than 8192 bytes will be truncated. > > To get 'streaming' mode to work, you have to disable all of the RX error > > checking. > > That is unfortunate, since it means you can't do checksum offloading with > jumbo frames. Uhm. I'm not sure about that. The 8K FIFO limitation is in the XMAC II, not in the GEnesis controller. And I believe it's the GEnesis that actually does the hardware checksumming stuff. Oh, and the XMAC appears to have a 4K TX FIFO, not 2K. My mistake. > FWIW, of the three gigabit ethernet implementations I've seen anything of > (Alteon, Intel, SysKonnect), none have implemented all of the hooks > necessary for a seamless zero copy receive implementation. > > Alteon comes the closest, but they don't support splitting out the headers > (yet), which is a requirement for us. The only way to do zero copy receive > with our VM architecture (that I know of) is page flipping, i.e. receive > the page in the kernel, and then trade it for the user's page. You can't > do it on anything less than page-sized granularity, and things have to be > page aligned. (The IO-Lite stuff from Rice is an exception to all this.) > > The nice thing about the Alteon boards, though, is that you can modify the > firmware, and so header splitting is an option there. It would even be > possible to split the headers off of IPv6 packets, or any other protocol > that you have knowlege of. If you can actually modify the firmware to do this then you have a lot more guru points than I do. :) I've looked at the Alteon firmware code but it's all quite opaque to me. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message