> So instead of ib_sa_mcmember_rec_set which returned the query by pointer we
> now
> have ib_sa_join_multicast which returns the pointer. This part looks OK I
> guess, but
> I still do not understand why does the patch tinker with logic (e.g.
> setting/clearing IPOIB_MCAST_FLAG_BUSY) in the IPoIB code.
The use of the flag is still there. The difference in the APIs is that the
multicast API requires exactly 1 call to leave the group after the call to
join.
The ib_multicast interface is simple. A user calls ib_join_multicast,
followed by ib_free_multicast. What issues do you see with this interface?
> *All* the new API was supposed to do is add reference counting on top of
> join/leave queries. So why the need to rework the logic? Is it possible that
> what is missing is the analog of ib_sa_cancel_query - a non-blocking call
> which
> would guarantee that join callback is invoked soon? If yes, I think we should
> just add that to the new API.
Focus on the ib_multicast code first. Then look at the ipoib changes. The
ib_multicast code does add reference counting on top of the existing ib_sa
APIs.
Join increments the reference count. Free decrements it. The
"ib_sa_cancel_query" call that you're wanting is ib_free_multicast.
> Sean, it seems like you are trying to push some unrelated re-factoring in the
> IPoIB
> code, which might be fine, but should be done separately from the update to
> the new API - could be before, or after the multicast change.
There should not be any unrelated changes to the ipoib code. The changes are a
result of using the new ib_multicast API and its restrictions.
- Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
