> Quoting Moni Shoua <[EMAIL PROTECTED]>: > Subject: Re: infiniband bonding/merging/aggregation with SDP and/or?VERBS > > Michael S. Tsirkin wrote: > >> Quoting Moni Shoua <[EMAIL PROTECTED]>: > >> 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 _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
