> That sounds like we're really spending most of our time actually handling
> the physical interrupt. Is that right? That implies we don't even get to
> the networking layer, we're just too slow getting the packet off the card.
> And that's scary.
Yes, it is correct. net_bh() does not work mainly not because it is bad,
it just have too small slice of time to make any progress
at high packet load. Timing measurements at moderate loads show,
that 200MHz P-II could handle 100Mbit and more. But at some
threshould (I guess, when average net_bh backlog size exceeds
L1 cache size), exponential degradation starts.
[ BTW there is one very interesting observation: in this state
turning off L2 cache practically did not change timings. ]
It is not so scary really. The solution to this "congestion up to
death problem" is throttling card, when interrupts eat to much of time.
In this case, at least some percent of packets is served and
machine is not locked.
But this percent is still too low to handle pretty usual situation:
One Linux-2.1 box make usual UDP send() in loop, another one receives.
If sender does not make any application level flow control
(again usual situation), Linux receiver drop almost all the packets.
When we bypass net_bh, and queue packets directly to receiver
queue on device interrupt, total packet processing time reduces
to the value, when receiver cannot be congested by single 100Mbit
interface. Compare this with net_bh, when we are able to receive only
about 10Kpps on 233 MHz cpu and forward about 30Kpps, losing >99% of packets
at higher rates.
It is paradox: we have disguisting highly latent transmittion path,
which could be much better, however 2.1 can send much faster than
it is able to receive. 8) BTW NT cannot congest 2.1 8)8)8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/