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

[Hal Rosenstock <hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html