> Yes, it's currently copy the logical we are using to branch the
> management, however, if the vendor could provide his own setup code
> here, we don't really need to infer anymore but following the
> indicator from vendor, this 'default' method is for transition.
>
> Sean, could you please give more hint or details on what you'd rather
> like to have? I think I got some misunderstanding on your
> suggestion...
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 */
};
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).
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.
- Sean
N�����r��y����b�X��ǧv�^�){.n�+����{��ٚ�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�m��������zZ+�����ݢj"��!�i
