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.

TMS320C6678: Questions about NDK bufsize

Genius 13655 points
Part Number: TMS320C6678



Hello Champs, 

Customer has some questions about NDK. 

(1) What's the relationship between pbm buffer, queue, tcp bufsize and nimu?

(2) What's the relationship between the rc value and the bufsize of send(), recv()?


Thanks.
Rgds
Shine

  • Hi,

    PBM buffer is the NDK global buffer for hold the Tx and Rx packets. In Rx direction, when NIMU received the packets, it put into PBM. In the Tx direction, the packet from PBM sends to NIMU, EMAC for transmit.

    There is no direct relationship between TCP buffer size and PBM buffer. Below:

    #define CFGITEM_IP_SOCKTCPTXBUF 26 /* TCP Transmit buffer size */
    #define CFGITEM_IP_SOCKTCPRXBUF 27 /* TCP Receive buffer size (copy mode) */
    #define CFGITEM_IP_SOCKTCPRXLIMIT 28 /* TCP Receive limit (non-copy mode) */
    #define CFGITEM_IP_SOCKUDPRXLIMIT 29 /* UDP Receive limit */

    are higher layer protocol level buffer size, when used to create a new socket.

    Regards, Eric

  • What is the relationship between rc = 80000 and the TCPbufsize (send(s,buff,TCPbufsize ,0);).

  • It means RC = 80000 is pbmbuff?

  • Hi,

    PBM buffer size is determined inside packages\ti\ndk\stack\pbm\pbm_data.c.

    Regards, Eric

  • Hi,Iding

    I think that I'll find out what is PBM, but I still want to find out What is the relationship between rc = 80000 and the TCPbufsize (send(s,buff,TCPbufsize ,0);)

    thanks

  • Hi,

    I thought there is no direct relationship between RC and send. From searching the NDK source code, e.g. NDK 3.61.01.01. The RC you used here is CFGITEM_IP_SOCKTCPTXBUF. This is used in: 

    int SockNew( int Family, int Type, int Protocol, int RxBufSize, int TxBufSize, void **phSock ) for creating a new socket.

    Then in the int32_t SlNetIfNDK_send(int16_t sd, void *sdContext, const void *buf, uint32_t len, uint32_t flags) this calls NDK_send(). I thought the len here needs to <= TxBufSize.

    Regards, Eric

  • Hi,

    thanks again.In my test,I found that increasing the value of RC increases the network transmission rate.Moreover, RC has little to do with the buffsize of send or recv.In addition,I found that the udp protocol for the NDKl cannot exceed 1472 bytes in a single transmission,If you go over it, you get stuck in the send().But tcp is 2048 ,If you exceed it, it will help you break it down.such as 2049,TCP it will split into 2048 and 1.Also in recvieving,udp is 3012,(if the client send more than 3012,it also stuck),tcp is 1460(but it will split)

    regards

  • Hi,

    That is not related to buffer size, but how big the Ethernet driver can send out a packet. It is subject to the maximum MTU size setup (1514 bytes ) in the CPSW. For TCP of 2049 bytes, you mentioned it will be split into 2048 and 1 bytes. I thought that is inside the TCP protocol level, but when you look at the layer 2, I believe the packet size of 2048 bytes is further split into 2, the first one is around 1514 bytes (with header), and the other is the remaining. You should be able to do a Wireshark capture to confirm this.

    If you want to do one packet beyond the 1514 bytes, you need to enable jumbo packet support. There is information on old MCSDK: https://processors.wiki.ti.com/index.php/Enabling_Jumbo_Packet_Support_for_C6678

    Regards, Eric

  • Hi,

    I think I've figured out the relationship between them.But I have one more question

     #define MAX_NUM_NIMU_DESC   (NIMU_NUM_TX_DESC + NIMU_NUM_RX_DESC + NIMU_MAX_NUM_TX_CMD_DESC) /**< Maximum number of descriptors used by NIMU */ .

    What is the use of this file descriptor.

    thanks

  • Hi,

    For C6678 device, the network co-processor (NETCP) relies on the queue manager subsystem (QMSS) and the packet DMA to communicate with the host, the MAX_NUM_NIMU_DESC is used for queue setup in QMSS. 

    This is not related to NDK, but SOC specific.

    Regards, Eric