> You're right that apps can be coded to other CA types, like RNICs and
> USNICs. However, those are all very different from an IB_CA due to
> limited queue pair types or limited primitives. If OPA had that same
> limitation then I would agree it needs a different node type.
>
> So this will be my litmus test. Currently, an app that supports all of
> the RDMA types looks like this:
>
> if (node_type == RNIC)
> do iwarpy stuff
> else if (node_type == USNIC)
> do USNIC stuff
> else if (node_type == IB_CA)
> do IB verbs stuff
> if (link_layer == Ethernet)
> do RoCE addressing/management
> else
> do IB addressing/management
The node type values were originally defined to align with the IB management NodeInfo structure. AFAICT, there was no intent to associate those values with specific functionality or addressing or verbs support or anything else, really, outside of what IB management needed.
iWarp added a new node type, so that the IB management code could ignore those devices. RoCE basically broke this association by forcing additional checks in the local management code to also check against the link layer. The recent mad capability bits are a superior solution, making the node type obsolete.
At this point, the node type essentially indicates if we start counting ports at a numeric value 0 or 1. The NodeType that an OPA channel adapter will report in a NodeInfo structure will be 1, the same value as if it were an IB channel adapter.
In the end, this argument matters one iota. The kernel code barely relies on the node type, and a user space verbs provider can report whatever value it wants.
- Sean
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
