Re: netif_tx_disable and lockless TX

[Stephen Hemminger <shemminger@osdl.org>]

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.