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 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 agree
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 not available
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
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
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 does not
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.
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
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 since
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 suppliers
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 if
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 and
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 have so
register_client , unregister_client 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
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 specifically designed
to allow that.
When
This patch cleans up dat/ a bit, removing unneeded parenthesis,
gratuitous comments, and a few whitespace cleanups. Please apply.
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
api.c| 684 ++-
core.c | 24 --
dictionary.c |
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
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 bit more
On Wed, Jun
18 matches
Mail list logo
