Christoph Hellwig wrote:
> On Thu, Aug 18, 2005 at 04:05:29PM -0400, Luben Tuikov wrote:
>
>>On 08/18/05 13:56, Christoph Hellwig wrote:
<snip/>
>>> What we might need an rport for is to support SMP. I'm
>>>not yet sure how to do SMP passthrough, but we will need some object
>>>to represent SMP ports.
>>
>>Why? How is this going to be used? What is the architecture model?
>
>
> We need some way to implement SMP passthrough. One of the options is
> to have a passthrough node that frames can be written to - for that we
> obviously need an object for non-scsi target sas remote ports.
Well lets talk about SMP for a bit. We need to
be able to use this protocol for more complex SAS
topologies. Monitoring simple SAS topologies with
only one expander would be aided by using SMP.
Like many management protocols, SMP violates
the layer abstraction. Since it sits besides SSP and STP
above the transport and port layers in the SAS stack then
it should be addressing via a (source) port. However its
functions talk about phys (not ports).
Further, if you look at SDI (revision 0), specifically
the SDI_SMP_PASSTHROUGH in section 5.12, then it assumes
the SAS initiator (rather than an initiator port) can
have an ioctl sent to it. On the source side it routes
via either:
- a phy ***
- a port
- or both (a phy within a port)
It also specifies the connection rate (SAS defines both
1.5 and 3 Gbps), and the destination SAS address (most likely
of an expander). That ioctl reports two levels of errors:
- associated with the connection (e.g. ...REJECT_BAD_DESTINATION)
- from the SMP target (e.g. UNKNOWN_SMP_FUNCTION)
and if all is well the response may include information
from the target (i.e. an expander). The ioctl also handles
security issues which a pretty simple in the case of
SMP [codes 0x0->0x7f fetch information while codes
0x80->0xff potentially change the state of an expander].
BTW There is nothing to stop a SAS HBA implementing a
SMP target, which would allow multiple initiators to
at least see one another. Also SMP has its own pass-through
to read and write a GPIO register.
Now the SDI_SMP_PASSTHROUGH ioctl seems pretty ugly,
passing over 2048 bytes of data for each function
(1024 bytes for the request and 1024 bytes for the
response). That 1024 matches the maximum payload
for SMP requests and responses (SAS 1.1 transport
layer). Given the definition of SAS-1.1 SMP functions
that is massive overkill. However zoning in SAS-2
will increase the number and size of some SMP functions
(and responses). [One company has already announced
silicon for SAS-2 zoning.]
So the SDI_SMP_PASSTHROUGH is closely tuned to the
capabilities of SMP rather than a generic pass through.
A SAS expander must have an SMP target whose SAS address
is by definition the expander's address. Expanders are
not SCSI devices (but may include or be associated with
SCSI devices (e.g. a SES device)). Expanders directly
connected to a SAS HBA are visible as "attached" (SAS)
devices; other expanders are discovered via SMP.
My theme here is if we are not going to use the
SDI_SMP_PASSTHROUGH at least we should understand what
it does. It is different from the SG_IO ioctl (for
example) which opens a connection to an end device
that has a device node and a sysfs identity (in
/sys/class/scsi_device). The SG_IO ioctl has no
addressing information in its metadata. Rather
SDI_SMP_PASSTHROUGH talks via a SAS HBA which has a
sysfs identity (and could have a device node) and
passes addressing information (source port/phy and
SMP target address) through as part of its metadata.
That way expanders (especially those not directly
attached to the HBA) do not have to appear in sysfs.
I'll stop here to see who objects to the above.
*** SMP seems to consume one connection along a path for
the duration of its request-response cycle. So when
an SMP initiator sends a request through a source phy then
nothing else will happen on that phy until the response
(or some error) arrives back on that phy.
Doug Gilbert
-
: 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
