[T10] FW: Initiator determine of IPTT reusability - clarification needed

[Bill Martin]

T10 protocol experts:

Please see the below question from Samsung and the initial response from Tim Symons. It looks like this is a topic for discussion next week at the T10 meeting. I will post a document on Monday related to this.

Bill Martin

Chair INCITS T10
Co-Chair SNIA Technical Council

NVMe Board of Directors
SSD I/O Standards
Samsung Semiconductor, Inc.
Cell (408) 499-1839

From: Richard Deglin
Sent: Friday, July 9, 2021 12:10 PM
To: Tim.Symons at microchip.com
Cc: Bill Martin <bill.martin at samsung.com>
Subject: RE: Initiator determine of IPTT reusability - clarification needed

Tim,

Please see my comment below.

I would argue that it's unclear if control over and proper use of and recycling of initiator port transfer tags is rightly part of SPL or is, as you suggest, outside the scope of SPL. I will leave this determination to the SPC and SAM experts.

By all means, please forward this to the appropriate persons for further discussions, or bring this question up in the meeting next week.

Thanks.

From: Tim.Symons at microchip.com<mailto:Tim.Symons at microchip.com> [mailto:Tim.Symons at microchip.com]
Sent: Friday, July 9, 2021 11:58 AM
To: Richard Deglin <r.deglin at samsung.com<mailto:r.deglin at samsung.com>>
Cc: Bill Martin <bill.martin at samsung.com<mailto:bill.martin at samsung.com>>
Subject: RE: Initiator determine of IPTT reusability - clarification needed

Hi Rich,
I didn't see your e-mail, perhaps the old e-mail address goes to a quarantine  or junk area. My new e-mail address is: tim.symons at microchip.com<mailto:tim.symons at microchip.com>.

Now that I have your question here are some initial responses, and maybe we need to post this to the SCSI Protocol experts for a more system oriented response.


1.       First question - what is IPTT?  I cannot find this term in SPL Initiator Port Transfer Tag

2.       General comment about the way T10 specifications avoid too much prescriptive text:

*         SPL defines the SAS protocol and transport aspects, but host behavior is not supposed to be defined in the SPL specification, this is probably why in section 9.2.2 (SPL4 r13) the text is non-prescriptive and the text provides an "example" of how a host "may" detect a certain condition.

3.       SPL deals with the transport of data packets and connections but the host needs to use the command tools to evaluate whether a transfer tag is still valid.

I am probably not the right person to answer your exact question, and I think it may be better directed to the SPC experts with some specific examples if there is ambiguity or better still a suggestion for improving the text to remove ambiguity.

Let's keep this chat going if I've miss interpreted the questions.

Regards
Tim.


From: Bill Martin <bill.martin at samsung.com<mailto:bill.martin at samsung.com>>
Sent: Friday, July 9, 2021 10:53 AM
To: Richard Deglin <r.deglin at samsung.com<mailto:r.deglin at samsung.com>>; tim.symons at microsemi.com<mailto:tim.symons at microsemi.com>
Subject: RE: Initiator determine of IPTT reusability - clarification needed

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
Tim:

Can you answer this question.

Rich:

If Tim does not get back to you over the weekend I will try to decipher this on Monday. Next week is also the T10 meeting week, where I can ask the question.

Bill Martin
Chair INCITS T10
Co-Chair SNIA Technical Council
NVMe Board of Directors
SSD I/O Standards
Samsung Semiconductor, Inc.
Cell (408) 499-1839

From: Richard Deglin
Sent: Friday, July 9, 2021 10:06 AM
To: tim.symons at microsemi.com<mailto:tim.symons at microsemi.com>
Cc: Bill Martin <bill.martin at samsung.com<mailto:bill.martin at samsung.com>>
Subject: RE: Initiator determine of IPTT reusability - clarification needed
Importance: High

Did you both miss this email? I need some help with this. Thanks.

From: Richard Deglin
Sent: Thursday, July 1, 2021 11:03 AM
To: 'tim.symons at microsemi.com' <tim.symons at microsemi.com<mailto:tim.symons at microsemi.com>>
Cc: Bill Martin <bill.martin at samsung.com<mailto:bill.martin at samsung.com>>
Subject: Initiator determine of IPTT reusability - clarification needed

Hi Tim.

Although it was a long time ago, you may remember me from my days at Vitesse. Or perhaps not.

An interesting question has arisen about the methods that an initiator can use to determine the eligibility of an IPTT for reuse. Consider the following sequence:


1.       Target sends RESPONSE frame, which is ACKed by initiator.

2.       Target receives the ACK and sends DONE (NORMAL).

3.       DONE is lost due to bus error.

4.       Initiator BREAKs the connection.

What is the state of the IPTT? Section 9.2.2 of SPL4 / SPL5 says nothing about broken connections. Is the state indeterminate? Is it vendor specific what an initiator will do in this case? Is that the right approach for the standard?

"a SCSI application
client shall not reuse the initiator port transfer tag until it determines the initiator port transfer tag is no longer in
use by the logical unit (e.g., the ACK for the RESPONSE frame was seen by the SSP target port). Examples
of ways the SCSI application client may determine that an initiator port transfer tag may be reused are:

a) receiving another frame in the same connection;
b) receiving a DONE (NORMAL) or DONE (CREDIT TIMEOUT) in the same connection; or
c) receiving a DONE (ACK/NAK TIMEOUT) in the same connection, then running a QUERY TASK task
management function to confirm that the initiator port transfer tag is no longer active in the logical unit."

The list given in this section is not exhaustive. Also, the use of "may" bothers me. Tag overlap is a serious failure. It makes me wonder why this section doesn't have stronger language.

What do you think?

Thanks.

Rich Deglin
Principal Engineer and Firmware Architect, Enterprise Product Development
Samsung Semiconductor Inc.
Office   408 544 4204
Cell        408 410 6584

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.t10.org/pipermail/t10/attachments/20210709/ab96529c/attachment.html>