My concern is the requirement that RDS resync the structures in the face of failure
and know whether to re-transmit or will deal with duplicates. Having pre-posted buffers
will help enable the resync to be accomplished but should not be equated to pre-post equals
one can deal with duplicates or will verify to prevent duplicates from occurring.
Mike
The
semantics should be that barring an error the flow between any
two
endpoints is reliable and ordered.
The
difference versus a normal point-to-point definition of reliable is
that
a)
lack of a receive buffer is an error, b) the endpoint
communicates
with
many known remote peers (as opposed to one known remote
peer,
or many unknown).
Having
an API with those semantics, particularly as an upgrade in
semanitcs from SOCK_DGRAM while preserving
SOCK_DGRAM
syntax, is something that I believe is of distinct value to
many
cluster based applications. Further the API can be
implemeneted
in an
offload device (IB or IP) more efficiently than if it is
simply
implemented on top of SOCK_STREAM sockets by the
application.
Documenting and clarifying the semantics to make it's general
applicability
clearer should definitely be done, however.
_______________________________________________ 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
