From: Edward Cree <ecree@solarflare.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Jakub Kicinski <kuba@kernel.org>, Jiri Pirko <jiri@resnulli.us>,
<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>, <mlxsw@mellanox.com>,
<netfilter-devel@vger.kernel.org>
Subject: Re: [patch net-next v2 01/12] flow_offload: Introduce offload of HW stats type
Date: Tue, 3 Mar 2020 21:06:48 +0000 [thread overview]
Message-ID: <0452cffa-1054-418f-0a5d-8e15afd87969@solarflare.com> (raw)
In-Reply-To: <20200303202739.6nwq3ru2vf62j2ek@salvia>
On 03/03/2020 20:27, Pablo Neira Ayuso wrote:
> On Tue, Mar 03, 2020 at 06:55:54PM +0000, Edward Cree wrote:
>> On 02/03/2020 22:49, Jakub Kicinski wrote:
>>> On Mon, 2 Mar 2020 22:46:59 +0100 Pablo Neira Ayuso wrote:
>>>> On Mon, Mar 02, 2020 at 12:18:52PM -0800, Jakub Kicinski wrote:
>>>>> On Mon, 2 Mar 2020 20:24:37 +0100 Pablo Neira Ayuso wrote:
>>>>>> It looks to me that you want to restrict the API to tc for no good
>>>>>> _technical_ reason.
>> The technical reason is that having two ways to do things where one would
>> suffice means more code to be written, tested, debugged. So if you want
>> to add this you need to convince us that the existing way (a) doesn't
>> meet your needs and (b) can't be extended to cover them.
> One single unified way to express the hardware offload for _every_
> supported frontend is the way to go. The flow_offload API provides a
> framework to model all hardware offloads for each existing front-end.
>
> I understand your motivation might be a specific front-end of your
> choice, that's fair enough.
I think we've misunderstood each other (90% my fault).
When you wrote "restrict the API to tc" I read that as "restrict growth of
the API for flow offloading" (which I *do* want); I've now re-parsed and
believe you meant it as "limit the API so that only tc may use it" (which
is not my desire at all).
Thus, when I spoke of "two ways to do things" I meant that _within_ the
(unified) flow_offload API there should be a single approach to stats
(the counters attached to actions), to which levels above and below it
impedance-match as necessary (e.g. by merging netfilter count actions
onto the following action as Jakub described), rather than bundling
two interfaces (tc-style counters and separate counter actions) into
one API (which would mean that drivers would all need to write code to
handle both kinds, at no gain of expressiveness).
I was *not* referring to tc and netfilter as the "two different ways", but
I can see why you read it that way.
I hope that makes sense now.
-ed
next prev parent reply other threads:[~2020-03-03 21:07 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-28 17:24 [patch net-next v2 00/12] net: allow user specify TC action HW stats type Jiri Pirko
2020-02-28 17:24 ` [patch net-next v2 01/12] flow_offload: Introduce offload of " Jiri Pirko
2020-02-29 19:29 ` Pablo Neira Ayuso
2020-03-01 8:44 ` Jiri Pirko
2020-03-02 13:20 ` Pablo Neira Ayuso
2020-03-02 13:58 ` Jiri Pirko
2020-03-02 16:29 ` Edward Cree
2020-03-02 19:24 ` Pablo Neira Ayuso
2020-03-02 20:18 ` Jakub Kicinski
2020-03-02 21:46 ` Pablo Neira Ayuso
2020-03-02 22:49 ` Jakub Kicinski
2020-03-03 17:25 ` Pablo Neira Ayuso
2020-03-03 19:34 ` Jakub Kicinski
2020-03-03 18:55 ` Edward Cree
2020-03-03 19:26 ` Jakub Kicinski
2020-03-03 20:27 ` Pablo Neira Ayuso
2020-03-03 21:06 ` Edward Cree [this message]
2020-03-03 21:25 ` Pablo Neira Ayuso
2020-03-03 19:13 ` Edward Cree
2020-03-04 14:18 ` Jiri Pirko
2020-02-28 17:24 ` [patch net-next v2 02/12] ocelot_flower: use flow_offload_has_one_action() helper Jiri Pirko
2020-02-29 0:50 ` Vladimir Oltean
2020-02-28 17:24 ` [patch net-next v2 03/12] flow_offload: check for basic action hw stats type Jiri Pirko
2020-02-28 19:40 ` Jakub Kicinski
2020-02-29 7:40 ` Jiri Pirko
2020-02-29 19:18 ` Jakub Kicinski
2020-03-01 9:00 ` Jiri Pirko
2020-03-02 19:33 ` Jakub Kicinski
2020-03-03 11:46 ` Jiri Pirko
2020-02-28 17:24 ` [patch net-next v2 04/12] mlx5: en_tc: Do not allow mixing HW stats types for actions Jiri Pirko
2020-02-28 17:24 ` [patch net-next v2 05/12] mlxsw: spectrum_flower: " Jiri Pirko
2020-02-28 17:24 ` [patch net-next v2 06/12] mlx5: restrict supported HW stats type to "any" Jiri Pirko
2020-02-28 17:25 ` [patch net-next v2 07/12] mlxsw: " Jiri Pirko
2020-02-28 17:25 ` [patch net-next v2 08/12] flow_offload: introduce "immediate" HW stats type and allow it in mlxsw Jiri Pirko
2020-02-29 19:32 ` Pablo Neira Ayuso
2020-03-01 8:47 ` Jiri Pirko
2020-03-02 13:23 ` Pablo Neira Ayuso
2020-03-02 13:59 ` Jiri Pirko
2020-02-28 17:25 ` [patch net-next v2 09/12] flow_offload: introduce "delayed" HW stats type and allow it in mlx5 Jiri Pirko
2020-02-28 17:25 ` [patch net-next v2 10/12] mlxsw: spectrum_acl: Ask device for rule stats only if counter was created Jiri Pirko
2020-02-28 17:25 ` [patch net-next v2 11/12] flow_offload: introduce "disabled" HW stats type and allow it in mlxsw Jiri Pirko
2020-02-28 17:25 ` [patch net-next v2 12/12] sched: act: allow user to specify type of HW stats for a filter Jiri Pirko
2020-02-28 19:59 ` Jakub Kicinski
2020-02-29 7:52 ` Jiri Pirko
2020-02-29 20:14 ` Jakub Kicinski
2020-03-01 8:57 ` Jiri Pirko
2020-03-02 19:39 ` Jakub Kicinski
2020-03-03 13:20 ` Jiri Pirko
2020-03-03 19:48 ` Jakub Kicinski
2020-03-04 8:15 ` Jiri Pirko
2020-03-03 19:44 ` Jakub Kicinski
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=0452cffa-1054-418f-0a5d-8e15afd87969@solarflare.com \
--to=ecree@solarflare.com \
--cc=aelior@marvell.com \
--cc=alexandre.torgue@st.com \
--cc=davem@davemloft.net \
--cc=idosch@mellanox.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=michael.chan@broadcom.com \
--cc=mlxsw@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@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;
as well as URLs for NNTP newsgroup(s).