[openib-general] [PATCH 1/7 v2] for 2.6.20 ib/ib_sa: add tracking of multicast join / leave requests
Sean Hefty
mshefty at ichips.intel.com
Mon Nov 6 10:02:29 PST 2006
> 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
More information about the general
mailing list