• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1523 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.

Packet accelerator feedback

Pavlo Sergiienko
Intellectual 660 points

Hi everyone,

I'am using MSDK 2.1.2.6, custom board with C6670 processor.

If you look in the pdk_C6670_1_1_2_6\packages\ti\drv\pa\example\emacExample\ cppi_qmss_mgmt.c file, you can find a CycleDelay (10000) line (#753) in the SendPacket() function. To my understanding this delay required for PA to generate the CRC, and insert it in the packet. At some forum threads there was a discussion about  necessity of that line, but for my case without it some random packet loss occur on the accepting side using standard UDP frames (1518 bytes) and Gigabit connection.

But it's another topic at this thread. I wanted to ask is there any feedback possible from Packet Accelerator? In particular I want to know the exact moment when it finished CRC calculation and packet modification, so now it should be ready to accept another packet for processing.

I'am asking because I don't really like the "Delay" way, since it has a constant value, and in case of some exceptions it could be not enough. I observe the packet loss on the receiving side if I remove the CycleDelay statement. Worth to mention that such problems occur only with Gigabit connection, with 100 Mbps or lower networks no such phenomena observed.

Best Regards,

Pavlo!

  • 0
    TI__Guru* 81335 points
    Hi Pavlo,
    I will ask PA expert to comment. Thank you.
  • 0 in reply to Raja
    TI__Guru* 95265 points
    Can you let me know what is the loopback mode in your case? internal loopback or loopback_none but use something to loop Tx/Rx externally?

    Seems that the PA/switch takes sometime to processing the packet that is why there is cycleDelay. There is feedback at Qmss_getQueueEntryCount(gvTxQ[8]), this should be always = 1, you can monitor this for every packets Tx out, if you saw this went up (i.e., when you made the cycleDelay very small), then there is Tx packet loss.

    Regards, Eric
  • 0 in reply to lding
    Intellectual 660 points

    Hi, Eric, Raja,

    Thank you for your reply.

    According to this statement in the CPPI initialization code and send_packet() function, I can assume that we have the loopback_none mode. 

    // Clear CPPI Loobpack bit in PASS CDMA Global Emulation Control Register
    Cppi_setCpdmaLoopback(gCpdmaHnd, 0);

    Cppi_setPSFlags(Cppi_DescType_HOST, (Cppi_Desc *)pCppiDesc, 0);

    As I understand with Qmss_getQueueEntryCount(gvTxQ[8]) function we can track an error appearance during the PA routine work. It's useful to know for exception processing, thank you for this information. Or you mean that we can forbid sending next packet for processing until the  Qmss_getQueueEntryCount(gvTxQ[8]) will be equal to 0? 

    But I really want to know is there a register or flag that can notify us about successful packet processing (i.e. PA done processing you can send the next packet), with such logic we could replace the Delay statement to more reliable and universal for any possible scenario, at least as I see it.

    Regards, Pavlo.

  • 0 in reply to Pavlo Sergiienko
    TI__Guru* 95265 points
    Pavlo,

    There is no such register or flag for it, sorry.

    Regards, Eric
  • 0 in reply to lding
    Guru 13202 points

    Eric,

    In fact. the question is not about to know, when PA has finished processing. We suspect that PA input queue might get overflowed, when we submit too much packets back to back without any delay. I'd reformulate the question as, is there a way to know the status of the input queue with qualifications like "There is room in the queue, OK to submit another packet" of "Queue is full, backoff with your submission".  Hope such the function does exist. Please comment.

  • 0 in reply to Victor Kazmirenko
    TI__Guru* 95265 points

    In sendpacket routine, there is code to send out the packet, you can query the queue size before and after push
       
       before = Qmss_getQueueEntryCount(gvTxQ[8]); ======> this is should be 0
        Qmss_queuePush (gvTxQ[8], hd, len4, CONFIG_SIZE_DESC, Qmss_Location_TAIL);
        after = Qmss_getQueueEntryCount(gvTxQ[8]); ======> this is should be 1

    You can try different delay values between successive packets to see how "before" and "after" changes. If you send packets too fast, the "after" will increase to 2, 3 .... . This can be used for your purpose.

    Regards, Eric 

  • 0 in reply to lding
    Guru 13202 points

    Hi Eric,

    Your hint was just right: I see queue entry count becomes 1 right after packet submission. Now its time for us to get use of it.

    Thank you.