[dat-discussions] [openib-general] [RFC] DAT 2.0 immediate dataproposal

[Davis, Arlin R]

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:Arkady.Kanevsky at netapp.com]
>Sent: Monday, February 06, 2006 8:08 AM
>To: Sean Hefty; Davis, Arlin R
>Cc: dat-discussions at yahoogroups.com; openib-general at openib.org
>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: arkady at netapp.com
>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:mshefty at ichips.intel.com]
>> Sent: Friday, February 03, 2006 7:30 PM
>> To: Davis, Arlin R
>> Cc: dat-discussions at yahoogroups.com; openib-general at openib.org
>> 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
>> openib-general at openib.org
>> http://openib.org/mailman/listinfo/openib-general
>>
>> To unsubscribe, please visit
>> http://openib.org/mailman/listinfo/openib-general
>>