<br><font size=2 face="sans-serif">Hi Hal,</font>
<br>
<br><font size=2 face="sans-serif">I use opensm with a single unmanaged
switch to connect several HCAs. I found that HCAs take much longer time
to get LID from SA after opensm restart without hard reset the switch.
If the switch is hard reset before opensm restart, then HCAs get their
LIDs sooner. I'm wondering if there's minhop table pre-existing in the
switch which will prevent HCAs from regain their LIDs soon. Is there any
option to reset the switch during opensm start?</font>
<br>
<br><font size=2 face="sans-serif">Thanks!</font>
<br><font size=2 face="sans-serif">Yicheng</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Hal Rosenstock"
<hal.rosenstock@gmail.com></b> </font>
<p><font size=1 face="sans-serif">07/10/2008 09:15 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">"Yicheng Jia" <YJia@tmriusa.com></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">"Jim Mott" <jim@mellanox.com>,
general@lists.openfabrics.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [ofa-general] minimum sw components
requirement for driver/opensm in a single unmanaged switch network</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>On Thu, Jul 10, 2008 at 7:39 PM, Yicheng Jia <YJia@tmriusa.com>
wrote:<br>
><br>
>> If you want to avoid all the SM stuff, and are willing to program
the<br>
>> switches directly (a few mads)<br>
><br>
> Is it done by opensm?<br>
<br>
Yes.<br>
<br>
> What information should be set up in the switch by<br>
> opensm?<br>
<br>
Things like the PortInfos and LFT. See IBA spec vol 1 14.2.5<br>
<br>
>> Then to figure out QP connections, you just use a function of
3<br>
>> parameters:<br>
>>  my_qp_num = fn_sqp(my_node, target_node, qp_num)<br>
>>  target_qp_num = fn_tqp(my_node, target_node, qp_num)<br>
>> Where qp_num is a small number between 0 and the maximum number
of QPs you<br>
>> need active between any 2 endpoints.<br>
><br>
> Can the qp_num be manually assigned?<br>
> Does it need opensm be involved?<br>
<br>
SM has nothing to do with QP numbers.<br>
<br>
>> If it works, you are done.  If not, reset, up, wait for him
to connect and<br>
>> send something to you.<br>
><br>
> Is it reliable? I mean the QPs connection will keep alive during the
QPs<br>
> lifecycle?<br>
<br>
For one thing, SM needs to try to keep ports at active.<br>
<br>
-- Hal<br>
<br>
> Best,<br>
> Yicheng<br>
><br>
><br>
><br>
> "Jim Mott" <jim@mellanox.com><br>
><br>
> 07/10/2008 04:17 PM<br>
><br>
> To<br>
> "Yicheng Jia" <YJia@tmriusa.com>, <general@lists.openfabrics.org><br>
> cc<br>
> Subject<br>
> RE: [ofa-general] minimum sw components requirement for driver/opensm
in a<br>
> single unmanaged switch network<br>
><br>
><br>
><br>
><br>
> If you want to avoid all the SM stuff, and are willing to program
the<br>
> switches directly (a few mads), then I've used schemes like:<br>
><br>
> Node LID=base + (switch port * constant) (base=0, constant = 1 works)<br>
><br>
> Then to figure out QP connections, you just use a function of 3 parameters:<br>
>   my_qp_num = fn_sqp(my_node, target_node, qp_num)<br>
>   target_qp_num = fn_tqp(my_node, target_node, qp_num)<br>
> Where qp_num is a small number between 0 and the maximum number of
QPs you<br>
> need active between any 2 endpoints.<br>
><br>
> With the above scheme, you know your node_id (switch port number),
your lid,<br>
> the lid of the target node,  and the QPs on both sides.  From
there on, it<br>
> is clear sailing.  You don't even need to send MADs; just transition
the QP<br>
> up and try and use it.  If it works, you are done.  If not,
reset, up, wait<br>
> for him to connect and send something to you.  A little timer
to make sure<br>
> everybody retries once in awhile and what can go wrong?<br>
><br>
> Jim<br>
> From: general-bounces@lists.openfabrics.org<br>
> [mailto:general-bounces@lists.openfabrics.org] On Behalf Of Yicheng
Jia<br>
> Sent: Thursday, July 10, 2008 2:59 PM<br>
> To: general@lists.openfabrics.org<br>
> Subject: [ofa-general] minimum sw components requirement for driver/opensm<br>
> in a single unmanaged switch network<br>
><br>
><br>
> Hi Folks,<br>
><br>
> I have a IB network which consists of only a single unmanaged switch,
all<br>
> end nodes connecting with the switch only need to do RDMA read/write<br>
> operation with each other. My question is, what are the indispensable<br>
> modules in driver's core and opensm that make the network up and run?<br>
><br>
> I've been using only ib_mad module in driver's core with a managed
switch<br>
> before, and the network works fine. So I assume that only the ib_mad
module<br>
> in driver's core and SM in opensm are mandatory in my network. The
LIDs are<br>
> assigned by them. The SA and CM modules are not useful in my case.
Am I<br>
> right?<br>
><br>
> I need to minimize driver and opensm to fit them in my network, the
HCA<br>
> driver is mthca.<br>
><br>
> Best,<br>
> Yicheng<br>
> _____________________________________________________________________________<br>
> Scanned by IBM Email Security Management Services powered by MessageLabs.<br>
> For more information please visit </font></tt><a href=http://www.ers.ibm.com/><tt><font size=2>http://www.ers.ibm.com<br>
> _____________________________________________________________________________<br>
><br>
> _____________________________________________________________________________<br>
> Scanned by IBM Email Security Management Services powered by MessageLabs.<br>
> For more information please visit </font></tt><a href=http://www.ers.ibm.com/><tt><font size=2>http://www.ers.ibm.com<br>
> _____________________________________________________________________________<br>
><br>
> _____________________________________________________________________________<br>
> Scanned by IBM Email Security Management Services powered by MessageLabs.<br>
> For more information please visit </font></tt><a href=http://www.ers.ibm.com/><tt><font size=2>http://www.ers.ibm.com<br>
> _____________________________________________________________________________<br>
><br>
> _______________________________________________<br>
> general mailing list<br>
> general@lists.openfabrics.org<br>
> </font></tt><a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general"><tt><font size=2>http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general<br>
><br>
> To unsubscribe, please visit<br>
> </font></tt><a href="http://openib.org/mailman/listinfo/openib-general"><tt><font size=2>http://openib.org/mailman/listinfo/openib-general<br>
><br>
<br>
_____________________________________________________________________________<br>
Scanned by IBM Email Security Management Services powered by MessageLabs.
For more information please visit </font></tt><a href=http://www.ers.ibm.com/><tt><font size=2>http://www.ers.ibm.com<br>
_____________________________________________________________________________<br>
</font></tt></a></a></a></a></a></a>
<br>

<BR>
_____________________________________________________________________________<BR>
Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com<BR>
_____________________________________________________________________________<BR>