• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 449 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.

Original question:

AM6442: Cannot forward the multicast frame with Cut-through

AM6442: Everything flows to another port with cut-through, Multicast cannot be received on the EVM,

Hideaki Matsumoto
Genius 9120 points
Part Number: AM6442

Hi,

Thank you team for supporting the following thread.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1274912/am6442-cannot-forward-the-multicast-frame-with-cut-through/4955670#4955670

My customer has updated the Processor SDK to the latest 9.1 and confirmed that cut-through issue has been fixed, but found another new problem.

Have you also seen the same problem which they reported below ?

Could you check if the same issue can be observed on you environment ?

 

The EVM was able to cut through the multicast frame that arrived on one port to the other.

However, the multicast cannot be received on the EVM, and everything flows to another port with cut-through.

Their expectation is to cut through when br0 receives the multicast and receives it on one of the ports.

 

Here ae the steps they have taken.

  • Add the following command and execute the attached file.

bridge vlan add dev br0 vid 1 self

 

  • Add the multicast address to MDB by bridge mdb add command.

The following is an entry added for cut-through LLDP.

dev br0 port eth1 grp 01:80:c2:00:00:0e permanent offload vid 1

dev br0 port eth0 grp 01:80:c2:00:00:0e permanent offload vid 1

 

Thanks and regards,

Hideaki

  • 0
    TI__Mastermind 40090 points

    Hi Hideaki,

    I am currently out of office, I will look at this tomorrow. Assuming the customer is using the latest SDK on the TI EVM please run switch-config -d, this will dump the contents of the ALE. Ideally the MAC IDs should be listed in the output.

    Best Regards,

    Schuyler 

  • 0 in reply to Schuyler Patton
    TI__Genius 9120 points

    Hi Schuyler,

    Thank you for your response. Here is the dump list which you asked below. Please give them any advice if you can find something problem below.

    /opt/cut_through# switch-config -d
    K3 cpsw dump version (1) len(11704)
    ALE table dump ents(512):
    0 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x7
    1 : type: mcast, addr = 01:80:c2:00:00:00, mcast_state = blf, super, port_mask = 0x1
    2 : type: ucast, vid = 1, addr = 70:ff:76:1e:2d:25, ucast_type = persistant, port_num = 0x0, Secure
    3 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x7
    4 : type: mcast, addr = 33:33:00:00:00:01, mcast_state = f, no super, port_mask = 0x1
    5 : type: ucast, vid = 1, addr = 70:ff:76:1e:2d:26, ucast_type = persistant, port_num = 0x0, Secure, Blocked
    6 : type: vlan , vid = 1, untag_force = 0x7, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x7
    7 : type: mcast, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x1
    8 : type: ucast, vid = 1, addr = ac:1f:0f:85:08:9b, ucast_type = persistant, port_num = 0x0, Secure
    9 : type: mcast, vid = 1, addr = 01:15:4e:00:00:01, mcast_state = f, no super, port_mask = 0x6
    10 : type: mcast, vid = 1, addr = 01:15:4e:00:00:02, mcast_state = f, no super, port_mask = 0x6
    11 : type: mcast, vid = 1, addr = 01:80:c2:00:00:0e, mcast_state = f, no super, port_mask = 0x6
    12 : type: mcast, vid = 0, addr = 33:33:ff:1e:2d:24, mcast_state = f, no super, port_mask = 0x1
    13 : type: mcast, vid = 0, addr = 33:33:00:00:00:6a, mcast_state = f, no super, port_mask = 0x1
    14 : type: mcast, vid = 0, addr = 33:33:00:00:00:fb, mcast_state = f, no super, port_mask = 0x1
    15 : type: mcast, vid = 0, addr = 33:33:00:01:00:03, mcast_state = f, no super, port_mask = 0x1
    16 : type: ucast, vid = 1, addr = 38:4b:24:dd:cc:62, ucast_type = untouched , port_num = 0x1
    32 : type: ucast, vid = 1, addr = 38:4b:24:dd:cc:63, ucast_type = touched , port_num = 0x1
    64 : type: ucast, vid = 1, addr = 00:02:a2:cd:cd:cd, ucast_type = touched , port_num = 0x2

    Thanks and regards,
    Hideaki

  • 0 in reply to Hideaki Matsumoto
    TI__Mastermind 27050 points

    If the AM6442 is not configured as switch, does the multicast test work? For example by default Linux does not respond to ping to a multicast address, you have to enable it:

    sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0

    I'm wondering is the multicast being ignored in the SW unrelated to the interface being a switch or not?

  • 0 in reply to Pekka Varis
    TI__Mastermind 27050 points

    I received side-band response that with using in non-switch configuration doing:

    Pekka Varis said:
    sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0

    Allows responding to ping to multicast address. As switch did you try the same thing?

  • 0 in reply to Pekka Varis
    TI__Mastermind 27050 points
    Pekka Varis said:
    sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0

    This applies for ping, but looks like you are using LLDP (01:80:c2:00:00:0e is the multicast address). I have not tested LLDP but looking at your commands I think you need to add 01:80:c2:00:00:0e to also the br0 port in order to make it a member in that multicast group. Then the command should show 0x7 as port mask instead of 0x6:

    Hideaki Matsumoto said:
    11 : type: mcast, vid = 1, addr = 01:80:c2:00:00:0e, mcast_state = f, no super, port_mask = 0x6

    if you run:

    bridge mdb add dev br0 port br0 grp 01:80:c2:00:00:0e permanent offload vid 1

    you should see also the host port (br0) be a member in the multicast group so port_mask = 0x7.

    If this does not help, what LLDP stack (802.1AB) are you running?

      Pekka

  • +1 in reply to Pekka Varis
    TI__Mastermind 27050 points

    Did you try adding also the port to the local networking stack (br0) as proposed above?

    Also a double check, without relying on switching offload at all, so just using Linux for switching everything works? So do not run these lines:

    devlink dev param set platform/8000000.ethernet name switch_mode value true cmode runtime

echo 1 > /sys/kernel/debug/8000000.ethernet/Port1/cut_thru_rx_pri_mask
echo 1 > /sys/kernel/debug/8000000.ethernet/Port1/cut_thru_tx_pri_mask
echo 1 > /sys/kernel/debug/8000000.ethernet/Port2/cut_thru_rx_pri_mask
echo 1 > /sys/kernel/debug/8000000.ethernet/Port2/cut_thru_tx_pri_mask

ethtool --set-priv-flags eth0 cut-thru on
ethtool --set-priv-flags eth1 cut-thru on

    The point of this check is to see if the logical functionality is as expected. Our offload of switching and then further cut-through switching, should not change anything other than performance (timing, CPU load). The handling of multicast traffic should be the same as with soft switch using Linux Ethernet driver.

  • 0 in reply to Pekka Varis
    TI__Genius 9120 points

    Hi Pekka,

    Thank you for sending the additional information. The customer is now confirming that. Please wait for a while.

    Thanks and regards,
    Hideaki