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.

C6678 Ethernet UDP payload size

Is there a limit on the size of UDP payload the C6678 can transmit?

I have code that works for payloads up to 1488 bytes in length. As soon as I try to send a packet with a payload longer than this (for example, 1492 bytes), the packet does not appear on the Ethernet (the packet is not detected by WireShark). The problem is not a buffer overflow in my code.

I have tried this code on two different C6678 platforms (one being the EVM6678L) and both exhibit identical behaviour.

What is the limit and where is it documented?

  • Further information: Not only do long packets never appear on the Ethernet, but also having pushed the descriptor for a long packet onto the appropriate TX queue, it never appears on the corresponding TX return queue. It looks like the Queue Manager is failing in some way.

    I have checked all the status registers that seem relevany, and none is indicating anything untoward.

  • Peter,

    The issue is that NDK stack doesn't support jumbo packet. Please look at instructions "Sending and Receiving UDP Datagrams over MTU Size" in the SPRU523H.pdf.

    Regards, Eric

  • I am not using the NDK stack. I am constructing packets and queueing them explicitly.

  • Can you explain what software you are running on 6678?

    Regards, Eric

  • I am running my own, custom software. My requirements are so simple that the considerable complexity and overheads of the NDK are inappropriate.

    The relevant part of the code is:

       TxP1->hd.packet_length = sizeof(Frame) + bytes;
       TxP1->hd.ps_flags      = 0;
       TxP1->hd.buffer_ptr    = GLOBAL(Frame);
       TxP1->hd.buffer_len    = sizeof(Frame);
       TxP1->hd.next_desc_ptr = GLOBAL(TxP2);
       TxP2->hd.buffer_ptr    = GLOBAL(Payload);
       TxP2->hd.buffer_len    = bytes;
       TxP2->hd.next_desc_ptr = 0;
       PUSH_QUEUE(TX_CH8_QUEUE, TxP1);
       while (!GET_Q_ENTRY_COUNT(TX_RETURN_QUEUE)) {}
       POP_QUEUE(TX_RETURN_QUEUE);

    As I have said, this works perfectly as long as bytes<=1488.

    Regards,

    Peter

  • Peter,

    It is most likely the DSP's switch is not configured to receive such big packets. Can you configure the MTU to 9000?

    /* Configure the Receive Maximum length on this port,

    * i.e., the maximum size the port can receive without

    * any errors.

    *

    * Set the Rx Max length to the MTU configured for the

    * interface.

    */

    CSL_CPGMAC_SL_setRxMaxLen (macPortNum, mtu);

    Regards, Eric

  • Thank you for the suggestion, but:

    1. The problem is appearing when the DSP is trying to WRITE large packets.
    2. I am already setting the following:

    gess->EMAC1.RX_MAXLEN = 9000;
    gess->EMAC2.RX_MAXLEN = 9000;
    gess->P0_RX_MAXLEN    = 9000;

    Are there any other parameters that need to be changed?

    Regards,

    Peter

  • Peter,

    That all the changes. If still doesn't work, can you check the register:

    0x2090b00: This is Rx good frame from DSP. Before change, when packet size is greater than 1488, this should stop increment. After change, this should still increment for packet size greater than 1488.

    0x2090b18: RXOVERSIZEDFRAMES. Before you change the RX_MAXLEN to 9000, this should increment by 1 when you send out a packet szie greater than 1488. After changing to 9000, this should not increment.

    0x2090b30: Rx octets. Before change, when packet size is greater than 1488, this should stop increment. After change, this should still increment for packet size greater than 1488.

    Can you let me know if you saw above behavior?

    Regards, Eric

  • The RX/TX terminology seems to be confused. From what you write it looks like RX is NOT to do with packets arriving at the DSP from an external source, but to do with packets being sent FROM the DSP!

    Anyway, 0x2090b00 is being incremented when MAXLEN is set large enough and RXOVERSIZEDFRAME increments when it is not. Still no packets appear on the Ethernet (according to WIreShark on the PC).

    My earlier comment about the TX return queue not receiving hte sent descriptor was incorrect, however, I still see no evidence of anything being put on the Ethernet.

    Back to my earlier question: is there any limit on the packet size on the EVM6678L?

  • Peter,

    6678 supports Jumbo packets, in the past I used it to send UDP packets ~3000 bytes in size using NDK.

    The statistics are from the EMAC/switch point of view. For 0x2090b00 region, Rx means Rx from DSP. For the 0x2090C00 region, Rx means from outside network. With the change, you can see the 0x2090b00 and 0x2090b30 increments correctly. Then, you should also see 0x2090C34 and 0x2090c64 increments (Tx to network). If yes, then from the switch, those big packets are sent to network already. 

    Is your setup verified to be able to capture jumbo packets (assuming you replace 6678 EVM with another device, it sends jumbo packets and Wireshark can caprure it, this is to rule out set-up issue)?

    Regards, Eric  

  • I understand the the C6678 can send large packets. My question was explicitly about the EVM6678L.

    Is there anything in this device that would prevent large packets getting out or is there no limit imposed between the C6678 DSP and the Ethernet connectior on the EVM6678L?

  • Problem Solved.

    The MTU on the PC's interface had got switched back from 9000 to the default during routine maintenance.

  • Hi Peter,

    I am still struggling to achieve Jumbo frame support in my data transfer application between PC to C6678 DSP board through Ethernet.
    I referred the section "Sending and Receiving UDP Datagrams over MTU Size" in SPRU523 doc as well as referred carefully the following wiki page:
    processors.wiki.ti.com/.../Enabling_Jumbo_Packet_Support_for_C6678
    Even though I am unable to send data of MTU size more than 2000.

    Please provide me the details how you achieved to support MTU of size 9000 in your application

    Regards,
    Hemanth, P