Date: Fri, 4 Feb 2000 00:24:46 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Suggestions for Gigabit cards for -CURRENT Message-ID: <20000204002446.A59300@panzer.kdm.org> In-Reply-To: <200002040409.XAA10688@skynet.ctr.columbia.edu>; from wpaul@skynet.ctr.columbia.edu on Thu, Feb 03, 2000 at 11:09:46PM -0500 References: <20000203193710.A57242@panzer.kdm.org> <200002040409.XAA10688@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 03, 2000 at 23:09:46 -0500, Bill Paul wrote: > Of all the gin joints in all the towns in all the world, Kenneth D. Merry had > to walk into mine and say: > > > > > Alteon also provides firmware source, which can really come in handy. Do > > you know if SysKonnect has released firmware? > > The SysKonnect GEnesis controller and the XaQti XMAC II chips are both static > devices and do not require firmware. If you go to www.syskonnect.com and > search their online knowledge base for the word "manual" you should be > able to find the gigabit NIC programmer's manual. Similarly, XaQti has > the full datasheet for the XMAC II at www.xaqti.com somewhere. (As I recall, > you have to go through a brief registration procedure to get it, but once > that's done you should be able to download it right away.) Well, all-hardware designs can be great when they're done right, and irritating when they're not. Thanks for the manual pointers. I've got the SysKonnect manual, and it seems pretty nifty. > 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. 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. Ken -- Kenneth Merry ken@kdm.org 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?20000204002446.A59300>