netdev - Re: [PATCH v2 net-next 0/2] Allow unknown unicast traffic to CPU for Felix DSA

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: <20200225134316.yoy5hqlhkmt6ctz4@lx-anielsen.microsemi.net>
Date:   Tue, 25 Feb 2020 14:43:16 +0100
From:   "Allan W. Nielsen" <allan.nielsen@...rochip.com>
To:     Vladimir Oltean <olteanv@...il.com>
CC:     "David S. Miller" <davem@...emloft.net>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...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>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        "Y.b. Lu" <yangbo.lu@....com>, netdev <netdev@...r.kernel.org>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH v2 net-next 0/2] Allow unknown unicast traffic to CPU for
 Felix DSA

On 25.02.2020 15:08, Vladimir Oltean wrote:
>On Tue, 25 Feb 2020 at 15:02, Allan W. Nielsen
><allan.nielsen@...rochip.com> wrote:
>>
>> On 24.02.2020 23:34, Vladimir Oltean wrote:
>> >From: Vladimir Oltean <vladimir.oltean@....com>
>> >
>> >This is the continuation of the previous "[PATCH net-next] net: mscc:
>> >ocelot: Workaround to allow traffic to CPU in standalone mode":
>> >
>> >https://www.spinics.net/lists/netdev/msg631067.html
>> >
>> >Following the feedback received from Allan Nielsen, the Ocelot and Felix
>> >drivers were made to use the CPU port module in the same way (patch 1),
>> >and Felix was made to additionally allow unknown unicast frames towards
>> >the CPU port module (patch 2).
>> >
>> >Vladimir Oltean (2):
>> >  net: mscc: ocelot: eliminate confusion between CPU and NPI port
>> >  net: dsa: felix: Allow unknown unicast traffic towards the CPU port
>> >    module
>> >
>> > drivers/net/dsa/ocelot/felix.c           | 16 ++++--
>> > drivers/net/ethernet/mscc/ocelot.c       | 62 +++++++++++++---------
>> > drivers/net/ethernet/mscc/ocelot.h       | 10 ----
>> > drivers/net/ethernet/mscc/ocelot_board.c |  5 +-
>> > include/soc/mscc/ocelot.h                | 67 ++++++++++++++++++++++--
>> > net/dsa/tag_ocelot.c                     |  3 +-
>> > 6 files changed, 117 insertions(+), 46 deletions(-)
>> Did this fix you original issue with the spamming of the CPU?
>No, the entire handling of unknown unicast packets still leaves a lot
>to be desired, but at least now the CPU gets those frames, which is
>better than it not getting them.
>For one thing, an unknown unicast packet received by a standalone
>Felix port will still consume CPU cycles dropping it, whereas the same
>thing cannot be said for a different DSA switch setup, say a sja1105
>switch inheriting the MAC address from the DSA master, because the DSA
>master drops that.
>Secondly, even traffic that the CPU _intends_ to terminate remains
>"unknown" from the switch's perspective, due to the
>no-learning-from-injected-traffic issue. So that traffic is still
>going to be flooded, potentially to unwanted ports as well.
Strange, it does sounds like something is not right, but it is really
hard to debug without having the HW.

If we find the time, then Horatiu and I discuss doing a DSA driver for
the VSC7511 (4 port Ocelot without the MIPS CPU). That target should
behave exactly as Felix.

/Allan