Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>> 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?
The bonding driver has a kernel listener attached to a packet
type that will be delivered by the ptype_base[] loop in
netif_receive_skb.
>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.
It's part of the regular 802.3 standard, which is free.
Anyway, 802.3ad uses a standard link multicast address, and I
see that br_handle_frame() should check that and pass the packet on for
further processing by the ptype_base[] loop.
Unless ... the bridge is in disabled state. I'm not sure right
off what would cause that (the check in port_carrier_check(), perhaps?).
There may be, as you say, a catch-22 since the bonding driver must
exchange the control frames in order to establish the aggregation.
The carrier state of the slaves is not affected by the control
frame exchange, only the bonding master's carrier state is dependent
upon the 802.3ad aggregation. That is a very recent change.
-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
