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

[Leonid Keller]

do_you_want_this_mad() is generally a good way to go.
But it is not, that this patch adds Mellanox vendor-specific
functionality to IBAL, it just fixes the existing one.
And Melanox vendor-specific MADs appear just in two or three lines of
code.
And there is no other vendor-specific MADs.
And when they appear, maybe they can use the same literals.
And this problem has broken the work of our management package, which
was reported by our *current* customer, that needs it to be fixed *now*.

So, I'd prefer Sean first to commit his patch to make the things move
forward.
And, IMO, it should go also to 2.2.

Then, if Sean can see and have time to check that this patch can be
improved by changing the interface and using do_you_want_this_mad()
function, it can be done as a new patch and added to the trunk for 2.3
release.


> -----Original Message-----
> From: Sean Hefty [mailto:sean.hefty at intel.com] 
> Sent: Wednesday, January 20, 2010 4:04 AM
> To: Hefty, Sean; 'Todd Rimmer'; Leonid Keller; Fab Tillier; ofw_list
> Cc: Oren Kladnitsky; Amit Krig; Mohammad Sawalha
> Subject: RE: [ofw] [PATCH] ib/mad: fix routing of vendor mads
> 
> >Always letting the HCA driver process the MADs, similar to the linux 
> >code, makes sense.  But MAD handling in the HCA driver is done 
> >synchronously, and not all calls into the MAD layer are blockable.
> >Probably the best you could do is add a new 'do_you_want_this_mad()'
> >call to ci_interface_t that returned whether the HCA wanted 
> the MAD or 
> >not, but did not process the MAD.
> 
> Both of the HCA drivers contain functionality that looks like 
> it could be extracted out and placed into a 
> do_you_want_this_mad() call.  The functionality could come 
> from the mthca_process_mad() and
> mlx4_ib_process_mad() routines.  I can see what it would take 
> to do this, and remove the local routing determination from ibal.
> 
> Leonid, do you have a preference on which direction you would prefer?
> 
> - Sean
> 
>