<br><font size=2 face="sans-serif">This is basically the answer why its
so "sensitive" which port is plugged.</font>
<br><font size=2 face="sans-serif">We're working on a solution to that
problem.</font>
<br><font size=2 face="sans-serif">But currently we only see a chance to
change this behaviour by also changing the firmware interface,</font>
<br><font size=2 face="sans-serif">which needs to be coordinated with firmware
development.</font>
<br>
<br><font size=2><tt>Roland Dreier wrote on 10.10.2005 23:44:21:<br>
<br>
> IBMEHCA> So you need some kind of signal from the operating system<br>
> IBMEHCA> to system firmware, which in the eHCA case is the<br>
> IBMEHCA> H_DEFINE_AQP1 triggered by ib_create_qp with IB_QPT_GSI<br>
> IBMEHCA> parameter.  AFTER that call handshaking between system<br>
> IBMEHCA> firmware and the SM will start, here's a new adapter<br>
> IBMEHCA> active on a switch port... what's your guid? here's your<br>
> IBMEHCA> LID, p_key, SM lid....  ...and after all that it's<br>
> IBMEHCA> possible to send and receive packets from the fabric.<br>
> IBMEHCA> The openib stack expects that a port is fully functional<br>
> IBMEHCA> after this create_qp returns, and starts to do all sorts<br>
> IBMEHCA> of modify QP and post send.  So the only choice we
have<br>
> IBMEHCA> there is to delay create_qp until the complete<br>
> IBMEHCA> handshaking between system firmware and the SM has<br>
> IBMEHCA> finished (until we see a IB_PORT_ACTIVE in hcad_mod).
If<br>
> IBMEHCA> we don't see that until EHCA_PORT_ACTIVE_TIMEOUT we have<br>
> IBMEHCA> to return an error code to openib, otherwise we're<br>
> IBMEHCA> seriously in trouble (tried that).</tt></font>
<br><font size=2><tt>> <br>
> I think this scheme breaks the IB model.  When consumers get
access to<br>
> an HCA, they expect to be able to access the HCA, even if an SM has<br>
> not configured it (and even in the case no cable is connected).  As
an<br>
> example of why this is useful, if the link won't come up, it's nice
to<br>
> be able to get to query the port's PMA counters to see if there are<br>
> excessive errors or something like that.<br>
</tt></font>
<br><font size=2><tt>> I understand that you don't want to have all
HCAs always visible to<br>
> the SM, but the scheme you've chosen puts an unneeded dependency<br>
> between driver initialization and the external SM.  It would
be fine<br>
> if creating QP1 triggered the transition of the port from DOWN to
INIT<br>
> so that it is discoverable by the SM, but there's no reason for<br>
> creation of QP1 to wait to finish until the SM has brought the port
up.<br>
</tt></font>
<br><font size=2><tt>> (As a side note, Mellanox HCAs don't bring a
port to INIT until the<br>
> host driver has transitioned QP0 to the RTR state, which seems more<br>
> sensible than waiting for QP1 to be created)<br>
</tt></font>
<br><font size=2><tt>> I hope this can be fixed in firmware with your
current HCA hardware.<br>
</tt></font>
<br><font size=2><tt>> - R.</tt></font>