[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <75eec70e-60de-e33b-aea0-be595ca625f4@solarflare.com>
Date: Mon, 12 Aug 2019 18:50:09 +0100
From: Edward Cree <ecree@...arflare.com>
To: Pablo Neira Ayuso <pablo@...filter.org>
CC: <netdev@...r.kernel.org>, <netfilter-devel@...r.kernel.org>
Subject: Re: [PATCH net-next,v4 08/12] drivers: net: use flow block API
On 09/07/2019 21:55, Pablo Neira Ayuso wrote:
> This patch updates flow_block_cb_setup_simple() to use the flow block API.
> Several drivers are also adjusted to use it.
>
> This patch introduces the per-driver list of flow blocks to account for
> blocks that are already in use.
>
> Remove tc_block_offload alias.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@...filter.org>
> ---
> v4: fix typo in list in nfp driver - Jakub Kicinski.
> Move driver_list handling to the driver code, this list is transitional,
> until drivers are updated to support multiple subsystems. No more
> driver_list handling from core.
Pablo, can you explain (because this commit message doesn't) why these per-
driver lists are needed, and what the information/state is that has module
(rather than, say, netdevice) scope?
AFAICT none of these drivers otherwise interacts with TC at a module level
(every block binding, callback etc. is associated with a single netdevice,
usually through a cb_priv = netdev_priv(net_dev)), so this looks very out
of place.
(More questions likely to follow as I work my way through trying to re-
target my in-development driver to this new API. Also if you have any
kind of design document explaining how it all fits together, that'd be
nice, because currently trying to figure it out is giving me a headache.)
-Ed
Powered by blists - more mailing lists