[ofa-general] Re: infiniband bonding/merging/aggregation with SDP and/or VERBS

[Michael S. Tsirkin]

> Quoting Moni Shoua <monisonlists at gmail.com>:
> Subject: Re: infiniband bonding/merging/aggregation with SDP and/or?VERBS
> 
> Michael S. Tsirkin wrote:
> >> Quoting Moni Shoua <monisonlists at gmail.com>:
> >> Subject: Re: infiniband bonding/merging/aggregation with SDP and/or?VERBS
> >>
> >> Tziporet Koren wrote:
> >>> Moni Shoua wrote:
> >>>> ib-bonding is based on standard Linux bonding with some required
> >>>> changes to make it work with IPoIB.
> >>> What is the status of accepting the specific IB changes to Linux kernel?
> >> I've sent a new patch yesterday with a comment about module unload being 
> >> unsafe under specific scenarios.
> >> Michael's opinion is that we should fix this issue first but I think that
> >> there is a place to push the current patch now and wait for the other fix to
> >> come later (which is probably not in IB or at least not just IB).
> > 
> > I don't think this summarizes my opinion correctly.
> > I just would like to see all the patches together - I have a feeling caching the
> > device in ipoib->dev is problematic and module unloading issues are just a
> > symptom pointing to deeper issues.
> > 
> I'll try to summarize the concept of bonding and IPoiB soon but in the
> meantime I just want to make sure that I understand you.  You're saying that
> caching the device in ipoib->dev is problematic. What do you mean by that?

I am merely speaking about caching the device pointer inside struct ipoib_neigh.
I have a feeling this addresses a symptom and not the root cause.

> This is how bonding works (even for Ethernet). It takes a pointer of dev and
> remembers it for its operation.

That's fine, but maybe bonding can be fixed to have neighbour->dev and skb->dev
match, and if they don't, destroy the neighbour and create a new one.

-- 
MST