Hi Chris,

On 01/27/2017 01:24 PM, Chris Healy wrote:

Hi Florian,

In saying the below, I may just be showing my naivety but here goes:

If I understand this correctly, what you are using is similar to the
TCAM hardware present in the newer Marvell switches.  I think Pablo is
doing some work with nftables and HW offload using TCAM HW.  Is there
overlap here?  It seems that one or the other API should be used but
not both.

Well, the problem is that there is overlap with 3 different unrelated
subsystems accessing the same HW here: tc, ethtool, and netfilter, all
(two at least) with different ways of formatting input parameters, as I
pointed out a while back in this thread:
https://www.mail-archive.com/netdev@vger.kernel.org/msg126321.html

My angle on this submission is the following, purely based on pragmatism:

- I have real users behind this feature who are currently very happy
with how this works using ethtool, switching them to netlink, tc,
netfilter is not trivial, but could be done in the long run, not just
now. At the very least, this serves as reference code for people who are
curious to see how Broadcom's CFP works

- cls_flower was looked at, it is missing a critical feature IMHO which
is the ability to specify a rule index, and the amount of code necessary
to validate input parameters is just totally insane, just like the fact
that there is not a common intermediate input representation (ala
ethtool_rx_flow_spec) makes it impractical

- I have heard about the work Pablo is doing, but until it is publicly
submitted and reviewed, it's hard to project what it is going to look like

Thanks!