[openib-general] RE: [PATCH] osm_lid_mgr: handle different MTU

Hal Rosenstock halr at voltaire.com
Sun Mar 12 07:46:50 PST 2006


On Sun, 2006-03-12 at 10:16, Ofer Gigi wrote:
> Hi Hal,
> I retested it with the fix:
> __osm_lid_mgr_set_remote_pi_state_to_init(p_mgr, p_physp);
> 
> and it is OK.
> 
> Please check-in this change.

Thanks. Already done.

-- Hal

> 
> Thanks again!
> Ofer
> 
> -----Original Message-----
> From: Ofer Gigi 
> Sent: Sunday, March 12, 2006 10:02 AM
> To: 'Hal Rosenstock'
> Cc: OPENIB
> Subject: RE: [PATCH] osm_lid_mgr: handle different MTU
> 
> Hi Hal,
> Thanks a lot for your comments.
> It should be as you said:
> __osm_lid_mgr_set_remote_pi_state_to_init(p_mgr, p_physp);
> 
> I will retest it.
> 
> Thanks!
> Ofer
> 
> 
> -----Original Message-----
> From: Hal Rosenstock [mailto:halr at voltaire.com] 
> Sent: Thursday, March 09, 2006 4:36 PM
> To: Ofer Gigi
> Cc: OPENIB
> Subject: Re: [PATCH] osm_link_mgr: handle different MTU
> 
> Hi Ofer,
> 
> On Wed, 2006-03-08 at 11:17, Ofer Gigi wrote:
> > Hi Hal,
> > 
> > There was a bug that in case of a difference between the MTU of two
> ports, only the 
> > port with the higher MTU was set to down. Its remote port was written
> in the DB in ACTIVE
> > state although its real status was INIT. Because of that the SM didn't
> try to lift the remote
> > port to ACTIVE. 
> > The change below fixes this issue.
> 
> Two things (one nit):
> 
> Subject is really osm_lid_mgr rather than osm_link_mgr. Also, see below:
> 
> -- Hal
> 
> > Thanks
> > 
> > Ofer G.
> > 
> > Signed-off-by:  Ofer Gigi <oferg at mellanox.co.il>
> > 
> > Index: osm_lid_mgr.c
> > ===================================================================
> > --- osm_lid_mgr.c	(revision 5628)
> > +++ osm_lid_mgr.c	(working copy)
> > @@ -893,6 +893,21 @@ __osm_lid_mgr_get_port_lid(
> >  }
> >  
> >
> /**********************************************************************
> > + Set to INIT the remote port of the given physical port
> > +
> **********************************************************************/
> > +static void
> > +__osm_lid_mgr_set_remote_pi_state_to_init(
> > +  IN osm_lid_mgr_t *       const p_mgr,
> > +  IN osm_physp_t*          const p_physp)
> > +{
> > +  osm_physp_t *p_rem_port = osm_physp_get_remote(p_physp);
> > +  CL_ASSERT(p_rem_port);
> > +
> > +  ib_port_info_t * p_pi = osm_physp_get_port_info_ptr( p_rem_port );
> > +  ib_port_info_set_port_state( p_pi, IB_LINK_INIT );
> > +}
> > +
> >
> +/**********************************************************************
> >
> **********************************************************************/
> >  static boolean_t
> >  __osm_lid_mgr_set_physp_pi(
> > @@ -1090,10 +1105,6 @@ __osm_lid_mgr_set_physp_pi(
> >        send_set = TRUE;
> >  
> >      /*
> > -      TO DO -
> > -      If the subnet is being reconfigured, should we force the link
> > -      to the INIT state?
> > -
> >        To reset the port state machine we can send PortInfo.State =
> DOWN.
> >        (see: 7.2.7 p161 lines:10-19.)
> >      */
> > @@ -1109,6 +1120,13 @@ __osm_lid_mgr_set_physp_pi(
> >                   op_vls, ib_port_info_get_op_vls(p_old_pi)
> >                   );
> >        }
> > +
> > +      /* 
> > +         we need to make sure the internal DB will follow the fact
> the remote
> > +         port is also going through "down" state into "init"...
> > +      */
> > +      __osm_lid_mgr_set_remote_pi_state_to_init(p_mgr, p_pi);
>                                                           ^^^^^^
>                                         Shouldn't this be p_physp ?
> 
> If so, I've made the change (no need for a new patch) but a need to
> retest.
> 
> -- Hal
> 
> >        ib_port_info_set_port_state( p_pi, IB_LINK_DOWN );
> >        if ( ib_port_info_get_port_state(p_pi) !=
> >             ib_port_info_get_port_state(p_old_pi) )
> > 
> > 




More information about the general mailing list