Date: Thu, 25 May 2006 16:04:37 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: Gordon Bergling <gbergling@0xfce3.net>, freebsd-current@freebsd.org, Max Laier <max@love2party.net> Subject: Re: Take 2: new IP Checksum Code from DragonFlyBSD Message-ID: <20060525160437.515b4f3e@Magellan.Leidinger.net> In-Reply-To: <20060525115447.GB724@turion.vk2pj.dyndns.org> References: <20060524180802.GA59176@central.0xfce3.net> <200605250517.12054.max@love2party.net> <20060525104000.GA4962@central.0xfce3.net> <20060525115447.GB724@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Peter Jeremy <peterjeremy@optushome.com.au> (Thu, 25 May 2006 21:54:48 +1000): > On Thu, 2006-May-25 12:40:00 +0200, Gordon Bergling wrote: > >* Thus spake Max Laier (max@love2party.net): > >> I'm a little scared about this. We have had several problems in the > >> checksumming code that were due to -O2 or -O0 that screwed up just a little > > > | * This routine is very heavily used in the network > > | * code and should be modified for each CPU to be as fast as > > | * possible. > > But _correct_ code is far more important. And I'm not sure that comment > is still as relevant as it used to be - most (if not all) gigabit NICs > have checksum offloading and processors are fast enough that generic > checksum code should be "good enough" for most lesser purposes. I don't comment on the GB-NIC part (except for: not everything is GB today...), but regarding the "correct" part above: sorry, but that's exactly the reason why I put up the entry for porting this on our ideas page (it never showed up there, since Gordon took it before the page went life). More below. > >So having a better situated implementation is still an improved. The > >patch doesn't touch any arch !i386 and derivates, so I don't see any reason > >why it shouldn't be included. > > You stated that you don't understand the code. IP checksumming is a > crucial part of the kernel so the Project needs to be very careful about > making changes. As Max pointed out, there have been past situations > where the checksum code revealed gcc optimiser bugs so any change has > to be checked using a variety of compiler flags. These are not bugs in the optimizer, but mostly bugs in our assembly code. I had the same problems with the Intel C compiler. The guys at Intel had a look at the code and told me that it's it no the fault of the compiler, but the code is not done right. Therefore I switched to the plain-C version when icc is used to compile the kernel. Here's a short discussion on our mailinglists where Matt tells a little bit more about it: http://lists.freebsd.org/pipermail/freebsd-arch/2004-June/002271.html Basically most of our "huge assembly one" is reduced to a faster "nearly everything is plain-C and only a small part is done in assembly" version. Bye, Alexander. -- Selling GoodYear Eagle F1 235/40ZR18, 2x 4mm + 2x 5mm, ~150 EUR you have to pick it up between Germany/Saarland and Luxembourg/Capellen http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060525160437.515b4f3e>