On Tue, Mar 03, 2020 at 06:55:54PM +0000, Edward Cree wrote: > On 02/03/2020 22:49, Jakub Kicinski wrote: > > On Mon, 2 Mar 2020 22:46:59 +0100 Pablo Neira Ayuso wrote: > >> 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: > >>>> 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. > > 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.
