On Sat, Feb 27, 2010 at 11:38:37AM +0100, Jiri Pirko wrote: > >The problem this statement is trying to solve had to do with bonding > >creating multicast addresess for ethernet rather than infiniband in > >some cases. This happens because bonding makes a device that switches > >from ethernet to infiniband during its lifetime. I'm not quite > >sure what kind of life cycle those addresses go through, but if they > >somehow stay on the mc_list then ipoib_mcast_addr_is_valid will still > >need to have the check.
> Ok I see your point now. But in this case, the length check should be in all > drivers because if for example bonding device changes from infiniband back to > eth, the addresses stored would be "cut" to 6 bytes and would make no sense. Ideally, but the other wrinkle is due to other problems in the ipoib driver one bad multicast address blocks further addresses from being processed - effectively rendering the interface useless for multicast. Ethernet drivers will just subscribe to a bogus address, no real harm done. I would prefer to see the check remain in ipoib until we can see through testing that it is no longer triggering. > 2) when bonding changes it's type, flush mc addresses and start over. > > Second option looks nicer to me, but I might be missing something, thouths? There was a patch posted that tried to do something like what you are describing: From: Moni Shoua <[email protected]> Subject: Re: [PATCH RESEND] bonding: remap muticast addresses without using dev_close() and dev_open() Thanks, Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
