[ofa-general] Re: [PATCH 0/2] Opensm support for external routing engines

[Nicolas Morey-Chaisemartin]

Hi Sasha,

Le 18/06/2009 16:36, Sasha Khapyorsky a écrit :
>> It also enables to try a new algorithm on the fly without having to
>> reinstall opensm, which can prove useful on a running cluster.
> 
> Even with your patches you will need to restart OpenSM, so it should not
> be a big deal to build and run OpenSM even on a running cluster
> especially if you are going to experiment with new routing engines.
> Alternatively you can load routing tables from file.

Well at least we wouldn't have to reinstall a new OpenSM (and its dependencies) each time.
Problem is we are experimenting with several algorithms for different topologies and different usages  and we don't necessary want to give them all to the clients at once.
With this plugin API you simply need to override the old lib and restart OpenSM (I guess it can probably be made even more interactive by reloading the plugin without restarting).
Most of our algorithm try to add a "dynamic" behaviour to IB routing so loading a file is definitly not a viable solution.

> 
>> The event-based perfmgr plugin does not make it easy to integrate a new
>> routing algorithm because the list of available routing algorithms is
>> statically declared.
> 
> Eventually it is only link list with names and callbacks. It should be
> easy to add new entry there.
> 
I guess it could be done but are you sure the event plugin is loaded and set up before the routing engine ?
If it is, we could make the routing_engine list a bit more dynamic. However I'm not fully satisfied of the idea of inserting new engines through an "event" plugin.
We could also make this interface a bit more generic and provides the means to add new features around OpenSM more easily.

>> AFAIK, the latest Voltaire UFM also includes or will include proprietary
>> routing algorithms (mesh + fat tree), so it could also be useful for
>> Voltaire.
> 
> I don't know about this, but even if it is so. It is not our charter as
> open source project to care about such practices and they (UFM) will need
> to support their stuff by themselves.
> 

Fair enough but the cost of this plugin is quite low in terms of code quantity, 
so it shouldn't introduce too much trouble maintaning it.
And as Ira, it reduces OpenSM dependencies for external algorithm. 
Some of ours for example  rely on PostgreSQL drivers or libdbi, some own library (which uses libibnetdisc) and much more.

Anyway, this was just a proposal as we thought it might be handful to other people than us. If you think it's not or don't agree with the code, we'll just keep it on our own git branches.

Regards

Nicolas