[PATCH] Receive multiple packets at a time

Etienne Dechamps etienne at edechamps.fr
Wed Dec 2 22:07:41 CET 2015


On 2 December 2015 at 13:20, Samuel Thibault
<samuel.thibault at ens-lyon.org> wrote:
>> > More is yet to come: I'll have a look at extending the tun/tap interface
>> > to send/receive several packets at a time, and then also using sendmmsg
>> > will again improve performance.
>>
>> Last time I checked, the send/recvmmsg() functionality is actually there
>> in the kernel code, but just not exposed to userspace. It would be great
>> to have access to it though.
>
> Well, the tun driver currently expects the writer (for instance) to
> put one packet at a time. If given more than one packet it's not able
> to consume only one packet and let the rest for a further call. But it
> shouldn't be too hard to fix that.

It sounds like you would be interested in section 3.3 "Multiqueue
tuntap interface" of
https://www.kernel.org/doc/Documentation/networking/tuntap.txt

Overall, I find your findings quite interesting. IMHO, the ideal way
to increase raw tinc performance would be to make the most CPU and
system call intensive parts of tinc's TX and RX paths (mostly sockets,
TUN/TAP, and crypto) multi-threaded - that would make it way more
scalable in terms of throughput, and it would also benefit pretty much
any OS (as opposed to making Linux-specific optimizations). However,
that's a much bigger can of worms as the current codebase very
strongly assumes single-threaded operation, so it would likely require
a lot of work.

Another possible avenue for increasing performance would be to make
use of some of the highly optimized ASM versions of ChaCha-Poly1305
(possibly through the use of some crypto library) instead of the
simple C implementation that tinc-1.1 currently uses. According to
benchmark results there is quite a lot to be gained:
http://bench.cr.yp.to/impl-stream/chacha20.html


More information about the tinc-devel mailing list