* David S. Miller <[EMAIL PROTECTED]> 2005-08-13 14:10 > From: Herbert Xu <[EMAIL PROTECTED]> > Date: Sat, 13 Aug 2005 11:32:39 +1000 > > > I actually had a play with the fast clone stuff. However, eventually > > I gave up because of this dilemma: I needed to either introduce an extra > > atomic op on the __kfree_skb path, or add bloat to the inlined kfree_skb > > path. > > It might be possible to make use of skb->users, but currently > the patch Thomas and myself are trying to get to work is > adding a new fclone_ref member.
Indeed, this is actually a great idea. We can simply inc users when fast-cloning so we'll only reach kfree_skbmem if a free is actually safe. We still need 2 state bits though, one bit to mark a skb as fast-clone'able so we use the correct slab cache when freeing and a second bit to identify whether we're the parent or clone so we pass on the correct address. The disadvantage is that we cannot do "clone resycling" easly anymore, that is we allow a fast-clone'able skb to be cloned up again if the clone portion was already freed. - 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
