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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.