Arkady,
Your requirements are slightly different then the proposed set of
requirements.
"iii) DAPL Provider does not provide any identification that that the
Receive operation matches remote RDMA Write with Immediate data if it
completes as Receive DTO.
- It is up to an ULP to separate Receive completion of remote
Send from remote RDMA Write with Immediate Data."
Tell me how this is possible? How can the application distinguish
between a 4 byte message and a 4 byte immediate data message? We would
have to add a new requirement... "If the provider supports immediate
data in the payload the ULP cannot send a message equal to the immediate
data size".
-arlin
>-----Original Message-----
>From: Kanevsky, Arkady [mailto:[EMAIL PROTECTED]
>Sent: Monday, February 06, 2006 8:08 AM
>To: Sean Hefty; Davis, Arlin R
>Cc: [EMAIL PROTECTED]; [email protected]
>Subject: RE: [dat-discussions] [openib-general] [RFC] DAT 2.0 immediate
dataproposal
>
>Here are the changes to the existing requirements chapters
>for RDMA Write with Immediate Data.
>
>Feedback please.
>Arkady
>
>Arkady Kanevsky email: [EMAIL PROTECTED]
>Network Appliance Inc. phone: 781-768-5395
>1601 Trapelo Rd. - Suite 16. Fax: 781-895-1195
>Waltham, MA 02451 central phone: 781-768-5300
>
>
>> -----Original Message-----
>> From: Sean Hefty [mailto:[EMAIL PROTECTED]
>> Sent: Friday, February 03, 2006 7:30 PM
>> To: Davis, Arlin R
>> Cc: [EMAIL PROTECTED]; [email protected]
>> Subject: Re: [dat-discussions] [openib-general] [RFC] DAT 2.0
>> immediate dataproposal
>>
>> Davis, Arlin R wrote:
>> > "Applications need an optimized mechanism to notify the
>> receiving end
>> > that RDMA write data has completed beyond the two operation method
>> > currently used (RDMA write followed by message send). This new RDMA
>> > write feature will support 4-bytes of inline data that will be sent
>>
>> Is there any reason to restrict the size of the immediate
>> data? Could you define the API such that the size is
>> variable? I.e. the provider can simply give the immediate
>> data size, with 0 indicating that it is not supported.
>>
>> > It should avoid
>> > any latency penalties normally associated with a two
>> operation method.
>>
>> I would state this as a requirement. A write followed by a
>> send should be pushed to the application, since they may be
>> able to provide additional optimizations (such as combining
>> operations) beyond what a provider could.
>>
>> > The initiating side must expose a 4-byte immediate data
>> parameter for
>> > the application to set the inline data. The receiving side must
>> > provide a mechanism to accept the 4-byte immediate data. On the
>> > receiving side, the write with immediate completion notification is
>> > indicated through a receive completion. It is the responsibility of
>> > the provider to identify to the application 4-byte
>> immediate data from
>> > a normal 4-byte send message. The inline byte ordering is
>> application specific."
>>
>> Requirements look good to me.
>>
>> - Sean
>> _______________________________________________
>> openib-general mailing list
>> [email protected]
>> http://openib.org/mailman/listinfo/openib-general
>>
>> To unsubscribe, please visit
>> http://openib.org/mailman/listinfo/openib-general
>>
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
