Subject: Re: tuning IP checksumming code...
To: Thorsten Lockert <tholo@SigmaSoft.COM>
From: Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu>
List: tech-net
Date: 07/18/1996 00:07:21
> The fields are mbuf chain length, total bytes in chain [ ... ]

I'm not going to comment on the numbers at all; i don't care
about them, or i386 checksum performance.

However, I do have to ask: what rationale was used for picking the
chain length and/or number of bytes in the chain?  The numbers
below seem to make no sense.  (I know what Charles uses in his
test harness, because i've used it, and they _do_ seem to make
sense.)

(1) your longest chain is 16 mbufs?  are there really 16-mbuf chains
    floating around out there, in regular usage?  Are they as
    common as you'd have them seem?

(2) the longest "total bytes" shown was 948...  That's unrealistic,
    given the typical size that NFS packets have when they hit the
    wire, even more unrealistic if you think about how they get
    passed around in the kernel and where they get checksummed.


BTW, don't bother giving an answer of "but his is slower in any
case," because, like i said, i just don't care.  I don't even
care which would do better if you increased the size of the
packets in your test.  I want to know why you picked those
numbers (or why you have your random number generator tuned such
that it picked those numbers), and why you think they're a valid
measure of real-world performance.


cgd