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

Fri Jan 9 10:28:09 PST 2009

I didn't add "parent" device. The new vendor defined devices are
children of ibbus/hca. I don't know much about IOU. Can you shed the
light on why we need IOU? Can all the drivers just connect through IBAL
interface?

Thanks,

-James

________________________________

From: Fab Tillier [mailto:ftillier at windows.microsoft.com] 
Sent: Friday, January 09, 2009 9:19 AM
To: Deepak Gupta; James Yang
Cc: ofw at lists.openfabrics.org
Subject: RE: ***SPAM*** Re: [ofw] Expose a vendor defined device in
ibbus?

I had suggested allowing devices to have a 'parent' device, in order to
let the ibbus driver create a hierarchy of devices.  This would
eliminate the need for the ibiou driver altogether.  I haven't had a
chance to look at James' patch, though, so I don't know how much would
need to be done.

Personally, I think it would make sense to start a new bus driver, based
on the KMDF, to implement this.  It makes (in theory at least) handling
the child device lists much easier.

-Fab

From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Deepak Gupta
Sent: Thursday, January 08, 2009 5:08 AM
To: James Yang
Cc: ofw at lists.openfabrics.org; Fab Tillier
Subject: ***SPAM*** Re: [ofw] Expose a vendor defined device in ibbus?

James,

Although I didn't get the time to test it but I had a look at the patch,

Going by a dry run on the patch it looks to me that it is for creating
vendor defined child devices on "IBA".

It looks ok to me, I will do a test on it and will reply.

We need multiple IOC device interfaces (more than one child device
mapping to same IOC).
If we go on the similar lines, it seems to me that we need to put the
same device creation logic in "ibiou" driver.

But as specified above by Fab, If we are removing the IOC PnP Manager
code from IBAL, then there will be changes
required in "ibiou" driver because currently "ibiou" registers a PnP
callback for IOC events. 

If IOC PnP manager code is removed from IBAL then we will need SA
queries to be done specifically from "ibiou" driver.

I want to implement child device creations from "ibiou" too.
Should I remove IOC PnP callback mechanisms in "ibiou" and make it
dependent on user configurations for creating the child devices?

I am new to IBAL's code, So please let me know if I am getting anything
wrong.

Regards
Deepak

On Thu, Jan 8, 2009 at 12:35 AM, James Yang <jyang at xsigo.com> wrote:

Please use this new patch which fixed a few compile errors in free
build.

Thanks,

James

________________________________

From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of James Yang
Sent: Tuesday, January 06, 2009 12: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/20090109/20744aad/attachment.html>