Date: Sun, 10 Mar 2002 10:33:01 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Giorgos Keramidas <keramida@ceid.upatras.gr> Cc: Simon 'corecode' Schubert <corecode@corecode.ath.cx>, freebsd-hackers@freebsd.org Subject: Re: Swapping performance Message-ID: <3C8BA6DD.7D57BAB1@mindspring.com> References: <20020307090707.GC26621@elvis.mu.org> <Pine.BSF.4.21.0203070359110.41354-100000@InterJet.elischer.org> <20020307142759.0d95d467.mitko@rila.bg> <20020307080906.367be8df.gclarkii@vsservices.com> <20020307164724.D377@straylight.oblivion.bg> <20020307153615.GB1942@student.uu.se> <20020307164500.5dd21d16.corecode@corecode.ath.cx> <20020310125158.GA798@hades.hell.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
Giorgos Keramidas wrote: > On 2002-03-07 16:45, Simon 'corecode' Schubert wrote: > > to everybody who doesn't believe that: it really generates bad code. > > i've been having severe problems with my tcp and udp stack lately (on a > > i586/mmx machine). guess what, -O2 resulted in code which >>sometimes<< > > generated bad tcp and/or udp checksums (depending on ip). i didn't > > investigate any further, but believe me: not being able to access some > > dns servers is a pain in the ass. > > I've seen this too. When I built both my kernel and userland with -O3, > problems accessing the Internet started. When I tried to use tcpdump to > find out what went wrong, I saw that it reported *all* outgoing packets for > *some* hosts as invalid [0xffff]. > > The funny thing was that depending on which source/destination I used, it > would either work or fail. For destinations that it failed once, it failed > all the time. Since I could not verify both the userland and kernel > binaries, I chose to disable most optimizations and stick with -O :-) Uh, I told you guys the NAT checksum code is broken for certain underflow cases. THis includes the TCP pseudo-header rewrite and the IP header rewrite, when the source and destination address sum goes negative. A simple way of fixing the calculation is to convert all operands to shorts, and then add with carry into an int, folding the final result. You have to accumulate the old value (m) and the new value (m') in seperate accumulators, then reduce the accumulations to shorts, again. THen you compute the final value, per RFC 1624, and reduce it to a short, as well: HC' = ~(~HC + ~m +m') Those are all 16-bit "~"'s; the same effect is available for an int value (which the accumulators should be) via m^0x0000ffff. The key here is that the underflow is associative, but not commutative (this failure, though, is a different commutation than the failure dicussed in the reason RFC 1624 is updating the algorithm). Note that your accumulators must be int's, or you aren't folding the carrys correctly. -- Terry 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?3C8BA6DD.7D57BAB1>