Re: Numen with reference to vmap

From: "Serguei Bezverkhi (sbezverk)" <sbezverk@cisco.com>
To: Phil Sutter <phil@nwl.cc>
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 14:05:58 +0000	[thread overview]
Message-ID: <C5103001-881F-46A8-8738-EC8F8117FAE6@cisco.com> (raw)
In-Reply-To: <20191217122925.GD8553@orbyte.nwl.cc>

Hi Phil,

Thank you very much for your reply. Can I paste your reply into the doc with reference to your name? If you do not wish. I will rephrase it and post it there.

I have one question, 

chain KUBE-SVC-57XVOCFNTLTR3Q27 {
	numgen random mod 2 vmap { 0 : jump KUBE-SEP-FS3FUULGZPVD4VYB, 
                                                                       1 : jump KUBE-SEP-MMFZROQSLQ3DKOQA }
}

In this rule, as far as I understood you last time, there is no way dynamically change elements of anonymous vmap. So if the service has large number of dynamic (short lived) endpoints, this rule will have to be reprogrammed for every change and it would be extremely inefficient. Is there any way to make it more dynamic or plans to change the static behavior?  That would extremely important.

Thank you
Serguei

On 2019-12-17, 7:29 AM, "n0-1@orbyte.nwl.cc on behalf of Phil Sutter" <n0-1@orbyte.nwl.cc on behalf of phil@nwl.cc> wrote:

    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