[T10] [SAS] Request for clarification on handling non-interlocked frame

Lana Chan lana at cadence.com
Thu Mar 14 14:52:02 PDT 2019


Hello

I'd like to get clarification on the expected transmission of non-interlocked frames in the case of multiple XFER_RDY frames received by the initiator.

Per Figure 173 of the SPL4 spec, all non-interlocked frames (DATA frames) with the same initiator port transfer tag (ITAG) are transmitted together without waiting for ACK/NAK.  Once transmission of all data frames with the same ITAG is completed and all the data frames are responded with ACK/NACK, then transmission of DATA frames with different ITAG values begins.


However, non-interlocked frame transmission differs dependent upon the commands that can be handled by the target LUN

  1.  Target LUN can handle single command per LUN
     *   3 WRITE commands (total bytes to write = 3K) with different ITAGS are transmitted from initiator to target
     *   Target sends XFER_RDY (XRDY) for 1st ITAG
     *   Initiator in response sends all DATA frames back to back without waiting for ACK/NAK
     *   Once all DATA frames received ACK/NAK response from Target, next XRDY with different ITAG value is transmitted
[cid:image001.png at 01D4DA74.A0E523E0]

  1.  Target LUN can handle multiple commands per LUN
     *   3 WRITE commands (total bytes to write = 3K) with different ITAGS are transmitted from initiator to target
     *   Target sends XFER_RDY (XRDY) for all 3 DATA frames with different ITAG
     *   Initiator sends all 1st data frames of all 3 ITAG and wait for ACK/NAK for each data frame
[cid:image002.png at 01D4DA74.A0E523E0]
                In section 6.20.6

                Before transmitting a non-interlocked frame, an SSP phy shall wait for:

  1.  All non-interlocked frames with different initiator port transfer tags; and
  2.  All interlocked frames

To be acknowledged with ACK or NAK, even if transmit SSP frame credit is available



After transmitting a non-interlocked frame, a SSP phy may transmit another non-interlocked frame with the same initiator port transfer tag if transmit SSP frame credit available.  The phy shall not transmit

  1.  A non-interlocked frame with a different initiator port transfer tag; or
  2.  An interlocked frame
Until all SSP frames have been acknowledged with ACK or NAK even if transmit SSP frame credit is available.


Our understand is that Figure 173 is only true for "Pending TX Frame" buffer in Port layer (already put by Transport layer)

Specifically,


     *   Transport layer is having 3 XRDY reception with different ITAG. So, transport layer will prepare to send all 3 DATA frames handled through individual ST_ITS state machines (one ST_ITS state machine for each possible command and task management function i.e., for each initiator port transfer tag)
     *   Now, Once all 3 state machines put their first prepared DATA frame in Port layer queue/buffer; next valid DATA frame can be put in port layer buffer/queue once frame transmitted confirmation received from Link layer for previously transmitted frame by that state machine. (SPL4 spec reference : section 8.2.6.2.3.3 ST_ITS2:Initiator_Send_Frame state)
     *   Here, there is no arbitration define at Transport layer, for handling multiple ITAG DATA frames transmission once XRDY frame received for those - as a result Initiator will prepare 1st DATA frame of each ITAG received, and as all three frames have different ITAG value, as per specification each DATA frame will wait for ACK before transmitting another DATA frame with different ITAG.

Is our understanding correct?  Do you see any implementation/execution conflict?

Kind regards
Lana

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20190314/50e14e42/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 153775 bytes
Desc: image001.png
URL: <http://www.t10.org/pipermail/t10/attachments/20190314/50e14e42/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 173365 bytes
Desc: image002.png
URL: <http://www.t10.org/pipermail/t10/attachments/20190314/50e14e42/attachment-0003.png>


More information about the T10 mailing list