>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,
Si
>> 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
>> immed
>>> 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"
>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 su
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 elim
>>> 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
>>> 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).
>
>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 so
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.
>
>From: Kanevsky, Arkady [mailto:[EMAIL PROTECTED]
>Sent: Monday, February 06, 2006 2:27 PM
>
>Roy,
>comments inline.
>
Mine too
>>
>> >From: Kanevsky, Arkady [mailto:[EMAIL PROTECTED]
>> >Roy,
>> >Can you explain, please?
>> >
>> >For IB the operation will be layered properly on Transport
p
>From: Kanevsky, Arkady [mailto:[EMAIL PROTECTED]
>Roy,
>Can you explain, please?
>
>For IB the operation will be layered properly on Transport primitive.
>And on Recv side it will indicate in completion event DTO
>that it matches RDMA Write with Immediate and that Immediate Data
>is in event.
>
If it is up to the ULP to separate out "normal" receive data from that
associated with a write immediate, how is this different from the ULP
doing a write followed by a send? If there is no difference, then what
we're really talking about is a convenience to the initiating ULP.
Perhaps what would
12 matches
Mail list logo
