[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