Netdev Archive on lore.kernel.org help / color / mirror / Atom feed
From: Lukas Wunner <firstname.lastname@example.org> To: John Fastabend <email@example.com> Cc: Pablo Neira Ayuso <firstname.lastname@example.org>, Jozsef Kadlecsik <email@example.com>, Florian Westphal <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, Daniel Borkmann <firstname.lastname@example.org>, Alexei Starovoitov <email@example.com>, Eric Dumazet <firstname.lastname@example.org>, Thomas Graf <email@example.com>, Laura Garcia <firstname.lastname@example.org>, David Miller <email@example.com> Subject: Re: [PATCH nf-next v3 3/3] netfilter: Introduce egress hook Date: Fri, 4 Sep 2020 18:21:54 +0200 [thread overview] Message-ID: <20200904162154.GA24295@wunner.de> (raw) In-Reply-To: <5f5261535a32a_1932208c8@john-XPS-13-9370.notmuch> <5f5078705304_9154c2084c@john-XPS-13-9370.notmuch> On Wed, Sep 02, 2020 at 10:00:32PM -0700, John Fastabend wrote: > Lukas Wunner wrote: > > * Before: 4730418pps 2270Mb/sec (2270600640bps) > > * After: 4759206pps 2284Mb/sec (2284418880bps) > > I used a 10Gbps ixgbe nic to measure the performance after the dummy > device hung on me for some reason. I'll try to investigate what happened > later. It was unrelated to these patches though. > > But, with 10Gbps NIC and doing a pktgen benchmark with and without > the patches applied I didn't see any measurable differences. Both > cases reached 14Mpps. Hm, I strongly suspect you may have measured performance of the NIC and that you'd get different before/after numbers with the dummy device. > > * Before + tc: 4063912pps 1950Mb/sec (1950677760bps) > > * After + tc: 4007728pps 1923Mb/sec (1923709440bps) > > Same here before/after aggregate appears to be the same. Even the > numbers above show a 1.2% degradation. Just curious is the above > from a single run or averaged over multiple runs or something > else? Seems like noise to me. I performed at least 3 runs, but included just a single number in the commit message for brevity. That number is intended to show where the numbers settled: Before: 2257 2270 2270 Mb/sec After: 2282 2283 2284 2282 Mb/sec Before + tc: 1941 1950 1951 Mb/sec After + tc: 1923 1923 1919 1920 1919 Mb/sec After + nft: 1782 1783 1782 1781 Mb/sec After + nft + tc: 1574 1566 1566 Mb/sec So there's certainly some noise but still a speedup is clearly visible if neither tc nor nft is used, and a slight degradation if tc is used. > I did see something odd where it appeared fairness between threads > was slightly worse. I don't have any explanation for this? Did > you have a chance to run the test with -t >1? Sorry, no, I only tested with a single thread on an otherwise idle machine. > Do you have plans to address the performance degradation? Otherwise > if I was building some new components its unclear why we would > choose the slower option over the tc hook. The two suggested > use cases security policy and DSR sound like new features, any > reason to not just use existing infrastructure? > > Is the use case primarily legacy things already running in > nft infrastructure? I guess if you have code running now > moving it to this hook is faster and even if its 10% slower > than it could be that may be better than a rewrite? nft and tc are orthogonal, i.e. filtering/mangling versus queueing. However tc has gained the ability to filter packets as well, hence there's some overlap in functionality. Naturally tc does not allow the full glory of nft filtering/mangling options as Laura has stated, hence the need to add nft in the egress path. > huh? Its stated in the commit message with no reason for why it might > be the case and I can't reproduce it. The reason as stated in the commit message is that cache pressure is apparently reduced with the tc handling moved out of the hotpath, an effect that Eric Dumazet had previously observed for the ingress path: https://firstname.lastname@example.org/ Thanks a lot for taking the time to give these patches a whirl. Lukas
next prev parent reply other threads:[~2020-09-04 16:22 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-27 8:55 [PATCH nf-next v3 0/3] Netfilter egress hook Lukas Wunner 2020-08-27 8:55 ` [PATCH nf-next v3 1/3] netfilter: Rename ingress hook include file Lukas Wunner 2020-08-27 8:55 ` [PATCH nf-next v3 2/3] netfilter: Generalize ingress hook Lukas Wunner 2020-08-27 8:55 ` [PATCH nf-next v3 3/3] netfilter: Introduce egress hook Lukas Wunner 2020-08-28 18:52 ` John Fastabend 2020-09-03 5:00 ` John Fastabend 2020-09-04 8:54 ` Laura García Liébana 2020-09-04 15:46 ` John Fastabend 2020-09-05 11:13 ` Laura García Liébana 2020-09-04 16:21 ` Lukas Wunner [this message] 2020-09-04 21:14 ` Daniel Borkmann 2020-09-05 5:24 ` Lukas Wunner 2020-09-08 12:55 ` Daniel Borkmann 2020-09-11 7:42 ` Laura García Liébana 2020-09-11 16:27 ` Daniel Borkmann 2020-09-14 11:29 ` Laura García Liébana 2020-09-14 22:02 ` Daniel Borkmann 2020-09-17 10:28 ` Laura García Liébana 2020-09-18 20:31 ` Daniel Borkmann 2020-09-19 15:52 ` Pablo Neira Ayuso 2020-09-21 7:07 ` Laura García Liébana 2020-10-11 8:26 ` Lukas Wunner 2020-11-21 18:59 ` Pablo Neira Ayuso 2020-11-22 3:24 ` Alexei Starovoitov 2020-11-22 11:01 ` Pablo Neira Ayuso 2020-11-24 3:34 ` Alexei Starovoitov 2020-11-24 7:31 ` Lukas Wunner 2020-11-24 22:55 ` Alexei Starovoitov 2020-10-11 7:59 ` Lukas Wunner 2020-09-05 11:18 ` Laura García Liébana 2020-09-07 22:11 ` Daniel Borkmann 2020-09-08 6:19 ` Laura García Liébana 2020-09-08 11:46 ` Arturo Borrero Gonzalez 2020-09-08 13:27 ` Daniel Borkmann 2020-09-08 18:58 ` John Fastabend 2020-09-19 15:54 ` Pablo Neira Ayuso 2020-09-28 12:20 ` Lukas Wunner 2020-08-27 10:36 ` [PATCH nf-next v3 0/3] Netfilter " Laura García Liébana 2020-08-28 7:14 ` Daniel Borkmann 2020-08-28 9:14 ` Eric Dumazet
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=20200904162154.GA24295@wunner.de \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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: linkBe 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).