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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:18 EST