<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3243" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=428531713-29012009><FONT face=Arial color=#0000ff size=2>Having
an application, configuring IOC fabric means that you can't reveal and work with
remote disks at boot time.</FONT></SPAN></DIV>
<DIV><SPAN class=428531713-29012009><FONT face=Arial color=#0000ff size=2>Having
a configuration file means additional maintance/deployment work. Changing of the
may require fixing of the node images.</FONT></SPAN></DIV>
<DIV><SPAN class=428531713-29012009><FONT face=Arial color=#0000ff size=2>What
"failover" are you expecting from virtual adapters, running over a physical one
?</FONT></SPAN></DIV>
<DIV><SPAN class=428531713-29012009><FONT face=Arial color=#0000ff size=2>If the
latter gets stuck, all of them are dead. :(</FONT></SPAN></DIV>
<DIV><SPAN class=428531713-29012009><FONT face=Arial color=#0000ff size=2>[I'm
sure missing here something. Could you elaborate more on usage of these virtual
adapters ? TIA]</FONT></SPAN></DIV>
<DIV><SPAN class=428531713-29012009><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=428531713-29012009><FONT face=Arial color=#0000ff size=2>BTW,
if you are going to create IOC devices (from application but) on base of
ibiou.sys discovery, why wouldn't you do the same without application
?</FONT></SPAN></DIV>
<DIV><SPAN class=428531713-29012009><FONT face=Arial color=#0000ff size=2>Let
ibiou.sys creates IOC per HCA for every discovered
device...</FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> mailmeatdkg@gmail.com
[mailto:mailmeatdkg@gmail.com] <B>On Behalf Of </B>Deepak
Gupta<BR><B>Sent:</B> Thursday, January 29, 2009 2:47 PM<BR><B>To:</B> Leonid
Keller<BR><B>Cc:</B> ofw@lists.openfabrics.org<BR><B>Subject:</B> Re:
***SPAM*** Re: [ofw] Expose a vendor defined device in
ibbus?<BR></FONT><BR></DIV>
<DIV></DIV>Leonid,<BR><BR>I understand you might be busy with some other stuff
too.<BR><BR>As I already said, this was just a first draft patch and there are
no intentions to move it into the svn repository.<BR>I am sorry, I guess I
misled you by asking the question "whether above patch is
acceptable".<BR><BR>This patch was just to show a use case of having multiple
child devices associated with a IOC instead of having a single<BR>child PDO
for each IOC.<BR><BR>Plan is to provide a IOCTL interface in ibiou for
creation of child devices and all device information will be passed through
device<BR>IOCTLs (and not INF file, in this first draf patch I used INF file
for just POC). So no one has to know the IOC parameters at the time of
installation.<BR><BR>It indeed raise the need of a user application which can
scan the fabric and provide list the of reachable IOCs (particularly Port to
IOC path, like <B>ibsrpdm</B> and <B>ib_qlgc_vnic_query</B> tools on linux
do). <BR>I am thinking of providing a IOCTL in ibiou to return the list of
reachable IOCs.<BR>Having a list of reachable IOCs with the user, now user can
write a configuration file describing the child devices (or a GUI to enter the
child device descriptions). This user application will parse the configuration
file and will create the device interfaces.<BR>Also it will record the all
these descriptions into registry so that from the next boot, ibiou will create
the devices without the intervention of user app.<BR><BR><SPAN>>>
<FONT face=Arial color=#0000ff size=2>- having configured one
node, one has to repeate all this work with all the others or to prepare
and clone the image;<BR><BR><SPAN style="COLOR: rgb(0,0,0)">Once a node
has been configured with a config file, that can be used on other nodes
too.</SPAN><BR></FONT></SPAN><BR><SPAN>>> <FONT face=Arial
color=#0000ff size=2>- if a new IOC has been added, one has to go through all
the nodes and to change the Registries. It may also require reimaging of all
the nodes;</FONT></SPAN><BR><BR>If a new IOC has been added, then yes he would
need to make entries into config file and then user app will take care of
rest.<BR><BR><SPAN>>> <FONT face=Arial color=#0000ff
size=2>- what will happen during the WINOF package upgrade ? We don't want
user to repeat all this configuration work, do we ?</FONT></SPAN><BR><BR>We
will have to provide a versioning on above mentioned device IOCTLs interface
of ibiou. Minimal release changes will not affect the config file structure
and hence from a user perspective reconfiguration will not be
required.<BR><BR>This User Application will help create multiple child devices
for ULP's (SRP/VNIC) and hence much more failover configurations for the
user.<BR><BR>My basic question is if we agree to above then I can move ahead
for implmenting above mentioned device IOCTLs in ibiou<BR>and also start doing
work on the developing the user application to do this.<BR><BR>Please let me
know if you have any further queries on
it.<BR><BR>Regards<BR>Deepak<BR><BR><BR>
<DIV class=gmail_quote>On Thu, Jan 29, 2009 at 3:27 PM, Leonid Keller <SPAN
dir=ltr><<A
href="mailto:leonid@mellanox.co.il">leonid@mellanox.co.il</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV dir=ltr>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>Hi
Deepak,</FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>Sorry for that late
reaction. Could not find time beforehand to look into it...
:(</FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>I'm not sure, whether the
advantages of your patch are worth the deployment problems that it
can cause (IMO).</FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>Here are several
ones at the first look:</FONT></SPAN></DIV>
<DIV><SPAN></SPAN><SPAN> <FONT face=Arial><FONT
color=#0000ff size=2>- one has to know all the IOC parameters at the time of
installation;</FONT></FONT></SPAN></DIV></DIV></BLOCKQUOTE>
<DIV> </DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV dir=ltr>
<DIV><SPAN><FONT face=Arial><FONT color=#0000ff
size=2></FONT></FONT></SPAN></DIV>
<DIV><SPAN> <FONT face=Arial
color=#0000ff size=2>And what if they are yet unknown (IOCs still not
purchased) or unknown to the guy (he doesn't know what IOC at all is)
? :(</FONT></SPAN></DIV>
<DIV><SPAN> <FONT face=Arial><FONT color=#0000ff size=2>-
one has to enter IOC parameters during the installation in some
way;</FONT></FONT></SPAN></DIV>
<DIV><SPAN> <FONT face=Arial
color=#0000ff size=2>Changing INF file is not a convenient way. One has
to provide some GUI to edit the parameters during- and the Registry after
the installation;</FONT></SPAN></DIV>
<DIV><SPAN> <FONT face=Arial color=#0000ff size=2>- having
configured one node, one has to repeate all this work with all the others or
to prepare and clone the image;</FONT></SPAN></DIV>
<DIV><SPAN> <FONT face=Arial color=#0000ff size=2>- if a
new IOC has been added, one has to go through all the nodes and to change
the Registries. It may also require reimaging of all the
nodes;</FONT></SPAN></DIV>
<DIV><SPAN> <FONT face=Arial color=#0000ff size=2>- what
will happen during the WINOF package upgrade ? We don't want user to repeat
all this configuration work, do we ?</FONT></SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>What do you think
?</FONT></SPAN></DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(0,0,255) 2px solid; MARGIN-RIGHT: 0px">
<DIV lang=en-us dir=ltr align=left>
<HR>
<FONT face=Tahoma size=2><B>From:</B> <A
href="mailto:ofw-bounces@lists.openfabrics.org"
target=_blank>ofw-bounces@lists.openfabrics.org</A> [mailto:<A
href="mailto:ofw-bounces@lists.openfabrics.org"
target=_blank>ofw-bounces@lists.openfabrics.org</A>] <B>On Behalf Of
</B>Deepak Gupta<BR><B>Sent:</B> Tuesday, January 27, 2009 5:19
PM<BR><B>To:</B> <A href="mailto:ofw@lists.openfabrics.org"
target=_blank>ofw@lists.openfabrics.org</A><BR><B>Subject:</B> ***SPAM***
Re: [ofw] Expose a vendor defined device in ibbus?<BR></FONT><BR></DIV>
<DIV>
<DIV></DIV>
<DIV class=Wj3C7c>
<DIV></DIV><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial
color=#0000ff size=2></FONT><BR>Since I didn't receive any concrete
response from the list about the patch, I still have following questions
unanswered:--<BR><BR>1) I would like to know who is current owner of ibiou
and get a feedback on whether above patch is acceptable.<BR>Or Do you
suggest some modifications on it ?<BR><BR>2) If we are ok with this patch
then what time frame should we set for it. Should we target it for coming
2.1 release or for post 2.1 releases?<BR><BR>3) Also, I want to move ahead
for implementing IOCTL layer in ibiou for creation of child devices and
IOC listings on user request. Is it acceptable to implement this IOCTL
layer for device creations and IOC listings in ibiou and you suggest to
achieve the same through some other means?<BR><BR><BR><B>I want to
reiterate the purpose of this patch:--</B><BR><BR>This patch is for
creating multiple PDO's for a HCA to IOC path as configured by the user in
INF file.<BR>It will help in having multiple sessions with the IOC and
hence will give some user configurations for fail over.<BR><BR><B>Behavior
change from current ibiou implementation:--</B><BR><BR>Currently ibiou
simply discovers the IOCs and creates child devices for the IOCs
discovered.<BR>This patch will create multiple child devices for HCA to
IOC paths as configured by the user in INF file.<BR>If there are no child
device configurations for a particular IOC then no devices will be created
for that IOC and hence will not appear in device manager's device
tree.<BR><BR>This is just a first draft patch to show the usability and we
have plans to implement IOCTLs in ibiou for child device creations and for
listing the reachable IOC PATHs so that a user application can be written
which can list the IOCs and local HCAs to the user and user can send
IOCTLs to create devices for the
ULPs.<BR><BR><BR>Regards<BR>Deepak<BR><BR><BR><BR><BR>
<DIV class=gmail_quote>On Tue, Jan 27, 2009 at 7:09 PM, Deepak Gupta <SPAN
dir=ltr><<A href="mailto:deepak.gupta@qlogic.com"
target=_blank>deepak.gupta@qlogic.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Forgot
to include the list.<BR><BR>Regards<BR><FONT
color=#888888>Deepak<BR><BR></FONT>
<DIV class=gmail_quote>
<DIV>---------- Forwarded message ----------<BR>From: <B
class=gmail_sendername>Deepak Gupta</B> <SPAN dir=ltr><<A
href="mailto:deepak.gupta@qlogic.com"
target=_blank>deepak.gupta@qlogic.com</A>></SPAN><BR>Date: Sat, Jan
24, 2009 at 5:07 PM<BR>Subject: Re: [ofw] Expose a vendor defined device
in ibbus?<BR></DIV>
<DIV>
<DIV></DIV>
<DIV>To: Fab Tillier <<A href="mailto:ftillier@windows.microsoft.com"
target=_blank>ftillier@windows.microsoft.com</A>><BR><BR><BR>Fab,
Nice to see your response.<BR>Please see below.<BR><BR>
<DIV class=gmail_quote>
<DIV>On Fri, Jan 23, 2009 at 11:09 PM, Fab Tillier <SPAN dir=ltr><<A
href="mailto:ftillier@windows.microsoft.com"
target=_blank>ftillier@windows.microsoft.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV lang=EN-US link="blue" vlink="purple">
<DIV>
<P><SPAN style="FONT-SIZE: 11pt; COLOR: rgb(31,73,125)">I don't have
time to look at this in depth, but I can tell you from past experience
that having a single PDO for an IOC leads to trouble if you ever have
multiple HCAs in the system. If you have a miniport driver (like
NDIS or StorPort), the port driver takes care of DMA mappings of
user-provided buffers. That DMA mapping goes down to the PCI
driver for the particular HCA, so you could potentially have a mapping
that isn't valid for one of the multiple HCAs in the system.
It's best IMO to have a PDO per IOC per HCA (this allows automatic
path migration to work in multi-port HCAs), and push failover between
IOCs to a higher level
(LBFO/MPIO).</SPAN></P></DIV></DIV></BLOCKQUOTE></DIV>
<DIV><BR>I had the same concern while implementing the patch.<BR>So I
tried to dig into the stack till h/w drivers and it came to me that all
DMA mappings are being<BR>handled by PCI driver.<BR>So this patch
creates PDO's per IOC per HCA. <BR>User can specify the child device
descriptions in INF file (later on we can think of having a IOCTL
interface in ibiou) and HCA to IOC path.<BR>ibiou will create child
PDO's only if HCA to IOC path is present.<BR><BR>Any more suggestions
are welcome!!!<BR><BR>Regards<BR><FONT
color=#888888>Deepak<BR> <BR></FONT></DIV>
<DIV>
<DIV></DIV>
<DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV lang=EN-US link="blue" vlink="purple">
<DIV>
<P><SPAN style="FONT-SIZE: 11pt; COLOR: rgb(31,73,125)"></SPAN></P>
<P><SPAN
style="FONT-SIZE: 11pt; COLOR: rgb(31,73,125)"></SPAN> </P>
<P><SPAN
style="FONT-SIZE: 11pt; COLOR: rgb(31,73,125)">-Fab</SPAN></P>
<P><SPAN
style="FONT-SIZE: 11pt; COLOR: rgb(31,73,125)"></SPAN> </P>
<DIV
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<DIV>
<DIV
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: rgb(181,196,223) 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P><B><SPAN style="FONT-SIZE: 10pt">From:</SPAN></B><SPAN
style="FONT-SIZE: 10pt"> <A href="mailto:mailmeatdkg@gmail.com"
target=_blank>mailmeatdkg@gmail.com</A> [mailto:<A
href="mailto:mailmeatdkg@gmail.com"
target=_blank>mailmeatdkg@gmail.com</A>] <B>On Behalf Of </B>Deepak
Gupta<BR><B>Sent:</B> Friday, January 23, 2009 6:41 AM<BR><B>To:</B>
James Yang<BR><B>Cc:</B> Leonid Keller; Fab Tillier; <A
href="mailto:ofw@lists.openfabrics.org"
target=_blank>ofw@lists.openfabrics.org</A>
<DIV>
<DIV></DIV>
<DIV><BR><B>Subject:</B> Re: [ofw] Expose a vendor defined device in
ibbus?</DIV></DIV></SPAN>
<P></P>
<P></P></DIV></DIV>
<DIV>
<DIV></DIV>
<DIV>
<P> </P>
<P style="MARGIN-BOTTOM: 12pt">Did any one get the chance to have a
look at the patch?<BR><BR>I am really concerned with the tight
coupling of representing each single IOC as a single
PDO.<BR><BR>Regards<BR>Deepak<BR><BR><BR></P>
<DIV>
<P>On Wed, Jan 21, 2009 at 5:55 PM, Deepak Gupta <<A
href="mailto:deepak.gupta@qlogic.com"
target=_blank>deepak.gupta@qlogic.com</A>> wrote:</P>
<P style="MARGIN-BOTTOM: 12pt">All,<BR><BR>Based on James patch of
creating user defined devices tied to local HCA ports, I have created
a first draft patch attached herewith <BR>to allow "ibiou" to create
user defined devices which will associate with IOC paths.<BR><BR>This
patch does the following:-<BR><BR>Now ibiou will not create child
devices on it's own when it discovers a IOC.<BR>Instead it will create
child devices only when it is instructed to do so.<BR>For the sake of
this patch, currently it uses name/description of the devices hard
coded into INF file of ibiou driver.<BR>Later on we can implement a
IOCTL to pass this information to the driver (more below)<BR><BR>It
will make a listing of devices to be created in it's DriverEntry
routine.<BR>When it will get IOC_PNP_ADD pnp events, it will check in
device list prepare<BR>earlier. If it finds device(s) in it's list
which corresponds to the new IOC<BR>discovered then it will create
those child devices and a similar mechanism<BR>will happen when ibiou
will get IOC_PNP_ADD event.<BR><BR>This more of a initial patch for
giving an insight into what we want to achieve.<BR>On a longer run we
are thinking of providing a IOCTL support in ibiou driver for creating
child devices (like vnic/srp/etc) and<BR>differnet vendor specific
applications can create those devices and have their driver loaded on
top of that.<BR><BR>Following is the advantage of this
functionality:-<BR><BR> Earlier there was only one device
created per IOC on host side.<BR> Now there can be
multiple devices on host side per IOC as configured in the
registry.<BR> It will be many to one function i.e there
can be many devices on host side which will target to the same
IOC.<BR> It will be like having different sessions with
the same IOC.<BR><BR>Please have a look at it and let me know of your
comments/suggestions/feeback.<BR><BR>NOTE--> Device descriptions in
the INF file of this patch creates devices that corresponds to a IOC
PATH (CAGUID and
IOCGUID).<BR> Those values
are local to my machine and you should change it according to your
fabric.<BR><BR>Regards<BR><SPAN
style="COLOR: rgb(136,136,136)">Deepak<BR><BR><BR></SPAN></P>
<DIV>
<DIV>
<DIV>
<P>On Tue, Jan 20, 2009 at 1:37 AM, James Yang <<A
href="mailto:jyang@xsigo.com" target=_blank>jyang@xsigo.com</A>>
wrote:</P></DIV></DIV>
<BLOCKQUOTE
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 6pt; PADDING-BOTTOM: 0in; MARGIN-LEFT: 4.8pt; BORDER-LEFT: 1pt solid; MARGIN-RIGHT: 0in; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<DIV>
<DIV>
<DIV>
<DIV>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy">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.</SPAN></P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy"></SPAN> </P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy">Thanks,</SPAN></P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy">James</SPAN></P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy"></SPAN> </P>
<DIV>
<DIV style="TEXT-ALIGN: center" align=center>
<HR align=center width="100%" SIZE=2>
</DIV>
<P><B><SPAN style="FONT-SIZE: 10pt">From:</SPAN></B><SPAN
style="FONT-SIZE: 10pt"> Leonid Keller [mailto:<A
href="mailto:leonid@mellanox.co.il"
target=_blank>leonid@mellanox.co.il</A>] <BR><B>Sent:</B> Sunday,
January 18, 2009 5:57 AM<BR><B>To:</B> James Yang; Deepak Gupta; Fab
Tillier</SPAN></P>
<DIV>
<DIV>
<P><SPAN style="FONT-SIZE: 10pt"><BR><B>Cc:</B> <A
href="mailto:ofw@lists.openfabrics.org"
target=_blank>ofw@lists.openfabrics.org</A><BR><B>Subject:</B> RE:
[ofw] Expose a vendor defined device in
ibbus?</SPAN></P></DIV></DIV></DIV>
<DIV>
<DIV>
<P> </P>
<DIV>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: blue">After first look: why
did you put the list of the created devices into Globals (and not,
say, FDO) ?</SPAN></P></DIV>
<DIV>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: blue">How it will work for
multi-home machine ? (several HCA cards)</SPAN></P></DIV>
<DIV>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: blue">Would anybode like to
check it for various partition keys ?</SPAN></P></DIV>
<BLOCKQUOTE
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt 3.75pt; BORDER-LEFT: 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<P> </P>
<DIV style="TEXT-ALIGN: center" align=center>
<HR align=center width="100%" SIZE=2>
</DIV>
<P style="MARGIN-BOTTOM: 12pt"><B><SPAN
style="FONT-SIZE: 10pt">From:</SPAN></B><SPAN
style="FONT-SIZE: 10pt"> <A
href="mailto:ofw-bounces@lists.openfabrics.org"
target=_blank>ofw-bounces@lists.openfabrics.org</A> [mailto:<A
href="mailto:ofw-bounces@lists.openfabrics.org"
target=_blank>ofw-bounces@lists.openfabrics.org</A>] <B>On Behalf
Of </B>James Yang<BR><B>Sent:</B> Tuesday, January 06, 2009 10:11
PM<BR><B>To:</B> Deepak Gupta; Fab Tillier<BR><B>Cc:</B> <A
href="mailto:ofw@lists.openfabrics.org"
target=_blank>ofw@lists.openfabrics.org</A><BR><B>Subject:</B> RE:
[ofw] Expose a vendor defined device in ibbus?</SPAN></P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy">Hi,</SPAN></P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy"></SPAN> </P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy">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.</SPAN></P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy"></SPAN> </P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy">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.</SPAN></P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy"></SPAN> </P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy">Thanks,</SPAN></P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy">James</SPAN></P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy"></SPAN> </P>
<P><SPAN style="FONT-SIZE: 10pt; COLOR: navy"></SPAN> </P>
<DIV>
<DIV style="TEXT-ALIGN: center" align=center>
<HR align=center width="100%" SIZE=2>
</DIV>
<P><B><SPAN style="FONT-SIZE: 10pt">From:</SPAN></B><SPAN
style="FONT-SIZE: 10pt"> <A href="mailto:mailmeatdkg@gmail.com"
target=_blank>mailmeatdkg@gmail.com</A> [mailto:<A
href="mailto:mailmeatdkg@gmail.com"
target=_blank>mailmeatdkg@gmail.com</A>] <B>On Behalf Of
</B>Deepak Gupta<BR><B>Sent:</B> Monday, January 05, 2009 10:51
PM<BR><B>To:</B> Fab Tillier<BR><B>Cc:</B> Tzachi Dar; James Yang;
<A href="mailto:ofw@lists.openfabrics.org"
target=_blank>ofw@lists.openfabrics.org</A><BR><B>Subject:</B> Re:
[ofw] Expose a vendor defined device in ibbus?</SPAN></P></DIV>
<P> </P>
<P style="MARGIN-BOTTOM: 12pt">Have a gr8 New Year to all the
members!!!.<BR><BR>Do you we any updates on "vendor defined device
in ibbus"?<BR><BR>I wanted to create multiple vnic interfaces
irrespective of number of reachable IOCs.<BR><BR>Currently I am
creating vnic child devices on "root" bus.<BR>Inside VNIC driver,
I am looking for arrival GUID_IB_AL_INTERFACE and hence contacting
the IBAL.<BR>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.<BR><BR>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.<BR><BR>Can any one please comment on
this.<BR><BR>Regards<BR>Deepak</P>
<DIV>
<P>On Mon, Dec 22, 2008 at 1:12 PM, Deepak Gupta <<A
href="mailto:deepak.gupta@qlogic.com"
target=_blank>deepak.gupta@qlogic.com</A>> wrote:</P>
<P>All,<BR><BR>I came across one more question in my mind which
are I think is not clear to me after reading the whole
thread.<BR><BR>In new design being discussed:- <BR>Are we making
sure that we can have more than one child devices configured for
the same IOC.<BR>Currently, there is one child device created per
IOC discovered.<BR><BR>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.<BR>Consider a
case in which a host is connected to a single IOC and IOC is
connected to a ethernet network via switch.<BR>If there are two
different IP subnets then there is a requirement of two different
Ethernet interfaces on the host side too.<BR><BR>Please let me
know if you need more clarification of my
question.<BR><BR>Regards<BR><SPAN
style="COLOR: rgb(136,136,136)">Deepak</SPAN></P>
<DIV>
<DIV>
<P style="MARGIN-BOTTOM: 12pt"> </P>
<DIV>
<P>On Sat, Dec 20, 2008 at 2:19 PM, Deepak Gupta <<A
href="mailto:deepak.gupta@qlogic.com"
target=_blank>deepak.gupta@qlogic.com</A>> wrote:</P>
<P style="MARGIN-BOTTOM: 12pt">Please see
below.<BR><BR>Regards<BR>Deepak</P>
<DIV>
<DIV>
<DIV>
<P>On Sat, Dec 20, 2008 at 12:42 AM, Fab Tillier <<A
href="mailto:ftillier@windows.microsoft.com"
target=_blank>ftillier@windows.microsoft.com</A>> wrote:</P>
<DIV>
<P>> On Wed, Dec 17, 2008 at 11:43 PM, Fab Tillier<BR>>
<<A href="mailto:ftillier@windows.microsoft.com"
target=_blank>ftillier@windows.microsoft.com</A>>
wrote:</P></DIV>
<DIV>
<P style="MARGIN-BOTTOM: 12pt">>> Are there other properties
that I have missed that are needed?<BR>><BR>> We need a way
in which devices created should be configured for<BR>>
failovers ( ULPs like VNIC, SRP need more configurable
failovers).<BR>> Looking at IBAL's code it create the devices
based on the reachable<BR>> IOC's and thus failover's are
possible across the HCA/ports and not<BR>> across two different
IOCs.<BR>> Users can have a case in which two different IOCs
connected to same<BR>> physical network/storage (redundancy is
provided for high availability)<BR>> and want a failover across
the IOCs.</P></DIV>
<P>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.</P></DIV></DIV>
<DIV>
<P><BR>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.<BR> </P></DIV>
<BLOCKQUOTE
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 6pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt 4.8pt; BORDER-LEFT: 1pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<P><BR><SPAN
style="COLOR: rgb(136,136,136)"><BR>-Fab</SPAN></P></BLOCKQUOTE></DIV>
<P> </P></DIV>
<P> </P></DIV></DIV></DIV>
<P> </P></BLOCKQUOTE></DIV></DIV></DIV></DIV>
<P> </P></DIV></DIV>
<DIV>
<P>_______________________________________________<BR>ofw mailing
list<BR><A href="mailto:ofw@lists.openfabrics.org"
target=_blank>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></P></DIV></BLOCKQUOTE></DIV>
<P> </P></DIV>
<P> </P></DIV></DIV></DIV></DIV></DIV><BR>_______________________________________________<BR>ofw
mailing list<BR><A href="mailto:ofw@lists.openfabrics.org"
target=_blank>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></BLOCKQUOTE></DIV></DIV></DIV><BR></DIV></DIV></DIV><BR></BLOCKQUOTE></DIV><BR></DIV></DIV></BLOCKQUOTE></DIV><BR>_______________________________________________<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></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML>