[openib-general] [PATCH 0/6] osm: QoS policy parser

[Yevgeny Kliteynik]

Hi Hal,

Hal Rosenstock wrote:
> Hi Yevgeny,
> 
> On Wed, 2007-01-24 at 19:34, Yevgeny Kliteynik wrote:
>> Hi Hal,
>>
>> Hal Rosenstock wrote:
>>> Hi Yevgeny,
>>>
>>> On Wed, 2007-01-24 at 09:15, Yevgeny Kliteynik wrote:
>>>
>>> [snip...]
>>>
>>>>> I also have some questions about the patches 
>>>> Shoot
>>> First, as I understand it, this higher level QoS is not yet an approved
>>> standard (annex) so is this code experimental? 
>> I guess so
>>
>>> In any case, some things
>>> might change, etc. so IMO this QoS should be implemented in a way that
>>> minimizes the risk to the non QoS code. 
>> Agree
>>
>>> I suspect the main interactions
>>> are in osm_sa_path/multipath_record.c but will also extend to the QoS
>>> manager. So should this all be conditionalized with something like
>>> QOS_ANNEX and by default be off with some build switch to enable this
>>> code in OpenSM until be becomes standard ?
>> I suggest that instead of enclosing the code in ifdef, this new code 
>> will be invoked only when QoS in OpenSM has been turned on.
> 
> Perhaps. I don't see this in the SA PR/MPR patch you supplied though.
> What happens if a QoS request is made and it is not enabled on the SM side ?
> Also, what happens when a QoS request is made but only the previous
> (more primitive) QoS is enabled (not this QoS support) ?

I didn't try it (it's worth trying thought), but I believe that 
SM should do whatever it does right now (bofere QoS) if such
request is made - ignore all the QoS-related part of the query.
SM refers the QoS fields as reserved fields an doesn't do anything
with them.
Am I wrong on this?

>>> When will the remainder of the changes to the QoS manager be ready ? It
>>> would be good to see the whole picture. Are there any other missing
>>> pieces ?
>>  
>> I'm working right now on checking path record for QoS constraints.
>> I'm hoping to finish it in a day or two. After that, I'll do the same 
>> with multipath record.
> 
> Will this take care of the questions asked above ? If so, I guess I'll
> need to wait to see this. 
> 
>>> It would be good to have some documentation for this including an opensm
>>> man page update.
> 
> When do you plan on doing this ? Clearly, this is not as important as
> the work immediately in front of you on this.

I'll work on the documentation as soon as the code is ready.

--Yevgeny
 
>>> As far as using lex/yacc, are they invoked as part of the build
>>> procedure or are the files they generate just checked in and used ?
>> When lex/yacc are invoked, they generate three files: 
>>   - osm_qos_parser_l.c
>>   - osm_qos_parser_y.c
>>   - osm_qos_parser_y.h
>> These generated files should be included in the git repository,
>> and they are the ones that are compiled by 'make' command.
>> To cause lex/yacc generate these files on every compilation, a 
>> configuration flag '--enable-maintainer-mode' should be used when
>> running 'configure'.
>> So normally, lex/yacc won't be invoked during the build (unless the
>> --enable-maintainer-mode option was selected).
> 
>>> How could/would multiple file versions be supported ? One previous
>>> example was a mention that port groups can be shared by more than one
>>> manager (e.g. QoS and partitions) so this might be made hierarchical.
>>> I'd like to understand this before we get locked in.
>> The parser can be enhanced to support different versions of grammar.
>> It will just check the first line of the policy file:
>> 	<?xml version="1.0" encoding="ISO-8859-1"?>
>> and then it will decide which grammar rules to apply according to the 
>> 'version' value.
> 
> Thanks.
> 
> -- Hal
> 
>> --Yevgeny
>>
>>> There are some other lower level questions which I'll get to later. I'll
>>> also review the XML file format in detail later. 
>>>
>>> -- Hal
>>>
>>>
>