* jamal <[EMAIL PROTECTED]> 2006-06-30 22:23
> I am not certain i understood then: Are we in the mode where the
> refcount is not needed because chances are small that a device will
> disappear? It seems to me after all this trouble that it may not be so
> bad to refcount (I guess i meant refcount the device on input to the ifb
> and decrement on the output).
Based on two principles:
a) All netdevices a packet is processed through is properly
refcounted until the packet is queued for the first time.
Given that iif is strictly set to the previous device, a
refcnt is certainly taken up to the point where the skb is
put into rq. There is one exception to this: The fact that
you don't set skb->dev = ifb when reinjecting at ingress
will not take a refcnt on the ifb. This sounds like a broken
architecture to me but it doesn't matter as you want to
prohibit ifb -> ifb anyways.
b) The netdevice used for xmit via dev_queue_xmit() is already
protected by the initial xmit attempt.
I can't see reason why to hurt performance by introducing more
atomic operations in your fast path.
If you have more concerns regarding these patches, feel free to
fix your own architecture or propose to drop the patches, I think
I've spend enough time on this.
-
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
