SAS 2 Muxing and DISCOVER

Sheffield, Robert L robert.l.sheffield at intel.com
Mon May 7 16:24:33 PDT 2007


Formatted message: <A HREF="r0705078_f.htm">HTML-formatted message</A>

Craig and Brian,
Saw my name mentioned in this thread. I think what's being suggested is
that it might be a reasonable thing for logical phys to be in different
SAS ports, even if they share the same physical phy. This would require
changing the standard, andI haven't heard a good argument to say why it
wouldn't work. Nobody has posted a proposal showing the changes that
would allow this.
Bob Sheffield
Intel Corporation
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Day,
Brian
Sent: Monday, May 07, 2007 3:28 PM
To: craig at expertio.com; t10 at t10.org
Subject: RE: SAS 2 Muxing and DISCOVER
Craig...
Actually, the current 9a draft of the spec (it was also present in
revision 9) does require all logical phys/links for a physical phy/link
have the same SAS address.  The statement is in section 7.8.2, saying:
"The IDENTIFY address frame sent by each logical phy in a physical phy
shall be identical."
Based on that requirement, logical links within a muxxed physical phy
would then always be in the same wide port.
And provides a reason that keeping the discovery based on physical phys
is sufficient.
Brian Day
LSI Corp.
________________________________
From: Craig Stoops [mailto:craig at expertio.com] 
Sent: Sunday, May 06, 2007 10:09 AM
To: t10 at t10.org
Cc: Day, Brian; 'Sheffield, Robert L'
Subject: FW: SAS 2 Muxing and DISCOVER
Rob (Elliot), 
I don't think anyone responded to this. I have seen several proposals
(one from Robert Sheffield) that discuss handling of virtual phys (in an
expander) but none talking about logical phys that have been created by
the addition of muxing.
Logical phys for a physical link need not have the same address, and may
or may not be part of the a wide port.
Does anyone have a proposal on how this (discover and reporting) should
be handled?
Thanks,
Craig
-----Original Message-----
From: Craig Stoops [mailto:craig at expertio.com] 
Sent: Wednesday, March 14, 2007 8:11 PM
To: 't10 at t10.org'
Subject: SAS 2 Muxing and DISCOVER
Rob, Steve, Brian and others involved:
I'm wondering about SMP Discover and interaction with Muxing. I've read
the recent proposal 07-091r0 regarding the Discover extensions, but I
feel there are some issues at hand. 
>From a higher perspective, there isn't much difference between 2 logical
phys with muxing and 2 physical phys. Each logical phy sends and
receives an Identify Frame (IAF). As such, each logical phy is free to
advertise any capabilities it sees fit, including a unique SAS address.
The two logical phys need not send the same information. The net result
is, that the 2 related logical phys may either be viewed as 2 logical
ports, or two phys as part of a wide port. I know that when Muxing was
suggested that being seen as a wide port is what was in mind, but I can
think of several target devices that would like to advertize two
different SAS addresses on the muxed link. There is nothing I can find
in the standard to prevent this, and modeling show it works very nicely.
To the higher level layers such as port layer of Expander Function,
there is no difference between a muxed link and a non-muxed link. Only
the SAS addresses on that link determine whether the logical phy is part
of a wide port or not.
However, this implies that when addressing a SAS device that has muxing
enabled, that it should report the number of phy as as the number of
logical phys, not physical. And also, it needs to be possible to issue a
Discover to each logical phy, not just physical phy inorder to gain
access to the individual IAF results.
Another potential solution is to issue Discover for Phyical phys, but
have space to report the capabilities of each logical phy that is part
of that phycial phy, eg two attached sas address, two sets of
capbiltiies (both local and remote), etc
Comments?
Craig Stoops
ExpertIO, Inc.
"Your Storage Verification and Design Experts"
805-428-0839



More information about the T10 mailing list