|
While looking at the design of some conformance tests a
couple of issues have come up: Item 5 in clause 10.2.1 states: “ 5. An RNIC MUST
provide a mechanism for the ULP to establish and
revoke read, write, or read and write access to the ULP Buffer
referenced by an STag. “ I am unclear as to the intent of this statement. Is it
stating that the RNIC must provide the ULP with the ability to revoke read and
write access independent of the revoking of the association between an Stag and
a buffer? In particular, if I have Stag 1 which was allocated with
write access, must the RNIC provide an interface that allows the ULP to change
the access granted through Stag 1 to just “read” ? (i.e. a
mechanism in addition to revoking Stag access and allocating a new Stag with
read access) Is memory associated to a Stag TO pair, or just a Stag? A
buffer appears to be defined by both the Stag and the TO, so is it possible for
the RNIC interface to return (STAG=100, TO =0), associating a buffer to a
(STAG, TO) and then return (STAG=100, TO= 500) for another buffer? (Assuming
this did not violate any length constraints) Item 6 in clause 10.2.1 states: 6. An RNIC MUST ensure
that the network interface can no longer
modify an advertised buffer after the ULP revokes remote
access rights for an STag. The actual wording makes no assertion about what happens to
READ access via the network interface to a buffer once the ULP revokes remote
access rights. I am assuming the intent of this is really type of access. (I
think this is a editorial issue and “modify” should be replaced by
a more general terms)\ Item 7 in clause 10.2.1 states: 7. An RNIC MUST ensure that a
Remote Peer is not able to
invalidate an STag enabled for remote access, if the STag is
shared on multiple streams. What is the expected behavior of the RNIC when its remote
peer attempts to invalidate a Stag that is valid within the context of two
streams? The draft does not indicate what the actual behavior is – I am
assuming that the RNIC will terminate the stream. Is this correct? Item 8 in clause 10.2.1 states: 8. An RNIC MUST choose
the value of STags in a way difficult to
predict. It is RECOMMENDED to sparsely populate them over the full
range available. Is the “full range” a reference to the bits available
in the fields used to describe the Stag (i.e. the Stags should range over 32
bits from 0 to 2^32 -1) or is it some vendor specific range? Item 11 in clause 10.2.1 states: 11. An RNIC implementation
SHOULD provide a mechanism to cap the
number of outstanding RDMA Read Requests. Does “cap” imply that the ULP API must provide
the ability to define and hence “cap” the number of outstanding
READ requests that the RNIC will accept from the ULP, or does CAP imply that,
whatever the limit is (lets say 16) then the RNIC will ensure that there are
never more than 16 READ REQUEST as compared to READ REPLIES (as seen on the
wire)? |
_______________________________________________ rddp mailing list rddp at ietf.org https://www1.ietf.org/mailman/listinfo/rddp