netdev - Re: [PATCH net-next 0/4] net: dsa: bcm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <be2a5c66-190a-1d10-16a0-22d1b96ef1c9@gmail.com>
Date:   Fri, 27 Jan 2017 13:58:11 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Chris Healy <cphealy@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next 0/4] net: dsa: bcm_sf2: CFP support

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!
--
Florian