Message-ID: <CA+h21hqHnH3BwyQp-SDk-=aV+7Ms+08b+Rzw1=OpXEhha+Nh0Q@mail.gmail.com>
Date:   Sun, 24 May 2020 19:34:54 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jiri Pirko <jiri@...nulli.us>,
        Ido Schimmel <idosch@...sch.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Ivan Vecera <ivecera@...hat.com>,
        netdev <netdev@...r.kernel.org>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        "Allan W. Nielsen" <allan.nielsen@...rochip.com>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [PATCH RFC net-next 00/13] RX filtering for DSA switches

Hi Florian,

On Sun, 24 May 2020 at 19:13, Florian Fainelli <f.fainelli@...il.com> wrote:
>
> Hi Vladimir,
>
> On 5/21/2020 2:10 PM, Vladimir Oltean wrote:
> > From: Vladimir Oltean <vladimir.oltean@....com>
> >
> > This is a WIP series whose stated goal is to allow DSA and switchdev
> > drivers to flood less traffic to the CPU while keeping the same level of
> > functionality.
> >
> > The strategy is to whitelist towards the CPU only the {DMAC, VLAN} pairs
> > that the operating system has expressed its interest in, either due to
> > those being the MAC addresses of one of the switch ports, or addresses
> > added to our device's RX filter via calls to dev_uc_add/dev_mc_add.
> > Then, the traffic which is not explicitly whitelisted is not sent by the
> > hardware to the CPU, under the assumption that the CPU didn't ask for it
> > and would have dropped it anyway.
> >
> > The ground for these patches were the discussions surrounding RX
> > filtering with switchdev in general, as well as with DSA in particular:
> >
> > "[PATCH net-next 0/4] DSA: promisc on master, generic flow dissector code":
> > https://www.spinics.net/lists/netdev/msg651922.html
> > "[PATCH v3 net-next 2/2] net: dsa: felix: Allow unknown unicast traffic towards the CPU port module":
> > https://www.spinics.net/lists/netdev/msg634859.html
> > "[PATCH v3 0/2] net: core: Notify on changes to dev->promiscuity":
> > https://lkml.org/lkml/2019/8/29/255
> > LPC2019 - SwitchDev offload optimizations:
> > https://www.youtube.com/watch?v=B1HhxEcU7Jg
> >
> > Unicast filtering comes to me as most important, and this includes
> > termination of MAC addresses corresponding to the network interfaces in
> > the system (DSA switch ports, VLAN sub-interfaces, bridge interface).
> > The first 4 patches use Ivan Khoronzhuk's IVDF framework for extending
> > network interface addresses with a Virtual ID (typically VLAN ID). This
> > matches DSA switches perfectly because their FDB already contains keys
> > of the {DMAC, VID} form.
> >
> > Multicast filtering was taken and reworked from Florian Fainelli's
> > previous attempts, according to my own understanding of multicast
> > forwarding requirements of an IGMP snooping switch. This is the part
> > that needs the most extra work, not only in the DSA core but also in
> > drivers. For this reason, I've left out of this patchset anything that
> > has to do with driver-level configuration (since the audience is a bit
> > larger than usual), as I'm trying to focus more on policy for now, and
> > the series is already pretty huge.
>
>
> First off, thank you very much for collecting the various patches and
> bringing them up to date, so far I only had a cursory look at your
> patches and they do look good to me in principle. I plan on testing this
> next week with the b53/bcm_sf2 switches and give you some more detailed
> feedback.
>
> Which of UC or MC filtering do you value the most for your use cases?
> For me it would be MC filtering because the environment is usually
> Set-top-box and streaming devices.
> --
> Florian

Actually one of my main motivations has to do with the fact that with
sja1105, I can only deliver up to 32 unique VLANs to the CPU. But I do
want to be able to use the other ~2000 VLANs in an
autonomous-forwarding manner. So I need to do very strict bookkeeping
of {DMAC, VLAN} addresses that the operating system needs to see,
because the CPU port will not be a member of the
autonomously-forwarded VLANs.
So it's not that I value unicast filtering more than multicast
filtering - I need to do both before I can achieve this goal, but at
the moment I have some trouble setting up IGMP snooping to work
properly on a device that doesn't look beyond L2 headers. With
Ocelot/Felix that is easier, but it has some challenges of its own.

Thanks,
-Vladimir

Powered by blists - more mailing lists