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: [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, January 24, 2006 7:17 PM > To: Kanevsky, Arkady > Cc: Arlin Davis; Caitlin Bestler; Lentini, James; > [EMAIL PROTECTED]; openib-general@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 > _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general