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(a)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/