***SPAM*** Re: [ofw] Expose a vendor defined device in ibbus?

[Deepak Gupta]

Please see my comments below:--

Regrads
Deepak

On Fri, Dec 19, 2008 at 7:31 PM, Tzachi Dar <tzachid at mellanox.co.il> wrote:

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

True,  it should be extensible.
One more thing I want to add is need for a IOCTL which will notify IBAL to
rescan the registry and create/delete required child devices which are not
already there in the tree so that we don't need to restart IBAL each time we
want to add/remove a child device.


> 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/9888ddcf/attachment.html>