Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Baptiste Jonglez <baptiste@bitsofnetworks.org>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Performance of Wireguard on Infiniband 40G
Date: Sun, 14 May 2017 00:52:11 +0200	[thread overview]
Message-ID: <CAHmME9pgLtP4z-vvuHxH4ST2f6ZeHhKZXM8FnyrRnxojYDsGGQ@mail.gmail.com> (raw)
In-Reply-To: <20170513073721.GD22218@tuxmachine.polynome.dn42>

Hey Baptiste,

Awesome test! Thanks for reporting the results.

On Sat, May 13, 2017 at 9:37 AM, Baptiste Jonglez
<baptiste@bitsofnetworks.org> wrote:
> Using iperf (TCP mode) over the wireguard interface, performance was
> around 1.6 Gbit/s.  In bidirectional mode (iperf -d), performance was
> 700 Mbit/s + 800 Mbit/s.

Indeed the current multicore algorithm has a lot of issues. Samuel,
CCd, is going to be doing some work on optimizing this algorithm this
summer.

> After raising the MTU of the wireguard interface to 65450, performance
> went up to 7.6 Gbit/s (unidirectional iperf).

It makes sense that it'd be higher, since CPUs work best when running
uninterrupted, but still this indicates that padata is a very
suboptimal algorithm. Expect some improvements on this in the coming
months. Hopefully you'll be able to test on similar hardware at some
point when things are finished.

> Note that infiniband has a MTU of 65520 bytes, but Wireguard still selects
> a MTU of 1420 bytes for its interface.

Yea the 1420 is just a hard coded "default". I probably add something
clever to autoselect an MTU when configuring the first peer's first
endpoint (by computing the route and taking its interface's mtu and
doing subtraction, etc), but the long term solution, I think, will be
to do some more clever PMTU situation from within WireGuard. I'm still
working out exactly how to do this, but it should be possible.


> - Xeon E5520 @2.27GHz (2 CPUs, 4 cores each)
> - Mellanox ConnectX IB 4X QDR MT26428

*drools* That's some awesome hardware!

> - iperf 2.0.5

iperf2 has the -b bidirectional mode which is nice, but it seems like
most people are using iperf3 now. Out of curiosity, is there a reason
for preferring iperf2, beyond the -b switch?

Jason

  reply	other threads:[~2017-05-13 22:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-13  7:37 Baptiste Jonglez
2017-05-13 22:52 ` Jason A. Donenfeld [this message]
2017-05-14  9:55   ` Baptiste Jonglez
2017-05-14 10:48     ` Greg KH
2017-05-14 10:49       ` Jason A. Donenfeld
2017-05-13 23:45 ` Jason A. Donenfeld

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=CAHmME9pgLtP4z-vvuHxH4ST2f6ZeHhKZXM8FnyrRnxojYDsGGQ@mail.gmail.com \
    --to=jason@zx2c4.com \
    --cc=baptiste@bitsofnetworks.org \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).