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

[Deepak Gupta]

Did any one get the chance to have a look at the patch?

I am really concerned with the tight coupling of representing each single
IOC as a single PDO.

Regards
Deepak



On Wed, Jan 21, 2009 at 5:55 PM, Deepak Gupta <deepak.gupta at qlogic.com>wrote:

> All,
>
> Based on James patch of creating user defined devices tied to local HCA
> ports, I have created a first draft patch attached herewith
> to allow "ibiou" to create user defined devices which will associate with
> IOC paths.
>
> This patch does the following:-
>
> Now ibiou will not create child devices on it's own when it discovers a
> IOC.
> Instead it will create child devices only when it is instructed to do so.
> For the sake of this patch, currently it uses name/description of the
> devices hard coded into INF file of ibiou driver.
> Later on we can implement a IOCTL to pass this information to the driver
> (more below)
>
> It will make a listing of devices to be created in it's DriverEntry
> routine.
> When it will get IOC_PNP_ADD pnp events, it will check in device list
> prepare
> earlier. If it finds device(s) in it's list which corresponds to the new
> IOC
> discovered then it will create those child devices and a similar mechanism
> will happen when ibiou will get IOC_PNP_ADD event.
>
> This more of a initial patch for giving an insight into what we want to
> achieve.
> On a longer run we are thinking of providing a IOCTL support in ibiou
> driver for creating child devices (like vnic/srp/etc) and
> differnet vendor specific applications can create those devices and have
> their driver loaded on top of that.
>
> Following is the advantage of this functionality:-
>
>    Earlier there was only one device created per IOC on host side.
>    Now there can be multiple devices on host side per IOC as configured in
> the registry.
>    It will be many to one function i.e there can be many devices on host
> side which will target to the same IOC.
>    It will be like having different sessions with the same IOC.
>
> Please have a look at it and let me know of your
> comments/suggestions/feeback.
>
> NOTE--> Device descriptions in the INF file of this patch creates devices
> that corresponds to a IOC PATH (CAGUID and IOCGUID).
>         Those values are local to my machine and you should change it
> according to your fabric.
>
> Regards
> Deepak
>
>
>
> On Tue, Jan 20, 2009 at 1:37 AM, James Yang <jyang at xsigo.com> wrote:
>
>>  The proposal is to use registry key to define vendor devices, and the
>> registry key is global to the driver. The assumption is that multiple HCA
>> cards will have the same vendor defined devices. It cannot support one HCA
>> with vendor-A device, and the other HCA with vendor-B device, in the same
>> system. At default all hcas will have IPoIB as child devices.
>>
>>
>>
>> Thanks,
>>
>> James
>>
>>
>>  ------------------------------
>>
>> *From:* Leonid Keller [mailto:leonid at mellanox.co.il]
>> *Sent:* Sunday, January 18, 2009 5:57 AM
>> *To:* James Yang; Deepak Gupta; Fab Tillier
>>
>> *Cc:* ofw at lists.openfabrics.org
>> *Subject:* RE: [ofw] Expose a vendor defined device in ibbus?
>>
>>
>>
>> After first look: why did you put the list of the created devices into
>> Globals (and not, say, FDO) ?
>>
>> How it will work for multi-home machine ? (several HCA cards)
>>
>> Would anybode like to check it for various partition keys ?
>>
>>
>>  ------------------------------
>>
>> *From:* ofw-bounces at lists.openfabrics.org [mailto:
>> ofw-bounces at lists.openfabrics.org] *On Behalf Of *James Yang
>> *Sent:* Tuesday, January 06, 2009 10:11 PM
>> *To:* Deepak Gupta; Fab Tillier
>> *Cc:* ofw at lists.openfabrics.org
>> *Subject:* RE: [ofw] Expose a vendor defined device in ibbus?
>>
>> Hi,
>>
>>
>>
>> Please review the patch to create user defined devices by reading from
>> registry. By default there is only one IpoIB device enabled in mlx4_hca.inx
>> file. This patch will only work for ConnectX.
>>
>>
>>
>> The paritition key if set to default to FFFF, I didn't test on other
>> value. And the Ioctl part to add partition key may also need to be verified.
>>
>>
>>
>> Thanks,
>>
>> James
>>
>>
>>
>>
>>  ------------------------------
>>
>> *From:* mailmeatdkg at gmail.com [mailto:mailmeatdkg at gmail.com] *On Behalf
>> Of *Deepak Gupta
>> *Sent:* Monday, January 05, 2009 10:51 PM
>> *To:* Fab Tillier
>> *Cc:* Tzachi Dar; James Yang; ofw at lists.openfabrics.org
>> *Subject:* Re: [ofw] Expose a vendor defined device in ibbus?
>>
>>
>>
>> Have a gr8 New Year to all the members!!!.
>>
>> Do you we any updates on "vendor defined device in ibbus"?
>>
>> I wanted to create multiple vnic interfaces irrespective of number of
>> reachable IOCs.
>>
>> Currently I am creating vnic child devices on "root" bus.
>> Inside VNIC driver, I am looking for arrival GUID_IB_AL_INTERFACE and
>> hence contacting the IBAL.
>> But since vnic devices are root enumerated, VNIC driver gets loaded very
>> earlier in boot phase (Before "Extended Base" group to which IB Stack
>> drivers belong) and hence VNIC device interfaces are not getting initialized
>> properly.
>>
>> If we are providing a vendor defined device functionality in ibbus in near
>> future, then it would be worth for me to wait for it.
>>
>> Can any one please comment on this.
>>
>> Regards
>> Deepak
>>
>>  On Mon, Dec 22, 2008 at 1:12 PM, Deepak Gupta <deepak.gupta at qlogic.com>
>> wrote:
>>
>> All,
>>
>> I came across one more question in my mind which are I think is not clear
>> to me after reading the whole thread.
>>
>> In new design being discussed:-
>> Are we making sure that we can have more than one child devices configured
>> for the same IOC.
>> Currently, there is one child device created per IOC discovered.
>>
>> Having more than one child device configured for same IOC is a requirement
>> if a user wants two different ULP interfaces to be created on host side.
>> Consider a case in which a host is connected to a single IOC and IOC is
>> connected to a ethernet network via switch.
>> If there are two different IP subnets then there is a requirement of two
>> different Ethernet interfaces on the host side too.
>>
>> Please let me know if you need more clarification of my question.
>>
>> Regards
>> Deepak
>>
>>
>>
>> On Sat, Dec 20, 2008 at 2:19 PM, Deepak Gupta <deepak.gupta at qlogic.com>
>> wrote:
>>
>> Please see below.
>>
>> Regards
>> Deepak
>>
>> On Sat, Dec 20, 2008 at 12:42 AM, Fab Tillier <
>> ftillier at windows.microsoft.com> wrote:
>>
>> > On Wed, Dec 17, 2008 at 11:43 PM, Fab Tillier
>> > <ftillier at windows.microsoft.com> wrote:
>>
>> >> 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.
>>
>> This would be done via LBFO for network devices, and MPIO for storage
>> devices.  I think having the bus driver report a single IOC that really maps
>> to two IOCs on the fabric is asking for management problems.  Further,
>> LBFO/MPIO can provide failover between different device types, so the
>> failover devices don't have to be identical HW.
>>
>>
>> I don't know about how MPIO works. But for LBFO,  BundleID param will have
>> to be included in extended params then so that user gets the freedom of
>> bundling  different failover configurations.
>>
>>
>>
>>
>> -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/20090123/7c7f471e/attachment.html>