[openib-general] semantics of process_mad?

[Hal Rosenstock]

On Fri, 2004-09-10 at 16:49, Roland Dreier wrote:
> I'm now looking at implementing the process_mad method:
> 
> 	int	 (*process_mad)(struct ib_device *device,
> 				int process_mad_flags,
> 				struct ib_mad *in_mad,
> 				struct ib_mad *out_mad);
> 
> First of all, it seems that a port_num parameter needs to be added.
Agreed. How did this get missed 'till now ? (That's rhetorical)...

> A QP number parameter might also be good, 
> but maybe we can rely on the
> access layer to ensure that the MAD's class and QP number match
> appropriately.

Are you saying to just make sure SM class is QP0 and all GS classes are
not QP0 (QP1 is insufficient when redirection is supported) ? Because
of redirection, it seems adding QP number as a parameter is a better
solution.

> Finally, what should the return value be?  There are several
> independent things that the process_mad function needs to tell the
> access layer:
> 
>  - Did the operation succeed?
>  - Was the MAD consumed or should it be dispatched to a registered consumer?
>  - Was a reply generated or should no reply be sent?
> 
> In the Topspin drivers, we handled this by returning an enum
> ib_mad_result as below:
> 
> 	enum ib_mad_result {
> 		IB_MAD_RESULT_FAILURE      = 0,        // (!SUCCESS is the important flag)
> 		IB_MAD_RESULT_SUCCESS      = 1 << 0,   // MAD was successfully processed
> 		IB_MAD_RESULT_REPLY        = 1 << 1,   // Reply packet needs to be sent
> 		IB_MAD_RESULT_CONSUMED     = 1 << 2    // Packet consumed: stop processing
> 	};

I think the only difference with OpenIB right now is that a MAD right
now cannot be multiply consumed as it can in the Topspin implementation.

-- Hal