Kais Belgaied wrote:
>>> - Case boundary question: since this marks a flag day for both TI and
>>> CI, can you list the components
>>> that are affected by this flag day?
>>
>> Most of the IB modules in ON -
>> framework: IBTL
>> IB ULPs (TI): IPonIB, SDP, NFS/RDMA, uDAPL
>> HCA Drivers (CI): Tavor, Hermon
>
> at the risk of re-stating the obvious, all changes in the above 3 sets
> of components are in-scope of this case,
> right?
Yes
>>> - mi_ibt_version seems to be an enumeration of apparently mutually
>>> exclusive values IBTI_V{1,2,3}
>>> yet the definition suggests a combination of independent (discrete)
>>> capabilities
>>> (FMR support, DMA wrapper support, etc.)
>>
>> The features are examples of what was included at each version change.
>> More discussion of the relationship between ABI and features below ...
>>
>>> . Is there any consumer of this interface that uses DMA wapper
>>> but not FMR?
>>
>> Well to be honest FMR in the current form turned out to be a failure.
>> So no one uses FMR in ON right now.
>>
>> But I think more generally what is going to happen is that
>> the features will be used independently of each other,
>> since they are generally not related to each other.
>>
>>
>>> . For future evolution, is the mi_ibt_version always intended to
>>> express a monotonically increasing set
>>> of capabilities (capabs of V(n+1) includes all capabs of N(n)) ?
>>
>> Yes, that is the intent, but it is not guaranteed. However,
>> as you might imagine, it would involve a great deal of
>> discussion/agreement to remove anything and the ARC would be
>> in the loop.
>>
>>
>>> Basically I'm trying to see if information of different nature if
>>> being encoded in the same field. Without slipping
>>> in a design discussion you should consider if two fileds are more
>>> appropriate: 1 version (number or enum) and one capabs (bitmask).
>>
>> There are in fact capability bitmasks elsewhere.
>> In IB there are a number of optional features. So the bitmasks
>> generally are for saying you have these optional features.
>>
>> But the version number is more an ABI thing, and it is mistake
>> to conflate the too, though the reason we have to change ABI
>> is that new features demand more fields in the structs, etc.
>
> so are you fixing the mistake of conflating the capabs + version ? I
> still see the updated material unchanged
> on that.
I think it's a mistake in *understanding* to not distinguish API
from ABI. I am trying to clarify that.
I don't think it is a mistake in the design.
I am also not sure where this is leading.
Are you suggesting some specific change to the case?
-ted
--
Ted H. Kim
Sun Microsystems, Inc. ted.kim at sun.com
222 North Sepulveda Blvd., 10th Floor (310) 341-1116
El Segundo, CA 90245 (310) 341-1120 FAX
