From: Jiri Pirko <jiri@resnulli.us>
To: Edward Cree <ecree@solarflare.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, davem@davemloft.net, saeedm@mellanox.com,
leon@kernel.org, michael.chan@broadcom.com, vishal@chelsio.com,
jeffrey.t.kirsher@intel.com, idosch@mellanox.com,
aelior@marvell.com, peppe.cavallaro@st.com,
alexandre.torgue@st.com, jhs@mojatatu.com,
xiyou.wangcong@gmail.com, pablo@netfilter.org,
mlxsw@mellanox.com
Subject: Re: [patch net-next 00/10] net: allow user specify TC filter HW stats type
Date: Mon, 24 Feb 2020 14:11:01 +0100 [thread overview]
Message-ID: <20200224131101.GC16270@nanopsycho> (raw)
In-Reply-To: <b6c5f811-2313-14a0-75c4-96d29196e7e6@solarflare.com>
Mon, Feb 24, 2020 at 12:38:20PM CET, ecree@solarflare.com wrote:
>On 22/02/2020 06:38, Jiri Pirko wrote:
>> Fri, Feb 21, 2020 at 07:22:00PM CET, kuba@kernel.org wrote:
>>> Hmm, but the statistics are on actions, it feels a little bit like we
>>> are perpetuating the mistake of counting on filters here.
>> You are right, the stats in tc are per-action. However, in both mlxsw
>> and mlx5, the stats are per-filter. What hw_stats does is that it
>> basically allows the user to set the type for all the actions in the
>> filter at once.
>>
>> Could you imagine a usecase that would use different HW stats type for
>> different actions in one action-chain?
>Potentially a user could only want stats on one action and disable them
> on another. For instance, if their action chain does delivery to the
> 'customer' and also mirrors the packets for monitoring, they might only
> want stats on the first delivery (e.g. for billing) and not want to
> waste a counter on the mirror.
Okay.
>
>> Plus, if the fine grained setup is ever needed, the hw_stats could be in
>> future easilyt extended to be specified per-action too overriding
>> the per-filter setup only for specific action. What do you think?
>I think this is improper; the stats type should be defined per-action in
> the uapi, even if userland initially only has UI to set it across the
> entire filter. (I imagine `tc action` would grow the corresponding UI
> pretty quickly.) Then on the driver side, you must determine whether
> your hardware can support the user's request, and if not, return an
> appropriate error code.
>
>Let's try not to encourage people (users, future HW & driver developers)
> to keep thinking of stats as per-filter entities.
Okay, but in that case, it does not make sense to have "UI to set it
across the entire filter". The UI would have to set it per-action too.
Othewise it would make people think it is per-filter entity.
But I guess the tc cmdline is chatty already an it can take other
repetitive cmdline options.
What do you think?
Thanks!
next prev parent reply other threads:[~2020-02-24 13:11 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 9:56 [patch net-next 00/10] net: allow user specify TC filter HW stats type Jiri Pirko
2020-02-21 9:56 ` [patch net-next 01/10] net: rename tc_cls_can_offload_and_chain0() to tc_cls_can_offload_basic() Jiri Pirko
2020-02-21 9:56 ` [patch net-next 02/10] iavf: use tc_cls_can_offload_basic() instead of chain check Jiri Pirko
2020-02-21 9:56 ` [patch net-next 03/10] flow_offload: Introduce offload of HW stats type Jiri Pirko
2020-02-21 9:56 ` [patch net-next 04/10] net: extend tc_cls_can_offload_basic() to check " Jiri Pirko
2020-02-21 9:56 ` [patch net-next 05/10] mlx5: restrict supported HW stats type to "any" Jiri Pirko
2020-02-21 9:56 ` [patch net-next 06/10] mlxsw: " Jiri Pirko
2020-02-21 9:56 ` [patch net-next 07/10] flow_offload: introduce "immediate" HW stats type and allow it in mlxsw Jiri Pirko
2020-02-21 9:56 ` [patch net-next 08/10] flow_offload: introduce "delayed" HW stats type and allow it in mlx5 Jiri Pirko
2020-02-21 9:56 ` [patch net-next 09/10] flow_offload: introduce "disabled" HW stats type and allow it in mlxsw Jiri Pirko
2020-02-21 9:56 ` [patch net-next 10/10] sched: cls_flower: allow user to specify type of HW stats for a filter Jiri Pirko
2020-02-21 18:22 ` [patch net-next 00/10] net: allow user specify TC filter HW stats type Jakub Kicinski
2020-02-22 6:38 ` Jiri Pirko
2020-02-24 11:38 ` Edward Cree
2020-02-24 13:11 ` Jiri Pirko [this message]
2020-02-24 15:45 ` Jamal Hadi Salim
2020-02-24 15:50 ` Edward Cree
2020-02-24 15:55 ` Jamal Hadi Salim
2020-02-24 16:25 ` Jiri Pirko
2020-02-25 16:01 ` Jamal Hadi Salim
2020-02-25 16:22 ` Jiri Pirko
2020-02-25 18:06 ` Jakub Kicinski
2020-02-26 12:52 ` Jamal Hadi Salim
2020-02-26 13:56 ` Jiri Pirko
2020-02-28 19:59 ` Pablo Neira Ayuso
2020-02-29 8:01 ` Jiri Pirko
2020-02-29 19:56 ` Pablo Neira Ayuso
2020-03-02 16:07 ` Edward Cree
2020-02-27 15:57 ` Edward Cree
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=20200224131101.GC16270@nanopsycho \
--to=jiri@resnulli.us \
--cc=aelior@marvell.com \
--cc=alexandre.torgue@st.com \
--cc=davem@davemloft.net \
--cc=ecree@solarflare.com \
--cc=idosch@mellanox.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jhs@mojatatu.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=michael.chan@broadcom.com \
--cc=mlxsw@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=peppe.cavallaro@st.com \
--cc=saeedm@mellanox.com \
--cc=vishal@chelsio.com \
--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