All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: [ANNOUNCE] WireGuard Snapshot `0.0.20180708` Available
Date: Tue, 10 Jul 2018 20:57:29 +0500	[thread overview]
Message-ID: <20180710205729.645bc734@natsu> (raw)
In-Reply-To: <CAHmME9peVZz_x2tQPGng68N1bphyYMHi4FxK9PV4Tt5XRLf4fQ@mail.gmail.com>

On Tue, 10 Jul 2018 16:57:14 +0200
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

> The latest snapshot will still have the same preemption relaxation
> with simd_relax(), but gets performance gains by moving to napi, so
> it's still faster overall. If you want the simd_relax() to not take a
> hit and get maximum throughput, the right way of doing this is
> actually to just disable preemption in your kernel with
> PREEMPT_NONE=y.

I build a single kernel to use across a diverse park of machines, including
servers, routers -- and a few GUI desktops. It is not an option for me to
disable preemption entirely in that kernel. (And it would be a hassle to build
two or more kernels each time).

However those of my hosts which are routers with WG, are NOT the same hosts
which are interactive desktops. So I don't want any sacrifices towards
interactivity *in WG*.

I'll probably test again without simd_relax, but from the past mailing list
discussion it seemed like that one doesn't affect things much. In any case,
it's great that you found a way to keep performance and increase interactivity
at the same time with NAPI.

-- 
With respect,
Roman

  reply	other threads:[~2018-07-10 15:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-08 16:52 [ANNOUNCE] WireGuard Snapshot `0.0.20180708` Available Jason A. Donenfeld
2018-07-10 14:54 ` Roman Mamedov
2018-07-10 14:57   ` Jason A. Donenfeld
2018-07-10 15:57     ` Roman Mamedov [this message]
2018-07-10 18:37       ` Roman Mamedov
2018-07-10 18:38         ` Jason A. Donenfeld
2018-07-10 19:07           ` Roman Mamedov

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=20180710205729.645bc734@natsu \
    --to=rm@romanrm.net \
    --cc=Jason@zx2c4.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.