From: Daniel Borkmann <dan...@iogearbox.net> Date: Fri, 20 Jul 2018 19:28:23 +0200
> This might be fine as new ndo depending on the use case this will have (?), > but fwiw the term 'flow' or 'rule' would be misleading for what tc offload > would be doing today (e.g. to name one, there's no notion of 'flow' in BPF > offload). Given today this interface is deeply baked into tc, just a rename > might not suffice but should probably move the whole handling around it such > as assembling the offload info into generic net/core/netdev.c as well if this > is the way to go. I would much rather see a new NDO for handling a new offload. That is consistent with our overall game plan of the past few years ever since this TC offload NDO went in. We can't pretend to be able to predict the future and know that these various things can be consolidated into a single interface beforehand. It is important to see what implementing a new offload looks like, in a couple of drivers, first. And then we can have something to look at, and discuss, with respect to NDO consolidation. What is happening with this patch is you are brute force making this NDO generic, and then saying "I will show you how it can be generic." Sorry, that's the wrong way around. Make a new NDO op for your flow offloading, show how it works and is implemented in a few drivers, and then (and only then) can you talk about whether consolidating is possible or appropriate. Thank you.
