[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200420134658.GG6581@nanopsycho.orion>
Date: Mon, 20 Apr 2020 15:46:58 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: Edward Cree <ecree@...arflare.com>,
netfilter-devel@...r.kernel.org, davem@...emloft.net,
netdev@...r.kernel.org, kuba@...nel.org
Subject: Re: [PATCH net] net: flow_offload: skip hw stats check for
FLOW_ACTION_HW_STATS_DISABLED
Mon, Apr 20, 2020 at 02:49:20PM CEST, pablo@...filter.org wrote:
>On Mon, Apr 20, 2020 at 02:36:11PM +0200, Jiri Pirko wrote:
>> Mon, Apr 20, 2020 at 02:28:22PM CEST, ecree@...arflare.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.
User asked for disable. They should be disabled. If driver does not
support it, should not pretend they are disabled. Does not make sense.
>
>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).
Powered by blists - more mailing lists