From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Edward Cree <ecree@solarflare.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>,
netdev <netdev@vger.kernel.org>, Jiri Pirko <jiri@resnulli.us>,
Cong Wang <xiyou.wangcong@gmail.com>
Subject: Re: TC stats / hw offload question
Date: Mon, 29 Apr 2019 17:21:28 +0200 [thread overview]
Message-ID: <20190429152128.4mbqyipjv25jiiko@salvia> (raw)
In-Reply-To: <97133878-8e78-287b-9854-431b116b0788@solarflare.com>
On Mon, Apr 29, 2019 at 03:11:06PM +0100, Edward Cree wrote:
> On 26/04/2019 19:49, Pablo Neira Ayuso wrote:
> > On Fri, Apr 26, 2019 at 01:13:41PM +0100, Edward Cree wrote:
> >> Thus if (and only if) two TC actions have the same tcfa_index, they will
> >> share a single counter in the HW.
> >> I gathered from a previous conversation with Jamal[1] that that was the
> >> correct behaviour:
> >>> Note, your counters should also be shareable; example, count all
> >>> the drops in one counter across multiple flows as in the following
> >>> case where counter index 1 is used.
> >>>
> >>> tc flower match foo action drop index 1
> >>> tc flower match bar action drop index 1
> > The flow_action_entry structure needs a new 'counter_index' field to
> > store this. The tc_setup_flow_action() function needs to be updated
> > for this for the FLOW_ACTION_{ACCEPT,DROP,REDIRECT,MIRRED} cases to
> > set this entry->counter_index field to tcfa_index, so the driver has
> > access to this.
> Hmm, I'm still not sure this solves everything.
> Before, we could write
> tc flower match foo \
> action mirred egress mirror eth1 index 1 \
> action mirred egress redirect eth2 index 2
> and have two distinct HW counters (one of which might e.g. be shared
> with another rule). But when reading those counters, under
> fl_hw_update_stats(), the driver only gets to return one set of flow
> stats for both actions.
> Previously, the driver's TC_CLSFLOWER_STATS handler was updating the
> action stats directly, so was able to do something different for each
> action, but that's not possible in 5.1. At stats gathering time, the
> driver doesn't even have access to anything that's per-action and
> thus could have a flow_stats member shoved in it.
> AFAICT, the only reason this isn't a regression is that existing
> drivers didn't implement the old semantics correctly.
>
> This is a bit of a mess; the best idea I've got is for the
> TC_CLSFLOWER_STATS call to include a tcfa_index. Then the driver
> returns counter stats for that index, and tcf_exts_stats_update()
> only updates those actions whose index matches. But then
> fl_hw_update_stats() would have to iterate over all the indices in
> f->exts. What do you think?
You could extend struct flow_stats to pass an array of stats to the
driver, including one stats per action and the counter index. Then,
tcf_exts_stats_update() uses this array of stats to update per-action
stats.
struct flow_action_stats {
u32 counter_index;
u64 pkts;
u64 bytes;
u64 lastused;
};
struct flow_stats {
struct flow_action_stats *stats[];
u32 num_actions;
};
As you mentioned, no driver supports for tcfa_index so far, probably
it would be a good idea to return -EOPNOTSUPP in such case by now.
next prev parent reply other threads:[~2019-04-29 15:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-05 19:41 TC stats / hw offload question Edward Cree
2019-02-06 2:20 ` Jamal Hadi Salim
2019-02-08 10:26 ` Edward Cree
2019-02-09 17:39 ` Jamal Hadi Salim
2019-02-11 11:44 ` Edward Cree
2019-02-14 12:39 ` Jamal Hadi Salim
2019-02-14 15:17 ` Andy Gospodarek
2019-02-18 18:56 ` Edward Cree
2019-02-18 19:37 ` Edward Cree
2019-04-24 14:05 ` Edward Cree
2019-04-24 14:11 ` Pablo Neira Ayuso
2019-04-24 15:03 ` Edward Cree
2019-04-25 13:23 ` Edward Cree
2019-04-25 22:33 ` Pablo Neira Ayuso
2019-04-26 12:13 ` Edward Cree
2019-04-26 12:42 ` Jamal Hadi Salim
2019-04-26 18:49 ` Pablo Neira Ayuso
2019-04-29 14:11 ` Edward Cree
2019-04-29 15:21 ` Pablo Neira Ayuso [this message]
2019-04-29 16:25 ` Edward Cree
2019-04-29 19:14 ` Pablo Neira Ayuso
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=20190429152128.4mbqyipjv25jiiko@salvia \
--to=pablo@netfilter.org \
--cc=ecree@solarflare.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.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).