On Mon, Jun 06, 2005 at 12:15:53PM -0700, Caitlin Bestler wrote:
> As your reply indicates below, the OS does *not*
> know *when* the device is active.
The driver doesn't have to and in fact does not for other technologies
either. The device driver knows (or can know) who registered
the region sin
On 6/6/05, Grant Grundler <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 04, 2005 at 04:33:12PM -0700, Caitlin Bestler wrote:
> ...
> > The Quadrics patch informed zero copy devices
> > of new mappings, but does so when the device
> > is not actively doing work. That latter piece of
> > information is no
On Sat, Jun 04, 2005 at 04:33:12PM -0700, Caitlin Bestler wrote:
...
> The Quadrics patch informed zero copy devices
> of new mappings, but does so when the device
> is not actively doing work. That latter piece of
> information is not available for an RDMA device.
It certainly is.
Anyway, I agre
Caitlin Bestler wrote:
On 6/4/05, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
The Quadrics patch informed zero copy devices
of new mappings, but does so when the device
is not actively doing work. That latter piece of
information is not available for an RDMA device.
For normal devices the OS
On 6/4/05, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > That is
> > why the Quadrics extensions for zero placement are not
> > applicable to an RDMA device. That extension, for example,
> > only remaps memory when the IO device is not actively
> > doing a transfer. Something that the kernel
On Fri, Jun 03, 2005 at 11:58:50AM -0700, Caitlin Bestler wrote:
> Since you haven't bothered to learn much about RDMA, let me
> explain that unlike typical devices an RDMA device can be
> pefrforming IO even when the OS is not aware of it.
We have similar issues with spurious dma transfers and i
On 6/3/05, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > The next question is to define what if any handshake is desired.
> > My guess that the consumer would acknowledge this by closing
> > the RNIC, and that there would be some sort of deadline for doing
> > so (much like a shutdown, you h
On Fri, Jun 03, 2005 at 09:13:25AM -0700, Caitlin Bestler wrote:
> Customers are using insmod to load DAPL Providers today, and
> then using the registry to find them. That applies to both IB and
> iWARP providers. The need for the registry reduces with each
> step, but it doesn't instantly vanish
On Fri, Jun 03, 2005 at 04:38:15AM -0700, Caitlin Bestler wrote:
> OpenRDMA discussed with the DAT Collaborative the idea
> of subsuming the responsibilities of the DAT Registry, so that
> the OpenRDMA directory could take the 'dat_xxx' calls
> directly. When the device dependent logic used a dynam
On Fri, Jun 03, 2005 at 04:30:51AM -0700, Caitlin Bestler wrote:
> The appropriate plafce to add that would be as an unafilliated asynchronous
> event reported via the async evd.
No. The async evds are a horrible API that should go away not beeing
added to.
> The next question is to define what
On 6/3/05, Bob Woodruff <[EMAIL PROTECTED]> wrote:
> Catlin Wrote,
> >That approach is certainly applicable for OpenIB as well.
> >The key is recognizing the need for a transition plan.
> >Customers have DAT Providers installed now, they
> >cannot synchronize getting new DAT Providers from
> >their
Catlin Wrote,
>That approach is certainly applicable for OpenIB as well.
>The key is recognizing the need for a transition plan.
>Customers have DAT Providers installed now, they
>cannot synchronize getting new DAT Providers from
>their suppliers with a new Linux release. This is
>especially true s
On 6/3/05, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > Keep in mind that loading/unloading DAT Provider is *not*
> > synonymous with loading/unloading drivers. In fact I believe
> > the intent is to have a single provider that supports multiple
> > devices. Such a provider would simply reg
The appropriate plafce to add that would be as an unafilliated asynchronous
event reported via the async evd.
The next question is to define what if any handshake is desired.
My guess that the consumer would acknowledge this by closing
the RNIC, and that there would be some sort of deadline for do
On Thu, Jun 02, 2005 at 09:56:51AM -0700, Caitlin Bestler wrote:
> Why is it that you believe that the DAT registry does not support
> plug and play? The interface was most specifically designed
> to allow that.
DAT is based on a enumerate and request instead of a callback-based
client interface.
7 PM
> To: Itamar Rabenstein
> Cc: Christoph Hellwig; Tom Duffy; openib-general@openib.org
> Subject: Re: [openib-general] [PATCH] kDAPL: cleanup dat/ a bit more
>
>
> Why is it that you believe that the DAT registry does not support
> plug and play? The interface was most specifi
y
> > Cc: openib-general@openib.org
> > Subject: Re: [openib-general] [PATCH] kDAPL: cleanup dat/ a bit more
> >
> >
> > On Wed, Jun 01, 2005 at 11:23:44AM -0700, Tom Duffy wrote:
> > > This patch cleans up dat/ a bit, removing unneeded parenthesis,
> > &
On Wed, 1 Jun 2005, Christoph Hellwig wrote:
hch> On Wed, Jun 01, 2005 at 11:23:44AM -0700, Tom Duffy wrote:
hch> > This patch cleans up dat/ a bit, removing unneeded parenthesis,
hch> > gratuitous comments, and a few whitespace cleanups. Please apply.
hch>
hch> btw, I think most of the code u
register_provider , unregister_provider
Itamar
> -Original Message-
> From: Christoph Hellwig [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 01, 2005 9:36 PM
> To: Tom Duffy
> Cc: openib-general@openib.org
> Subject: Re: [openib-general] [PATCH] kDAPL: cleanup dat/ a b
On Wed, Jun 01, 2005 at 11:23:44AM -0700, Tom Duffy wrote:
> This patch cleans up dat/ a bit, removing unneeded parenthesis,
> gratuitous comments, and a few whitespace cleanups. Please apply.
btw, I think most of the code under dat/ should just go away ASAP.
Just have a simple linked list of pro
20 matches
Mail list logo
