using perf for profiling

the sample code test_a.c as below:

#include <stdio.h>
#include <stdint.h>
#include <string.h>

void func3(void)
{
   int count = 0;
   char src[100];
   char dst[100];
   for(count=0; count < 0XFF; count++)
       memcpy(src,dst, sizeof(src));

   return;
}

void func2()
{
   int count = 0;
   int64_t s =1;
   for(count=0; count < 0XFF; count++)
   {
       s =s *(count+1);
       func3();
   }

   return;
}

void func4()
{
   int count = 0;
   int64_t s =1;
   for(count=0; count < 0XFF; count++)
   {
       s =s *(count+1);
       func3();
   }

   return;
}
void func1(void)
{
   int count = 0;
   for(count=0; count < 0XFFFF; count++)
       func2();

   return;
}

int main(void)
{
    printf("\n Hello World! \n");
    func1();
    printf("\n step 2! \n");
    func4();
    return 0;
}

#compiling with:

gcc -Wall  test_a.c -g -o test_a

#install perf on ubuntu 14:

 sudo apt-get install linux-tools-common linux-tools-generic linux-tools-`uname -r`

#run test_a:

./test_a

#find test_a pid as 21033 through

ps aux|grep test_a

sudo perf record -p 21033

#ctrl+c to break

sudo perf report

it will show the profiling result as below:

now you know the bottle neck--- func3()

you can also see real time cpu usage by :

sudo perf top

other option -g

perf record -g -p pid

perf report -g 'graph,0.5,caller'

perf report --max-stack=6 --stdio -s parent

ref: http://rhaas.blogspot.co.uk/2012/06/perf-good-bad-ugly.html

My git quick start

1. setup git diff tool in ~/.gitconfig

[diff]
    tool = p4merge

You can use git difftool to show a single commit.


Say you want to see the commit with the sha1 abc123:

git difftool abc123~1 abc123



(~1 tells git to move to the previous commit, so abc123~1 is the commit before abc123)


If you use this regularly, you could make a custom git command to make it easier:



Create a file called git-show somewhere on your $PATH with the following contents:
git difftool $1~1 $1



Give that file execute permissions:
chmod +x ~/path/to/git-show



Use the command git-show <sha1 or tag or ...>                                                           




For the modified files on current branch:


   git difftool ./my_modified_file



After git add command (staged files)
   git difftool --staged


2. git show current branch name:


   git branch






3. git show all remote branches:


  git branch --all






4. git switch branch:



  git checkout my_branch_name



5. git Add file:

  git add ./path/my_file.txt



6. git commit changes:

  git commit -m "my change text"



7. git push

  git push



8. git log, show change history

  git log



9. delete remote branch

  git push origin --delete branch_name



10. branch diff

   git diff master_git master_git_test



11. Create a local branch test which will use to track remote branch origin/test:

    git branch test origin/test

export KVM image to other host

steps for exporting KVM images to other host:
1. copy vm image from /var/lib/libvirt/images on source host to destination host

2. on the source host run:
    virsh dumpxml vmname > my_vm.xml
    edit my_vm.xml, removing mac address or host guid if needed.

3.  on the destination host run:
    virsh define my_vm.xml

4. start the vm:
    virsh start my_vm

Quick DPDK log

1.DPDK log level
#define RTE_LOG_EMERG 1U /**< System is unusable. */
#define RTE_LOG_ALERT 2U /**< Action must be taken immediately. */
#define RTE_LOG_CRIT 3U /**< Critical conditions. */
#define RTE_LOG_ERR 4U /**< Error conditions. */
#define RTE_LOG_WARNING 5U /**< Warning conditions. */
#define RTE_LOG_NOTICE 6U /**< Normal but significant condition. */
#define RTE_LOG_INFO 7U /**< Informational. */
#define RTE_LOG_DEBUG 8U /**< Debug-level messages. */

rte_set_log_level(); 

eg：rte_set_log_level(RTE_LOG_DEBUG    );  

rte_set_log_level() was called inside rte_eal_init()

2.DPDK log types

defined in "./liblibrte_eal/common/include/rte_log.h"：

#define RTE_LOGTYPE_EAL 0x00000001 /**< Log related to eal. */
#define RTE_LOGTYPE_MALLOC 0x00000002 /**< Log related to malloc. */
#define RTE_LOGTYPE_RING 0x00000004 /**< Log related to ring. */
#define RTE_LOGTYPE_MEMPOOL 0x00000008 /**< Log related to mempool. */
#define RTE_LOGTYPE_TIMER 0x00000010 /**< Log related to timers. */
#define RTE_LOGTYPE_PMD 0x00000020 /**< Log related to poll mode driver. */
#define RTE_LOGTYPE_HASH 0x00000040 /**< Log related to hash table. */
#define RTE_LOGTYPE_LPM 0x00000080 /**< Log related to LPM. */
#define RTE_LOGTYPE_KNI 0x00000100 /**< Log related to KNI. */
#define RTE_LOGTYPE_ACL 0x00000200 /**< Log related to ACL. */
#define RTE_LOGTYPE_POWER 0x00000400 /**< Log related to power. */
#define RTE_LOGTYPE_METER 0x00000800 /**< Log related to QoS meter. */
#define RTE_LOGTYPE_SCHED 0x00001000 /**< Log related to QoS port scheduler. */
#define RTE_LOGTYPE_PORT 0x00002000 /**< Log related to port. */
#define RTE_LOGTYPE_TABLE 0x00004000 /**< Log related to table. */
#define RTE_LOGTYPE_PIPELINE 0x00008000 /**< Log related to pipeline. */

/* these log types can be used in an application */
#define RTE_LOGTYPE_USER1 0x01000000 /**< User-defined log type 1. */
#define RTE_LOGTYPE_USER2 0x02000000 /**< User-defined log type 2. */
#define RTE_LOGTYPE_USER3 0x04000000 /**< User-defined log type 3. */
#define RTE_LOGTYPE_USER4 0x08000000 /**< User-defined log type 4. */
#define RTE_LOGTYPE_USER5 0x10000000 /**< User-defined log type 5. */
#define RTE_LOGTYPE_USER6 0x20000000 /**< User-defined log type 6. */
#define RTE_LOGTYPE_USER7 0x40000000 /**< User-defined log type 7. */
#define RTE_LOGTYPE_USER8 0x80000000 /**< User-defined log type 8. */

3. support syslog
configuration in syslog.conf

4. eal command line option
--log-level
eg： ./build/l2fwd -c 3 -n 4  --log-level  8  

5. log example code
  File *my_log = fopen("./my_log.txt", "a");
  rte_openlog_stream(my_log);
  rte_log_set_global_level(RTE_LOG_WARNING);
  RTE_LOG(ERR, USER8, "my test log, id: %d\n", 1688);

Makefile template

CC=gcc
DEBUG = -g
CFLAGS=-c -Wall $(DEBUG) -I../build/include/
LDFLAGS=-L../build/lib/
LDLIBS=-lrte_cfgfile -lrte_eal
SOURCES=test_cfg.c
OBJECTS=$(SOURCES:.c=.o)
EXECUTABLE=test_cfg
all: $(SOURCES) $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
    # $(CC) $(LDFLAGS) $(OBJECTS) -o $@
    # $(CC) $(OBJECTS) -o $@ $(LDFLAGS)
    $(CC) $(OBJECTS) $(LDFLAGS) $(LDLIBS) -o $@

.c.o:
     $(CC) $(CFLAGS) $< -o $@
clean:
     rm -rf *.o $(EXECUTABLE)

stack-frame-layout-on-x86-64

Argument passing on Linux x64
I'm going to simplify the discussion here on purpose and focus on integer/pointer arguments [3]. According to the ABI, the first 6 integer or pointer arguments to a function are passed in registers. The first is placed in rdi, the second in rsi, the third in rdx, and then rcx, r8 and r9. Only the 7th argument and onwards are passed on the stack.
The stack frame
With the above in mind, let's see how the stack frame for this C function looks:

long myfunc(long a, long b, long c, long d,
long e, long f, long g, long h)
{
     long xx = a * b * c * d * e * f * g * h;
     long yy = a + b + c + d + e + f + g + h;
     long zz = utilfunc(xx, yy, xx % yy);
     return zz + 20;
}

This is the stack frame: referenced from:
stack-frame-layout-on-x86-64

Hub vs Switch vs router vs VLAN

a hub, a frame is passed along or "broadcast" to every one of its ports. It doesn't matter that the frame is only destined for one port. The hub has no way of distinguishing which port a frame should be sent to. Passing it along to every port ensures that it will reach its intended destination. This places a lot of traffic on the network and can lead to poor network response times. (layer 2)

A switch, however, keeps a record of the MAC addresses of all the devices connected to it. With this information, a switch can identify which system is sitting on which port. So when a frame is received, it knows exactly which port to send it to, without significantly increasing network response times. And, unlike a hub, a 10/100Mbps switch will allocate a full 10/100Mbps to each of its ports. So regardless of the number of PCs transmitting, users will always have access to the maximum amount of bandwidth. (layer 2)

A router is typically connected to at least two networks, commonly two Local Area Networks (LANs) or Wide Area Networks (WAN) or a LAN and its ISP's network . for example, your PC or workgroup and EarthLink. Routers are located at gateways, the places where two or more networks connect. Using headers and forwarding tables, routers determine the best path for forwarding the packets. Router use protocols such as ICMP to communicate with each other and configure the best route between any two hosts.

Virtual LANs (VLANs) are an abstraction to permit a single physical network to emulate the functionality of multiple parallel physical networks. This is handy because there may be situations where you need the functionality of multiple parallel physical networks but you'd rather not spend the money on buying parallel hardware. (VLAN protocol 802.1Q) http://serverfault.com/questions/188350/how-do-vlans-work 46down voteaccepted If you have more than one VLAN on a port (a "trunk port"), you need some way to tell which packet belongs to which VLAN on the other end. To do this you are "tagging" a packet with a VLAN tag (or VLAN header if you like). In reality a VLAN tag is inserted in the Ethernet frame like this: VLAN Header

The 802.1Q (dot1q, VLAN) tag contains a VLAN-ID and other things explained in the 802.1Q Standard. The first 16 bits contain the "Tag Protocol Identifier" (TPID) which is 8100. This also doubles as the EtherType 0x8100 for devices that don't understand VLANs. So a "tagged" packet contains the VLAN information in the Ethernet frame while an "untagged" packet doesn't. A typical use case would be if you have one port from a router to a switch which multiple customers are attached to: VLAN Trunking

In this example customer "Green" has VLAN 10 and Customer "Blue" has VLAN 20. The ports between switch and customers are "untagged" meaning for the customer the arriving packet is just a normal Ethernet packet. The port between router and switch is configured as a trunk port so that both router and switch know which packet belongs to which customer VLAN. On that port the Ethernet frames are tagged with the 802.1Q tag.