[ofa-general] [OpenSM][RFC] OpenSM Proposed Perf Manager

[Sasha Khapyorsky]

On 09:55 Mon 14 May     , Ira Weiny wrote:
> > 
> > Instead I would purpose to have a builtin PerfMgr which will be able to
> > pull and store performance related data and then to call "generic" event
> > manager which can process such data. This also will help to have simpler
> > generic API for such event db plugin so other parts of OpenSM will be
> > able to report events using same method(s). What do you think?
> 
> This is a good idea.  I will think about how to make it work.

Thanks.

> <snip>
> 
> > > +
> > > +/**
> > > + * group port counters for ports into the nodes
> > > + */
> > > +typedef struct _osm_pc_node {
> > > +	cl_map_item_t  map_item; /* must be first */
> > > +	uint64_t       node_guid;
> > > +	osm_event_pc_t   *ports;
> > > +	uint8_t        num_ports;
> > > +} osm_pc_node_t;
> > 
> > Is it really needed to keep osm_pc_node_t nodes in separate db (qmap)?
> > Why not to reuse already existed maps in osm_subn_t (we could add
> > 'void *pm_data' or so field to osm_physp_t structure)?
> > 
> 
> I did not want to complicate the SM data structures.  Also these structures
> were part of the plugin. This reference plugin used the compatibility lib qmap
> structures to store the data.  But other plugins may use SQL or other data
> stores.

Right, but plugin can access OpenSM data structures in the same way as
its internal stuff, and just qmaps duplication affects performance.

> I think I agree with Hal that we should keep these data structures
> separate from the SM structures.

[snip..]

> I think one can control these better from the opensm.opts file.
> There seems to be too many options which must be set for this to work correctly
> right now.  Also what would you guys think of having a separate perfmgr config
> file?  I am not sure about that idea.  On one hand it helps to keep the
> opensm.opts file clean but on the other hand it means the user has to deal with
> another config file.  :-/

Probably we need to think about /etc/*/opensm.conf instead of option
cached /var/*/osm/opensm.opts?

> <snip>
> 
> Thanks for the comments.  I will get a framework done for the general event
> plugin...  I do agree that would be better for other types of events.  My
> original idea was to have these events reported to the "perfmgr".  But that is
> somewhat invasive on the perfmgr object.
> 
> I am not sure what the best way to do this is at the moment.  I have cleaned up
> the DB interface quite a bit, including making it more generic.  So I think
> this might fit in nicely.  I can reissue a patch if you would like to see it.
> Or I can just submit the header file to see the interface.

A "header file" way looks fine. Probably we may want to separate PerfMgr
and EventMgr things to be separate patch sets. But it is up to you.

Thanks again for the great work!

Sasha