We need a better job coordinating between 2 reflectors.
One issue is that someone must subscribe to the dat-discussion list to post to
it.
- Sean
___
openib-general mailing list
openib-general@openib.org
On Wed, 2006-02-08 at 23:20 -0800, Sean Hefty wrote:
Hmm. Can you put a number on how much better RDMA write with
immediate is on current HCA hardware? How does using the underlying
OpenIB verbs ability to post a list of work requests compare (ie
posting an RDMA write followed by a send in
But why define an IB specific feature when a transport neutral feature
can be defined?
Viewing the operation as Write with following Send maintains transport
neutral semantics AND allows IB to encode it as a Write with Immediate.
That avoids IB to use the silicon that already exists to support
Roland Dreier wrote:
Hmm. Can you put a number on how much better RDMA write with
immediate is on current HCA hardware? How does using the underlying
OpenIB verbs ability to post a list of work requests compare (ie
posting an RDMA write followed by a send in one verbs call)?
Maybe post
[EMAIL PROTECTED] wrote:
Roland Dreier wrote:
Hmm. Can you put a number on how much better RDMA write with
immediate is on current HCA hardware? How does using the underlying
OpenIB verbs ability to post a list of work requests compare (ie
posting an RDMA write followed by a send in one
At 03:36 PM 2/8/2006, Arlin Davis wrote:
Roland Dreier wrote:
Michael So,
here we have a long discussion on attempting to
Michael perpetuate a concept that is not universal
across
Michael transports and was deemed to have minimal value
that most
Michael wanted to see removed from the
Hmm. Can you put a number on how much better RDMA write with
immediate is on current HCA hardware? How does using the underlying
OpenIB verbs ability to post a list of work requests compare (ie
posting an RDMA write followed by a send in one verbs call)?
Maybe post multiple is a better
central phone: 781-768-5300
-Original Message-
From: Caitlin Bestler [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 07, 2006 3:03 PM
To: Larsen, Roy K; [EMAIL PROTECTED]; Arlin
Davis; Hefty, Sean
Cc: openib-general@openib.org
Subject: RE: [dat-discussions] [openib-general
: [EMAIL PROTECTED]; openib-general@openib.org
Subject: RE: [dat-discussions] [openib-general] [RFC]
DAT2.0immediatedataproposal
[EMAIL PROTECTED] wrote:
Roland Dreier wrote:
Hmm. Can you put a number on how much better RDMA write with
immediate is on current HCA hardware? How does
[EMAIL PROTECTED] wrote:
Hmm. Can you put a number on how much better RDMA write with
immediate is on current HCA hardware? How does using the
underlying OpenIB verbs ability to post a list of work requests
compare (ie posting an RDMA write followed by a send in one verbs
call)? Maybe post
[EMAIL PROTECTED] wrote:
Caitlin,
can you clarify this.
Are you proposing that Consumer encode a bit of Immediate
Data to specify that it is immediate data?
iWARP will pass it in Send message and IB in Immediate Data.
If we agreed that there was some accute need for this 33rd
bit coming
D] Sent: Thursday, February 09, 2006 3:25
PMTo: Arlin DavisCc: [EMAIL PROTECTED];
openib-general@openib.orgSubject: Re: [dat-discussions]
[openib-general][RFC] DAT2.0immediatedataproposal
At 03:36 PM 2/8/2006, Arlin Davis wrote:
Roland Dreier wrote:
Michael So,
]
Sent: Thursday, February 09, 2006 3:32 PM
To: [EMAIL PROTECTED]; Arlin Davis; Roland Dreier
Cc: openib-general@openib.org
Subject: RE: [dat-discussions] [openib-general]
[RFC]DAT2.0immediatedataproposal
Hmm. Can you put a number on how much better RDMA write with
immediate
All we're asking is that a write/send combined API not be
called immediate data unless it fits the semantics of
immediate data. I am puzzled at the resistance this is
getting. There is a standards body specification for
immediate data. If it is not followed, don't call it
immediate data.
Larsen, Roy K wrote:
Even on iWARP transports small send data can be in-lined, avoiding
the need for buffers to be registered. A special API where the
length of the send buffer is known in advance makes this even
easier.
Ah, I wasn't aware iWARP could carry inline data. I take it
Roy,
and if tomorrow iWARP decides to support Immediate data with variable
length. API does not changes. Semantic does not changes and IB
will not be able to support it.
I am trying to define the semantic and API which will not have to be
modified for each rev of the transport.
Arkady,
Simply
Michael Krause wrote:
RDMA Write with Immediate is part of the IB Extended Transport
Header. It is a fixed-sized quantity and not one subject to change,
i.e. increasing its size.
Your argument above reinforces that the particular application need is
IB-specific and thus should not be part
-
From: Arlin Davis [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 09, 2006 5:57 PM
To: Michael Krause
Cc: [EMAIL PROTECTED];
openib-general@openib.org; Kanevsky, Arkady
Subject: Re: [dat-discussions] [openib-general] [RFC]
DAT2.0immediatedataproposal
Michael Krause wrote:
RDMA
]; Larsen, Roy K; Arlin
Davis; Hefty, Sean
Cc: openib-general@openib.org
Subject: RE: [dat-discussions] [openib-general] [RFC]
DAT2.0immediatedataproposal
[EMAIL PROTECTED] wrote:
We have problem no matter which option we choose.
The current Transport Level Requirement state
[EMAIL PROTECTED] wrote:
One more issue to discuss.
Does Completion of Recv that matches RDMA Write with
Immediate Data automatically sync local memory or Consumer
still need to do lmr_sync_rdma_write prior to accessing RDMAed data.
Why would it be any different than for a plain receive?
At 09:16 PM 2/6/2006, Sean Hefty wrote:
The requirement is to
provide an API that supports RDMA writes with immediate
data. A send that follows an RDMA write is not immediate data,
and the API
should not be constructed around trying to make it so.
To be clear, I believe that write with immediate
Michael So, here we have a long discussion on attempting to
Michael perpetuate a concept that is not universal across
Michael transports and was deemed to have minimal value that most
Michael wanted to see removed from the architecture.
But this discussion is being driven by an
Roland Dreier wrote:
Michael So, here we have a long discussion on attempting to
Michael perpetuate a concept that is not universal across
Michael transports and was deemed to have minimal value that most
Michael wanted to see removed from the architecture.
But this discussion is
Arlin A very latency sensitive application that requires
Arlin immediate notification of RDMA write completion on the
Arlin remote node without ANY latency penalties associated with
Arlin combining operations, HCA priority rules across QPs, wire
Arlin congestion, etc. An
One thing to keep in mind is that the IBTA workgroup
responsible for the transport wanted to eliminate immediate data support
entirely but it was retained solely to enable VIA application migration (even
though the application base was quite small). If that requirement could
have been
[EMAIL PROTECTED] wrote:
Arlin A very latency sensitive application that requires
Arlin immediate notification of RDMA write completion on the
Arlin remote node without ANY latency penalties associated with
Arlin combining operations, HCA priority rules across QPs, wire
Hmm. Can you put a number on how much better RDMA write with
immediate is on current HCA hardware? How does using the underlying
OpenIB verbs ability to post a list of work requests compare (ie
posting an RDMA write followed by a send in one verbs call)?
Maybe post multiple is a better direction
Sean Hefty wrote:
The requirement is to provide an API that supports RDMA writes with immediate
data. A send that follows an RDMA write is not immediate data, and the API
should not be constructed around trying to make it so.
To be clear, I believe that write with immediate should be
Arlin Davis wrote:
Sean Hefty wrote:
The requirement is to provide an API that supports RDMA writes with
immediate data. A send that follows an RDMA write is not immediate
data, and the API should not be constructed around trying to make
it so.
To be clear, I believe that write
Caitlin Bestler wrote:
Arlin Davis wrote:
Sean Hefty wrote:
The requirement is to provide an API that supports RDMA writes with
immediate data. A send that follows an RDMA write is not immediate
data, and the API should not be constructed around trying to make
it so.
To be clear, I
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 07, 2006 2:46 PM
To: [EMAIL PROTECTED]; Arlin Davis; Hefty, Sean
Cc: Kanevsky, Arkady; Sean Hefty; openib-general@openib.org
Subject: RE: [dat-discussions] [openib-general] [RFC]
DAT2.0immediatedataproposal
Caitlin Bestler wrote:
Arlin
[EMAIL PROTECTED] wrote:
Caitlin Bestler wrote:
Arlin Davis wrote:
Sean Hefty wrote:
The requirement is to provide an API that supports RDMA writes
with immediate data. A send that follows an RDMA write is not
immediate data, and the API should not be constructed around
trying to make
IB does optionally support send_with_invalidate as defined in IBTA 1.2
spec.
OpenIB does not support this yet but this is a different matter.
So this is bad analogy.
The better analogy is socket based CM.
But I am still not clear what you are advocating:
extensions, IB specific API or something
What is proposed in a definition of
'dat_ep_post_rdma_write_with_immediate'
that can be implemented over iWARP using the sequence of messages
that were intended to support the same purpose (i.e., letting the
other side know that an RDMA Write transfer has been fully
received).
No, iWARP
Larsen, Roy K wrote:
Completing a transaction, complete with supplying a transaction
response and releasing the advertised STag associated with the
transaction is something that makes sense in the application domain
and conforms to normal DAT ordering rules.
I don't disagree. And
Completing a transaction, complete with supplying a transaction
response and releasing the advertised STag associated with the
transaction is something that makes sense in the application domain
and conforms to normal DAT ordering rules.
I don't disagree. And unambiguous immediate data
Message-
From: Caitlin Bestler [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 07, 2006 6:57 PM
To: Larsen, Roy K; [EMAIL PROTECTED]; Arlin
Davis; Hefty, Sean
Cc: openib-general@openib.org
Subject: RE: [dat-discussions] [openib-general] [RFC]
DAT2.0immediatedataproposal
[EMAIL
37 matches
Mail list logo
