• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 535 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2434: only ARP broadcast packets forwarding

Christian Dahlke
Prodigy 40 points
Part Number: AM2434
Other Parts Discussed in Thread: DP83869

I have been working with the AM2434 CPU in conjunction with the "AM243x MCU+ SDK 08.06.00" for my networking project. Specifically, I am using the "Enet Layer 2 CPSW SWITCH Example" from the SDK. In my setup, I have connected cpsw port 1 as a MAC to MAC connection, and cpsw port 2 is connected via the PHY dp83869.

While monitoring the network traffic using Wireshark, I have noticed that only ARP broadcast packets are being forwarded. I would like to understand the reason behind this behavior and if there is any configuration or limitation that might be causing it.

I have verified that the CPSW_CUTTHRU feature is enabled in the SDK test example. However, it seems that only ARP broadcast packets are being forwarded, and other types of packets are not being processed.

All connections in my setup are Ethernet Gigabit connections.

Considering this situation, I would like to inquire whether packet manipulation is necessary in the TX thread to ensure the forwarding of all packet types. Is there any specific logic or code that needs to be implemented within the TX thread to handle and forward packets other than ARP broadcasts?

Specifically, I would like to know if it is feasible to configure the CPSW to broadcast all incoming packets to all ports, similar to the behavior of a hub. This means that any packet received on one port would be replicated and forwarded to all other ports, ensuring that all devices connected to the CPSW receive a copy of the packet.

Is there any additional configuration or setting that needs to be considered to ensure the forwarding of all packet types? Are there any limitations with the AM2434 CPU or the specific SDK version I am using that could be causing this behavior?

Thank you in advance for your assistance and expertise.

Best regards, Bernhard

  • 0
    TI__Prodigy 290 points

    Hello Christian,

    The CPSW switch has ALE (Address Look-up Engine) where it stores a look up table with the information about forwarding rules. The ALE has a learning process where it updates this table with mac-address and port number associated with it.  For every ingress packet, there is ALE lookup process that happens based on the packet's destination address. There is no software or CPU involvement needed here. Please look into the ALE section of the CPSW peripheral in the TRM to get more detail on the capabilities of ALE.
     
    All the broadcast packets (need not be ARP) and unknown unicast packets, unknown multi-cast packets (unknown means the dest address is not present in the ALE table) will be forwarded to all the ports except the ingress port. (unknown unicast will not be sent to CPU (host port)). If you want a behaviour of a hub, you can disable the ALE learning process. This can be done by enabling the "no learning" option in Syscfg, CPSW -> ALE Config -> ALE Port Config -> Learning Security Config.

    CutThru forwarding is a different feature of CPSW where the packet forwarding doesn't wait for the whole packet to be received, it starts the forwarding on the fly i.e after receiving certain data of the packet header. This is to address low latency use cases. 

  • 0 in reply to Venkata Susheel Voora
    Prodigy 40 points

    Hello Venkata Susheel Voora,

    I have enabled this flag for both the host port and the two MAC ports in an attempt to achieve the functionality of a "network hub." However, despite enabling this flag, the packet forwarding behavior has not changed as expected. The packets are still not being forwarded to the other port.

    To provide further context and aid in troubleshooting, I have attached screenshots of Wireshark outputs from both a Windows PC connected via PHY to CPSW port 2 and a Linux machine connected via MAC-to-MAC connection to CPSW port 1. Additionally, I am sharing the application's log file containing packet statistics, which demonstrates that packets are being sent and received on all ports.

    In relation to this matter, I have a few additional questions:

    1. Is it necessary to implement the UDMA connection for achieving the desired functionality? Are there any specific considerations or configurations required for the UDMA connection when attempting to configure the CPSW as a hub-like device?

    2. Are the RX, TX, and eth queues essential for this setup, or is it possible to manually modify the packet content within these queues? Should I be making any specific modifications to these queues to ensure proper packet forwarding?

    ==========================
     Layer 2 CPSW SWITCH Test
    ==========================
    EnetApp_init
    EnetApp_open

    Init all peripheral clocks
    ----------------------------------------------
    Enabling clocks!

    Create RX tasks
    ----------------------------------------------
    cpsw-3g: Create RX task
    EnetApp_createRxTask
    EnetApp_rxTask

    Open all peripherals
    ----------------------------------------------
    ti_enet_open_close.c EnetApp_driverInit. ONLY ONCE
    cpsw-3g: Open enet
    ti_enet_open_close.c EnetApp_driverOpen
    ti_enet_open_close.c EnetApp_getCpswInitCfg
    ti_enet_open_close.c EnetApp_initAleConfig
    host learningCfg.noLearn:1  
    MACPort1 learningCfg.noLearn:1  
    MACPort2 learningCfg.noLearn:1
    ti_enet_open_close.c EnetApp_initMdioConfig
    ti_enet_open_close.c EnetApp_initCptsConfig
    ti_enet_open_close.c EnetApp_initHostPortConfig
    EnetAppUtils_reduceCoreMacAllocation: Reduced Mac Address Allocation for CoreId:1 From 4 To 2
    EnetApp_updateCpswInitCfg

    Init all configs
    ----------------------------------------------
    cpsw-3g: init config
    l2_cpsw_cfg.c EnetApp_initEnetLinkCbPrms
    ti_enet_open_close.c EnetApp_doCpswOpen
    Mdio_open: MDIO Manual_Mode enabled

    ti_enet_open_close.c EnetApp_enablePorts
    ti_enet_open_close.c EnetApp_getMacPortInitConfig
    l2_cpsw_cfg.c EnetApp_initLinkArgs
    cpsw-3g: Open port 1
    ti_enet_open_close.c EnetApp_enablePorts() open MAC port: 0
    ti_enet_open_close.c EnetApp_getMacPortInitConfig
    l2_cpsw_cfg.c EnetApp_initLinkArgs
    cpsw-3g: Open port 2
    ti_enet_open_close.c EnetApp_enablePorts() open MAC port: 1
    ti_enet_open_close.c EnetApp_enablePorts() CPSW_ALE_IOCTL_SET_PORT_STATE
    ti_enet_open_close.c EnetApp_enablePorts() enable host port
    ti_enet_open_close.c EnetApp_enablePorts PHY 3 is alive

    Attach core id 1 on all peripherals
    ----------------------------------------------
    cpsw-3g: Attach core
    cpsw-3g: Open DMA
    EnetApp_openDma
    EnetApp_initTxFreePktQ
    initQs() txFreePktInfoQ initialized with 16 pkts
    EnetApp_initRxReadyPktQ
    allocEthPkt Nr. 0
    allocEthPkt Nr. 1
    allocEthPkt Nr. 2
    allocEthPkt Nr. 3
    allocEthPkt Nr. 4
    allocEthPkt Nr. 5
    allocEthPkt Nr. 6
    allocEthPkt Nr. 7
    allocEthPkt Nr. 8
    allocEthPkt Nr. 9
    allocEthPkt Nr. 10
    allocEthPkt Nr. 11
    allocEthPkt Nr. 12
    allocEthPkt Nr. 13
    allocEthPkt Nr. 14
    allocEthPkt Nr. 15
    cpsw-3g: CPSW_CUTTHRU enabled
    EnetApp_setCutThruParams
    l2_cpsw_cfg.c EnetApp_waitForLinkUp
    cpsw-3g: Waiting for link up... RGMII MAC 1
    cpsw-3g: MAC to MAC link up !
    cpsw-3g: host port MAC addr: 70:ff:76:1d:92:c1

    l2_cpsw_cfg.c EnetApp_addMCastEntry
    l2_cpsw_cfg.c EnetApp_createPhyRegisterPollingTask
    l2_cpsw_cfg.c EnetApp_initPhyLinkHandlerCtx
    l2_cpsw_cfg.c EnetApp_phyRegPollHandler
    cpsw-3g: Init MAC PORT 2 and PHY
    l2_cpsw_cfg.c EnetApp_waitForPhyAlive
    l2_cpsw_cfg.c EnetApp_waitForPhyAlive() PHY#: 3 macPort: 1   
    l2_cpsw_cfg.c EnetApp_initExtPhy MacPort 1
    l2_cpsw_cfg.c EnetApp_initExtPhyArgs
    cpsw-3g: PHY Mask 0x08
    enetextphy.c EnetExtPhy_WaitForLinkUp PHY2 Link Led = 0
    complete =  EnetExtPhy_nwayWait  PHY2 Link Led = 1
    isLinkUp = EnetExtPhy_isLinked   PHY2 Link Led = 1
    l2_cpsw_cfg.c EnetApp_enablePhyLinkPollingMask
    EnetApp_open
    l2_cpsw_cfg.c EnetApp_getExtPhyLinkCfgInfo
    Cpsw_handleExternalPhyLinkUp: Port 2: Link up: 1-Gbps Full-Duplex

    Print statistics
    ----------------------------------------------
      rxGoodFrames            = 40
      aleDrop                 = 17
      rxOctets                = 5925
      txGoodFrames            = 57
      txBcastFrames           = 41
      txMcastFrames           = 16
      txOctets                = 7776
      octetsFrames64          = 2
      octetsFrames65to127     = 73
      octetsFrames128to255    = 14
      octetsFrames256to511    = 8
      netOctets               = 13701
      portMaskDrop            = 40
      aleDAEqSADrop           = 23
      aleUnknownUcast         = 40
      aleUnknownUcastBcnt     = 5925
      txPri[0]                = 57
      txPriBcnt[0]            = 7776

     cpsw-3g - Port 1 statistics
    --------------------------------
      rxGoodFrames            = 73
      rxBcastFrames           = 53
      rxMcastFrames           = 20
      aleDrop                 = 4
      rxOctets                = 10723
      octetsFrames64          = 3
      octetsFrames65to127     = 51
      octetsFrames128to255    = 11
      octetsFrames256to511    = 8
      netOctets               = 10723
      portMaskDrop            = 4
      aleUnknownMcast         = 20
      aleUnknownMcastBcnt     = 4633
      aleUnknownBcast         = 53
      aleUnknownBcastBcnt     = 6090


     cpsw-3g - Port 2 statistics
    --------------------------------
      rxGoodFrames            = 32
      rxBcastFrames           = 14
      rxMcastFrames           = 18
      rxOctets                = 2678
      octetsFrames64          = 5
      octetsFrames65to127     = 27
      netOctets               = 2678
      aleUnknownMcast         = 18
      aleUnknownMcastBcnt     = 1494
      aleUnknownBcast         = 14
      aleUnknownBcastBcnt     = 1184


    Reset statistics
    ----------------------------------------------
    cpsw-3g: Reset statistics

    Allocated MAC addresses
    ----------------------------------------------
    cpsw-3g:     70:ff:76:1d:92:c1

  • 0 in reply to Christian Dahlke
    TI__Prodigy 290 points

    Hello Christian,

    Apologies for the delay. 

    From the port stats, I see that there are no txGoodFrames on either Port 1 or Port 2 which is not expected. To help us root cause the issue, Can you please try the following 

    1. Is it possible for you to run the same example via PHY connection on both CPSW port 1 and CPSW port 2 ? This is our default configuration that is tested out of box. If you observe the same behavior here, it will be easier for us to reproduce on our end and debug.

    2. Can you inject some layer-2 broadcast frame traffic from any Linux tool like Packeth and provide the CPSW port stats and wireshark pcap files?


    >>Is it necessary to implement the UDMA connection for achieving the desired functionality? Are there any specific considerations or configurations required for the UDMA connection when attempting to configure the CPSW as a hub-like device?
    - No, the UDMA path is only required for the packets to be received by the R5 core. The switch functionality is totally performed by the CPSW hardware, no intervention of CPU is needed.

    >> Are the RX, TX, and eth queues essential for this setup, or is it possible to manually modify the packet content within these queues? Should I be making any specific modifications to these queues to ensure proper packet forwarding?
    - No special modifications are required for packet forwarding. The switching is taken care by the CPSW hardware internal queues.  

    Regards

    Susheel

  • 0 in reply to Venkata Susheel Voora
    Prodigy 40 points

    Hello Susheel

    I want to express my gratitude for your support and suggestions.
    I have managed to find a solution to my previous issue.
    By deleting the configuration generated by the "TI System Configuration Tool" and only setting the "learningCfg.noLearn" flags, I have achieved the desired behavior.
    Now, I can also see TX packets in the statistics, and the ping functionality is working flawlessly.

    However, I still have a couple of open questions that I hope you can help me with:

        In the "HUB" operation mode, is it necessary to handle MDIO, Link UP, and Link Down? Currently, due to the "i2329 MDIO: MDIO interface corruption (CPSW and PRU-ICSS)" issue, I am using the manual mode. Is there any specific consideration I should be aware of when dealing with MDIO in this setup?

        Do any of you have a sample implementation for CPSW hub-like operation with minimal configuration and initialization?

    Thank you once again for your support.

    Best regards

  • 0 in reply to Christian Dahlke
    TI__Prodigy 290 points

    Hello Christian,

    Yes, Handling Link up and Link Down events is necessary to avoid unnecessary drops. In these Link Up and Link Down events, we update the MacPort's state (like Disabled state, Forwarding state) internally which is essential for packet forwarding. And As we have a Hardware Errata for MDIO, MDIO manual mode is also needed. 

    >>  Do any of you have a sample implementation for CPSW hub-like operation with minimal configuration and initialization?
    Sorry, Currently we do not have any sample implementation specific to hub-like operation as it is not a generic use-case. Let us know if you face any issues.

    Regards

    Susheel

  • 0 in reply to Venkata Susheel Voora
    Prodigy 40 points

    Firstly,  I want to express my gratitude for the valuable information provided.

    I have an additional question:

    In the configuration with a MAC-PHY connection, all packets appear to pass through without any issues.

    However, when using the MAC-to-MAC connection, there is a packet loss ranging from 1% to 3%.

    I am seeking assistance in identifying the possible cause of this packet loss.

    Could you kindly offer any insights or potential reasons that might be contributing to this behavior?

    Best regards

  • 0 in reply to Christian Dahlke
    Prodigy 40 points

    I am pleased to inform you that the problem has been successfully resolved. After thorough investigation and debugging, it appears that the packet loss issue was caused by the implementation of the Rx-Tx Task in the example code. Upon removing this specific piece of code, there has been a complete elimination of packet loss.

    Once again, thank you for your help.

    Best regards