Date: Sat, 29 Sep 2001 15:39:32 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, the_srinivas@hotmail.com, hackers@FreeBSD.ORG Subject: Re: TCP&IP cksum offload on FreeBSD 4.2 Message-ID: <20010929153932.A50715@panzer.kdm.org> In-Reply-To: <3BB61A6B.A97E955A@mindspring.com>; from tlambert2@mindspring.com on Sat, Sep 29, 2001 at 12:00:59PM -0700 References: <200109270157.f8R1vZ546863@prism.flugsvamp.com> <3BB42E50.B32F5E95@mindspring.com> <20010928074347.A36960@panzer.kdm.org> <3BB61A6B.A97E955A@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 29, 2001 at 12:00:59 -0700, Terry Lambert wrote: > "Kenneth D. Merry" wrote: > [ ... transmit checksum offload ... ] > > > You've got things confused. I think that may be a limitation of some > > SysKonnect boards, but certainly isn't a Tigon limitation. > > Yes, it's not Tigon chipset specific. It's not a Tigon chipset problem at all. > > Tigon boards come with 512KB, 1MB, or 2MB (never seen one of these) of SRAM > > on board. The firmware takes a couple hundred KB, so you generally have at > > least 200KB, and possibly a good bit more for packet storage space on the > > card. > > > > So there is buffer space for a number of packets on both the send and > > receive sides, and checksumming works in both directions. > > This depends on the driver division of memory; fortunately, > the FreeBSD driver is OK in this regard. I suppose if you set the transmit/receive buffer ratio all the way to one side or the other, you'd have problems, but any driver writer with half a clue wouldn't do that. > > > Also note that this card is not known to be the fastest > > > one ot there, so you may be better off doing the checksum > > > on your 1GHz+ host processor instead. > > > > You can get wire rate with a Tigon 2 board, with jumbo frames at least. > > (That's with checksum offloading enabled.) > > Unfortunately, it can not correctly interoperate with a > number of cards in jumbogram mode, so unless you know the > card on the other end and manually configure it (it can't > negotiate properly), you can't really use jumbograms. Or > you could rewrite the firmware (of course). Huh? Care to explain? Why wouldn't it interoperate with jumbo frames? Why are jumbo frames something that need be negotiated by the card? They're not negotiated by the card, but rather by the TCP stack. > I have never seen the board with the stock FreeBSD driver > get better than about half wire rate with normal size > packets and window depth. Yep, it doesn't handle large numbers of small packets very well. You can easily get wire rate with jumbo frames, though. > On the other hand, the Tigon III > is capable of 960 megabits -- about the wire rate limit -- > with normal size packets, if you implement software interrupt > coelescing (which doesn't help, unless you crank the load up > to close to wire speed and/or do more of the stack processing > at interrupt time). > > The Tigon II also has the unfortunate need to download its > firmware, and a FreeBSD bug -- the lack of a distinct state > for firmware download -- means that the firmware get sent > to the card each time the thing is config'ed up, or an IP > alias is added to the thing. Plus the damn things are more > expensive than the Tigon III based cards. That's partially because Bill wanted to have a process context when he was downloading the firmware, and didn't want to do a kernel thread to do it. So it gets done when the card is ifconfiged up. I wrote some code for my former employer to wait up to 10 seconds for link to show up when the board is configured. The alternative is a 'sleep 5' (for fiber boards) or 'sleep 8' (for copper boards) after it is ifconfiged up. Having downloadable firmware is actually a huge advantage. You can do things with the Tigon II that just aren't possible with any other chip, either because they don't have downloadable firmware, or because the vendor won't release firmware source. This is a problem with the Broadcom Tigon III boards, and to some extent with the Tigon II. Basically it looks like the firmware for the Tigon II is very hard to get now that 3Com has control of it, and I don't think Broadcom will release the Tigon III firmware. (Assuming it is a firmware-based chip.) > To put a final nail in the coffin, the card can't offload > TCP checksum with VLANs enabled (it breaks). Probably something that could be fixed in the firmware. Too bad the vendor isn't really supporting it very much now. > All in all, the Tigon II is a bad board. That's your opinion, but I disagree. 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?20010929153932.A50715>