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

[Hal Rosenstock]

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