> It adds severe spikes in CPU utilization that are even moderate > line rates begins to affect RTTs. > > Or do you think it's OK to process 500,000 SKBs while locked > in a software interrupt.
You can always push it into a work queue. Even put it to other cores if you want. In fact this is already done partly for the ->completion_queue. Wouldn't be a big change to queue it another level down. Also even freeing a lot of objects doesn't have to be that expensive. I suspect the most cost is in taking the slab locks, but that could be batched. Without that the kmem_free fast path isn't particularly expensive, as long as the headers are still in cache. Long ago I had sk_buff optimized for the routing case so that freeing can be all done with a single cache line. That is long gone, but could be probably restored. But asking for protocol changes just to work around such a internal implementation detail is ... <I miss words> > Perhaps you have another broken awk script to prove this :-) Your hand waved numbers on inline sizes there were definitely worse than mine. -Andi -- 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
