From owner-freebsd-hackers Thu Feb 26 21:12:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA18765 for freebsd-hackers-outgoing; Thu, 26 Feb 1998 21:12:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA18670 for ; Thu, 26 Feb 1998 21:12:09 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id VAA26266; Thu, 26 Feb 1998 21:09:51 -0800 (PST) Message-Id: <199802270509.VAA26266@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: sthaug@nethelp.no cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: "Best" Fast Ethernet Card In-reply-to: Your message of "Thu, 26 Feb 1998 23:26:20 +0100." <27484.888531980@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Feb 1998 21:09:51 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > One *great* bonus is it will do IP, TCP and UDP checksums automagically > > > in hardware! > > > > Oh great. This card was designed *explicitly* for Windows systems, > > where they think it's funny for the network adapter driver to know > > enough about the protocol layer to manage junk like this. > > Probably not. More likely it was simply meant to give lower CPU usage, > given the right modifications to the TCP/IP stack. If you check the new > Gigabit Ethernet cards that are becoming available, you'll find *most* > of them will do IP checksum on-chip. It's odd then that these cards should be surfacing after NDIS 5 made checksum calculations a feature of the NIC driver, no? > I've included below a recent Usenet article by Craig Partridge which > explains some of the things that can be done to speed up BSD TCP/IP. > You'll note that he explicitly mentions hardware checksums. Sure. However I think the point here is that you can only do hardware checksums efficiently if you collapse the protocol stack to the point where code has access to both the hardware and then TCP layer. That's expedient, and fast, but potentially *very* ugly. It also raises the issue of fragment reassembly. Should you take it into your head to actually implement any of these features, I'm sure we'd be happy to test & integrate them. Note that the stuff about hardware checksumming is a bit of a handwave; it'd be nice if things were that simple, but I can't help thinking that the COW overhead would be worse than the checksum cost for, eg. a telnet session's outbound traffic. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message