Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: "jwollrath@web.de" <jwollrath@web.de>,
	"wireguard@lists.zx2c4.com" <wireguard@lists.zx2c4.com>
Subject: Re: [PATCH] wg-quick: linux: add support for nft and prefer it
Date: Tue, 10 Dec 2019 23:00:58 +0500	[thread overview]
Message-ID: <20191210230058.51f602f2@natsu> (raw)
In-Reply-To: <CAHmME9oYJFfQByaaVefEfbbXT=DABV+=DShuupJjBrk5i87GQA@mail.gmail.com>

On Tue, 10 Dec 2019 18:36:06 +0100
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

> That bachelors thesis says in the abstract, "Latency was measured
> through the round-trip time of ICMP packets while throughput was
> measured by generating UDP traffic using iPerf3. The results showed
> that, when using linear look-ups, nftables performs worse than
> iptables when using small frame sizes and when using large rulesets.

Smallest possible frame sizes are what matters the most when testing any
router or firewall setup, because only then you will hit the packet-per-second
limits of the actual firewalling/routing engine. Good performance at large
frame sizes is not an impressive achievent, there you will just hit
on-the-wire bandwidth limits sooner than the CPU toll of processing rulesets
or routing lookups for each of those frames will begin to matter.

> On the other hand, if what you say is actually true in our case, and
> nftables is utter crap, then perhaps we should scrap this nft(8) patch
> all together and just keep pure iptables(8). DKG - you seemed to want
> nft(8) support, though. How would you feel about that sort of
> conclusion?

Even with my view of it I do not argue for removing nftables support from
your tools, realistically it's probably not going anywhere, or at least not
soon enough, just thought I should point out that "nftables is faster" should
not be so naturally assumed to be the case, and if I dare to say that
everyone should decide for themselves what tools they prefer, and to carefully
weigh all benefits and downsides of the proposed alternatives -- not just come
along obediently with some external party that "knows what is best for you" and
declares something deprecated out of their own arbitrary reasons.

-- 
With respect,
Roman
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

  reply	other threads:[~2019-12-10 18:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10 15:48 Jason A. Donenfeld
2019-12-10 16:52 ` Jordan Glover
2019-12-10 16:54   ` Jason A. Donenfeld
2019-12-10 17:05     ` Jordan Glover
2019-12-10 17:11       ` Jason A. Donenfeld
2019-12-10 17:12     ` Roman Mamedov
2019-12-10 17:28       ` Davide Depau
2019-12-10 17:33       ` Matthias Urlichs
2019-12-10 17:36       ` Jason A. Donenfeld
2019-12-10 18:00         ` Roman Mamedov [this message]
2019-12-10 18:58         ` Jordan Glover
2019-12-10 19:15           ` Jason A. Donenfeld
2019-12-10 20:30             ` Jordan Glover
2019-12-10 20:34               ` Jason A. Donenfeld
2019-12-10 21:56       ` Vasili Pupkin
2019-12-10 22:09         ` Jason A. Donenfeld
2019-12-10 22:27           ` Vasili Pupkin
2019-12-12 11:21             ` Jason A. Donenfeld
2019-12-10 17:31 ` Vasili Pupkin
2019-12-10 17:38   ` 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=20191210230058.51f602f2@natsu \
    --to=rm@romanrm.net \
    --cc=Jason@zx2c4.com \
    --cc=jwollrath@web.de \
    --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).