From: Florian Fainelli <f.fainelli@gmail.com>
To: David Miller <davem@davemloft.net>, pablo@netfilter.org
Cc: netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
steffen.klassert@secunet.com
Subject: Re: [PATCH net-next,RFC 00/13] New fast forwarding path
Date: Thu, 14 Jun 2018 11:14:37 -0700 [thread overview]
Message-ID: <66634ba7-3d72-644a-9d26-d9644c540619@gmail.com> (raw)
In-Reply-To: <20180614.101831.465275975690050595.davem@davemloft.net>
On 06/14/2018 10:18 AM, David Miller wrote:
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Thu, 14 Jun 2018 16:19:34 +0200
>
>> This patchset proposes a new fast forwarding path infrastructure
>> that combines the GRO/GSO and the flowtable infrastructures. The
>> idea is to add a hook at the GRO layer that is invoked before the
>> standard GRO protocol offloads. This allows us to build custom
>> packet chains that we can quickly pass in one go to the neighbour
>> layer to define fast forwarding path for flows.
>
> We have full, complete, customizability of the packet path via XDP
> and eBPF.
>
> XDP and eBPF supports everything necessary to accomplish that,
> there are implementations of forwarding implementations in
> the tree and elsewhere.
>
> And most importantly, XDP and eBPF are optimized in drivers and
> offloaded to hardware.
>
> There really is no need for something like what you are proposing.
>
I see one possible upside to that approach here which is the low end
MIPS/ARM/PowerPC 32-bit based routers that do not have an eBPF JIT
available (that's only MIPS32 and PowerPC AFAICT), it would be great to
see what happens on those systems and if we do get any performance
improvements for a traditional forwarding/routing workload. On those
platforms there are a number of things that just literally kill the
routing performance: small I and D caches, small or not L2, limited
bandwidth DRAM, huge call depths, big struct sk_buff layout, you name it.
--
Florian
next prev parent reply other threads:[~2018-06-14 18:14 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-14 14:19 [PATCH net-next,RFC 00/13] New fast forwarding path Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 01/13] net: Add a helper to get the packet offload callbacks by priority Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 02/13] net: Change priority of ipv4 and ipv6 packet offloads Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 03/13] net: Add a GSO feature bit for the netfilter forward fastpath Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 04/13] net: Use one bit of NAPI_GRO_CB for the netfilter fastpath Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 05/13] netfilter: add early ingress hook for IPv4 Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 06/13] netfilter: add early ingress support for IPv6 Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 07/13] netfilter: add ESP support for early ingress Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 08/13] netfilter: nft_chain_filter: add " Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 09/13] netfilter: nf_flow_table: add hooknum to flowtable type Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 10/13] netfilter: nf_flow_table: add flowtable for early ingress hook Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 11/13] netfilter: nft_flow_offload: enable offload after second packet is seen Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 12/13] netfilter: nft_flow_offload: remove secpath check Pablo Neira Ayuso
2018-06-14 14:19 ` [PATCH net-next,RFC 13/13] netfilter: nft_flow_offload: make sure route is not stale Pablo Neira Ayuso
2018-06-14 15:50 ` [PATCH net-next,RFC 00/13] New fast forwarding path Willem de Bruijn
2018-06-15 5:23 ` Steffen Klassert
2018-06-14 15:57 ` Eric Dumazet
2018-06-15 6:03 ` Steffen Klassert
2018-06-15 13:01 ` Eric Dumazet
2018-06-14 17:18 ` David Miller
2018-06-14 18:14 ` Florian Fainelli [this message]
2018-06-14 23:55 ` David Miller
2018-06-20 0:56 ` Andrew Collins
2018-06-15 6:17 ` Steffen Klassert
2018-06-15 13:22 ` Daniel Borkmann
2018-06-17 9:23 ` Steffen Klassert
2018-06-19 22:22 ` Daniel Borkmann
2018-06-14 20:52 ` Tom Herbert
2018-06-14 23:58 ` David Miller
2018-06-15 6:34 ` Steffen Klassert
2018-06-15 12:18 ` Edward Cree
2018-06-15 20:12 ` Tom Herbert
2018-06-15 6:27 ` Steffen Klassert
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=66634ba7-3d72-644a-9d26-d9644c540619@gmail.com \
--to=f.fainelli@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=steffen.klassert@secunet.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 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).