[openib-general] RE: A couple of questions aboutosm_lid_mgr.c::__osm_lid_mgr_set_physp_pi

[Eitan Zahavi]

Hi Hal,

Yes when you change OperationalVLs you can run into situation where the
link will retrain. But this retrain might happen anytime when the
watchdog timer expires. 
Instead of letting it surprises the SM (which thinks the link is armed
or active) - I prefer taking the link down in then to arm and active in
an orderly manner. Another aspect is that the watchdog timer might
expire much later in the bring-up process causing traps to be injected
such that OpenSM will perform extra sweeps which could be avoided.

This "preference" of mine was developed over the bad experience of
trying to rely on the watchdog timer in the past...

EZ

Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Box 586 Yokneam 20692 ISRAEL


> -----Original Message-----
> From: Hal Rosenstock [mailto:halr at voltaire.com]
> Sent: Thursday, December 22, 2005 7:19 AM
> To: Eitan Zahavi
> Cc: openib-general at openib.org; Yael Kalka
> Subject: Re: [openib-general] RE: A couple of questions
> aboutosm_lid_mgr.c::__osm_lid_mgr_set_physp_pi
> 
> On Mon, 2005-12-19 at 06:37, Hal Rosenstock wrote:
> > Hi Eitan,
> >
> > On Sun, 2005-12-18 at 14:20, Eitan Zahavi wrote:
> > > [EZ] Thanks. I have seen the patch. It is fine.
> >
> > Thanks. I just committed it.
> >
> > > > > > Also, why does changing the MTU require that the link be
taken
> > > down ?
> > > >
> > > > > The behavior of the link when a neighbor MTU is changes is not
very
> > > well defined.
> > > > > So the best way to handle that is to force it down.
> > > >
> > > > NeighborMTU is not involved with the link negotiation nor is
there a
> > > > comment in the description like OperationalVLs. What behavior
are you
> > > > referring to ?
> >
> > > [EZ] I actually do not see any spec note about modifying neighbor
MTU
> > > during link up.
> >
> > Yes, that was what I was saying.
> >
> > >  However, I remember we had to add this functionality. I
> > > try to dig this up in the old bit keeper and found the first
occurrence
> > > of the setting of the port down in version 1.7. But the log does
not say
> > > why.
> >
> > Thanks for looking. This seems mysterious to me but I would
hestitate to
> > remove it even though I don't think it should be required or if it
is
> > some spec comment should be made. I would like to close the loop on
this
> > but don't see how.
> 
> In looking at this area some more, is it even required for changing
> OperationalVLs ? The spec component description states "Changing
> OperationalVLs in certain PortStates may cause flow control update
> errors which may initiate Link/Phy retraining." So it sounds like the
> link might retrain (and go down) on its own if needed but the SM
needn't
> take the link down.
> 
> -- Hal