From: Stephen Hemminger <stephen@networkplumber•org>
To: ValdikSS <iam@valdikss•org.ru>
Cc: Guus Sliepen <guus@tinc-vpn•org>,
Willem de Bruijn <willemdebruijn.kernel@gmail•com>,
David Miller <davem@davemloft•net>,
Tom Herbert <tom@herbertland•com>,
netdev@vger•kernel.org
Subject: Re: Best way to reduce system call overhead for tun device I/O?
Date: Mon, 4 Apr 2016 10:28:45 -0700 [thread overview]
Message-ID: <20160404102845.54ffd20c@xeon-e3> (raw)
In-Reply-To: <57026D91.4090207@valdikss.org.ru>
On Mon, 4 Apr 2016 16:35:13 +0300
ValdikSS <iam@valdikss•org.ru> wrote:
> I'm trying to increase OpenVPN throughput by optimizing tun manipulations, too.
> Right now I have more questions than answers.
>
> I get about 800 Mbit/s speeds via OpenVPN with authentication and encryption disabled on a local machine with OpenVPN server and client running in a different
> network namespaces, which use veth for networking, with 1500 MTU on a TUN interface. This is rather limiting. Low-end devices like SOHO routers could only
> achieve 15-20 Mbit/s via OpenVPN with encryption with a 560 MHz CPU.
> Increasing MTU reduces overhead. You can get > 5GBit/s if you set 16000 MTU on a TUN interface.
> That's not only OpenVPN related. All the tunneling software I tried can't achieve gigabit speeds without encryption on my machine with MTU 1500. Didn't test
> tinc though.
>
> TUN supports various offloading techniques: GSO, TSO, UFO, just as hardware NICs. From what I understand, if we use GSO/GRO for TUN, we would be able to receive
> send small packets combined in a huge one with one send/recv call with MTU 1500 on a TUN interface, and the performance should increase and be just as it now
> with increased MTU. But there is a very little information of how to use offloading with TUN.
> I've found an old example code which creates TUN interface with GSO support (TUN_VNET_HDR), does NAT and echoes TUN data to stdout, and a script to run two
> instances of this software connected with a pipe. But it doesn't work for me, I never see any combined frames (gso_type is always 0 in a virtio_net_hdr header).
> Probably I did something wrong, but I'm not sure what exactly is wrong.
>
> Here's said application: http://ovrload.ru/f/68996_tun.tar.gz
>
> The questions are as follows:
>
> 1. Do I understand correctly that GSO/GRO would have the same effect as increasing MTU on TUN interface?
> 2. How GRO/GSO is different from TSO, UFO?
> 3. Can we get and send combined frames directly from/to NIC with offloading support?
> 4. How to implement GRO/GSO, TSO, UFO? What should be the logic behind it?
>
>
> Any reply is greatly appreciated.
>
> P.S. this could be helpful: https://ldpreload.com/p/tuntap-notes.txt
>
> > I'm trying to reduce system call overhead when reading/writing to/from a
> > tun device in userspace. For sockets, one can use sendmmsg()/recvmmsg(),
> > but a tun fd is not a socket fd, so this doesn't work. I'm see several
> > options to allow userspace to read/write multiple packets with one
> > syscall:
> >
> > - Implement a TX/RX ring buffer that is mmap()ed, like with AF_PACKET
> > sockets.
> >
> > - Implement a ioctl() to emulate sendmmsg()/recvmmsg().
> >
> > - Add a flag that can be set using TUNSETIFF that makes regular
> > read()/write() calls handle multiple packets in one go.
> >
> > - Expose a socket fd to userspace, so regular sendmmsg()/recvmmsg() can
> > be used. There is tun_get_socket() which is used internally in the
> > kernel, but this is not exposed to userspace, and doesn't look trivial
> > to do either.
> >
> > What would be the right way to do this?
> >
> > --
> > Met vriendelijke groet / with kind regards,
> > Guus Sliepen <guus@tinc-vpn•org>
The first step to getting better performance through GRO would be modifying
TUN device to use NAPI when receiving. I tried this once, and it got more complex
than I had patience for because TUN device write is obviously in userspace context.
next prev parent reply other threads:[~2016-04-04 17:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 13:35 Best way to reduce system call overhead for tun device I/O? ValdikSS
2016-04-04 17:28 ` Stephen Hemminger [this message]
[not found] <57026C8F.8050406@valdikss.org.ru>
2016-04-04 14:31 ` Guus Sliepen
-- strict thread matches above, loose matches on Subject: below --
2016-03-29 22:40 Guus Sliepen
2016-03-31 21:18 ` Tom Herbert
2016-03-31 21:20 ` David Miller
2016-03-31 22:28 ` Guus Sliepen
2016-03-31 23:39 ` Stephen Hemminger
2016-04-03 23:03 ` Willem de Bruijn
2016-04-04 14:40 ` Guus Sliepen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160404102845.54ffd20c@xeon-e3 \
--to=stephen@networkplumber$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=guus@tinc-vpn$(echo .)org \
--cc=iam@valdikss$(echo .)org.ru \
--cc=netdev@vger$(echo .)kernel.org \
--cc=tom@herbertland$(echo .)com \
--cc=willemdebruijn.kernel@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox