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: [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: Tuesday, February 07, 2006 10:39 AM > To: 'Caitlin Bestler'; Kanevsky, Arkady; Larsen, Roy K; > [EMAIL PROTECTED]; Sean Hefty > Cc: [email protected] > 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 > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
