ALE setup in GbE for PA simpleExample project etc

Hi, Aamir:

Yes, your observation is correct.
We are sorry that the cpsw code is little mislead.
The intention is to send the test packet from port 0 (CPPI port) to port 1(EMAC port 0) and loopback the same packet from port 1 to port 0.
It is only required to program ALE of port 1 with the destination MAC address of the test packet  (address1) at the simulator because the simulator does not support ALE learning.
You can also specify destination EMAC port number (0, 1) by setting psFlags to (1, 2). Therefore, it is not necessary to program ALE at EVM.
To deliver loopbacked packet form port 1 (EMAC port 0) to port 0 (CPPI port) is achived by enabling ALE bypass, in this mode all packets entering port 1 and 2 will be delivered to port 0 (CPPI port).

Init_Switch():
...
    if(cpswLpbkMode != CPSW_LOOPBACK_NONE)
        CSL_CPSW_3GF_enableAleBypass();

I hope that this information is helpful and if it does, please click the "verify" button.

Best regards,

Eric

Eric,

Yes, your observation is correct.
We are sorry that the cpsw code is little mislead.
The intention is to send the test packet from port 0 (CPPI port) to port 1(EMAC port 0) and loopback the same packet from port 1 to port 0.

yes
It is only required to program ALE of port 1 with the destination MAC address of the test packet  (address1) at the simulator because the simulator does not support ALE learning.

Is this because for any loopback mode on simulator, with the bypassALE enabled all packets on port 1 and port 2 are sent to port 0 so only need to setup port 1 and port 2 ALE. What is the difference between ALE learning and forwarding. So if port 1 ALE is set to learn and matches address1, it is still forwarded to port 1 but what does the learning do?

You can also specify destination EMAC port number (0, 1) by setting psFlags to (1, 2). Therefore, it is not necessary to program ALE at EVM.

The enableALEbypass is also called for the EVM when doing any loopback so again should you not need to program the ALE for port 1 and port2 atleast much like the simulator?

To deliver loopbacked packet form port 1 (EMAC port 0) to port 0 (CPPI port) is achived by enabling ALE bypass, in this mode all packets entering port 1 and 2 will be delivered to port 0 (CPPI port).

Init_Switch():
...
    if(cpswLpbkMode != CPSW_LOOPBACK_NONE)
        CSL_CPSW_3GF_enableAleBypass();

I hope that this information is helpful and if it does, please click the "verify" button.

Hi, Aamir:

CPSW Forwarding: Allow the packets entering this port to be forwarded to the other CPSW ports.
ALE Learning: Register the  source MAC address into the ALE table for every packet entering this port from outside. When CPSW receives a packet,  it will forward the packet to the port which ALE table contains the destination MAC address of this packet. If the destination MAC address does not exist at the ALE tables of all ports, then the SW should broadcast the packets to all ports.

However, CPSW does not forward unicast packet from port 1/2 to port 0 (CPPI port) unless its ALE table contains then destination MAC address.    
In other word,  the NetCP will not recerive any packet with its own MAC address until it transmit one packet out. To avoid this problem, you should program the chip MAC address into the ALE table of the CPPI port.

For the second question, what I mean is that you only need to program ALE table at simulator. It is not required at EVM.

Best regards,

Eric

Eric,

Thanks for your explanation. I am sorry but I do have a few questions still.

Since ALE learning is not available on the simulator, one has to program the ALE port 1 (and port 2) with the dest mac address for outgoing packets from the DSP to get from port 0 to port 1/2. However for incoming packets since the ALE bypass is set for loopback modes, all packets into port 1 and port 2 are sent to port 0 automatically so it would appear that one does not need to set port 0 ALE to the mac address1 due to bypass setting, but it is still required as commenting it out results in the packets not getting back to the DSP. I did this by only setting up port 0 ALE for forwarding by calling the CSL_CPSW_3GF_setAlePortControlReg in switch_update_address for port 0 and then skipping the rest of the function. Can you square that? You have two statements that seem contradictory to me - One is CPSW does not forward unicast packets from port 1/2 to port 0 unless its ALE table contains dest MAC address. The other statement is that with ALE bypass enabled port 1 and port 2 packets are sent to port 0.

Also I am looking at the STATs for module A (port 0 stats) and B (port 1/2 stats). When doing ext loopback on simulator with all 10 packets that are sent out of DSP returning back to the DSP. The StatB registers seems to be updating but why are the STATA registers not updating? After all packets are going out port 0 to port 1/2 and then returning back from 1/2 to port 0.

I also tried the emacs example with the EVM and ensuring that we use MAC 1 i.e port 2 to send packets out the EVM and I put it in no loopback. I also set up the dest mac and dest IP address of the PC that I want the packets from the DSP to go to.  I set up the psFlags =2 in sendPacket(). Does this use directed packets to force the packet to go out over EMAC1 and not use emac 0 as before? If not how does it end up going out EMAC1 by setting the psFlag in the sendPacket()? I also am capturing the packets that are coming out of the EVM to my machine and am seeing 2 UDP packets for every one packet that I am supposedly transmitting out of the DSP. I have SGMII0 set up in loopback so am thinking when I send a packet to port 0, one ends up being sent out to port 2 and the other get sent to port 1, gets looped back to the 3-port switch and then gets forwarded to port 2 and so I see 2 UDP packets. I am not sure why that is happening? Is the purpose of setting the MAC address in the Init_MAC function for say EMAC port 1 to only allow through to port 1 all those broadcast messages and the unicast packets that match the MAC address for EMAC 1? 

Thanks, Aamir

I also tried the emacs example with the EVM and ensuring that we use MAC 1 i.e port 2 to send packets out the EVM and I put it in no loopback. I also set up the dest mac and dest IP address of the PC that I want the packets from the DSP to go to.  I set up the psFlags =2 in sendPacket(). Does this use directed packets to force the packet to go out over EMAC1 and not use emac 0 as before? If not how does it end up going out EMAC1 by setting the psFlag in the sendPacket()? I also am capturing the packets that are coming out of the EVM to my machine and am seeing 2 UDP packets for every one packet that I am supposedly transmitting out of the DSP. I have SGMII0 set up in loopback so am thinking when I send a packet to port 0, one ends up being sent out to port 2 and the other get sent to port 1, gets looped back to the 3-port switch and then gets forwarded to port 2 and so I see 2 UDP packets. I am not sure why that is happening?

I believe I have answered the question above about teh multiple UDP packets. I had the switch not set in bypass so packets coming into port 1after loopback would be sent into port 0 and port 2 so that is why they were duplicate packets. I set up the switch bypass to get all port 1 packets to get sent to port 0 and the probem was solved.

Is the purpose of setting the MAC address in the Init_MAC function for say EMAC port 1 to only allow through to port 1 all those broadcast messages and the unicast packets that match the MAC address for EMAC 1?

I am able to get packets into and out of the EVM now.

thanks, Aamir

Eric,

These are a list of my outstanding questions that I would appreciate some clarification on. Thanks.

1. Since ALE learning is not available on the simulator, one has to program the ALE port 1 (and port 2) with the dest mac address for outgoing packets from the DSP to get from port 0 to port 1/2. However for incoming packets since the ALE bypass is set for loopback modes, all packets into port 1 and port 2 are sent to port 0 automatically so it would appear that one does not need to set port 0 ALE to the mac address1 due to bypass setting, but it is still required as commenting it out results in the packets not getting back to the DSP. I did this by only setting up port 0 ALE for forwarding by calling the CSL_CPSW_3GF_setAlePortControlReg in switch_update_address for port 0 and then skipping the rest of the function. Can you square that? You have two statements that seem contradictory to me - One is CPSW does not forward unicast packets from port 1/2 to port 0 unless its ALE table contains dest MAC address. The other statement is that with ALE bypass enabled port 1 and port 2 packets are sent to port 0. Is this a simulator bug?

2. Also I am looking at the STATs for module A (port 0 stats) and B (port 1/2 stats). When doing ext loopback on simulator with all 10 packets that are sent out of DSP returning back to the DSP. The StatB registers seems to be updating but why are the STATA registers not updating? After all packets are going out port 0 to port 1/2 and then returning back from 1/2 to port 0. Is this again an issue with the simulator only.

3. What is the issue with psFlags=1 or 2 in the sendPacket() function. It talks of forcing the packet over EMAC 1. However from my experience playing with this setting does nothing to decide if it goes to port 1 or port 2 of the switch as the packet is being sent from port 0 to both ports 1 and 2 on the EVM. As a side question, how does one use directed packets to get the packets to use a particular EMAC?

4. What is the purpose of setting the MAC address in the Init_MAC function for say EMAC port 1? Is it to only allow through to port 1 all those broadcast messages and the unicast packets that match the MAC address for EMAC 1? 

Further I would like clarification on how and if I can achieve the following.

In the setup I have working right now for the emacExample. I have ALE port 0 and port 2 set to forward with learning on and port 1 set to disabled. I have packets go out from the DSP to switch port 0 then to switch port 2 and out of the EVM. Meanwhile undesired incoming packets, multicast and broadcast packets are being received by switch port 2 and getting across to switch port 0 as the packets dest MAC address does not match the port 0 ALE entry added initially or by ALE learning and so are getting forwarded to all ports i.e. 1 and 0. In addition these src mac addresses are getting added to the port 2 ALE entries as expected. My question is how can I ensure that these packets do not get through to switch port 0 as they then will go onto the PA where they have to be needlessly processed by the first PDSP to prune based on MAC addresses? As I am expecting significant UDP traffic to my DSP and require a lot of PA processing I do not want to waste scarce PA resources pruning packets in the PA when I got stop them somehow at the switch. Basically I do want to have the switch flood packets from port 2 to the other ports like it does when it does not find the dest mac addess in the port 0 table.

Thanks, Aamir

Thanks for your answers on question 1, 2 and 5. I hope to hear from javier on question 4.

As for question 3, I believe I did have the Cppi_setPSFlags set as the test was for ext loopback mode and so it should have been called. However, I would need to re-investigate that to see if that was the issue and will get back to you if it is not.

I have started a new thread on the implementation of the PA for a range of UDP ports. Will appreciate your reply.

Thanks, Aamir

hi, eric.

I  appreciate a little support on the information you give in the post by you should program the chip MAC address into the ALE table of the CPPI port.

how can i do this. I cant find the port 0mac address configuration lines in the emacexample

thank you 

Hi, Eric:

Here is the sample code:

Init_Cpsw()
...
Switch_update_addr(0, macAddress0, 0);  // portNum = 0 (CPPI port)

Switch_update_addr (Uint32 portNum, UInt8 macAddress[6], Uint16 add)
...

        /* Program the ALE with the MAC address.
        *
        * The ALE entries determine the switch port to which any
        * matching received packet must be forwarded to.
        */
        /* Get the next free ALE entry to program */
        for (i = 0; i < CSL_CPSW_3GF_NUMALE_ENTRIES; i++)
        {
            if (CSL_CPSW_3GF_getALEEntryType (i) == ALE_ENTRYTYPE_FREE)
            {
                /* Found a free entry */
                break;                   
            }
        }
        if (i == CSL_CPSW_3GF_NUMALE_ENTRIES)
        {
            /* No free ALE entry found. return error. */           
            return -1;           
        }
        else
        {
            /* Found a free ALE entry to program our MAC address */           
            memcpy (ucastAddrCfg.macAddress, macAddress, 6);    // Set the MAC address
            ucastAddrCfg.ucastType      =      ALE_UCASTTYPE_UCAST_NOAGE;   // Add a permanent unicast address entryALE_UCASTTYPE_UCAST_NOAGE.
            ucastAddrCfg.secureEnable   =      FALSE;  
            ucastAddrCfg.blockEnable    =      FALSE;  
            ucastAddrCfg.portNumber     =      portNum;   // Add the ALE entry for this port

            /* Setup the ALE entry for this port's MAC address */
            CSL_CPSW_3GF_setAleUnicastAddrEntry (i, &ucastAddrCfg);           
        }

If your question is answered, please click "verify answer" button!

Best regards,

Eric