[ofw] patch: [ibbus] Add A new function to IBAL that allows one to create a multicast group without attaching a QP to it.

Tzachi Dar tzachid at mellanox.co.il
Thu Feb 10 13:31:21 PST 2011


Just to make sure:

ib_join_mcast(struct ib_mcast_req *req, ib_mcast_handle_t *h_mcast);
the h_mcast is actually an out parameter?

Thanks
Tzachi


> -----Original Message-----
> From: Hefty, Sean [mailto:sean.hefty at intel.com]
> Sent: Thursday, February 10, 2011 11:26 PM
> To: Tzachi Dar; ofw at lists.openfabrics.org
> Subject: RE: [ofw] patch: [ibbus] Add A new function to IBAL that allows one
> to create a multicast group without attaching a QP to it.
> 
> > I guess that if we want to keep tracking the multicast group (as fab has
> > noticed) than we don't have a way to not change the API.
> 
> Personally, I'm fine requiring the caller to handle the cleanup (provided the
> kernel cleans up after user space).
> 
> The main issue I see with the existing APIs is that the user has no way to
> cancel a join request without blowing up everything.  So, I would vote for
> replacing the existing kernel APIs with something like:
> 
> ib_join_mcast(struct ib_mcast_req *req, ib_mcast_handle_t *h_mcast);
> ib_free_mcast(ib_mcast_handle_t h_mcast, ib_pfn_destroy_cb_t pfn_destroy_cb);
> 
> 'leave' is replaced with 'free, which must always be called.  Eventually, I
> would like these APIs available separately from the rest of ibal, so that
> winverbs can use them without being forced to use the other ibal APIs.  If the
> API is being modified, there's no reason to keep the existing calls.  Users
> should just be moved to the new APIs.
> 
> - Sean



More information about the ofw mailing list