Caitlin Bestler wrote: > >Arlin Davis wrote: >> Sean Hefty wrote: >> >>>> The requirement is to provide an API that supports RDMA writes with >>>> immediate data. A send that follows an RDMA write is not immediate >>>> data, and the API should not be constructed around trying to make >>>> it so. >>>> >>>> >>> >>> To be clear, I believe that write with immediate should be part of >>> the normal APIs, rather than an extension, but should be designed >>> around those devices that provide it natively. >>> >>> >> I totally agree. A standard RDMA write with immediate API can >> be very useful to RDMA applications based on the requirements >> (native support) set forth in my earlier email. It is analogous to >> the new dat_ep_post_send_with_invalidate() call; a call that supports >> a native iWARP transport operation but provides no provisions >> to help other transports emulate. So, other transports simply >> return NOT_SUPPORTED and add it natively in the future if it makes >> sense. >> >> -arlin > >What is proposed in a definition of >'dat_ep_post_rdma_write_with_immediate' >that can be implemented over iWARP using the sequence of messages that >were intended to support the same purpose (i.e., letting the other >side know that an RDMA Write transfer has been fully received).
No, iWARP *CAN NOT* implement write immediate data any better than IB can implement send with invalidate. Immediate data *MUST* be indicated to the ULP unambiguously. Imposing an algorithm on the application to infer immediate data arrival is hack, pure and simple. An application is free to perform a write/send if that is the semantic they want. Why does iWARP get transport unique APIs but not IB? I find this attempt to bastardize the IB semantic of immediate data a little curious. Roy _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
