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

Bob Snively Bob.Snively at Eng.Sun.COM
Tue Apr 28 12:39:53 PDT 1998

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Bob Snively <Bob.Snively at Eng.Sun.COM>


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

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

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:

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.
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

     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
     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

More information about the T10 mailing list