On Mon, Mar 02, 2020 at 02:49:28PM -0800, Jakub Kicinski wrote: > On Mon, 2 Mar 2020 22:46:59 +0100 Pablo Neira Ayuso wrote: [...] > > The real question is: if you think this tc counter+action scheme can > > be used by netfilter, then please explain how. > > In Jiri's latest patch set the counter type is per action, so just > "merge right" the counter info into the next action and the models > are converted. The input "merge right" approach might work. > If user is silly and has multiple counter actions in a row - the > pipe/no-op action comes into play (that isn't part of this set, > as Jiri said). Probably gact pipe action with counters can be mapped to the counter action that netfilter needs. Is this a valid use-case you consider for the tc hardware offload? > Can you give us examples of what wouldn't work? Can you for instance > share the counter across rules? Yes, there might be counters that are shared accross rules, see nfacct. Two different rules might refer to the same counter, IIRC there is a way to do this in tc too. > Also neither proposal addresses the problem of reporting _different_ > counter values at different stages in the pipeline, i.e. moving from > stats per flow to per action. But nobody seems to be willing to work > on that. You mean, in case that different counter types are specified, eg. one action using delayed and another action using immediate? > AFAICT with Jiri's change we only need one check in the drivers to > convert from old scheme to new, with explicit action we need two > (additional one being ignoring the counter action). Not a big deal, > but 1 is less than 2 🤷♂️ What changes are expected to retrieve counter stats? Will per-flow stats remain in place after this place? Thank you.
