From: jamal <[EMAIL PROTECTED]> Date: Fri, 30 Jun 2006 15:40:26 -0400
> My arguement was: > dev get by index per device will involve a a) lookup + b) incrementing > the refcount. > if i use the dev pointer in that path then it becomes only #b > > in both cases, you need to increment the counter and then somewhere > decrement it. The position is that ->input_dev usage is not fast path. It may be a fast path in your mirred and ifb devices, but for the rest of the networking and %99 of users it is totally unused. We have a lot of bits of state that sit in the sk_buff but which are used by a tiny minority, yet the space consumption is eaten by everyone. Maybe when the IFB and mirred are in more widespread use we can investigate a different approach. But at this time any change that makes fringe sk_buff state objects shrink or disappear will be seriously considered. Another part of this issue is that if you use a pointer there is no clean place to clean up the input_dev reference within the scope it is actually used. The only reliable place is kfree_skb() which is far beyond the scope that this ->input_dev thing is used. We have a lot of problems in some parts of the networking because object references are held for too long. One example is all the awful side effects of the way the bridge netfilter code holds onto object references for long periods of time in the netfilter call chains. And we know the refcounting is broken. And one way we know to fix the refcounting without incurring the cost upon everyone is to use an interface index and only make the input_dev users eat the atomic operation incurred by grabbing the reference. And even for the input_dev users, it isn't such a big deal, there are other costs already associated with hitting these actions and devices that use input_dev, the atomic reference grab there should be lost in the noise I think. - 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
