Ben Greear <[EMAIL PROTECTED]> wrote:
>Jay Vosburgh wrote:
>> Sadly, elegance remains elusive, since the by the time skb_bond
>> is called, the slave device the packet arrived on isn't available
>> (vlan->real_dev points to 'bond0' by this point), and that information
>> is needed to decide whether to drop the packet or not.
>> The least grotty solution that comes to mind is to have
>> __vlan_hwaccel_rx call some skb_bond_suppress_dups() function directly,
>> and change skb_bond() to also call that function.
>
>Can you use skb->input_dev?
Not as it is currently implemented. It is set by
netif_receive_skb, not by the vlan accelerator, so input_dev ends up
being the vlan device, not the underlying actual ethernet device. It
looks like input_dev will be inconsistently assigned with vlans over
bonding: if the slave device is vlan accelerated, input_dev will be the
vlan device; if the slave isn't accelerated, input_dev will be the
slave.
As far as I can tell, the input_dev is only used by the
NET_CLS_IND (input device classification) stuff, which has warnings
saying it might be going away. I'm not seeing anything else right
offhand that uses it.
Anyway, the skb_bond logic really needs the enslaved interface,
which isn't necessarily the input_dev (even if input_dev was always the
device that actually had the wire plugged into it). If the slave is
itself some kind of virtual device (a vlan, for example), then input_dev
wouldn't be the right thing.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
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
