[DSA] L2 Forwarding Offload not working

[DSA] L2 Forwarding Offload not working

[ѽ҉ᶬḳ℠]

"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@eth1)
----------

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)

That said queried bridge fdb for lan2 (as example here), producing:

44:8a:5b:47:0b:c2 dev lan2 master br-lan
44:8a:5b:47:0b:c2 dev lan2 vlan 1 self

then went ahead with

bridge fdb add 44:8a:5b:47:0b:c2 dev lan2 vlan 1 self

resulting in

44:8a:5b:47:0b:c2 dev lan2 master br-lan
44:8a:5b:47:0b:c2 dev lan2 vlan 1 self static

So it is static now but nothing about offload still. Next up

ip l s br-lan ty bridge vlan_filtering 1

checking again bridge fdb and now exhibiting

44:8a:5b:47:0b:c2 dev lan2 vlan 1 master br-lan
44:8a:5b:47:0b:c2 dev lan2 master br-lan
44:8a:5b:47:0b:c2 dev lan2 vlan 1 self static

Do I suffer some sort of misconception of how to get it working, missing
something?

Re: [DSA] L2 Forwarding Offload not working

[Andrew Lunn]

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@eth1)
> ----------
> 
> 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

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@eth1)
>> ----------
>>
>> 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?

Re: [DSA] L2 Forwarding Offload not working

[Andrew Lunn]

> 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.

DSA has always worked like this.

It does however very from switch to switch. When adding a new switch,
the first version of the driver sometimes does not support offloading.
All frames are forwarded to the software bridge, and the software
bridge does all the work. Then the driver gets extended, to support
the hardware doing the work. And the driver gets extended again to
allow static FDB entries to be passed to the hardware. DSA drivers are
not 'big bang'. It is not all or nothing. They gain features with
time. So you need to look at the driver in your specific version of
the kernel to see what it supports. And you might need to be careful
with the OpenWRT kernel, see if they have backported features.

> 
> 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?

It should be true. But you need a reasonably recent iproute2 for this
to be shown.

   Andrew

Re: [DSA] L2 Forwarding Offload not working

[ѽ҉ᶬḳ℠]

On 09/07/2020 14:35, Andrew Lunn wrote:
>> 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.
> DSA has always worked like this.
>
> It does however very from switch to switch. When adding a new switch,
> the first version of the driver sometimes does not support offloading.
> All frames are forwarded to the software bridge, and the software
> bridge does all the work. Then the driver gets extended, to support
> the hardware doing the work. And the driver gets extended again to
> allow static FDB entries to be passed to the hardware. DSA drivers are
> not 'big bang'. It is not all or nothing. They gain features with
> time. So you need to look at the driver in your specific version of
> the kernel to see what it supports. And you might need to be careful
> with the OpenWRT kernel, see if they have backported features.
>
>> 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?
> It should be true. But you need a reasonably recent iproute2 for this
> to be shown.
>
>     Andrew

The distro backported bridge from 5.7 (ip-bridge 5.7.0-1)

but the offload label does not show, which I would reckon does make
sense anyway for the DSA ports (or should it anyway?) but then attempted
to add a MAC to a WLan port (mPCIe to CPUl), e.g.

bridge fdb add MAC dev WLan_5G vlan 1 self

which printed

RTNETLINK answers: Invalid argument

and

bridge fdb add MAC dev WLan_5G self

which worked but does not show the offload label either, instead when
queried with bridge fdb exhibiting:

MAC dev WLan_5G self permanent