[ofa-general] Question about perfmgr on OpenSM

[Nicolas Morey-Chaisemartin]

Ira Weiny a écrit :
> On Fri, 16 Jan 2009 13:46:06 +0100
> Nicolas Morey Chaisemartin <nicolas.morey-chaisemartin at ext.bull.net> wrote:
>
>   
>> Hi,
>>
>> I'm working on a perf manager plugin for OpenSM.
>> It will have quite advanced features which will do more than simply 
>> treating received events and extract some informations from OpenSM.
>> I have one question though: how are perf manager plugins managed when 
>> there are multiple OpenSM running on the same subnet?
>> -Is only the one on the MASTER SM started?
>> -Are they all started but only the one on the MASTER SM received events 
>> (counters/trap)
>> -They all start and received events but coming from different par of the 
>> subnet
>>
>>     
>
> I am not quite sure what you are asking.  Do you have multiple OpenSM's running
> on the same subnet perhaps a master and a standby?
>
>   

Yes. For HA reasons, it is necessary for us to have a couple of OpenSM
running on the subnet.
> The plugins are managed via the OpenSM process.  Each OpenSM which is started
> will load the plugins specified in the opensm.conf file.  If those plugins are
> the same and would conflict, due to a common database for example, you will
> have to synchronize them yourself.  Each SM will report events to all
> of it's plugins.
>   
That's what I expected from reading the code. So even in STANDBY mode,
openSM will report all the counters (data, errors,...) ?
Or only traps?
> If you are using the new plugin interface I think the easiest implimentation
> might be to have your plugin query the SM and if it is in standby ignore the
> events being reported.  If the standby becomes master then the plugin could
> "turn itself on".
>
> Is this what you are trying to do?
>
>   
The new plugin interface?
My plugin is based on libopensmskummeeplugin (though only tiny pieces of
the original code remains). However I'm still using providing the same
functions, and have the same overall behaviour.

Bit what I did is basically a state machine where openSM state triggers
state change in my plugin, with some synchronization in the DB to ensure
the former active plugin has stopped working.
However I only use this on one part of my plugin (which is quite
independant from the perf manager and reads data in opensm structs).
For the perf manager part, I wasn't expecting openSM to report the perf
counter when not in master mode (I didn't see anything like this in the
original code from libskummee so I didn't quite think about it before now).
I'll run some tests tomorrow.

>> Due to the data I'm going to use, I need to have only one thread doing 
>> its job at a time.
>> If there is only one plugin running on the Subnet it'll be fine, if 
>> there are several, I'll have to monitor the SM status to ensure only one 
>> of my threads is active.
>>     
>
> I think this is what you will have to do.  The SM does not communicate the
> plugin information to the other SM's on the Subnet.
>
> Hope this helps,
> Ira
>   

A lot. Thanks for the info !

Best Regards

Nicolas