On Mon, 10 Apr 2006 22:57:45 +0300
Vlad Drukker <[EMAIL PROTECTED]> wrote:

> On Mon, 2006-04-10 at 11:06 -0700, Stephen Hemminger wrote:
> > On Mon, 10 Apr 2006 19:28:39 +0200
> > Ingo Oeser <[EMAIL PROTECTED]> wrote:
> > 
> > > Hi Vlad,
> > > 
> > > Vlad Drukker wrote:
> > > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > > index 434220d..a351687 100644
> > > > --- a/net/core/dev.c
> > > > +++ b/net/core/dev.c
> > > > @@ -1614,6 +1614,8 @@ static __inline__ int handle_bridge(stru
> > > >         struct net_bridge_port *port;
> > > >  
> > > >         if ((*pskb)->pkt_type == PACKET_LOOPBACK ||
> > > > +           ((*pskb)->dev->priv_flags & IFF_MASTER_8023AD && 
> > > > +           (*pskb)->protocol == __constant_htons(ETH_P_SLOW)) ||
> > > >             (port = rcu_dereference((*pskb)->dev->br_port)) == NULL)
> > > >                 return 0;
> > > >  
> > > 
> > > Please use "htons(ETH_P_SLOW)", since the compiler will constant fold 
> > > this 
> > > and it is more readable this way.
> > > 
> > 
> > I still don't think it is correct to special case bonding this way.
> > The only way bonding frames would ever arrive at handle_bridge is
> > in the case of a bridge being added to a bonded device.
> nope. there _is_ other way when bonding frame (slow protcol multicast)
> arrive at handle_bridge when bond is part of bridge (as in your picture
> below). and that's exactly the problem.
> 
> > Bridge's should not be part of a bonded interface. Either the bonded device
> > should be added to the bridge:
> > 
> >             | br0
> >        +----------+
> >        |  bridge  |
> >        +----------+
> >             | bond0
> >        +----------+
> >        |  bonding |
> >            +----------+
> >          |eth0  | eth1
> > 
> > In this case bonding driver should already the multicasts before passing up 
> > to
> > bridge.
> bonding driver cannot get mulicast before bridge, 
> because it has registered protocol handler in ptype_base[]
> consider the flow:
> netif_receive_skb() { // occures on eth0 at your picture
> ...
> skb_bond() // changes dev to dev->master 
> ...
> handle_bridge() // bridge got the frame
> ...
> deliver_skb() // ETH_P_SLOW bonding handler from ptype_base[]
> ...
> }
> notice that: netif_receive_skb() executes handle_bridge before protocol
> hadlers in ptype_base[]
>  
> the alternative is to deliver_skb() (protocol handlers) in ptype_base[]
> before handle_bridge, which is also a bad idea ...
> 
> > 
> > Or for failover both eth0 and eth1 should be added to bridge (no bonding).
> > 

Okay, I understand it now. But this should only happen if the device has no
carrier present (ie disabled). Otherwise the bridge will forward the frame up.
Is there a catch-22 problem? Do the bonding code need to see the frame, 
to bring the pseudo-carrier up?

I don't have that IEEE std, and am not paying money for it. But if it uses
a link multicast, then the frame will be normally received.
-
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

Reply via email to