[openib-general] basic IB doubt

[Michael Krause]

At 02:58 PM 8/24/2006, Sean Hefty wrote:
> >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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20060828/cdd830f7/attachment.html>