[dat-discussions] [openib-general] [RFC] DAT 2.0immediatedataproposal

[Kanevsky, Arkady]

But each of the multiple work requests follow the semantic of single
completion per work request. It can be controlled by completion_flags
but it still not a semantic of a "single" post.

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:sean.hefty at intel.com] 
> Sent: Tuesday, February 07, 2006 10:39 AM
> To: 'Caitlin Bestler'; Kanevsky, Arkady; Larsen, Roy K; 
> dat-discussions at yahoogroups.com; Sean Hefty
> Cc: openib-general at openib.org
> Subject: RE: [dat-discussions] [openib-general] [RFC] DAT 
> 2.0immediatedataproposal
> 
> >	And further it is only on the receiving side.
> >	And only if the receiving side cares about the data
> >		(sometimes it only needs the notification).
> 
> The send size cares about this check because it must size its 
> SQ appropriately.
> I disagree with the assumption that a "transport neutral" API 
> is inherently easier for the application developer.
> 
> >The attempt is to define a composite work request that can 
> reduce the 
> >number of actual work requests required for some providers, without 
> >requiring different work flows dependent on whether the "immediate" 
> >feature was present.
> 
> This is exactly what Roy was pointing out.  This is no longer 
> defining a write with immediate data, but instead addressing 
> some other requirement.  In this case, you can define a 
> generic send side API that takes multiple work requests as 
> input, since a provider may be able to reduce the actual 
> number of work requests in this case as well.
> 
> - Sean
>