C6678 Packet not received by random cores

What example are you using and MCSDK version ?
What is the packet size ?

Hi Titus,

Thank you for your prompt reply.

i have forwarded this question to my customer and will get back to you.

Thank you.

Regards,

YC

Hi Titus,

Here are the information.

Version:

XDC_PATH := $(TI_DIR)xdctools_3_25_00_48/xs

BIOS_PATH := $(TI_DIR)bios_6_33_06_50/

VO_LIB_PATH := $(TI_DIR)volib_C66_2_1_0_1/packages

MCSDK_DEMO := $(TI_DIR)mcsdk_2_01_02_05/demos

PDK_PAC := $(TI_DIR)pdk_C6678_1_1_2_5/packages

XDAIS_EXMP := $(TI_DIR)xdais_7_21_01_07/examples

XDAIS_PAC := $(TI_DIR)xdais_7_21_01_07/packages

DSP_LIB := $(TI_DIR)dsplib_c66x_3_1_0_0

 

Reference example:

ti/drv/pa/example/multicoreExample]

 

Packet size:

214 bytes (rtp:172 + udph:8 + IPh:20 + MACh:14)

Regards,

YC

Hi,
How many cores used for tx and rx ?
Are you doing simple internal loop back ?

In example, just we did internal loop back without ethernet cable interface.
If you want to transfer the packet to outer world, we have to modify the code accordingly.

How about "NUM_HOST_DESC" value ?

Did they modified the code ?
Just increasing the packet,IP address,MAC alone ?
Help us to reproduce the problem.

Hi Titus,

Please take a look at the feedback from the customer. Thank you.

How many cores used for tx and rx ?

We have seen this issue in 1 chip i.e. 8 cores and 2 chips with 16 cores. We stopped adding more chips at this point. The cores are pretty random.

Are you doing simple internal loop back ?

I am not clear on this question. But in our scenario, DSP chip receives packets from the BRCM switch, transcodes the packet send back to the destination it came from by changing IP header and MAC header. We also tried by simply changing the IP header without going through the transcoding process and still see the issue. The interface to DSP is the BRCM switch. The packets come to the BRCM switch from fabric interface.

In example, just we did internal loop back without ethernet cable interface.

Could you please tell us which Ethernet cable interface you are talking about?

If you want to transfer the packet to outer world, we have to modify the code accordingly.

We have configured PA for IP and UDP port filtering. For UDP we used custom port filtering. From our debugging, we see the issue in receive, looks like PA is dropping in UDP filtering.

How about "NUM_HOST_DESC" value ?

We tried by changing this value, did not help.

Did you modified the code ?

which code? If you are asking about the example, yes. Here is the flow,

1)      Core0 sets up custom_LUT2 by using Pa_setCustomLUT2(…) function.

2)      Rest of the cores including Core0, calls Pa_addCustomLUT2.  We let this step done after step#1 is done.

3)      We found a temporary solution, by adding staggering delay (1msec * coreNum) before step #1 is called. But we need to understand the root cause and what is the permanent fix.

Just increasing the packet,IP address,MAC alone ?

We have configured each chip with one IP address and MAC address. Use UDP ports for routing to different cores. Each core has specific port range.

Regards,

YC

Hi Titus,

Any update on this thread?

Please let me know if you need more details.

Thank you.

Regards,

YC

Hi,
Sorry for the delay in response.

3) We found a temporary solution, by adding staggering delay (1msec * coreNum) before step #1 is called. But we need to understand the root cause and what is the permanent fix.

I think, I too faced this packet missing and got fixed by adding some delay.
Let me check with team to know better this background.

Hi,
Sorry for the delay in response.
Could you please ask your customer for the steps to reproduce the same problem at our end.

Hi Titus,

Sorry for the late reply.

My customer is out of office until  07/05/2015

I will update to you ASAP.

Thank you.

Regards,

YC

Dear Support: 

Attached below is the feedback from customer: 

I am not sure if I responded to this e-mail or not. But there is no specific method to use to reproduce the issue. We used very basic scenario as I mentioned in the first e-mail.

 1)      Each DSP chip is assigned with unique ip address.

2)      Create rtp channels in all the cores with unique port numbers per DSP chip.

3)      Send traffic to all cores, you will see some of the cores did not receive any packet at all.

 I thought the TI engineer earlier mentioned that they had seen this issue and delay was needed to fix the issue,

 “I think, I too faced this packet missing and got fixed by adding some delay.

Let me check with team to know better this background.”

 

Please let us know, if we can avoid adding delay and what is the root cause of the some cores not receiving any packet.

 

Rex