Please see my comments below:--<br><br>Regrads<br>Deepak<br><br><div class="gmail_quote">On Fri, Dec 19, 2008 at 7:31 PM, Tzachi Dar <span dir="ltr"><<a href="mailto:tzachid@mellanox.co.il">tzachid@mellanox.co.il</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div><span><font color="#0000ff" face="Arial" size="2">Two
comments:</font></span></div>
<div><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div><span><font color="#0000ff" face="Arial" 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></blockquote><div><br>True, it should be extensible.<br>One more thing I want to add is need for a IOCTL which will notify IBAL to rescan the registry and create/delete required child devices which are not already there in the tree so that we don't need to restart IBAL each time we want to add/remove a child device.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div><span><font color="#0000ff" face="Arial" size="2"></font></span></div>
<div><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div><span><font color="#0000ff" face="Arial" 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><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div><span><font color="#0000ff" face="Arial" size="2">Thanks</font></span></div>
<div><span><font color="#0000ff" face="Arial" size="2">Tzachi</font></span></div><br>
<blockquote style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div dir="ltr" align="left" lang="en-us">
<hr>
<font face="Tahoma" size="2"><b>From:</b> Deepak Gupta
[mailto:<a href="mailto:mailmeatdkg@gmail.com" target="_blank">mailmeatdkg@gmail.com</a>] <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;
<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?<br></font><br></div><div><div></div><div class="Wj3C7c">
<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" target="_blank">ftillier@windows.microsoft.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>> 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="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><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>_______________________________________________<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>
</div></div></blockquote></div><br></div></div></blockquote></div>
</blockquote></div><br>