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

Brad Besmer brad.besmer at broadcom.com
Wed May 29 12:05:04 PDT 2019


Not sure I follow what you are really asking.



Both #1 and #2 could be supported, however 2c is not ideal, it would be
better to say:



c. Initiator sends N data frames for first ITAG, M data frames for second
ITAG and O data frames for third ITAG

where: N M and O is 1 to the number of frames for each respective IO.



IMO, it really depends upon the buffering behavior of the device as to how
many frames are actually transmitted for each IO.



*From:* Deep Mehta [mailto:deep at cadence.com]
*Sent:* Wednesday, May 29, 2019 12:48 PM
*To:* Brad Besmer <brad.besmer at broadcom.com>; Lana Chan <lana at cadence.com>;
t10 at t10.org; Tim.Symons at microchip.com
*Cc:* Gurudatta Mewundi <gmewundi at cadence.com>
*Subject:* RE: [T10] [SAS]RESENDING: Request for clarification on handling
non-interlocked frame



Hi Brad,



Thank you for the response.



So, Initially there may be two approaches/options (mentioned in our
previous mail)

   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*



What I understood from your suggestion is – “Preferred way” of doing is
Single IO/ITAG with its back to back DATA frames – *OPTION 1 *



We understood that concern, but rather here we are not getting specific
pointers from specification reference which allow us to only implement
OPTION 1.

So will you consider this as “Vendor specific” implementation or there is
other references which we are missing here from SPL4.



Your thought will be greatly appreciated.



Thanks.



Regards,

Deep

*From:* Brad Besmer <brad.besmer at broadcom.com>
*Sent:* Wednesday, May 29, 2019 8:33 PM
*To:* Lana Chan <lana at cadence.com>; t10 at t10.org; Tim.Symons at microchip.com
*Cc:* Gurudatta Mewundi <gmewundi at cadence.com>; Deep Mehta <deep at cadence.com
>
*Subject:* RE: [T10] [SAS]RESENDING: Request for clarification on handling
non-interlocked frame



EXTERNAL MAIL

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

*All non-interlocked frames with different initiator port transfer tags;
and*

*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 non-interlocked frame with a different initiator port transfer tag; or*

*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/ed289c18/attachment.html>


More information about the T10 mailing list