On 10/15/08 12:07, Ted H. Kim wrote:
> Kais,
>
>
> 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?
>
>
>> - I am not clear on the consumer side of this new interface: What
>> prompts a ULP to start using this interface?
>> Is it expected to attempt ibt_alloc_io_mem() until it exhausts all
>> resources?
>> It would be easier to assess the completeness and the usefulness of
>> the TI if you either extended the case's scope
>> to include at least the changes on one transport consumer or gave a
>> real example thereof.
>
> We are in the process of fixing bugs in certain IB ULPs to
> be good citizens in big SPARC platforms with memory DR where
> we have to be careful about what is in/out of the cage.
> The current plan for ULP usage (i.e. TI usage) is related
> to this motivation.
>
>
>> - 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.
>
>
Kais.
