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

PA Multicore Example - Why is there a delay after pushing packet to switch transmit queue?

Simon Wheeler
Intellectual 425 points

Hi.

We have been using the PA Multicore example code from PDK_C6678_1_1_2_5 as a base for our access to the Gbe switch and we have a question regarding the example.

Why is there a delay of 10000 cycles after pushing a transmit packet to the switch queue?

It has the comment of "Give some time for the PA to process the packet", however since the queue being pushed into goes straight to the switch, can you explain why this delay is necessary?

We cannot afford this delay for our product but when we remove this delay and continually push packets onto the switch queue, we see corruption in packets that are greater than 1000 bytes when they appear on the wire. The last 300ish bytes are zeroed out, apparently by the switch, it isn't a consistent number.

Thanks.

  • 0
    TI__Guru* 95265 points

    Simon,

    The sample code is for loopback test and we added a delay cycle. Yes, you can remove it.

    When you say packet corruption, how fast sendPacket() inside pkttxrx.c is called by your application? Do you just send (without receiving)? Can you upload a wireshark capture showing data corruption? And what is the gPacketTxData in sendPacket() looks like? Did switch (0x2090b00) showed all packets from DSP application is received? Is the DSP EMAC connected to Internet via 1Gbe or 100/10 ports? Please provide details for us to analyze.

    Regards, Eric

  • 0 in reply to lding
    Intellectual 425 points

    Hi Eric.

    We have figured out the problem.

    Following the EMAC examples from the PDK we were calling Cppi_setData for every packet. We assumed this made an internal copy of the buffer provided, but it does not for Cppi_DescType_HOST. As a result, when we very quickly called our send function the second time, the buffer was partially overwritten before the switch was able to process the first buffer.

    The solution was to memcpy the buffer to the host descriptor buffer.

    The EMAC examples get away with this because of the 10000 cycle delay.

     May I suggest the emac examples make this clear in comments to avoid others making the same mistake we did.

    Thanks.

  • 0 in reply to Simon Wheeler
    Prodigy 95 points

    Hi, Simon

    Thank you for the solution. I had the same problem with 10000 delay. With your help it was solved.

    Also usefull topic is here: http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/520867