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