tinc devel - Dec 2015 - [PATCH] Receive multiple packets at a time

Hello,

Dave Taht, on Wed 02 Dec 2015 13:21:56 +0100, wrote:
> I'd made a start on the send direction here:
> https://github.com/dtaht/tinc/commits/master
> 
> Perhaps that will help.
Well, converting a sendto call into a sendmsg call is not really
"hard"
:)

What will be really hard is getting multiple packet receive/send over
the tap/tun device, because support for it has to be added at the kernel
layer first.

At least for now we could commit the recvmmsg part?

Samuel

On Wed, Dec 2, 2015 at 1:36 PM, Samuel Thibault
<samuel.thibault at ens-lyon.org> wrote:
> Hello,
>
> Dave Taht, on Wed 02 Dec 2015 13:21:56 +0100, wrote:
>> I'd made a start on the send direction here:
>> https://github.com/dtaht/tinc/commits/master
>>
>> Perhaps that will help.
>
> Well, converting a sendto call into a sendmsg call is not really
"hard"
> :)
the "hard" bit was in trying to reliably extract the tos bits and then
figure out how to deal with correct ecn encap/decap according to the
rfc - ironically, a year ago today.

http://www.tinc-vpn.org/pipermail/tinc-devel/2014-December/000680.html

but it was only two nights of hacking, then I had to go to something else.

The original observation of mine was that we were bottlenecking on the
tinc output stage, and dropping at the input stage, with about 30ms
latency on the hardware I was trying - where I said AHA! fq_codel in
vpnspace might be useful, might scale better to multiple cores,
even... and then there was another AHA! when I realized the meshy bits
of tinc could be mapped over a received /64 without exposing all that
much over a single flow tinc.... making the vpn bits incur nearly zero
delay for everything but big flows, and holding the delay down...

And after the aha moments, other work took over... getting a generic
userspace fq_codel in C done has been on my todo list for a very long
time (models exist for ns2, ns3 in c++)...

but I'm stuck on finishing up cake, first, and will probably use
something derived from that if I ever (or find someone(s) to
collaborate with) get a userspace inside of vpn thing back on my
plate.
> What will be really hard is getting multiple packet receive/send over
> the tap/tun device, because support for it has to be added at the kernel
> layer first.
I think there was some discussion on the netdev list on improving
tun/vtap, but I am not sure if that directly went anywhere.

More recently Tom Herbert was working on udp encapsulation methods in
the kernel "foo over udp"

https://www.netdev01.org/docs/herbert-UDP-Encapsulation-Linux.pdf

https://lwn.net/Articles/614348/

which preserve things important at high rates like GRO/GSO.
>
> At least for now we could commit the recvmmsg part?
Not my call. It is a linux only thing, so far as I know.
> Samuel
> _______________________________________________
> tinc-devel mailing list
> tinc-devel at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc-devel

Dave Taht, on Wed 02 Dec 2015 14:13:27 +0100, wrote:
> More recently Tom Herbert was working on udp encapsulation methods in
> the kernel "foo over udp"
> 
> https://www.netdev01.org/docs/herbert-UDP-Encapsulation-Linux.pdf
> 
> https://lwn.net/Articles/614348/
> 
> which preserve things important at high rates like GRO/GSO.
Yes, FOU will probably get the highest rates, but it doesn't support
even basic encryption, and is harder to set up for normal people :)
> > At least for now we could commit the recvmmsg part?
> 
> Not my call. It is a linux only thing, so far as I know.
ATM yes.  I wouldn't be surprised that other OSes adopt it, though.

Samuel

Dave Taht, on Wed 02 Dec 2015 14:13:27 +0100, wrote:
> > What will be really hard is getting multiple packet receive/send over
> > the tap/tun device, because support for it has to be added at the
kernel
> > layer first.
> 
> I think there was some discussion on the netdev list on improving
> tun/vtap, but I am not sure if that directly went anywhere.
I see the patches from Alex Gartrell indeed. It seems things didn't go
on.

Samuel