[openib-general] Re: RDMA Generic Connection Management
Steve Wise
swise at ammasso.com
Tue Aug 30 12:01:29 PDT 2005
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:Thomas.Talpey at netapp.com]
> Sent: Tuesday, August 30, 2005 1:59 PM
> To: Roland Dreier
> Cc: Steve Wise; openib-general at 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.
>
More information about the general
mailing list