On Wed, 2006-31-05 at 22:40 +1000, Herbert Xu wrote: > On Wed, May 31, 2006 at 08:36:12AM -0400, jamal wrote: > > [..] > > > > Been done in the past, bad numbers especially in SMP for reasons of > > latency and likelihood that a tasklet will run in a totally different > > CPU. > > Was the bad latency measured with code like the above or was it with > an unconditional tasklet schedule? >
The idea was to prune those skbs for reuse within reason so as to not sacrifice perfomance. Perfomance is sacrificed if you have too many TX EOLs, or you dont prune the descriptors fast enough. The dynamics of proved to be hard to nail in a generic way because behavior varies based on traffic patterns. So the "within reason" part will unconditionally schedule a tasklet on the tx if certain DMA ring thresholds are crossed, way after the tx lock has been grabbed which is different from your suggestion to do it when you cant grab a lock. Otherwise you let the hardirq take care of things. Tasklets proved to be a bad idea and instead we ended reclaiming the skb/descriptors right at the point where we initially had scheduled tasklets. I dont know what happened to using that technique - Robert can testify better than i. > Please note that my code will do the completion in the IRQ handler > most of the time. Only if there is contention for the spin lock will > it defer work to the softirq. that part is different and I think there may be potential - it will require experimenting with a variety of traffic patterns. I wish i had time to help. cheers, jamal - 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
