[ofw] Expose a vendor defined device in ibbus?

[Tzachi Dar]

Two comments:
 
The format written in the registry should be extensible.  That is, each
vendor ULP will be able to add more fields if it needs them. I guess
that the format that Fab has suggested is already such.
 
Another thing is that ipoib should also work in this method. This means
that the coinstaller that installs the bus filter should also create the
needed registry entries for ipoib.
 
Thanks
Tzachi


________________________________

	From: Deepak Gupta [mailto:mailmeatdkg at gmail.com] 
	Sent: Friday, December 19, 2008 12:21 PM
	To: Fab Tillier
	Cc: Tzachi Dar; James Yang; ofw at lists.openfabrics.org
	Subject: Re: [ofw] Expose a vendor defined device in ibbus?
	
	


	On Wed, Dec 17, 2008 at 11:43 PM, Fab Tillier
<ftillier at windows.microsoft.com> wrote:
	

		> It seems to me that the best solution for you is to
use a mechanism
		> that is close to what the ipoib partition manager are
using. This is a
		> mechanism that allows one to add more devices with a
hard coded name
		> of IBA\\IPoIBP. So what you should probably do is to
change that
		> mechanism to allow it creating devices with different
names.
		> Using this you will be able to achieve your goal in a
generic way.
		
		
		I think it would be worthwhile at this point to design a
solution that works for both James' issue, IPoIB's partition support, as
well as IOU/IOC devices (to replace IBAL's IOC PnP logic).  Some of this
was already discussed either on the mailing list or at the Sonoma
Workshop in the past.
		
		And to be clear, James, the way this would work from a
development perspective is that you would implement the change and
submit patches for discussion, unless you make other arrangements.
		
		To kick off the discussion, here are my thoughts:
		
		1. static device creation should be generic enough that
it could be used for all IO Units/IO Controllers.  A REG_MULTI_SZ
registry type, filled with strings representing each child device, would
do the trick here.  We should discuss what should be in this string.  As
a starting point, let me suggest:
		- Hardware IDs
		- Compatible IDs
		- Name
		- Location
		- Unique ID of the device -
		- Parent ID, which is either NULL if the parent is the
HCA, or the Unique ID of a parent device.  This allows building a
hierarchy of devices so that IOC to IOU relationships can be represented
in the device manager.
		- Port GUID
		- PKey
		
		For IPoIB this could look something like:
"HW_ID:IBA\IPOIB COMP_ID:NULL NAME:"IPoIB Adapter" LOC:AUTO
UID:IBA\IPOIB\F8F3010000AD0500FFFF PARENT_ID:NULL
PORT_GUID:0005AD000001F3F8 PKEY:FFFF"
		
		Are there other properties that I have missed that are
needed?


	We need a way in which devices created should be configured for
failovers ( ULPs like VNIC, SRP need more configurable failovers).
	Looking at IBAL's code it create the devices based on the
reachable IOC's and thus failover's are possible across the HCA/ports
and not across two different IOCs.
	Users can have a case in which two different IOCs connected to
same physical network/storage (redundancy is provided for high
availability) and want a failover across the IOCs.
	
	So I think it would be great to add path  properties (with
failover configurations) when devices are created.
	So that ulp drivers can get those path params by issuing a
QUERY_INTERFACE on the child PDOs.
	
	



		2. The IOC PnP manager in IBAL is problematic in large
fabrics because it creates such a high SA traffic load.  Sean suggested
a while back having a configuration tool that scans the fabric for
IOU/IOC and allows the user to select the devices which should be
reported statically (by writing a bus driver registry key that the bus
driver reads when it loads or is triggered via an IOCTL).  This would
allow removing the IOC PnP manager form IBAL.
		
		-Fab
		
		_______________________________________________
		ofw mailing list
		ofw at lists.openfabrics.org
	
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
		


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20081219/3ac49216/attachment.html>