At the bottom line, with this device/firmware the problem does not happen,
but there's a possible hole here if the IB spec does not require the SM to
set the client re-register bit each time it discovers a node.
BTW according to IB spec client reregistration support is optional for
IB port (indicated by bit 25 of PortInfo:CapabilityMask).
The multicast code transitions all local multicast groups into an error
state on any of these events: port error, LID change, SM change, or
client reregister. IPoIB responds to these events, plus port active and
pkey change.
From section 7.2 (figure 50) and section 11.6.3.4, we should get a port
error event before a port active event, except in the case of link
active defer. I didn't think it was necessary to transition all
multicast groups into the error state for link active defer. But, do we
need to?
Pkey changes were not handled, to avoid failing unaffected multicast
groups. However, to be safe, we could see what the change was and
generate errors on the affected multicast groups.
Does anyone see any other holes in the multicast group handling?
- Sean
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
