<br><br><div class="gmail_quote">On Wed, Dec 17, 2008 at 11:43 PM, Fab Tillier <span dir="ltr"><<a href="mailto:ftillier@windows.microsoft.com">ftillier@windows.microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">> It seems to me that the best solution for you is to use a mechanism<br>
> that is close to what the ipoib partition manager are using. This is a<br>
> mechanism that allows one to add more devices with a hard coded name<br>
> of IBA\\IPoIBP. So what you should probably do is to change that<br>
> mechanism to allow it creating devices with different names.<br>
> Using this you will be able to achieve your goal in a generic way.<br>
<br>
</div>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.<br>

<br>
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.<br>
<br>
To kick off the discussion, here are my thoughts:<br>
<br>
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:<br>

- Hardware IDs<br>
- Compatible IDs<br>
- Name<br>
- Location<br>
- Unique ID of the device -<br>
- 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.<br>

- Port GUID<br>
- PKey<br>
<br>
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"<br>
<br>
Are there other properties that I have missed that are needed?</blockquote><div><br>We need a way in which devices created should be configured for
failovers ( ULPs like VNIC, SRP need more configurable failovers).<br>
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.<br>
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.<br>
<br>
So I think it would be great to add path  properties (with failover configurations) when devices are created.<br>
So that ulp drivers can get those path params by issuing a QUERY_INTERFACE on the child PDOs.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
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.<br>

<font color="#888888"><br>
-Fab<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
ofw mailing list<br>
<a href="mailto:ofw@lists.openfabrics.org">ofw@lists.openfabrics.org</a><br>
<a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw" target="_blank">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw</a><br>
</div></div></blockquote></div><br>