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  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]
Date:   Sun, 24 May 2020 19:34:54 +0300
From:   Vladimir Oltean <>
To:     Florian Fainelli <>
Cc:     Andrew Lunn <>,
        Vivien Didelot <>,
        "David S. Miller" <>,
        Jiri Pirko <>,
        Ido Schimmel <>,
        Jakub Kicinski <>,
        Ivan Vecera <>,
        netdev <>,
        Horatiu Vultur <>,
        "Allan W. Nielsen" <>,
        Nikolay Aleksandrov <>,
        Roopa Prabhu <>
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 <> wrote:
> Hi Vladimir,
> On 5/21/2020 2:10 PM, Vladimir Oltean wrote:
> > From: Vladimir Oltean <>
> >
> > 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":
> >
> > "[PATCH v3 net-next 2/2] net: dsa: felix: Allow unknown unicast traffic towards the CPU port module":
> >
> > "[PATCH v3 0/2] net: core: Notify on changes to dev->promiscuity":
> >
> > LPC2019 - SwitchDev offload optimizations:
> >
> >
> > 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.


Powered by blists - more mailing lists