[ofa-general] [PATCH] ipoib: refresh path when remote lid changes

Hal Rosenstock hal.rosenstock at gmail.com
Fri Jul 31 12:05:07 PDT 2009


On Fri, Jul 31, 2009 at 2:51 PM, Yossi Etigin <yosefe at voltaire.com> wrote:

> On 31/07/09 20:50, Hal Rosenstock wrote:
> >
> >
> > On Fri, Jul 31, 2009 at 12:13 PM, Yossi Etigin <yosefe at voltaire.com
> > <mailto:yosefe at voltaire.com>> wrote:
> >
> >     On 29/07/09 19:35, Hal Rosenstock wrote:
> >     >
> >     >
> >     > On Wed, Jul 29, 2009 at 10:22 AM, Moni Shoua <monis at voltaire.com
> >     <mailto:monis at voltaire.com>
>  >     > <mailto:monis at voltaire.com <mailto:monis at voltaire.com>>> wrote:
> >     >
> >     >     Hal Rosenstock wrote:
> >     >     >
> >     >     >
> >     >     > On Wed, Jul 29, 2009 at 8:16 AM, Moni Shoua
> >     <monis at voltaire.com <mailto:monis at voltaire.com>
> >     >     <mailto:monis at voltaire.com <mailto:monis at voltaire.com>>
> >     >     > <mailto:monis at voltaire.com <mailto:monis at voltaire.com>
> >     <mailto:monis at voltaire.com <mailto:monis at voltaire.com>>>> wrote:
> >     >     >
> >     >     >
> >     >     >     >     > Is the LMC in the above from the local port ?
> >     >     Unfortunately, LMC
> >     >     >     >     is not
> >     >     >     >     > required to be uniform across the subnet so the
> >     remote
> >     >     >     port's LMC may
> >     >     >     >     > not be the same as that on the local port.
> >     >     >     >
> >     >     >     >     opensm configures the same LMC to all endports
> >     (CA) in the
> >     >     >     fabric so
> >     >     >     >     in which case do you suspect that
> >     >     >     >     it will be different?
> >     >     >     >
> >     >     >     >
> >     >     >     > I wasn't talking about the simplification that OpenSM
> uses
> >     >     but rather
> >     >     >     > what IBA allows. There may be other SMs which do this
> >     or OpenSM
> >     >     >     could be
> >     >     >     > extended (with additional configuration for this).
> >     >     >     >
> >     >     >     > -- Hal
> >     >     >
> >     >     >     So I guess a possible solutions for that is to query each
> >     >     suspected
> >     >     >     node before making a decision to flush it.
> >     >     >     When getting the node info response the true LMC can be
> >     put in the
> >     >     >     LID check function.
> >     >     >
> >     >     >
> >     >     > I'm not following how you are saying to determine the true
> >     LMC (of the
> >     >     > remote port).
> >     >     >
> >     >     Send PortInfo query for that port
> >     >
> >     >
> >     > from the IPoIB client ? I think this ends up needing to contact the
> SA
> >     > to get this info rather than the port directly. Isn't that what
> >     you were
> >     > trying to avoid originally ? If that's the case, one way would've
> been
> >     > if ARPs carried the LMC as well as the LID.
> >     >
> >
> >     What if we query the remote port LMC once, when the path is
> >     resolved, and then
> >     use it to mask the LID until the path is refreshed again?
> >
> >
> > Just like the LID, remote LMC could change.
> >
>
> Yes, but AFAIK the only "bad" case is if the LID stays the same but LMC
> changes to a lower
> value. In this case the path refresh will not happen when it is supposed
> to.


What's the impact of that ?

Also the LID can change at the same time as the LMC.

I can't tell if all the possible cases are handled properly. Are they ?


> If LMC changes to a higher value it might trigger an unneeded path refresh,
> which is not bad because it will refresh the LMC as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20090731/6e916536/attachment.html>


More information about the general mailing list