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

[Michael S. Tsirkin]

Quoting r. Yevgeny Kliteynik <kliteyn at dev.mellanox.co.il>:
Subject: Re: [openib-general] tavor quirks etc (opensm compliance etc)

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

I believe you misrepresent what I am saying.

I understand the spec in the following way:
if I set MTU selector to less than 1K, and there is a path
that can support MTU of 1/2 K, I expect it is legal for SM
to select that path and return it to me, setting
the MTU selector to a value of 1/2K or less.

Whether that path *also* supports higher MTUs need not be relevant -
whether SM will prefer another path in this case is up to SM,
but it is clear that if there are paths that satisfy the request, it does not
make sense to fail the request because paths have more capabilities.
--Yevgeny


-- 
MST