[openib-general] RE: [RFC] DAT 2.0 immediate data proposal

[Kanevsky, Arkady]

Sean,
Immediate data can be handled in Transport independent way.
API for it certainly is. I am more concern that different vendors
will come up with their own extensions for the same features.

The size of immediate data is no big deal.
The reall issue is that App will need to be changes to handle
more data. So DAT can just increase the size of the immed_data field
in event and in posted buffer. NO API functionality change just API
header change
and recompile of app.

But these kind of changes will face the same problem whether it is part
of DAT
or part of the DAT extension.

Let talk more about it on the DAT call tomorrow.
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: Tuesday, January 24, 2006 7:17 PM
> To: Kanevsky, Arkady
> Cc: Arlin Davis; Caitlin Bestler; Lentini, James; 
> dat-discussions at yahoogroups.com; openib-general at openib.org; 
> Davis, Arlin R
> Subject: Re: [openib-general] RE: [RFC] DAT 2.0 immediate 
> data proposal
> 
> Kanevsky, Arkady wrote:
> > But this penalizes user which need to deal with 2 way to deal with 
> > post calls and completions.
> 
> Yes, any app that wants to take advantage of transport 
> specific features, which immediate data is, is no longer 
> transport neutral.
> 
> How do you plan to handle the next RDMA transport that comes 
> along with 64-bytes of immediate data?
> 
> - Sean
>