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