David S. Miller wrote:
I studied this and it's merely a matter of parameter passing.
Specifically, at ptype->func() time, it is plainly the skb->dev
before skb_bond() is applied.
So I added a "real_dev" arg to ptype->func() and converted
the tree over to that.
Thomas, this kills the TCF_META_ID_REALDEV stuff, so we should
kill it in 2.6.13-rcX too so that nobody starts using it in
userspace ok?
I'm trying to figure out if it matters for multiple levels of
decapsulation. As far as I can tell for the bond_3ad() case,
it doesn't, and that's the only user of this thing.
if_vlan.h was setting ->real_dev but that looked totally wrong
and had no usage, so I simply deleted that.
Comments?
Well, I have some code that uses this, but it's not in the tree proper.
I can carry the skb->real_dev in my patch if I have to, but maybe
the general mechanism could be useful to others too.
Here is how I use it:
I have some virtual devices, of which 802.1Q VLANs are a good example. When
using something like pktgen to send packets you can over-run the transmit
queue of the underlying ethernet device. For ethernet devices, it is easy to
know when you can restart the transmission again because it will send an
interrupt
or otherwise notify wakeup via pg_notify_queue_woken.
The problem is that virtual interfaces do not have interrupts, and so are not
woken up in the same manner (actually, they probably never go to sleep, which
is why I added some logic to return an error code from vlan's hard_start_xmit
when the vlan failed to transmit to it's lower layer.)
I added a hook in the pg_notify_queue_woken method to wake any interested
parties (ie, pktgen). In order to get this to function with VLANs, I set the
hook on the vlan->real_dev because that is the device that is actually woken,
not the virtual.
Among other things, this allows me to have a pktgen that does not busy spin
trying to transmit when the device's tx queues are full. I think this logic
would be useful for anyone writing code that wants to send traffic very fast
on virtual devices and cares enough not to just send packets that will
immediately
be dropped when the underlying device is congested.
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
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
