[ofw] [PATCH] ib/mad: fix routing of vendor mads

[Todd Rimmer]

While this fix will work for now, it seems short sighted and incorrect to enhance the core drivers with vendor specific MAD case statements.  Instead it would seem more appropriate for the HCA driver to register with the core as being interested in the appropriate list of classes.  This way future extensions to any driver or new special MAD processing in drivers can be supported without any core driver enhancements.

An alternative would be to pass all MADs to the driver and allow it to claim those it handles and ignore (with appropriate return code) those which it does not support, hence allowing the core driver to route them as appropriate.

Todd Rimmer
Chief Architect 
QLogic Network Systems Group
Voice: 610-233-4852     Fax: 610-233-4777
Todd.Rimmer at QLogic.com  www.QLogic.com
 

> -----Original Message-----
> From: ofw-bounces at openfabrics.org [mailto:ofw-bounces at openfabrics.org]
> On Behalf Of Sean Hefty
> Sent: Tuesday, January 19, 2010 7:21 PM
> To: 'Leonid Keller'; Fab Tillier; ofw_list
> Cc: Oren Kladnitsky; Amit Krig; Mohammad Sawalha
> Subject: [ofw] [PATCH] ib/mad: fix routing of vendor mads
> 
> SVN commit 2174 introduced an error that resulted in all
> vendor MADs being routed to the local HCA driver.
> 
> This results in the ib-diag vendstat failing to receive
> a response when trying to gather statistics about a remote
> device.
> 
> We should only route vendor mads to the local HCA if the
> mad is one of the mellanox vendor classes, the mad is not
> a response, and the local HCA is the destination for the
> mad.  Simplify both the send and receive processing to
> be consistent in vendor mad handling.
> 
> Problem reported by Mohammad Sawalha.
> 
> Signed-off-by: Sean Hefty <sean.hefty at intel.com>
> ---
> Vendstat to a local and remote lid worked for me with this patch.
> I still need to perform some additional testing, but I think this
> will work.
> 
> SVN 2174 only touched the receive side handling, but this patch
> 'fixes' the send side as well, plus makes the send side handling
> for performance and base management mads similar.
> 
>  trunk/core/al/kernel/al_smi.c |   28 ++++++++++++++++------------
>  1 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/trunk/core/al/kernel/al_smi.c
> b/trunk/core/al/kernel/al_smi.c
> index 7f5abee..5e1c7fa 100644
> --- a/trunk/core/al/kernel/al_smi.c
> +++ b/trunk/core/al/kernel/al_smi.c
> @@ -192,6 +192,10 @@ static mad_route_t
>  route_recv_perf(
>  	IN				ib_mad_element_t*
> 	p_mad_element );
> 
> +static mad_route_t
> +route_recv_vendor(
> +	IN				ib_mad_element_t*
> 	p_mad_element );
> +
>  ib_api_status_t
>  forward_sm_trap(
>  	IN				spl_qp_svc_t*
> 	p_spl_qp_svc,
> @@ -1191,20 +1195,12 @@ route_mad_send(
> 
>  		case IB_MCLASS_PERF:
>  		case IB_MCLASS_BM:
> -			local = ( h_av &&
> +		case IB_MLX_VENDOR_CLASS1:
> +		case IB_MLX_VENDOR_CLASS2:
> +			local = !(p_mad->method & IB_MAD_METHOD_RESP_MASK) &&
> ( h_av &&
>  				( h_av->av_attr.dlid ==
>  				( h_av->av_attr.path_bits | p_spl_qp_svc-
> >base_lid ) ) );
>  			break;
> -
> -		default:
> -			/* Route vendor specific MADs to the HCA provider. */
> -			if( ib_class_is_vendor_specific( p_mad->mgmt_class )
> )
> -			{
> -				local = ( h_av &&
> -					( h_av->av_attr.dlid ==
> -					( h_av->av_attr.path_bits | p_spl_qp_svc-
> >base_lid ) ) );
> -			}
> -			break;
>  		}
>  	}
> 
> @@ -2959,7 +2955,7 @@ process_mad_recv(
> 
>  		case IB_MLX_VENDOR_CLASS1:
>  		case IB_MLX_VENDOR_CLASS2:
> -			route = ROUTE_LOCAL;
> +			route = route_recv_vendor( p_mad_element );
>  			break;
> 
>  		default:
> @@ -3119,6 +3115,14 @@ route_recv_perf(
>  	return ROUTE_DISPATCHER;
>  }
> 
> +static mad_route_t
> +route_recv_vendor(
> +	IN				ib_mad_element_t*
> 	p_mad_element )
> +{
> +	return ( p_mad_element->p_mad_buf->method &
> IB_MAD_METHOD_RESP_MASK ) ?
> +		ROUTE_DISPATCHER : ROUTE_LOCAL;
> +}
> +
>  /*
>   * Forward a locally generated Subnet Management trap.
>   */
> 
> 
> _______________________________________________
> ofw mailing list
> ofw at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw