Date: Fri, 21 Jan 2000 21:34:23 -0800 (PST) From: Jim Shankland <jas@flyingfox.com> To: brett@lariat.org, bright@wintelcom.net, dillon@apollo.backplane.com Cc: phk@critter.freebsd.dk, security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001220534.VAA10095@biggusdiskus.flyingfox.com> In-Reply-To: <4.2.2.20000121205951.01a58bb0@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass writes: > At 08:46 PM 1/21/2000 , Alfred Perlstein wrote: > > >Please look at tcp_input, notice the "goto drop" and "goto > >dropwithreset" jumps, they are scattered throught and after some > >pretty close examination (no tests yet) I've been able to see that > >we can signifigantly move the tcp checksum farther into the path. > > One of the first things the routine does is look for a socket that > matches the TCP header. This relies on the port numbers and control > bits, which are covered by the checksum. This is the hard limit > on how long you can defer the checksum. With all due respect, I think you guys are polishing a pretty round ball here. If checksumming is so all-fired expensive, how come I can saturate a 100 Mb/s point-to-point Ethernet link with an ftp transfer to a fairly slow machine (Pentium 133? not sure, it's been a few years since I did this) without the machine buckling under the weight of all that checksumming (plus socket buffering, user process scheduling, etc.). If a 10 Mb/s junk packet stream can really bring a FreeBSD machine to its knees, I don't think it's the checksumming that's the problem. Jim Shankland NLynx Systems, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001220534.VAA10095>