[openib-general] FW: [openfabrics-ewg] Changes in SM for the new SRP daemon

Thu Apr 6 11:11:58 PDT 2006

Yes it should.

Ishai

________________________________

From: Woodruff, Robert J [mailto:robert.j.woodruff at intel.com] 
Sent: Thursday, April 06, 2006 1:31 AM
To: Ishai Rabinovitz; openfabrics-ewg at openib.org
Subject: RE: [openfabrics-ewg] Changes in SM for the new SRP daemon

Shouldn't this discussion be on openib-general ?

________________________________

From: openfabrics-ewg-bounces at openib.org
[mailto:openfabrics-ewg-bounces at openib.org] On Behalf Of Ishai
Rabinovitz
Sent: Wednesday, April 05, 2006 2:14 PM
To: openfabrics-ewg at openib.org
Subject: [openfabrics-ewg] Changes in SM for the new SRP daemon

Summary:

	In the next release of SRP we want to add a daemon that is
executed in each initiator and finds out which targets exist in the
fabric.

	The new daemon can use SA capabilities from IBTA 1.2 errata
(details at the bottom) to improve performance. If you are using SM
other then openIB's openSM please support this feature in your SM.

Details:

	When one wants to find all SRP targets and their information in
the fabric, he/she currently run "ibsrpdm"
	"ibsrpdm" uses the following procedure to discover all SRP
targets available in the fabric

	1.	"ibsrpdm" sends a query get_table node info with node
type is CA. 
	2.	It gets quite a big table and then for every node it
sends a port_info query. 
	3.	From the response to this query the initiator can check
if this port is an SRP target. (dm bit capability is set)

	The problem with this procedure is that it may create too much
traffic on the fabric.

	Let's assume there is a cluster of 4096 nodes booting together.
Each of this 4096 nodes is sending the first query and gets a list of
4096 nodes. This list is divided into a long number of UD messages and
may cause retransmit. After getting this list each node sends 4096
queries for the port of each node.

	This traffic is quite huge.

	The SA has a new capability to answer the query: "please return
a list of the ports that has the dm bit set" (meaning return ports of
SRP targets). (This capability of the SA is part of Errata Release
Version: 1.2 1/26/2006 Chapter/Subsection: 15.2.5.3  - quoted at the
bottom). 

	Using this capability we can use the following procedure:

	1.	The daemon will send "get table port_info of ports that
has dm bit set" query and gets a table of small number of port_info.  
	2.	For each port It queries for the guid of this ports.

	This will significantly reduce the traffic on the fabric. 

	Actually, in this solution there is so little traffic that the
new daemon will run it periodically (every minute) to look for changes
(There will be less traffic than registering to Trap 64 and Trap 65.)

Quoting the errata:

------------------------------------------------------------------------
----

	Errata Tracking Number: MGTWG8372 

	Sub-Case Number: 0 

	Reference ID: 4291 

	Title: Enhanced SA PortInfoRecord searches 

	Submitter: Livingston, James (James.Livingston at necsam.com) 

	Volume: 1 

	Revision: 1.2 

	Errata Release Version: 1.2 1/26/2006 

	Chapter/Subsection: 15 

	Page: 885 

	Line: 20 

	AssignedIntensity: 

	Status/Disposition: WG_Approved 

	Problem Description: Add a new row to Table 186 SA-Specific 

	ClassPortInfo:CapabilityMask Bits: 

	Problem Resolution: Add a new row to Table 186 SA-Specific 

	ClassPortInfo:CapabilityMask Bits 

	Original Text: <none> 

	Corrected Text: <Name> 

	IsPortInfoCapMaskMatchSupported 

	<Bit> 

	13 

	<Description> 

	If this value is 1, SA shall support matching the 

	PortInfo:CapabilityMask component as described in <ref to
section 

	15.2.5.3>. 

	Comment History: Dec 14, 2005 08:11:26 PM Old: New:Pending
By:Benner, Alan 

	(bennera at us.ibm.com) 

------------------------------------------------------------------------
----

	Errata Tracking Number: MGTWG8372 

	Sub-Case Number: 1 

	Reference ID: 4292 

	Title: Enhanced SA PortInfoRecord searches 

	Submitter: Livingston, James (James.Livingston at necsam.com) 

	Volume: 1 

	Revision: 1.2 

	Errata Release Version: 1.2 1/26/2006 

	Chapter/Subsection: 15.2.5.3 

	Page: 891 

	Line: 36 

	AssignedIntensity: 

	Status/Disposition: WG_Approved 

	Problem Description: Add optional compliance statement for new
capability. 

	Problem Resolution: Make the proposed change to the spec text. 

	Original Text: <none> 

	Corrected Text: o15-0.x.y: If SA's 

	ClassPortInfo:CapabilityMask.IsPortInfoCapMaskMatchSupported is
1, 

	then the AttributeModifier of the SubnAdmGet() and
SubnAdmGetTable() 

	methods affects the matching behavior on the
PortInfo:CapabilityMask 

	component. If the high-order bit (bit 31) of the
AttributeModifier 

	is set to 1, matching on the CapabilityMask component will not
be an 

	exact bitwise match as described in <ref to 15.4.4>. Instead, 

	matching will only be performed on those bits which are set to 1
in 

	the PortInfo:CapabilityMask embedded in the query. 

	In <ref to o15-0.x.y>, bits in the PortInfo:CapabilityMask
embedded 

	in the query that are set to 0 are bitwise wildcards for
purposes of 

	matching. 

	This gives a requester the ability to select desired
capabilities 

	and query for ports which support those capabilities. 

	If SA's
ClassPortInfo:CapabilityMask.IsPortInfoCapMaskMatchSupported 

	is 0, or if bit 31 of the AttributeModifier is 0, then any
matching 

	performed on the PortInfo:CapabilityMask component is as
described 

	in <ref to 15.4.4>. 

	Comment History: Dec 14, 2005 08:21:47 PM Old: New:Pending
By:Benner, Alan 

	(bennera at us.ibm.com) 

------------------------------------------------------------------------
----

	Ishai

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20060406/018586df/attachment.html>