TDA4VH-Q1: Unclear steps in TI documentation of bridge setup

Matthias Hörger

Part Number: TDA4VH-Q1

Tool/software:

Hi,

To keep the other thread (DRA829J: CPSW9G behaving like a hub - Processors forum - Processors - TI E2E support forums) separate, I start this new thread here.

In the latest TI documentation, to setup a bridge for CPSW9G in native ethernet mode, there are some commands I don't fully understand.

3.2.2.10.3.2.3.1. CPSWng Native Ethernet — Processor SDK Linux for TDA4VM Documentation

At the end of the setup are three mandatory steps (as indicated by [*]).

[*] ip link set dev br0 type bridge vlan_filtering 1
[*] bridge vlan add dev br0 vid 1 self
[*] bridge vlan add dev br0 vid 1 pvid untagged self

Please correct me if I'm wrong. To me the documentation reads as: "you have to run every one of these commands in this exact order".

To me, the two last commands do more or less the same thing.

Add VID 1 to the bridge interface br0 (first command):

bridge vlan add dev br0 vid 1 self

Add VID 1 to the bridge interface br0, but also set VID 1 as PVID and untag packets with VID 1 on egress (second command):

bridge vlan add dev br0 vid 1 pvid untagged self

So both commands add VID 1 to br0. "pvid" and "untagged" are only options. Why do I have to run the first command first?

Why can't I just run

bridge vlan add dev br0 vid 1 pvid untagged self

This command alone will add VID 1 to br0. Just as the first command does. But it will also set up the additional flags.

Further down the documentation adds some explanation to the two commands:

<---- add VLAN as a Bridge Entry

<---- add cpu port to VLAN 1

But "pvid" and "untagged" are just additional option (as stated in the man pages bridge(8) - Linux manual page)

bridge vlan { add | del } dev DEV vid VID [ tunnel_info TUNNEL_ID ] [ pvid ] [ untagged ] [ self ] [ master ]

Is TI somehow using the fact, that the second command adds "pvid" and "untagged" to the command and does something different than when these options are missing?

What is the technical explanation that both commands are needed for CPSW9G?

Regards,

Matthias

23 days ago

0 Tanmay Patil 20 days ago

TI__Mastermind 38790 points

Hi Matthias,

The bridge layer is not modified by TI. We just use hooks in this to hardware offload VLAN filtering and tagging properties.

That means that there is no one specific order or structure to the commands. It depends on how the user configures. The behavior doesn't change from the man pages.

I tried by commenting the command just now and there are differences in the resulting configuration. So it does seem that both commands are required and do different things.

Regards,
Tanmay

0 Matthias Hörger 20 days ago in reply to Tanmay Patil

Prodigy 116 points

Hi Tanmay,

I can see the differences in the configuration on my system as well. But I only see them on the TI hardware. The "bridge" tool has no indication that something is different.

Running "bridge vlan show" always shows this result:

port              vlan-id
xf2               1 PVID Egress Untagged
                    state forwarding mcast_router 1
xf4               1 PVID Egress Untagged
                    state forwarding mcast_router 1
br0               1 PVID Egress Untagged
                    state forwarding mcast_router 1

Only the switch ALE entries show some differences.

If I run the lines from the documentaion:

bridge vlan add dev br0 vid 1 self
bridge vlan add dev br0 vid 1 pvid untagged self

I get a working configuration with:

7: Type: Inner VLAN
 Nolearn Mask = 0x0, Ingress Check = 0
 VLAN ID = 1, Registered Mask = 0x61, No Frag = 0
 Force Untagged Packet Egress = 0x61, Limit Next Header Control = 0, Unregistered Mask = 0x1, Members = 0x61

If I ommit "bridge vlan add dev br0 vid 1 self" and only run this:

bridge vlan add dev br0 vid 1 pvid untagged self

I get a not working configuration:

7: Type: Inner VLAN
 Nolearn Mask = 0x0, Ingress Check = 0
 VLAN ID = 1, Registered Mask = 0x60, No Frag = 0
 Force Untagged Packet Egress = 0x60, Limit Next Header Control = 0, Unregistered Mask = 0x0, Members = 0x60

However, if I slightly change the documentation example to:

bridge vlan add dev br0 vid 1 pvid tagged self
bridge vlan add dev br0 vid 1 pvid untagged self

I again get a working configuratin with:

7: Type: Inner VLAN
 Nolearn Mask = 0x0, Ingress Check = 0
 VLAN ID = 1, Registered Mask = 0x61, No Frag = 0
 Force Untagged Packet Egress = 0x61, Limit Next Header Control = 0, Unregistered Mask = 0x1, Members = 0x61

Yes, both commands are required and do different things. But the difference is only on the TI HW.

This seems very strange to me. I can't imagine how running these two almost identical lines is really making a difference and is always required with every Linux bridge interface. The kernel shows the correct configuration after I run "bridge vlan add dev br0 vid 1 pvid untagged self" and the software solution of the Linux bridge interface also functions correctly after only running this one line.

I only get a working configuration with the TI hardware after I run two almost identical commands.

To me it looks quite clearly that only the TI HW needs both commands to function and this is not a Linux bridge requirement in general. I can't find any other example with a Linux bridge interface where adding a VID requires running the almost identical command twice.

Regards,
Matthias

0 Tanmay Patil 20 days ago in reply to Matthias Hörger

TI__Mastermind 38790 points

Hi Matthias,

Not sure what is happening in the kernel (bridge layer regarding this). But it does seems that the second command is not adding the vid to host port. This could be a bug in kernel or it could have some deliberate reasons to keep it this way for hardware bridges. Moreover, the bridge configuration also works with standard systemd networkd configuration

In any case, there is no issue with TI switchdev layer.

Regards,
Tanmay

0 Matthias Hörger 19 days ago in reply to Tanmay Patil

Prodigy 116 points

Hi Tanmay,

So the technical reason is unclear. We just know that it's needed. It could be a bug or an unknown requirement.

Thanks for your help regardless.

Regards,

Matthias

0 Tanmay Patil 17 days ago in reply to Matthias Hörger

TI__Mastermind 38790 points

Hi Matthias,

Matthias Hörger said:
So the technical reason is unclear. We just know that it's needed.

This is also something I agree with. So it turns out I think the two commands were not needed before kernel 5.10. So there might be some changes in kernel where this is coming from.

Just wanted to let you know.

Regards,
Tanmay