[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]

After some more thinking, I have some more questions:

1) On ib_join_mcast( ...,  ib_mcast_handle_t *h_mcast); the h_mcast gets back to the user from the call back.
I guess that there is no problem to return the h_mcast in the call itself but are we sure this has a good reason?

2) " Personally, I'm fine requiring the caller to handle the cleanup (provided the kernel cleans up after user space)."
Doesn't this has an influence on the API which would actually force us to  have something else in the API (for example h_al) or something similar.

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