On 10:24 Fri 13 Nov , Eli Dorfman wrote: > On Thu, Nov 12, 2009 at 2:50 PM, Yevgeny Kliteynik > <[email protected]> wrote: > > Eli Dorfman (Voltaire) wrote: > >> > >> Yevgeny Kliteynik wrote: > >>> > >>> Eli Dorfman (Voltaire) wrote: > >>>> > >>>> Yevgeny Kliteynik wrote: > >>>>> > >>>>> Eli Dorfman (Voltaire) wrote: > >>>>>> > >>>>>> Yevgeny Kliteynik wrote: > >>>>>>> > >>>>>>> Eli Dorfman (Voltaire) wrote: > >>>>>>>> > >>>>>>>> Yevgeny Kliteynik wrote: > >>>>>>>>> > >>>>>>>>> Yevgeny Kliteynik wrote: > >>>>>>>>>> > >>>>>>>>>> Line Holen wrote: > >>>>>>>>>>> > >>>>>>>>>>> On 11/ 4/09 04:54 PM, Yevgeny Kliteynik wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Line Holen wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 11/ 4/09 10:47 AM, Yevgeny Kliteynik wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Sasha Khapyorsky wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 12:26 Tue 03 Nov , Yevgeny Kliteynik wrote:
This is a nice and productive discussion. But please remove a context which is not related to the current point - it helps to follow thread. [snip] > >> The PSC bit should be cleared before SM reads the PortInfo from that > >> switch. > > > > This may be true, but do you really want to require > > Set(SwitchInfo) *completion* before getting other PortInfo > > MADs from this switch? > > I don't see any other good alternative and I'm sure this will solve > all race conditions. I agree with Eli - if we want to prevent PSC bit loss (which can be relevant for any subnet/SM topology), we need to clear it first and than to fetch PortInfo. Obviously this may have some performance penalty, but proper discovery is more important. > I suggest that when PSC bit is set in SwitchInfo response we will send > Set(SwitchInfo) to clear the PSC bit and > in SwitchInfo response send Get(PortInfo) - this requires adding > another flag to the mad context. Another flag or reusing one of existing flag. > If PSC bit is not set or SM is not in Master state Get(PortInfo) will > be done in the immediately. > > what do you think? Another potential issue is to avoid a secondary trap triggered sweep for cases when PSC change is already cached. Basically looks like a right direction for me. Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
