[SR-Users] Simulating kamailio config flows

[Daniel-Constantin Mierla]

On 5/23/13 10:45 PM, Victor Seva wrote:
> 2013/5/23 Daniel-Constantin Mierla <miconda at gmail.com>:
>> First a general recommendation: try to avoid patching core that much for
>> non-common use cases.
> Sure. I was just trying to see how this could be done. I don't want to
> mess with the core. :-)
>
> [snip]
>
>> At this moment, I think a good solution could be:
> [snip]
>> - update the interpreter to use pv cache instead of own spec per pv (I can
>> do it, being in my list and hopefully is no big change)
> I will try to do it myself just to get familliar with this area. Let's
> see how it goes.
>
>> - if this feature is enabled in debugger module, it will create a hash table
>> where to index pv set functions by pointer and point to the cache item
>> - this index has to be created in child_init with rank PROC_INIT to be sure
>> all pvs were resolved to cache item
> Sorry. But I don't get this. Can you, please, explain me the rationale
> behind this hash table?.
First about the pv_cache - it is a hash table with specs of pvs used in 
config file. Not all pvs are using the cache yet, but should be migrate 
to it. The nebefit is that if a same pv is used more than one, only one 
spec is stored in cache. For example, if there will be no pv cache used, 
if you have 10 of $ru, used memory is 20*sizeof(pv_spec). If pv cache 
will be used everywhere, the will be one pv_spec and 10 pointers to it. 
Because the size of pvspec is much larger than pointer size, it 
obviously results in lower memory usage. More that that, if one needs to 
parse a pv name at runtime, will not allocate memory each time, but only 
first time when added to cache, avoiding memory leak because some 
pv_spec have dynamic structure and no free function.

The pv_cache contains items of:

{
   pvname
   pvspec
   ...
}

A lookup by pvname in pv_cache returns the address of pvspec in the 
above structure.

If the config interpreter uses pv_cache, you get access to pointer of 
pvspec field. You can use structure offset to get the start of the item 
and from there pvname, but because cache is not used name, what you get 
from config interpreter can be a standalone pointer and will result in 
segmentation fault.

You can lookup the pointer in the pv_cache, by iterating through all 
slots until a match. Could be good/fast enough for debugging. I was 
thinking of using a hash table to index needed pv_cache items.

A virtual example of config:

$x1 = $x2 + $x3 + $x4;
xlog("$x5 $x6 $x7");
$x8 = $x1 + $x9;
$x1 = $x10 + $x11 + $x4;

The pv cache will have 11 items, but you need to know only the name of 
two pvs: $x1 and $x2, because the others are not assigned. To speed up, 
you look first for the pointer to $x1 on debugger hash table, it is not 
found, iterate in pv cache, find it and store the pointer in debugger 
hash table so next time you need it, you find it quickly.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
   * http://asipto.com/u/katu *