[dpdk-dev] Testing vmdq sample application

Hi, I have started the application on my host machine.And from another terminal on host machine gave sudo killall -HUP vmdq_dcb_app and sent packets on NIC card from another machine .But on terminal where vmdq application is running, I am seeing that no packets are coming.All rows and columns are

[dpdk-dev] [memnic PATCH 0/7] MEMNIC PMD performance improvement

From: Hiroshi Shimamoto This patchset improves MEMNIC PMD performance. The first patch introduces a new benchmark test run in guest, and will be used to evaluate the following patch effects. This patchset improves the throughput results of memnic-tester. Using Xeon

[dpdk-dev] [memnic PATCH 1/7] guest: memnic-tester: PMD benchmark in guest

From: Hiroshi Shimamoto Introduce memnic-tester which benchmarks MEMNIC PMD performance in guest. It starts with two threads, one thread produces and consumes packets, other thread receives packets and directly transmits the received packets. This evaluates MEMNIC PMD

[dpdk-dev] [memnic PATCH 2/7] pmd: remove needless assignment

From: Hiroshi Shimamoto Because these assignment are done in rte_pktmbuf_alloc(), get rid of them. Signed-off-by: Hiroshi Shimamoto Reviewed-by: Hayato Momma --- pmd/pmd_memnic.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/pmd/pmd_memnic.c

[dpdk-dev] [memnic PATCH 3/7] pmd: use helper macros

From: Hiroshi Shimamoto Do not touch pktmbuf directly. Instead of direct access, use rte_pktmbuf_pkt_len() and rte_pktmbuf_data_len() to access the property. Signed-off-by: Hiroshi Shimamoto Reviewed-by: Hayato Momma --- pmd/pmd_memnic.c | 4 ++-- 1 file changed,

[dpdk-dev] [memnic PATCH 4/7] pmd: use compiler barrier

From: Hiroshi Shimamoto x86 can keep store ordering with standard operations. Using memory barrier is much expensive in main packet processing loop. Removing this improves xmit/recv packet performance. We can see performance improvements with memnic-tester. Using

[dpdk-dev] [memnic PATCH 5/7] pmd: packet receiving optimization with prefetch

From: Hiroshi Shimamoto Prefetch the next packet area to reduce memory stall cycles. Prefetching the next packet area could hide memory stall, because the next area will be accessed just after processing the current receive operations. We can see performance

[dpdk-dev] [memnic PATCH 6/7] pmd: add branch hint in recv/xmit

From: Hiroshi Shimamoto To reduce instruction cache miss, add branch condition hints into recv/xmit functions. This improves a bit performance. We can see performance improvements with memnic-tester. Using Xeon E5-2697 v2 @ 2.70GHz, 4 vCPU. size | before | after

[dpdk-dev] [memnic PATCH 7/7] pmd: split calling mbuf free

From: Hiroshi Shimamoto In rte_pktmbuf_free(), there might be cache miss/memory stall issue. In small packet case, it could harm the performance. >From the result of memnic-tester, in less than 1024 frame size the performance could be improved. Using Xeon E5-2697 v2

[dpdk-dev] [memnic PATCH 0/7] MEMNIC PMD performance improvement

Hi Shimamoto-san, (2014/09/11 16:45), Hiroshi Shimamoto wrote: > From: Hiroshi Shimamoto > > This patchset improves MEMNIC PMD performance. > > The first patch introduces a new benchmark test run in guest, > and will be used to evaluate the following patch effects. > > This patchset improves

[dpdk-dev] Testing vmdq sample application

Also check that the mac addresses are configured correctly on the packets being sent. In vmdq_dcb mode, the nic doesn't act in promiscuous mode picking up all packet irrespective of MAC address, so the destination mac must match that of the NIC port. /Bruce > -Original Message- >

[dpdk-dev] [memnic PATCH 0/7] MEMNIC PMD performance improvement

Hi Mukawa-san, > Subject: Re: [dpdk-dev] [memnic PATCH 0/7] MEMNIC PMD performance improvement > > Hi Shimamoto-san, > > > (2014/09/11 16:45), Hiroshi Shimamoto wrote: > > From: Hiroshi Shimamoto > > > > This patchset improves MEMNIC PMD performance. > > > > The first patch introduces a new

[dpdk-dev] l2fwd does not send packets

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Xin Li > Sent: Wednesday, September 10, 2014 10:19 PM > To: dev > Subject: [dpdk-dev] l2fwd does not send packets > > Hi, > > The l2fwd sample application in my environment does not send packets > through the

[dpdk-dev] l2fwd does not send packets

Hi, To make l2fwd act like a L2 bridge, I had altered l2fwd_simple_forward() function: static void l2fwd_simple_forward(struct rte_mbuf *m, unsigned portid) { unsigned dst_port; dst_port = l2fwd_dst_ports[portid]; l2fwd_send_packet(m, (uint8_t) dst_port); } 11.09.2014 3:18, Xin Li

[dpdk-dev] dpdk starting issue with descending virtual address allocation in new kernel

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Hu (NSBU) > Sent: Wednesday, September 10, 2014 11:41 PM > To: dev at dpdk.org > Subject: [dpdk-dev] dpdk starting issue with descending virtual address > allocation in new kernel > > Hi All, > > We

[dpdk-dev] Testing vmdq sample application

Hi, I want to use VMDQ for traffic exchange between virtual machines and external world. Need to know how to configure vmdq interface and the configuration to be done on virtual machine manager(host machine) as well as on the Virtual Machines(guest). On Thu, Sep 11, 2014 at 2:03 PM, Richardson,

[dpdk-dev] [PATCH v2 00/13] Mbuf Structure Rework, part 2

This patch set continues on from the changes in part 1, and depends upon that patch set. This patch set reorders the fields in the mbuf structure and splits the structure across two cache lines, given lots of new space for new fields to be added. This set uses some of that space by expanding the

[dpdk-dev] [PATCH v2 08/13] mbuf: add named points inside the mbuf structure

Add markers or "labels" at given points inside the mbuf which can be used instead of individual fields to identify the start of logical sections inside the mbuf. The use of typedefs and dummy fields was chosen over using unions because of a couple reasons: * unions cause an extra level of

[dpdk-dev] [PATCH v2 07/13] mbuf: move metadata macros to rte_port library

The metadata macros are only used by libs and apps using the rte_port packet framework library, so move them to a header file there. Signed-off-by: Bruce Richardson --- lib/librte_mbuf/rte_mbuf.h | 18 -- lib/librte_port/rte_port.h | 22 ++ 2 files changed,

[dpdk-dev] [PATCH v2 13/13] ixgbe: Improve slow-path perf: vector scattered RX

Provide a wrapper routine to enable receive of scattered packets with a vector driver. This improves the performance of the slow-path RX. Updates in V2: * Fixed up some checkpatch errors and warnings Signed-off-by: Bruce Richardson --- lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 16

[dpdk-dev] [PATCH v2 01/13] mbuf: replace data pointer by an offset

From: Olivier Matz Original patch: The mbuf structure already contains a pointer to the beginning of the buffer (m->buf_addr). It is not needed to use 8 bytes again to store another pointer to the beginning of the data. Using a 16 bits unsigned integer is enough as

[dpdk-dev] [PATCH v2 09/13] ixgbe: rework vector pmd following mbuf changes

The vector PMD expects fields to be in a specific order so that it can do vector operations on multiple fields at a time. Following mbuf rework, adjust driver to take account of the new layout and re-enable it in the config. Updates in V2: * Remove extra line at end of file to eliminate git

[dpdk-dev] [PATCH v2 06/13] mbuf: use macros only to access the mbuf metadata

Removed the explicit zero-sized metadata definition at the end of the mbuf data structure. Updated the metadata macros to take account of this change so that all existing code which uses those macros still works. Updates in V2: * None Signed-off-by: Bruce Richardson ---

[dpdk-dev] [PATCH v2 10/13] mbuf: split mbuf across two cache lines.

This change splits the mbuf in two to move the pool and next pointers to the second cache line. This frees up 16 bytes in first cache line. The reason for this change is that we believe that there is no possible way that we can ever fit all the fields we need to fit into a 64-byte mbuf, and so we

[dpdk-dev] [PATCH v2 03/13] mbuf: expand ol_flags field to 64-bits

The offload flags field (ol_flags) was 16-bits and had no further room for expansion. This patch increases the field size to 64-bits, using up the remaining reserved space in the single-cache-line mbuf. NOTE: none of the values for existing flags have been changed, i.e. no new numbers have been

[dpdk-dev] [PATCH v2 02/13] mbuf: reorder fields by time of use

* Reorder the fields in the mbuf so that we have fields that are used together side-by-side in the structure. This means that we have a contiguous block of 8-bytes in the mbuf which are used to reset an mbuf of descriptor rearm, and a block of 16-bytes of data (excluding flags) which are set on

[dpdk-dev] [PATCH v2 04/13] mbuf: introduce a flag to indicate a control mbuf

Since the flags field is now 64-bits, we can allow one bit to be used to indicate a control i.e. non-packet mbuf. Dedicate the high bit (bit 63) for this purpose and add in a utility macro to test if a given mbuf has the bit set or not. Updated in V2: * Fix typo in comment in rte_mbuf.h

[dpdk-dev] [PATCH v2 12/13] ixgbe: Fix perf regression due to moved pool ptr

Adjust the fast-path code to fix the regression caused by the pool pointer moving to the second cache line. This change adjusts the prefetching and also the way in which the mbufs are freed back to the mempool. Note: slow-path e.g. path supporting jumbo frames, is still slower, but is dealt with

[dpdk-dev] [PATCH v2 11/13] mbuf: move l2_len and l3_len to second cache line

The l2_len and l3_len fields are used for TX offloads and so should be put on the second cache line, along with the other fields only used on TX. Updates in V2: * The l2 and l3 lengths can be accessed as a single uint16_t for performance, as well as individually. Signed-off-by: Bruce

[dpdk-dev] There are a lot of error log when run l3fwd of dpdk-1.7.1

Hi, When run l3fwd sample of dpdk-1.7.1 version, there are a lot of error log. But for dpdk-1.7.0 version, so such issue. My compile option: $ make config T=x86_64-native-linuxapp-gcc $ make install T=x86_64-native-linuxapp-gcc /examples/l3fwd$ sudo ./build/l3fwd -c 0x1 -n 1 -- -p 0x1

[dpdk-dev] [PATCH 0/3] eal affinitize low priority threads to lcore 0

This patchset sets things up so that we can affinitize the interrupt, vfio management, and hpet timer management threads to lcore 0, so that they never interfere with data plane threads. Bruce Richardson (3): eal: add core id param to eal_thread_set_affinity eal: increase scope of

[dpdk-dev] [PATCH 2/3] eal: increase scope of eal_thread_set_affinity

This patch changes eal_thread_set_affinity to the EAL-local function rte_eal_thread_set_affinity. This will allow us to use the function anywhere else in the EAL, while not having it part of the official APIs Signed-off-by: Bruce Richardson --- lib/librte_eal/bsdapp/eal/eal_thread.c | 8

[dpdk-dev] [PATCH 1/3] eal: add core id param to eal_thread_set_affinity

the function eal_thread_set_affinity always sets the affinity of the thread to the lcore_id of the thread as given by the thread-local variable. To allow this function to be used by arbitrary threads (e.g. eal utility threads such as those for interrupts, timers, etc.), add a parameter to specify

[dpdk-dev] [PATCH 3/3] eal: affinitize low-priority threads to lcore 0

There are extra utility threads inside the linuxapp EAL, for managing things like interrupts, requests for the vfio file handle for multi-process, and hpet timer management. These are mostly sleeping, but to avoid any possibility of conflict with threads handling packets, this patch affinitizes

[dpdk-dev] [RFC] Virtual Machine Power Management

Hi folks, I am currently working on a Power Management example application for a Virtual Machine environment running on qemu/KVM and would appreciate any feedback(with code to share shortly). The basic idea is to provide librte_power functionality from within a VM to address the lack(for good

[dpdk-dev] [PATCH 1/4] lib/librte_table: Fix empty bucket removal during entry deletion in rte_table_hash_ext

When an entry is deleted from an extensible rte_table_hash, the bucket that stored the entry can become empty. If this is the case, the bucket needs to be removed from the chain of buckets. During removal of the bucket, the chain should be updated first. If the bucket that will be removed is

[dpdk-dev] [PATCH 2/4] lib/librte_table: Fix checking extended buckets in unoptimized case

If a key is not found in a bucket and the bucket has been extended, the extended buckets also have to checked for potentially matching keys. The extended buckets are checked at the end of the lookup. In most cases, this logic is skipped as it is uncommon to have buckets in an extended state. In

[dpdk-dev] [PATCH 3/4] lib/librte_table: Fix incorrect t->data_size_shl initialization

During initialization of rte_hash_table_ext and rte_hash_table_lru, t->data_size_shl is calculated. This member contains the number of bits to shift left during calculation of the location of entries in the hash table. To determine the number of bits to shift left, the size of the entry (as

[dpdk-dev] [PATCH 4/4] lib/librte_table: Fix pointer calculations at initialization

During initialization of rte_table_hash_ext and rte_table_hash_lru, a contiguous region of memory is allocated to store meta data, buckets, extended buckets, keys, stack of keys, stack of extended buckets and data entries. The size of each region depends on the hash table configuration. The

[dpdk-dev] [PATCH 0/4] lib/librte_table: Fix bugs occuring in corner cases

Acked by: Cristian.Dumitrescu -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Balazs Nemeth Sent: Thursday, September 11, 2014 6:47 PM To: dev at dpdk.org Cc: Nemeth, Balazs Subject: [dpdk-dev] [PATCH 0/4] lib/librte_table: Fix bugs occuring in corner cases This

[dpdk-dev] dpdk starting issue with descending virtual address allocation in new kernel

Thanks for the info, Bruce. We are using 64bit system. The kernel config that affect this behavior is CONFIG_PAX_RANDMMAP where it is defined as --- config PAX_RANDMMAP bool "Randomize user stack and mmap() bases" default y if GRKERNSEC_CONFIG_AUTO depends on PAX_ASLR select

[dpdk-dev] [PATCH] virtio: fix crash if VIRTIO_NET_F_CTRL_VQ is not negotiated

From: Damjan Marion If VIRTIO_NET_F_CTRL_VQ is not negotiated hw->cvq will be NULL Signed-off-by: Damjan Marion --- lib/librte_pmd_virtio/virtio_rxtx.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c

[dpdk-dev] [PATCH 0/3] eal affinitize low priority threads to lcore 0

On Thu, 11 Sep 2014 23:47:52 + Hiroshi Shimamoto wrote: > Hi Bruce, > > > Subject: [dpdk-dev] [PATCH 0/3] eal affinitize low priority threads to > > lcore 0 > > > > This patchset sets things up so that we can affinitize the interrupt, > > vfio management, and hpet timer management threads