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

[rddp] Conformance test design issue with exposed MULPDU



I am seeking to write a conformance tests that addresses that following
item from DDP clause 3, first item, which states:

"   1.  LLPs MUST expose MULPDU & MULPDU Changes. This is required so 
       that the DDP layer can perform segmentation aligned with the 
       MULPDU and can adapt as MULPDU changes come about. The corner 
       case of how to handle outstanding requests during a MULPDU 
       change is covered by the requirements below.

   2.  In the event of a MULPDU change, DDP MUST NOT be required by the 
       LLP to re-segment DDP Segments that have been previously posted 
       to the LLP. Note that under pathological conditions the LLP may 
       change the advertised MULPDU more frequently than the queue of 
       previously posted DDP Segment transmit requests is flushed. 
       Under this pathological condition, the LLP transmit queue can 
       contain DDP Messages which were posted multiple MULPDU updates 
       previously, thus there may be no correlation between the queued 
       DDP Segment(s) and the LLP's current value of MULPDU. "

In seeking to test the DUT's exposing of MULPDU changes I am currently
assuming that if:

1. There has been no TCP MAXSEG option advertisement,
2. The maximum sized TCP window seen by the DUT is N octets (where N is
not limited by the lower bound of a segment, and is smaller than that
advertised by the DUT)
3. The window size is advertised to the DUT at a time when no RDMA
operation has been requested.

then when a RDMA Send/write operation is requested of the DUT w/ Nish
octets the DUT will send one FPDU in one TCP segment. (Nish implies that
N is selected with an awareness of the need to take into account
headers).

What I am a less sure on is the next step. I would like to know if
people believe that the following is required normative behavior:

Once the DUT has sent the FPDU as outlined above, consuming the N octets
advertised by the test station, the test station advertises a window
smaller that N, uses PULP to queue additional RDMA send/write requests,
and then checks to see that the new FPDUs are such that they fit into
the now smaller TCP segment.

I believe this to be the heart of what the conformance item is
requesting, but I'm not sure how quickly a LLP is supposed to map a
change in the EMSS to the MULPDU and expose it to the ULP.

If this is an invalid test in your mind, is there a delta (in either
time or octet stream space) by which the DUT would have to change the
exposed MULPDU?





Barry Reinhold
Lamprey Networks
bbr at lampreynetworks.com
(603) 868-8411
 




_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp