Message-ID: <CA+h21hoBxX3GWQ7+ehov2eGzhsqodH9RjN0FfVTW6beFFjETBQ@mail.gmail.com>
Date:   Mon, 20 Apr 2020 03:03:23 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     "Allan W. Nielsen" <allan.nielsen@...rochip.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Antoine Tenart <antoine.tenart@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Joergen Andreasen <joergen.andreasen@...rochip.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        netdev <netdev@...r.kernel.org>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        "Y.b. Lu" <yangbo.lu@....com>, Po Liu <po.liu@....com>,
        Jiri Pirko <jiri@...lanox.com>,
        Ido Schimmel <idosch@...sch.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Mingkai Hu <mingkai.hu@....com>
Subject: Re: [PATCH net-next] net: mscc: ocelot: deal with problematic
 MAC_ETYPE VCAP IS2 rules

Hi Allan,

On Sun, 19 Apr 2020 at 21:25, Allan W. Nielsen
<allan.nielsen@...rochip.com> wrote:
>
> On 19.04.2020 17:20, Vladimir Oltean wrote:
> >EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> >On Sun, 19 Apr 2020 at 10:33, Allan W. Nielsen
> ><allan.nielsen@...rochip.com> wrote:
> >>
> >> Hi,
> >>
> >> Sorry I did not manage to provide feedback before it was merged (I will
> >> need to consult some of my colleagues Monday before I can provide the
> >> foll feedback).
> >>
> >> There are many good things in this patch, but it is not only good.
> >>
> >> The problem is that these TCAMs/VCAPs are insanely complicated and it is
> >> really hard to make them fit nicely into the existing tc frame-work
> >> (being hard does not mean that we should not try).
> >>
> >> In this patch, you try to automatic figure out who the user want the
> >> TCAM to be configured. It works for 1 use-case but it breaks others.
> >>
> >> Before this patch you could do a:
> >>      tc filter add dev swp0 ingress protocol ipv4 \
> >>              flower skip_sw src_ip 10.0.0.1 action drop
> >>      tc filter add dev swp0 ingress \
> >>              flower skip_sw src_mac 96:18:82:00:04:01 action drop
> >>
> >> But the second rule would not apply to the ICMP over IPv4 over Ethernet
> >> packet, it would however apply to non-IP packets.
> >>
> >> With this patch it not possible. Your use-case is more common, but the
> >> other one is not unrealistic.
> >>
> >> My concern with this, is that I do not think it is possible to automatic
> >> detect how these TCAMs needs to be configured by only looking at the
> >> rules installed by the user. Trying to do this automatic, also makes the
> >> TCAM logic even harder to understand for the user.
> >>
> >> I would prefer that we by default uses some conservative default
> >> settings which are easy to understand, and then expose some expert
> >> settings in the sysfs, which can be used to achieve different
> >> behavioral.
> >>
> >> Maybe forcing MAC_ETYPE matches is the most conservative and easiest to
> >> understand default.
> >>
> >> But I do seem to recall that there is a way to allow matching on both
> >> SMAC and SIP (your original motivation). This may be a better default
> >> (despite that it consumes more TCAM resources). I will follow up and
> >> check if this is possible.
> >>
> >> Vladimir (and anyone else whom interested): would you be interested in
> >> spending some time discussion the more high-level architectures and
> >> use-cases on how to best integrate this TCAM architecture into the Linux
> >> kernel. Not sure on the outlook for the various conferences, but we
> >> could arrange some online session to discuss this.
> >>
> >> /Allan
> >>
> >
> >And yes, we would be very interested in attending a call for syncing
> >up on integrating the TCAM hardware with the flow offload
> >infrastructure from Linux. Actually at the moment we are trying to add
> >support for offloaded VLAN retagging with the VCAP IS1 and ES0 blocks.
>
> Sounds good - lets spend some time to talk discuss this and see what
> comes out of it.
>
> Ido, if you want to join us, pleaes comment with your preferences. If
> others want to join please let me know.
>
> I can setup a meeting in WebEx or Teams. I'm happy to join on other
> platformws if you prefer. They both works fine from Linux in Chrome and
> FireFox (sometimes tricky to get the sound working in FF).
>
> Proposed agenda:
>
> - Cover the TCAM architecture in Ocelot/Felix (just to make sure we are
>    all on the same page).
> - Present some use-cases MCHP would like to address in future.
> - Open discussion.
>
> I think we will need something between 30-120 minutes depending on how
> the discussion goes.
>
> We are in CEST time - and I'm okay to attend from 7-22.
>
> What about you.
>
> /Allan

>From my side I am available for the entire time interval you
mentioned, since the time zone in Bucharest (GMT+3) is rather close to
Copenhagen. Our colleagues from NXP Beijing might also be interested,
which is probably going to restrict the time interval to the first
half of the day. And you can also schedule for Tuesday if tomorrow is
on too short notice.
Both WebEx and Teams should work, with a slight preference to Teams
since NXP people are already using it.

Thanks,
-Vladimir

Powered by blists - more mailing lists