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.
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.
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:
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.