SAS SL_CC handling of CLOSE

Reif, Jim Jim.Reif at hp.com
Wed Apr 2 17:26:35 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Reif, Jim" <Jim.Reif at hp.com>
*
I don't think we want to prohibit STP Target ports from initiating CLOSE. 
Maybe prohibit SATA/STP bridges from doing this, but as you said in your
first email, STP Targets have more knowledge about when a good time to
close the connection is. 

Jim Reif
Hewlett-Packard 
281-514-8237
email: jim.reif at hp.com


-----Original Message-----
From: Sheffield, Robert L [mailto:robert.l.sheffield at intel.com]
Sent: Wednesday, April 02, 2003 6:13 PM
To: Day, Brian; George Penokie; Elliott, Robert (Server Storage)
Cc: owner-t10 at t10.org; t10 at t10.org
Subject: RE: SAS SL_CC handling of CLOSE


* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Robert L" <robert.l.sheffield at intel.com>
*
OK, so if the STP/SATA bridge decides (for whatever reason) to close the connection, it can flow-control frames from the SATA device to avoid stomping on them. But that still doesn't mean the bridge has enough information to know when is a 'good' time to close the connection. My earlier suggestion to allow only the STP initiator to send CLOSE could cause a "clean-up" condition if the STP initiator happens to send a CLOSE out while there's a FIS or X_RDY in-flight from the SATA device, or would it?

Question - if the STP initiator sends a CLOSE and there's an X_RDY or FISes in-flight from the SATA device, can the bridge (and expander) hold-off closing the connection (and sending the CLOSE in return) until the end of the frame? That would leave the connection open long enough to avoid stomping on frames, and would allow the bridge to cleanly close the connection. Obviously if the STP initiator had sent a CLOSE, it would expect to get a CLOSE in return - ergo, an implied Request Close from the STP link layer on the STP initiator side.

The proposed rules would then be:
1. Prohibit STP target ports (or perhaps just SATA/STP bridges) from initiating CLOSE.
2. STP target ports can only generate CLOSE upon receipt of CLOSE. 

Does this solve the problem?

Bob

-----Original Message-----
From: Day, Brian [mailto:bday at lsil.com]
Sent: Wednesday, April 02, 2003 4:10 PM
To: Sheffield, Robert L; George Penokie; Elliott, Robert (Server
Storage)
Cc: owner-t10 at t10.org; t10 at t10.org
Subject: RE: SAS SL_CC handling of CLOSE


Bob...

I don't think there is any "clean-up" required when the STP/SATA bridge
piece closes the connection just as the SATA device wants to send a frame.
Based on the CLOSE rules for STP connection that were added in my 02-363, as
long as the bridge hasn't given any hint that the SATA device wants to send
a frame over the STP connection (as determined that is hasn't forwarded the
X_RDY from the SATA link to the STP link), then there aren't any frames that
get corrupted or lost.

In this case, the STP/SATA bridge would just continue to send SATA_SYNCs to
the SATA device, until the connection to the initiator is re-established at
some later (perhaps MUCH later) time.

Brian Day
LSI Logic



-----Original Message-----
From: Sheffield, Robert L [mailto:robert.l.sheffield at intel.com]
Sent: Wednesday, April 02, 2003 2:40 PM
To: George Penokie; Elliott, Robert (Server Storage)
Cc: owner-t10 at t10.org; t10 at t10.org
Subject: RE: SAS SL_CC handling of CLOSE


* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Robert L" <robert.l.sheffield at intel.com>
*
Let's see first if I can restate the problem to make sure I'm clear on it...

The STP/SATA bridge is responsible for deciding when to request a close on
behalf of a SATA device. The SATA device knows whether it has frames to
send, but the bridge doesn't, and there doesn't seem to be a reliable way
for the SATA device to inform the bridge whether or not it will have frames
to send. So whatever heuristics the bridge uses to decide when to send a
close, there's a race condition where the SATA device attempts to send
frames just as the bridge decides to close the connection. I'm not sure what
we can do about that.

If we simply accept that this race condition occurs and requires cleanup of
some kind (close connection, reset device, retry command???) then perhaps
there's a more straightforward solution:
1. Prohibit STP target ports (or perhaps just SATA/STP bridges) from
generating CLOSE.
2. Require STP target ports to close immediately upon receipt of CLOSE
without requiring a preceding Request Close from the Link Layer.

This leaves it entirely up to the STP initiator port to manage closing
connections. Since an STP/SATA bridge doesn't ever generate CLOSE, the STP
initiator port doesn't ever have to worry about receiving a CLOSE without
first having received a Request Close from the link layer. The race
condition at the STP/SATA bridge still exists, but the STP initiator sees
all of the traffic from the SATA target just like the STP/SATA bridge, so it
has at least as much information to work with as the STP/SATA bridge, plus
some concept of the state of execution of outstanding commands, so it ought
to be able to do as good a job of deciding when to close the connection as
the bridge could.

This just applies to SATA devices attached through an STP/SATA bridge. We
might want STP target devices to behave differently since they can account
for the internal state of command execution in deciding when to close
connections.

This isn't a formal proposal to resolve the problem, just some thoughts.
What do you think?

Bob

Bob Sheffield
Intel Corporation - CH6-333
Storage Components Division (SCD)
5000 W. Chandler Blvd
Chandler, AZ 85226-3699
Phone: 480-554-8597
Fax: 480-554-6617
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list