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

Brad Besmer brad.besmer at broadcom.com
Wed May 29 08:03:27 PDT 2019


Hello Lana,



Figure 173 is an example of non-interlocked frame transmission. It is from
the perspective traffic on the SAS Link, it does not specify specific rules
for the state machines.



In SPL4, section 7.2.2.3.10 PL_OC: Overall_Control state frame
transmission, it provides information about handling Tx Frame messages with
different logical unit number and initiator port transfer tag.



In practice, it is optimal to transmit multiple DATA frames for a single IO
“back to back”.



Brad



*From:* t10-bounces at t10.org [mailto:t10-bounces at t10.org] *On Behalf Of *Lana
Chan
*Sent:* Wednesday, May 15, 2019 4:44 PM
*To:* t10 at t10.org; Tim.Symons at microchip.com
*Cc:* Gurudatta Mewundi <gmewundi at cadence.com>; Deep Mehta <deep at cadence.com
>
*Subject:* [T10] [SAS]RESENDING: Request for clarification on handling
non-interlocked frame



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
      1. 3 WRITE commands (total bytes to write = 3K) with different ITAGS
      are transmitted from initiator to target
      2. Target sends XFER_RDY (XRDY) for 1st ITAG
      3. Initiator in response sends all DATA frames back to back without
      waiting for ACK/NAK
      4. Once all DATA frames received ACK/NAK response from Target, next
      XRDY with different ITAG value is transmitted
   2. Target LUN can handle multiple commands per LUN
      1. 3 WRITE commands (total bytes to write = 3K) with different ITAGS
      are transmitted from initiator to target
      2. Target sends XFER_RDY (XRDY) for all 3 DATA frames with different
      ITAG
      3. Initiator sends all 1st data frames of all 3 ITAG and wait for
      ACK/NAK for each data frame



Per 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*

*a)      **A non-interlocked frame with a different initiator port transfer
tag; or*

*b)      **An interlocked frame*

*Until all SSP frames have been acknowledged with ACK or NAK even if
transmit SSP frame credit is available**.*



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



Specifically:

   1. 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)
   2. 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)
   3. 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/20190529/fd7ed4ab/attachment.html>


More information about the T10 mailing list