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 > > > > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
