Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: 8diXjE1BHUCwR7ruJb2Js1oQxx0NR1FxldPu2olFVYsbtwhEjA2IX5vVtD7hMdpcje4QuVxrya
 U0qvMjPIrnkOLvfsY6HIz8V+ounKPbUlIq7AazdCN/BCU8WCG6e/mAWNoQ7o0e9bNRtGeLE/2b
 Vizg3pTMDwOApMBNkDnoxyRNp8d7LJQ6JoWisGN3QkwnO3hr/NcYANbuFN9FgmyROeuHlaeWQ4
 SsFqn/3nkkU/TJeV2vVeNpaDg4KnGww+ZJgonrQ0Ictd0jQZdk+LL/EIDPKxYVmm0vThUr9MEQ
 zmw=
Date:   Wed, 6 May 2020 11:43:45 +0200
From:   "Allan W. Nielsen" <allan.nielsen@microchip.com>
To:     Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
CC:     <po.liu@nxp.com>, <claudiu.manoil@nxp.com>,
        <alexandru.marginean@nxp.com>, <vladimir.oltean@nxp.com>,
        <leoyang.li@nxp.com>, <mingkai.hu@nxp.com>, <andrew@lunn.ch>,
        <f.fainelli@gmail.com>, <vivien.didelot@gmail.com>,
        <davem@davemloft.net>, <jiri@resnulli.us>, <idosch@idosch.org>,
        <kuba@kernel.org>, <netdev@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <horatiu.vultur@microchip.com>,
        <alexandre.belloni@bootlin.com>, <joergen.andreasen@microchip.com>,
        <UNGLinuxDriver@microchip.com>, <nikolay@cumulusnetworks.com>,
        <roopa@cumulusnetworks.com>, <linux-devel@linux.nxdi.nxp.com>
Subject: Re: [PATCH v1 net-next 4/6] net: mscc: ocelot: VCAP IS1 support
Message-ID: <20200506094345.n4zdgjvctwiz4pkh@ws.localdomain>
References: <20200506074900.28529-1-xiaoliang.yang_1@nxp.com>
 <20200506074900.28529-5-xiaoliang.yang_1@nxp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Disposition: inline
In-Reply-To: <20200506074900.28529-5-xiaoliang.yang_1@nxp.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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