[SR-Dev] what if ...

[Daniel-Constantin Mierla]

On 05/21/2009 12:10 PM, Jan Janak wrote:
> On 20-05 19:44, Daniel-Constantin Mierla wrote:
>   
>> On 05/20/2009 07:31 PM, Andrei Pelinescu-Onciul wrote:
>>     
>>> On May 20, 2009 at 19:24, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>>>   
>>>       
>>>> Hello,
>>>>
>>>> what would be the drawback of having sip_msg being all the time in 
>>>> shared memory? Would pkg vs shm operations have relevant impact?
>>>>     
>>>>         
>>> Yes.
>>>
>>>   
>>>       
>>>>  From personal observations, most of the requests (over 95%) end in TM 
>>>> module (to absorb retransmission or to forward) where the sip_msg s 
>>>> moved to shm. It would make things simpler for tm callbacks and related 
>>>> routes (no need to move back/forward from/to pkg/shm). Parsing will 
>>>> happen always once, as now cloning to shm in tm discards some parsed 
>>>> headers, which may be needed in failure route or callbacks.
>>>>     
>>>>         
>>> Havin a non-shm copy helps with locking and with moving cache lines
>>> between cpus.
>>>   
>>>       
>> as lot of processing is done with the message in shm anyhow, I tried to 
>> figure out the impact of the rest of processing. So you say that is 
>> better to copy to pkg and re-parse, than working with shm structures.
>>
>> The access is not sync'ed, as there will be same usage - in one process 
>> - just the alloc/free will be different.
>>     
>
> I think it would make sense to make the memory allocator used in parsers
> somehow configurable, so that we can select whether the parsed structure is
> stored in shared or in private memory.
>
> Not only this could save us some memory copying in modules like tm, but we
> could also experiment with using the shared memory directly in some parts of
> the code.
>   
Yes, being configurable will make happy everyone.

Since we are here, couple more thoughts about discussions we had in the 
past on various mailing lists:
- when there are changes in the parsed headers structure, there are 
other parts of code forgotten to be updated, usually TM. I was thinking 
it might worth to change the parsed field from void* to pointer to a 
structure like:
{
void *data;
void free_function(void *data);
void *clone_function(void *date, malloc_function, free_function);
}

Drawback is two more pointers, but if we remove most of "very unused" 
direct header hooks, then we have same spare space...

Advantage will be automatic and easy cloning/freeing.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com/