98-145r0 - Discovering If This Is SES Port A or Port B

Binford, Charles charles.binford at symbios.com
Tue Apr 28 15:36:00 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Binford, Charles" <charles.binford at symbios.com>
*
See my comments below.  By the way,  Ralph's proposal was on my behalf
since I will not be at the T10 meeting to argue the point.  But, I am on
the reflector!

Charles Binford
Symbios Inc.


 ----------
>From: Bob Snively
>To: T10 at symbios.com
>Subject: Re: 98-145r0 - Discovering If This Is SES Port A or Port B
>Date: Tuesday, April 28, 1998 2:39PM
>
>* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
>* Bob Snively <Bob.Snively at Eng.Sun.COM>
>*
>
>Folks,
>
>Gene is absolutely correct.  Dual Port never made it into a standard,
but
>rather into a period of drafts.  In addition to these identification
>bits, there were also some complex interrelationships involving
>clearing tasks and reseting devices that were part of the proposal, and
>these too were dropped because of their complexity, potential conflicts
>with other task management states, and because the PERSISTENT
RESERVATION
>function provided the needed task management functionality with a
uniform
>mechanism.
>
>History aside, it has been my impression that the "REPORT" bits in
>many of the SES elements actually provide much of this function.
>The report bits are included in the device element, the ES controller
>electronics element, the SSC controller electronics element, the
>SCSI port/transceiver element, the SCSI target port element, and the
>SCSI initiator port element.  I have always assumed that a given
>drive port is attached to a given link accessed through a
>given SCSI port/transceiver element or target port element.  While the
>mapping may be enclosure specific, the mapping is fixed and can be
>built into the driver structures and data files associated with that
>enclosure.

While the "REPORT" bits are very useful, they don't solve the problem
Ralph's proposal was trying to solve.  If drive enclosures were
restricted to two SCSI port/transceivers then I could live with an SES
requirement that the SCSI port/transceiver on loop A was always reported
as the first element.  However there is no restriction on the number of
port/transceivers on a drive enclosures.  I know of enclosures which
have 4.  Are the two ports connected to loop A reported as the first and
second element or as the first and third element?  As Bob mentioned in
his text above, the "mapping is fixed" for a given enclosure,  BUT THAT
IS VENDOR SPECIFIC, not a *standard*.


>
>For device elements with more than two ports, a new device element
>definition would be required in SES, but that is not as likely as
>finding an enclosure or RAID controller with multiple ports.
Fortunately,
>that case is already well covered by SES.
>
>If you will not grant me this, and insist on reporting port information
>through the inquiry command, then I recommend the following approach:

I would not insist on reporting port information through inquiry, that
is merely a proposal to solve the problem.  I do insist we agree upon a
*standard* solution to the problem.  The requirement is the ability to
relate a given port of a device (or path to a device) to either the "A"
or "B" designation of the bypass bits in the SES device element status
and control page.  If there are others ways to solve this problem I'd
like to here them.  Using the VS bit in the Inquiry as it was defined in
several intermediate drafts seemed like a quick and easy way to get
there.

>A)  No change to task management
>
>	Do not provide any controls for tasks as a function of
>	port except those provided through the presently defined
>	Task Management functions and through the presently
>	defined service actions of PERSISTENT RESERVE OUT.

I completely agree.  Changing this was never the intent.

>	
>B)  No change to the Vendor Specific bit (INQUIRY data, byte 6, bit 5)
>
>	This bit was an interim solution used by a few early
>	adopters of dual (not multi-) port implementations.
>	
>C)  No change to the Multi Port bit (INQUIRY data, byte 6, bit 7)
>
>	This bit is still valid and needs no changes.
>	
>D)  Add a formal (and optional) multi-port path identification
function.
>
> 	This would allow the identification of one of a number of ports
> 	to the device.  It could be included in any of the following
> 	locations, depending on the preference of the committee.  I put
> 	these options in my preferred order, most desirable being
presented
> 	first.

These proposals seem to require more work for implementors, but I have
no strong objection as any of them can solve the problem at hand.

>
>     1)  INQUIRY vital product data, new page.
>
>        A new vital product data page of with a page length of 1 would
>        provide a field which would allow 256 separate ports to be
>        identifed.
>
>     2)	 INQUIRY vital product data, additional parameter in
page 83.
>
>      	A new identifier could be provided to the device identification
>      	page.  This descriptor would have a new type, called
>      	"ordinal identifier" and would have a one byte identifier field.
>      	The association field would have a value of 1 for the
>      	ordinal identifier, indicating that it was associated with
>      	the port that received the request.  Up to 256 separate ports
>      	could be identified.
>      	
>     3)  INQUIRY data, byte 5.
> 	
> 	A 3 bit (0-2) or 4 bit (0-3) field could be used in byte 5
> 	of the INQUIRY data to indicate which port is being used in
> 	communicating this particular INQUIRY command.  8 or 16
> 	separate ports could be identified.
>
>
>*
>* For T10 Reflector information, send a message with
>* 'info t10' (no quotes) in the message body to majordomo at symbios.com
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list