It looks like the kDAPL provider doesn't free up any resources in its remove functions.
See dapl_remove_port() and dapl_provider_free()... I cant find where it cleans up any allocated QPs, CQ, etc... > -----Original Message----- > From: Talpey, Thomas [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 30, 2005 1:59 PM > To: Roland Dreier > Cc: Steve Wise; openib-general@openib.org > Subject: Re: [openib-general] Re: RDMA Generic Connection Management > > kDAPL does this! > > :-) > > > At 02:35 PM 8/30/2005, Roland Dreier wrote: > > Thomas> Well, you're saying somebody has to do it, right? Is it > > Thomas> easier to fob this off to upper layers that (frankly) > > Thomas> don't care what hardware they're talking to!? This means > > Thomas> we have N copies of this, and N ways to do it. Talk about > > Thomas> cacheline pingpong. > > > >Upper layers have the luxury of being able to do this at a > >per-connection level, can sleep, etc. If we push it down into the > >verbs, then we have to do it in every verbs call, including the fast > >path verbs call. And that means we get into all sorts of crazy code > >to deal with a device disappearing between a consumer calling > >ib_post_send() and the core code being entered, etc. > > > >Right now we have a very simple set of rules: > > > > An upper level protocol consumer may begin using an IB device as > > soon as the add method of its struct ib_client is called for that > > device. A consumer must finish all cleanup and free all resources > > relating to a device before returning from the remove method. > > > > A consumer is permitted to sleep in its add and remove methods. > > > > - R. > _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
