From: Bogdan Costescu <bogdan.costescu@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 10 Jun 2003 18:45:03 +0200 (CEST)
With this driver I would typically get TCP bandwidth figures
4-5 Mbps lower than those obtained with 3c59x and noticable difference in
the parallel jobs timing (using MPI over TCP). I'm not saying that NAPI
will perform the same way, just that there might be also hardware limits
somewhere...
I think it won't, hardware interrupt mitigation schemes have lots of
problems that NAPI is more ept to deal with.
But the real question is: does it make sense to spend time now in
trying to improve a driver with hope for only a marginal speed
increase ?
People who have the cards care, and I think PIO-->MMIO is more
than marginal.
You're attempt to get "latency" was ill founded :) Your limits
have to do with the wire speed, not all the cpu cycles being eaten
by PIO acceses.
On a DoS'd router, it's another situation altogether.
And another important question: how much improvement can be gained from
the driver ? Folks that do parallel computation over TCP over Ethernet
know very well that the software in the kernel is the bottleneck (extra
copies, TCP, IRQ management, etc).
Your lmitations in parallel computation have to do with how TCP
behaves more than how TCP is implemented.
For starters try:
echo "1" >/proc/sys/net/ipv4/tcp_low_latency
That's the kind of thing that will help parallel computation
folks, not driver hacks.
|