From: wenxu <wenxu@ucloud.cn>
To: Pablo Neira Ayuso <pablo@netfilter.org>, Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 2/3 nf-next] netfilter:nf_flow_table: Support bridge type flow offload
Date: Fri, 28 Jun 2019 11:37:42 +0800 [thread overview]
Message-ID: <b2a48653-9f30-18a9-d0e1-eaa940a361a9@ucloud.cn> (raw)
In-Reply-To: <20190627125839.t56fnptdeqixt7wd@salvia>
On 6/27/2019 8:58 PM, Pablo Neira Ayuso wrote:
> On Thu, Jun 27, 2019 at 02:22:36PM +0800, wenxu wrote:
>> On 6/27/2019 3:19 AM, Florian Westphal wrote:
>>> Florian Westphal <fw@strlen.de> wrote:
> [...]
>>>> Whats the idea with this patch?
>>>>
>>>> Do you see a performance improvement when bypassing bridge layer? If so,
>>>> how much?
>>>>
>>>> I just wonder if its really cheaper than not using bridge conntrack in
>>>> the first place :-)
>> This patch is based on the conntrack function in bridge. It will
>> bypass the fdb lookup and conntrack lookup to get the performance
>> improvement. The more important things for hardware offload in the
>> future with nf_tables add hardware offload support
> Florian would like to see numbers / benchmark.
I just did a simple performace test with following test.
p netns add ns21
ip netns add ns22
ip l add dev veth21 type veth peer name eth0 netns ns21
ip l add dev veth22 type veth peer name eth0 netns ns22
ifconfig veth21 up
ifconfig veth22 up
ip netns exec ns21 ip a a dev eth0 10.0.0.7/24
ip netns exec ns22 ip a a dev eth0 10.0.0.8/24
ip netns exec ns21 ifconfig eth0 up
ip netns exec ns22 ifconfig eth0 up
ip l add dev br0 type bridge vlan_filtering 1
brctl addif br0 veth21
brctl addif br0 veth22
ifconfig br0 up
bridge vlan add dev veth21 vid 200 pvid untagged
bridge vlan add dev veth22 vid 200 pvid untagged
nft add table bridge firewall
nft add chain bridge firewall zones { type filter hook prerouting priority - 300 \; }
nft add rule bridge firewall zones counter ct zone set iif map { "veth21" : 2, "veth22" : 2 }
nft add chain bridge firewall rule-200-ingress
nft add rule bridge firewall rule-200-ingress ct zone 2 ct state established,related counter accept
nft add rule bridge firewall rule-200-ingress ct zone 2 ct state invalid counter drop
nft add rule bridge firewall rule-200-ingress ct zone 2 tcp dport 23 ct state new counter accept
nft add rule bridge firewall rule-200-ingress counter drop
nft add chain bridge firewall rule-200-egress
nft add rule bridge firewall rule-200-egress ct zone 2 ct state established,related counter accept
nft add rule bridge firewall rule-200-egress ct zone 2 ct state invalid counter drop
nft add rule bridge firewall rule-200-egress ct zone 2 tcp dport 23 ct state new counter drop
nft add rule bridge firewall rule-200-egress counter accept
nft add chain bridge firewall rules-all { type filter hook prerouting priority - 150 \; }
nft add rule bridge firewall rules-all counter meta protocol ip iif vmap { "veth22" : jump rule-200-ingress, "veth21" : jump rule-200-egress }
netns21 communication with ns22
ns21 iperf to 10.0.0.8 with dport 22 in ns22
first time with OFFLOAD enable
nft add flowtable bridge firewall fb2 { hook ingress priority 0 \; devices = { veth21, veth22 } \; }
nft add chain bridge firewall ftb-all {type filter hook forward priority 0 \; policy accept \; }
nft add rule bridge firewall ftb-all counter ct zone 2 ip protocol tcp flow offload @fb2
# iperf -c 10.0.0.8 -p 22 -t 60 -i2
------------------------------------------------------------
Client connecting to 10.0.0.8, TCP port 22
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.7 port 60014 connected with 10.0.0.8 port 22
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 10.8 GBytes 46.5 Gbits/sec
[ 3] 2.0- 4.0 sec 10.9 GBytes 46.7 Gbits/sec
[ 3] 4.0- 6.0 sec 10.9 GBytes 46.8 Gbits/sec
[ 3] 6.0- 8.0 sec 11.0 GBytes 47.2 Gbits/sec
[ 3] 8.0-10.0 sec 11.0 GBytes 47.1 Gbits/sec
[ 3] 10.0-12.0 sec 11.0 GBytes 47.1 Gbits/sec
[ 3] 12.0-14.0 sec 11.7 GBytes 50.4 Gbits/sec
[ 3] 14.0-16.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 16.0-18.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 18.0-20.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 20.0-22.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 22.0-24.0 sec 12.0 GBytes 51.4 Gbits/sec
[ 3] 24.0-26.0 sec 12.0 GBytes 51.3 Gbits/sec
[ 3] 26.0-28.0 sec 12.0 GBytes 51.7 Gbits/sec
[ 3] 28.0-30.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 30.0-32.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 32.0-34.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 34.0-36.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 36.0-38.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 38.0-40.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 40.0-42.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 42.0-44.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 44.0-46.0 sec 12.0 GBytes 51.4 Gbits/sec
[ 3] 46.0-48.0 sec 12.0 GBytes 51.4 Gbits/sec
[ 3] 48.0-50.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 50.0-52.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 52.0-54.0 sec 12.0 GBytes 51.6 Gbits/sec
[ 3] 54.0-56.0 sec 12.0 GBytes 51.5 Gbits/sec
[ 3] 56.0-58.0 sec 11.9 GBytes 51.2 Gbits/sec
[ 3] 58.0-60.0 sec 11.8 GBytes 50.7 Gbits/sec
[ 3] 0.0-60.0 sec 353 GBytes 50.5 Gbits/sec
The second time on any offload:
# iperf -c 10.0.0.8 -p 22 -t 60 -i2
------------------------------------------------------------
Client connecting to 10.0.0.8, TCP port 22
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.7 port 60536 connected with 10.0.0.8 port 22
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 8.88 GBytes 38.1 Gbits/sec
[ 3] 2.0- 4.0 sec 9.02 GBytes 38.7 Gbits/sec
[ 3] 4.0- 6.0 sec 9.02 GBytes 38.8 Gbits/sec
[ 3] 6.0- 8.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 8.0-10.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 10.0-12.0 sec 9.04 GBytes 38.8 Gbits/sec
[ 3] 12.0-14.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 14.0-16.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 16.0-18.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 18.0-20.0 sec 9.07 GBytes 39.0 Gbits/sec
[ 3] 20.0-22.0 sec 9.07 GBytes 38.9 Gbits/sec
[ 3] 22.0-24.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 24.0-26.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 26.0-28.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 28.0-30.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 30.0-32.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 32.0-34.0 sec 9.07 GBytes 38.9 Gbits/sec
[ 3] 34.0-36.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 36.0-38.0 sec 9.03 GBytes 38.8 Gbits/sec
[ 3] 38.0-40.0 sec 9.03 GBytes 38.8 Gbits/sec
[ 3] 40.0-42.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 42.0-44.0 sec 9.03 GBytes 38.8 Gbits/sec
[ 3] 44.0-46.0 sec 9.04 GBytes 38.8 Gbits/sec
[ 3] 46.0-48.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 48.0-50.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 50.0-52.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 52.0-54.0 sec 9.06 GBytes 38.9 Gbits/sec
[ 3] 54.0-56.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 56.0-58.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 58.0-60.0 sec 9.05 GBytes 38.9 Gbits/sec
[ 3] 0.0-60.0 sec 271 GBytes 38.8 Gbits/sec
>
next prev parent reply other threads:[~2019-06-28 3:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-26 10:32 [PATCH 1/3 nf-next] netfilter:nf_flow_table: Refactor flow_offload_tuple to support more offload method wenxu
2019-06-26 10:32 ` [PATCH 2/3 nf-next] netfilter:nf_flow_table: Support bridge type flow offload wenxu
2019-06-26 18:38 ` Florian Westphal
2019-06-26 19:19 ` Florian Westphal
2019-06-27 6:22 ` wenxu
2019-06-27 12:58 ` Pablo Neira Ayuso
2019-06-28 3:37 ` wenxu [this message]
2019-06-28 6:06 ` Florian Westphal
2019-06-28 9:51 ` wenxu
2019-06-26 18:40 ` Pablo Neira Ayuso
2019-06-26 10:32 ` [PATCH 3/3 nf-next] netfilter: Flow table support for the bridge family wenxu
2019-06-26 18:29 ` [PATCH 1/3 nf-next] netfilter:nf_flow_table: Refactor flow_offload_tuple to support more offload method 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=b2a48653-9f30-18a9-d0e1-eaa940a361a9@ucloud.cn \
--to=wenxu@ucloud.cn \
--cc=fw@strlen.de \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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).