[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