Date: Fri, 4 Feb 2000 03:24:28 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: ken@kdm.org (Kenneth D. Merry) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Suggestions for Gigabit cards for -CURRENT Message-ID: <200002040824.DAA11089@skynet.ctr.columbia.edu> In-Reply-To: <20000204002446.A59300@panzer.kdm.org> from "Kenneth D. Merry" at Feb 4, 2000 00:24:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002040824.DAA11089>