DRA821U: cpsw5g VLAN configuration

Hi,

This would require adding VLAN configuration rules to the ALE and Policer on the EthFW side. I will forward query to the team and answer your query.

Thanks.

Please refer to the below APIs for configuring ALE.

https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/08_02_00_05/exports/docs/pdk_jacinto_08_02_00_21/docs/apiguide/j721e/html/group__CPSW__ALE__MOD.html

Please also refer to the below FAQ for example to program ALE table.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1011237/faq-tda4vm-how-to-configure-cpsw-5g-9g-ale

Regards,
Stanley

Thanks Stanley and Praveen!

We are resolving some setup issues with VLAN tags at our end. Could you please help with follow-up questions

Questions:

1) UNTAG ethernet packets on ingress

• From documentation link 
  
  • I saw force untag packets on egress but couldn't find one for untagging vlan on ingress. Could you please let me know how to add support for this?
  • 

2 ) How to set egress port priority? 

Thanks,

Swapna

Swapna,

I think the problem statement needs to be rephrased in terms of what CPSW supports. Let me try to explain what's supported.

CPSW supports force untagging on egress.

For untagged packets at ingress, port's default VLAN determines what VID and PCP values assigned at ingress. This default VLAN/PCP is passed via CpswMacPortCfg which is part of the PortLinkCfg struct:

• https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-
• jacinto7/08_01_00_11/exports/docs/pdk_jacinto_08_01_00_33/docs/apiguide/j721e/html/structEnetPer__PortLinkCfg.html
• https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/08_01_00_11/exports/docs/pdk_jacinto_08_01_00_33/docs/apiguide/j721e/html/structCpswMacPort__Cfg.html

CPSW has 3 priority levels:

• Packet priority - Determined at ingress from the VLAN PCP field for tagged packets, or from port's default VLAN.
• Header packet priority - Remapped from packet priority (this is used for priority regeneration)
  • See https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/08_01_00_11/exports/docs/pdk_jacinto_08_01_00_33/docs/apiguide/j721e/html/group__ENET__MOD__MACPORT.html#ggaae019ccdc5a774caa8ffdb35123ca59da07a66f83086b012ff7e4dffaaf2c252e
• Switch priority - Remapped from header packet priority (determines which egress queue the packet is placed on)
  
  • See https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/08_01_00_11/exports/docs/pdk_jacinto_08_01_00_33/docs/apiguide/j721e/html/group__ENET__MOD__MACPORT.html#ggaae019ccdc5a774caa8ffdb35123ca59da65396bbc7

So, if you want packets egress with priority 6, you will have to remap the needed priorities to header-packet-piority value of 6.

Regards,
-Misa

Thanks Misa!

I have follow up questions for you and praveen based on recommended VLAN settings in code above https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1011237/faq-tda4vm-how-to-configure-cpsw-5g-9g-ale

We used above example for setting static VLAN12 in RTOS code and on QNX we set up the interfaces as below

Able to ping 8.8.8.8 and gateway 10.13.168.1 but pinging other DRA821 PCBA on same subnet with same SW changes(different mac) failed.

We can see broadcast messages for PCBA1 on network but tcpdump on PCBA2 couldn't see ICMP BCAST messages.

# SOCK=/alt ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=110 time=8 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=110 time=8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=110 time=7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=8 ms

# SOCK=/alt ping 10.13.169.1
PING 10.13.169.1 (10.13.169.1): 56 data bytes
64 bytes from 10.13.169.1: icmp_seq=0 ttl=64 time=0 ms
64 bytes from 10.13.169.1: icmp_seq=1 ttl=64 time=0 ms

# SOCK=/alt ping 10.13.169.61
PING 10.13.169.61 (10.13.169.61): 56 data bytes
ping: sendto: Host is down

ALE Table:

0: Vlanid: 012c, UTagged: 1ff, Mult: 1ff, UMult: 0, Member: 1ff RAW:[0 212c1ff1 ff0001ff]
1: Vlanid: 0001, UTagged: 13, Mult: 13, UMult: 0, Member: 13 RAW:[0 20010130 13000013]
2: Vlanid: 0191, UTagged: 1ff, Mult: 1ff, UMult: 0, Member: 1ff RAW:[0 21911ff1 ff0001ff]
3: Vlanid: 0192, UTagged: 1ff, Mult: 1ff, UMult: 0, Member: 1ff RAW:[0 21921ff1 ff0001ff]
4: Address: ffffffffffff, Member:01f Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[7c 1000ffff ffffffff]
5: Address: 70ff761d92c2, Port: 000 Se=1 Bl=0 TOUCH=0 AGE=0 TRUNK=0 RAW:[1 100070ff 761d92c2]
6: EtherType: 0806 RAW:[1 20000000 00000806]
7: Address: aabbccddee01, Port: 000 Se=1 Bl=0 TOUCH=0 AGE=0 TRUNK=0 RAW:[1 1000aabb ccddee01]
8: Vlanid: 000c, UTagged: 0, Mult: 13, UMult: 13, Member: 13 RAW:[0 200c0130 00013013]
16: Address: 68ff7b11bfa9, Port: 001 Se=0 Bl=0 TOUCH=0 AGE=1 TRUNK=0 RAW:[4 500168ff 7b11bfa9]
17: Address: 00187475f600, Port: 001 Se=0 Bl=0 TOUCH=0 AGE=1 TRUNK=0 RAW:[4 500c0018 7475f600]
33: Address: aabbccddee04, Port: 001 Se=0 Bl=0 TOUCH=0 AGE=1 TRUNK=0 RAW:[4 5001aabb ccddee04]
34: Address: 00307b3700c1, Port: 001 Se=0 Bl=0 TOUCH=1 AGE=1 TRUNK=0 RAW:[4 d00c0030 7b3700c1]

Would you help us understand why would this happen or if any of the above settings don't look correct?

• Looks like devices on same subnet with VLAN tags enabled cannot ping each other ( Broadcast traffic doesn't get passed through A72 )? 
  • Documentation for SDK 8.1 says broadcast/shared multicast uses intercore virtual ethernet driver and broadcast traffic is routed from R5F_0 to other cores are there any filters based on subnet or should it be enabled from remote clients somewhere in code?
• Please advise if TI has evaluated such usecase with VLAN's on same subnet using TISDK 8.1 QNX+RTOS image? This is gating our customer development and would appreciate your response.

Thank You,

Swapna 

Sapna

Can you help summarize the exact use case needs.

I see double headed arrows between PCB1<-->PCB3 and PCB2<-->PCB3, does this imply ping in both directions are working . and in case of PCB1-->PCB2, uni-directional ping fails.

Is the QNX/VLAN SW configuration and ALE configuration identical across all the 3 instances of DRA821. For the ping traffic do you expect the traffic on the wire between the PCBs to be vlan tagged.

Is any of the ping traffic passing through the vlan tagged switch and what is configuration at the switch side for such traffic.

I feel the overall usage of vlan/subnet partitioning is not well understood in this case.

The very purpose of using VLAN is restrict the broadcast domain - traffic including broadcast/multicast is confined to the respective VLANs alone and not forwarded outside the VLAN. The general usage model is to group nodes under a subnet using a specific VLAN ID

Can you review your use case needs from VLAN partitioning and usage perspective

Regards

sriram

Thanks Sriram!

• Please find the answers below

All PCBA's above have the same SW loaded

I see double headed arrows between PCB1<-->PCB3 and PCB2<-->PCB3, does this imply ping in both directions are working . and in case of PCB1-->PCB2, uni-directional ping fails.

• Ping between PCBA1 and PCBA2 does not work in both directions

Is the QNX/VLAN SW configuration and ALE configuration identical across all the 3 instances of DRA821. For the ping traffic do you expect the traffic on the wire between the PCBs to be vlan tagged.

• Correct the traffic is always VLAN tagged

Is any of the ping traffic passing through the vlan tagged switch and what is configuration at the switch side for such traffic.

• Yes, the traffic is passing through the external VLAN tagged switch

Follow up questions:

We can fix this problem by adding a static entry in the arp cache " arp -s 10.13.169.x aa:bb:cc:dd:ee:0x" on PCBA1 and PCBA2 but need permanent solution.

• I think the VLAN traffic with broadcast frames is not passing through the cpsw5g switch . Could you please review the ALE table and tell us if we need a separate entry for broadcast addresses with VLAN tags? Currently, we see

                         4: Address: ffffffffffff, Member:01f Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[7c 1000ffff ffffffff]

• Can we have two broadcast addresses entry in ALE table one for non vlan traffic and other for VLAN traffic as below

                         4: Address: ffffffffffff, Member:01f Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[7c 1000ffff ffffffff]

                         5. Vlanid: 000c,  Address: ffffffffffff, Member:01f Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[x]

If so, Please share a sample code on how to achieve this

Thanks,

Swapna

Any update on this request please?

Hi Swapna,

As you may know, ARP request packets are handled by Ethernet Firmware on behalf of the remote clients (like QNX virtual client driver) which had registered their MAC address + IP address pair.

This is implemented as follows:

1. In hardware - using an ALE classifier to route ARP packets to an UDMA RX flow allocated by Ethernet Firmware solely for ARP traffic. I have verified this, and packets with and without VLAN are being routed to this RX flow.

2. In software - packets received on this RX flow are passed to Enet LLD's lwIP adaptation layer, which ultimately passes the lwIP pbuf corresponding to the ARP request packet to EthFw for it to respond. This stage is described here: https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/08_02_00_05/exports/docs/ethfw/docs/user_guide/ethfw_c_ug_top.html

To prove this theory, you can try rebuilding EthFw with ETHFW_CALLBACKS_DEBUG (ethfw/utils/ethfw_callbacks/src/ethfw_callbacks_lwipif.c). This will print a message for each ARP packet being received, and also will print a message if an response was sent. I believe you are going to see both prints.

Now, the problem is that the ARP response sent in step 2 is VLAN untagged, so the response doesn't reach the original sender. This needs VLAN support enabled in lwIP (lwipopts.h) and EthFw needs to be able to pass the appropriate VLAN id in the response, etc. At this point I'm not sure if additional steps will be needed.

Thanks Misa! 

Step 2)

I enabled this Flag and see LWIP layer is receiving ARP messages but no response.

Received ARP dstIp 0.0.0.0, dstMac ff:ff:ff:ff:ff:ff
Received ARP dstIp 0.0.0.0, dstMac ff:ff:ff:ff:ff:ff
Received ARP dstIp 0.0.0.0, dstMac ff:ff:ff:ff:ff:ff
Received ARP dstIp 0.0.0.0, dstMac ff:ff:ff:ff:ff:ff
Received ARP dstIp 0.0.0.0, dstMac ff:ff:ff:ff:ff:ff

As mentioned in setup above we are using two DRA821 PCBA's connected to same VLAN12 tagged switch and pinging from PCBA1 to PCBA2 when we see this issue. ( TISDK 8.1 QNX+RTOS )

I tried enabling VLAN support in lwipopts.h as below but this didn't help

#define ETHARP_SUPPORT_VLAN     1

To workaround this issue we added an entry in ALE table as below but I think this might break non vlan broadcast traffic.

Vlanid: 000c,  Address: ffffffffffff, Member:01f Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[x]

Please let us know if there is anything we can check from our side to investigate this issue further

Hi Misa,

The workaround mentioned below to add VLAN entry for broadcast traffic works for VLAN12 traffic 

"Vlanid: 000c,  Address: ffffffffffff, Member:01f Su=0 FWDSTLVL=0 IGNMBITS=0 RAW:[x]"

Could you please advise if TI was able to reproduce broadcast message issue on same subnet with vlan tags at your end?

There is a comment in ethfw document about broadcast packets

We need to pass broadcast messages on non vlan traffic and this will not work with the above workaround and need support from TI to resolve this issue.

Thank you,

Swapna

Hi Swapna,

ETHFW intercore functionality is supported on select remote client OSes: RTOS and Linux. QNX and AUTOSAR remote clients do not support EthFw intercore.

Unfortunately, this asked feature needs VLAN support while handling proxy ARP packets which our SW does not support. We will get back to you when such a feature would be available in our SW, but currently I don't have a date to share with you.

Thank you! please update this thread when you have more information.