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:
> > On Mon, Mar 02, 2020 at 04:29:32PM +0000, Edward Cree wrote:
> > > On 02/03/2020 13:20, Pablo Neira Ayuso wrote:
> > > > 2) explicit counter action, in this case the user specifies explicitly
> > > > that it needs a counter in a given position of the rule. This
> > > > counter might come before or after the actual action.
> > >
> > > But the existing API can already do this, with a gact pipe. Plus, Jiri's
> > > new API will allow specifying a counter on any action (rather than only,
> > > implicitly, those which have .stats_update()) should that prove to be
> > > necessary.
> > >
> > > I really think the 'explicit counter action' is a solution in search of a
> > > problem, let's not add random orthogonality violations. (Equally if the
> > > counter action had been there first, I'd be against adding counters to
> > > the other actions.)
> >
> > It looks to me that you want to restrict the API to tc for no good
> > _technical_ reason.
>
> Undeniably part of the reason is that given how complex flow offloads
> got there may be some resistance to large re-factoring. IMHO well
> thought out refactoring of stats is needed.. but I'm not convinced
> this is the direction.
>
> Could you give us clearer understanding of what the use cases for the
> counter action is?
>
> AFAIK right now actions do the accounting on input. That seems like the
> only logical option. Either action takes the packet out of the action
> pipeline, in which case even the counter action after will not see it,
> or it doesn't and the input counter of the next action can be used.
>
> Given counters must be next to real actions and not other counter
> to have value, having them as a separate action seems to make no
> difference at all (if users are silly, we can use the pipe/no-op).
This model that is proposed here is correct in the tc world, where
counters are tied to actions (as you describe above). However, the
flow_offload API already supports for ethtool and netfilter these
days.
In Netfilter, counters are detached from actions. Obviously, a counter
must be placed before the action _if_ the action gets the packet out
of the pipeline, e.g.
ip saddr 1.1.1.1 counter drop
In this case, the counter is placed before the 'drop' action. Users
that need no counters have to remove 'counter' from the rule syntax to
opt-out.
> IOW modeling the stats as attribute of other actions or a separate
> action is entirely equivalent, and there's nothing to be gained from
> moving from the existing scheme to explicit actions... other than it'd
> make it look more like nft actions... :)
I just wonder if a model that allows tc and netfilter to use this new
statistics infrastructure would make everyone happy. My understanding
is that it is not far away from what this patchset provides.
The retorical question here probably is if you still want to allow the
Netfilter front-end to benefit from this new flow_action API
extension.
The real question is: if you think this tc counter+action scheme can
be used by netfilter, then please explain how.
