[dpdk-dev] ixgbe vPMD question

2015-09-17 Thread Zoltan Kiss
Hi,

The recv function does a prefetch on cacheline1, however it seems to me 
that rx_pkts[pos] should be uninitialized pointer at that time:

http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/ixgbe_rxtx_vec.c#n287

So I guess it prefetches only random value. Or am I missing something?

Regards,

Zoltan


[dpdk-dev] [PATCH v2 4/4] librte_table: modify release notes and deprecation notice

2015-09-17 Thread Jasvinder Singh
The LIBABIVER number is incremented. The release notes
is updated and the deprecation announcement is removed.

Signed-off-by: Jasvinder Singh 
---
 doc/guides/rel_notes/deprecation.rst | 3 ---
 doc/guides/rel_notes/release_2_2.rst | 4 +++-
 lib/librte_table/Makefile| 2 +-
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 5f6079b..ce6147e 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -62,9 +62,6 @@ Deprecation Notices
   as currently they are able to access any packet buffer location except the
   packet mbuf structure.

-* librte_table LPM: A new parameter to hold the table name will be added to
-  the LPM table parameter structure.
-
 * librte_table: New functions for table entry bulk add/delete will be added
   to the table operations structure.

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index abe57b4..75fc1ab 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -44,6 +44,8 @@ ABI Changes

 * The LPM structure is changed. The deprecated field mem_location is removed.

+* librte_table LPM: A new parameter to hold the table name will be added to
+  the LPM table parameter structure.

 Shared Library Versions
 ---
@@ -76,6 +78,6 @@ The libraries prepended with a plus sign were incremented in 
this version.
  librte_reorder.so.1
  librte_ring.so.1
  librte_sched.so.1
- librte_table.so.1
+   + librte_table.so.2
  librte_timer.so.1
  librte_vhost.so.1
diff --git a/lib/librte_table/Makefile b/lib/librte_table/Makefile
index c5b3eaf..7f02af3 100644
--- a/lib/librte_table/Makefile
+++ b/lib/librte_table/Makefile
@@ -41,7 +41,7 @@ CFLAGS += $(WERROR_FLAGS)

 EXPORT_MAP := rte_table_version.map

-LIBABIVER := 1
+LIBABIVER := 2

 #
 # all source are stored in SRCS-y
-- 
2.1.0



[dpdk-dev] [PATCH v2 3/4] ip_pipeline: modify lpm table for routing pipeline

2015-09-17 Thread Jasvinder Singh
The name parameter has been defined in lpm table of
routing pipeline.

Signed-off-by: Jasvinder Singh 
---
 examples/ip_pipeline/pipeline/pipeline_routing_be.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/examples/ip_pipeline/pipeline/pipeline_routing_be.c 
b/examples/ip_pipeline/pipeline/pipeline_routing_be.c
index 1e817dd..06d3e65 100644
--- a/examples/ip_pipeline/pipeline/pipeline_routing_be.c
+++ b/examples/ip_pipeline/pipeline/pipeline_routing_be.c
@@ -484,6 +484,7 @@ pipeline_routing_init(struct pipeline_params *params,
p->n_tables = 1;
{
struct rte_table_lpm_params table_lpm_params = {
+   .name = p->name,
.n_rules = p_rt->n_routes,
.entry_unique_size = sizeof(struct routing_table_entry),
.offset = p_rt->ip_da_offset,
-- 
2.1.0



[dpdk-dev] [PATCH v2 2/4] app/test: modify table and pipeline test

2015-09-17 Thread Jasvinder Singh
LPM table and test-pipeline has been modified to
include name parameter of the lpm table.

Signed-off-by: Jasvinder Singh 
---
 app/test-pipeline/pipeline_lpm.c  |   1 +
 app/test-pipeline/pipeline_lpm_ipv6.c |   1 +
 app/test/test_table_combined.c|   2 +
 app/test/test_table_tables.c  | 102 --
 4 files changed, 63 insertions(+), 43 deletions(-)

diff --git a/app/test-pipeline/pipeline_lpm.c b/app/test-pipeline/pipeline_lpm.c
index b1a2c13..c03799c 100644
--- a/app/test-pipeline/pipeline_lpm.c
+++ b/app/test-pipeline/pipeline_lpm.c
@@ -112,6 +112,7 @@ app_main_loop_worker_pipeline_lpm(void) {
/* Table configuration */
{
struct rte_table_lpm_params table_lpm_params = {
+   .name = "LPM",
.n_rules = 1 << 24,
.entry_unique_size =
sizeof(struct rte_pipeline_table_entry),
diff --git a/app/test-pipeline/pipeline_lpm_ipv6.c 
b/app/test-pipeline/pipeline_lpm_ipv6.c
index 3f24a2d..02b7a9c 100644
--- a/app/test-pipeline/pipeline_lpm_ipv6.c
+++ b/app/test-pipeline/pipeline_lpm_ipv6.c
@@ -113,6 +113,7 @@ app_main_loop_worker_pipeline_lpm_ipv6(void) {
/* Table configuration */
{
struct rte_table_lpm_ipv6_params table_lpm_ipv6_params = {
+   .name = "LPM",
.n_rules = 1 << 24,
.number_tbl8s = 1 << 21,
.entry_unique_size =
diff --git a/app/test/test_table_combined.c b/app/test/test_table_combined.c
index dd09da5..f5c7c9b 100644
--- a/app/test/test_table_combined.c
+++ b/app/test/test_table_combined.c
@@ -293,6 +293,7 @@ test_table_lpm_combined(void)

/* Traffic flow */
struct rte_table_lpm_params lpm_params = {
+   .name = "LPM",
.n_rules = 1 << 16,
.entry_unique_size = 8,
.offset = 0,
@@ -352,6 +353,7 @@ test_table_lpm_ipv6_combined(void)

/* Traffic flow */
struct rte_table_lpm_ipv6_params lpm_ipv6_params = {
+   .name = "LPM",
.n_rules = 1 << 16,
.number_tbl8s = 1 << 13,
.entry_unique_size = 8,
diff --git a/app/test/test_table_tables.c b/app/test/test_table_tables.c
index 566964b..9d75fbf 100644
--- a/app/test/test_table_tables.c
+++ b/app/test/test_table_tables.c
@@ -322,6 +322,7 @@ test_table_lpm(void)

/* Initialize params and create tables */
struct rte_table_lpm_params lpm_params = {
+   .name = "LPM",
.n_rules = 1 << 24,
.entry_unique_size = entry_size,
.offset = 1
@@ -331,40 +332,47 @@ test_table_lpm(void)
if (table != NULL)
return -1;

-   lpm_params.n_rules = 0;
+   lpm_params.name = NULL;

table = rte_table_lpm_ops.f_create(&lpm_params, 0, entry_size);
if (table != NULL)
return -2;

+   lpm_params.name = "LPM";
+   lpm_params.n_rules = 0;
+
+   table = rte_table_lpm_ops.f_create(&lpm_params, 0, entry_size);
+   if (table != NULL)
+   return -3;
+
lpm_params.n_rules = 1 << 24;
lpm_params.offset = 32;
lpm_params.entry_unique_size = 0;

table = rte_table_lpm_ops.f_create(&lpm_params, 0, entry_size);
if (table != NULL)
-   return -3;
+   return -4;

lpm_params.entry_unique_size = entry_size + 1;

table = rte_table_lpm_ops.f_create(&lpm_params, 0, entry_size);
if (table != NULL)
-   return -4;
+   return -5;

lpm_params.entry_unique_size = entry_size;

table = rte_table_lpm_ops.f_create(&lpm_params, 0, entry_size);
if (table == NULL)
-   return -5;
+   return -6;

/* Free */
status = rte_table_lpm_ops.f_free(table);
if (status < 0)
-   return -6;
+   return -7;

status = rte_table_lpm_ops.f_free(NULL);
if (status == 0)
-   return -7;
+   return -8;

/* Add */
struct rte_table_lpm_key lpm_key;
@@ -372,75 +380,75 @@ test_table_lpm(void)

table = rte_table_lpm_ops.f_create(&lpm_params, 0, 1);
if (table == NULL)
-   return -8;
+   return -9;

status = rte_table_lpm_ops.f_add(NULL, &lpm_key, &entry, &key_found,
&entry_ptr);
if (status == 0)
-   return -9;
+   return -10;

status = rte_table_lpm_ops.f_add(table, NULL, &entry, &key_found,
&entry_ptr);
if (status == 0)
-   return -10;
+   return -11;

status = rte_table_lpm_ops.f_add(table, &lpm_key, NULL, &key_found,
&entry_ptr);
if (status == 0)
-   return -11;
+   return -12;

lpm_k

[dpdk-dev] [PATCH v2 1/4] librte_table: modify LPM table parameter structure

2015-09-17 Thread Jasvinder Singh
This patch relates to ABI change proposed for librte_table
(lpm table). A new parameter to hold the table name has
been added to the LPM table parameter structures
rte_table_lpm_params and rte_table_lpm_ipv6_params.

Signed-off-by: Jasvinder Singh 
---
 lib/librte_table/rte_table_lpm.c  | 8 ++--
 lib/librte_table/rte_table_lpm.h  | 3 +++
 lib/librte_table/rte_table_lpm_ipv6.c | 8 ++--
 lib/librte_table/rte_table_lpm_ipv6.h | 3 +++
 4 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/lib/librte_table/rte_table_lpm.c b/lib/librte_table/rte_table_lpm.c
index b218d64..849d899 100644
--- a/lib/librte_table/rte_table_lpm.c
+++ b/lib/librte_table/rte_table_lpm.c
@@ -103,7 +103,11 @@ rte_table_lpm_create(void *params, int socket_id, uint32_t 
entry_size)
__func__);
return NULL;
}
-
+   if (p->name == NULL) {
+   RTE_LOG(ERR, TABLE, "%s: Table name is NULL\n",
+   __func__);
+   return NULL;
+   }
entry_size = RTE_ALIGN(entry_size, sizeof(uint64_t));

/* Memory allocation */
@@ -119,7 +123,7 @@ rte_table_lpm_create(void *params, int socket_id, uint32_t 
entry_size)
}

/* LPM low-level table creation */
-   lpm->lpm = rte_lpm_create("LPM", socket_id, p->n_rules, 0);
+   lpm->lpm = rte_lpm_create(p->name, socket_id, p->n_rules, 0);
if (lpm->lpm == NULL) {
rte_free(lpm);
RTE_LOG(ERR, TABLE, "Unable to create low-level LPM table\n");
diff --git a/lib/librte_table/rte_table_lpm.h b/lib/librte_table/rte_table_lpm.h
index c08c958..06e8410 100644
--- a/lib/librte_table/rte_table_lpm.h
+++ b/lib/librte_table/rte_table_lpm.h
@@ -77,6 +77,9 @@ extern "C" {

 /** LPM table parameters */
 struct rte_table_lpm_params {
+   /** Table name */
+   const char *name;
+
/** Maximum number of LPM rules (i.e. IP routes) */
uint32_t n_rules;

diff --git a/lib/librte_table/rte_table_lpm_ipv6.c 
b/lib/librte_table/rte_table_lpm_ipv6.c
index ff4a9c2..e9bc6a7 100644
--- a/lib/librte_table/rte_table_lpm_ipv6.c
+++ b/lib/librte_table/rte_table_lpm_ipv6.c
@@ -109,7 +109,11 @@ rte_table_lpm_ipv6_create(void *params, int socket_id, 
uint32_t entry_size)
__func__);
return NULL;
}
-
+   if (p->name == NULL) {
+   RTE_LOG(ERR, TABLE, "%s: Table name is NULL\n",
+   __func__);
+   return NULL;
+   }
entry_size = RTE_ALIGN(entry_size, sizeof(uint64_t));

/* Memory allocation */
@@ -128,7 +132,7 @@ rte_table_lpm_ipv6_create(void *params, int socket_id, 
uint32_t entry_size)
lpm6_config.max_rules = p->n_rules;
lpm6_config.number_tbl8s = p->number_tbl8s;
lpm6_config.flags = 0;
-   lpm->lpm = rte_lpm6_create("LPM IPv6", socket_id, &lpm6_config);
+   lpm->lpm = rte_lpm6_create(p->name, socket_id, &lpm6_config);
if (lpm->lpm == NULL) {
rte_free(lpm);
RTE_LOG(ERR, TABLE,
diff --git a/lib/librte_table/rte_table_lpm_ipv6.h 
b/lib/librte_table/rte_table_lpm_ipv6.h
index 91fb0d8..43aea39 100644
--- a/lib/librte_table/rte_table_lpm_ipv6.h
+++ b/lib/librte_table/rte_table_lpm_ipv6.h
@@ -79,6 +79,9 @@ extern "C" {

 /** LPM table parameters */
 struct rte_table_lpm_ipv6_params {
+   /** Table name */
+   const char *name;
+
/** Maximum number of LPM rules (i.e. IP routes) */
uint32_t n_rules;

-- 
2.1.0



[dpdk-dev] [PATCH v2 0/4]librte_table: add name parameter to lpm table

2015-09-17 Thread Jasvinder Singh
This patchset links to ABI change announced for librte_table. For
lpm table, name parameter has been included in LPM table parameters
structure. It will eventually allow applications to create more
than one instances of lpm table, if required.

Changes in v2:
- rte_table_lpm_ipv6.c: removed name varibale from
rte_zmalloc_socket() and inserted that in rte_lpm6_create().


Jasvinder Singh (4):
  librte_table: modify LPM table parameter structure
  app/test: modify table and pipeline test
  ip_pipeline: modify lpm table for routing pipeline
  librte_table: modify release notes and deprecation notice

 app/test-pipeline/pipeline_lpm.c   |   1 +
 app/test-pipeline/pipeline_lpm_ipv6.c  |   1 +
 app/test/test_table_combined.c |   2 +
 app/test/test_table_tables.c   | 102 -
 doc/guides/rel_notes/deprecation.rst   |   3 -
 doc/guides/rel_notes/release_2_2.rst   |   4 +-
 .../ip_pipeline/pipeline/pipeline_routing_be.c |   1 +
 lib/librte_table/Makefile  |   2 +-
 lib/librte_table/rte_table_lpm.c   |   8 +-
 lib/librte_table/rte_table_lpm.h   |   3 +
 lib/librte_table/rte_table_lpm_ipv6.c  |   8 +-
 lib/librte_table/rte_table_lpm_ipv6.h  |   3 +
 12 files changed, 86 insertions(+), 52 deletions(-)

-- 
2.1.0



[dpdk-dev] Fwd: [PATCH] PPC: Fix NUMA node numbering on IBM POWER8 LE machine

2015-09-17 Thread Chao Zhu

David,

Let me take a look.

On 2015/9/16 16:09, David Marchand wrote:
> Hello Chao,
>
> On Wed, Sep 16, 2015 at 4:02 AM, Chao Zhu  > wrote:
>
> Actually, without this change, DPDK can't work properly on PPC64
> little endian platform. It'll report "EAL: Not enough memory
> available! Requested: xxxMB, available: xxxMB" such kind of error.
> But for users, they don't know that changing the value of
> CONFIG_RTE_MAX_NUMA_NODES can fix this.  That why I invoke this patch.
>
>
> Sorry, I forgot to reply in this thread.
>
> Well, to me, this is a workaround.
> Yes it will work, but what happens if tomorrow we have some hardware 
> that tells us that it has some numa node which 6 index ?
>
> I think we need a rework in eal to proerly handle this, like I said in 
> this mail :
> http://dpdk.org/ml/archives/dev/2015-September/023630.html
>
> Do you think you can look into this ?
>
>
> Thanks.
>
> -- 
> David Marchand



[dpdk-dev] QoS scheduler example fails to run

2015-09-17 Thread Gholam Reza Rahimi
Hi all,

I'm trying to run QoS scheduler example based on the information which has
been posted in "http://dpdk.org/doc/guides/sample_app_ug/qos_scheduler.html";
with DPDK 2.1.0.

I have been trying different hugepage sizes (2MByte, 1GByte), but I have
received the same error for both.

I have pasted the output to the end of this email.

Any kind of help will be appreciated.

Regards,
Reza


EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 6 on socket 0
EAL: Detected lcore 7 as core 7 on socket 0
EAL: Detected lcore 8 as core 0 on socket 1
EAL: Detected lcore 9 as core 1 on socket 1
EAL: Detected lcore 10 as core 2 on socket 1
EAL: Detected lcore 11 as core 3 on socket 1
EAL: Detected lcore 12 as core 4 on socket 1
EAL: Detected lcore 13 as core 5 on socket 1
EAL: Detected lcore 14 as core 6 on socket 1
EAL: Detected lcore 15 as core 7 on socket 1
EAL: Detected lcore 16 as core 0 on socket 0
EAL: Detected lcore 17 as core 1 on socket 0
EAL: Detected lcore 18 as core 2 on socket 0
EAL: Detected lcore 19 as core 3 on socket 0
EAL: Detected lcore 20 as core 4 on socket 0
EAL: Detected lcore 21 as core 5 on socket 0
EAL: Detected lcore 22 as core 6 on socket 0
EAL: Detected lcore 23 as core 7 on socket 0
EAL: Detected lcore 24 as core 0 on socket 1
EAL: Detected lcore 25 as core 1 on socket 1
EAL: Detected lcore 26 as core 2 on socket 1
EAL: Detected lcore 27 as core 3 on socket 1
EAL: Detected lcore 28 as core 4 on socket 1
EAL: Detected lcore 29 as core 5 on socket 1
EAL: Detected lcore 30 as core 6 on socket 1
EAL: Detected lcore 31 as core 7 on socket 1
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 32 lcore(s)
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0x2 bytes
EAL: Virtual area found at 0x7f974000 (size = 0x2)
EAL: Ask a virtual area of 0x2 bytes
EAL: Virtual area found at 0x7f95 (size = 0x2)
EAL: Requesting 8 pages of size 1024MB from socket 0
EAL: Requesting 8 pages of size 1024MB from socket 1
EAL: TSC frequency is ~2094950 KHz
EAL: Master lcore 1 is ready (tid=5b208900;cpuset=[1])
EAL: lcore 7 is ready (tid=5930d700;cpuset=[7])
EAL: lcore 5 is ready (tid=59b0e700;cpuset=[5])
EAL: PCI device :02:00.0 on NUMA socket 0
EAL:   probe driver: 8086:1521 rte_igb_pmd
EAL:   Not managed by a supported kernel driver, skipped
EAL: PCI device :02:00.1 on NUMA socket 0
EAL:   probe driver: 8086:1521 rte_igb_pmd
EAL:   PCI memory mapped at 0x7f994000
EAL:   PCI memory mapped at 0x7f994010
PMD: eth_igb_dev_init(): port_id 0 vendorID=0x8086 deviceID=0x1521
EAL: PCI device :02:00.2 on NUMA socket 0
EAL:   probe driver: 8086:1521 rte_igb_pmd
EAL:   Not managed by a supported kernel driver, skipped
EAL: PCI device :02:00.3 on NUMA socket 0
EAL:   probe driver: 8086:1521 rte_igb_pmd
EAL:   PCI memory mapped at 0x7f9940104000
EAL:   PCI memory mapped at 0x7f9940204000
PMD: eth_igb_dev_init(): port_id 1 vendorID=0x8086 deviceID=0x1521
APP: Initializing port 0... PMD: eth_igb_rx_queue_setup():
sw_ring=0x7f9815b96040 hw_ring=0x7f9815b96480 dma_addr=0x4d5b96480
PMD: eth_igb_tx_queue_setup(): To improve 1G driver performance, consider
setting the TX WTHRESH value to 4, 8, or 16.
PMD: eth_igb_tx_queue_setup(): sw_ring=0x7f9815b84ec0
hw_ring=0x7f9815b85f00 dma_addr=0x4d5b85f00
PMD: eth_igb_start(): <<
done:  Link Up - speed 1000 Mbps - full-duplex
APP: Initializing port 1... PMD: eth_igb_rx_queue_setup():
sw_ring=0x7f9815b74840 hw_ring=0x7f9815b74c80 dma_addr=0x4d5b74c80
PMD: eth_igb_tx_queue_setup(): To improve 1G driver performance, consider
setting the TX WTHRESH value to 4, 8, or 16.
PMD: eth_igb_tx_queue_setup(): sw_ring=0x7f9815b636c0
hw_ring=0x7f9815b64700 dma_addr=0x4d5b64700
PMD: eth_igb_start(): <<
done:  Link Up - speed 1000 Mbps - full-duplex
SCHED: Low level config for pipe profile 0:
Token bucket: period = 3277, credits per period = 8, size = 100
Traffic classes: period = 500, credits per period = [12207, 12207,
12207, 12207]
Traffic class 3 oversubscription: weight = 0
WRR cost: [1, 1, 1, 1], [1, 1, 1, 1], [1, 1, 1, 1], [1, 1, 1, 1]
EAL: Error - exiting with code: 1


[dpdk-dev] [PATCH v2 0/4]librte_table: add name parameter to lpm table

2015-09-17 Thread Dumitrescu, Cristian


> -Original Message-
> From: Singh, Jasvinder
> Sent: Thursday, September 17, 2015 7:03 PM
> To: dev at dpdk.org
> Cc: Dumitrescu, Cristian
> Subject: [PATCH v2 0/4]librte_table: add name parameter to lpm table
> 
> This patchset links to ABI change announced for librte_table. For
> lpm table, name parameter has been included in LPM table parameters
> structure. It will eventually allow applications to create more
> than one instances of lpm table, if required.
> 
> Changes in v2:
> - rte_table_lpm_ipv6.c: removed name varibale from
> rte_zmalloc_socket() and inserted that in rte_lpm6_create().
> 
> 

Acked-by: Cristian Dumitrescu 



[dpdk-dev] [PATCH 1/1] ip_pipeline: add pipeline type validation

2015-09-17 Thread Dumitrescu, Cristian


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Maciej Gajdzica
> Sent: Thursday, September 17, 2015 3:59 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/1] ip_pipeline: add pipeline type validation
> 
> This commit add to CLI command check for pipeline type. It prevents
> running CLI commands on not supported pipeline types.
> 
> Signed-off-by: Maciej Gajdzica 
> ---

Acked-by: Cristian Dumitrescu 



[dpdk-dev] virtio optimization idea

2015-09-17 Thread Xie, Huawei
On 9/8/2015 11:54 PM, Xie, Huawei wrote:
> On 9/8/2015 11:39 PM, Stephen Hemminger wrote:
>> On Fri, 4 Sep 2015 08:25:05 +
>> "Xie, Huawei"  wrote:
>>
>>> Hi:
>>>
>>> Recently I have done one virtio optimization proof of concept. The
>>> optimization includes two parts:
>>> 1) avail ring set with fixed descriptors
>>> 2) RX vectorization
>>> With the optimizations, we could have several times of performance boost
>>> for purely vhost-virtio throughput.
>>>
>>> Here i will only cover the first part, which is the prerequisite for the
>>> second part.
>>> Let us first take RX for example. Currently when we fill the avail ring
>>> with guest mbuf, we need
>>> a) allocate one descriptor(for non sg mbuf) from free descriptors
>>> b) set the idx of the desc into the entry of avail ring
>>> c) set the addr/len field of the descriptor to point to guest blank mbuf
>>> data area
>>>
>>> Those operation takes time, and especially step b results in modifed (M)
>>> state of the cache line for the avail ring in the virtio processing
>>> core. When vhost processes the avail ring, the cache line transfer from
>>> virtio processing core to vhost processing core takes pretty much CPU
>>> cycles.
>>> To solve this problem, this is the arrangement of RX ring for DPDK
>>> pmd(for non-mergable case).
>>>
>>> avail  
>>> idx
>>> +  
>>> |  
>>> +++---+-+--+   
>>> | 0  | 1  | 2 | ... |  254  | 255  |  avail ring
>>> +-+--+-+--+-+-+-+---+--+---+   
>>>   |||   |   |  |   
>>>   |||   |   |  |   
>>>   vvv   |   v  v   
>>> +-+--+-+--+-+-+-+---+--+---+   
>>> | 0  | 1  | 2 | ... |  254  | 255  |  desc ring
>>> +++---+-+--+   
>>> |  
>>> |  
>>> +++---+-+--+   
>>> | 0  | 1  | 2 | |  254  | 255  |  used ring
>>> +++---+-+--+   
>>> |  
>>> +
>>> Avail ring is initialized with fixed descriptor and is never changed,
>>> i.e, the index value of the nth avail ring entry is always n, which
>>> means virtio PMD is actually refilling desc ring only, without having to
>>> change avail ring.
>>> When vhost fetches avail ring, if not evicted, it is always in its first
>>> level cache.
>>>
>>> When RX receives packets from used ring, we use the used->idx as the
>>> desc idx. This requires that vhost processes and returns descs from
>>> avail ring to used ring in order, which is true for both current dpdk
>>> vhost and kernel vhost implementation. In my understanding, there is no
>>> necessity for vhost net to process descriptors OOO. One case could be
>>> zero copy, for example, if one descriptor doesn't meet zero copy
>>> requirment, we could directly return it to used ring, earlier than the
>>> descriptors in front of it.
>>> To enforce this, i want to use a reserved bit to indicate in order
>>> processing of descriptors.
>>>
>>> For tx ring, the arrangement is like below. Each transmitted mbuf needs
>>> a desc for virtio_net_hdr, so actually we have only 128 free slots.
>>> 
>>>   
>>>
>>>

++  
 
||  
 
||  
 
   +-+-+-+--+--+--+--+  
 
   |  0  |  1  | ... |  127 || 128  | 129  | ...  | 255  |   avail ring 
 
   +--+--+--+--+-+---+--+---+--+---+--+--+---+  
 
  | ||  ||  |  | |  
 
  v vv  ||  v  v v  
 
   +--+--+--+--+-+---+--+---+--+---+--+--+---+  
 
   | 127 | 128 | ... |  255 || 127  | 128  | ...  | 255  |   desc ring for 
virtio_net_hdr
   +--+--+--+--+-+---+--+---+--+---+--+--+---+  
 
  | ||  ||  |  | |  
 
  v vv  ||  v  v v  
 
   +--+--+--+--+-+---+--+---+--+---+--+--+---+  
 
   |  0  |  1  | ... |  127 ||  0   |  1   | ...  | 127  |   desc ring for tx 
dat 

>>>   
>>>
>> Does this st

[dpdk-dev] [PATCH 1/1] ip_pipeline: add pipeline type validation

2015-09-17 Thread Maciej Gajdzica
This commit add to CLI command check for pipeline type. It prevents
running CLI commands on not supported pipeline types.

Signed-off-by: Maciej Gajdzica 
---
 examples/ip_pipeline/app.h |1 +
 examples/ip_pipeline/init.c|2 ++
 examples/ip_pipeline/pipeline/pipeline_common_fe.h |5 +++-
 examples/ip_pipeline/pipeline/pipeline_firewall.c  |   26 +---
 .../pipeline/pipeline_flow_classification.c|   12 -
 examples/ip_pipeline/pipeline/pipeline_routing.c   |   22 -
 6 files changed, 41 insertions(+), 27 deletions(-)

diff --git a/examples/ip_pipeline/app.h b/examples/ip_pipeline/app.h
index 521e3a0..23a09c9 100644
--- a/examples/ip_pipeline/app.h
+++ b/examples/ip_pipeline/app.h
@@ -219,6 +219,7 @@ struct app_pipeline_params {
 struct app_pipeline_data {
void *be;
void *fe;
+   struct pipeline_type *ptype;
uint64_t timer_period;
 };

diff --git a/examples/ip_pipeline/init.c b/examples/ip_pipeline/init.c
index 3f9c68d..19b82e9 100644
--- a/examples/ip_pipeline/init.c
+++ b/examples/ip_pipeline/init.c
@@ -1220,6 +1220,8 @@ app_init_pipelines(struct app_params *app)
"init error\n", params->name);
}

+   data->ptype = ptype;
+
data->timer_period = (rte_get_tsc_hz() * params->timer_period)
/ 1000;
}
diff --git a/examples/ip_pipeline/pipeline/pipeline_common_fe.h 
b/examples/ip_pipeline/pipeline/pipeline_common_fe.h
index 693848d..02ebe9e 100644
--- a/examples/ip_pipeline/pipeline/pipeline_common_fe.h
+++ b/examples/ip_pipeline/pipeline/pipeline_common_fe.h
@@ -60,7 +60,7 @@ app_pipeline_data(struct app_params *app, uint32_t id)
 }

 static inline void *
-app_pipeline_data_fe(struct app_params *app, uint32_t id)
+app_pipeline_data_fe(struct app_params *app, uint32_t id, struct pipeline_type 
*ptype)
 {
struct app_pipeline_data *pipeline_data;

@@ -68,6 +68,9 @@ app_pipeline_data_fe(struct app_params *app, uint32_t id)
if (pipeline_data == NULL)
return NULL;

+   if (strcmp(pipeline_data->ptype->name, ptype->name) != 0)
+   return NULL;
+
return pipeline_data->fe;
 }

diff --git a/examples/ip_pipeline/pipeline/pipeline_firewall.c 
b/examples/ip_pipeline/pipeline/pipeline_firewall.c
index f6924ab..3a097ae 100644
--- a/examples/ip_pipeline/pipeline/pipeline_firewall.c
+++ b/examples/ip_pipeline/pipeline/pipeline_firewall.c
@@ -127,7 +127,7 @@ app_pipeline_firewall_rule_find(struct 
app_pipeline_firewall *p,
return NULL;
 }

-static void
+static int
 app_pipeline_firewall_ls(
struct app_params *app,
uint32_t pipeline_id)
@@ -139,11 +139,11 @@ app_pipeline_firewall_ls(

/* Check input arguments */
if (app == NULL)
-   return;
+   return -1;

-   p = app_pipeline_data_fe(app, pipeline_id);
+   p = app_pipeline_data_fe(app, pipeline_id, &pipeline_firewall);
if (p == NULL)
-   return;
+   return -1;

n_rules = p->n_rules;
for (priority = 0; n_rules; priority++)
@@ -161,6 +161,8 @@ app_pipeline_firewall_ls(
printf("Default rule: DROP\n");

printf("\n");
+
+   return 0;
 }

 static void*
@@ -275,7 +277,7 @@ app_pipeline_firewall_add_rule(struct app_params *app,
(key->type != PIPELINE_FIREWALL_IPV4_5TUPLE))
return -1;

-   p = app_pipeline_data_fe(app, pipeline_id);
+   p = app_pipeline_data_fe(app, pipeline_id, &pipeline_firewall);
if (p == NULL)
return -1;

@@ -363,7 +365,7 @@ app_pipeline_firewall_delete_rule(struct app_params *app,
(key->type != PIPELINE_FIREWALL_IPV4_5TUPLE))
return -1;

-   p = app_pipeline_data_fe(app, pipeline_id);
+   p = app_pipeline_data_fe(app, pipeline_id, &pipeline_firewall);
if (p == NULL)
return -1;

@@ -419,7 +421,7 @@ app_pipeline_firewall_add_default_rule(struct app_params 
*app,
if (app == NULL)
return -1;

-   p = app_pipeline_data_fe(app, pipeline_id);
+   p = app_pipeline_data_fe(app, pipeline_id, &pipeline_firewall);
if (p == NULL)
return -1;

@@ -470,7 +472,7 @@ app_pipeline_firewall_delete_default_rule(struct app_params 
*app,
if (app == NULL)
return -1;

-   p = app_pipeline_data_fe(app, pipeline_id);
+   p = app_pipeline_data_fe(app, pipeline_id, &pipeline_firewall);
if (p == NULL)
return -1;

@@ -948,8 +950,14 @@ cmd_firewall_ls_parsed(
 {
struct cmd_firewall_ls_result *params = parsed_result;
struct app_params *app = data;
+   int status;

-   app_pipeline_firewall_ls(app, params->pipeline_id);
+   status = app_pipeline_firewall_ls(app, params->pipeline_id);
+
+   if (status !

[dpdk-dev] [PATCH v3] ixgbe: fix access to last byte of EEPROM

2015-09-17 Thread Remy Horton
Incorrect operator in ixgbe_get_eeprom & ixgbe_set_eeprom prevents
last byte of EEPROM being read/written, and hence cannot be dumped
or updated in entirity using these functions.

Fixes: 0198848a47f5 ("ixgbe: add access to specific device info")

Signed-off-by: Remy Horton 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index ec2918c..4a7ee3b 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -5444,8 +5444,8 @@ ixgbe_get_eeprom(struct rte_eth_dev *dev,

first = in_eeprom->offset >> 1;
length = in_eeprom->length >> 1;
-   if ((first >= hw->eeprom.word_size) ||
-   ((first + length) >= hw->eeprom.word_size))
+   if ((first > hw->eeprom.word_size) ||
+   ((first + length) > hw->eeprom.word_size))
return -EINVAL;

in_eeprom->magic = hw->vendor_id | (hw->device_id << 16);
@@ -5464,8 +5464,8 @@ ixgbe_set_eeprom(struct rte_eth_dev *dev,

first = in_eeprom->offset >> 1;
length = in_eeprom->length >> 1;
-   if ((first >= hw->eeprom.word_size) ||
-   ((first + length) >= hw->eeprom.word_size))
+   if ((first > hw->eeprom.word_size) ||
+   ((first + length) > hw->eeprom.word_size))
return -EINVAL;

in_eeprom->magic = hw->vendor_id | (hw->device_id << 16);
-- 
1.9.3



[dpdk-dev] [RFC PATCH] vhost: Add VHOST PMD

2015-09-17 Thread Loftus, Ciara
> 
> On 2015/09/16 1:27, Loftus, Ciara wrote:
> >> +
> >> +static int
> >> +rte_pmd_vhost_devinit(const char *name, const char *params)
> >> +{
> >> +  struct rte_kvargs *kvlist = NULL;
> >> +  int ret = 0;
> >> +  int index;
> >> +  char *iface_name;
> >> +
> >> +  RTE_LOG(INFO, PMD, "Initializing pmd_vhost for %s\n", name);
> >> +
> >> +  kvlist = rte_kvargs_parse(params, valid_arguments);
> >> +  if (kvlist == NULL)
> >> +  return -1;
> >> +
> >> +  if (strlen(name) < strlen("eth_vhost"))
> >> +  return -1;
> >> +
> >> +  index = strtol(name + strlen("eth_vhost"), NULL, 0);
> >> +  if (errno == ERANGE)
> >> +  return -1;
> >> +
> >> +  if (rte_kvargs_count(kvlist, ETH_VHOST_IFACE_ARG) == 1) {
> >> +  ret = rte_kvargs_process(kvlist, ETH_VHOST_IFACE_ARG,
> >> +  &open_iface, &iface_name);
> >> +  if (ret < 0)
> >> +  goto out_free;
> >> +
> >> +  eth_dev_vhost_create(name, index, iface_name,
> >> rte_socket_id());
> >> +  }
> >> +
> >> +out_free:
> >> +  rte_kvargs_free(kvlist);
> >> +  return ret;
> >> +}
> >> +
> > This suggests to me that vHost ports will only be available/created if one
> supplies the " --vdev 'eth_vhost0,iface=...' " options when launching the
> application. There seems to be no option available to add vHost ports on-the-
> fly after the init process. One would have to restart the application with
> different parameters in order to modify the vHost port configuration. Is this
> correct?
> 
> Hi Ciara,
> 
> Thanks for your checking and description.
> We can attach and detach a port created by vhost PMD using Port Hotplug
> functionality.
> 
> example)
> ./testpmd -c f -n 4 -- -i
> testpmd> port attach eth_vhost0,iface=/tmp/aaa
> 
> Does this fit your case?
> 
> Thanks,
> Tetsuya

Hi,

Thanks for your reply. I wasn't aware of the hotplug functionality but this 
should work for this use case. Thanks!
I will continue to review the remainder of the patch and reply if I have any 
further feedback.

Ciara

> 
> > If so, this pmd implementation will not work with Open vSwitch. OVS relies
> on the ability to call the rte_vhost_driver_register function at any point in 
> the
> lifetime of the application, in order to create new vHost ports and
> subsequently register/create the sockets. Being bound to the selection
> chosen on the command line when launching the application is not suitable
> for OVS.
> >
> > Thanks,
> > Ciara



[dpdk-dev] [Q] asymmetric ping latency over KNI

2015-09-17 Thread Moon-Sang Lee
hello.
I installed dpdp-2.1.0 on my ubuntu 14.04 server where two NIC ports are
available.
There are two KNI interfaces, vEth0 and vEth1, for two NIC ports. (i.e. one
KNI for one NIC port)
And I connected two servers, M1 and M3, to each NIC port as below.

[ M1 ]eth0-[ M2 ]-eth1[ M3 ]
 (vEth0)   (vEth1)

After running KNI example in dpdk-2.1.0 source tree,
I pinged from M1 to M2(eth0) and from M3 to M2(eth1).

It shows short latency over M1-M2, but large latency (1 second) over M2-M3.
If I put "-i 0.2" option to ping, the large latency reduces to 200ms.
If I put "-i 0.x", then the latency becomes 0.x secnod.

I can't figure out what's wrong with my configuration and running
parameters.
Any comments are appreciated.

my runtime environment as follows.

# loading kni driver
insmod igb_uio.ko
insmod rte_kni,ko lo_mode=lo_mode_ring_skb

# execute kni example (i.e. packet burst size is the default, 32)
a.out -c 0x1414 -n 4 -- -p 0x3 -P --config="(0,2,4,6),(1,10,12,14)"


-- 
Moon-Sang Lee, SW Engineer
Email: sang0627 at gmail.com
Wisdom begins in wonder. *Socrates*


[dpdk-dev] [PATCH] hash: fix incorrect lookup if key is all zero

2015-09-17 Thread Thomas Monjalon
Hi Pablo,

2015-09-17 10:04, Pablo de Lara:
> If user has not added an all zero key in the hash table,
> and tries to look it up, it results in an incorrect hit,
> as dummy slot in the key table has all zero as well.
> 
> Signed-off-by: Pablo de Lara 

Please try to remember to use "Fixes:" tag.


[dpdk-dev] [PATCH v2] ixgbe: fix access to last byte of EEPROM

2015-09-17 Thread Thomas Monjalon
2015-09-17 10:05, Remy Horton:
> Incorrect operator in ixgbe_get_eeprom & ixgbe_set_eeprom prevents
> last byte of EEPROM being read/written, and hence cannot be dumped
> or updated in entirity using these functions.
> 
> Signed-off-by: Remy Horton 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

>From my previous comment:
"
Then creating a commit starting with "fix" should trigger 2 other things:
- a Fixes: tag
- an update in the release notes (because the bug exists in previous 
releases)
"

Maybe it does not deserve an entry in the release notes if the bug
has no real impact.



[dpdk-dev] X520 virtual functions worked in 2.0 but fails in 2.1

2015-09-17 Thread Jesper Wramberg
Hey there,

Thanks for your help. I checked the eth_ixgbevf_dev_init() function against
DPDK 2.0 but did think about changes in the eth_ixgbe_dev_init() function.
Anyway, I have just been using 2.0 for now but it's nice to know I wasn't
doing anything wrong :-)

Regards,
Jesper Wramberg

2015-09-16 13:27 GMT+02:00 Van Haaren, Harry :

> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jesper Wramberg
> > Hi all,
>
> Hi Jesper,
>
> > I got a Dell PowerEdge R630 with an X520 NIC. I want to set up two VFs
> that
> > use the first port on the NIC. I've done the following:
>
> Your process is correct - nothing wrong here.
>
> > EAL: PCI device :03:10.0 on NUMA socket 0
> > EAL:   probe driver: 8086:10ed rte_ixgbevf_pmd
> > EAL:   PCI memory mapped at 0x7f08c0108000
> > EAL:   PCI memory mapped at 0x7f08c010c000
> > PMD: eth_ixgbevf_dev_init():  >>
> > PMD: ixgbevf_intr_disable():  >>
> > PMD: eth_ixgbevf_dev_init(): VF Initialization Failure: -100
> > PMD: rte_eth_dev_init: driver rte_ixgbevf_pmd:
> > eth_dev_init(vendor_id=0x32902 device_id=0x10ed) failed
> > EAL: Error - exiting with code: 1
> >   Cause: Requested device :03:10.0 cannot be used
>
> This is a recently-discovered regression from commit
> 0eb609239efdb52a1cea5abca5e3316052071d81 in the ixgbe driver - a fix is in
> progress.
>
> The code in the diff below[1] of the above commit is the offender,
> And adding the code back in solves the immediate problem here.
>
> If this temporary fix doesn't work, please let me know.
> Cheers, -Harry
>
> [1] Snipped of diff that breaks DPDK PF / VF mailbox handling:
>  @@ -1000,12 +1038,6 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
>  eth_dev->data->port_id, pci_dev->id.vendor_id,
>  pci_dev->id.device_id);
>
>  -   rte_intr_callback_register(&(pci_dev->intr_handle),
>  -   ixgbe_dev_interrupt_handler, (void *)eth_dev);
>  -
>  -   /* enable uio intr after callback register */
>  -   rte_intr_enable(&(pci_dev->intr_handle));
>  -
>  /* enable support intr */
>  ixgbe_enable_intr(eth_dev);
>


[dpdk-dev] [PATCH v2] hash: fix incorrect lookup if key is all zero

2015-09-17 Thread Pablo de Lara
If user has not added an all zero key in the hash table,
and tries to look it up, it results in an incorrect hit,
as dummy slot in the key table has all zero as well.

Fixes: 48a399119619 ("hash: replace with cuckoo hash implementation") 

Signed-off-by: Pablo de Lara 
---
Changes in v2:
- Include Fixes: tag in commit message

 doc/guides/rel_notes/release_2_2.rst |  5 +
 lib/librte_hash/rte_cuckoo_hash.c| 27 +--
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index 682f468..e4460f7 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -8,6 +8,11 @@ New Features
 Resolved Issues
 ---

+* **hash: Fixed incorrect lookup if key is all zero. **
+
+Fixed issue in hash library that occurred if an all zero
+key was not added in the table and the key was looked up,
+resulting in an incorrect hit.

 Known Issues
 
diff --git a/lib/librte_hash/rte_cuckoo_hash.c 
b/lib/librte_hash/rte_cuckoo_hash.c
index 7019763..62d7143 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -861,15 +861,22 @@ lookup_stage2(unsigned idx, hash_sig_t prim_hash, 
hash_sig_t sec_hash,
 /* Lookup bulk stage 3: Check if key matches, update hit mask and return data 
*/
 static inline void
 lookup_stage3(unsigned idx, const struct rte_hash_key *key_slot, const void * 
const *keys,
-   void *data[], uint64_t *hits, const struct rte_hash *h)
+   const int32_t *positions, void *data[], uint64_t *hits,
+   const struct rte_hash *h)
 {
unsigned hit;
+   unsigned key_idx;

hit = !h->rte_hash_cmp_eq(key_slot->key, keys[idx], h->key_len);
if (data != NULL)
data[idx] = key_slot->pdata;

-   *hits |= (uint64_t)(hit) << idx;
+   key_idx = positions[idx] + 1;
+   /*
+* If key index is 0, force hit to be 0, in case key to be looked up
+* is all zero (as in the dummy slot), which would result in a wrong hit
+*/
+   *hits |= (uint64_t)(hit && !!key_idx)  << idx;
 }

 static inline void
@@ -961,8 +968,8 @@ __rte_hash_lookup_bulk(const struct rte_hash *h, const void 
**keys,
lookup_stage2(idx21, primary_hash21, secondary_hash21,
primary_bkt21, secondary_bkt21, &k_slot21, positions,
&extra_hits_mask, key_store, h);
-   lookup_stage3(idx30, k_slot30, keys, data, &hits, h);
-   lookup_stage3(idx31, k_slot31, keys, data, &hits, h);
+   lookup_stage3(idx30, k_slot30, keys, positions, data, &hits, h);
+   lookup_stage3(idx31, k_slot31, keys, positions, data, &hits, h);
}

k_slot30 = k_slot20, k_slot31 = k_slot21;
@@ -988,8 +995,8 @@ __rte_hash_lookup_bulk(const struct rte_hash *h, const void 
**keys,
lookup_stage2(idx21, primary_hash21, secondary_hash21, primary_bkt21,
secondary_bkt21, &k_slot21, positions, &extra_hits_mask,
key_store, h);
-   lookup_stage3(idx30, k_slot30, keys, data, &hits, h);
-   lookup_stage3(idx31, k_slot31, keys, data, &hits, h);
+   lookup_stage3(idx30, k_slot30, keys, positions, data, &hits, h);
+   lookup_stage3(idx31, k_slot31, keys, positions, data, &hits, h);

k_slot30 = k_slot20, k_slot31 = k_slot21;
idx30 = idx20, idx31 = idx21;
@@ -1009,14 +1016,14 @@ __rte_hash_lookup_bulk(const struct rte_hash *h, const 
void **keys,
lookup_stage2(idx21, primary_hash21, secondary_hash21, primary_bkt21,
secondary_bkt21, &k_slot21, positions, &extra_hits_mask,
key_store, h);
-   lookup_stage3(idx30, k_slot30, keys, data, &hits, h);
-   lookup_stage3(idx31, k_slot31, keys, data, &hits, h);
+   lookup_stage3(idx30, k_slot30, keys, positions, data, &hits, h);
+   lookup_stage3(idx31, k_slot31, keys, positions, data, &hits, h);

k_slot30 = k_slot20, k_slot31 = k_slot21;
idx30 = idx20, idx31 = idx21;

-   lookup_stage3(idx30, k_slot30, keys, data, &hits, h);
-   lookup_stage3(idx31, k_slot31, keys, data, &hits, h);
+   lookup_stage3(idx30, k_slot30, keys, positions, data, &hits, h);
+   lookup_stage3(idx31, k_slot31, keys, positions, data, &hits, h);

/* ignore any items we have already found */
extra_hits_mask &= ~hits;
-- 
2.4.2



[dpdk-dev] [PATCH v2] ixgbe: fix access to last byte of EEPROM

2015-09-17 Thread Remy Horton
Incorrect operator in ixgbe_get_eeprom & ixgbe_set_eeprom prevents
last byte of EEPROM being read/written, and hence cannot be dumped
or updated in entirity using these functions.

Signed-off-by: Remy Horton 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index ec2918c..4a7ee3b 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -5444,8 +5444,8 @@ ixgbe_get_eeprom(struct rte_eth_dev *dev,

first = in_eeprom->offset >> 1;
length = in_eeprom->length >> 1;
-   if ((first >= hw->eeprom.word_size) ||
-   ((first + length) >= hw->eeprom.word_size))
+   if ((first > hw->eeprom.word_size) ||
+   ((first + length) > hw->eeprom.word_size))
return -EINVAL;

in_eeprom->magic = hw->vendor_id | (hw->device_id << 16);
@@ -5464,8 +5464,8 @@ ixgbe_set_eeprom(struct rte_eth_dev *dev,

first = in_eeprom->offset >> 1;
length = in_eeprom->length >> 1;
-   if ((first >= hw->eeprom.word_size) ||
-   ((first + length) >= hw->eeprom.word_size))
+   if ((first > hw->eeprom.word_size) ||
+   ((first + length) > hw->eeprom.word_size))
return -EINVAL;

in_eeprom->magic = hw->vendor_id | (hw->device_id << 16);
-- 
1.9.3



[dpdk-dev] [PATCH] hash: fix incorrect lookup if key is all zero

2015-09-17 Thread Pablo de Lara
If user has not added an all zero key in the hash table,
and tries to look it up, it results in an incorrect hit,
as dummy slot in the key table has all zero as well.

Signed-off-by: Pablo de Lara 
---
 doc/guides/rel_notes/release_2_2.rst |  5 +
 lib/librte_hash/rte_cuckoo_hash.c| 27 +--
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index 682f468..e4460f7 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -8,6 +8,11 @@ New Features
 Resolved Issues
 ---

+* **hash: Fixed incorrect lookup if key is all zero. **
+
+Fixed issue in hash library that occurred if an all zero
+key was not added in the table and the key was looked up,
+resulting in an incorrect hit.

 Known Issues
 
diff --git a/lib/librte_hash/rte_cuckoo_hash.c 
b/lib/librte_hash/rte_cuckoo_hash.c
index 7019763..62d7143 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -861,15 +861,22 @@ lookup_stage2(unsigned idx, hash_sig_t prim_hash, 
hash_sig_t sec_hash,
 /* Lookup bulk stage 3: Check if key matches, update hit mask and return data 
*/
 static inline void
 lookup_stage3(unsigned idx, const struct rte_hash_key *key_slot, const void * 
const *keys,
-   void *data[], uint64_t *hits, const struct rte_hash *h)
+   const int32_t *positions, void *data[], uint64_t *hits,
+   const struct rte_hash *h)
 {
unsigned hit;
+   unsigned key_idx;

hit = !h->rte_hash_cmp_eq(key_slot->key, keys[idx], h->key_len);
if (data != NULL)
data[idx] = key_slot->pdata;

-   *hits |= (uint64_t)(hit) << idx;
+   key_idx = positions[idx] + 1;
+   /*
+* If key index is 0, force hit to be 0, in case key to be looked up
+* is all zero (as in the dummy slot), which would result in a wrong hit
+*/
+   *hits |= (uint64_t)(hit && !!key_idx)  << idx;
 }

 static inline void
@@ -961,8 +968,8 @@ __rte_hash_lookup_bulk(const struct rte_hash *h, const void 
**keys,
lookup_stage2(idx21, primary_hash21, secondary_hash21,
primary_bkt21, secondary_bkt21, &k_slot21, positions,
&extra_hits_mask, key_store, h);
-   lookup_stage3(idx30, k_slot30, keys, data, &hits, h);
-   lookup_stage3(idx31, k_slot31, keys, data, &hits, h);
+   lookup_stage3(idx30, k_slot30, keys, positions, data, &hits, h);
+   lookup_stage3(idx31, k_slot31, keys, positions, data, &hits, h);
}

k_slot30 = k_slot20, k_slot31 = k_slot21;
@@ -988,8 +995,8 @@ __rte_hash_lookup_bulk(const struct rte_hash *h, const void 
**keys,
lookup_stage2(idx21, primary_hash21, secondary_hash21, primary_bkt21,
secondary_bkt21, &k_slot21, positions, &extra_hits_mask,
key_store, h);
-   lookup_stage3(idx30, k_slot30, keys, data, &hits, h);
-   lookup_stage3(idx31, k_slot31, keys, data, &hits, h);
+   lookup_stage3(idx30, k_slot30, keys, positions, data, &hits, h);
+   lookup_stage3(idx31, k_slot31, keys, positions, data, &hits, h);

k_slot30 = k_slot20, k_slot31 = k_slot21;
idx30 = idx20, idx31 = idx21;
@@ -1009,14 +1016,14 @@ __rte_hash_lookup_bulk(const struct rte_hash *h, const 
void **keys,
lookup_stage2(idx21, primary_hash21, secondary_hash21, primary_bkt21,
secondary_bkt21, &k_slot21, positions, &extra_hits_mask,
key_store, h);
-   lookup_stage3(idx30, k_slot30, keys, data, &hits, h);
-   lookup_stage3(idx31, k_slot31, keys, data, &hits, h);
+   lookup_stage3(idx30, k_slot30, keys, positions, data, &hits, h);
+   lookup_stage3(idx31, k_slot31, keys, positions, data, &hits, h);

k_slot30 = k_slot20, k_slot31 = k_slot21;
idx30 = idx20, idx31 = idx21;

-   lookup_stage3(idx30, k_slot30, keys, data, &hits, h);
-   lookup_stage3(idx31, k_slot31, keys, data, &hits, h);
+   lookup_stage3(idx30, k_slot30, keys, positions, data, &hits, h);
+   lookup_stage3(idx31, k_slot31, keys, positions, data, &hits, h);

/* ignore any items we have already found */
extra_hits_mask &= ~hits;
-- 
2.4.2



[dpdk-dev] [PATCH] ethdev: add new RX/TX queue state arrays in rte_eth_dev_data

2015-09-17 Thread Thomas Monjalon
2015-09-16 21:22, De Lara Guarch, Pablo:
> From: Ananyev, Konstantin
> > Why not something like:
> > ret = dev->dev_ops->tx_queue_start(dev, tx_queue_id);
> > if (ret == 0)
> >   dev->data->tx_queue_state[tx_queue_id] =
> > RTE_ETH_QUEUE_STATE_START;
> > 
> > Same for dev_stop and RX.
> > Then you hopefully wouldn't need to update each and every PMD,
> > only rteh_ethdev* would be affected.
> 
> Problem is that some PMDs call internally queue_start/stop, but not the 
> generic rte_eth_rx_queue_start (stop and RX),
> so in that case this would not update the state of the queue.

Why not changing PMD to call rte_eth_rx_queue_start? Do you think it will be
too much error prone for later updates?


[dpdk-dev] [Pktgen] [PATCH] pktgen_setup_packets: fix race for packet header

2015-09-17 Thread Ilya Maximets
Ok. Thank you. I'll wait.

On 16.09.2015 18:37, Wiles, Keith wrote:
> Thanks the patch looks fine, but I have not had a lot of time to review it
> detail. I hope to get to it next week after I return back home.
> 
> On 9/16/15, 2:09 AM, "Ilya Maximets"  wrote:
> 
>> Ping.
>>
>> On 09.09.2015 17:22, Ilya Maximets wrote:
>>> While pktgen_setup_packets() all threads of one port uses same
>>> info->seq_pkt. This leads to constructing packets in the same memory
>>> region
>>> (&pkt->hdr). As a result, pktgen_setup_packets generates random headers.
>>>
>>> Fix that by making a local copy of info->seq_pkt and using it for
>>> constructing of packets.
>>>
>>> Signed-off-by: Ilya Maximets 
>>> ---
>>>  app/pktgen-arp.c  |  2 +-
>>>  app/pktgen-cmds.c | 40 
>>>  app/pktgen-ipv4.c |  2 +-
>>>  app/pktgen.c  | 39 +++
>>>  app/pktgen.h  |  4 ++--
>>>  app/t/pktgen.t.c  |  6 +++---
>>>  6 files changed, 54 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/app/pktgen-arp.c b/app/pktgen-arp.c
>>> index c378880..b7040d7 100644
>>> --- a/app/pktgen-arp.c
>>> +++ b/app/pktgen-arp.c
>>> @@ -190,7 +190,7 @@ pktgen_process_arp( struct rte_mbuf * m, uint32_t
>>> pid, uint32_t vlan )
>>>  
>>> rte_memcpy(&pkt->eth_dst_addr, &arp->sha, 6);
>>> for (i = 0; i < info->seqCnt; i++)
>>> -   pktgen_packet_ctor(info, i, -1);
>>> +   pktgen_packet_ctor(info, i, -1, NULL);
>>> }
>>>  
>>> // Swap the two MAC addresses
>>> diff --git a/app/pktgen-cmds.c b/app/pktgen-cmds.c
>>> index da040e5..a6abb41 100644
>>> --- a/app/pktgen-cmds.c
>>> +++ b/app/pktgen-cmds.c
>>> @@ -931,7 +931,7 @@ pktgen_set_proto(port_info_t * info, char type)
>>> if ( type == 'i' )
>>> info->seq_pkt[SINGLE_PKT].ethType = ETHER_TYPE_IPv4;
>>>  
>>> -   pktgen_packet_ctor(info, SINGLE_PKT, -1);
>>> +   pktgen_packet_ctor(info, SINGLE_PKT, -1, NULL);
>>>  }
>>>  
>>>  
>>> /
>>> **//**
>>> @@ -1067,7 +1067,7 @@ pktgen_set_pkt_type(port_info_t * info, const
>>> char * type)
>>> 
>>> (type[3] == '6') ? ETHER_TYPE_IPv6 :
>>> 
>>> /* TODO print error: unknown type */ ETHER_TYPE_IPv4;
>>>  
>>> -   pktgen_packet_ctor(info, SINGLE_PKT, -1);
>>> +   pktgen_packet_ctor(info, SINGLE_PKT, -1, NULL);
>>>  }
>>>  
>>>  
>>> /
>>> **//**
>>> @@ -1092,7 +1092,7 @@ pktgen_set_vlan(port_info_t * info, uint32_t
>>> onOff)
>>> }
>>> else
>>> pktgen_clr_port_flags(info, SEND_VLAN_ID);
>>> -   pktgen_packet_ctor(info, SINGLE_PKT, -1);
>>> +   pktgen_packet_ctor(info, SINGLE_PKT, -1, NULL);
>>>  }
>>>  
>>>  
>>> /
>>> **//**
>>> @@ -1112,7 +1112,7 @@ pktgen_set_vlanid(port_info_t * info, uint16_t
>>> vlanid)
>>>  {
>>> info->vlanid = vlanid;
>>> info->seq_pkt[SINGLE_PKT].vlanid = info->vlanid;
>>> -   pktgen_packet_ctor(info, SINGLE_PKT, -1);
>>> +   pktgen_packet_ctor(info, SINGLE_PKT, -1, NULL);
>>>  }
>>>  
>>>  
>>> /
>>> **//**
>>> @@ -1137,7 +1137,7 @@ pktgen_set_mpls(port_info_t * info, uint32_t
>>> onOff)
>>> }
>>> else
>>> pktgen_clr_port_flags(info, SEND_MPLS_LABEL);
>>> -   pktgen_packet_ctor(info, SINGLE_PKT, -1);
>>> +   pktgen_packet_ctor(info, SINGLE_PKT, -1, NULL);
>>>  }
>>>  
>>>  
>>> /
>>> **//**
>>> @@ -1157,7 +1157,7 @@ pktgen_set_mpls_entry(port_info_t * info,
>>> uint32_t mpls_entry)
>>>  {
>>> info->mpls_entry = mpls_entry;
>>> info->seq_pkt[SINGLE_PKT].mpls_entry = info->mpls_entry;
>>> -   pktgen_packet_ctor(info, SINGLE_PKT, -1);
>>> +   pktgen_packet_ctor(info, SINGLE_PKT, -1, NULL);
>>>  }
>>>  
>>>  
>>> /
>>> **//**
>>> @@ -1182,7 +1182,7 @@ pktgen_set_qinq(port_info_t * info, uint32_t
>>> onOff)
>>> }
>>> else
>>> pktgen_clr_port_flags(info, SEND_Q_IN_Q_IDS);
>>> -   pktgen_packet_ctor(info, SINGLE_PKT, -1);
>>> +   pktgen_packet_ctor(info, SINGLE_PKT, -1, NULL);
>>>  }
>>>  
>>>  
>>> /
>>> **//**
>>> @@ -1204,7 +1204,7 @@ pktgen_set_qinqids(port_info_t * info, uint16_t
>>> outerid, uint16_t innerid)
>>> info->seq_pkt[SINGLE_PKT].qinq_outerid = info->qinq_outerid;
>>> info->qinq_innerid = innerid;
>>> info->seq_pkt[SINGLE_PKT].qinq_innerid = info->qinq_innerid;
>>> -   p

[dpdk-dev] [PATCH] ethdev: add new RX/TX queue state arrays in rte_eth_dev_data

2015-09-17 Thread De Lara Guarch, Pablo


> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, September 17, 2015 8:24 AM
> To: De Lara Guarch, Pablo
> Cc: dev at dpdk.org; Ananyev, Konstantin
> Subject: Re: [dpdk-dev] [PATCH] ethdev: add new RX/TX queue state arrays
> in rte_eth_dev_data
> 
> 2015-09-16 21:22, De Lara Guarch, Pablo:
> > From: Ananyev, Konstantin
> > > Why not something like:
> > > ret = dev->dev_ops->tx_queue_start(dev, tx_queue_id);
> > > if (ret == 0)
> > >   dev->data->tx_queue_state[tx_queue_id] =
> > > RTE_ETH_QUEUE_STATE_START;
> > >
> > > Same for dev_stop and RX.
> > > Then you hopefully wouldn't need to update each and every PMD,
> > > only rteh_ethdev* would be affected.
> >
> > Problem is that some PMDs call internally queue_start/stop, but not the
> generic rte_eth_rx_queue_start (stop and RX),
> > so in that case this would not update the state of the queue.
> 
> Why not changing PMD to call rte_eth_rx_queue_start? Do you think it will
> be
> too much error prone for later updates?

I thought PMDs didn't call API from rte_ethdev. In fact, that function needs a 
port id,
which is not available in the PMD functions usually.
Well, port id can be available in this case since the queues have it as a 
field, but I see it as a worse solution,
as it would be inconsistent with the way PMDs work, IMO.

Thanks,
Pablo


[dpdk-dev] [PATCH v2]doc:Add performance test guide about how to get DPDK high perf on Intel platform

2015-09-17 Thread Xu, Qian Q
Thomas/John
Thanks a lot for your comments, and I will update the patch soon. 

Thanks
Qian

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Wednesday, September 16, 2015 9:01 PM
To: Mcnamara, John
Cc: Xu, Qian Q; dev at dpdk.org; Jayakumar, Muthurajan
Subject: Re: [dpdk-dev][PATCH v2]doc:Add performance test guide about how to 
get DPDK high perf on Intel platform

2015-09-16 10:43, Mcnamara, John:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > --- /dev/null
> > > +++ b/doc/guides/perf_test_guide/index.rst
> > 
> > Why creating a new guide?
> > Can it be included as a chapter of the Linux user guide?
> 
> I think the subject is probably distinct enough to merit its own guide 
> and it is more of an advanced topic than a getting started topic.

I think we should avoid creating too many guides.
This chapter is about using DPDK in Linux. Yes it is a bit more advanced than 
the Linux QSG. So why not creating an advanced section?


[dpdk-dev] [PATCH 8/8] app/testpmd: modify the mac of csum forwarding

2015-09-17 Thread Jijiang Liu
The change will affect on the csum fwd performance.
But I also think the change is necessary, or we cannot use csumonly fwd mode in 
a VM.

Signed-off-by: Jijiang Liu 
---
 app/test-pmd/csumonly.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 1bf3485..c4ba22e 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -636,6 +636,12 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
}
m->tso_segsz = info.tso_segsz;
m->ol_flags = ol_flags;

+   ether_addr_copy(&peer_eth_addrs[fs->peer_addr],
+   ð_hdr->d_addr);
+
+   ether_addr_copy(&ports[fs->tx_port].eth_addr,
+   ð_hdr->s_addr);

/* if verbose mode is enabled, dump debug info */
if (verbose_level > 0) {
-- 
1.7.7.6



[dpdk-dev] [PATCH 7/8] examples/vhost:support TSO in vhost sample

2015-09-17 Thread Jijiang Liu
Change the vhost sample in order to support and test TSO offload.

Signed-off-by: Jijiang Liu 
---
 examples/vhost/main.c |   20 ++--
 1 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 1b137b9..482f7af 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "main.h"

@@ -441,6 +442,9 @@ port_init(uint8_t port)

if (port >= rte_eth_dev_count()) return -1;

+   if (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_TCP_TSO)
+   rte_vhost_feature_enable(1ULL << VIRTIO_NET_F_HOST_TSO4);
+
rx_rings = (uint16_t)dev_info.max_rx_queues;
/* Configure ethernet device. */
retval = rte_eth_dev_configure(port, rx_rings, tx_rings, &port_conf);
@@ -1148,6 +1152,13 @@ virtio_tx_route(struct vhost_dev *vdev, struct rte_mbuf 
*m, uint16_t vlan_tag)
len = tx_q->len;

nh = rte_pktmbuf_mtod(m, struct ether_hdr *);
+   m->l2_len = sizeof(struct ether_hdr);
+   m->l3_len = sizeof(struct ipv4_hdr);
+   if (m->tso_segsz) {
+   m->l4_len = sizeof(struct tcp_hdr);
+   m->ol_flags |= PKT_TX_IP_CKSUM;
+   }
+
if (unlikely(nh->ether_type == rte_cpu_to_be_16(ETHER_TYPE_VLAN))) {
/* Guest has inserted the vlan tag. */
struct vlan_hdr *vh = (struct vlan_hdr *) (nh + 1);
@@ -1155,8 +1166,9 @@ virtio_tx_route(struct vhost_dev *vdev, struct rte_mbuf 
*m, uint16_t vlan_tag)
if ((vm2vm_mode == VM2VM_HARDWARE) &&
(vh->vlan_tci != vlan_tag_be))
vh->vlan_tci = vlan_tag_be;
+   m->l2_len += sizeof(struct vlan_hdr);
} else {
-   m->ol_flags = PKT_TX_VLAN_PKT;
+   m->ol_flags |= PKT_TX_VLAN_PKT;

/*
 * Find the right seg to adjust the data len when offset is
@@ -1841,10 +1853,14 @@ virtio_tx_route_zcp(struct virtio_net *dev, struct 
rte_mbuf *m,
mbuf->buf_physaddr = m->buf_physaddr;
mbuf->buf_addr = m->buf_addr;
}
-   mbuf->ol_flags = PKT_TX_VLAN_PKT;
+   mbuf->ol_flags |= PKT_TX_VLAN_PKT;
mbuf->vlan_tci = vlan_tag;
mbuf->l2_len = sizeof(struct ether_hdr);
mbuf->l3_len = sizeof(struct ipv4_hdr);
+   if (mbuf->tso_segsz) {
+   mbuf->l4_len = sizeof(struct tcp_hdr);
+   mbuf->ol_flags |= PKT_TX_IP_CKSUM;
+   }
MBUF_HEADROOM_UINT32(mbuf) = (uint32_t)desc_idx;

tx_q->m_table[len] = mbuf;
-- 
1.7.7.6



[dpdk-dev] [PATCH 6/8] lib/librte_vhost:extend supported vhost features

2015-09-17 Thread Jijiang Liu
Add host TSO support into vhost features bits

Signed-off-by: Jijiang Liu 
---
 lib/librte_vhost/virtio-net.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index b520ec5..2f9ac25 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -71,7 +71,10 @@ static struct virtio_net_config_ll *ll_root;
 #define VHOST_SUPPORTED_FEATURES ((1ULL << VIRTIO_NET_F_MRG_RXBUF) | \
(1ULL << VIRTIO_NET_F_CTRL_VQ) | \
(1ULL << VIRTIO_NET_F_CTRL_RX) | \
-   (1ULL << VHOST_F_LOG_ALL))
+   (1ULL << VHOST_F_LOG_ALL)  | \
+   (1ULL << VIRTIO_NET_F_HOST_TSO4) | \
+   (1ULL << VIRTIO_NET_F_HOST_TSO6))
+
 static uint64_t VHOST_FEATURES = VHOST_SUPPORTED_FEATURES;


-- 
1.7.7.6



[dpdk-dev] [PATCH 5/8] lib/librte_vhost:dequeue vhost TSO offload

2015-09-17 Thread Jijiang Liu
Dequeue host TSO4/6 offload in host side.

Signed-off-by: Jijiang Liu 
---
 lib/librte_vhost/vhost_rxtx.c |   29 -
 1 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 0d07338..b84ec64 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -545,6 +545,30 @@ rte_vhost_enqueue_burst(struct virtio_net *dev, uint16_t 
queue_id,
return virtio_dev_rx(dev, queue_id, pkts, count);
 }

+static inline void __attribute__((always_inline))
+vhost_dequeue_offload(uint64_t addr, struct rte_mbuf *m)
+{
+   struct virtio_net_hdr *hdr =
+   (struct virtio_net_hdr *)((uintptr_t)addr);
+
+   if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
+   switch (hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
+   case VIRTIO_NET_HDR_GSO_TCPV4:
+   m->ol_flags |= (PKT_TX_IPV4 | PKT_TX_TCP_SEG);
+   m->tso_segsz = hdr->gso_size;
+   break;
+   case VIRTIO_NET_HDR_GSO_TCPV6:
+   m->ol_flags |= (PKT_TX_IPV6 | PKT_TX_TCP_SEG);
+   m->tso_segsz = hdr->gso_size;
+   break;
+   default:
+   RTE_LOG(WARNING, VHOST_DATA,
+   "unsupported gso type %u.\n", hdr->gso_type);
+   break;
+   }
+   }
+}
+
 uint16_t
 rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t queue_id,
struct rte_mempool *mbuf_pool, struct rte_mbuf **pkts, uint16_t count)
@@ -553,6 +577,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t 
queue_id,
struct vhost_virtqueue *vq;
struct vring_desc *desc;
uint64_t vb_addr = 0;
+   uint64_t vb_net_hdr_addr = 0;
uint32_t head[MAX_PKT_BURST];
uint32_t used_idx;
uint32_t i;
@@ -604,6 +629,8 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t 
queue_id,

desc = &vq->desc[head[entry_success]];

+   vb_net_hdr_addr = gpa_to_vva(dev, desc->addr);
+
/* Discard first buffer as it is the virtio header */
if (desc->flags & VRING_DESC_F_NEXT) {
desc = &vq->desc[desc->next];
@@ -742,7 +769,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t 
queue_id,
break;

m->nb_segs = seg_num;
-
+   vhost_dequeue_offload(vb_net_hdr_addr, m);
pkts[entry_success] = m;
vq->last_used_idx++;
entry_success++;
-- 
1.7.7.6



[dpdk-dev] [PATCH 4/8] driver/virtio:enqueue TSO offload

2015-09-17 Thread Jijiang Liu
Enqueue host TSO4/6 offload in guest side.

Signed-off-by: Jijiang Liu 
---
 drivers/net/virtio/virtio_rxtx.c |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index c5b53bb..68b293e 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -198,6 +198,31 @@ virtqueue_enqueue_recv_refill(struct virtqueue *vq, struct 
rte_mbuf *cookie)
return 0;
 }

+static int
+virtqueue_enqueue_offload(struct virtqueue *txvq, struct rte_mbuf *m,
+   uint16_t idx, uint16_t hdr_sz)
+{
+   struct virtio_net_hdr *hdr = (struct virtio_net_hdr *)(uintptr_t)
+   (txvq->virtio_net_hdr_addr + idx * hdr_sz);
+
+   if (m->tso_segsz != 0 && m->ol_flags & PKT_TX_TCP_SEG) {
+   if (m->ol_flags & PKT_TX_IPV4) {
+   if (!vtpci_with_feature(txvq->hw,
+   VIRTIO_NET_F_HOST_TSO4))
+   return -1;
+   hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
+   } else if (m->ol_flags & PKT_TX_IPV6) {
+   if (!vtpci_with_feature(txvq->hw,
+   VIRTIO_NET_F_HOST_TSO6))
+   return -1;
+   hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
+   }
+   hdr->gso_size = m->tso_segsz;
+   hdr->hdr_len = m->l2_len + m->l3_len + m->l4_len;
+   }
+   return 0;
+}
+
 static int
 virtqueue_enqueue_xmit(struct virtqueue *txvq, struct rte_mbuf *cookie)
 {
@@ -221,6 +246,9 @@ virtqueue_enqueue_xmit(struct virtqueue *txvq, struct 
rte_mbuf *cookie)
dxp->cookie = (void *)cookie;
dxp->ndescs = needed;

+   if (virtqueue_enqueue_offload(txvq, cookie, idx, head_size) < 0)
+   return -EPERM;
+
start_dp = txvq->vq_ring.desc;
start_dp[idx].addr =
txvq->virtio_net_hdr_mem + idx * head_size;
-- 
1.7.7.6



[dpdk-dev] [PATCH 3/8] driver/virtio: record virtual address of virtio net header

2015-09-17 Thread Jijiang Liu
Record virtual address of virtio net header.

Signed-off-by: Jijiang Liu 
---
 drivers/net/virtio/virtio_ethdev.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 465d3cd..cb5dfee 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -376,6 +376,9 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
}
vq->virtio_net_hdr_mem =
vq->virtio_net_hdr_mz->phys_addr;
+   vq->virtio_net_hdr_addr =
+   (uint64_t)(uintptr_t)vq->virtio_net_hdr_mz->addr;
+
memset(vq->virtio_net_hdr_mz->addr, 0,
vq_size * hw->vtnet_hdr_size);
} else if (queue_type == VTNET_CQ) {
-- 
1.7.7.6



[dpdk-dev] [PATCH 2/8] driver/virtio:add virtual addr for virtio net header

2015-09-17 Thread Jijiang Liu
The virtual addr for virtio net header need to be recorded.

Signed-off-by: Jijiang Liu 
---
 drivers/net/virtio/virtqueue.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 7789411..530f840 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -189,6 +189,7 @@ struct virtqueue {
uint16_t vq_used_cons_idx;
uint16_t vq_avail_idx;
phys_addr_t virtio_net_hdr_mem; /**< hdr for each xmit packet */
+   uint64_t virtio_net_hdr_addr; /**< virtual addr for virtio net header */

/* Statistics */
uint64_tpackets;
-- 
1.7.7.6



[dpdk-dev] [PATCH 1/8] driver/virtio:add vhost TSO support capability

2015-09-17 Thread Jijiang Liu

Signed-off-by: Jijiang Liu 
---
 drivers/net/virtio/virtio_ethdev.h |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/net/virtio/virtio_ethdev.h 
b/drivers/net/virtio/virtio_ethdev.h
index 9026d42..3a66491 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -64,7 +64,9 @@
 1u << VIRTIO_NET_F_CTRL_VQ   | \
 1u << VIRTIO_NET_F_CTRL_RX   | \
 1u << VIRTIO_NET_F_CTRL_VLAN | \
-1u << VIRTIO_NET_F_MRG_RXBUF)
+1u << VIRTIO_NET_F_MRG_RXBUF | \
+1u << VIRTIO_NET_F_HOST_TSO4 | \
+1u << VIRTIO_NET_F_HOST_TSO6)

 /*
  * CQ function prototype
-- 
1.7.7.6



[dpdk-dev] [PATCH 0/8] add vhost TSO capability

2015-09-17 Thread Jijiang Liu
The patch set add the negotiation between us-vhost and virtio-net for vhost TSO 
feature, and enqueue/dequeue vhost TSO offload and change vhost sample and csum 
application to test these.

*** BLURB HERE ***

Jijiang Liu (8):
  add host TSO support in virtio_ethdev.h file
  add virtual addr for virtio net header in struct virtqueue.
  record the virtual addr for virtio net header
  enqueue TSO offload in virtio-net
  extend VHOST_SUPPORTED_FEATURES list for TSO support
  add TSO offload dequeue
  TSO support in vhost sample 
  fix an issue in csum file.

 app/test-pmd/csumonly.c|6 ++
 drivers/net/virtio/virtio_ethdev.c |3 +++
 drivers/net/virtio/virtio_ethdev.h |4 +++-
 drivers/net/virtio/virtio_rxtx.c   |   28 
 drivers/net/virtio/virtqueue.h |1 +
 examples/vhost/main.c  |   20 ++--
 lib/librte_vhost/vhost_rxtx.c  |   29 -
 lib/librte_vhost/virtio-net.c  |5 -
 8 files changed, 91 insertions(+), 5 deletions(-)

-- 
1.7.7.6



[dpdk-dev] vhost-net stops sending to virito pmd -- already fixed?

2015-09-17 Thread Ouyang, Changchun


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Kyle Larose
> Sent: Wednesday, September 16, 2015 5:05 AM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] vhost-net stops sending to virito pmd -- already
> fixed?
> 
> On Sun, Sep 13, 2015 at 5:43 PM, Thomas Monjalon
>  wrote:
> >
> > Hi,
> >
> > 2015-09-11 12:32, Kyle Larose:
> > > Looking through the version tree for virtio_rxtx.c, I saw the
> > > following
> > > commit:
> > >
> > >
> http://dpdk.org/browse/dpdk/commit/lib/librte_pmd_virtio?id=8c09c20f
> > > b4cde76e53d87bd50acf2b441ecf6eb8
> > >
> > > Does anybody know offhand if the issue fixed by that commit could be
> > > the root cause of what I am seeing?
> >
> > I won't have the definitive answer but I would like to use your
> > question to highlight a common issue in git messages:
> >
> > PLEASE, authors of fixes, explain the bug you are fixing and how it
> > can be reproduced. Good commit messages are REALLY read and useful.
> >
> > Thanks
> >
> 
> I've figured out what happened. It has nothing to do with the fix I pasted
> above. Instead, the issue has to do with running low on mbufs.
> 
> Here's the general logic:
> 
> 1. If packets are not queued, return
> 2. Fetch each queued packet, as an mbuf, into the provided array. This may
> involve some merging/etc 3. Try to fill the virtio receive ring with new mbufs
>   3.a. If we fail to allocate an mbuf, break out of the refill loop 4. Update 
> the
> receive ring information and kick the host
> 
> This is obviously a simplification, but the key point is 3.a. If we hit this 
> logic
> when the virtio receive ring is completely used up, we essentially lock up.
> The host will have no buffers with which to queue packets, so the next time
> we poll, we will hit case 1. However, since we hit case 1, we will not 
> allocate
> mbufs to the virtio receive ring, regardless of how many are now free. Rinse
> and repeat; we are stuck until the pmd is restarted or the link is restarted.
> 
> This is very easy to reproduce when the mbuf pool is fairly small, and packets
> are being passed to worker threads/processes which may increase the
> length of the pipeline.
> 
> I took a quick look at the ixgbe driver, and it looks like it checks if it 
> needs to
> allocate mbufs to the ring before trying to pull packets off the nic. Should 
> we
> not be doing something similar for virtio? Rather than breaking out early if 
> no
> packets are queued, we should first make sure there are resources with
> which to queue packets!

Try to allocate mbuf and refill the vring descriptor when 1 is hit,
This way probably address your issue.

> 
> One solution here is to increase the mbuf pool to a size where such
> exhaustion is impossible, but that doesn't seem like a graceful solution. For
> example, it may be desirable to drop packets rather than have a large
> memory pool, and becoming stuck under such a situation is not good. Further,
> it isn't easy to know the exact size required. You may end up wasting a bunch
> of resources allocating far more than necessary, or you may unknowingly
> under allocate, only to find out once your application has been deployed into
> production, and it's dropping everything on the floor.
> 
> Does anyone have thoughts on this? I took a look at virtio_rxtx and head and
> I didn't see anything resembling my suggestion.
> 
> Comments would be appreciated. Thanks,
> 
> Kyle