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.

TCP Traffic Causes UDP EMSGSIZE Error

Other Parts Discussed in Thread: TMS320C6657

Hi,

I am hoping someone knows the cause of this strange error.

I have an embedded program running in Core-0 of my C6657, with NDK 2.24.0.11, TI-RTOS 2.0.1.23, MCSDK PDK TMS320C6657 1.1.2.6.

My program sends out an 8044-byte UDP message 25 times per second (JUMBOFRAMEs on) and listens for incoming HTTP/TCP messages, which it responds to with more HTTP/TCP.

All this runs fine until the number of incoming TCP messages increases to more than about one every second. Then the NDK_sendto() which is sending the UDP messages starts reporting EMSGSIZE (Errno 40). It doesn't recover from this even when incoming TCP messages cease. After a minute or so the error code changes to 55 (ENOBUFS).

The message size being sent via UDP is always 8044. I have checked that 8044 is given to NDK_sendto() even when NDK_sendto() is returning EMSGSIZE.

What could cause EMSGSIZE to be returned for a valid message size?

Why do incoming TCP messages cause the UDP EMSGSIZE errors?

Any ideas appreciated,

Duncan Hurst

  • Hi Duncan Hurst,

    Please follow below wiki page for enabling jumbo packet support. This wiki has been written for C6678 ,

    Thank you.

  • Hi Rajasekaran,

    If you read my original post, you will see that sending 8044 byte messages via UDP already "runs fine" with "JUMBOFRAMES on". That is, sending 8044-byte UDP messages succeeds. NDK_sendto() reports no error and the PC receiving the UDP messages sees whole 8044-byte messages.

    Usually.

    The problem is that this *stops* working when the NDK sees any significant incoming TCP traffic. NDK_sendto() then reports EMSGSIZE which cannot be an accurate error code since the message size is always constant at 8044.

    I hope this clarifies the issue and that you can help me further.

    Thanks,
    Duncan Hurst