From: Edward Cree <ecree@solarflare.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: <netdev@vger.kernel.org>, <netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH net-next,v4 08/12] drivers: net: use flow block API
Date: Fri, 16 Aug 2019 18:00:35 +0100 [thread overview]
Message-ID: <cb418901-2f09-3c0e-c87a-83d97f222179@solarflare.com> (raw)
In-Reply-To: <20190816010421.if6mbyl2n3fsujy4@salvia>
On 16/08/2019 02:04, Pablo Neira Ayuso wrote:
> On Wed, Aug 14, 2019 at 05:17:20PM +0100, Edward Cree wrote:
>> TBH I'm still not clear why you need a flow_block per subsystem, rather than
>> just having multiple subsystems feed their offload requests through the same
>> flow_block but with different enum tc_setup_type or enum tc_fl_command or
>> some other indication that this is "netfilter" rather than "tc" asking for a
>> tc_cls_flower_offload.
> In tc, the flow_block is set up by when the ingress qdisc is
> registered. The usual scenario for most drivers is to have one single
> flow_block per registered ingress qdisc, this makes a 1:1 mapping
> between ingress qdisc and flow_block.
>
> Still, you can register two or more ingress qdiscs to make them share
> the same policy via 'tc block'. In that case all those qdiscs use one
> single flow_block. This makes a N:1 mapping between these qdisc
> ingress and the flow_block. This policy applies to all ingress qdiscs
> that are part of the same tc block. By 'tc block', I'm refering to the
> tcf_block structure.
>
> In netfilter, there are ingress basechains that are registered per
> device. Each basechain gets a flow_block by when the basechain is
> registered. Shared blocks as in tcf_block are not yet supported, but
> it should not be hard to extend it to make this work.
>
> To reuse the same flow_block as entry point for all subsystems as your
> propose - assuming offloads for two or more subsystems are in place -
> then all of them would need to have the same block sharing
> configuration, which might not be the case, ie. tc ingress might have
> a eth0 and eth1 use the same policy via flow_block, while netfilter
> might have one basechain for eth0 and another for eth1 (no policy
> sharing).
Thank you, that's very helpful.
>> This really needs a design document explaining what all the bits are, how
>> they fit together, and why they need to be like that.
> I did not design this flow_block abstraction, this concept was already
> in place under a different name and extend it so the ethtool/netfilter
> subsystems to avoid driver code duplication for offloads.
It's more the new implementation that you've created as part of this
extension that I was asking about, although I agree that the
abstraction that already existed is in need of documentation too.
next prev parent reply other threads:[~2019-08-16 17:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-09 20:55 [PATCH net-next,v4 00/11] netfilter: add hardware offload infrastructure Pablo Neira Ayuso
2019-07-09 20:55 ` [PATCH net-next,v4 01/12] net: flow_offload: add flow_block_cb_setup_simple() Pablo Neira Ayuso
2019-07-09 20:55 ` [PATCH net-next,v4 02/12] net: flow_offload: rename TC_BLOCK_{UN}BIND to FLOW_BLOCK_{UN}BIND Pablo Neira Ayuso
2019-07-09 20:55 ` [PATCH net-next,v4 03/12] net: flow_offload: rename TCF_BLOCK_BINDER_TYPE_* to FLOW_BLOCK_BINDER_TYPE_* Pablo Neira Ayuso
2019-07-09 20:55 ` [PATCH net-next,v4 04/12] net: flow_offload: add flow_block_cb_alloc() and flow_block_cb_free() Pablo Neira Ayuso
2019-07-09 20:55 ` [PATCH net-next,v4 05/12] net: flow_offload: add list handling functions Pablo Neira Ayuso
2019-07-10 7:36 ` Jiri Pirko
2019-07-10 9:06 ` Jiri Pirko
2019-07-09 20:55 ` [PATCH net-next,v4 06/12] net: flow_offload: add flow_block_cb_{priv,incref,decref}() Pablo Neira Ayuso
2019-07-09 20:55 ` [PATCH net-next,v4 07/12] net: sched: use flow block API Pablo Neira Ayuso
2019-08-14 16:32 ` Edward Cree
2019-08-16 1:10 ` Pablo Neira Ayuso
2019-07-09 20:55 ` [PATCH net-next,v4 08/12] drivers: net: " Pablo Neira Ayuso
2019-07-10 8:01 ` Jiri Pirko
2019-08-12 17:50 ` Edward Cree
2019-08-13 19:51 ` Pablo Neira Ayuso
2019-08-14 16:17 ` Edward Cree
2019-08-16 1:04 ` Pablo Neira Ayuso
2019-08-16 17:00 ` Edward Cree [this message]
2019-07-09 20:55 ` [PATCH net-next,v4 09/12] net: sched: remove tcf " Pablo Neira Ayuso
2019-07-09 20:55 ` [PATCH net-next,v4 10/12] net: flow_offload: add flow_block_cb_is_busy() and use it Pablo Neira Ayuso
2019-07-09 20:55 ` [PATCH net-next,v4 11/12] net: flow_offload: rename tc_cls_flower_offload to flow_cls_offload Pablo Neira Ayuso
2019-07-09 20:55 ` [PATCH net-next,v4 12/12] netfilter: nf_tables: add hardware offload support Pablo Neira Ayuso
2019-07-10 7:52 ` Jiri Pirko
2019-07-11 0:18 ` Pablo Neira Ayuso
2019-07-09 21:43 ` [PATCH net-next,v4 00/11] netfilter: add hardware offload infrastructure David Miller
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=cb418901-2f09-3c0e-c87a-83d97f222179@solarflare.com \
--to=ecree@solarflare.com \
--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).