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

[Deepak Gupta]

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