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

[Andrei Pelinescu-Onciul]

On Jun 10, 2010 at 10:48, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> 
> 
> Am 08.06.2010 09:09, schrieb Andrei Pelinescu-Onciul:
> >On Jun 08, 2010 at 08:43, Klaus Darilion<klaus.mailinglists at pernau.at>  wrote:
> >>Lovely.
> >>
> >>Do you plan to export this functionality to the script? e.g. if
> >>force_send_socket() does not find the forced UDP socket, it uses a
> >>raw socket?
> >
> >Not exactly, I plan to use it as a replacement for udp sockets (higher
> >performance on send on linux) and in the future for handling icmp.
> >The force_send_socket() stuff it's a good idea.
> 
> I just read about raw sockets (http://sock-raw.org/papers/sock_raw)
> and when sending on raw_sockets, there wont be any fragmentation. So
> that would need to be implemented in sr as well.

Yes, if one sets IP_HDRINCL (which is what I intend to do).

> 
> Is the performance gain really worth the effort? I wonder why
> constructing of IP/UDP headers in sr is faster than having it done
> in the kernel.

It's a workaround for performance/scalability problems on bigger
multi-cpu/cores machines running linux. It has nothing to do with the
construction of the headers, but with locking inside the kernel when
sending on the same udp socket (or raw socket w/o IP_HDRINCL). If you
are trying to send on the same socket in the same time from multiple
cores you'll hit this problem.
Some of us have seen symptoms which I believe are related to this
problem.
On an 8 cpu machine running an older kernel (IIRC 2.6.22),
I got between 18%-28% improvement in _stateless_ forwarding just by
distributing the traffic on 8 different sockets instead of one.
I believe it would be even better with the raw socket support, but we'll
see when the code will be ready for testing.

Note that I'm speaking only of the sending part. The receive part I've
added just for fun (while I am at it I would like to test also receiving
 on raw sockets, although I don't know if it would add any benefits).

> 
> another interesting point is if the raw socket receives the packet
> before or after iptables filtering.

After NF_INET_LOCAL_IN. For sending, after the raw socket send call it would
go through NF_INET_LOCAL_OUT (it's the same as for udp or tcp from the
iptables hooks point of view).


Andrei