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;
MIME-Version: 1.0
References: <20200602051828.5734-1-xiaoliang.yang_1@nxp.com>
 <CA+h21hp5K8BvNSuWKuAc_tVYeLpRUqrZtfvFz+3hdLWcAOfMag@mail.gmail.com> <DB8PR04MB5785D8DA658A4557973EA233F08B0@DB8PR04MB5785.eurprd04.prod.outlook.com>
In-Reply-To: <DB8PR04MB5785D8DA658A4557973EA233F08B0@DB8PR04MB5785.eurprd04.prod.outlook.com>
From:   Vladimir Oltean <olteanv@gmail.com>
Date:   Tue, 9 Jun 2020 14:35:39 +0300
Message-ID: <CA+h21hpK6iuzyVCLbosUSGcdqCERxpE4WbZrgeB1C6sKmSrK2Q@mail.gmail.com>
Subject: Re: [EXT] Re: [PATCH v2 net-next 00/10] net: ocelot: VCAP IS1 and ES0 support
To:     Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
Cc:     Po Liu <po.liu@nxp.com>, Claudiu Manoil <claudiu.manoil@nxp.com>,
        Alexandru Marginean <alexandru.marginean@nxp.com>,
        Vladimir Oltean <vladimir.oltean@nxp.com>,
        Leo Li <leoyang.li@nxp.com>, Mingkai Hu <mingkai.hu@nxp.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jiri Pirko <jiri@resnulli.us>,
        Ido Schimmel <idosch@idosch.org>,
        Jakub Kicinski <kuba@kernel.org>,
        Vinicius Costa Gomes <vinicius.gomes@intel.com>,
        Nikolay Aleksandrov <nikolay@cumulusnetworks.com>,
        Roopa Prabhu <roopa@cumulusnetworks.com>,
        netdev <netdev@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        Horatiu Vultur <horatiu.vultur@microchip.com>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        "Allan W. Nielsen" <allan.nielsen@microchip.com>,
        Joergen Andreasen <joergen.andreasen@microchip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
        "linux-devel@linux.nxdi.nxp.com" <linux-devel@linux.nxdi.nxp.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Xiaoliang,

On Tue, 2 Jun 2020 at 11:50, Xiaoliang Yang <xiaoliang.yang_1@nxp.com> wrot=
e:
>
> Hi Vladimir,
>
> On Tus, 2 Jun 2020 at 16:04,
> > First of all, net-next has just closed yesterday and will be closed for=
 the following 2 weeks:
> > https://eur01.safelinks.protection.outlook.com/?url=3Dhttp:%2F%2Fvger.k=
ernel.org%2F~davem%2Fnet-next.html&amp;data=3D02%7C01% 7Cxiaoliang.yang_1%4=
0nxp.com%7C2fad4495dabc4f4ca5fd08d806cb70af%7C686ea1d3bc2b4c6fa92cd99c5c301=
635%7C0%7C0%7C637266818117666386&amp;sdata=3DziVybWb4HzYXanehF5KwNv5RJL%2BZ=
z6NeFvrZWg657B8%3D&amp;reserved=3D0
> >
> > Secondly, could you give an example of how different chains could expre=
ss the fact that rules are executed in parallel between the IS1,
> > IS2 and ES0 TCAMs?
> >
>
> Different TCAMs are not running in parallel, they have flow order: IS1->I=
S2->ES0. Using goto chain to express the flow order.
> For example:
>         tc qdisc add dev swp0 ingress
>         tc filter add dev swp0 chain 0 protocol 802.1Q parent ffff: flowe=
r skip_sw vlan_id 1 vlan_prio 1 action vlan modify id 2 priority 2 action g=
oto chain 1
>         tc filter add dev swp0 chain 1 protocol 802.1Q parent ffff: flowe=
r skip_sw vlan_id 2 vlan_prio 2 action drop
> In this example, package with (vid=3D1,pcp=3D1) vlan tag will be modified=
 to (vid=3D2,pcp=3D2) vlan tag on IS1, then will be dropped on IS2.
>
> If there is no rule match on IS1, it will still lookup on IS2. We can set=
 a rule on chain 0 to express this:
>         tc filter add dev swp0 chain 0 parent ffff: flower skip_sw action=
 goto chain 1
>
> In addition, VSC9959 chip has PSFP and "Sequence Generation recovery" mod=
ules are running after IS2, the flow order like this: IS1->IS2->PSFP-> "Seq=
uence Generation recovery" ->ES0, we can also add chains like this to expre=
ss these two modules in future.
>

I've been pondering over what is a good abstraction for 802.1CB and I
don't think that it would be a tc action. After reading Annex C "Frame
Replication and Elimination for Reliability in systems" in
8021CB-2017, I think maybe it should be modeled as a stacked net
device a la hsr, but with the ability to add its own stream filtering
rules and actions (a la bridge fdb).
But for the PSFP policers, in principle I think you are correct, we
could designate a static chain id for those.

> BTW, where should I sent patches to due to net-next closed?
>

You can keep sending patches just as you did. There's nothing wrong
with doing that as long as you're only doing it for the feedback (RFC
=3D=3D Request For Comments).
Since David receives a lot of patches and the backlog builds up very
quickly, he just rejects patches sent to net-next during the merge
window instead of queuing them up.
Patches that are bugfixes (not the case here, just in general) can be
sent to the net tree at all times (even during the merge window).
In all cases, the mailing list is the same, just the --subject-prefix
is different (net, net-next, rfc).

> Thanks,
> Xiaoliang Yang

Thanks,
-Vladimir