> From: Hal Rosenstock [mailto:[EMAIL PROTECTED] > 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 _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general