Hi Eitan, On 10:35 Mon 23 Jul , Eitan Zahavi wrote: > Hi Sasha, > > > On 14:59 Sun 22 Jul , Eitan Zahavi wrote: > > > Hi Sasha > > > > > > Let's assume someone has reset a switch on the fabric. > > > What would cause the SM to re-assign the LFT of that switch? > > > > OpenSM will sweep and drop this switch and when switch will > > back it will be initialized again. But if the reset was too > > fast (relative to discovery), we can be in trouble (and maybe > > not only with LFTs). > > > > > I assumed that there is a mechanism to do that. > > > > Not for "fast" switch reboot. > So we have a problem with these fast resetting devices. > > > > Hmm, I think we could try to detect this case by comparing > > SwitchInfo:LinerFDBTop with current p_sw->max_lid_ho or even > > by seeing that PortInfo:LID is not set. Something like below: > > > I think we should have a predicate that will be used to mark a > port/device as needing a full update.
Agreed, but what is the best criteria? LID == 0 will work in many cases, but LID initialization is not required by spec. The only strong requirement I found is Port State. Another ideas? > Not just LFT but everything (SL2VL, VLArb, LID, PKey ... If a device was > reset then it probably lost everything). Right, all incrementally updated data should be flushed - osm_physp and osm_switch are affected objects. > Another approach is to mark it for the entire fabric. It is too expensive IMO, and not much easier to implement. Sasha > > The original intention of kill -HUP was to force a new heavy sweep and > setup. > I this another signal is acceptible but not required. > > Thanks > > Eitan _______________________________________________ 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
