On Tue, Mar 03, 2020 at 06:55:54PM +0000, Edward Cree wrote:

On 02/03/2020 22:49, Jakub Kicinski wrote:

quoted

On Mon, 2 Mar 2020 22:46:59 +0100 Pablo Neira Ayuso wrote:

quoted

On Mon, Mar 02, 2020 at 12:18:52PM -0800, Jakub Kicinski wrote:

quoted

On Mon, 2 Mar 2020 20:24:37 +0100 Pablo Neira Ayuso wrote:  

quoted

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.

quoted

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.

For the record, I produced a patch series[1] to support that, but it
 wasn't acceptable because none of the in-tree drivers implemented the
 facility.  My hope is that we'll be upstreaming our new driver Real
 Soon Now™, at which point I'll rebase and repost those changes.
Alternatively if any other vendor wants to support it in their driver
 they could use those patches as a base.

Great, I am very much looking forward to reviewing your upstream code.

Just keep in my mind that whatever proposal you make must work for
netfilter too.

Thank you.