Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-20 Thread Christophe Devriese 
This fixes my issue. Thanks.

On Tuesday 15 August 2006 02:09, you wrote:
 From: Jay Vosburgh [EMAIL PROTECTED]
 Date: Thu, 03 Aug 2006 18:01:35 -0700

  In this case (bond0.555 above bond0 above eth0,eth1,etc),
  skb_bond doesn't suppress duplicates because skb_bond is called with the
  skb-dev set to the bond0.555 dev, not the ethX dev.  Non-accelerated
  VLAN devices don't do this; they'll come in with skb-dev set to ethX
  and will go through skb_bond as expected.

 Ok, since __vlan_hwaccel_rx() bypasses the netif_receive_skb()
 that would normally occur, we have to duplicate the bonding
 drop checks.

 The submitted patch put skb_bond() into if_vlan.h which is
 definitely the wrong thing to do.  This is a generic operation
 and therefore belongs in linux/netdevice.h at best.

 Furthermore, we're only interested in the packet drop check,
 so that's the only part of the logic we need to export,
 the rest can stay private to skb_bond() in net/core/dev.c

 Can the folks who can reproduce this try this patch?

 Thanks.

 commit 8a9583e08d0524e3bfe43a51af7c66ca21adf9f3
 Author: David S. Miller [EMAIL PROTECTED]
 Date:   Mon Aug 14 17:08:36 2006 -0700

 [VLAN]: Make sure bonding packet drop checks get done in hwaccel RX
 path.

 Since __vlan_hwaccel_rx() is essentially bypassing the
 netif_receive_skb() call that would have occurred if we did the VLAN
 decapsulation in software, we are missing the skb_bond() call and the
 assosciated checks it does.

 Export those checks via an inline function, skb_bond_should_drop(),
 and use this in __vlan_hwaccel_rx().

 Signed-off-by: David S. Miller [EMAIL PROTECTED]

 diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
 index 383627a..ab27408 100644
 --- a/include/linux/if_vlan.h
 +++ b/include/linux/if_vlan.h
 @@ -155,6 +155,11 @@ static inline int __vlan_hwaccel_rx(stru
  {
   struct net_device_stats *stats;

 + if (skb_bond_should_drop(skb)) {
 + dev_kfree_skb_any(skb);
 + return NET_RX_DROP;
 + }
 +
   skb-dev = grp-vlan_devices[vlan_tag  VLAN_VID_MASK];
   if (skb-dev == NULL) {
   dev_kfree_skb_any(skb);
 diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
 index 75f02d8..c0c2b46 100644
 --- a/include/linux/netdevice.h
 +++ b/include/linux/netdevice.h
 @@ -1012,6 +1012,30 @@ static inline int netif_needs_gso(struct
   unlikely(skb-ip_summed != CHECKSUM_HW));
  }

 +/* On bonding slaves other than the currently active slave, suppress
 + * duplicates except for 802.3ad ETH_P_SLOW and alb non-mcast/bcast.
 + */
 +static inline int skb_bond_should_drop(struct sk_buff *skb)
 +{
 + struct net_device *dev = skb-dev;
 + struct net_device *master = dev-master;
 +
 + if (master 
 + (dev-priv_flags  IFF_SLAVE_INACTIVE)) {
 + if (master-priv_flags  IFF_MASTER_ALB) {
 + if (skb-pkt_type != PACKET_BROADCAST 
 + skb-pkt_type != PACKET_MULTICAST)
 + return 0;
 + }
 + if (master-priv_flags  IFF_MASTER_8023AD 
 + skb-protocol == __constant_htons(ETH_P_SLOW))
 + return 0;
 +
 + return 1;
 + }
 + return 0;
 +}
 +
  #endif /* __KERNEL__ */

  #endif   /* _LINUX_DEV_H */
 diff --git a/net/core/dev.c b/net/core/dev.c
 index d95e262..9fe96cd 100644
 --- a/net/core/dev.c
 +++ b/net/core/dev.c
 @@ -1619,26 +1619,10 @@ static inline struct net_device *skb_bon
   struct net_device *dev = skb-dev;

   if (dev-master) {
 - /*
 -  * On bonding slaves other than the currently active
 -  * slave, suppress duplicates except for 802.3ad
 -  * ETH_P_SLOW and alb non-mcast/bcast.
 -  */
 - if (dev-priv_flags  IFF_SLAVE_INACTIVE) {
 - if (dev-master-priv_flags  IFF_MASTER_ALB) {
 - if (skb-pkt_type != PACKET_BROADCAST 
 - skb-pkt_type != PACKET_MULTICAST)
 - goto keep;
 - }
 -
 - if (dev-master-priv_flags  IFF_MASTER_8023AD 
 - skb-protocol == __constant_htons(ETH_P_SLOW))
 - goto keep;
 -
 + if (skb_bond_should_drop(skb)) {
   kfree_skb(skb);
   return NULL;
   }
 -keep:
   skb-dev = dev-master;
   }
-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-16 Thread Krzysztof Oledzki 



On Mon, 14 Aug 2006, David Miller wrote:


From: Jay Vosburgh [EMAIL PROTECTED]
Date: Thu, 03 Aug 2006 18:01:35 -0700


In this case (bond0.555 above bond0 above eth0,eth1,etc),
skb_bond doesn't suppress duplicates because skb_bond is called with the
skb-dev set to the bond0.555 dev, not the ethX dev.  Non-accelerated
VLAN devices don't do this; they'll come in with skb-dev set to ethX
and will go through skb_bond as expected.


Ok, since __vlan_hwaccel_rx() bypasses the netif_receive_skb()
that would normally occur, we have to duplicate the bonding
drop checks.

The submitted patch put skb_bond() into if_vlan.h which is
definitely the wrong thing to do.  This is a generic operation
and therefore belongs in linux/netdevice.h at best.

Furthermore, we're only interested in the packet drop check,
so that's the only part of the logic we need to export,
the rest can stay private to skb_bond() in net/core/dev.c

Can the folks who can reproduce this try this patch?


Works for me, thank you.

Acked-by: Krzysztof Piotr Oledzki [EMAIL PROTECTED]

Best regards,

Krzysztof Olędzki

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-15 Thread Jay Vosburgh 
David Miller [EMAIL PROTECTED] wrote:
[...]
Ok, since __vlan_hwaccel_rx() bypasses the netif_receive_skb()
that would normally occur, we have to duplicate the bonding
drop checks.

The submitted patch put skb_bond() into if_vlan.h which is
definitely the wrong thing to do.  This is a generic operation
and therefore belongs in linux/netdevice.h at best.

Furthermore, we're only interested in the packet drop check,
so that's the only part of the logic we need to export,
the rest can stay private to skb_bond() in net/core/dev.c

Can the folks who can reproduce this try this patch?

I have successfully reproduced the problem and subsequently
validated this patch against 2.6.17.6.  I'm building netdev-2.6#upstream
right now, but I expect it will work as well (and will report back only
if it does not).

Acked-by: Jay Vosburgh [EMAIL PROTECTED]

-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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-14 Thread Christophe Devriese 
On Friday 11 August 2006 08:45, you wrote:
 From: Krzysztof Oledzki [EMAIL PROTECTED]
 Date: Thu, 10 Aug 2006 20:18:23 +0200 (CEST)

  OK, this patch really solves the bug from my report. Are there any
  chances for similar fix in the net-2.6.19.git?

 I'm still thinking about this patch and what various people have
 explained about the situation.

Anything I can do ? I need this bug fixed.

Regards,

Christophe
-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-14 Thread David Miller 

BTW, I'll be honest with you, by continuing to bug me about this, it
makes me want to look at this issue less, not more.

Just be patient ok?
-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-14 Thread David Miller 
From: Christophe Devriese [EMAIL PROTECTED]
Date: Mon, 14 Aug 2006 10:16:36 +0200

 On Friday 11 August 2006 08:45, you wrote:
  From: Krzysztof Oledzki [EMAIL PROTECTED]
  Date: Thu, 10 Aug 2006 20:18:23 +0200 (CEST)
 
   OK, this patch really solves the bug from my report. Are there any
   chances for similar fix in the net-2.6.19.git?
 
  I'm still thinking about this patch and what various people have
  explained about the situation.
 
 Anything I can do ? I need this bug fixed.

Then patch your kernel, you don't need my permission for that.

-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-14 Thread David Miller 
From: Jay Vosburgh [EMAIL PROTECTED]
Date: Thu, 03 Aug 2006 18:01:35 -0700

   In this case (bond0.555 above bond0 above eth0,eth1,etc),
 skb_bond doesn't suppress duplicates because skb_bond is called with the
 skb-dev set to the bond0.555 dev, not the ethX dev.  Non-accelerated
 VLAN devices don't do this; they'll come in with skb-dev set to ethX
 and will go through skb_bond as expected.

Ok, since __vlan_hwaccel_rx() bypasses the netif_receive_skb()
that would normally occur, we have to duplicate the bonding
drop checks.

The submitted patch put skb_bond() into if_vlan.h which is
definitely the wrong thing to do.  This is a generic operation
and therefore belongs in linux/netdevice.h at best.

Furthermore, we're only interested in the packet drop check,
so that's the only part of the logic we need to export,
the rest can stay private to skb_bond() in net/core/dev.c

Can the folks who can reproduce this try this patch?

Thanks.

commit 8a9583e08d0524e3bfe43a51af7c66ca21adf9f3
Author: David S. Miller [EMAIL PROTECTED]
Date:   Mon Aug 14 17:08:36 2006 -0700

[VLAN]: Make sure bonding packet drop checks get done in hwaccel RX path.

Since __vlan_hwaccel_rx() is essentially bypassing the
netif_receive_skb() call that would have occurred if we did the VLAN
decapsulation in software, we are missing the skb_bond() call and the
assosciated checks it does.

Export those checks via an inline function, skb_bond_should_drop(),
and use this in __vlan_hwaccel_rx().

Signed-off-by: David S. Miller [EMAIL PROTECTED]

diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 383627a..ab27408 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -155,6 +155,11 @@ static inline int __vlan_hwaccel_rx(stru
 {
struct net_device_stats *stats;
 
+   if (skb_bond_should_drop(skb)) {
+   dev_kfree_skb_any(skb);
+   return NET_RX_DROP;
+   }
+
skb-dev = grp-vlan_devices[vlan_tag  VLAN_VID_MASK];
if (skb-dev == NULL) {
dev_kfree_skb_any(skb);
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 75f02d8..c0c2b46 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1012,6 +1012,30 @@ static inline int netif_needs_gso(struct
unlikely(skb-ip_summed != CHECKSUM_HW));
 }
 
+/* On bonding slaves other than the currently active slave, suppress
+ * duplicates except for 802.3ad ETH_P_SLOW and alb non-mcast/bcast.
+ */
+static inline int skb_bond_should_drop(struct sk_buff *skb)
+{
+   struct net_device *dev = skb-dev;
+   struct net_device *master = dev-master;
+
+   if (master 
+   (dev-priv_flags  IFF_SLAVE_INACTIVE)) {
+   if (master-priv_flags  IFF_MASTER_ALB) {
+   if (skb-pkt_type != PACKET_BROADCAST 
+   skb-pkt_type != PACKET_MULTICAST)
+   return 0;
+   }
+   if (master-priv_flags  IFF_MASTER_8023AD 
+   skb-protocol == __constant_htons(ETH_P_SLOW))
+   return 0;
+
+   return 1;
+   }
+   return 0;
+}
+
 #endif /* __KERNEL__ */
 
 #endif /* _LINUX_DEV_H */
diff --git a/net/core/dev.c b/net/core/dev.c
index d95e262..9fe96cd 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1619,26 +1619,10 @@ static inline struct net_device *skb_bon
struct net_device *dev = skb-dev;
 
if (dev-master) {
-   /*
-* On bonding slaves other than the currently active
-* slave, suppress duplicates except for 802.3ad
-* ETH_P_SLOW and alb non-mcast/bcast.
-*/
-   if (dev-priv_flags  IFF_SLAVE_INACTIVE) {
-   if (dev-master-priv_flags  IFF_MASTER_ALB) {
-   if (skb-pkt_type != PACKET_BROADCAST 
-   skb-pkt_type != PACKET_MULTICAST)
-   goto keep;
-   }
-
-   if (dev-master-priv_flags  IFF_MASTER_8023AD 
-   skb-protocol == __constant_htons(ETH_P_SLOW))
-   goto keep;
-   
+   if (skb_bond_should_drop(skb)) {
kfree_skb(skb);
return NULL;
}
-keep:
skb-dev = dev-master;
}
 
-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-11 Thread David Miller 
From: Krzysztof Oledzki [EMAIL PROTECTED]
Date: Thu, 10 Aug 2006 20:18:23 +0200 (CEST)

 OK, this patch really solves the bug from my report. Are there any chances 
 for similar fix in the net-2.6.19.git?

I'm still thinking about this patch and what various people have
explained about the situation.
-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-11 Thread David Miller 
From: Christophe Devriese [EMAIL PROTECTED]
Date: Fri, 11 Aug 2006 10:50:44 +0200

 What can I do to get you to apply this then ? This patch is about
 fixing a bug which is bothering me a lot.

You need to be patient while I review the problem.

Nothing you say will allow my brain to operate any faster, sorry to
say.
-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-11 Thread Christophe Devriese 
On Friday 11 August 2006 08:45, David Miller wrote:
 From: Krzysztof Oledzki [EMAIL PROTECTED]
 Date: Thu, 10 Aug 2006 20:18:23 +0200 (CEST)

  OK, this patch really solves the bug from my report. Are there any
  chances for similar fix in the net-2.6.19.git?

 I'm still thinking about this patch and what various people have
 explained about the situation.

What can I do to get you to apply this then ? This patch is about fixing a bug 
which is bothering me a lot.

Regards,

Christophe Devriese
-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-10 Thread Krzysztof Oledzki 



On Thu, 3 Aug 2006, Krzysztof Oledzki wrote:




On Wed, 2 Aug 2006, David Miller wrote:
CUT

Finally, I'm still a little stumped about why this change is necessary
still, to be honest.


If I understand it correctly this patch fixes the [PATCH] bonding: suppress 
duplicate packets patch:


http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8f903c708fcc2b579ebf16542bf6109bad593a1d;hp=ebe19a4ed78d4a11a7e01cdeda25f91b7f2fcb5a

It seems that the original patch does not work properly in vlan accelerated 
environment, which I reported 31 Mar 2006

http://marc.theaimsgroup.com/?l=bonding-develm=114381240718113w=2

Anyway, I didn't test this patch yet but I'm going to di it ASAP.


OK, this patch really solves the bug from my report. Are there any chances 
for similar fix in the net-2.6.19.git?


Best regards,

Krzysztof Olędzki

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-03 Thread Krzysztof Oledzki 



On Wed, 2 Aug 2006, David Miller wrote:
CUT

Finally, I'm still a little stumped about why this change is necessary
still, to be honest.


If I understand it correctly this patch fixes the [PATCH] bonding: 
suppress duplicate packets patch:


http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8f903c708fcc2b579ebf16542bf6109bad593a1d;hp=ebe19a4ed78d4a11a7e01cdeda25f91b7f2fcb5a

It seems that the original patch does not work properly in vlan 
accelerated environment, which I reported 31 Mar 2006

 http://marc.theaimsgroup.com/?l=bonding-develm=114381240718113w=2

Anyway, I didn't test this patch yet but I'm going to di it ASAP.

Best regards,

Krzysztof Olędzki

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-03 Thread Christophe Devriese 
On Wednesday 02 August 2006 22:58, you wrote:
 From: Christophe Devriese [EMAIL PROTECTED]
 Date: Mon, 31 Jul 2006 10:15:40 +0200

 Thanks for the detailed explanation.

  If you bond 2 vlan subinterfaces, the patch is not necessary at all. In
  that case also the source device will be changed from eth0.vlan to
  bondx. So that's correct behavior no ?
 
  In the second case, you create vlan subifs on a bonding device, vlan
  subinterfaces will be created on the slave interfaces. In that case the
  vlan code will reassign the skb-dev node, and because skb_bond needs to
  know the actual input device in order to make an informed drop decision
  before passing this code (skb active-backup mode needs to drop packets
  from the backup slave interface, if you don't do that you get big
  problems with broadcasts).
 
  The same struct vlan_group is assigned to all slave devices and so the
  only vlan subinterfaces that exist in this case are the bondx.vlan
  subinterfaces, and the vlan path for both slaves will assign the
  bondx.vlan interface to skb-dev, thereby erasing the information
  about where the packet came from.

 Assuming it is correct to do the skb_bond() here in the VLAN hwaccel
 RX path, then there is still one piece missing from what I can see.

The problem is that the vlan access path changes the skb-dev pointer around, 
after which it can no longer be determined what the source device was. (It 
defineately is not the parent of the vlan subinterface in the bond case)

 Notice that in the netif_receive_skb() path, the return value from
 skb_bond() is used as the third argument to the deliver_skb() routine
 and friends which in turn gets passed to the packet_type functions.

 Bonding, in particular, makes use of this third argument, see:

 bond_3ad_lacpdu_recv()
 rlb_arp_recv()

 So if the new orig_dev you are computing in the VLAN hwaccel RX path
 is the correct one, somehow this has to propagate down to the third
 argument of the packet type -func() invocations, right?

 Finally, I'm still a little stumped about why this change is necessary
 still, to be honest.  When you configure the bond, the slaves should
 be the VLAN devices as far as I can tell.  Therefore it should be the
 vlan_device-masster that we are interested in not the top-level
 dev-master.

Indeed but vlan_device-master is bond0 instead of eth0 or eth1 (assuming 
you bond eth0 and eth1) so you cannot determine where the packet came from.

 If the ethernet is on a VLAN, and the administrator configures the
 underlying ethernet device as the slaves of the bond, this to me seems
 like a misconfiguration rather than something we should put hacks in
 to support.

In this configuration you have lot's more interfaces to administer and keep 
track of. Besides, what happened to there's more than one way to do it ?. 
If you configure vlan subifs on a bonding device the correct behavior would 
be that the bonding logic is applied _first_ and then after the vlan gets 
considered, no ?

 The fact that you do not propagate the orig_dev returned from
 skb_bond() down to the packet type functions seems to support this.
 From my perspective, this looks like a hack for a bonding
 misconfiguration.

 -
 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
-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-03 Thread Jay Vosburgh 
David Miller [EMAIL PROTECTED] wrote:

 The same struct vlan_group is assigned to all slave devices and so the only 
 vlan subinterfaces that exist in this case are the bondx.vlan 
 subinterfaces, and the vlan path for both slaves will assign the 
 bondx.vlan interface to skb-dev, thereby erasing the information about 
 where the packet came from.

Assuming it is correct to do the skb_bond() here in the VLAN hwaccel
RX path, then there is still one piece missing from what I can see.

I'm not sure it's correct to do everything that skb_bond() does
(I've been away on family business, and I'm a bit rusty coming back to
this), but it is correct to do the should we drop this packet because
it's a duplicate because bonding is involved logic (because the VLAN
acceleration processing is indavertently bypassing that step).

Notice that in the netif_receive_skb() path, the return value from
skb_bond() is used as the third argument to the deliver_skb() routine
and friends which in turn gets passed to the packet_type functions.

Bonding, in particular, makes use of this third argument, see:

bond_3ad_lacpdu_recv()

This function expects the third argument to be the the device
that is actually enslaved to the bond and is acting as the endpoint for
the 802.3ad protocol negotiations.  If it's a VLAN interface under
there, that's what it needs.

rlb_arp_recv()

This function doesn't actually use the third argument that I'm
seeing.

So if the new orig_dev you are computing in the VLAN hwaccel RX path
is the correct one, somehow this has to propagate down to the third
argument of the packet type -func() invocations, right?

Finally, I'm still a little stumped about why this change is necessary
still, to be honest.  When you configure the bond, the slaves should
be the VLAN devices as far as I can tell.  Therefore it should be the
vlan_device-masster that we are interested in not the top-level
dev-master.

If the ethernet is on a VLAN, and the administrator configures the
underlying ethernet device as the slaves of the bond, this to me seems
like a misconfiguration rather than something we should put hacks in
to support.

Not necessarily.  For a configuration with redundant paths
(either multiple ports or multiple switches) or multiple VLANs over the
same physical ports, it's also plausible to configure the vlan
interfaces above bonding, and make the ethernet devices direct slaves of
bonding.  In that configuration, the vlan interfaces are on top,
followed by the bonding device, and the ethernet devices at the bottom.

In this case (bond0.555 above bond0 above eth0,eth1,etc),
skb_bond doesn't suppress duplicates because skb_bond is called with the
skb-dev set to the bond0.555 dev, not the ethX dev.  Non-accelerated
VLAN devices don't do this; they'll come in with skb-dev set to ethX
and will go through skb_bond as expected.

-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

Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-02 Thread Christophe Devriese 
On Tuesday 01 August 2006 19:21, you wrote:
 John W. Linville wrote:
 I'm just not sure that cleverness is worth the headache, especially
 since the most clever things usually only work by accident...
 
 Or, work by solid, modular design and small tweaks!
 
  Point taken.  But stashing little hacks in the networking core for
  specific virtual drivers isn't totally modular either.  And even if
  it were, modular design probably belongs on the list of things
  that can be taken too far, like everything in userland, never
  use ioctl, and microkernels are superior. :-)

 To be honest, I'm not over-joyed to see bridging hooks included
 in the VLAN code..but if that is what it takes to get bridging
 and VLANs to play well and be flexible, I think it is a fair price.

 It certainly wouldn't hurt to have someone take a holistic view of the
 various L2 device interactions.  Just documenting current functionality
 on, say, the netdev wiki would be a good first step.

Ultimate flexibility could be provided by making the netif_rx routine (and the 
others, including vlan etc), a virtual routine.

That way a list of filters could be defined that allow any processing to be 
done on the packet before it is handed of to the linux kernel's higher 
layers, including not delivering it on that interface, or delivering it on 
another interface.

This would allow very complex implementations including stuff like a 
high-level l2 bridge, with vlan support, and a number of protocols like rstp, 
pvst+, ... with relatively simple code, that could be isolated from the main 
kernel.

Would anyone be interested in signing off on such a patch ? (which basically 
creates netif_rx and vlan_acc_netif_rx lists in the net_device structure, and 
then modify bridging and bonding drivers to just use this) 

Regards,

Christophe
-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-02 Thread David Miller 
From: Christophe Devriese [EMAIL PROTECTED]
Date: Mon, 31 Jul 2006 10:15:40 +0200

Thanks for the detailed explanation.

 If you bond 2 vlan subinterfaces, the patch is not necessary at all. In that 
 case also the source device will be changed from eth0.vlan to bondx. So 
 that's correct behavior no ?
 
 In the second case, you create vlan subifs on a bonding device, vlan 
 subinterfaces will be created on the slave interfaces. In that case the vlan 
 code will reassign the skb-dev node, and because skb_bond needs to know the 
 actual input device in order to make an informed drop decision before passing 
 this code (skb active-backup mode needs to drop packets from the backup slave 
 interface, if you don't do that you get big problems with broadcasts). 
 
 The same struct vlan_group is assigned to all slave devices and so the only 
 vlan subinterfaces that exist in this case are the bondx.vlan 
 subinterfaces, and the vlan path for both slaves will assign the 
 bondx.vlan interface to skb-dev, thereby erasing the information about 
 where the packet came from.

Assuming it is correct to do the skb_bond() here in the VLAN hwaccel
RX path, then there is still one piece missing from what I can see.

Notice that in the netif_receive_skb() path, the return value from
skb_bond() is used as the third argument to the deliver_skb() routine
and friends which in turn gets passed to the packet_type functions.

Bonding, in particular, makes use of this third argument, see:

bond_3ad_lacpdu_recv()
rlb_arp_recv()

So if the new orig_dev you are computing in the VLAN hwaccel RX path
is the correct one, somehow this has to propagate down to the third
argument of the packet type -func() invocations, right?

Finally, I'm still a little stumped about why this change is necessary
still, to be honest.  When you configure the bond, the slaves should
be the VLAN devices as far as I can tell.  Therefore it should be the
vlan_device-masster that we are interested in not the top-level
dev-master.

If the ethernet is on a VLAN, and the administrator configures the
underlying ethernet device as the slaves of the bond, this to me seems
like a misconfiguration rather than something we should put hacks in
to support.

The fact that you do not propagate the orig_dev returned from
skb_bond() down to the packet type functions seems to support this.
From my perspective, this looks like a hack for a bonding
misconfiguration.

-
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

Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-01 Thread John W. Linville 
On Mon, Jul 31, 2006 at 09:39:08PM -0400, Jamal Hadi Salim wrote:
 On Mon, 2006-31-07 at 08:30 -0400, John W. Linville wrote:

  Do we hold the view that our L2 code is on par with the rest of
  our code?  Is there an appetite for a clean-up?  Or is it just me?
  
  /rant
  
  If you made it this far, thanks for listening...I feel better now. :-)
 
 Yes, I made it this far and you do make good arguement (or i may be
 over-dosed ;-).
 I have seen the following setups that are useful:
 
 1) Vlans with bridges; in which one or more vlans exist per ethernet
 port. Broadcast packets within such vlans are restricted to just those
 vlans by the bridge.
 2) complicate the above a little by having multiple spanning trees. 
 3) Add to the above link layer HA (802.1ad or otherwise as presented
 today by Bonding).
 
 To answer your question; i think yes we need all 3.

Oh, don't get me wrong -- I definitely think we need all three.

I'm just not sure we need every conceivable combination of a) bonds
of vlan interfaces; b) vlan interfaces on top of bonds; c) bridged
vlan interfaces w/ disparate vlan IDs; d) bonded vlan interfaces w/
disparate vlan IDs; e) bonded bridge interfaces (does this work?) f)
bonded bonds (seen customers trying to do it); g) bridged vlan
interfaces; h) bridged bonds; i) bridged bridges (probably doesn't
work, but someone probably wants it); j) vlan interfaces on top of
bridges; k) vlan interfaces on top of vlans (double vlan tagging);
and, l) what am I leaving out?

Most (actually all afaik) L2 networking equipment enforces some
hierarchy on the relationship between these L2 entities.  I am more
and more convinced we should do the same, although I do acknowledge
that the current situation does allow for some cleverness.

I'm just not sure that cleverness is worth the headache, especially
since the most clever things usually only work by accident...

 Unfortunately the 3 above are all done by different people with
 different intentions altogether. I think BGrears end goal was VLANs for
 an end host. I think Lennert wrote the original Bridge code and for a
 while had some VLAN code that worked well with bridging (that code died
 as far as i know). Then bonding - theres some pre-historic relation to
 it since D Becker days and then the good folks from Intel adding about
 1M features to it. Yes, the fact all 3 need to work together is a
 mess ;- (but there are good pragmatic reasons for them to work
 together)...

I'm sure you are correct -- each entity was developed to serve its
purpose, and each does so admirably on its own.  The fact that they
work together is a desirable miracle.

There is no doubt that we need to be able to do all three (vlan,
bridge, bond) at once.  I'm just not convinced we need to support
stacking them in every conceivable order.  And, I think that a
reconsideration of all three functions as a group could lead to
better/cleaner functionality with easier support for extension (e.g.
802.1s).

Well, I'll guit now before I get sent-off to the visionaries list.
I am putting some thought to this, but I'm not yet far enough along
to sound coherent... :-)

John
-- 
John W. Linville
[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

Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-01 Thread Jamal Hadi Salim 
On Tue, 2006-01-08 at 08:08 -0400, John W. Linville wrote:
[..]
 There is no doubt that we need to be able to do all three (vlan,
 bridge, bond) at once.  I'm just not convinced we need to support
 stacking them in every conceivable order.  

In theory there should be no issues stacking netdevices in any order
you want. In other words the hooks for doing so exist (albeit in some
limited way[1]). Practically, some of the topologies of interconnected
netdevices dont make a lot of sense. The danger is in restricting how
the stacking happens and overlooking some future creative use.
Safer to let the user own the policy and configure any way they want aka
shoot themselves in the foot.

 And, I think that a
 reconsideration of all three functions as a group could lead to
 better/cleaner functionality with easier support for extension (e.g.
 802.1s).

Agreed. I have some very strong opinions on this subject that i could
share with you if you want. For example, IMO, I think it would be a lot
reasonable to assume that a VLAN or VLANS are attributes of a netdevice
(just like IP addresses or MAC addresses are). 

cheers,
jamal

-
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

Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-01 Thread Ben Greear 

Jamal Hadi Salim wrote:

On Tue, 2006-01-08 at 08:08 -0400, John W. Linville wrote:
[..]


There is no doubt that we need to be able to do all three (vlan,
bridge, bond) at once.  I'm just not convinced we need to support
stacking them in every conceivable order.  



In theory there should be no issues stacking netdevices in any order
you want. In other words the hooks for doing so exist (albeit in some
limited way[1]). Practically, some of the topologies of interconnected
netdevices dont make a lot of sense. The danger is in restricting how
the stacking happens and overlooking some future creative use.
Safer to let the user own the policy and configure any way they want aka
shoot themselves in the foot.



And, I think that a
reconsideration of all three functions as a group could lead to
better/cleaner functionality with easier support for extension (e.g.
802.1s).



Agreed. I have some very strong opinions on this subject that i could
share with you if you want. For example, IMO, I think it would be a lot
reasonable to assume that a VLAN or VLANS are attributes of a netdevice
(just like IP addresses or MAC addresses are). 


As might be expected, I feel that VLANs are much more
useful as full-featured net devices.  I do not believe it is worth
decreasing functionality to try to 'clean up' the code.  There are people
doing interesting things with the mentioned virtual devices that the original
developers of the individual parts never envisioned, but I see that only
as a resounding success and validation of the architecture.

It is true that there are some interesting issues about where you add
the hooks to slurp up vlan, bridged, bonded and other type of virtual
device packets.

At least for some of my out-of-the-tree virtual lan devices (mac-vlan, in 
particular),
I thought it would be useful to allow dynamic registration of the layer-2 hooks 
such
as bridging.  This way, where there is no logical way to determine which 
virtual interface
should get first chance at a packet, the user can provide the ordering by 
adjusting
where the hooks sit in the chain.

Last time I mentioned this feature, it was pointed out that the net-filter 
hooks provide,
or come close to providing, this ability to stack.  If someone wants to work on
virtual device priority, it might be worth investigating this further and 
create an
API that makes this usable from kernel and user-space.

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

Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-01 Thread Ben Greear 

John W. Linville wrote:

On Mon, Jul 31, 2006 at 09:39:08PM -0400, Jamal Hadi Salim wrote:


On Mon, 2006-31-07 at 08:30 -0400, John W. Linville wrote:




Do we hold the view that our L2 code is on par with the rest of
our code?  Is there an appetite for a clean-up?  Or is it just me?

/rant

If you made it this far, thanks for listening...I feel better now. :-)


Yes, I made it this far and you do make good arguement (or i may be
over-dosed ;-).
I have seen the following setups that are useful:

1) Vlans with bridges; in which one or more vlans exist per ethernet
port. Broadcast packets within such vlans are restricted to just those
vlans by the bridge.
2) complicate the above a little by having multiple spanning trees. 
3) Add to the above link layer HA (802.1ad or otherwise as presented

today by Bonding).

To answer your question; i think yes we need all 3.



Oh, don't get me wrong -- I definitely think we need all three.

I'm just not sure we need every conceivable combination of a) bonds
of vlan interfaces; b) vlan interfaces on top of bonds; c) bridged
vlan interfaces w/ disparate vlan IDs; d) bonded vlan interfaces w/
disparate vlan IDs; e) bonded bridge interfaces (does this work?) f)
bonded bonds (seen customers trying to do it); g) bridged vlan
interfaces; h) bridged bonds; i) bridged bridges (probably doesn't
work, but someone probably wants it); j) vlan interfaces on top of
bridges; k) vlan interfaces on top of vlans (double vlan tagging);
and, l) what am I leaving out?


Well, if it makes you feel better, I can't see a good way to do
vlans-over-vlans cleanly, backwards compatibly, and functional with
bridging, etc.  I would not plan to add such a feature to the kernel
unless from it's moment of inclusion it could handle at least bridging,
either.  So that feature will probably not see the light of day
any time soon :)


Most (actually all afaik) L2 networking equipment enforces some
hierarchy on the relationship between these L2 entities.  I am more
and more convinced we should do the same, although I do acknowledge
that the current situation does allow for some cleverness.


Very often, the answer to difficult networking issues is to 'get a linux box',
since that very flexibility is often key to interesting problems.


I'm just not sure that cleverness is worth the headache, especially
since the most clever things usually only work by accident...


Or, work by solid, modular design and small tweaks!

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

Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-01 Thread John W. Linville 
On Tue, Aug 01, 2006 at 08:33:34AM -0400, Jamal Hadi Salim wrote:
 On Tue, 2006-01-08 at 08:08 -0400, John W. Linville wrote:

  And, I think that a
  reconsideration of all three functions as a group could lead to
  better/cleaner functionality with easier support for extension (e.g.
  802.1s).
 
 Agreed. I have some very strong opinions on this subject that i could
 share with you if you want. For example, IMO, I think it would be a lot
 reasonable to assume that a VLAN or VLANS are attributes of a netdevice
 (just like IP addresses or MAC addresses are). 

I'd love to hear them.  Feel free to send them off list, since I know
how shy you can be... :-)

John
-- 
John W. Linville
[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

Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-01 Thread John W. Linville 
On Tue, Aug 01, 2006 at 09:10:06AM -0700, Ben Greear wrote:
 Jamal Hadi Salim wrote:

 Agreed. I have some very strong opinions on this subject that i could
 share with you if you want. For example, IMO, I think it would be a lot
 reasonable to assume that a VLAN or VLANS are attributes of a netdevice
 (just like IP addresses or MAC addresses are). 
 
 As might be expected, I feel that VLANs are much more
 useful as full-featured net devices.  I do not believe it is worth
 decreasing functionality to try to 'clean up' the code.

In general, I agree that we shouldn't lose functionality.

I'm curious as to what particularly functionality you fear would be
lost if VLANs were not implemented the way they are now?

Thanks,

John
-- 
John W. Linville
[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

Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-01 Thread Ben Greear 

John W. Linville wrote:

On Tue, Aug 01, 2006 at 09:10:06AM -0700, Ben Greear wrote:


Jamal Hadi Salim wrote:




Agreed. I have some very strong opinions on this subject that i could
share with you if you want. For example, IMO, I think it would be a lot
reasonable to assume that a VLAN or VLANS are attributes of a netdevice
(just like IP addresses or MAC addresses are). 


As might be expected, I feel that VLANs are much more
useful as full-featured net devices.  I do not believe it is worth
decreasing functionality to try to 'clean up' the code.



In general, I agree that we shouldn't lose functionality.

I'm curious as to what particularly functionality you fear would be
lost if VLANs were not implemented the way they are now?


Well, Jamal and I and others discussed this in depth in the 2.4.12 time frame
when VLANs where about to go into the kernel.  Basically, my point is that
if VLANs are true devices, they will just work with all of the user-space 
protocols
and they will easily handle abstractions such as bridges, (multiple) IP 
addresses, MAC addresses,
net-filter, and all the rest.

Sounds like Jamal still remembers his reasons for wanting it otherwise...so
will let him describe his reasons.

Nothing is set in stone in Linux, and I am certainly not the final arbiter of
what gets into the linux kernel, but in my opinion, the current VLAN 
architecture
is supperior to the ip-alias model, and I see no reason to make any significant
changes.

Ben



Thanks,

John



--
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

Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-01 Thread Ben Greear 

John W. Linville wrote:


I'm just not sure that cleverness is worth the headache, especially
since the most clever things usually only work by accident...


Or, work by solid, modular design and small tweaks!



Point taken.  But stashing little hacks in the networking core for
specific virtual drivers isn't totally modular either.  And even if
it were, modular design probably belongs on the list of things
that can be taken too far, like everything in userland, never
use ioctl, and microkernels are superior. :-)


To be honest, I'm not over-joyed to see bridging hooks included
in the VLAN code..but if that is what it takes to get bridging
and VLANs to play well and be flexible, I think it is a fair price.

It certainly wouldn't hurt to have someone take a holistic view of the
various L2 device interactions.  Just documenting current functionality
on, say, the netdev wiki would be a good first step.

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

Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-08-01 Thread Krzysztof Halasa 
Ben Greear [EMAIL PROTECTED] writes:

 Basically, my point is that
 if VLANs are true devices, they will just work with all of the
 user-space protocols
 and they will easily handle abstractions such as bridges, (multiple)
 IP addresses, MAC addresses,
 net-filter, and all the rest.

AOL mode I think the same.
-- 
Krzysztof Halasa
-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-31 Thread Christophe Devriese 
On Monday 31 July 2006 05:50, you wrote:
 From: Ben Greear [EMAIL PROTECTED]
 Date: Fri, 28 Jul 2006 14:55:17 -0700

  The skb_bond method assigns skb-dev when it does the 'keep',
  but the VLAN code immediately over-writes the skb-dev when
  searching for the vlan device.
 
  What is the purpose of assinging skb-dev to the master device?

 This makes me consider this patch highly dubious, at best.

 The whole intention of bonding on input is to make all packets
 incoming on the individual bond slaves to look like they come in via
 the master device.

 Therefore, even when the bond slaves are VLAN devices, in the end the
 skb-dev should be the bond master device _not_ the VLAN device.

 I'm not applying this patch, it doesn't look correct at all.

That code is not introduced by this patch, but is already in the kernel. This 
patch is about having the same behavior for the vlan accelerated input path 
and the normal input path.

If you bond 2 vlan subinterfaces, the patch is not necessary at all. In that 
case also the source device will be changed from eth0.vlan to bondx. So 
that's correct behavior no ?

In the second case, you create vlan subifs on a bonding device, vlan 
subinterfaces will be created on the slave interfaces. In that case the vlan 
code will reassign the skb-dev node, and because skb_bond needs to know the 
actual input device in order to make an informed drop decision before passing 
this code (skb active-backup mode needs to drop packets from the backup slave 
interface, if you don't do that you get big problems with broadcasts). 

The same struct vlan_group is assigned to all slave devices and so the only 
vlan subinterfaces that exist in this case are the bondx.vlan 
subinterfaces, and the vlan path for both slaves will assign the 
bondx.vlan interface to skb-dev, thereby erasing the information about 
where the packet came from.

I have tested the patch, and it works correctly, in both cases on my test 
sytem (where I join vlan subifs on a bonding device into a bridge and have 
xen guests' vifX.Y interfaces connected to those bridges, which is a 
configuration we imho really want to support) (without this patch, as 
explained earlier in this thread, this config does not work)

Regards,

Christophe
-
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

Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-31 Thread John W. Linville 
On Mon, Jul 31, 2006 at 10:15:40AM +0200, Christophe Devriese wrote:

 If you bond 2 vlan subinterfaces, the patch is not necessary at all. In that 
 case also the source device will be changed from eth0.vlan to bondx. So 
 that's correct behavior no ?
 
 In the second case, you create vlan subifs on a bonding device, vlan 
 subinterfaces will be created on the slave interfaces. In that case the vlan 

(This is not directed at Christophe, or anyone in particular...)

rant

Am I the only one that thinks that our handling of LAN L2 stuff
is at best a little too flexible (and at worst a collection of
nasty hacks)?

I mean, do we really need both the ability to bond multiple vlan
interfaces AND the ability to have vlan interfaces on top of a bond?
How many people really appreciate the subtle(?) differences?

Then throw bridging into the mix!  If I'm using VLANs and bonds in
a bridged environment, do I bridge the bonds, or bond the bridges?
Do the VLANs come before the bonds?  after the bridges?  or somewhere
in-between?  Do all these combinations even work together?  Who has
the definitive answer (besides the code itself)?

I have no doubt that there are plenty of opportunities for cleverness
here (and no doubt dragons too).  I just doubt that most of them
are worth the complexities introduced by our current collection of
transparently stackable pseudo-drivers and strategically placed hacks
(e.g. skb_bond).  All that, and it still isn't clear to me how we
can cleanly accomodate 802.1s (which adds VLAN awareness to bridging).

Do we hold the view that our L2 code is on par with the rest of
our code?  Is there an appetite for a clean-up?  Or is it just me?

/rant

If you made it this far, thanks for listening...I feel better now. :-)

John
-- 
John W. Linville
[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

Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-31 Thread Christophe Devriese 
On Monday 31 July 2006 14:30, you wrote:
 (This is not directed at Christophe, or anyone in particular...)

 rant

 Am I the only one that thinks that our handling of LAN L2 stuff
 is at best a little too flexible (and at worst a collection of
 nasty hacks)?

 I mean, do we really need both the ability to bond multiple vlan
 interfaces AND the ability to have vlan interfaces on top of a bond?
 How many people really appreciate the subtle(?) differences?

 Then throw bridging into the mix!  If I'm using VLANs and bonds in
 a bridged environment, do I bridge the bonds, or bond the bridges?

In all honesty, you cannot bond bridges :-p

 Do the VLANs come before the bonds?  after the bridges?  or somewhere
 in-between?  Do all these combinations even work together?  Who has
 the definitive answer (besides the code itself)?

 I have no doubt that there are plenty of opportunities for cleverness
 here (and no doubt dragons too).  I just doubt that most of them
 are worth the complexities introduced by our current collection of
 transparently stackable pseudo-drivers and strategically placed hacks
 (e.g. skb_bond).  All that, and it still isn't clear to me how we
 can cleanly accomodate 802.1s (which adds VLAN awareness to bridging).

 Do we hold the view that our L2 code is on par with the rest of
 our code?  Is there an appetite for a clean-up?  Or is it just me?

A vlan capable bridge with trunk ports and access ports would be nice :-p

I think the current code is nice. You need it to properly support 
virtualization and I find it very useful where I work to have this option.

Regards,

Christophe
-
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

Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-31 Thread Jamal Hadi Salim 
On Mon, 2006-31-07 at 08:30 -0400, John W. Linville wrote:
 On Mon, Jul 31, 2006 at 10:15:40AM +0200, Christophe Devriese wrote:
 
  If you bond 2 vlan subinterfaces, the patch is not necessary at all. In 
  that 
  case also the source device will be changed from eth0.vlan to bondx. So 
  that's correct behavior no ?
  
  In the second case, you create vlan subifs on a bonding device, vlan 
  subinterfaces will be created on the slave interfaces. In that case the 
  vlan 
 
 (This is not directed at Christophe, or anyone in particular...)
 
 rant
 
 Am I the only one that thinks that our handling of LAN L2 stuff
 is at best a little too flexible (and at worst a collection of
 nasty hacks)?
 
 I mean, do we really need both the ability to bond multiple vlan
 interfaces AND the ability to have vlan interfaces on top of a bond?
 How many people really appreciate the subtle(?) differences?
 
 Then throw bridging into the mix!  If I'm using VLANs and bonds in
 a bridged environment, do I bridge the bonds, or bond the bridges?
 Do the VLANs come before the bonds?  after the bridges?  or somewhere
 in-between?  Do all these combinations even work together?  Who has
 the definitive answer (besides the code itself)?
 
 I have no doubt that there are plenty of opportunities for cleverness
 here (and no doubt dragons too).  I just doubt that most of them
 are worth the complexities introduced by our current collection of
 transparently stackable pseudo-drivers and strategically placed hacks
 (e.g. skb_bond).  All that, and it still isn't clear to me how we
 can cleanly accomodate 802.1s (which adds VLAN awareness to bridging).
 
 Do we hold the view that our L2 code is on par with the rest of
 our code?  Is there an appetite for a clean-up?  Or is it just me?
 
 /rant
 
 If you made it this far, thanks for listening...I feel better now. :-)

Yes, I made it this far and you do make good arguement (or i may be
over-dosed ;-).
I have seen the following setups that are useful:

1) Vlans with bridges; in which one or more vlans exist per ethernet
port. Broadcast packets within such vlans are restricted to just those
vlans by the bridge.
2) complicate the above a little by having multiple spanning trees. 
3) Add to the above link layer HA (802.1ad or otherwise as presented
today by Bonding).

To answer your question; i think yes we need all 3.
Unfortunately the 3 above are all done by different people with
different intentions altogether. I think BGrears end goal was VLANs for
an end host. I think Lennert wrote the original Bridge code and for a
while had some VLAN code that worked well with bridging (that code died
as far as i know). Then bonding - theres some pre-historic relation to
it since D Becker days and then the good folks from Intel adding about
1M features to it. Yes, the fact all 3 need to work together is a
mess ;- (but there are good pragmatic reasons for them to work
together)...
Hope that helps ;-

cheers,
jamal


-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-30 Thread David Miller 
From: Ben Greear [EMAIL PROTECTED]
Date: Fri, 28 Jul 2006 14:55:17 -0700

 The skb_bond method assigns skb-dev when it does the 'keep',
 but the VLAN code immediately over-writes the skb-dev when
 searching for the vlan device.
 
 What is the purpose of assinging skb-dev to the master device?

This makes me consider this patch highly dubious, at best.

The whole intention of bonding on input is to make all packets
incoming on the individual bond slaves to look like they come in via
the master device.

Therefore, even when the bond slaves are VLAN devices, in the end the
skb-dev should be the bond master device _not_ the VLAN device.

I'm not applying this patch, it doesn't look correct at all.
-
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

PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-28 Thread Christophe Devriese 
diff -rU3 linux-2.6.17.7/net/core/dev.c linux-2.6.17.7-wapper/net/core/dev.c
--- linux-2.6.17.7/net/core/dev.c   2006-07-25 05:36:01.0 +0200
+++ linux-2.6.17.7-wapper/net/core/dev.c2006-07-27 20:16:36.0 
+0200
@@ -88,6 +88,7 @@
 #include linux/sockios.h
 #include linux/errno.h
 #include linux/interrupt.h
+#include linux/if_bonding.h
 #include linux/if_ether.h
 #include linux/netdevice.h
 #include linux/etherdevice.h
@@ -1518,37 +1519,6 @@

 EXPORT_SYMBOL(netif_rx_ni);

-static inline struct net_device *skb_bond(struct sk_buff *skb)
-{
-   struct net_device *dev = skb-dev;
-
-   if (dev-master) {
-   /*
-* On bonding slaves other than the currently active
-* slave, suppress duplicates except for 802.3ad
-* ETH_P_SLOW and alb non-mcast/bcast.
-*/
-   if (dev-priv_flags  IFF_SLAVE_INACTIVE) {
-   if (dev-master-priv_flags  IFF_MASTER_ALB) {
-   if (skb-pkt_type != PACKET_BROADCAST 
-   skb-pkt_type != PACKET_MULTICAST)
-   goto keep;
-   }
-
-   if (dev-master-priv_flags  IFF_MASTER_8023AD 
-   skb-protocol == __constant_htons(ETH_P_SLOW))
-   goto keep;
-
-   kfree_skb(skb);
-   return NULL;
-   }
-keep:
-   skb-dev = dev-master;
-   }
-
-   return dev;
-}
-
 static void net_tx_action(struct softirq_action *h)
 {
struct softnet_data *sd = __get_cpu_var(softnet_data);

-- 
---
Christophe Devriese   EURiD
Network Adminstrator / Developer
[EMAIL PROTECTED]
 http://www.eth1.org --

-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-28 Thread Ben Greear 

This patch by itself does nothing useful, other than remove a method.

If we assume you did the patch backwards, and wanted to add the method
instead, then where is this method ever called?

Ben


Christophe Devriese wrote:

diff -rU3 linux-2.6.17.7/net/core/dev.c linux-2.6.17.7-wapper/net/core/dev.c
--- linux-2.6.17.7/net/core/dev.c   2006-07-25 05:36:01.0 +0200
+++ linux-2.6.17.7-wapper/net/core/dev.c2006-07-27 20:16:36.0 
+0200
@@ -88,6 +88,7 @@
 #include linux/sockios.h
 #include linux/errno.h
 #include linux/interrupt.h
+#include linux/if_bonding.h
 #include linux/if_ether.h
 #include linux/netdevice.h
 #include linux/etherdevice.h
@@ -1518,37 +1519,6 @@

 EXPORT_SYMBOL(netif_rx_ni);

-static inline struct net_device *skb_bond(struct sk_buff *skb)
-{
-   struct net_device *dev = skb-dev;
-
-   if (dev-master) {
-   /*
-* On bonding slaves other than the currently active
-* slave, suppress duplicates except for 802.3ad
-* ETH_P_SLOW and alb non-mcast/bcast.
-*/
-   if (dev-priv_flags  IFF_SLAVE_INACTIVE) {
-   if (dev-master-priv_flags  IFF_MASTER_ALB) {
-   if (skb-pkt_type != PACKET_BROADCAST 
-   skb-pkt_type != PACKET_MULTICAST)
-   goto keep;
-   }
-
-   if (dev-master-priv_flags  IFF_MASTER_8023AD 
-   skb-protocol == __constant_htons(ETH_P_SLOW))
-   goto keep;
-
-   kfree_skb(skb);
-   return NULL;
-   }
-keep:
-   skb-dev = dev-master;
-   }
-
-   return dev;
-}
-
 static void net_tx_action(struct softirq_action *h)
 {
struct softnet_data *sd = __get_cpu_var(softnet_data);




--
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-28 Thread Christophe Devriese 
I basically move the skb_bond method into if_bonding.h, include that file
in if_vlan ( and call it from the vlan forwarding path, and the netif_rx
routine ). 

Somehow this patch is very incomplete. Let me try again.

sorry for the trouble. (I'm new at this)

Regards,

Christophe 

 Christophe Devriese wrote:
 diff -rU3 linux-2.6.17.7/net/core/dev.c 
 linux-2.6.17.7-wapper/net/core/dev.c
 --- linux-2.6.17.7/net/core/dev.c   2006-07-25 05:36:01.0 +0200
 +++ linux-2.6.17.7-wapper/net/core/dev.c2006-07-27 
 20:16:36.0 +0200
 @@ -88,6 +88,7 @@
  #include linux/sockios.h
  #include linux/errno.h
  #include linux/interrupt.h
 +#include linux/if_bonding.h
  #include linux/if_ether.h
  #include linux/netdevice.h
  #include linux/etherdevice.h
 @@ -1518,37 +1519,6 @@
 
  EXPORT_SYMBOL(netif_rx_ni);
 
 -static inline struct net_device *skb_bond(struct sk_buff *skb)
 -{
 -   struct net_device *dev = skb-dev;
 -
 -   if (dev-master) {
 -   /*
 -* On bonding slaves other than the currently active
 -* slave, suppress duplicates except for 802.3ad
 -* ETH_P_SLOW and alb non-mcast/bcast.
 -*/
 -   if (dev-priv_flags  IFF_SLAVE_INACTIVE) {
 -   if (dev-master-priv_flags  IFF_MASTER_ALB) {
 -   if (skb-pkt_type != PACKET_BROADCAST 
 -   skb-pkt_type != PACKET_MULTICAST)
 -   goto keep;
 -   }
 -
 -   if (dev-master-priv_flags  IFF_MASTER_8023AD 
 -   skb-protocol == __constant_htons(ETH_P_SLOW))
 -   goto keep;
 -
 -   kfree_skb(skb);
 -   return NULL;
 -   }
 -keep:
 -   skb-dev = dev-master;
 -   }
 -
 -   return dev;
 -}
 -
  static void net_tx_action(struct softirq_action *h)
  {
 struct softnet_data *sd = __get_cpu_var(softnet_data);
 
 
 
 -- 
 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

-- 
---
Christophe Devriese   EURiD
Network Adminstrator / Developer
[EMAIL PROTECTED]
 http://www.eth1.org --

diff -rU3 linux-2.6.17.7/include/linux/if_bonding.h 
linux-2.6.17.7-wapper/include/linux/if_bonding.h
--- linux-2.6.17.7/include/linux/if_bonding.h   2006-07-25 05:36:01.0 
+0200
+++ linux-2.6.17.7-wapper/include/linux/if_bonding.h2006-07-27 
21:17:25.0 +0200
@@ -46,6 +46,7 @@
 #include linux/if.h
 #include linux/types.h
 #include linux/if_ether.h
+#include linux/netdevice.h
 
 /* userland - kernel ABI version (2003/05/08) */
 #define BOND_ABI_VERSION 2
@@ -110,6 +111,37 @@
__u8 partner_system[ETH_ALEN];
 };
 
+static inline struct net_device *skb_bond(struct sk_buff *skb)
+{
+   struct net_device *dev = skb-dev;
+
+   if (dev-master) {
+   /*
+* On bonding slaves other than the currently active
+* slave, suppress duplicates except for 802.3ad
+* ETH_P_SLOW and alb non-mcast/bcast.
+*/
+   if (dev-priv_flags  IFF_SLAVE_INACTIVE) {
+   if (dev-master-priv_flags  IFF_MASTER_ALB) {
+   if (skb-pkt_type != PACKET_BROADCAST 
+   skb-pkt_type != PACKET_MULTICAST)
+   goto keep;
+   }
+
+   if (dev-master-priv_flags  IFF_MASTER_8023AD 
+   skb-protocol == __constant_htons(ETH_P_SLOW))
+   goto keep;
+   
+   kfree_skb(skb);
+   return NULL;
+   }
+keep:
+   skb-dev = dev-master;
+   }
+
+   return dev;
+}
+
 #endif /* _LINUX_IF_BONDING_H */
 
 /*
diff -rU3 linux-2.6.17.7/include/linux/if_vlan.h 
linux-2.6.17.7-wapper/include/linux/if_vlan.h
--- linux-2.6.17.7/include/linux/if_vlan.h  2006-07-25 05:36:01.0 
+0200
+++ linux-2.6.17.7-wapper/include/linux/if_vlan.h   2006-07-27 
20:16:36.0 +0200
@@ -24,6 +24,7 @@
 struct hlist_node;
 
 #include linux/proc_fs.h /* for proc_dir_entry */
+#include linux/if_bonding.h /* for skb_bond */
 #include linux/netdevice.h
 
 #define VLAN_HLEN  4   /* The additional bytes (on top of the 
Ethernet header)
@@ -154,6 +155,12 @@
unsigned short vlan_tag, int polling)
 {
struct net_device_stats *stats;
+   struct net_device

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-28 Thread Ben Greear 

Christophe Devriese wrote:

I basically move the skb_bond method into if_bonding.h, include that file
in if_vlan ( and call it from the vlan forwarding path, and the netif_rx
routine ). 


Somehow this patch is very incomplete. Let me try again.


The patch looks sane this time.

The skb_bond method assigns skb-dev when it does the 'keep',
but the VLAN code immediately over-writes the skb-dev when
searching for the vlan device.

What is the purpose of assinging skb-dev to the master device?

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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-28 Thread Christophe Devriese 
On Fri, Jul 28, 2006 at 02:55:17PM -0700, Ben Greear wrote:
 Christophe Devriese wrote:
 I basically move the skb_bond method into if_bonding.h, include that file
 in if_vlan ( and call it from the vlan forwarding path, and the netif_rx
 routine ). 
 
 Somehow this patch is very incomplete. Let me try again.
 
 The patch looks sane this time.
 
 The skb_bond method assigns skb-dev when it does the 'keep',
 but the VLAN code immediately over-writes the skb-dev when
 searching for the vlan device.
 
 What is the purpose of assinging skb-dev to the master device?

I don't know. The method was only moved by this patch, not changed. The
contents of the method are exactly what they are in
linux-2.6.17.7/net/core/dev.c 

I assume it has something to do with the other bonding methods.

-- 
---
Christophe Devriese   EURiD
Network Adminstrator / Developer
[EMAIL PROTECTED]
 http://www.eth1.org --
-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-28 Thread Christophe Devriese 
On Fri, Jul 28, 2006 at 03:08:49PM -0700, Ben Greear wrote:
 Christophe Devriese wrote:
 On Fri, Jul 28, 2006 at 02:55:17PM -0700, Ben Greear wrote:
 
 Christophe Devriese wrote:
 
 I basically move the skb_bond method into if_bonding.h, include that file
 in if_vlan ( and call it from the vlan forwarding path, and the netif_rx
 routine ). 
 
 Somehow this patch is very incomplete. Let me try again.
 
 The patch looks sane this time.
 
 The skb_bond method assigns skb-dev when it does the 'keep',
 but the VLAN code immediately over-writes the skb-dev when
 searching for the vlan device.
 
 What is the purpose of assinging skb-dev to the master device?
 
 
 I don't know. The method was only moved by this patch, not changed. The
 contents of the method are exactly what they are in
 linux-2.6.17.7/net/core/dev.c 
 
 I assume it has something to do with the other bonding methods.
 
 Ok, I don't know much about the bonding logic.  Looks OK to me.

Will you sign-off on it then ? Or how do I get this applied ?

-- 
---
Christophe Devriese   EURiD
Network Adminstrator / Developer
[EMAIL PROTECTED]
 http://www.eth1.org --

-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-28 Thread David Miller 
From: Christophe Devriese [EMAIL PROTECTED]
Date: Sat, 29 Jul 2006 00:58:59 +0200

 On Fri, Jul 28, 2006 at 03:08:49PM -0700, Ben Greear wrote:
  Christophe Devriese wrote:
  On Fri, Jul 28, 2006 at 02:55:17PM -0700, Ben Greear wrote:
  
  Christophe Devriese wrote:
  
  I basically move the skb_bond method into if_bonding.h, include that file
  in if_vlan ( and call it from the vlan forwarding path, and the netif_rx
  routine ). 
  
  Somehow this patch is very incomplete. Let me try again.
  
  The patch looks sane this time.
  
  The skb_bond method assigns skb-dev when it does the 'keep',
  but the VLAN code immediately over-writes the skb-dev when
  searching for the vlan device.
  
  What is the purpose of assinging skb-dev to the master device?
  
  
  I don't know. The method was only moved by this patch, not changed. The
  contents of the method are exactly what they are in
  linux-2.6.17.7/net/core/dev.c 
  
  I assume it has something to do with the other bonding methods.
  
  Ok, I don't know much about the bonding logic.  Looks OK to me.
 
 Will you sign-off on it then ? Or how do I get this applied ?

I'll apply this over the weekend unless I spot some problem
with it, thanks.

A sign off from Ben would be nice too :)
-
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

Re: PATCH Fix bonding active-backup behavior for VLAN interfaces

2006-07-28 Thread Ben Greear 

David Miller wrote:

From: Christophe Devriese [EMAIL PROTECTED]
Date: Sat, 29 Jul 2006 00:58:59 +0200



On Fri, Jul 28, 2006 at 03:08:49PM -0700, Ben Greear wrote:


Christophe Devriese wrote:


On Fri, Jul 28, 2006 at 02:55:17PM -0700, Ben Greear wrote:



Christophe Devriese wrote:



I basically move the skb_bond method into if_bonding.h, include that file
in if_vlan ( and call it from the vlan forwarding path, and the netif_rx
routine ). 


Somehow this patch is very incomplete. Let me try again.


The patch looks sane this time.

The skb_bond method assigns skb-dev when it does the 'keep',
but the VLAN code immediately over-writes the skb-dev when
searching for the vlan device.

What is the purpose of assinging skb-dev to the master device?



I don't know. The method was only moved by this patch, not changed. The
contents of the method are exactly what they are in
linux-2.6.17.7/net/core/dev.c 


I assume it has something to do with the other bonding methods.


Ok, I don't know much about the bonding logic.  Looks OK to me.


Will you sign-off on it then ? Or how do I get this applied ?



I'll apply this over the weekend unless I spot some problem
with it, thanks.

A sign off from Ben would be nice too :)


I don't see any problems with the patch.  The skb-dev
assignment is redundant for the VLAN path, but may be useful
elsewhere.  At any rate, it doesn't seem like it would hurt
anything.

Signed-off-by Ben Greear [EMAIL PROTECTED]


--
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