>> What not pass a list of skbs (e.g. using skb->next)? > > Because the next layer, the slab API needs an array: > kmem_cache_free_bulk(struct kmem_cache *s, size_t size, void **p) >
I suppose we could ask the same question of that function. IMO encouraging drivers to define arrays of pointers on the stack like you're doing in the ixgbe patch is a bad direction. In any case I believe this would be simpler in the networking side just to maintain a list of skb's to free. Then the dev_free_waitlist structure might not be needed then since we could just use a skb_buf_head for that. Tom > Look at the patch: > [PATCH V2 3/3] slub: build detached freelist with look-ahead > http://thread.gmane.org/gmane.linux.kernel.mm/137469/focus=137472 > > Where I use this array to progressively scan for objects belonging to > the same page. (A subtle detail is I manage to zero out the array, > which is good from a security/error-handling point of view, as pointers > to the objects are not left dangling on the stack). > > > I cannot argue that, writing skb->next comes as an additional cost, > because the slUb free also writes into this cacheline. Perhaps the > slAb allocator does not? > > [...] >> > + if (likely(cnt)) { >> > + kmem_cache_free_bulk(skbuff_head_cache, cnt, (void **) >> > skbs); >> > + } >> > +} >> > +EXPORT_SYMBOL(kfree_skb_bulk); > > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Sr. Network Kernel Developer at Red Hat > Author of http://www.iptv-analyzer.org > LinkedIn: http://www.linkedin.com/in/brouer -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
