SAS SL_CC handling of CLOSE
Elliott, Robert (Server Storage)
Elliott at hp.com
Thu Apr 3 07:02:15 PST 2003
* 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
More information about the T10
mailing list