linux-kernel - Re: [PATCH v1 net-next 4/6] net: mscc: ocelot: VCAP IS1 support

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: <20200506094345.n4zdgjvctwiz4pkh@ws.localdomain>
Date:   Wed, 6 May 2020 11:43:45 +0200
From:   "Allan W. Nielsen" <allan.nielsen@...rochip.com>
To:     Xiaoliang Yang <xiaoliang.yang_1@....com>
CC:     <po.liu@....com>, <claudiu.manoil@....com>,
        <alexandru.marginean@....com>, <vladimir.oltean@....com>,
        <leoyang.li@....com>, <mingkai.hu@....com>, <andrew@...n.ch>,
        <f.fainelli@...il.com>, <vivien.didelot@...il.com>,
        <davem@...emloft.net>, <jiri@...nulli.us>, <idosch@...sch.org>,
        <kuba@...nel.org>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <horatiu.vultur@...rochip.com>,
        <alexandre.belloni@...tlin.com>, <joergen.andreasen@...rochip.com>,
        <UNGLinuxDriver@...rochip.com>, <nikolay@...ulusnetworks.com>,
        <roopa@...ulusnetworks.com>, <linux-devel@...ux.nxdi.nxp.com>
Subject: Re: [PATCH v1 net-next 4/6] net: mscc: ocelot: VCAP IS1 support

Hi Xiaoliang,

On 06.05.2020 15:48, Xiaoliang Yang wrote:
>VCAP IS1 is a VCAP module which can filter MAC, IP, VLAN, protocol, and
>TCP/UDP ports keys, and do Qos and VLAN retag actions.
>This patch added VCAP IS1 support in ocelot ace driver, which can supports
>vlan modify action of tc filter.
>Usage:
>        tc qdisc add dev swp0 ingress
>        tc filter add dev swp0 protocol 802.1Q parent ffff: flower \
>        skip_sw vlan_id 1 vlan_prio 1 action vlan modify id 2 priority 2
I skimmed skimmed through the patch serie, and the way I understood it
is that you look at the action, and if it is a VLAN operation, then you
put it in IS1 and if it is one of the other then put it in IS2.

This is how the HW is designed - I'm aware of that.

But how will this work if you have 2 rules, 1 modifying the VLAN and
another rule dropping certain packets?

The SW model have these two rules in the same table, and can stop
process at the first match. SW will do the action of the first frame
matching.

The HW will how-ever do both, as they are in independent TCAMs.

If we want to enable all the TCAM lookups in Ocelot/Felix, then we need
to find a way where we will get the same results when doing the
operation in HW and in SW.

/Allan