SATA tunneling in SAS

Ayyavu, Vetrivel vetri at lsil.com
Mon Oct 28 09:36:46 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Ayyavu, Vetrivel" <vetri at lsil.com>
*

//************************************************************
[Jim Reif]:
	If you are referring to figure 84, don’t you mean to say “the
SATA_X_RDY primitive
	is flowing from the SATA Target port to the STP Initiator through
the expander port?
	If that is what you meant to say, then what do you mean by
“flowing”? If you mean 
	that the expander is acting as a pass-through device at this point,
that is not correct.
	The expander has to have some intelligence to generate the
SATA_X_RDY + CONT
	+ random scrambled data on the STP Initiator side on behalf of the
SATA Target 
	since the SATA Target will only be generating random scrambled data
by the time 
	the OPEN Address Frame has reached the STP Initiator. 
	Tables 84 & 85 are lacking in details, and I’m not sure if that was
done on purpose
	or not. 

[Vetri]: What I'm trying to say here is.....The table 84 is not showing
about receiving a OPEN_ACCEPT or OPEN_REJECT primitives from the STP
Initiator port Instead SATA_XRDY is on the STP initiator side (As you said,
the expander is acting as a pass-through device at this point. Its just
sending OPEN Address frame and then passing SATA target port primitive/FIS
directly to STP initiator without knowing OPEN_ACCEPT/REJECT). As you noted,
the expander has to have some intelligence and it has to generate SATA_RRDY
primitive to the SATA target only after receiving OPEN_ACCEPT from the STP
initiator. Once after generating SATA_RRDY, the expander can act as a
pass-through device (ie, can connect SATA target port dircetly with STP
initiator port).

The point is, the table 84 is not mentioning anything about
OPEN_ACCEPT/REJECT primitives. The SATA_XRDY primitive may go to STP
initiator side only after receiving OPEN_ACCEPT from the STP initiator. But,
the table shows SATA_XRDY is next to OPEN Address frame and its misleading
me to understand that the expander has started acting as a pass-through
device at this point. I hope I'm not confusing now :-)    

The question is.....table84 is correct or not?. By looking at the table, I'm
trying to understand where exactly the expander is becoming pass-through
device.

//*************************************************************

[Jim Reif]:
	I’m not sure that the SATA spec indicates the required behavior of a
device if it does
	not receive an R_RDY in response to an X_RDY. I suspect that this is
vendor unique,
	and that at some point the Application layer in the SATA Target
would time out and 
	potentially start sending SYNC’s. Does anyone else know what the
SATA drive will
	do?

[Vetri]: I think you are correct, it may timeout.

//*************************************************************

[Jim Reif]
	You are missing SATA_XRDY showing up on the right hand side (to STP
Initiator).

[Vetri]: I believe....If expander handles OPEN_ACCEPT/REJECT then the
SATA_XRDY is don't care for STP initiator. Because, the expander becomes
pass-through only after receieving OPEN_ACCEPT and  generating SATA_RRDY to
the SATA target. 

The question is, my assumption is correct or not?

//*************************************************************

[Jim Reif]:
	Are you more concerned with how SATA_XRDY gets propogated thru the
expander
	from the source to destination or how SATA_RRDY gets propogated from
the destination
	to the source? Clearly the expander shouldn’t generate RRDY’s until
the OPEN_ACCEPT
	is received, unless it’s got enough buffering to start accepting
data from the Target, and
	that should be true for both case 1) and 2). For case 2), you do not
show where SATA_XRDY
	shows up on the Initiator side, so it’s hard to say if case 2) is
correct.  Or are you proposing that
	STP Initiators treat the OPEN Address Frame as the XRDY and don’t
actually need to see a
	propogated SATA_XRDY before sending SATA_RRDY?

	For further discussion, what should the expander’s response be to
the SATA Target if the
	STP Initiator returns with an OPEN_REJECT instead of an OPEN_ACCEPT?
Should the
	expander send SYNC’s to back to the SATA Target?


[Vetri]: Since the expander connects only after OPEN_ACCEPT, I thought that
our intent is not actually need to see a propagated SATA_XRDY at the STP
initiator side. Yes...You got me here.

Yes, the expander has to keep on SYNC if the STP initiator returns with an
OPEN_REJECT.

//*****************************************************************

Please correct me if I'm again wrong anywhere.


thanks,
Vetri. A
LSI Logic,
6145-D, Northbelt parkway,
Norcross, GA-30071, USA.
Tel: 678-728-1365
Email: vetri at lsil.com

     


-----Original Message-----
From: Reif, Jim [mailto:Jim.Reif at hp.com]
Sent: Saturday, October 26, 2002 9:39 PM
To: Ayyavu, Vetrivel; t10 at t10.org
Subject: RE: SATA tunneling in SAS


See  comments below…

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


	-----Original Message-----
	From:	Ayyavu, Vetrivel [SMTP:vetri at lsil.com]
	Sent:	Wednesday, October 23, 2002 2:16 PM
	To:	't10 at t10.org'
	Subject:	SATA tunneling in SAS

	* From the T10 Reflector (t10 at t10.org), posted by:
	* "Ayyavu, Vetrivel" <vetri at lsil.com>
	*
	Hi,

	       The discussion is about STP Transport layer Section 9.3.1
SATA
	tunneling (Page 247 - Revision 2b, 19OCT2002).

	1)

	This is the paragraph..........

	"
		Table 84 shows a target port transmitting a SATA frame to an
	expander port. The expander device opens a connection to an STP
initiator
	port or to an expander port on the path to the STP initiator port
solely for
	the frame

	 
	      Table 84 - SATA target port transmitting a frame

	SATA target port to Exp port	 Exp port to exp or STP initiator
port	
	          SATA_SYNC	           Idle dword	
	          SATA_XRDY	           OPEN address frame	
	          <repeats>	           SATA_XRDY	
	          <repeats>	           <repeats>	
	          <wait for SATA_RRDY	     <wait for SATA_RRDY>	
	          SATA_SOF	           SATA_SOF	
	          FIS	                 FIS	
	          CRC	                 CRC	
	          SATA_EOF	           SATA_EOF	
	          SATA_WTRM                SATA_WTRM	
	          SATA_SYNC	           CLOSE	

	"
	As per the table, the expander port sends OPEN address frame to STP
	initiator/Exp port  when there is SATA_XRDY primitive from the SATA
target
	port. After transmitting OPEN address frame, the expander connects
the SATA
	target directly with STP initiator/Exp port without waiting for
	OPEN_ACCEPT/OPEN_REJECT. As shown in the table, the SATA_XRDY
primitives are
	flowing from STP initiator/Exp port to SATA target port, the SATA
target can
	decode the SATA_XRDY and gives back SATA_RRDY (assuming that the
SATA target
	is ready)......then SOF, FIS etc. (Pls correct me if I'm wrong in
	understanding the above table this way)

	[Jim Reif]
	If you are referring to figure 84, don’t you mean to say “the
SATA_X_RDY primitive
	is flowing from the SATA Target port to the STP Initiator through
the expander port?
	If that is what you meant to say, then what do you mean by
“flowing”? If you mean 
	that the expander is acting as a pass-through device at this point,
that is not correct.
	The expander has to have some intelligence to generate the
SATA_X_RDY + CONT
	+ random scrambled data on the STP Initiator side on behalf of the
SATA Target 
	since the SATA Target will only be generating random scrambled data
by the time 
	the OPEN Address Frame has reached the STP Initiator. 
	Tables 84 & 85 are lacking in details, and I’m not sure if that was
done on purpose
	or not. 

	I beleieve the expander can connect the SATA target port with STP
	initiator/Exp port only after receiving OPEN_ACCEPT primitive.
Otherwise,
	when STP initiator/EXP port is busy, it will not send RRDY
primitives and
	the connections will be hanging for RRDY (both expander <--> STP
	Initiator/Exp and expander <--> SATA Target).

	[Jim Reif]
	I’m not sure that the SATA spec indicates the required behavior of a
device if it does
	not receive an R_RDY in response to an X_RDY. I suspect that this is
vendor unique,
	and that at some point the Application layer in the SATA Target
would time out and 
	potentially start sending SYNC’s. Does anyone else know what the
SATA drive will
	do?

	2)

	As I understood, the flow will be like this
	            
	SATA target port to Exp port	     Exp port to exp or STP
initiator port	
	          SATA_SYNC	           Idle dword	
	          SATA_XRDY	           OPEN address frame	
	          <repeats>	           Idle dword (waits for OPEN
Accept/Reject)

	          <repeats>	           <repeats>	
	          <wait for SATA_RRDY>     <Received OPEN Accept>	
	          SATA_SOF	           SATA_SOF	
	          FIS	                 FIS	
	          CRC	                 CRC	
	          SATA_EOF	           SATA_EOF	
	          SATA_WTRM                SATA_WTRM	
	          SATA_SYNC	           CLOSE	

	[Jim Reif]
	You are missing SATA_XRDY showing up on the right hand side (to STP
Initiator).

	The expander sends OPEN Address frame and waits for
OPEN_ACCEPT/OPEN_REJECT
	primitives from the STP Initiator/Exp port and if it receives
OPEN_ACCEPT
	then it signals RRDY to SATA target port and connects the SATA
target
	directly with STP Intiator/Exp port. 

	Simillarly, for Table 85 (STP initiator port transmitting a frame)
also.

	The question is .........

	Which is correct 1) or 2)?.

	[Jim Reif]
	Are you more concerned with how SATA_XRDY gets propogated thru the
expander
	from the source to destination or how SATA_RRDY gets propogated from
the destination
	to the source? Clearly the expander shouldn’t generate RRDY’s until
the OPEN_ACCEPT
	is received, unless it’s got enough buffering to start accepting
data from the Target, and
	that should be true for both case 1) and 2). For case 2), you do not
show where SATA_XRDY
	shows up on the Initiator side, so it’s hard to say if case 2) is
correct.  Or are you proposing that
	STP Initiators treat the OPEN Address Frame as the XRDY and don’t
actually need to see a
	propogated SATA_XRDY before sending SATA_RRDY?

	For further discussion, what should the expander’s response be to
the SATA Target if the
	STP Initiator returns with an OPEN_REJECT instead of an OPEN_ACCEPT?
Should the
	expander send SYNC’s to back to the SATA Target?


	Please correct me if anything wrong here.

	thanks,
	Vetri. A
	LSI Logic,
	Email: vetri at lsil.com







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