[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