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

Bogdan-Andrei Iancu bogdan at voice-system.ro
Mon Dec 17 16:00:14 UTC 2007


Hi Henning,

yes, this is an idea that was discussed for some time, but without any 
clear results for implementation. It is a bit complex and we need to 
think it over and over to be sure we get it right. Let's not jump into 
action until everything is settled.

Give me couple of days to go over this idea again and to dig for any 
previous notes on this matter.

The first thing we need to clarify is how to pass an unlimited number of 
parameters:
    - via array, like main() does - but it might be too generic for our 
purposes
    - combination of fixed and additional parameters. The function will 
have the 2 fix params and any additional params will be passed as array 
- this will maintain some clarity (we still have the visible 
parameters), but also scalability.

regards,
bogdan

Henning Westerholt wrote:
> 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%)
>
>   




More information about the Devel mailing list