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

[Hal Rosenstock]

Hi again Yevgeny,

On Thu, 2007-01-25 at 10:37, Yevgeny Kliteynik wrote:
> 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?

I suggest first consulting the QoS Annex to see what it says and use
that for hints about these implementation corner cases.

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

Thanks.

-- Hal

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