• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 318 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.

TMDSICE3359: cpsw in switch mode does not forward packets in both directions after cable swap

Panagiotis Tsolakos
Prodigy 45 points
Part Number: TMDSICE3359

Tool/software:

We are using a recently ordered TMDSICE3359 running Linux, as provided in ti-processor-sdk-linux-rt-am335x-evm-09.01.00.001-Linux-x86-Install.bin without any modifications.

Our goal is to test the switching functionality of cpsw which is needed by our application. Our test setup looks like this:

Host 1 <-> eth0 of TMDSICE3359 , eth1 of TMDSICE3359  <-> Host 2 

Host 1 is connected to Ethernet 0 port of TMDSICE3359  and Host 2 is connected to Ethernet 1 port of TMDSICE3359.

The cpsw is configured in switch mode and a bridge is created with the following commands found in the kernel documentation (https://docs.kernel.org/networking/device_drivers/ethernet/ti/cpsw_switchdev.html).

devlink dev param set platform/4a100000.switch name switch_mode value 1 cmode runtime
ip link add name br0 type bridge
ip link set dev eth0 master br0
ip link set dev eth1 master br0
ip link set eth0 down;ip link set eth1 down
ip link set eth0 up;ip link set eth1 up
ip link set br0 up

To generate test traffic we constantly ping Host 2 from Host 1 and Host 1 from Host 2. Everything works as expected.

Then we physically swap the cables at the ports of TMDSICE3359. Now, Host 1 is connected with Ethernet 1 port of TMDSICE3359 and Host 2 is connected with Ethernet 0 port of TMDSICE3359.

The setup looks like this:

Host 2 <-> eth0 of TMDSICE3359 , eth1 of TMDSICE3359  <-> Host 1

After the cable swapping the requests from each host reach the other host, but the replies are not forwarded back.

Communication works as expected only if both ports are forced down and up by:

ip link set eth0 down;ip link set eth1 down
ip link set eth0 up;ip link set eth1 up

Why is this necessary? We would expect that the communication recovers without any additional interaction.

Thank you for your help and best regards

Panagiotis

  • 0
    TI__Mastermind 40130 points

    Hi,

    I will discuss with the development team. Un-plugging the cables should be a link down event and plugging the cables back in should be link up event like you are describing. Are you performing the bridge setup after the cable swap? 

    Also out of curiosity could you please describe the reasoning behind this test case?

    Best Regards,

    Schuyler 

  • 0 in reply to Schuyler Patton
    Prodigy 45 points

    Hi Schuyler,

    Thank you for your reply.

    I am performing the bridge setup before the cable swap, exactly as in the sequence described above.

    Un-plugging the cables and plugging them back is of course a link down and link up event, but apparently it is not the same as forcing the links down and up with the ip link command.

    These are the kernel messages when the cables are swapped:

    [  250.166198] cpsw-switch 4a100000.switch eth0: Link is Down
    [  250.195145] br0: port 1(eth0) entered disabled state
    [  253.286238] cpsw-switch 4a100000.switch eth1: Link is Down
    [  253.315141] br0: port 2(eth1) entered disabled state
    [  258.486269] cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full - flow control off
    [  258.486416] br0: port 1(eth0) entered blocking state
    [  258.486440] br0: port 1(eth0) entered forwarding state
    [  260.566274] cpsw-switch 4a100000.switch eth1: Link is Up - 100Mbps/Full - flow control off
    [  260.566415] br0: port 2(eth1) entered blocking state
    [  260.566437] br0: port 2(eth1) entered forwarding state

    These are the kernel messages when the links are forced down and up with the ip link command:

    root@am335x-evm:~# ip link set eth0 down;ip link set eth1 down
    [  347.395362] cpsw-switch 4a100000.switch eth0: Link is Down
    [  347.445311] br0: port 1(eth0) entered disabled state
    [  347.495317] cpsw-switch 4a100000.switch eth1: Link is Down
    [  347.545086] br0: port 2(eth1) entered disabled state
    root@am335x-evm:~# ip link set eth0 up;ip link set eth1 up
    [  362.105337] cpsw-switch 4a100000.switch: starting ndev. mode: switch
    [  362.114348] Generic PHY 4a101000.mdio:01: attached PHY driver (mii_bus:phy_addr=4a101000.mdio:01, irq=POLL)
    [  362.162995] cpsw-switch 4a100000.switch: starting ndev. mode: switch
    [  362.195857] Generic PHY 4a101000.mdio:03: attached PHY driver (mii_bus:phy_addr=4a101000.mdio:03, irq=POLL)
    [  364.165708] cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full - flow control off
    [  364.165778] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    [  364.167589] br0: port 1(eth0) entered blocking state
    [  364.167619] br0: port 1(eth0) entered forwarding state
    [  364.246327] cpsw-switch 4a100000.switch eth1: Link is Up - 100Mbps/Full - flow control off
    [  364.246404] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
    [  364.247526] br0: port 2(eth1) entered blocking state
    [  364.247551] br0: port 2(eth1) entered forwarding state
    In the second case, the cpsw driver is restarting the network device while in the first not. Can you explain the above difference? Maybe it is the root cause of the problem.
    Our application requires that the device operates as a three port switch so that several nodes can be daisy chained in the network. The nodes should be able to communicate with each other even if the topology and the cable links change.
    I have executed the above test case with five different switch devices and all of them forward the packets in both directions and the communication recovers after the cable swap. This is how I would expect a switch should work.
    Best regards,
    Panagiotis
  • 0 in reply to Panagiotis Tsolakos
    TI__Mastermind 40130 points

    Hi Panagiotis,

    Thank you for the additional information. I will need a couple of days to discuss with the dev team. I will respond before the end of the week.

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    TI__Mastermind 40130 points

    Hi Panagiotis,

    I am still working on getting assistance from the development team on your question. I will post again to this thread before mid-next week.

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Prodigy 45 points

    Hi Schuyler,

    Do you maybe have an update on this topic?

    Best Regards

    Panagiotis