From: Phil Sutter <phil@nwl.cc>
To: "Serguei Bezverkhi (sbezverk)" <sbezverk@cisco.com>
Cc: Arturo Borrero Gonzalez <arturo@netfilter.org>,
"netfilter-devel@vger.kernel.org"
<netfilter-devel@vger.kernel.org>
Subject: Re: Numen with reference to vmap
Date: Tue, 17 Dec 2019 13:29:25 +0100 [thread overview]
Message-ID: <20191217122925.GD8553@orbyte.nwl.cc> (raw)
In-Reply-To: <98A8233C-1A83-44A1-A122-6F80212D618F@cisco.com>
Hi Serguei,
On Tue, Dec 17, 2019 at 12:51:07AM +0000, Serguei Bezverkhi (sbezverk) wrote:
> In this google doc, see link: https://docs.google.com/document/d/128gllbr_o-40pD2i0D14zMNdtCwRYR7YM49T4L2Eyac/edit?usp=sharing
I avoid Google-Doc as far as possible. ;)
> There is a question about possible optimizations. I was wondering if you could comment/reply. Also I got one more question about updates of a set. Let's say there is a set with 10k entries, how costly would be the update of such set.
Regarding Rob's question: With iptables, for N balanced servers there
are N rules. With equal probabilities a package traverses N/2 rules on
average (unless I'm mistaken). With nftables, there's a single rule
which triggers the map lookup. In kernel, that's a lookup in rhashtable
and therefore performs quite well.
Another aspect to Rob's question is jitter: With iptables solution, a
packet may traverse all N rules before it is dispatched. The nftables
map lookup will happen in almost constant time.
I can't give you performance numbers, but it should be easy to measure.
Given that you won't need set content for insert or delete operations
while iptables fetches the whole table for each rule insert or delete
command, I guess you can imagine how the numbers will look like. But
feel free to verify, it's fun! :)
Cheers, Phil
next prev parent reply other threads:[~2019-12-17 12:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-04 0:54 Numen with reference to vmap Serguei Bezverkhi (sbezverk)
2019-12-04 10:18 ` Phil Sutter
2019-12-04 13:47 ` Serguei Bezverkhi (sbezverk)
2019-12-04 15:17 ` Phil Sutter
2019-12-04 15:42 ` Serguei Bezverkhi (sbezverk)
2019-12-04 15:56 ` Phil Sutter
2019-12-04 16:13 ` Serguei Bezverkhi (sbezverk)
2019-12-04 17:00 ` Phil Sutter
2019-12-04 17:31 ` Arturo Borrero Gonzalez
2019-12-04 17:49 ` Serguei Bezverkhi (sbezverk)
2019-12-04 21:05 ` Serguei Bezverkhi (sbezverk)
2019-12-04 22:32 ` Phil Sutter
2019-12-17 0:51 ` Serguei Bezverkhi (sbezverk)
2019-12-17 12:29 ` Phil Sutter [this message]
2019-12-17 14:05 ` Serguei Bezverkhi (sbezverk)
2019-12-17 16:41 ` Phil Sutter
2019-12-18 17:01 ` Serguei Bezverkhi (sbezverk)
2019-12-18 17:24 ` Phil Sutter
2019-12-18 19:43 ` Serguei Bezverkhi (sbezverk)
2019-12-18 19:58 ` Laura Garcia
2019-12-18 20:54 ` Serguei Bezverkhi (sbezverk)
2019-12-19 10:48 ` Phil Sutter
2019-12-19 14:59 ` Serguei Bezverkhi (sbezverk)
2019-12-19 15:45 ` Phil Sutter
2019-12-19 16:00 ` Serguei Bezverkhi (sbezverk)
2019-12-19 18:19 ` Serguei Bezverkhi (sbezverk)
2020-01-04 12:30 ` Serguei Bezverkhi (sbezverk)
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=20191217122925.GD8553@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=arturo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=sbezverk@cisco.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.