SAS 2 Muxing and DISCOVER

Craig Stoops craig at expertio.com
Tue May 15 08:52:13 PDT 2007


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

Hi Bob Sheffield (and others),
My purpose isn't to change the standard, but to clarify it. I can find
nothing in the standard to prevent each logical phy from having it's own
address, and in fact in section 4.1.2 (of 9a), the words are pretty
supportive of this possibility where the spec describes that a physical phy
may operate as 2 complete logical phys and lists the characteristics. There
is nothing in any of the other sections to say one way or another. I also
don't see a way to enforce that the same address be used on the two logical
phys, and other than Discovery, it works fine - the two logical phys either
look like a wide port, or two single phys.
I do have to differ with section 4.1.2 a bit, in that phys don't really have
addresses. The way the standard is written, addresses and IAFs belong to the
link layer (SLIR) and MA and not the phy layer, but that's another matter
for discussion.
I'll state a fairly obvious example of a natural use for muxing. Since the
point of muxing is to effective use a 6Gb link to communicate with two 3Gb
devices, using muxing is is possible to build a very cheap active-active mux
with NO embedded processor and NO embedded expander function. Using muxing,
this part has one 6gb host port, and two 3Gb (or 1.5 Gb) ports to connec the
devices to. If each logical phy connected to the host has it's own SAS
address, there is no internal arbitration for links, and no processor
required to make this work.
Now someone might say, "but link multiplexing can't be required", however an
OEM can require anything they want in their box. And active-active muxes
appear to be a very hot commodity right now given the number of companies
that have them in development, and this demand is being driven directly by
OEM requirements. 
Please do not construe my comments one way or another as supportive of
Multiplexing in general. But if we are going to have it, we should deal with
the issues.
Craig Stoops
ExpertIO, Inc.
"Your Storage Verification Experts"
www.expertio.com
805-428-0839
-----Original Message-----
From: Sheffield, Robert L [mailto:robert.l.sheffield at intel.com] 
Sent: Monday, May 07, 2007 4:25 PM
To: Day, Brian; craig at expertio.com; t10 at t10.org
Subject: == SPAM == RE: SAS 2 Muxing and DISCOVER
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