Re: [PATCH v4 14/19] IB/core: Add IB_DEVICE_OPA_MAD_SUPPORT device cap flag

[Michael Wang <yun.wang-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>]

On 03/23/2015 05:31 PM, Hefty, Sean wrote:
>> [snip]
> To restate my suggesting, I was thinking of defining something like this:
>
> enum {
> 	IB_MGMT_PROTO_SM = (1 << 0),   /* supports IB SMPs */
> 	IB_MGMT_PROTO_SA = (1 << 1),   /* supports IB SA MADs */
> 	IB_MGMT_PROTO_GS = (1 << 2),   /* supports IB GSI MADs (e.g. PM, ...) */
> 	IB_MGMT_PROTO_CM = (1 << 3),   /* IB CM called out separately */
> 	IB_MGMT_PROTO_IW_CM = (1 << 4),/* iWarp CM */
> 	/* OPA can define new values here */
> };
>
> struct ib_port_attr {
> 	...
> 	u32	mgmt_proto;  /* bitmask of supported protocols */
> };

Thanks for the restate, Sean :) seems like your proposal is also to ask 
vendor
setup 'mgmt_proto' during ib_query_port(), correct?

>
> I am not familiar enough with RoCE (IBoE) to know off the top of my head if this breakdown works as I defined it, or if IB_MGMT_PROTO_GS needs to be separated into more mgmt classes.  (Hal or Ira might.)  I separated out the CM class, as the rdma cm has checks where it wants to distinguish between which CM protocol to execute (IB or iWarp).

Maybe we can apply this thought to CM part firstly?
>
> This change would be limited to management checks only.  There may still be places in the code where the link and transport checks would continue to exist.  Again, this is just a suggestion.  Without actually implementing the patch, I don't know if this would simplify things.  The checks in the rdma cm, in particular, are messy.
I think it's time to make a formal patch now and discuss the problem in
a separate thread, I'll still use the mechanism in draft and apply these
flags, let's see if it satisfied peoples ;-)

Regards,
Michael Wang

> - Sean

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html