netdev - Re: [DSA] L2 Forwarding Offload not working

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: <50c35a41-45c2-1f2b-7189-96fe7c0a1740@gmx.net>
Date:   Thu, 9 Jul 2020 14:06:00 +0000
From:   ѽ҉ᶬḳ℠ <vtol@....net>
To:     netdev@...r.kernel.org
Cc:     Andrew Lunn <andrew@...n.ch>
Subject: Re: [DSA] L2 Forwarding Offload not working


On 09/07/2020 13:53, Andrew Lunn wrote:
> On Thu, Jul 09, 2020 at 11:32:00AM +0000, ѽ҉ᶬḳ℠ wrote:
>> "kernel":"5.4.50", "system":"ARMv7 Processor rev 1
>> (v7l)","model":"Turris
>> Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"OpenWrt","version":"SNAPSHOT","revision":"r13719-66e04abbb6","target":"mvebu/cortexa9","}
>>
>> CPU Marvell Armada 385 88F6820 | Switch  Marvell 88E6176
>>
>> soft bridge br-lan enslaving DSA ports lan0 lan1 lan2
>>
>> DSA master device eth1 (subsequent ip l exhibits slaves as lanX@...1)
>> ----------
>>
>> After perusal of
>> https://www.kernel.org/doc/Documentation/networking/switchdev.txt it is
>> my understanding that offloading works only for static FDB entries,
>> though not clear to me:
>>
>> * what the logic is behind, and
>> * why DSA ports are not static FDB entries by default (would only seem
>> logical)
> Hello
>
> With DSA, we have two sets of tables. The switch performs address
> learning, and the software bridge performs address learning. No
> attempt is made to keep these dynamic FDB entries in sync. There is
> not enough bandwidth over the MDIO link to keep the two tables in
> sync. However, when you dump the FDB using the bridge command, you get
> to see the combination of both tables. The hardware will perform
> forwarding based on its table, and the software bridge based on its
> table.. However, if there is no entry in the hardware table for a
> given destination MAC address, it will forward the frame to the
> software bridge, so it can decide what to do with it.
>
> For static FDB entries which the user adds, they are first added to
> the software bridge, and then pushed down to the switch.
>
>      Andrew

Thank you for the instantaneous feedback and insight!

Two questions if you do not mind:

1) does the above apply to all stable kernel releases or only => 5.4?
Because with 4.14 there are reports that dynamic addresses of clients
roaming from a switch port to an bridge port (upstream of the switch,
e.g. WLan AP provided by the router) facing time outs until the switch
retires (ages) the client's MAC.

2) The document
https://www.kernel.org/doc/Documentation/networking/switchdev.txt cites
(for static entries)

bridge command will label these entries "offload"

Is that still up-to-date or rather outdated from the earlier days of DSA?