[Openib-windows] RE: PNP events

[Fab Tillier]

Plain text damnit.  I am going to stop responding to mails in HTML.  They are a
pain in my ass to deal with.  If you want *me* to respond, you need to be a
little more considerate and not make extra work for me.  Feel free to use HTML
for everyone else, but for me use plain text.  Ignoring this simple request is
just plain rude and inconsiderate.

> -----Original Message-----
> From: Yossi Leybovich [mailto:sleybo at mellanox.co.il]
> Sent: Thursday, August 18, 2005 9:23 AM
> 
> There is massive use of PNP events in all IBAL code.
> Is there reason not to use the IB SPEC asynchronous events for
> port_up/port_down and not special mechanism of PNP events.

The HW doesn't provide detailed port state change events (transitions from INIT
to ARMED to ACTIVE to DOWN).  So IBAL makes up for that by putting all events
into a single PnP class.  The other feature of this is that the PnP callbacks
are invoked at passive levels, allowing clients that normally operate at
dispatch level to execute verb calls from the PnP callback context (e.g. modify
QP to error to flush receives).

Also, when the HCA provides the port UP event, what logical state does that
correspond to?  Is it any transition away from DOWN, or a transition to ACTIVE?
The PRM isn't clear on this.

> Current HW support port up/down events and also client register event .
> Instead of  PNP_PORT_ADD/UP/DOWN/REMOVE events we can use
> IB_AE_PORT_UP/DOWN.....

An application can use these events by simply providing an async event callback
when they open the HCA.  However, if they want to get notification of SM change
(not reregister) or detailed port state changes they will need to also register
for PnP (or does the HCA also generate an event for SM change?).  It's simpler
to just use the PnP notifications as the single source since it provides richer
information (like the port attributes).  If the HCA could provide all the
port-related PnP events, then port PnP could be eliminated.

- Fab