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:[email protected]] > Sent: Thursday, February 10, 2011 11:26 PM > To: Tzachi Dar; [email protected] > 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 _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
