[OpenSER-Devel] Request for comment: module interface extension

[Henning Westerholt]

Hello all,

i would like to get your opinion about a planned extension of the module 
interface.

The current interface supports only two module parameter for functions. 
Additional to this limitation its necessary to specify two parameters for the 
function prototypes even if only one parameter is used. It would be great 
from a usability point of view to use more parameters in the config script. 
For example the carrierroute module uses several functions to rewrite a uri, 
that differs only in the used source for prefix matching. It would be nice to 
combine this functions to one. Of course its possible to use some flags to 
achieve this, like the tm module, but this would also add more complexity for 
the users and the programmer. Other functions uses global AVPs to support 
additional input values, but this solutions is also not optimal.


We would suggest a extension to make this interface more flexible, to support 
more module function parameter, and to remove the unnecessary ones too. 
Besides to the modifications in the config parser and the fixup functions the 
only significant change is in action.c. Its necessary to replace the static 
assignment here with a for-loop. We tested the performance impact with a 
small benchmark (details at the end of the mail). The proposed implementation 
is in this case appr. 10% slower for the function call overhead.


The tests were done one an relative old machine. In real-life scenarios the 
server needs to wait for external processes like the DNS resolver or 
databases, and the called function would need to do some real work too. So the 
slowdown as measured in the tests is insignificant in comparison to the other 
delays caused by external influences. The additional flexibility we gain is 
worth the increased overhead. The impact should be also smaller with current 
fast machines and multi-core processors.

If there are no objections against this extension, then we would like to start 
with the implementation in the next days.

Thank you,

Henning Westerholt



Benchmark details:

- 500000 calls from config script, two parameters for the empty (only return) 
  module function used
- all benchmarks run ten times, times are averaged, time measured with the 
  benchmark module

- used version: trunk, rev about 3270 (from 6. dec)

- used hardware: AMD Athlon(TM) XP 3000+, 1036448 kB Mem, Debian etch, idle

- loop without module function calls needs 5218.6 microseconds
- loop with function call, current implementation needs 18307.1 microseconds
  * current implementation without the loop time -> 13088.5 microseconds

- loop with function call proposed implementation needs 19633.6 microseconds
  * proposed implementation with out the loop time -> 14415.0 microseconds

- proposed implementation needs per call 2.65 nanoseconds more (10.1%)

-- 
Henning Westerholt - Development Consumer Products / DSL Core
1&1 Internet AG, Ernst-Frey-Str. 9, 76135 Karlsruhe