[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[rddp] Looking for some insight



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