SAS SL_CC handling of CLOSE

[Elliott, Robert (Server Storage)]

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott 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
> 
> 
> 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?

RE:
The STP/SATA bridge can only originate a CLOSE when it has not
forwarded an X_RDY or R_RDY from the SATA target.  The same
rules apply to all STP ports:
"An STP port shall not originate closing an STP connection after 
sending a SATA_X_RDY or SATA_R_RDY until after both sending and 
receiving SATA_SYNC."

> 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.

RE: 
There cannot be a FIS in-flight if the STP initiator sends a CLOSE.
A FIS means that R_RDY has been sent; after sending one, the
STP initiator cannot send a CLOSE.

If the CLOSE crosses an X_RDY on the wire, the CLOSE wins.  The
STP target port has to open a new connection to forward the X_RDY.

> 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. 

RE: Neither of these rules are necessary.

> Does this solve the problem?
> 
> Bob
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott


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