Leonid Keller wrote: > 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.
Agreed. > > 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. A very reasonable approach. Stan. > > >> -----Original Message----- >> From: Sean Hefty [mailto:[email protected]] >> 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 >> >> > _______________________________________________ > ofw mailing list > [email protected] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
