[openib-general] User Level Events - request for support

Fab Tillier ftillier at infiniconsys.com
Tue May 17 10:59:47 PDT 2005


> From: Hal Rosenstock [mailto:halr at voltaire.com]
> Sent: Tuesday, May 17, 2005 10:26 AM
> 
> On Tue, 2005-05-17 at 13:14, Fab Tillier wrote:
> >
> > Just to be clear, you need to trap when the port goes to INIT, not
> > ACTIVE.  Also, while the SM cares about DOWN/INIT, other ULPs tend to
> > care about DOWN/ACTIVE.  I suggest the mechanisms for these events
> > include the port state, and fire for any state change (DOWN, INIT,
ARMED,
> > ACTIVE).
> 
> Are you referring to the link state SM trap which is applicable to
> switch ports ? If so, we are talking about different things. ULP
> handling of these events is separate and the "domain" of the ULP. I was
> referring to the addition of events needed for proper SM operation on
> its own local port, not on other ports in the subnet.

No, I'm referring to local port state.  Maybe the HCA's event notification
isn't quite as sophisticated as I envisioned.  The IB spec defines two
states for the physical link state - UP and DOWN.  For the logical link
state, the IB spec defines DOWN, INIT, ARMED, ACTIVE, and ACTIVE_DEFER.  The
PRM states that the port state change event has a subtype to indicate the
down and active *logical* states only.  If that's the case, how does the SM
detect that the link is connected again, but not configured?   Are there
additional subtypes for the other logical states that the PRM left out?  The
logical state moves from DOWN to INIT by HW when the physical state goes
from DOWN to UP.  Once in INIT, the SM can configure the local port and
start sweeping.  INIT is what the SM cares about - if it waits for ACTIVE,
it will wait until the next sweep since the state change to ARM and ACTIVE
are performed by the SM.

Hopefully that makes more sense.

- Fab




More information about the general mailing list