From: Herbert Xu <[EMAIL PROTECTED]> Date: Mon, 15 Aug 2005 09:52:51 +1000
> 1) When you allocate for fast clones you do two kmem_cache_alloc's > in a row. You store the second pointer in the shared skb data area. > > The fast path within kmem_cache_alloc is good enough that the second > one should be free most of the time. > > 2) When you do a clone just use the stored pointer and forget about > it since it can be freed independently of the first. I think the atomic operation will still be cheaper than these two function calls. Even though the second one will be "cheap" we could be completely done with just one call and not even pay the reduced price of the second allocation. And since the state tracking is 1) simple and 2) now is known to be doable using skb->user as the refcount (thus eliding the necessity of a new atomic_t), I don't see why in the world you are showing a dislike for the fast-cloning optimization? We won't be even adding a new atomic operation anymore, do you see that? It will just be the plain skb->users decrement we already _must_ do. The total cost is one comparison in skb allocation, and one comparison at free time, and that is the absolute minimum implementation necessary just to choose the correct SLAB cache to alloc/free from :-) I'll cook up an updated patch later so you can see this more clearly. Meanwhile, really let me know why you are so buggered up about the fast cloning idea, I'm truly curious as to where the resistence comes from before we have _any_ performance data one way or the other :-) - 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
