On 3/4/2015 11:41 AM, Weiny, Ira wrote: >> >>> InfiniBand InfiniBand InfiniBand Verbs >>> iWARP InfiniBand iWARP Verbs (subset of IBV, with >>> specific connection establishment >>> requirements that don't exist with IBV) >>> RoCE Ethernet InfiniBand Verbs (but with different >>> addressing because of the different >>> link layer) >>> OPA OPA InfiniBand Verbs >> >> Verbs is an interface definition to hardware that has been twisted to be a >> software API and extended to expose vendor-specific implementation 'features' >> as extensions. It is not a transport. >> >> The device capability bits seems to have evolved to mean: vendor A >> implemented some random 'feature' in their hardware and wants all >> applications to now check for this 'feature' and change their code to use it. >> Basically, what gets defined as a device cap is rather arbitrary. >> > > This was the point I was trying to make and the reason the OPA MAD support > was implemented as a device capability.
The proposed device capability stands for a change that is way more drastic than just a vendor extension. This is a device running a completely different wire protocol which does not interoperate with the IB device that is impersonating. Also, it does not come under the same jurisdication as IB. It is entirely possible that IBTA could make some change in the future where OPA can no longer masquerade as IB. OPA must also be identifiable by any verbs or management application. To do that, it should be properly represented in node type, transport type, and link layer as all the other RDMA technologies have been regardless of the changes needed. All the other RDMA technologies have gone through this process. -- Hal > Ira > -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
