[SR-Users] mediaproxy-ng Tutorial
Daniel-Constantin Mierla
miconda at gmail.com
Fri Apr 5 09:53:29 CEST 2013
Hello,
On 4/4/13 9:15 PM, Richard Fuchs wrote:
> Hi,
>
> On 04/04/13 14:58, Daniel-Constantin Mierla wrote:
>
>> quite interesting, I didn't know it has two operations modes: user space
>> forwarding and kernel forwarding.
>>
>> Is there any plan in supporting more one mode (or dropping the other) in
>> the future?
> Not per se, kernel mode forwarding (at least for the primitive case with
> no modifications to the packets) will always be the primary means of
> forwarding packets. At the same time, user-space forwarding will also
> always be available, since at least the first few packets must always be
> processed by the daemon. As such, it doesn't really have two modes of
> operation, it will simply fall back to user-space processing if the
> kernel modules fails to do its job for whatever reason. It's designed to
> use the functionality of the kernel module if possible, but also not to
> rely on it.
She fallback to user space can happen even during a call? Or is just
about when the call is initialized, the application detects is some
problem when setting up forwarding rules in the kernel and goes for user
space.
>
>> Have you done some measurements to see the benefits of
>> kernel forwarding vs user space?
> I can't quote any specific numbers, but we've seen several times in the
> past that the overhead of pushing packets back and forth between kernel
> and user space is quite significant. I suppose I could try to set up
> some simple tests to get some unscientific ballpark numbers if people
> are interested.
Indeed, this is kind of general feeling, at least based on theoretical
aspects, but I haven't seen any kind of numbers just to compare and see
how much is worth to go for kernel forwarding.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -
More information about the sr-users
mailing list