Robert Olsson wrote:
jamal writes:
> Latency-wise: TX completion interrupt provides the best latency.
> Processing in the poll() -aka softirq- was almost close to the hardirq
> variant. So if you can make things run in a softirq such as transmit
> one, then the numbers will likely stay the same.
I don't remember we tried tasklet for TX a la Herbert's suggestion but we
used use tasklets for controlling RX processing to avoid hardirq livelock
in pre-NAPI versions.
Had variants of tulip driver with both TX cleaning at ->poll and TX
cleaning at hardirq and didn't see any performance difference. The
->poll was much cleaner but we kept Alexey's original work for tulip.
> Sorry, I havent been following discussions on netchannels[1] so i am not
> qualified to comment on the "replacement" part Dave mentioned earlier.
> What I can say is the tx processing doesnt have to be part of the NAPI
> poll() and still use hardirq.
Yes true but I see TX numbers with newer boards (wire rate small pakets)
with cleaing in ->poll. Also now linux is very safe in network "overload"
situations. Moving work to hardirq may change that.
I also noticed that you really don't save much by doing TX cleaning at
hardirq, because in hardirq you need to do dev_kfree_irq and that causes
a softirq (for the routing case where users=1). So when routing it
doesn't make much difference, both methods cause the softirq delayed
processing to be invoked. For locally generated packets which are
cloned, the hardirq will drop the ref count, and that is faster than
doing the whole softirq round trip.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
