From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: 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, 14 Nov 2020 12:59:06 +0100 [thread overview]
Message-ID: <20201114115906.GA21025@salvia> (raw)
In-Reply-To: <20201113175556.25e57856@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Fri, Nov 13, 2020 at 05:55:56PM -0800, Jakub Kicinski wrote:
> On Wed, 11 Nov 2020 20:37:28 +0100 Pablo Neira Ayuso wrote:
> > The following patchset augments the Netfilter flowtable fastpath [1] to
> > support for network topologies that combine IP forwarding, bridge and
> > VLAN devices.
> >
> > A typical scenario that can benefit from this infrastructure is composed
> > of several VMs connected to bridge ports where the bridge master device
> > 'br0' has an IP address. A DHCP server is also assumed to be running to
> > provide connectivity to the VMs. The VMs reach the Internet through
> > 'br0' as default gateway, which makes the packet enter the IP forwarding
> > path. Then, netfilter is used to NAT the packets before they leave
> > through the wan device.
> >
> > Something like this:
> >
> > fast path
> > .------------------------.
> > / \
> > | IP forwarding |
> > | / \ .
> > | br0 eth0
> > . / \
> > -- veth1 veth2
> > .
> > .
> > .
> > eth0
> > ab:cd:ef:ab:cd:ef
> > VM
> >
> > The idea is to accelerate forwarding by building a fast path that takes
> > packets from the ingress path of the bridge port and place them in the
> > egress path of the wan device (and vice versa). Hence, skipping the
> > classic bridge and IP stack paths.
>
> The problem that immediately comes to mind is that if there is any
> dynamic forwarding state the cache you're creating would need to be
> flushed when FDB changes. Are you expecting users would plug into the
> flowtable devices where they know things are fairly static?
If any of the flowtable device goes down / removed, the entries are
removed from the flowtable. This means packets of existing flows are
pushed up back to classic bridge / forwarding path to re-evaluate the
fast path.
For each new flow, the fast path that is selected freshly, so they use
the up-to-date FDB to select a new bridge port.
Existing flows still follow the old path. The same happens with FIB
currently.
It should be possible to explore purging entries in the flowtable that
are stale due to changes in the topology (either in FDB or FIB).
What scenario do you have specifically in mind? Something like VM
migrates from one bridge port to another?
Thank you.
next prev parent reply other threads:[~2020-11-14 11:59 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 [this message]
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
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=20201114115906.GA21025@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 \
/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).