[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190524100329.4e1f0ce4@cakuba.netronome.com>
Date: Fri, 24 May 2019 10:03:29 -0700
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Edward Cree <ecree@...arflare.com>
Cc: Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>,
"Pablo Neira Ayuso" <pablo@...filter.org>,
David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Cong Wang <xiyou.wangcong@...il.com>,
"Andy Gospodarek" <andy@...yhouse.net>,
Michael Chan <michael.chan@...adcom.com>,
Vishal Kulkarni <vishal@...lsio.com>
Subject: Re: [PATCH v3 net-next 0/3] flow_offload: Re-add per-action
statistics
On Fri, 24 May 2019 14:57:24 +0100, Edward Cree wrote:
> On 24/05/2019 14:09, Edward Cree wrote:
> > I'll put together an RFC patch, anyway
> Argh, there's a problem: an action doesn't have a (directly) associated
> block, and all the TC offload machinery nowadays is built around blocks.
> Since this action might have been used in _any_ block (and afaik there's
> no way, from the action, to find which) we'd have to make callbacks on
> _every_ block in the system, which sounds like it'd perform even worse
> than the rule-dumping approach.
> Any ideas?
Simplest would be to keep a list of offloaders per action, but maybe
something more clever would appear as one rummages through the code.
We're happy to help out with the driver side if you get stuck on that,
BTW.
Powered by blists - more mailing lists