On 10/11/2011 4:08 AM, Hans Schillstrom wrote:

Hello
On Tuesday 11 October 2011 04:43:03 Jesse Gross wrote:

quoted

On Mon, Oct 10, 2011 at 7:07 PM, John Fastabend
[off-list ref] wrote:

quoted

On 10/10/2011 3:37 PM, Jiri Pirko wrote:

quoted

Mon, Oct 10, 2011 at 09:16:41PM CEST, john.r.fastabend@intel.com wrote:

quoted

The following configuration used to work as I expected. At least
we could use the fcoe interfaces to do MPIO and the bond0 iface
to do load balancing or failover.

      ---eth2.228-fcoe
      |
eth2 -----|
         |
         |---- bond0
         |
eth3 -----|
      |
      ---eth3.228-fcoe

This worked because of a change we added to allow inactive slaves
to rx 'exact' matches. This functionality was kept intact with the
rx_handler mechanism. However now the vlan interface attached to the
active slave never receives traffic because the bonding rx_handler
updates the skb->dev and goto's another_round. Previously, the
vlan_do_receive() logic was called before the bonding rx_handler.

Now by the time vlan_do_receive calls vlan_find_dev() the
skb->dev is set to bond0 and it is clear no vlan is attached
to this iface. The vlan lookup fails.

This patch moves the VLAN check above the rx_handler. A VLAN
tagged frame is now routed to the eth2.228-fcoe iface in the
above schematic. Untagged frames continue to the bond0 as
normal. This case also remains intact,

eth2 --> bond0 --> vlan.228

Here the skb is VLAN tagged but the vlan lookup fails on eth2
causing the bonding rx_handler to be called. On the second
pass the vlan lookup is on the bond0 iface and completes as
expected.

Putting a VLAN.228 on both the bond0 and eth2 device will
result in eth2.228 receiving the skb. I don't think this is
completely unexpected and was the result prior to the rx_handler
result.

I think this OK, but I do have a question
if bond0 is in Active/Backup mode, eth2 and eth3 got the same MAC.addr,
what about the VLAN:s ?
(or is just one of thme working ??)

The VLAN MAC address will not be managed by the bond. In the
storage case a SAN mac may be used (NETDEV_HW_ADDR_T_SAN).
Otherwise the MAC can be managed normally.

Both VLANs will receive frames but in some modes only to packet
handlers that have exact matches. See bond_should_deliver_exact_match().

.John.