Re: [PATCH 16/20] IB/mad: Add Intel Omni-Path Architecture defines

Hal Rosenstock
2015-01-19T17:24:26Z

On 1/16/2015 2:49 PM, Weiny, Ira wrote:
>> On 1/15/2015 6:30 PM, Weiny, Ira wrote:
>>>>
>>>> On 1/12/2015 12:11 PM, ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
>>>>> From: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>>>>>
>>>>> OPA_MIN_CLASS_VERSION -- OPA Class versions are > 0x80
>>>>> OPA_SMP_CLASS_VERSION -- Defined at 0x80
>> OPA_MGMT_BASE_VERSION --
>>>>> Defined at 0x80
>>>>>
>>>>> Increase max management version to accommodate OPA
>>>>
>>>> Allocation of MAD base and class version numbers is owned by the IBTA.
>>>> It doesn't seem appropriate to arbitrarily claim code points without
>>>> proper approval.
>>>
>>> OPA is its own architecture space. While this space uses some of the
>>> same values as IB we are not claiming any IBTA values.
>>
>> You *are* claiming IBTA values. When the IBTA chooses to use those values,
>> then there will be a conflict.
>
> There is no conflict.
>
> It is true that when the IBTA assigns meaning to those values the code may have to be changed to interpret this new
> meaning. That has to happen regardless of these patches or their meaning on OPA devices.

Currently, these patches are claiming values that are controlled by an
established standards organization. It is the equivalent of just
grabbing a currently unused Ethertype value for a new protocol and then
claiming that whenever the IEEE allocates it for something else you will
make changes to resolve the conflict. There are then a range of kernel
versions which would do the wrong thing with the new IEEE value rather
than indicate that it is not (currently) supported. It's not an
appropriate practice in the design of networking protocols.

-- Hal

> Ira
>
>