<!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.6000.16788" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=405435116-29012009>Please 
see inline comments.</SPAN></FONT></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> ofw-bounces@lists.openfabrics.org 
[mailto:ofw-bounces@lists.openfabrics.org] <B>On Behalf Of </B>Deepak 
Gupta<BR><B>Sent:</B> Tuesday, January 27, 2009 7:19 AM<BR><B>To:</B> 
ofw@lists.openfabrics.org<BR><B>Subject:</B> ***SPAM*** Re: [ofw] Expose a 
vendor defined device in ibbus?<BR></FONT><BR></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 
class=405435116-29012009><FONT face=Arial color=#0000ff 
size=2> </FONT></SPAN></DIV>
<DIV><SPAN class=405435116-29012009></SPAN> </DIV>
<DIV><SPAN class=405435116-29012009><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">http://www.openfabrics.org/downloads/WinOF/README</A></FONT></SPAN><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 
class=405435116-29012009><FONT face=Arial color=#0000ff 
size=2> </FONT></SPAN></DIV>
<DIV><SPAN class=405435116-29012009></SPAN> </DIV>
<DIV><SPAN class=405435116-29012009><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">http://www.openfabrics.org/downloads/WinOF/WinOF_Roadmap.txt</A></FONT></SPAN><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 
class=405435116-29012009><FONT face=Arial color=#0000ff 
size=2> </FONT></SPAN></DIV>
<DIV><SPAN class=405435116-29012009><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=405435116-29012009><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 class=405435116-29012009><FONT face=Arial color=#0000ff size=2>Said 
IOC device is implemented in ibiou.sys 
driver?</FONT> </SPAN><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 class=405435116-29012009><FONT face=Arial 
color=#0000ff size=2> </FONT></SPAN></DIV>
<DIV><SPAN class=405435116-29012009><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=405435116-29012009><FONT face=Arial color=#0000ff size=2>I'm no 
IOU expert so please bare with me on this...</FONT></SPAN></DIV>
<DIV><SPAN class=405435116-29012009><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=405435116-29012009><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 class=405435116-29012009><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 class=405435116-29012009><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 class=405435116-29012009><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 class=405435116-29012009></SPAN><SPAN class=405435116-29012009><FONT 
face=Arial color=#0000ff size=2> </FONT></SPAN></DIV>
<DIV><SPAN class=405435116-29012009><FONT face=Arial color=#0000ff size=2>How 
would IPoIB work?</FONT></SPAN></DIV>
<DIV><SPAN class=405435116-29012009></SPAN> </DIV>
<DIV><SPAN class=405435116-29012009><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><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 class=gmail_quote>On Tue, Jan 27, 2009 at 7:09 PM, Deepak Gupta <SPAN 
dir=ltr><<A 
href="mailto:deepak.gupta@qlogic.com">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 class=Ih2E3d>---------- 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 class=Wj3C7c>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></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></BODY></HTML>