>>I think the skbinit patch and recycling skbs are mutually exclusive.
>I would say they are more orthogonal than mutually exclusive.
>Although ou still need to prove that relocating the code actually helps in
>real life. On paper it looks good.
Troy Wilson (who works with me) posted SPECweb99 results using my
skbinit patch to lkml on Friday:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.2/1470.html
I know you don't subscribe to lkml. Have you seen these results?
On Numa machine it showed around 3% improvement using SPECweb99.
Regards,
Mala
Mala Anand
IBM Linux Technology Center - Kernel Performance
E-mail:[email protected]
http://www-124.ibm.com/developerworks/opensource/linuxperf
http://www-124.ibm.com/developerworks/projects/linuxperf
Phone:838-8088; Tie-line:678-8088
Mala Anand writes:
> I know you don't subscribe to lkml. Have you seen these results?
> On Numa machine it showed around 3% improvement using SPECweb99.
In slab terms you moved part of the destructor to the constructor
but the main problem is still there. The skb entered the "wrong" CPU
so to be "reused from the slab again" the work has to done regardless
if it's in the constructor or destructor.
Eventually if we accept some cache misses a skb could possibly be re-routed
to the proper slab/CPU for this we would need some skb coloring.
Also I noticed your TCP results w. e1000.
Here is what I see:
Linux 2.4.20-pre4/UP PIII @ 933 MHz w. Intel's e100 2 port GIGE adapter.
e1000 4.3.2-k1 (current kernel version) and current NAPI patch. For NAPI
e1000 driver used RxIntDelay=1. RxIntDelay=0 caused problem now. Non-NAPI
driver used RxIntDelay=64. (default)
Three tests: TCP, UDP, packet forwarding.
Netperf. TCP socket size 131070, Single TCP stream. Test length 30 s.
M-size e1000 NAPI-e1000
============================
4 20.74 20.69 Mbit/s data received.
128 458.14 465.26
512 836.40 846.71
1024 936.11 937.93
2048 940.65 939.92
4096 940.86 937.59
8192 940.87 939.95
16384 940.88 937.61
32768 940.89 939.92
65536 940.90 939.48
131070 940.84 939.74
Netperf. UDP_STREAM. 1440 pkts. Single UDP stream. Test length 30 s.
e1000 NAPI-e1000
====================================
955.7 955.7 Mbit/s data received.
Forwarding test. 1 Mpkts at 970 kpps injected.
e1000 NAPI-e1000
=============================================
Tput 305 298580 Pkts routed.
Cheers.
--ro
On Mon, 26 Aug 2002, Mala Anand wrote:
> Troy Wilson (who works with me) posted SPECweb99 results using my
> skbinit patch to lkml on Friday:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.2/1470.html
> I know you don't subscribe to lkml. Have you seen these results?
> On Numa machine it showed around 3% improvement using SPECweb99.
>
The posting you pointed to says 1% - not that it matters. It becomes more
insignificant when skb recycling comes in play mostly because the alloc
and freeing of skbs doesnt really show up as hotlist item within
the profile.
I am not saying it is totaly useless -- anything that will save a few
cycles is good;
cheers,
jamal