From: Edward Cree <ecree@solarflare.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
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 15:11:06 +0100 [thread overview]
Message-ID: <97133878-8e78-287b-9854-431b116b0788@solarflare.com> (raw)
In-Reply-To: <20190426184943.idewf2rqebvslcva@salvia>
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?
-Ed
next prev parent reply other threads:[~2019-04-29 14:11 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 [this message]
2019-04-29 15:21 ` Pablo Neira Ayuso
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=97133878-8e78-287b-9854-431b116b0788@solarflare.com \
--to=ecree@solarflare.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=pablo@netfilter.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).