>We're trying to create *inter-operable* hardware and
>software in this community. So we follow the IB standard.
Atomic operations and RDD are optional, yet still part of the IB "standard". An
application that makes use of either of these isn't guaranteed to operate with
all IB hardware. I'm not even sure that CAs are required to implement RDMA
reads.
A TCA is not required to support RDMA Read. A HCA is required.
It is correct that atomic and reliable datagram are optional. However, that does not mean they can be used or will not work in an interoperable manner. The movement to a software multiplexing over a RC (a technique HP delivered to some ISV years ago) may make RD obsolete from an execution perspective but that does mean it is not interoperable. As for atomics, well, they are part of IB and many within MPI would like to see their support. Their usage should also be interoperable.
>> It's up to the application to verify that the hardware that they're
>> using provides the required features, or adjust accordingly, and
>> publish those requirements to the end users.
>
>If that was being done (and it isn't), it would still be bad for the
>ecosystem as a whole.
Applications should drive the requirements. Some poll on memory today. A lot
of existing hardware provides support for this by guaranteeing that the last
byte will always be written last. This doesn't mean that data cannot be placed
out of order, only that the last byte is deferred.
Seems much of this debate is really about how software chose to implement polling of a CQ versus polling of memory. Changing IB or iWARP semantics to compensate for what some might view as a sub-optimal implementation does not seem logical as others have been able to poll CQ without such overheads in other environments. In fact, during the definition of IB and iWARP, it was with this knowledge that we felt the need to change the semantics was not required.
Again, if a vendor wants to work with applications written this way, then this
is a feature that should be provided. If a vendor doesn't care about working
with those applications, or wants to require that the apps be rewritten, then
this feature isn't important.
But I do not see an issue with a vendor adding value beyond what's defined in the spec.
It all comes down to how much of the solution needs to be fully interoperable and how much needs to be communicated as optional semantics. You could always define API for applications to communicate their capabilities that go beyond a specification. This is in part the logic behind an iSCSI login or SDP Hello exchange where the capabilities are communicated in a standard way so software does the right thing based on the components involved. Changing fundamentals of IB and iWARP seems a bit much when it is much easier to have the ULP provide such an exchange of capabilities if people feel they are truly required.
Mike
_______________________________________________ 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
