netdev - Re: [PATCH net-next] net: mscc: ocelot: Workaround to allow traffic to CPU in standalone mode

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <CA+h21hp5NQNJJ5agMPAZ+edaZ+ouSjTJ8DypYR5Htx3ZT5iSYA@mail.gmail.com>
Date:   Wed, 19 Feb 2020 16:05:08 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     "Allan W. Nielsen" <allan.nielsen@...rochip.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        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>
Subject: Re: [PATCH net-next] net: mscc: ocelot: Workaround to allow traffic
 to CPU in standalone mode

On Wed, 19 Feb 2020 at 12:17, Allan W. Nielsen
<allan.nielsen@...rochip.com> wrote:
>
> With Ocelot we do not see this spamming - and I still do not understand
> why this is seen with Felix.
>

I should have watched my words.
When doing what all the other DSA switches do, which is enabling a
bulk forwarding path between the front-panel ports and the CPU, the
Ocelot switch core is more susceptible to doing more software
processing work than other devices in its class, for the same end
effect of dropping packets that the CPU is not interested in (say an
unknown unicast MAC that is not present in the switch FDB nor in the
DSA master's RX filter). In such a scenario, any other DSA system
would have the host port drop these packets in hardware, by virtue of
the unknown unicast MAC not being being present RX filter. With
Ocelot, this mechanism that prevents software work being done for
dropping is subverted. So to avoid this design limitation, the Ocelot
core does not enable a bulk forwarding path between the front-panel
ports and the CPU.

Hope this is clearer.

-Vladimir