<!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.16587" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=629045913-19122008><FONT face=Arial color=#0000ff size=2>Two
comments:</FONT></SPAN></DIV>
<DIV><SPAN class=629045913-19122008><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=629045913-19122008><FONT face=Arial color=#0000ff size=2>The
format written in the registry should be extensible. That is, each vendor
ULP will be able to add more fields if it needs them. I guess that the format
that Fab has suggested is already such.</FONT></SPAN></DIV>
<DIV><SPAN class=629045913-19122008><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=629045913-19122008><FONT face=Arial color=#0000ff
size=2>Another thing is that ipoib should also work in this method. This means
that the coinstaller that installs the bus filter should also create the needed
registry entries for ipoib.</FONT></SPAN></DIV>
<DIV><SPAN class=629045913-19122008><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=629045913-19122008><FONT face=Arial color=#0000ff
size=2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=629045913-19122008><FONT face=Arial color=#0000ff
size=2>Tzachi</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> Deepak Gupta
[mailto:mailmeatdkg@gmail.com] <BR><B>Sent:</B> Friday, December 19, 2008
12:21 PM<BR><B>To:</B> Fab Tillier<BR><B>Cc:</B> Tzachi Dar; James Yang;
ofw@lists.openfabrics.org<BR><B>Subject:</B> Re: [ofw] Expose a vendor defined
device in ibbus?<BR></FONT><BR></DIV>
<DIV></DIV><BR><BR>
<DIV class=gmail_quote>On Wed, Dec 17, 2008 at 11:43 PM, Fab Tillier <SPAN
dir=ltr><<A
href="mailto:ftillier@windows.microsoft.com">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 class=Ih2E3d>> It seems to me that the best solution for you is to
use a mechanism<BR>> that is close to what the ipoib partition manager
are using. This is a<BR>> mechanism that allows one to add more devices
with a hard coded name<BR>> of IBA\\IPoIBP. So what you should probably
do is to change that<BR>> mechanism to allow it creating devices with
different names.<BR>> Using this you will be able to achieve your goal in
a generic way.<BR><BR></DIV>I think it would be worthwhile at this point to
design a solution that works for both James' issue, IPoIB's partition
support, as well as IOU/IOC devices (to replace IBAL's IOC PnP logic).
Some of this was already discussed either on the mailing list or at
the Sonoma Workshop in the past.<BR><BR>And to be clear, James, the way this
would work from a development perspective is that you would implement the
change and submit patches for discussion, unless you make other
arrangements.<BR><BR>To kick off the discussion, here are my
thoughts:<BR><BR>1. static device creation should be generic enough that it
could be used for all IO Units/IO Controllers. A REG_MULTI_SZ registry
type, filled with strings representing each child device, would do the trick
here. We should discuss what should be in this string. As a
starting point, let me suggest:<BR>- Hardware IDs<BR>- Compatible IDs<BR>-
Name<BR>- Location<BR>- Unique ID of the device -<BR>- Parent ID, which is
either NULL if the parent is the HCA, or the Unique ID of a parent device.
This allows building a hierarchy of devices so that IOC to IOU
relationships can be represented in the device manager.<BR>- Port GUID<BR>-
PKey<BR><BR>For IPoIB this could look something like: "HW_ID:IBA\IPOIB
COMP_ID:NULL NAME:"IPoIB Adapter" LOC:AUTO
UID:IBA\IPOIB\F8F3010000AD0500FFFF PARENT_ID:NULL PORT_GUID:0005AD000001F3F8
PKEY:FFFF"<BR><BR>Are there other properties that I have missed that are
needed?</BLOCKQUOTE>
<DIV><BR>We need a way in which devices created should be configured for
failovers ( ULPs like VNIC, SRP need more configurable failovers).<BR>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.<BR>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.<BR><BR>So I think it would be great to add
path properties (with failover configurations) when devices are
created.<BR>So that ulp drivers can get those path params by issuing a
QUERY_INTERFACE on the child PDOs.<BR><BR></DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR>2.
The IOC PnP manager in IBAL is problematic in large fabrics because it
creates such a high SA traffic load. Sean suggested a while back
having a configuration tool that scans the fabric for IOU/IOC and allows the
user to select the devices which should be reported statically (by writing a
bus driver registry key that the bus driver reads when it loads or is
triggered via an IOCTL). This would allow removing the IOC PnP manager
form IBAL.<BR><FONT color=#888888><BR>-Fab<BR></FONT>
<DIV>
<DIV></DIV>
<DIV class=Wj3C7c>_______________________________________________<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></DIV></DIV></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML>