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

[Kanevsky, Arkady]

Arlin,
On Friday we agreed that receiver can not distinguish
between 4 byte of Send or 4 bytes of Immediate data
if RDMA Write with Immed is implemented as 2 operations:
RDMA Write followed by Send.

ULP Reciever "expects" Immediate data that is why it posts
Recv. Depending on Transport capability it MAY complete
as Recv or as Recv_RDMA_Write_with_Immed_in_event.

Neither Provider not Consumer can distinguish between the cases
unless there is additional info.

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: Davis, Arlin R [mailto:arlin.r.davis at intel.com] 
> Sent: Monday, February 06, 2006 1:25 PM
> To: Kanevsky, Arkady; Sean Hefty
> Cc: dat-discussions at yahoogroups.com; openib-general at openib.org
> Subject: RE: [dat-discussions] [openib-general] [RFC] DAT 2.0 
> immediate dataproposal
> 
> 
> 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
> >>
>