<!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=998565314-03022009><FONT face=Arial color=#0000ff size=2>This
is what i wanted to hear., thank you. :)</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> Tuesday, February 03, 2009 11:47 AM<BR><B>To:</B> Leonid
Keller<BR><B>Cc:</B> Smith, Stan; 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>Forgive me if I am not following you
correctly.<BR><BR>IIRC, you are talking about "\device\ibal" which is created
whenever first IB device is encountered.<BR><BR>I am not thinking of creating
this new device in AddDevice routine of ibiou.<BR>We will create the device
(let's say \Device\VNICCONFIG) at DriverEntry and is not tied to any instance
of IOU FDO.<BR><BR>We can maintain a global list of all ioc_mgrs, to which we
can reference to obtain the list of all IOCs on each time we get a specific
IOCTL from user space.<BR><BR>Regards<BR>Deepak<BR><BR><BR>
<DIV class=gmail_quote>On Mon, Feb 2, 2009 at 8:46 PM, Leonid Keller <SPAN
dir=ltr><<A href="mailto:leonid@mellanox.co.il"
target=_blank>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>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>What will happen if the
first created device will be disabled by user from Device Manager
?</FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>AFAIR, only the first
device you attach to HCA and maybe, only for the first device create a
name...</FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>We have such kind of
problem with IBAL today. </FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>Only the first instance of
IBAL has its name. So the disabling of the first HCA causes
disappearing of IBAL device and all IB applications stop working
...</FONT></SPAN></DIV><BR>
<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>
<DIV><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></DIV><B>Sent:</B> Friday, January 30, 2009 8:54
AM<BR><B>To:</B> Smith, Stan
<DIV><BR><B>Cc:</B> <A href="mailto:ofw@lists.openfabrics.org"
target=_blank>ofw@lists.openfabrics.org</A><BR></DIV>
<DIV>
<DIV></DIV>
<DIV><B>Subject:</B> ***SPAM*** Re: [ofw] Expose a vendor defined device
in ibbus?<BR></DIV></DIV></FONT><BR></DIV>
<DIV>
<DIV></DIV>
<DIV>
<DIV></DIV>Stan,<BR><BR>Thanks for response.<BR><BR>Yes you are correct,
we will create a named device object with user space visible symbolic link
to it.<BR>We will send IOCTLs to the this device for child device
creations (as configured by user).<BR>As explained in previous mails by
Alex and I, we will need this feature QLogic EVIC to give user a
configuration option.<BR>If there are concerns over user configuration of
SRP PDO's, then we will restrict the implementation to QLogic EVIC's IOC's
only.<BR>And device creations for other ULP's (SRP) will behave as it is
used to behave.<BR><BR>Regards<BR>Deepak<BR><BR><BR>
<DIV class=gmail_quote>On Thu, Jan 29, 2009 at 10:45 PM, Smith, Stan <SPAN
dir=ltr><<A href="mailto:stan.smith@intel.com"
target=_blank>stan.smith@intel.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>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN>Please see inline
comments.</SPAN></FONT></DIV><BR>
<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 7:19
AM<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><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 ?<SPAN><FONT face=Arial
color=#0000ff size=2> </FONT></SPAN></DIV>
<DIV><SPAN></SPAN> </DIV></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>See
trunk\docs\maintainers.txt</FONT> <FONT face=Arial color=#0000ff
size=2>or <A href="http://www.openfabrics.org/downloads/WinOF/README"
target=_blank>http://www.openfabrics.org/downloads/WinOF/README</A></FONT></SPAN>
<DIV><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?<SPAN><FONT face=Arial color=#0000ff
size=2> </FONT></SPAN></DIV></DIV>
<DIV><SPAN></SPAN> </DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>WinOF 2.1 freezes
functionality in April; see <A
href="http://www.openfabrics.org/downloads/WinOF/WinOF_Roadmap.txt"
target=_blank>http://www.openfabrics.org/downloads/WinOF/WinOF_Roadmap.txt</A></FONT></SPAN></DIV></DIV></BLOCKQUOTE>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2><A
href="http://www.openfabrics.org/downloads/WinOF/WinOF_Roadmap.txt"
target=_blank></A></FONT></SPAN>
<DIV><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?<SPAN><FONT face=Arial color=#0000ff
size=2> </FONT></SPAN></DIV></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>By IOCTL layer are you
implying the creation of a user visible device to which a user-app will
open->ioctl-> close?</FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>Said IOC device is
implemented in ibiou.sys driver?</FONT> </SPAN>
<DIV><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.<SPAN><FONT face=Arial
color=#0000ff size=2> </FONT></SPAN></DIV></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>I'm no IOU expert so
please bare with me on this...</FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>Your implication here
is the assumption of prior knowledge of which IOCs will be present
on the fabric.</FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>If I have an OFED
SRP target then I will need a specific entry in the ibiou.inf file
to describe the SRP target?</FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>Seems to be rather
cumbersome. Particularly from a package installation perspective. If a
.msi installer chooses the SRP option, then how does said option get
into the ibiou.inf file? Is the SRP entry always present
in the .inf file?</FONT></SPAN></DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>If the SRP device does
not appear then how will it's device driver be
installed?</FONT></SPAN></DIV>
<DIV><SPAN></SPAN><SPAN><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>How would IPoIB
work?</FONT></SPAN></DIV>
<DIV><SPAN></SPAN> </DIV>
<DIV><SPAN><FONT face=Arial color=#0000ff size=2>All in all, if I
am understanding your design, it sounds like you are defeating
the fabric discovery functionality which I believe to be a very
desirable feature.</FONT> </SPAN>
<DIV>
<DIV></DIV>
<DIV><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></DIV></DIV>
<DIV>
<DIV></DIV>
<DIV>
<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 vlink="purple" link="blue">
<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 vlink="purple" link="blue">
<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>
<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></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><BR></DIV></DIV></BLOCKQUOTE></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><BR></BLOCKQUOTE></BODY></HTML>