From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Tobias Waldekranz <tobias@waldekranz.com>,
netfilter-devel@vger.kernel.org, davem@davemloft.net,
netdev@vger.kernel.org, razor@blackwall.org, jeremy@azazel.net
Subject: Re: [PATCH net-next,v3 0/9] netfilter: flowtable bridge and vlan enhancements
Date: Sat, 21 Nov 2020 19:56:21 +0100 [thread overview]
Message-ID: <20201121185621.GA23017@salvia> (raw)
In-Reply-To: <20201121101551.3264c5fd@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Sat, Nov 21, 2020 at 10:15:51AM -0800, Jakub Kicinski wrote:
> On Sat, 21 Nov 2020 13:31:38 +0100 Pablo Neira Ayuso wrote:
> > On Mon, Nov 16, 2020 at 11:56:58PM +0100, Pablo Neira Ayuso wrote:
> > > On Mon, Nov 16, 2020 at 02:45:21PM -0800, Jakub Kicinski wrote:
> > > > On Mon, 16 Nov 2020 23:36:15 +0100 Pablo Neira Ayuso wrote:
[...]
> > I have been discussing the topology update by tracking fdb updates
> > with the bridge maintainer, I'll be exploring extensions to the
> > existing fdb_notify() infrastructure to deal with this scenario you
> > describe. On my side this topology update scenario is not a priority
> > to be supported in this patchset, but it's feasible to support it
> > later on.
>
> My concern is that invalidation is _the_ hard part of creating caches.
> And I feel like merging this as is would be setting our standards pretty
> low.
Interesting, let's summarize a bit to make sure we're on the same
page:
- This "cache" is optional, you enable it on demand through ruleset.
- This "cache" is configurable, you can specify through ruleset policy
what policies get into the cache and _when_ they are placed in the
cache.
- This is not affecting any existing default configuration, neither
Linux networking not even classic path Netfilter configurations,
it's a rather new thing.
- This is showing performance improvement of ~50% with a very simple
testbed. With pktgen, back few years ago I was reaching x2.5
performance boost in software in a pktgen testbed.
- This is adding minimal changes to netdev_ops, just a single
callback.
For the live VM migration you describe, connections might time out,
but there are many use-cases where this is still valid, some of them
has been described already here.
> Please gather some review tags from senior netdev developers. I don't
> feel confident enough to apply this as 100% my own decision.
Fair enough.
This requirement for very specific Netfilter infrastructure which does
not affect any other Networking subsystem sounds new to me.
What senior developers specifically you would like I should poke to
get an acknowledgement on this to get this accepted of your
preference?
Thank you.
next prev parent reply other threads:[~2020-11-21 18:56 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-11 19:37 [PATCH net-next,v3 0/9] netfilter: flowtable bridge and vlan enhancements Pablo Neira Ayuso
2020-11-11 19:37 ` [PATCH net-next,v3 1/9] netfilter: flowtable: add hash offset field to tuple Pablo Neira Ayuso
2020-11-11 19:37 ` [PATCH net-next,v3 2/9] netfilter: flowtable: add xmit path types Pablo Neira Ayuso
2020-11-11 19:37 ` [PATCH net-next,v3 3/9] net: resolve forwarding path from virtual netdevice and HW destination address Pablo Neira Ayuso
2020-11-14 1:42 ` Jakub Kicinski
2020-11-14 12:00 ` Pablo Neira Ayuso
2020-11-11 19:37 ` [PATCH net-next,v3 4/9] net: 8021q: resolve forwarding path for vlan devices Pablo Neira Ayuso
2020-11-11 19:37 ` [PATCH net-next,v3 5/9] bridge: resolve forwarding path for bridge devices Pablo Neira Ayuso
2020-11-12 0:53 ` Nikolay Aleksandrov
2020-11-13 15:40 ` Nikolay Aleksandrov
2020-11-11 19:37 ` [PATCH net-next,v3 6/9] netfilter: flowtable: use dev_fill_forward_path() to obtain ingress device Pablo Neira Ayuso
2020-11-11 19:37 ` [PATCH net-next,v3 7/9] netfilter: flowtable: use dev_fill_forward_path() to obtain egress device Pablo Neira Ayuso
2020-11-11 19:37 ` [PATCH net-next,v3 8/9] netfilter: flowtable: add vlan support Pablo Neira Ayuso
2020-11-11 19:37 ` [PATCH net-next,v3 9/9] selftests: netfilter: flowtable bridge and VLAN support Pablo Neira Ayuso
2020-11-14 1:55 ` [PATCH net-next,v3 0/9] netfilter: flowtable bridge and vlan enhancements Jakub Kicinski
2020-11-14 11:59 ` Pablo Neira Ayuso
2020-11-14 14:00 ` Tobias Waldekranz
2020-11-14 17:03 ` Jakub Kicinski
2020-11-16 22:18 ` Pablo Neira Ayuso
2020-11-16 22:28 ` Jakub Kicinski
2020-11-16 22:36 ` Pablo Neira Ayuso
2020-11-16 22:45 ` Jakub Kicinski
2020-11-16 22:56 ` Pablo Neira Ayuso
2020-11-21 12:31 ` Pablo Neira Ayuso
2020-11-21 18:15 ` Jakub Kicinski
2020-11-21 18:56 ` Pablo Neira Ayuso [this message]
2020-11-21 19:23 ` Jakub Kicinski
2020-11-22 11:33 ` Pablo Neira Ayuso
2020-11-16 22:31 ` Pablo Neira Ayuso
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=20201121185621.GA23017@salvia \
--to=pablo@netfilter.org \
--cc=davem@davemloft.net \
--cc=jeremy@azazel.net \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=razor@blackwall.org \
--cc=tobias@waldekranz.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.