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-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-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: Stackable devices.

2006-08-09 Thread Christophe Devriese 
It would however be considerable effort to do this. Is this going to end up 
unapplied like my last patch, or ?

Regards,

Christophe

On Tuesday 08 August 2006 18:36, you wrote:
 Christophe Devriese wrote:
  On Wed, Aug 02, 2006 at 10:50:08AM -0700, Ben Greear wrote:
 Currently, the bridge hook logic is something like:
 
 if (bridge-consumed-pkt) {
 return
 }
 
 // drop through to other layers
 
 
 There are several other hooks I'd like to see added (pktgen receive
 processing,
 mac-vlans, etc).  Each of these hooks are logically similar to the bridge
 hook,
 ie if it consumes the pkt, return, else, drop through to the next hook
 untill
 we get to the regular protocol processing logic.
 
 I would like to be able to chain layer-2 handlers, such as bridge,
  mac-vlan, pktgen such that if one consumed, you break out of the
  handling, else, you try the next handler.  The handlers can be
  dynamically registered and inserted
 in any order, controllable by user-space and/or module load/unload.
 
 For many of the handlers, the logic will re-insert the packet by
  re-calling the
 netif-rx logic, so there would need to be some protection to keep loops
  from occurring that would recurse too much and overflow the stack.
 
  I'm also a big fan of a generalized system like this. It would need to
  catch both the vlan accelerated path and the normal path.

 Well, it isn't actually needed for VLANs since VLAN's hook is a protocol
 handler

 Ben
-
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: Stackable devices.

2006-08-08 Thread Christophe Devriese 
On Wed, Aug 02, 2006 at 10:50:08AM -0700, Ben Greear wrote:
 Currently, the bridge hook logic is something like:
 
 if (bridge-consumed-pkt) {
   return
 }
 
 // drop through to other layers
 
 
 There are several other hooks I'd like to see added (pktgen receive 
 processing,
 mac-vlans, etc).  Each of these hooks are logically similar to the bridge 
 hook,
 ie if it consumes the pkt, return, else, drop through to the next hook 
 untill
 we get to the regular protocol processing logic.
 
 I would like to be able to chain layer-2 handlers, such as bridge, mac-vlan,
 pktgen such that if one consumed, you break out of the handling, else, you
 try the next handler.  The handlers can be dynamically registered and 
 inserted
 in any order, controllable by user-space and/or module load/unload.
 
 For many of the handlers, the logic will re-insert the packet by re-calling 
 the
 netif-rx logic, so there would need to be some protection to keep loops from
 occurring that would recurse too much and overflow the stack.

I'm also a big fan of a generalized system like this. It would need to
catch both the vlan accelerated path and the normal path.

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

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

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 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 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: Who maintains the website ?

2006-07-26 Thread Christophe Devriese 
I would like to have a VLAN page on the main page, so that I can update it
a bit with relevant info, and then include the link to the external site
as it's basically a here is a patch, here is a usage page, while an
explanation of the different stuff would be nice (such as the forwarding
path, the vlan acceleration, where packets go ...).

On Wed, Jul 26, 2006 at 08:41:58AM +1200, Ian McDonald wrote:
 On 7/26/06, Christophe Devriese [EMAIL PROTECTED] wrote:
 The http://linux-net.osdl.org/index.php/Main_Page website I mean.
 
 It's a Wiki so anybody can alter content on the website. The exception
 to this is that particular page - the main page. If you want something
 altered on that particular page send email to one of the sysops.
 -- 
 Ian McDonald
 Web: http://wand.net.nz/~iam4
 Blog: http://imcdnzl.blogspot.com
 WAND Network Research Group
 Department of Computer Science
 University of Waikato
 New Zealand
 -
 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 --

-
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: Who maintains the website ?

2006-07-26 Thread Christophe Devriese 
I have created the http://linux-net.osdl.org/index.php/VLAN page. What do
you think ?

Regards,

Christophe

On Wed, Jul 26, 2006 at 08:52:52PM +1200, Ian McDonald wrote:
 On 7/26/06, Christophe Devriese [EMAIL PROTECTED] wrote:
 I would like to have a VLAN page on the main page, so that I can update it
 a bit with relevant info, and then include the link to the external site
 as it's basically a here is a patch, here is a usage page, while an
 explanation of the different stuff would be nice (such as the forwarding
 path, the vlan acceleration, where packets go ...).
 
 What is the external page? If it doesn't exist consider putting the
 content on the wiki itself so others can improve it.
 
 Prepare the Wiki page including linking in the existing VLAN link on
 the front page and then we can see what can be done. You can create a
 VLAN page without having to change the wiki front page initially...
 
 If it looks good then Stephen, or myself or others can change the front 
 page.
 -- 
 Ian McDonald
 Web: http://wand.net.nz/~iam4
 Blog: http://imcdnzl.blogspot.com
 WAND Network Research Group
 Department of Computer Science
 University of Waikato
 New Zealand
 -
 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 --

-
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

Bonding active-backup issue.

2006-07-26 Thread Christophe Devriese 
If I implement a patch taking an unused flag and implementing IFF_SILENT,
in order to fix incorrect bonding active-backup behavior, will it get
accepted ?

If not, what can I do ?

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

Who maintains the website ?

2006-07-25 Thread Christophe Devriese 
The http://linux-net.osdl.org/index.php/Main_Page website I mean.

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