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

[Michael S. Tsirkin]

> 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.

> 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. 

-- 
MST