From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Edward Cree <ecree@solarflare.com>,
netfilter-devel@vger.kernel.org, davem@davemloft.net,
netdev@vger.kernel.org, kuba@kernel.org
Subject: Re: [PATCH net] net: flow_offload: skip hw stats check for FLOW_ACTION_HW_STATS_DISABLED
Date: Mon, 20 Apr 2020 14:49:20 +0200 [thread overview]
Message-ID: <20200420124920.j3edwvc5fwobqhyg@salvia> (raw)
In-Reply-To: <20200420123611.GF6581@nanopsycho.orion>
On Mon, Apr 20, 2020 at 02:36:11PM +0200, Jiri Pirko wrote:
> Mon, Apr 20, 2020 at 02:28:22PM CEST, ecree@solarflare.com wrote:
> >On 20/04/2020 12:52, Jiri Pirko wrote:
> >> However for TC, when user specifies "HW_STATS_DISABLED", the driver
> >> should not do stats.
> >What should a driver do if the user specifies DISABLED, but the stats
> > are still needed for internal bookkeeping (e.g. to prod an ARP entry
> > that's in use for encapsulation offload, so that it doesn't get
> > expired out of the cache)? Enable the stats on the HW anyway but
> > not report them to FLOW_CLS_STATS? Or return an error?
>
> If internally needed, it means they cannot be disabled. So returning
> error would make sense, as what the user requested is not supported.
Hm.
Then, if the user disables counters but there is internal dependency
on them, the tc rule fails to be loaded for this reason.
After this the user is forced to re-load the rule, specifying enable
counters.
Why does the user need to force in this case to reload? It seems more
natural to me to give the user what it is requesting (disabled
counters / front-end doesn't care) and the driver internally allocates
the resources that it needs (actually turn them on if there is a
dependency like tunneling).
next prev parent reply other threads:[~2020-04-20 12:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-19 11:53 [PATCH net] net: flow_offload: skip hw stats check for FLOW_ACTION_HW_STATS_DISABLED Pablo Neira Ayuso
2020-04-20 8:02 ` Jiri Pirko
2020-04-20 9:05 ` Pablo Neira Ayuso
2020-04-20 9:13 ` Jiri Pirko
2020-04-20 10:03 ` Pablo Neira Ayuso
2020-04-20 11:52 ` Jiri Pirko
2020-04-20 12:13 ` Pablo Neira Ayuso
2020-04-20 13:49 ` Jiri Pirko
2020-04-20 12:28 ` Edward Cree
2020-04-20 12:36 ` Jiri Pirko
2020-04-20 12:49 ` Pablo Neira Ayuso [this message]
2020-04-20 13:46 ` Jiri Pirko
2020-04-20 12:39 ` Pablo Neira Ayuso
2020-04-20 13:48 ` Jiri Pirko
2020-04-20 13:57 ` Florian Westphal
2020-04-20 14:14 ` Jiri Pirko
2020-04-20 19:18 ` Pablo Neira Ayuso
2020-04-22 18:37 ` Jiri Pirko
2020-04-27 14:31 ` Edward Cree
2020-04-27 18:12 ` 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=20200420124920.j3edwvc5fwobqhyg@salvia \
--to=pablo@netfilter.org \
--cc=davem@davemloft.net \
--cc=ecree@solarflare.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
/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