[sr-dev] git:andrei/raw_sock: core: basic raw socket support functions

[Andrei Pelinescu-Onciul]

On Jun 14, 2010 at 15:08, marius zbihlei <marius.zbihlei at 1and1.ro> wrote:
> Andrei Pelinescu-Onciul wrote:
> >On Jun 14, 2010 at 12:37, marius zbihlei <marius.zbihlei at 1and1.ro> wrote:
> >>Andrei Pelinescu-Onciul wrote:
> >>>Anyway from the coding point of view I'm almost ready, the testing will
> >>>be more difficult.
> >>>
> >>>Andrei
> >>>
> >>Hello Andrei,
> >>
> >>I might help with testing and providing some performance numbers.
> >
> >Thanks a lot!
> >
> >>Unfortunately I only have access to some quad core Xeon servers, not
> >>8 cores.
> >>If the weird UDP behavior appears also on 4 cores(less lock
> >>contention), I can run a test plan.
> >>
> >>My idea is to have several UDP workers (I plan to use 8- this will
> >>allow the kernel to distribute them evenly on all 4 CPUs - as the
> >>machine is idle). I plan to test using other 2-3 machines for
> >>sending SIP messages (using sipp or sipsak). Ser will just send some
> >>replies with some error code. I will measure the  throughput over a
> >>1 minute interval on the ser machine,  with both current UDP sender
> >>and the new UDP over raw sock sender.
> >>
> >>If this is ok then in the afternoon I will bring some results. Any
> >>suggestion regarding the test plan is welcomed.
> >
> >Well, while there is little more to be done, the code is not yet testing
> >ready (a few small things like on-send fragmentation and
> >integration in  ser are still missing). I'll have it ready
> >sometime this week, but I'm
> > not sure I'll have time do it today or tomorrow.
> >
> Hello,
> 
> I want to test using some small sip replies(so I am not sure if
> fragmentation takes part). Of course the fragmentation code should
> also be tested for performance. Ser integration is another issue. Do
> you plan to use a global parameter to switch between normal sendto()
> function and raw sockets ?

Yes, a global param for raw sockets, another for mtu (at least for now)
and in the future an option to use raw sockets also for listening
(they might be usefull for a transparent proxy / load balancer
implementation and who knows, maybe we get a nice surprise testing
 performance with them).

Andrei