spl2r02.pdf section 6.18.2 [link layer, SSP, Full duplex]:
"SSP is a full duplex protocol. An SSP phy may receive
an SSP frame or primitive in a connection while it is
transmitting an SSP frame or primitive in the same
connection. A wide SSP port may send and/or receive
SSP frames or primitives concurrently on different
connections (i.e., on different phys)."
For a SCSI command like READ(10) a connection consumes
one initiator phy and one target phy plus the pathway
between them until it is closed. Typically a READ
would have two connections: one to send the CDB and a
second connection later to return the data and response
(SCSI status and possibly sense data). For a spinning
disk there could be milliseconds between those two
connections; with an SSD less (do they use only one
connection?).
Due to the full duplex nature of a connection, DATA
frames associated with a WRITE could overlap with DATA
frames associated with an READ CDB sent earlier.
In SAS-2, a single READ's maximum data rate is 6 Gbps.
If a 2-phy wide link is available (along the whole pathway
(see Figure 129 in spl2r02.pdf)) then two READs, sent one
after the other or concurrently, could have their DATA
frames returned concurrently. So the combined maximum
data rate of the two READs would be 12 Gbps.
Expanders don't change what is stated above. Pathways
become an interconnection of links. A small latency is
added to the opening of connections. And there is the
possibility that no links are available to establish a
connection (e.g. target to expander has available link(s)
but all expander to initiator links are occupied).
Wondering has anyone measured performance under such scenario ?. It
would be
great to see Expanders terminating SSP frames to over come
some of above limitation. Links between HBA and Expander and Expander
to Disk
can be still Class 1.
Not sure I follow. Expanders come into play when
connections are being established.
If you've single Expander with multiple initiators and disks then there
are no issue unless multiple initiators/targets
trying to access to same resources. There is no QoS (other than Path way
count and Disconnect/Reconnect mode page)
enforced by the expander. Once you start daisy chaining expanders
pathway between expanders will be bottle neck due
to connection oriented nature of SAS protocol.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
