Sean Hefty wrote: >> 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
Yes such an interface is more general. It would be something along the lines of dat_ep_post_exchnage() which would post the SGLs for zero or more RDMA Writes and a single RDMA Send. It would be matched on the other end by a single receive. Would that be easy for IB vendors to optimize? It's pretty much the same for an iWARP provider. _______________________________________________ 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