Re: [PATCH] 2.6.9 Use skb_padto() in drivers/net/8390.c

From: Paul Gortmaker
Date: Sun Jan 09 2005 - 21:51:55 EST


Alan Cox wrote:

>On Sad, 2005-01-08 at 08:33, Paul Gortmaker wrote:
>
>
>>Is it possible that skb_padto has since got its act together? Reason I
>>ask is that I just dusted off a crusty 386dx40 (doesn't get much older
>>
>
>Could be - kmalloc has probably improved but the skbuffs have got far
>more complex
>
>
>>than that) with a wd8013. As a basic test, I did ttcp Tx tests with small
>>packets and they came out to all intents and purposes, identical. Kernel
>>was 2.6.10, with stack vs skb_padto, each size test ran 3 times, even tested
>>packets bigger than ETH_ZLEN as a (hopefully) invariant. I've attached the
>>edited down results below.
>>
>
>What are you testing ? I don't see the relationship between network
>throughput and efficiency on this device.

I was thinking that for a sufficiently slow CPU running at 100% (hence the
lowly 386), the throughput would be influenced by how efficiently we can
get in, get the Tx set up and get out.

>Drop it on a pentium or late 486 and use the tsc to compare the two code
>paths. One is much much more efficienct.

Using rdtscl over the area affected by the patch on the two variants for a
sample of 234 small packets, I see an average of 4141 for using the
existing stack scratch area, and 4162 for using skb_padto. That is a
difference of about 0.5%, which is significantly less than the typical
spread in the samples themselves. To help give a relevant scale, feeding
it a larger 1400 byte packet comes in at around 60,000 cycles on this
particular box. Am I being optimistic to see this as good news -- meaning
that there is no longer a need for driver specific padto implementations,
whereas it looks like there was back when you did your tests?

Paul.




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/