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

[Hal Rosenstock]

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) ?

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

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