>But why define an IB specific feature when a transport neutral feature >can be defined? > >Viewing the operation as Write with following Send maintains transport >neutral semantics AND allows IB to encode it as a Write with Immediate. > >That avoids IB to use the silicon that already exists to support >compressing >the Write and Send into a single message. That is the real benefit, isn't >it?
No, it's not.... >And for both transports it enables the Provider to pass the 4 byte >immediate >data by value rather than by registered reference. So there is a definite >benefit >to IB, and a potential benefit to IP, and it works for both transports. > >The *only* thing gained by making it a transport specific method is >the implicit 33rd bit in the "that RDMA Write payload you asked for >has arrived" message. > Ok, finally. A realization that the semantics of write/send are not the same as IB write with immediate data. And the difference is important. The proposed emulation could not pass a black box test since nothing distinguishes an "immediate" receive message from standard one containing rkeys or any other random data an application my need to exchange through send/receive. A true write with immediate data can pass such a black box test because it offers a unique service whereas the proposed emulation does not. It is a "helper" function that uses existing services. I have no objection to a write/send helper function, just call it that and not write with immediate data. Leave the true immediate data service as an extension as first proposed. >Is there a concrete example of any benefit from encoding a 33rd bit in >the selection of Write with Immediate versus Write followed by 32-bit Send? Yes, as stated several times, applications that use the send/receive facility to exchange information such as rkeys as well as using write immediate services must be able to unambiguously tell the difference between receive indications. Putting a requirement on the application to make that distinction by their own devices provides no additional service that they don't already have in existing APIs. Roy _______________________________________________ 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
