[openib-general] tavor quirks etc (opensm compliance etc)

[Yevgeny Kliteynik]

Michael,

Michael S. Tsirkin wrote:
>> The problems i see with the current approach are:
>>
>> 1) there are three patches
> 
> Not really, cma_tavor_quirk.patch is the *only* relevant tavor patch.
> It is not 100% but the only work around for proprietary SMs.
> Fixing the SA is a full solution.  We (Mellanox) will work with SA vendors to
> get this addressed.  But of course this takes time.
> 
>> 2) of them, the cma-tavor-quirk is broken (see *** below) in its design
>> since it assumes the opensm-tavor-quirk and it would not work with 
>> opensm that does not have it nor with 3rd party/commercial SMs which do 
>> not have similar quirk
> 
> cma-tavor-quirk in OFED 1.1 is broken but not by design -
> the patch I posted recently fixes the bug and should work with any compliant SM.
> I did not look at the opensm code specifically, but the
> "15.2.5.16 PATHRECORD" is quite explicit in its requirements:
> 
> MtuSelector 2 432 In a query request:
>                      3-largest MTU available
>                   If MTU is specified (i.e., the ComponentMask bit for
>                   MTU is 1):
>                      0-greater than MTU specified
>                      1-less than MTU specified
>                      2-exactly the MTU specified
> 
> So if e.g. opensm does not comply (e.g. it is not returning a path where one exists)
> we should simply fix it. If there are other broken SMs, we can look at how they
> are broken and how to solve this.
 
OSM implementation in this case matches the IB spec. 
On page 905, table 207, there's an example of such a 
request: 
	Required MTU = 4 (2048)
	Required MTUSelector = 1 ('less-than')
And then it is explained that the required path records
should have MTU of 1024 or lower.

OSM implementation converts these rules to code AS IS.

Now, what you're actually saying, is that the specification
in this case is bad. In our discussion, you said that if
you request MTU of X with MTU selector of 'less-than', you
want to also get any path records that supports MTU greater
than X, because they also support MTUs <= X.
The question is, if your understanding of spec is right, 
what's the point of having 'less-than' selector at all?
I mean, if selector says 'less-than', but you also accept 
MTU that are 'equal' and 'greater-than', then it looks like 
you actually don't care about the MTU, because any MTU would
be OK.

--Yevgeny

>> 3) the ipoib-selector patch (below) in a way assumes the open-sm quirk
>> and hence it was not pushed upstream, and vise-versa an upstream ipoib
>> code is broken with the open-sm running with the quirk!
> 
> All this is incorrect.  ipoib-selector is completely irrelevant to the MTU
> issue - its a strict compliance fix for IPoIB. IPoIB also works fine without
> this patch (with or without tavor quirk activated). It does not depend on any
> specific SM. It is not upstream because of style issues only and due to my lack
> of time to fix it. 
>