[openib-general] RE: [PATCH] OpenSM - fix osm_vendor_send on vendor mads

[Hal Rosenstock]

On Wed, 2006-04-05 at 08:13, Yael Kalka wrote:
> When we are sending MAD with ManagementClass Vendor, then it isn't
> defined with rmpp head. Thus when looking at the rmpp header we are
> actually looking at part of the mad data.

Right. See subsequent email and proposed patch.

-- Hal

> 
> Yael
> 
> > -----Original Message-----
> > From: Hal Rosenstock [mailto:halr at voltaire.com]
> > Sent: Wednesday, April 05, 2006 2:12 PM
> > To: Yael Kalka
> > Cc: openib-general at openib.org; Eitan Zahavi; Sasha Khapyorsky; Ofer
> Gigi
> > Subject: Re: [PATCH] OpenSM - fix osm_vendor_send on vendor mads
> > 
> > Hi Yael,
> > 
> > On Wed, 2006-04-05 at 04:54, Yael Kalka wrote:
> > > Hi Hal,
> > >
> > > We saw the following problem in the osm_vendor_send mad (in
> > > osm_vendor_ibumad.c). Currently, there is a case on the Management
> > > Class values, where the cases are
> > > IB_MCLASS_SUBN_DIR/IB_MCLASS_SUBN_LID and default, when the
> assumption
> > > is that in the default case the management class is
> > > IB_MCLASS_SUBN_ADM.
> > > So when the libosmvendor is used for sending for example Vendor type
> > > mads, we address it as SA mad, and address the rmpp fields, which
> are
> > > not relevant in this case.
> > > The following patch addes the default as case of IB_MCLASS_SUBN_ADM,
> > > and changes the default case to not to check the rmpp header.
> > > Please apply the patch on both trunk and branch 1.0.
> > 
> > The convention is that the RMPP active flag is off when not sending
> > RMPP. That needs to be conformed to in the GSI classes (consumers of
> > this). Is that the case ?
> > 
> > -- Hal
> > 
> > > Thanks,
> > >
> > > Yael
> > >
> > > Signed-off-by:  Yael Kalka <yael at mellanox.co.il>
> > >
> > > Index: libvendor/osm_vendor_ibumad.c
> > > ===================================================================
> > > --- libvendor/osm_vendor_ibumad.c	(revision 6192)
> > > +++ libvendor/osm_vendor_ibumad.c	(working copy)
> > > @@ -1053,7 +1053,7 @@ osm_vendor_send(
> > >  		umad_set_addr_net(p_vw->umad, p_mad_addr->dest_lid, 0,
> 0, 0);
> > >  		umad_set_grh(p_vw->umad, 0);
> > >  		break;
> > > -	default:	/* GSI		FIXME: no GRH */
> > > +   case IB_MCLASS_SUBN_ADM: /* GSI		FIXME: no GRH */
> > >  		umad_set_addr_net(p_vw->umad, p_mad_addr->dest_lid,
> > >  				  p_mad_addr->addr_type.gsi.remote_qp,
> > >
> p_mad_addr->addr_type.gsi.service_level,
> > > @@ -1087,6 +1087,14 @@ osm_vendor_send(
> > >  		}
> > >  #endif
> > >  		break;
> > > +	default:	/* GSI		FIXME: no GRH */
> > > +		umad_set_addr_net(p_vw->umad, p_mad_addr->dest_lid,
> > > +				  p_mad_addr->addr_type.gsi.remote_qp,
> > > +
> p_mad_addr->addr_type.gsi.service_level,
> > > +				  IB_QP1_WELL_KNOWN_Q_KEY);
> > > +		umad_set_grh(p_vw->umad, 0);	/* FIXME: GRH support */
> > > +		umad_set_pkey(p_vw->umad,
> p_mad_addr->addr_type.gsi.pkey);
> > > +		break;
> > >  	}
> > >
> > >  	if (resp_expected)
> > >