Fail to Receive ARP Request on PA_emacExample (C6670)

Aditya,

Was the 6670 PA example working before to receive normal UDP packets, I meant

- ethtype 0x0800 

- routeInfo directly to Host instead of LUT1 

- and host can get packets from queue?

If yes, you currently issue is host can't receive ARP from queue?

Regards, Eric 

Hi Eric,

sorry for late response. 

And yeah, I've just check it a moment ago and it won't work on normal UDP. The packet needs to be forwarded to LUT1 (IPv4 parse).

So, what workaround you  are suggesting then? 

In addition for this, I can't receive the packet from external host if I don't add correspond switch MAC address to ALE table. The default config for PA_emacExample for non loopback mode doesn't configure it, so I need to change it a little bit. No problem though, for Tx process. Without adding MAC to ALE, ext host with Wireshark still be able to receive packet from EVM. I'll be glad to hear some insight about this from anyone.

Thank you and regards,

Aditya

Aditya,

In no loopback mode, first check if the switch of 6678 EVM can receive packets, you can look at the memory 0x2090b00 and 0x2090c00 range, those registers are explained in table 3-2 of http://www.ti.com/lit/ug/sprugv9c/sprugv9c.pdf.

Then, what is the destination MAC address your external device sent to DSP, you can find it via Wireshark. In the pa_mgmt.c, there is a function called Add_MACAddress(), the line:

{ 0x10, 0x11, 0x12, 0x13, 0x14, 0x15 },

/* Dest mac */

should match the dst MAC sent from your external device. Otherwise, PA will discard it.

Regards, Eric

Hi Eric,

thanks for the reply. I'll try it right away and comeback ASAP.

FYI,

Since you're recommend me to check the mem address. Does the address will be the same between C6670 and C6678? I'm using PDK 1.1.2.6

Allright, so here is the result.

Now, I can transmit and receive packet between EVM and PC without using ALE. Some changes from the default PA_emacExample:

- (I had to enable ALE Bypass on cpsw_mgmt.c::Init_Switch even though I'm using non_loopback).

//if(cpswLpbkMode != CPSW_LOOPBACK_NONE)
CSL_CPSW_3GF_enableAleBypass();

- On pa_mgmt.c::Setup_PASS::Add_MACAddress, had to comment these lines because as you say, I want the PA to forward packet with dest address of packet (PC to EVM) 10:11:12:13:14:15, not 00:01:02:03:04:05.

/*

if(cpswLpbkMode == CPSW_LOOPBACK_NONE)
memcpy(ethInfo.dst, srcMac, sizeof(srcMac));

*/

Now, back to the first problem, I still can't forward the UDP packet directly to host (pa_DEST_HOST instead of pa_DEST_CONTINUE_PARSE_LUT1). Obviously, Ithis problem need to be solved before continuing the ARP request workaround.

Thank you and regards, Aditya

Aditya,

Yes, the address for C6670 and C6678 are the same.

I don't see any reason you can't forward the UDP directly to host, in Add_MACAddress() function,

paRouteInfo_t

routeInfo = { pa_DEST_CONTINUE_PARSE_LUT1,  =====> did you change this to pa_DEST_HOST already?

Another question, suppose you keep this as pa_DEST_CONTINUE_PARSE_LUT1, In Add_IPAddress()====>

paIpInfo_t ipInfo = { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* IP source = dont care */

{ 0xc0, 0xa8, 0x01, 0xa, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, ===========================>if you match this to you incoming packets

/* IP dest */

And in function Add_port()====>ports = {0x5678}; ==========> if you match this to your incoming UDP port

Will your host receive the UDP packets via L2/L3/L4 classification?

Regards, Eric

Hi Eric,

The example is working well with this config:

+ routeInfo on Add_MACAddress = {pa_DEST_CONTINUE_PARSE_LUT1, ...}

+ routeInfo on Add_IPAddress = {default}

+ port on Add_Port = {0x5678}, routeInfo on Add_Port = {pa_DEST_HOST, ...}

I can send and receiving raw UDP packets at the same time with the external host (my PC). Since the packet triggered the ISR, then we can assume that UDP pass the L2/L3/L4 classification. But, the problem still exists, in which I can't send the packet directly to EVM's host by putting pa_DEST_HOST on Add_MACAddress' routeInfo instead of pa_DEST_CONTINUE_PARSE_LUT1, Does this problem have something to do with the queue for the Rx Flow? Any wonder? I'm trying to check and learn more about the queue for Rx Flow for this example then.

Thank you and regards, Aditya

Hi, 

i want to ask a little about these commented doxygen lines:

/**
* @ingroup palld_api_structures
* @brief Packet routing configuration
*
* @details paRouteInfo_t is used to specify the physical routing of packets out of the packet accelerator
* sub-system. Not all fields are required for all destinations.
* @li pa_DEST_DISCARD: none
* @li pa_DEST_CONTINUE_PARSE_LUT1:
* @li pa_DEST_CONTINUE_PARSE_LUT2: customType, customIndex
* @li pa_DEST_HOST: flowId, queue, mRoutehandle, swInfo0, cmd
* @li pa_DEST_SASS: flowId, queue, swInfo0, swInfo1, cmd
* @li pa_DEST_ETH: emacCtrl
* @li pa_DEST_SRIO: flowId, queue, swInfo0, swInfo2, pktType
*/

Does it mean that I have to configure flowId, queue, mRoutehandle, swInfo0 and cmd if I want to use pa_DEST_HOST as my next route?

Thanks,

Aditya

I'm sorry, those were the infos for paRouteInfo_t in pa.h.

Thanks.

These are the STATSA (port0) and STATSB (port1 and port2) register result. I've sent 4 UDP packets from PC to EVM (RJ45 connected port --> port2). 

Looking at the STATSA and STATSB, the RXGOODFRAMES for those two STATS were same (4). But why there is a difference on RXMULTICASTFRAMES received on port0 (0x02090B08) and port2 (0x02090C08)? FYI, still the packet won't trigger the interrupt. But, since the RXGOODFRAMES was counted to 4, does it mean that the packet actually arrived at accumulator?

nb:

On Setup_PASS, I only use Add_MACAddress(). I ignored Add_IPAddress() as well as Add_Port(). On Add_MACAddress(), all route destination were pa_DEST_HOST, from routeInfo, nFailInfo and cmdReplyInfo.

Eric, It works. Now I can directly send the packet to host after L2, even though I had to change (making these param have same value with Add_Port's),

routeInfo.mRouteIndex = -1;

routeInfo.swInfo0 = 0xaaaaaaaa;

Thank you for the helps and regards,

Aditya

Would you please send me the working code that you have tried as I am also dealing with the same issue.

I am trying to send packets from PC to EVM.The packets are seen in Gbe switch Stats register but it is not recieved at host port 0.We are using polling method for recieving packets.We are concentrating on filtering based on MAC address only.

Please share ur inputs.

Hi, Yanuar.

If the problem was solved? I have a same open issue: can Tx/Rx UDP regular packeges(ethtype = 0x0800) via ISR , but not ARP (ethtype = 0x0806).

ISR just not triggered.

If you have a solution, I'll be glad to talk about.

Regurds,

Leon.