[ofa-general] bonding & ipoib patches to support bonding of ipoib devices (was: re [NET]: Fix neighbour destructor handling)

[Or Gerlitz]

Michael S. Tsirkin wrote:
>> I did followed most of the discussions between you and MoniS re the 
>> ipoib/bonding integration in OFED 1.2 and elsewhere, however: i don't 
>> see why "bonding is basically broken for ipoib", if you don't mind, 
>> please tell me the bottom line from your perspective.
> 
> Here's a short summary of issues I saw last time, I'm not sure
> I haven't forgot something but here goes:
> 
> 1.Calling to_ipoib_neigh without device lock taken might be racy
>   I think you need to find another way to find the device.
> 2.Ah kept in the ipoib_neigh might belong to a device which is different
>   from the one start_xmit is called at.
> 3.When the slave device goes down, master does not, and since
>   neighbours are matched to the master there's no guarantee they will be
>   cleaned up.
> 4.Bonding module copies a pointer to the cleanup function in a manner
>   that is unsafe if ipoib is built as a module.
> 
> I think these need to be addressed somehow before the patch's reposted.

Michael, Roland,

Following the high-availability/bonding session at Sonoma, I'd like to 
have a BOF to discuss the issues which from your perspective should be 
addressed before the patch set is merged upstream. Will you be around?

Now, for 1,3,4 above i am quite confident to understand what Michael is 
saying, on what we agree and on what not...

I just need a clarification on (2), can you educate me how can it 
happen? looking on the code (eg the below chains) my understanding is 
that address handles and struct ipoib_neigh are allocated 1:1

Or.

> ipoib_neigh_alloc <-- neigh_add_path   <-- ipoib_path_lookup <-- ipoib_start_xmit
> ipoib_neigh_alloc <-- ipoib_mcast_send <-- ipoib_path_lookup <-- ipoib_start_xmit
> ipoib_neigh_alloc <-- ipoib_mcast_send <-- ipoib_start_xmit

> ipoib_create_ah <-- ipoib_mcast_join_finish
> ipoib_create_ah <-- path_rec_completion