<html>
<body>
<font size=3>At 02:58 PM 8/24/2006, Sean Hefty wrote:<br>
<blockquote type=cite class=cite cite="">>We're trying to create
*inter-operable* hardware and<br>
>software in this community. So we follow the IB standard.<br><br>
Atomic operations and RDD are optional, yet still part of the IB
"standard". An<br>
application that makes use of either of these isn't guaranteed to operate
with<br>
all IB hardware. I'm not even sure that CAs are required to
implement RDMA<br>
reads.</font></blockquote><br>
A TCA is not required to support RDMA Read. A HCA is
required. <br><br>
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.<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>>> It's up to
the application to verify that the hardware that they're<br>
>> using provides the required features, or adjust accordingly,
and<br>
>> publish those requirements to the end users.<br>
><br>
>If that was being done (and it isn't), it would still be bad for
the<br>
>ecosystem as a whole.<br><br>
Applications should drive the requirements. Some poll on memory
today. A lot<br>
of existing hardware provides support for this by guaranteeing that the
last<br>
byte will always be written last. This doesn't mean that data
cannot be placed<br>
out of order, only that the last byte is
deferred.</font></blockquote><br>
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. <br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>Again, if a vendor
wants to work with applications written this way, then this<br>
is a feature that should be provided. If a vendor doesn't care
about working<br>
with those applications, or wants to require that the apps be rewritten,
then<br>
this feature isn't important.<br><br>
But I do not see an issue with a vendor adding value beyond what's
defined in the spec.</blockquote><br>
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.<br><br>
Mike</font></body>
</html>