> But it makes sense to me to use management specific
> fields/attributes/flags for the *management* pieces, rather than using the
> link and/or transport layer protocols as a proxy. Management related code
> should really branch based on that.
As a proposal, we could add a new field to the kernel port attribute structure.
The field would be a bitmask of management capabilities/protocols:
IB_MGMT_PROTO_SM - supports IB SMPs
IB_MGMT_PROTO_SA - supports IB SA MADs
IB_MGMT_PROTO_GS - supports IB GSI MADs (e.g. CM, PM, ...)
IB_MGMT_PROTO_OPA_SM - supports OPA SMPs (or whatever they are called)
IB_MGMT_PROTO_OPA_GS - supports OPA GS MADs (or whatever is supported)
If the *GS flags are not sufficient to distinguish between MADs supported over
IB and RoCE, it can be further divided (i.e. CM, PM, BM, DM, etc.).
This would provide a direct mapping of which management protocols are supported
for a given port, rather than it being inferred by the link/transport fields,
which should really be independent. It would also allow for simple checks by
the core layer.
If we want the code to be more generic, additional field(s) could be added,
such as mad_size, so that any size of management datagram is supported. This
would be used instead of inferring the size based on the supported protocol.
- Sean
N�����r��y����b�X��ǧv�^�){.n�+����{��ٚ�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�m��������zZ+�����ݢj"��!�i
