network stack

refer to dvr_rdk\mcfw\src_linux\utils\sys_pri\src\sys_pri.c, this is the src code for sys_pri.out

the last number means a priority.

refer to sprugx8 "DM816x DaVinci Technical Reference Manual " chapter

4.2.1.1 Priority Extension Generator (PEG) for detail

hello,

Q1. By checking the provision, I didn't find the default value. Did you know that?

Q2. by checking following, did you know why TI just set the following only?

./target/rfs_816x/opt/dvr_rdk/ti816x/init.sh:./bin/sys_pri.out --dmm-pri-set DUCATI 0
./target/rfs_816x/opt/dvr_rdk/ti816x/init.sh:./bin/sys_pri.out --dmm-pri-set HDVICP0 2
./target/rfs_816x/opt/dvr_rdk/ti816x/init.sh:./bin/sys_pri.out --dmm-pri-set HDVICP1 2
./target/rfs_816x/opt/dvr_rdk/ti816x/init.sh:./bin/sys_pri.out --dmm-pri-set HDVICP2 2

Q1: check the red line, sorry,  but I don't know the default vaule

/opt/dvr_rdk/ti816x/bin# ./sys_pri.out --help

TI816x System Prioirty read/write utility, (c) Texas Instruments 2010
Built on Jan 16 2014 21:13:47

./sys_pri.out --printAll # Prints all system priority setting info
./sys_pri.out --regDump # Prints all register values related to system priority setting

./sys_pri.out --dmm-pri-set <dmm-initiator-name> <dmm-priority>
# Set a DMM priority for a specified DMM initiator

./sys_pri.out --L3-bw-reg-set <L3-bw-reg-initiator-name> <L3-pressure-High> <L3-pressure-Low> <L3-Bandwidth> <L3-Watermark-cycles>
# Setup L3 Bandwidth regulator for a specified L3 initiator

Valid values for "dmm-initiator-name" are,
A8 SYS_MMU DUCATI EDMA_RD0 EDMA_RD1 EDMA_RD2 EDMA_RD3
EDMA_WR0 EDMA_WR1 EDMA_WR2 EDMA_WR3 SGX HDVICP0 HDVICP1
HDVICP2 GMAC0 GMAC1 USB_DMA USB_QMGR SATA PCIE

Valid values for "L3-bw-reg-initiator-name" are,
HDVICP0 HDVICP1 HDVICP2 EDMA_RD0 EDMA_WR0 EDMA_RD1 EDMA_WR1
DSP SGX

Valid values for "dmm-priority" are, 0..7 (0 is highest priority)
Valid values for "L3-pressure-High" are, 0, 1, 3 (0 is lowest priority)
Valid values for "L3-pressure-Low" are, 0, 1, 3 (0 is lowest priority)
Valid values for "L3-Bandwidth" (in MB/s) are, 0..8191
Valid values for "L3-Watermark" (in cycles) are, 0..4095

IMPORTANT NOTE:
- L3 Static pressure cannot be set via this utility.
- Processor needs to be in supervisor mode to set L3 static priority.
- L3 Static pressure can only be read via this utility.

Q2: this should be answered by TI experts

Hello lastshad0w,

thanks for your reply.

Q1. But I can't see the value if we don't  "sys_pri.out --dmm-pri-set A8 0" ??

Valid values for "dmm-priority" are, 0..7 (0 is highest priority)  ==> this tells us the range instead of default value. Right ?

Use --printAll option to see values. If you didn't set any value it will print default value. THe priority settings are set based on optimal configuration required for different initiators.

hello Badri,

thanks for your reply.

By checking DM81xx_DVR_RDK_Network_Stack_Optimization_Techniques_for_Multichannel_NVR.pdf

I found following description in section 2.3 Optimizations with system calls

so when select() unblocks application calls recvmsg()or recvfrom() to receive one packet from kernel. 

the "recvfrom()" was mentioned always. And I'm not sure if it always means the case of UDP. As we know recv() is different from recvfrom ( Once you have a socket up and connected, you can read incoming data from the remote side using the recv() (for TCPSOCK_STREAM sockets) and recvfrom() (for UDP SOCK_DGRAM sockets). ,pls refer to http://www.beej.us/guide/bgnet/output/html/multipage/recvman.html ) 

My question is

Q1. does the description in the section just mean UDP case ?

Q2. If Q1 is true, is there any other provided function for TCP ?

For #1, Yes this was written considering RTP over UDP and you are right you need to use recv() for TCP scokets.

For#2,  I'm not aware if anything other than recv() can be used in case of TCP but man page that you have pointed out says recvfrom() and recvmsg with NULL src_address behave as recv().

hello Yogesh,

  thanks for your reply.

Q1.

By checking following table in DM81xx_DVR_RDK_Network_Stack_Optimization_Techniques_for_Multichannel_NVR.pdf

It looks like the reduction of CPU loading by Offload is 31-28 = 3%. Right?

Q2.

by following description in DM81xx_DVR_RDK_Network_Stack_Optimization_Techniques_for_Multichannel_NVR.pdf

Live555 stack has been modified to use recvmmsg(). If OPTIMIZE_NETWORK_READ_HANDLER
is defined in live555\liveMedia\Makefile, recvmmsg() is used for data reception, otherwise it uses recvfrom()

Does it mean the recvmmsg() API was implemented in tool-chain from rdk4.x? 

For #1 No you can not conclude that. First of all it is 3% improvement  on 31% so actually it is  9-10% improvement (on 100%). e.g. dropping down from 50%-28% is not just 22% improvement it is 44% gain in terms of cycles. Also, If you enable offload  at test case 1 I believe result will be different.

For#2 No recvmmsg() is already supported as a unix system call like other system calls, we just modified live555 to change the handler which was using recvfrom() and made it use recvmmsg() for performance reasons.

hello Yogesh,

thanks for your reply.

Q1. Does the interrupt coalescing was enable in the offload driver for eth1 default?  Just double confirm.

Q2. by following, it looks like this function( recvmmsg() ) was supported in tool-chain from rdk4.x. Right?

[~] $ grep -r "recvmmsg" /root/CodeSourcery/Sourcery_G++_Lite/

[~] $

but

[~] $ grep -r "recvmmsg" /home/TI-8168/DVRRDK_04.01.00.02/ti_tools/cgt_a8/arago/linux-devkit/
Binary file /home/.../ti_tools/cgt_a8/arago/linux-devkit/arm-arago-linux-gnueabi/lib/libc.so.6 
Binary file /home/.../ti_tools/cgt_a8/arago/linux-devkit/arm-arago-linux-gnueabi/lib/libc-2.12.2.so 
/home/.../ti_tools/cgt_a8/arago/linux-devkit/arm-arago-linux-gnueabi/usr/include/gnu/stubs.h:#define __stub_recvmmsg
/home/.../ti_tools/cgt_a8/arago/linux-devkit/arm-arago-linux-gnueabi/usr/include/bits/socket.h:/* For `recvmmsg'. */
/home/.../ti_tools/cgt_a8/arago/linux-devkit/arm-arago-linux-gnueabi/usr/include/bits/socket.h:extern int recvmmsg (int __fd, struct mmsghdr *__vmessages,
[~] $

hello Yogesh,

thanks for your kindly

Yogesh Marathe said:

Also, If you enable offload  at test case 1 I believe result will be different.

Q3. Does TI have the test result for reference?