[dpdk-dev] [PATCH] drivers: make driver names consistent

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, August 24, 2016 11:25 PM
> To: dev at dpdk.org
> Cc: De Lara Guarch, Pablo 
> Subject: [dpdk-dev] [PATCH] drivers: make driver names consistent
>
> ...
>
> -$RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 
> 'eth_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- 
> --port-topology=chained
> +$RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 
> 'net_pcap0,rx_pcap=/path/to/ file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' -- 
> --port-topology=chained


I know that this is an existing issue but there shouldn't be a space in
"/path/to/ file". Perhaps you could fix that (in a number of places) as part
of this patch. You could probably leave out the "/path/to/" part altogether as 
it may be clearer, see below.

Also, could you wrap the long code lines in the sections that you change at 
80 chars using "\" to keep them on the page in the PDF docs, like:

$RTE_TARGET/app/testpmd -c '0xf' -n 4 \
--vdev 
'net_pcap0,rx_pcap=/path/to/file_rx.pcap,tx_pcap=/path/to/file_tx.pcap' \
-- --port-topology=chained

Or without the path part:

$RTE_TARGET/app/testpmd -c '0xf' -n 4 \
--vdev 'net_pcap0,rx_pcap=file_rx.pcap,tx_pcap=file_tx.pcap' \
-- --port-topology=chained

John

[dpdk-dev] [PATCH] drivers: make driver names consistent

[De Lara Guarch, Pablo]

> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Wednesday, August 24, 2016 3:25 PM
> To: dev at dpdk.org
> Cc: De Lara Guarch, Pablo
> Subject: [PATCH] drivers: make driver names consistent
> 
> As discussed in the past release, driver names are modified
> to be more consistent, and the future driver should follow
> this new convention.
> 
> Driver names consist of:
> "driver category"_"driver folder name"_"optional extra name".
> 
> For example:
> - Crypto null driver   -> "crypto_null"
> - Network IXGBE VF driver  -> "net_ixgbe_vf"
> 
> Signed-off-by: Pablo de Lara 

Some people asked to use "/" instead of "_", but there were compilation issues, 
so I had to use "_".

[dpdk-dev] [PATCH v1] dpdk-devbind.py: Virtio interface issue.

[souvikdey33]

This change is required to have the interface name for virtio interfaces.
When we execute the status command the for virtio inerfaces we get
Sample output without the change:
:00:04.0 'Virtio network device' if= drv=virtio-pci 
unused=virtio_pci,igb_uio
Though for other drivers this works.
Sample output with the change:
:00:04.0 'Virtio network device' if=eth0 drv=virtio-pci 
unused=virtio_pci,igb_uio

souvikdey33 (1):
  Signed-off-by: souvikdey33 

 tools/dpdk-devbind.py | 9 +
 1 file changed, 9 insertions(+)

 From d9e8937b8d88a22ee5519fde2c728b377bc8fb1f Mon Sep 17 00:00:00 2001
From: souvikdey33 
Date: Wed, 24 Aug 2016 19:56:36 -0400
Subject: [PATCH v1] Signed-off-by: souvikdey33 

When we execute the status command the for virtio inerfaces the interface name 
is not shown.
Sample output without the change.
:00:04.0 'Virtio network device' if= drv=virtio-pci 
unused=virtio_pci,igb_uio
Though for other this works.
---
 tools/dpdk-devbind.py | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/dpdk-devbind.py b/tools/dpdk-devbind.py
index b69ca2a..9829e25 100755
--- a/tools/dpdk-devbind.py
+++ b/tools/dpdk-devbind.py
@@ -36,6 +36,8 @@ import sys
 import os
 import getopt
 import subprocess
+import commands
+
 from os.path import exists, abspath, dirname, basename

 # The PCI base class for NETWORK devices
@@ -222,8 +224,15 @@ def get_pci_device_details(dev_id):
 device[name] = value
 # check for a unix interface name
 sys_path = "/sys/bus/pci/devices/%s/net/" % dev_id
+#The path for virtio devices are different. Get the correct path.
+   virtio = "/sys/bus/pci/devices/%s/" % dev_id
+cmd = " ls %s | grep 'virt' " %virtio
+virtio = commands.getoutput(cmd)
+virtio_sys_path = "/sys/bus/pci/devices/%s/%s/net/" % (dev_id,virtio)
 if exists(sys_path):
 device["Interface"] = ",".join(os.listdir(sys_path))
+elif exists(virt_path):
+device["Interface"] = ",".join(os.listdir(virtio_sys_path))
 else:
 device["Interface"] = ""
 # check if a port is used for ssh connection
-- 
2.9.3.windows.1

[dpdk-dev] [PATCH v1] Signed-off-by: Karmarkar Suyash <skarmar...@sonusnet.com> For Recurring/Periodic timers , if the lag gets introduced and it was keeping the lag consistently. Corrected the behavi

[Karmarkar Suyash]

---
 lib/librte_timer/rte_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 43da836..18782fa 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -613,7 +613,7 @@ void rte_timer_manage(void)
status.owner = (int16_t)lcore_id;
rte_wmb();
tim->status.u32 = status.u32;
-   __rte_timer_reset(tim, cur_time + tim->period,
+   __rte_timer_reset(tim, tim->expire + tim->period,
tim->period, lcore_id, tim->f, tim->arg, 1);
rte_spinlock_unlock(_timer[lcore_id].list_lock);
}
-- 
2.9.3.windows.1

[dpdk-dev] [PATCH] ethdev: ensure consistent port id assignment

[Tootoonchian, Amin]

Sergio, could you please review this patch?

Thanks,
Amin

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, July 20, 2016 8:12 AM
> To: Tootoonchian, Amin 
> Cc: dev at dpdk.org; Kerlin, MarcinX 
> Subject: Re: [dpdk-dev] [PATCH] ethdev: ensure consistent port id assignment
> 
> Hi,
> 
> 2016-07-20 15:07, Tootoonchian, Amin:
> > Thomas, your thoughts?
> 
> I have 2 thoughts:
> - it is too big for 16.07
> - it is related to multi-process mechanism, maintained by Sergio ;)
> 
> Sorry I won't look at it shortly.

[dpdk-dev] pthread_create fails with error code 11 (pthread_create: Cannot allocate memory)

[Ajay Khambadkone]

I am running dpdk with my existing application and after rte_eal_init, other 
inits and rte_eal_remote_launch, It end up going through my existing app that 
starts some more threads.

I do see all the rte_* ran successfully. But the pthread_create calls from my 
existing app fails with the following logs,

VMM rlimit set to 160
pthread_create: Cannot allocate memory
pthread_create: 11
movik_terminate called - program will exit


I have hugetables set up. I tried reducing the stack using ulimit -s 1024 and I 
still see the same issue.

Any idea?

-Ajay

[dpdk-dev] [PATCH 0/5] i40e: vector poll-mode driver on ARM64

[Shreyansh Jain]

Hi Thomas,

On Wednesday 24 August 2016 04:19 PM, Thomas Monjalon wrote:
> 2016-08-24 15:23, Jianbo Liu:
>> This patch set is to implement i40e vector PMD on ARM64.
>
> Thanks for extending ARM support.
>
> The current NIC support status is:
> % git grep -l 'ARM.*=.*Y' doc/guides/nics/features/
> doc/guides/nics/features/ixgbe.ini
> doc/guides/nics/features/ixgbe_vec.ini
> doc/guides/nics/features/ixgbe_vf.ini
> doc/guides/nics/features/ixgbe_vf_vec.ini
> doc/guides/nics/features/pcap.ini
> doc/guides/nics/features/thunderx.ini
> doc/guides/nics/features/virtio.ini
> doc/guides/nics/features/virtio_vec.ini
>
> To sum it up, only virtio, ixgbe (and specific thunderx device)
> seems to be supported on ARM in DPDK 16.07.
> Now you are bringing support of i40e on ARM.
> Do you plan to support more devices in near future?
> Who is interested to do and/or validate ARM support of other drivers?

We at NXP are currently working on integrating DPDK over NXP's ARM SoC. 
As the implementation is dependent on rte_driver/device [1] and SoC 
framework [2], my plan is to push base infra out in this week and NXP 
RFC early next week.

Other than above, we are also working on supporting ARM Crypto-extension 
based Cryto drivers.

[1] http://dpdk.org/ml/archives/dev/2016-January/031390.html (and 
multiple other patches after this)
[2] http://dpdk.org/ml/archives/dev/2016-May/038486.html

>
>

-
Shreyansh

[dpdk-dev] [PATCH] kni: memzone info not required to get mbuf address

[Thomas Monjalon]

2016-08-04 16:54, Ferruh Yigit:
> Originally mempool->mz is used to get address of the mbuf, but now
> address get directly from mempool, so mempool->mz information is not
> required.
> 
> Fixes: d1d914ebbc25 ("mempool: allocate in several memory chunks by default")
> 
> Signed-off-by: Ferruh Yigit 

Applied, thanks

[dpdk-dev] [PATCH] ethtool: remove triple license information

[Thomas Monjalon]

2016-08-04 17:45, Ferruh Yigit:
> On 8/1/2016 1:17 PM, Christian Ehrhardt wrote:
> > License information is already in LICENSE.GPL.
> > Remove two extra copies and change referred filename in the files.
> > 
> > Signed-off-by: Christian Ehrhardt 
> 
> In patch subject, I think it is better to use "kni: " tag instead of
> "ethtool:", apart from this:
> 
> Acked-by: Ferruh Yigit 

Applied, thanks

[dpdk-dev] [PATCH v2] scripts: make load-devel-config not to appear as executable

[Thomas Monjalon]

2016-08-03 16:59, Christian Ehrhardt:
> *Updates in v2*
> - drop the #!/bin/echo now that it is no more executable
> 
> Quoting the first line of the script: "#! /bin/echo must be loaded with ."
> Given that we should drop the .sh file ending as well as the executable
> flag - both are not needed to source the file.
> 
> Signed-off-by: Christian Ehrhardt 

Applied, thanks (despite I disagree with this change ;)

[dpdk-dev] [PATCH 2/4] mempool: make cache flush threshold macro public

[Olivier MATZ]

Hi Robert,

On 08/23/2016 06:07 PM, Sanford, Robert wrote:
> Hi Olivier,
>
> On 8/23/16, 11:09 AM, "Olivier MATZ"  wrote:
>
>  Hi Robert,
>
>  On 08/01/2016 10:42 PM, Robert Sanford wrote:
>  > Rename macros that calculate a mempool cache flush threshold, and
>  > move them from rte_mempool.c to rte_mempool.h, so that the bonding
>  > driver can accurately calculate its mbuf requirements.
>  >
>  > Signed-off-by: Robert Sanford 
>  > ---
>  >   lib/librte_mempool/rte_mempool.c |8 ++--
>  >   lib/librte_mempool/rte_mempool.h |7 +++
>  >   2 files changed, 9 insertions(+), 6 deletions(-)
>  >
>  > [...]
>  >
>  > --- a/lib/librte_mempool/rte_mempool.h
>  > +++ b/lib/librte_mempool/rte_mempool.h
>  > @@ -263,6 +263,13 @@ struct rte_mempool {
>  >   #define MEMPOOL_F_NO_PHYS_CONTIG 0x0020 /**< Don't need physically 
> contiguous objs. */
>  >
>  >   /**
>  > + * Calculate the threshold before we flush excess elements.
>  > + */
>  > +#define RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER 1.5
>  > +#define RTE_MEMPOOL_CALC_CACHE_FLUSHTHRESH(c) \
>  > +  ((typeof(c))((c) * RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER))
>  > +
>  > +/**
>  >* @internal When debug is enabled, store some statistics.
>  >*
>  >* @param mp
>  >
>
>  What do you think of using a static inline function instead of a macro ?
>
>
>  Regards,
>  Olivier
> --
>
> Yes, an inline function is better than a macro. We still need to move the 
> #define MULTIPLIER from rte_mempool.c to rte_mempool.h.
>
> How is this for the prototype?
> static inline unsigned rte_mempool_calc_cache_flushthresh(unsigned cache_size)
>
> Where in the .h should we place the function, right below the MULTIPLIER 
> definition?

Yep, looks good, thanks.

Maybe "unsigned" -> "unsigned int", because checkpatch may complain...


Regards,
Olivier

[dpdk-dev] [PATCH v2] examples: fix unusual-interpreter

[Thomas Monjalon]

> > *update in v2*
> > - use #!/usr/bin/env python as usually recommended and suggested in the
> >   discussion
> > 
> > Due to regular lintian checks in Debian packaging it surfaced that these
> > two scripts had a space in their #! statement which renders it to be
> > human, but not shell readable.
> > 
> > Fixes: 8673a3e8 ("examples/ip_pipeline: add config diagram generator")
> > Fixes: fa667b46 ("examples/ip_pipeline: add core mappings script")
> > 
> > Signed-off-by: Christian Ehrhardt 
> 
> Acked-by: Cristian Dumitrescu 

Applied, thanks

[dpdk-dev] [PATCH 3/4] net/bonding: another fix to LACP mempool size

[Olivier MATZ]

Hi Robert,

On 08/23/2016 10:01 PM, Sanford, Robert wrote:
> Hi Olivier,
>
> On 8/23/16, 11:09 AM, "Olivier MATZ"  wrote:
>
>  Hi Robert,
>
>  On 08/01/2016 10:42 PM, Robert Sanford wrote:
>  > The following log message may appear after a slave is idle (or nearly
>  > idle) for a few minutes: "PMD: Failed to allocate LACP packet from
>  > pool".
>  >
>  > Problem: All mbufs from a slave's private pool (used exclusively for
>  > transmitting LACPDUs) have been allocated and are still sitting in
>  > the device's tx descriptor ring and other cores' mempool caches.
>  >
>  > Solution: Ensure that each slaves' tx (LACPDU) mempool owns more than
>  > n-tx-queues * (n-tx-descriptors + per-core-mempool-flush-threshold)
>  > mbufs.
>  >
>  > Note that the LACP tx machine function is the only code that allocates
>  > from a slave's private pool. It runs in the context of the interrupt
>  > thread, and thus it has no mempool cache of its own.
>  >
>  > Signed-off-by: Robert Sanford 
>  > ---
>  >   drivers/net/bonding/rte_eth_bond_8023ad.c |   10 +++---
>  >   1 files changed, 7 insertions(+), 3 deletions(-)
>  >
>  > diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c 
> b/drivers/net/bonding/rte_eth_bond_8023ad.c
>  > index 2f7ae70..1207896 100644
>  > --- a/drivers/net/bonding/rte_eth_bond_8023ad.c
>  > +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
>  > @@ -854,6 +854,8 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev 
> *bond_dev, uint8_t slave_id)
>  >char mem_name[RTE_ETH_NAME_MAX_LEN];
>  >int socket_id;
>  >unsigned element_size;
>  > +  unsigned cache_size;
>  > +  unsigned cache_flushthresh;
>  >uint32_t total_tx_desc;
>  >struct bond_tx_queue *bd_tx_q;
>  >uint16_t q_id;
>  > @@ -890,19 +892,21 @@ bond_mode_8023ad_activate_slave(struct 
> rte_eth_dev *bond_dev, uint8_t slave_id)
>  >
>  >element_size = sizeof(struct slow_protocol_frame) + 
> sizeof(struct rte_mbuf)
>  >+ RTE_PKTMBUF_HEADROOM;
>  > +  cache_size = RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ?
>  > +  32 : RTE_MEMPOOL_CACHE_MAX_SIZE;
>  > +  cache_flushthresh = 
> RTE_MEMPOOL_CALC_CACHE_FLUSHTHRESH(cache_size);
>  >
>  >/* The size of the mempool should be at least:
>  > * the sum of the TX descriptors + 
> BOND_MODE_8023AX_SLAVE_TX_PKTS */
>  >total_tx_desc = BOND_MODE_8023AX_SLAVE_TX_PKTS;
>  >for (q_id = 0; q_id < bond_dev->data->nb_tx_queues; q_id++) {
>  >bd_tx_q = (struct 
> bond_tx_queue*)bond_dev->data->tx_queues[q_id];
>  > -  total_tx_desc += bd_tx_q->nb_tx_desc;
>  > +  total_tx_desc += bd_tx_q->nb_tx_desc + 
> cache_flushthresh;
>  >}
>  >
>  >snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", 
> slave_id);
>  >port->mbuf_pool = rte_mempool_create(mem_name,
>  > -  total_tx_desc, element_size,
>  > -  RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? 32 : 
> RTE_MEMPOOL_CACHE_MAX_SIZE,
>  > +  total_tx_desc, element_size, cache_size,
>  >sizeof(struct rte_pktmbuf_pool_private), 
> rte_pktmbuf_pool_init,
>  >NULL, rte_pktmbuf_init, NULL, socket_id, 
> MEMPOOL_F_NO_SPREAD);
>  >
>  >
>
>  I'm not very familiar with bonding code, so maybe your patch is correct.
>  I think the size of the mempool should be:
>
> BOND_MODE_8023AX_SLAVE_TX_PKTS +
>   n_cores * RTE_MEMPOOL_CALC_CACHE_FLUSHTHRESH(cache_size)
>
>  With n_cores = number of cores that can dequeue from the mempool.
>
>  The safest thing to do would be to have n_cores = RTE_MAX_LCORE. I don't
>  know if bond_dev->data->nb_tx_queue corresponds to this definition, if
>  yes you can ignore my comment ;)
>
>
>  Regards,
>  Olivier
>
> --
>
> Only one, non-EAL thread dequeues from a per-slave, private (LACPDU) mempool. 
> The thread calls mbuf-alloc in the context of an rte_eal_alarm_set( ) 
> callback function, and enqueues the mbuf to a multi-consumer ring.
>
> The consumer(s) of the mbufs can be any core(s) that invoke the bond PMD?s 
> tx-burst function. As we know, mbufs can sit around on TX descriptor rings 
> long after we transmit them, often until we need to reuse the descriptors for 
> subsequent TX packets. When the TX cores finally free some of the mbufs, some 
> of the mbufs get left in a pool?s per-core cache. So, the maximum number of 
> mbufs that may be lying around doing nothing is: the ?done? mbufs in the TX 
> desc ring and in the per-core cache, times the number of TX cores, or 
> approximately nb_tx_queues * (nb_tx_desc + CACHE_FLUSHTHRESH(cache_size)). (I 
> probably should also update the 

[dpdk-dev] [PATCH] ethdev: fix a typo in eth device API doc

[Thomas Monjalon]

2016-08-01 11:19, Nikhil Rao:
> This patch fixes a typo in the eth device API doc, device
> config. not stored between calls to rte_eth_dev_start/stop()
> should be restored before a call to rte_eth_dev_start()
> instead of after a call to rte_eth_dev_start().
> 
> Signed-off-by: Nikhil Rao 
[...]
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -118,7 +118,7 @@
>   * - NIC queue statistics mappings
>   *
>   * Any other configuration will not be stored and will need to be re-entered
> - * after a call to rte_eth_dev_start().
> + * before a call to rte_eth_dev_start().

I have some doubts about this and above comment.
I think we should give move details in the comments of the functions,
instead of this (not often read) global comment.

[dpdk-dev] [PATCH] doc: Fix incorrect comment line

[Thomas Monjalon]

2016-08-17 18:36, Shreyansh Jain:
> Signed-off-by: Shreyansh Jain 

Applied, thanks

[dpdk-dev] [PATCH] doc/versioning: add missing return value type in MAP_STATIC_SYMBOL example

[Thomas Monjalon]

2016-08-14 18:21, Mauricio Vasquez B:
> The example only had as return type struct, it is actually struct rte_acl_ctx 
> *
> 
> Signed-off-by: Mauricio Vasquez B 

Applied (minus a whitespace), thanks

[dpdk-dev] [RFC PATCH v1] rte: add bit-rate metrics to xstats

[Remy Horton]

This patch adds peak and average data-rate metrics to the extended
statistics. The intervals used to generate the statistics are
controlled by any application wishing to make use of these metrics.

Signed-off-by: Remy Horton 
---
 doc/guides/rel_notes/release_16_11.rst |   5 ++
 lib/librte_ether/rte_ethdev.c  | 107 -
 lib/librte_ether/rte_ethdev.h  |  41 +
 lib/librte_ether/rte_ether_version.map |   6 ++
 4 files changed, 157 insertions(+), 2 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
index 0b9022d..b319292 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -36,6 +36,11 @@ New Features

  This section is a comment. Make sure to start the actual text at the 
margin.

+   * **Added data-rate metrics to the extended statistics.**
+
+ Adds peak and average incoming and outgoing data-rate metrics to the
+ extended statistics, the calculation of which is controlled by
+ applications that wish for these to be derived.

 Resolved Issues
 ---
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index f62a9ec..71549b4 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -101,6 +101,7 @@ static const struct rte_eth_xstats_name_off 
rte_stats_strings[] = {
 };

 #define RTE_NB_STATS (sizeof(rte_stats_strings) / sizeof(rte_stats_strings[0]))
+#define RTE_NB_DEV_STATS 4

 static const struct rte_eth_xstats_name_off rte_rxq_stats_strings[] = {
{"packets", offsetof(struct rte_eth_stats, q_ipackets)},
@@ -1499,6 +1500,7 @@ void
 rte_eth_stats_reset(uint8_t port_id)
 {
struct rte_eth_dev *dev;
+   struct rte_eth_dev_stats *dev_stats;

RTE_ETH_VALID_PORTID_OR_RET(port_id);
dev = _eth_devices[port_id];
@@ -1506,6 +1508,19 @@ rte_eth_stats_reset(uint8_t port_id)
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->stats_reset);
(*dev->dev_ops->stats_reset)(dev);
dev->data->rx_mbuf_alloc_failed = 0;
+
+   /* Clear device running stat counts */
+   dev_stats = >data->stats;
+   memset(dev_stats->list_ibuckets, 0,
+   sizeof(uint64_t) * dev_stats->cnt_buckets);
+   memset(dev_stats->list_obuckets, 0,
+   sizeof(uint64_t) * dev_stats->cnt_buckets);
+   dev_stats->last_ibytes = 0;
+   dev_stats->last_obytes = 0;
+   dev_stats->peak_ibytes = 0;
+   dev_stats->peak_obytes = 0;
+   dev_stats->total_ibytes = 0;
+   dev_stats->total_obytes = 0;
 }

 static int
@@ -1522,7 +1537,7 @@ get_xstats_count(uint8_t port_id)
return count;
} else
count = 0;
-   count += RTE_NB_STATS;
+   count += RTE_NB_STATS + RTE_NB_DEV_STATS;
count += dev->data->nb_rx_queues * RTE_NB_RXQ_STATS;
count += dev->data->nb_tx_queues * RTE_NB_TXQ_STATS;
return count;
@@ -1574,6 +1589,19 @@ rte_eth_xstats_get_names(uint8_t port_id,
}
}

+   snprintf(xstats_names[cnt_used_entries++].name,
+   sizeof(xstats_names[0].name),
+   "tx_peak_bytes");
+   snprintf(xstats_names[cnt_used_entries++].name,
+   sizeof(xstats_names[0].name),
+   "tx_mean_bytes");
+   snprintf(xstats_names[cnt_used_entries++].name,
+   sizeof(xstats_names[0].name),
+   "rx_peak_bytes");
+   snprintf(xstats_names[cnt_used_entries++].name,
+   sizeof(xstats_names[0].name),
+   "rx_mean_bytes");
+
if (dev->dev_ops->xstats_get_names != NULL) {
/* If there are any driver-specific xstats, append them
 * to end of list.
@@ -1600,14 +1628,16 @@ rte_eth_xstats_get(uint8_t port_id, struct 
rte_eth_xstat *xstats,
unsigned count = 0, i, q;
signed xcount = 0;
uint64_t val, *stats_ptr;
+   struct rte_eth_dev_stats *dev_stats;

RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);

dev = _eth_devices[port_id];
+   dev_stats = >data->stats;

/* Return generic statistics */
count = RTE_NB_STATS + (dev->data->nb_rx_queues * RTE_NB_RXQ_STATS) +
-   (dev->data->nb_tx_queues * RTE_NB_TXQ_STATS);
+   (dev->data->nb_tx_queues * RTE_NB_TXQ_STATS) + RTE_NB_DEV_STATS;

/* implemented by the driver */
if (dev->dev_ops->xstats_get != NULL) {
@@ -1659,12 +1689,85 @@ rte_eth_xstats_get(uint8_t port_id, struct 
rte_eth_xstat *xstats,
}
}

+   xstats[count++].value = dev_stats->peak_obytes;
+   xstats[count++].value =
+   dev_stats->total_obytes / dev_stats->cnt_buckets;
+   xstats[count++].value = dev_stats->peak_ibytes;
+   xstats[count++].value =
+   dev_stats->total_ibytes / dev_stats->cnt_buckets;
+
for (i = 0; i < count + xcount; i++)

[dpdk-dev] [PATCH 0/7] vhost: vhost-cuse removal and code path refactoring

[Yuanhan Liu]

On Wed, Aug 24, 2016 at 07:30:23AM +, Xu, Qian Q wrote:
> I think you need also update vhost sample guide and vhost library in the 
> programmer guide for this release. 

Yes, updating vhost lib programmer would be easy, while updating the
vhost sample requires a rewrite, that I will defer it later to some
where that I have time for it.

--yliu

[dpdk-dev] [PATCH 1/6] vhost: simplify memory regions handling

[Yuanhan Liu]

Yes, it depends on the vhost-cuse removal patchset I sent last week.

--yliu

On Wed, Aug 24, 2016 at 07:26:07AM +, Xu, Qian Q wrote:
> I want to apply the patch on the latest DPDK, see below commit ID but failed 
> since no vhost.h and vhost-user.h files. So do you have any dependency on 
> other patches? 
> 
> commit 28d8abaf250c3fb4dcb6416518f4c54b4ae67205
> Author: Deirdre O'Connor 
> Date:   Mon Aug 22 17:20:08 2016 +0100
> 
> doc: fix patchwork link
> 
> Fixes: 58abf6e77c6b ("doc: add contributors guide")
> 
> Reported-by: Jon Loeliger 
> Signed-off-by: Deirdre O'Connor 
> Acked-by: John McNamara 
> 
> 
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yuanhan Liu
> Sent: Tuesday, August 23, 2016 4:11 PM
> To: dev at dpdk.org
> Cc: Maxime Coquelin ; Yuanhan Liu  at linux.intel.com>
> Subject: [dpdk-dev] [PATCH 1/6] vhost: simplify memory regions handling
> 
> Due to history reason (that vhost-cuse comes before vhost-user), some fields 
> for maintaining the vhost-user memory mappings (such as mmapped address and 
> size, with those we then can unmap on destroy) are kept in "orig_region_map" 
> struct, a structure that is defined only in vhost-user source file.
> 
> The right way to go is to remove the structure and move all those fields into 
> virtio_memory_region struct. But we simply can't do that before, because it 
> breaks the ABI.
> 
> Now, thanks to the ABI refactoring, it's never been a blocking issue any 
> more. And here it goes: this patch removes orig_region_map and redefines 
> virtio_memory_region, to include all necessary info.
> 
> With that, we can simplify the guest/host address convert a bit.
> 
> Signed-off-by: Yuanhan Liu 
> ---
>  lib/librte_vhost/vhost.h  |  49 ++--
>  lib/librte_vhost/vhost_user.c | 172 
> +-
>  2 files changed, 90 insertions(+), 131 deletions(-)
> 
> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h index 
> c2dfc3c..df2107b 100644
> --- a/lib/librte_vhost/vhost.h
> +++ b/lib/librte_vhost/vhost.h
> @@ -143,12 +143,14 @@ struct virtio_net {
>   * Information relating to memory regions including offsets to
>   * addresses in QEMUs memory file.
>   */
> -struct virtio_memory_regions {
> - uint64_t guest_phys_address;
> - uint64_t guest_phys_address_end;
> - uint64_t memory_size;
> - uint64_t userspace_address;
> - uint64_t address_offset;
> +struct virtio_memory_region {
> + uint64_t guest_phys_addr;
> + uint64_t guest_user_addr;
> + uint64_t host_user_addr;
> + uint64_t size;
> + void *mmap_addr;
> + uint64_t mmap_size;
> + int fd;
>  };
>  
>  
> @@ -156,12 +158,8 @@ struct virtio_memory_regions {
>   * Memory structure includes region and mapping information.
>   */
>  struct virtio_memory {
> - /* Base QEMU userspace address of the memory file. */
> - uint64_t base_address;
> - uint64_t mapped_address;
> - uint64_t mapped_size;
>   uint32_t nregions;
> - struct virtio_memory_regions regions[0];
> + struct virtio_memory_region regions[0];
>  };
>  
>  
> @@ -200,26 +198,23 @@ extern uint64_t VHOST_FEATURES;
>  #define MAX_VHOST_DEVICE 1024
>  extern struct virtio_net *vhost_devices[MAX_VHOST_DEVICE];
>  
> -/**
> - * Function to convert guest physical addresses to vhost virtual addresses.
> - * This is used to convert guest virtio buffer addresses.
> - */
> +/* Convert guest physical Address to host virtual address */
>  static inline uint64_t __attribute__((always_inline)) -gpa_to_vva(struct 
> virtio_net *dev, uint64_t guest_pa)
> +gpa_to_vva(struct virtio_net *dev, uint64_t gpa)
>  {
> - struct virtio_memory_regions *region;
> - uint32_t regionidx;
> - uint64_t vhost_va = 0;
> -
> - for (regionidx = 0; regionidx < dev->mem->nregions; regionidx++) {
> - region = >mem->regions[regionidx];
> - if ((guest_pa >= region->guest_phys_address) &&
> - (guest_pa <= region->guest_phys_address_end)) {
> - vhost_va = region->address_offset + guest_pa;
> - break;
> + struct virtio_memory_region *reg;
> + uint32_t i;
> +
> + for (i = 0; i < dev->mem->nregions; i++) {
> + reg = >mem->regions[i];
> + if (gpa >= reg->guest_phys_addr &&
> + gpa <  reg->guest_phys_addr + reg->size) {
> + return gpa - reg->guest_phys_addr +
> +reg->host_user_addr;
>   }
>   }
> - return vhost_va;
> +
> + return 0;
>  }
>  
>  struct virtio_net_device_ops const *notify_ops; diff --git 
> a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c index 
> eee99e9..d2071fd 100644
> --- a/lib/librte_vhost/vhost_user.c
> +++ b/lib/librte_vhost/vhost_user.c
> @@ -74,18 +74,6 @@ static const char *vhost_message_str[VHOST_USER_MAX] = {
>   

[dpdk-dev] [PATCH] vhost: add pmd xstats

[Panu Matilainen]

On 08/24/2016 11:44 AM, Thomas Monjalon wrote:
> 2016-08-24 13:46, Yuanhan Liu:
>> On Tue, Aug 23, 2016 at 12:45:54PM +0300, Panu Matilainen wrote:
>> Since collecting data of vhost_update_packet_xstats will have some
>> effect on RX/TX performance, so, Setting compiling switch
>> CONFIG_RTE_LIBRTE_PMD_VHOST_UPDATE_XSTATS=n by default in the
> file
>> config/common_base, if needing xstats data, you can enable it(y).
>
> NAK, such things need to be switchable at run-time.
>
>   - Panu -

 Considering the following reasons using the compiler switch, not
 command-line at run-time.

 1.Similar xstats update functions are always collecting stats data in the
 background when rx/tx are running, such as the physical NIC or virtio,
 which have no switch. Compiler switch for vhost pmd xstats is added
 as a option when performance is viewed as critical factor.

 2. No data structure and API in any layer support the xstats update switch
 at run-time. Common data structure (struct rte_eth_dev_data) has no
 device-specific data member, if implementing enable/disable of vhost_update
 _packet_xstats at run-time, must define a flag(device-specific) in it,
 because the definition of struct vhost_queue in the driver code
 (eth_vhost_rx/eth_vhost_tx processing)is not visible from device 
 perspective.

 3. I tested RX/TX with v1 patch (y) as reference based on Intel(R)
 Xeon(R) CPU E5-2699 v3 @ 2.30GHz, for 64byts packets in burst mode, 32 
 packets
 in one RX/TX processing. Overhead of vhost_update_packet_xstats is less 
 than
 3% for the rx/tx processing. It looks that vhost_update_packet_xstats has a
 limited effect on performance drop.
>>>
>>> Well, either the performance overhead is acceptable and it should always be
>>> on (like with physical NICs I think). Or it is not. In which case it needs
>>> to be turnable on and off, at run-time. Rebuilding is not an option in the
>>> world of distros.
>>
>> I think the less than 3% overhead is acceptable here, that I agree with
>> Panu we should always keep it on. If someone compains it later that even
>> 3% is too big for them, let's consider to make it be switchable at
>> run-time. Either we could introduce a generic eth API for that, Or
>> just introduce a vhost one if that doesn't make too much sense to other
>> eth drivers.
>
> +1
> It may have sense to introduce a generic run-time option for stats.
>

Yup, sounds good.

- Panu -

[dpdk-dev] [PATCH 5/5] maintainers: claim i40e vector PMD on ARM

[Jianbo Liu]

Signed-off-by: Jianbo Liu 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6536c6b..5d6ecba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -150,6 +150,7 @@ F: lib/librte_acl/acl_run_neon.*
 F: lib/librte_lpm/rte_lpm_neon.h
 F: lib/librte_hash/rte*_arm64.h
 F: drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
+F: drivers/net/i40e/i40e_rxtx_vec_neon.c

 EZchip TILE-Gx
 M: Zhigang Lu 
-- 
2.4.11

[dpdk-dev] [PATCH 4/5] i40e: make vector driver filenames consistent

[Jianbo Liu]

To be consistent with the naming for ARM NEON implementation,
i40e_rxtx_vec.c is renamed to i40e_rxtx_vec_sse.c.

Signed-off-by: Jianbo Liu 
---
 drivers/net/i40e/Makefile | 4 ++--
 drivers/net/i40e/{i40e_rxtx_vec.c => i40e_rxtx_vec_sse.c} | 0
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename drivers/net/i40e/{i40e_rxtx_vec.c => i40e_rxtx_vec_sse.c} (100%)

diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile
index 9e92b38..13085fb 100644
--- a/drivers/net/i40e/Makefile
+++ b/drivers/net/i40e/Makefile
@@ -100,7 +100,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_rxtx.c
 ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
 SRCS-$(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR) += i40e_rxtx_vec_neon.c
 else
-SRCS-$(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR) += i40e_rxtx_vec.c
+SRCS-$(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR) += i40e_rxtx_vec_sse.c
 endif
 SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_ethdev_vf.c
 SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_pf.c
@@ -108,7 +108,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_fdir.c

 # vector PMD driver needs SSE4.1 support
 ifeq ($(findstring RTE_MACHINE_CPUFLAG_SSE4_1,$(CFLAGS)),)
-CFLAGS_i40e_rxtx_vec.o += -msse4.1
+CFLAGS_i40e_rxtx_vec_sse.o += -msse4.1
 endif


diff --git a/drivers/net/i40e/i40e_rxtx_vec.c 
b/drivers/net/i40e/i40e_rxtx_vec_sse.c
similarity index 100%
rename from drivers/net/i40e/i40e_rxtx_vec.c
rename to drivers/net/i40e/i40e_rxtx_vec_sse.c
-- 
2.4.11

[dpdk-dev] [PATCH 3/5] i40e: enable i40e vector PMD on ARMv8a platform

[Jianbo Liu]

Signed-off-by: Jianbo Liu 
---
 config/defconfig_arm64-armv8a-linuxapp-gcc | 1 -
 doc/guides/nics/features/i40e_vec.ini  | 1 +
 doc/guides/nics/features/i40e_vf_vec.ini   | 1 +
 3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 1a17126..d10e1fd 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -46,6 +46,5 @@ CONFIG_RTE_EAL_IGB_UIO=n

 CONFIG_RTE_LIBRTE_IVSHMEM=n
 CONFIG_RTE_LIBRTE_FM10K_PMD=n
-CONFIG_RTE_LIBRTE_I40E_PMD=n

 CONFIG_RTE_SCHED_VECTOR=n
diff --git a/doc/guides/nics/features/i40e_vec.ini 
b/doc/guides/nics/features/i40e_vec.ini
index 0953d84..edd6b71 100644
--- a/doc/guides/nics/features/i40e_vec.ini
+++ b/doc/guides/nics/features/i40e_vec.ini
@@ -37,3 +37,4 @@ Linux UIO= Y
 Linux VFIO   = Y
 x86-32   = Y
 x86-64   = Y
+ARMv8= Y
diff --git a/doc/guides/nics/features/i40e_vf_vec.ini 
b/doc/guides/nics/features/i40e_vf_vec.ini
index 2a44bf6..d6674f7 100644
--- a/doc/guides/nics/features/i40e_vf_vec.ini
+++ b/doc/guides/nics/features/i40e_vf_vec.ini
@@ -26,3 +26,4 @@ Linux UIO= Y
 Linux VFIO   = Y
 x86-32   = Y
 x86-64   = Y
+ARMv8= Y
-- 
2.4.11

[dpdk-dev] [PATCH 2/5] i40e: implement vector PMD for ARM architecture

[Jianbo Liu]

Use ARM NEON intrinsic to implement i40e vPMD

Signed-off-by: Jianbo Liu 
---
 drivers/net/i40e/Makefile |   4 +
 drivers/net/i40e/i40e_rxtx_vec_neon.c | 581 ++
 2 files changed, 585 insertions(+)
 create mode 100644 drivers/net/i40e/i40e_rxtx_vec_neon.c

diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile
index 53fe145..9e92b38 100644
--- a/drivers/net/i40e/Makefile
+++ b/drivers/net/i40e/Makefile
@@ -97,7 +97,11 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_dcb.c

 SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_ethdev.c
 SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_rxtx.c
+ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
+SRCS-$(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR) += i40e_rxtx_vec_neon.c
+else
 SRCS-$(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR) += i40e_rxtx_vec.c
+endif
 SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_ethdev_vf.c
 SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_pf.c
 SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_fdir.c
diff --git a/drivers/net/i40e/i40e_rxtx_vec_neon.c 
b/drivers/net/i40e/i40e_rxtx_vec_neon.c
new file mode 100644
index 000..015fa9f
--- /dev/null
+++ b/drivers/net/i40e/i40e_rxtx_vec_neon.c
@@ -0,0 +1,581 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2016, Linaro Limited
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+
+#include "base/i40e_prototype.h"
+#include "base/i40e_type.h"
+#include "i40e_ethdev.h"
+#include "i40e_rxtx.h"
+#include "i40e_rxtx_vec_common.h"
+
+#include 
+
+#pragma GCC diagnostic ignored "-Wcast-qual"
+
+static inline void
+i40e_rxq_rearm(struct i40e_rx_queue *rxq)
+{
+   int i;
+   uint16_t rx_id;
+   volatile union i40e_rx_desc *rxdp;
+   struct i40e_rx_entry *rxep = >sw_ring[rxq->rxrearm_start];
+   struct rte_mbuf *mb0, *mb1;
+   uint64x2_t dma_addr0, dma_addr1;
+   uint64x2_t zero = vdupq_n_u64(0);
+   uint64_t paddr;
+   uint8x8_t p;
+
+   rxdp = rxq->rx_ring + rxq->rxrearm_start;
+
+   /* Pull 'n' more MBUFs into the software ring */
+   if (unlikely(rte_mempool_get_bulk(rxq->mp,
+ (void *)rxep,
+ RTE_I40E_RXQ_REARM_THRESH) < 0)) {
+   if (rxq->rxrearm_nb + RTE_I40E_RXQ_REARM_THRESH >=
+   rxq->nb_rx_desc) {
+   for (i = 0; i < RTE_I40E_DESCS_PER_LOOP; i++) {
+   rxep[i].mbuf = >fake_mbuf;
+   vst1q_u64((uint64_t *)[i].read, zero);
+   }
+   }
+   rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed +=
+   RTE_I40E_RXQ_REARM_THRESH;
+   return;
+   }
+
+   p = vld1_u8((uint8_t *)>mbuf_initializer);
+
+   /* Initialize the mbufs in vector, process 2 mbufs in one loop */
+   for (i = 0; i < RTE_I40E_RXQ_REARM_THRESH; i += 2, rxep += 2) {
+   mb0 = rxep[0].mbuf;
+   mb1 = rxep[1].mbuf;
+
+/* Flush mbuf with pkt template.
+* Data to be rearmed is 6 bytes long.
+* Though, RX will overwrite ol_flags that are coming next
+* anyway. So overwrite whole 8 bytes with one load:
+* 6 bytes of rearm_data plus first 2 bytes of ol_flags.
+*/
+  

[dpdk-dev] [PATCH 1/5] i40e: extract non-x86 specific code from vector driver

[Jianbo Liu]

move scalar code which does not use x86 intrinsic functions to new file
"i40e_rxtx_vec_common.h", while keeping x86 code in i40e_rxtx_vec.c.
This allows the scalar code to to be shared among vector drivers for
different platforms.

Signed-off-by: Jianbo Liu 
---
 drivers/net/i40e/i40e_rxtx_vec.c| 184 +---
 drivers/net/i40e/i40e_rxtx_vec_common.h | 239 
 2 files changed, 243 insertions(+), 180 deletions(-)
 create mode 100644 drivers/net/i40e/i40e_rxtx_vec_common.h

diff --git a/drivers/net/i40e/i40e_rxtx_vec.c b/drivers/net/i40e/i40e_rxtx_vec.c
index 51fb282..f847469 100644
--- a/drivers/net/i40e/i40e_rxtx_vec.c
+++ b/drivers/net/i40e/i40e_rxtx_vec.c
@@ -39,6 +39,7 @@
 #include "base/i40e_type.h"
 #include "i40e_ethdev.h"
 #include "i40e_rxtx.h"
+#include "i40e_rxtx_vec_common.h"

 #include 

@@ -421,68 +422,6 @@ i40e_recv_pkts_vec(void *rx_queue, struct rte_mbuf 
**rx_pkts,
return _recv_raw_pkts_vec(rx_queue, rx_pkts, nb_pkts, NULL);
 }

-static inline uint16_t
-reassemble_packets(struct i40e_rx_queue *rxq, struct rte_mbuf **rx_bufs,
-  uint16_t nb_bufs, uint8_t *split_flags)
-{
-   struct rte_mbuf *pkts[RTE_I40E_VPMD_RX_BURST]; /*finished pkts*/
-   struct rte_mbuf *start = rxq->pkt_first_seg;
-   struct rte_mbuf *end =  rxq->pkt_last_seg;
-   unsigned pkt_idx, buf_idx;
-
-   for (buf_idx = 0, pkt_idx = 0; buf_idx < nb_bufs; buf_idx++) {
-   if (end != NULL) {
-   /* processing a split packet */
-   end->next = rx_bufs[buf_idx];
-   rx_bufs[buf_idx]->data_len += rxq->crc_len;
-
-   start->nb_segs++;
-   start->pkt_len += rx_bufs[buf_idx]->data_len;
-   end = end->next;
-
-   if (!split_flags[buf_idx]) {
-   /* it's the last packet of the set */
-   start->hash = end->hash;
-   start->ol_flags = end->ol_flags;
-   /* we need to strip crc for the whole packet */
-   start->pkt_len -= rxq->crc_len;
-   if (end->data_len > rxq->crc_len) {
-   end->data_len -= rxq->crc_len;
-   } else {
-   /* free up last mbuf */
-   struct rte_mbuf *secondlast = start;
-
-   while (secondlast->next != end)
-   secondlast = secondlast->next;
-   secondlast->data_len -= (rxq->crc_len -
-   end->data_len);
-   secondlast->next = NULL;
-   rte_pktmbuf_free_seg(end);
-   end = secondlast;
-   }
-   pkts[pkt_idx++] = start;
-   start = end = NULL;
-   }
-   } else {
-   /* not processing a split packet */
-   if (!split_flags[buf_idx]) {
-   /* not a split packet, save and skip */
-   pkts[pkt_idx++] = rx_bufs[buf_idx];
-   continue;
-   }
-   end = start = rx_bufs[buf_idx];
-   rx_bufs[buf_idx]->data_len += rxq->crc_len;
-   rx_bufs[buf_idx]->pkt_len += rxq->crc_len;
-   }
-   }
-
-   /* save the partial packet for next time */
-   rxq->pkt_first_seg = start;
-   rxq->pkt_last_seg = end;
-   memcpy(rx_bufs, pkts, pkt_idx * (sizeof(*pkts)));
-   return pkt_idx;
-}
-
  /* vPMD receive routine that reassembles scattered packets
  * Notice:
  * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet
@@ -548,73 +487,6 @@ vtx(volatile struct i40e_tx_desc *txdp,
vtx1(txdp, *pkt, flags);
 }

-static inline int __attribute__((always_inline))
-i40e_tx_free_bufs(struct i40e_tx_queue *txq)
-{
-   struct i40e_tx_entry *txep;
-   uint32_t n;
-   uint32_t i;
-   int nb_free = 0;
-   struct rte_mbuf *m, *free[RTE_I40E_TX_MAX_FREE_BUF_SZ];
-
-   /* check DD bits on threshold descriptor */
-   if ((txq->tx_ring[txq->tx_next_dd].cmd_type_offset_bsz &
-   rte_cpu_to_le_64(I40E_TXD_QW1_DTYPE_MASK)) !=
-   rte_cpu_to_le_64(I40E_TX_DESC_DTYPE_DESC_DONE))
-   return 0;
-
-   n = txq->tx_rs_thresh;
-
-/* first buffer to free from S/W ring is at index
- * tx_next_dd - (tx_rs_thresh-1)
- */
-   txep = >sw_ring[txq->tx_next_dd - (n - 1)];
-   m = 

[dpdk-dev] [PATCH 0/5] i40e: vector poll-mode driver on ARM64

[Jianbo Liu]

This patch set is to implement i40e vector PMD on ARM64.
For x86, vPMD is only reorganized, there should be no performance loss.

Jianbo Liu (5):
  i40e: extract non-x86 specific code from vector driver
  i40e: implement vector PMD for ARM architecture
  i40e: enable i40e vector PMD on ARMv8a platform
  i40e: make vector driver filenames consistent
  maintainers: claim i40e vector PMD on ARM

 MAINTAINERS|   1 +
 config/defconfig_arm64-armv8a-linuxapp-gcc |   1 -
 doc/guides/nics/features/i40e_vec.ini  |   1 +
 doc/guides/nics/features/i40e_vf_vec.ini   |   1 +
 drivers/net/i40e/Makefile  |   8 +-
 drivers/net/i40e/i40e_rxtx_vec_common.h| 239 +
 drivers/net/i40e/i40e_rxtx_vec_neon.c  | 581 +
 .../i40e/{i40e_rxtx_vec.c => i40e_rxtx_vec_sse.c}  | 184 +--
 8 files changed, 833 insertions(+), 183 deletions(-)
 create mode 100644 drivers/net/i40e/i40e_rxtx_vec_common.h
 create mode 100644 drivers/net/i40e/i40e_rxtx_vec_neon.c
 rename drivers/net/i40e/{i40e_rxtx_vec.c => i40e_rxtx_vec_sse.c} (78%)

-- 
2.4.11

[dpdk-dev] [PATCH] app/testpmd: fix DCB config issue on ixgbe

[Iremonger, Bernard]

Hi Wenzhuo,



> > Subject: [dpdk-dev] [PATCH] app/testpmd: fix DCB config issue on ixgbe
> >
> > An issue is found that DCB cannot be configured on ixgbe NICs. It's
> > said the TX queue number is not right.
> > On ixgbe the max TX queue number is not fixed, it depends on the
> > multi- queue mode.
> >
> > This patch adds the device configuration before getting info in the
> > DCB configuration process. So the right info can be got depending on
> > the configuration.
> >
> > Fixes: 96c0450dff86 (ixgbe: fix dropping packets from unsupported Tx
> > queues)

As the fix in this patch is to testpmd, I don't think the fixes line is correct.

> > Signed-off-by: Wenzhuo Lu 
> > ---
> >  app/test-pmd/testpmd.c | 39 +--
> >  1 file changed, 21 insertions(+), 18 deletions(-)
> >
> > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> > 1428974..ba41bea 100644
> > --- a/app/test-pmd/testpmd.c
> > +++ b/app/test-pmd/testpmd.c
> > @@ -1962,17 +1962,30 @@ init_port_dcb_config(portid_t pid,
> >  uint8_t pfc_en)
> >  {
> > struct rte_eth_conf port_conf;
> > -   struct rte_eth_dev_info dev_info;
> > struct rte_port *rte_port;
> > int retval;
> > uint16_t i;
> >
> > -   rte_eth_dev_info_get(pid, _info);
> > +   rte_port = [pid];
> > +
> > +   memset(_conf, 0, sizeof(struct rte_eth_conf));
> > +   /* Enter DCB configuration status */
> > +   dcb_config = 1;
> > +
> > +   /*set configuration of DCB in vt mode and DCB in non-vt mode*/
> > +   retval = get_eth_dcb_conf(_conf, dcb_mode, num_tcs,
> > pfc_en);
> > +   if (retval < 0)
> > +   return retval;
> > +   port_conf.rxmode.hw_vlan_filter = 1;
> > +
> > +   (void)rte_eth_dev_configure(pid, 0, 0, _conf);
> 
> The return value of rte_eth_dev_configure() should be checked.
> Calling rte_eth_dev_configure() with  parameters nb_rx_q and nb_tx_q
> equal to 0 returns -EINVAL, and does nothing.
> Should the values of nb_rx_q and nb_tx_q be non zero?

The call to rte_eth_dev_configure() may not be necessary, as it is also called 
when the port is started.

> > +   rte_eth_dev_info_get(pid, _port->dev_info);
> >
> > /* If dev_info.vmdq_pool_base is greater than 0,
> >  * the queue id of vmdq pools is started after pf queues.
> >  */
> > -   if (dcb_mode == DCB_VT_ENABLED && dev_info.vmdq_pool_base >
> > 0) {
> > +   if (dcb_mode == DCB_VT_ENABLED &&
> > +   rte_port->dev_info.vmdq_pool_base > 0) {
> > printf("VMDQ_DCB multi-queue mode is nonsensical"
> > " for port %d.", pid);
> > return -1;
> > @@ -1982,13 +1995,13 @@ init_port_dcb_config(portid_t pid,
> >  * and has the same number of rxq and txq in dcb mode
> >  */
> > if (dcb_mode == DCB_VT_ENABLED) {
> > -   nb_rxq = dev_info.max_rx_queues;
> > -   nb_txq = dev_info.max_tx_queues;
> > +   nb_rxq = rte_port->dev_info.max_rx_queues;
> > +   nb_txq = rte_port->dev_info.max_tx_queues;

If nb_rxq and nb_txq are set to max_rx_queues and max_tx_queues respectively, 
there is a failure when the port is started in ixgbe_check_mq_mode() at line 
1990 in ixgbe_ethdev.c.
SRIOV is active, nb_rx_q=128 nb_tx_q=128 queue number must be less than or 
equal to 1.

nb_rxq and nb_txq are equal to 1 at this point, if they are not changed, port 
start completes successfully.


> > } else {
> > /*if vt is disabled, use all pf queues */
> > -   if (dev_info.vmdq_pool_base == 0) {
> > -   nb_rxq = dev_info.max_rx_queues;
> > -   nb_txq = dev_info.max_tx_queues;
> > +   if (rte_port->dev_info.vmdq_pool_base == 0) {
> > +   nb_rxq = rte_port->dev_info.max_rx_queues;
> > +   nb_txq = rte_port->dev_info.max_tx_queues;
> > } else {
> > nb_rxq = (queueid_t)num_tcs;
> > nb_txq = (queueid_t)num_tcs;
> > @@ -1997,16 +2010,6 @@ init_port_dcb_config(portid_t pid,
> > }
> > rx_free_thresh = 64;
> >
> > -   memset(_conf, 0, sizeof(struct rte_eth_conf));
> > -   /* Enter DCB configuration status */
> > -   dcb_config = 1;
> > -
> > -   /*set configuration of DCB in vt mode and DCB in non-vt mode*/
> > -   retval = get_eth_dcb_conf(_conf, dcb_mode, num_tcs,
> > pfc_en);
> > -   if (retval < 0)
> > -   return retval;
> > -
> > -   rte_port = [pid];
> > memcpy(_port->dev_conf, _conf, sizeof(struct
> > rte_eth_conf));
> >
> > rxtx_port_config(rte_port);
> > --
> > 1.9.3
Regards,

Bernard

[dpdk-dev] [PATCH] vhost: add pmd xstats

[Yuanhan Liu]

On Tue, Aug 23, 2016 at 12:45:54PM +0300, Panu Matilainen wrote:
> >>>Since collecting data of vhost_update_packet_xstats will have some
> >>>effect on RX/TX performance, so, Setting compiling switch
> >>>CONFIG_RTE_LIBRTE_PMD_VHOST_UPDATE_XSTATS=n by default in the
> >>file
> >>>config/common_base, if needing xstats data, you can enable it(y).
> >>
> >>NAK, such things need to be switchable at run-time.
> >>
> >>- Panu -
> >
> >Considering the following reasons using the compiler switch, not
> >command-line at run-time.
> >
> >1.Similar xstats update functions are always collecting stats data in the
> >background when rx/tx are running, such as the physical NIC or virtio,
> >which have no switch. Compiler switch for vhost pmd xstats is added
> >as a option when performance is viewed as critical factor.
> >
> >2. No data structure and API in any layer support the xstats update switch
> >at run-time. Common data structure (struct rte_eth_dev_data) has no
> >device-specific data member, if implementing enable/disable of vhost_update
> >_packet_xstats at run-time, must define a flag(device-specific) in it,
> >because the definition of struct vhost_queue in the driver code
> >(eth_vhost_rx/eth_vhost_tx processing)is not visible from device perspective.
> >
> >3. I tested RX/TX with v1 patch (y) as reference based on Intel(R)
> >Xeon(R) CPU E5-2699 v3 @ 2.30GHz, for 64byts packets in burst mode, 32 
> >packets
> >in one RX/TX processing. Overhead of vhost_update_packet_xstats is less than
> >3% for the rx/tx processing. It looks that vhost_update_packet_xstats has a
> >limited effect on performance drop.
> 
> Well, either the performance overhead is acceptable and it should always be
> on (like with physical NICs I think). Or it is not. In which case it needs
> to be turnable on and off, at run-time. Rebuilding is not an option in the
> world of distros.

I think the less than 3% overhead is acceptable here, that I agree with
Panu we should always keep it on. If someone compains it later that even
3% is too big for them, let's consider to make it be switchable at
run-time. Either we could introduce a generic eth API for that, Or
just introduce a vhost one if that doesn't make too much sense to other
eth drivers.

--yliu

[dpdk-dev] [PATCH 0/5] i40e: vector poll-mode driver on ARM64

[Thomas Monjalon]

2016-08-24 15:23, Jianbo Liu:
> This patch set is to implement i40e vector PMD on ARM64.

Thanks for extending ARM support.

The current NIC support status is:
% git grep -l 'ARM.*=.*Y' doc/guides/nics/features/
doc/guides/nics/features/ixgbe.ini
doc/guides/nics/features/ixgbe_vec.ini
doc/guides/nics/features/ixgbe_vf.ini
doc/guides/nics/features/ixgbe_vf_vec.ini
doc/guides/nics/features/pcap.ini
doc/guides/nics/features/thunderx.ini
doc/guides/nics/features/virtio.ini
doc/guides/nics/features/virtio_vec.ini

To sum it up, only virtio, ixgbe (and specific thunderx device)
seems to be supported on ARM in DPDK 16.07.
Now you are bringing support of i40e on ARM.
Do you plan to support more devices in near future?
Who is interested to do and/or validate ARM support of other drivers?

[dpdk-dev] [PATCH v2 0/6] various vmxnet3 fixes and enhancement

[Stephen Hemminger]

On Tue, 23 Aug 2016 17:05:34 -0700
Yong Wang  wrote:

> v2:
> * updated vmxnet3 feature doc.
> * updated vmxnet3 guide to remove stale information.
> 
> v1: This patchset includes a few bug fixes and some enhancement.
> 
> * Fixed a bug with dev_configure memzone size;
> * Enhanced error checks during device start.
>   * the driver will now report error if the rx queue number is
> not a power of two, instead of waiting for the activation
> to fail.
>   * Instead of returning -1 (which is interpreted as -EPERM) on
> device activation failure, -EINVAL is returned now.
> * Enabled LRO if requested.
> 
> Yong Wang (6):
>   net/vmxnet3: improve error checks and return values
>   net/vmxnet3: coding style changes
>   net/vmxnet3: reallocate shared memzone on re-config
>   net/vmxnet3: update feature doc
>   net/vmxnet3: update nic doc
>   net/vmxnet3: enable lro
> 
>  doc/guides/nics/features/vmxnet3.ini |  22 ++
>  doc/guides/nics/vmxnet3.rst  |  12 +---
>  drivers/net/vmxnet3/vmxnet3_ethdev.c | 125 
> +--
>  drivers/net/vmxnet3/vmxnet3_ethdev.h |  32 +
>  drivers/net/vmxnet3/vmxnet3_ring.h   |  22 +++---
>  drivers/net/vmxnet3/vmxnet3_rxtx.c   |  59 +
>  6 files changed, 158 insertions(+), 114 deletions(-)
> 

These all look good to me.

Acked-by: Stephen Hemminger 

[dpdk-dev] [PATCH] net/enic: add Ethernet VLAN ptype

[John Daley]

Enic is capable of recognizing packets to be delivered to the
app with single VLAN tags. Advertise this with the ptype
RTE_PTYPE_L2_ETHER_VLAN and set the ptype for VLAN packets.

Signed-off-by: John Daley 
---

Requires patchset http://dpdk.org/ml/archives/dev/2016-July/04.html
I recommend the patchset becasue among the other things it brings, the
ability to flag VLAN packets in HW is very useful to applications.

Because of the new VLAN flag, RTE_PTYPE_L2_ETHER is factored out
of the lookup table and RTE_PTYPE_L2_ETHER vs. RTE_PTYPE_L2_ETHER_VLAN
is determined later.

 drivers/net/enic/enic_ethdev.c |  2 ++
 drivers/net/enic/enic_rxtx.c   | 49 ++
 2 files changed, 23 insertions(+), 28 deletions(-)

diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 47b07c9..13b4b34 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -464,6 +464,8 @@ static void enicpmd_dev_info_get(struct rte_eth_dev 
*eth_dev,
 static const uint32_t *enicpmd_dev_supported_ptypes_get(struct rte_eth_dev 
*dev)
 {
static const uint32_t ptypes[] = {
+   RTE_PTYPE_L2_ETHER,
+   RTE_PTYPE_L2_ETHER_VLAN,
RTE_PTYPE_L3_IPV4_EXT_UNKNOWN,
RTE_PTYPE_L3_IPV6_EXT_UNKNOWN,
RTE_PTYPE_L4_TCP,
diff --git a/drivers/net/enic/enic_rxtx.c b/drivers/net/enic/enic_rxtx.c
index 50f0b28..4f63a82 100644
--- a/drivers/net/enic/enic_rxtx.c
+++ b/drivers/net/enic/enic_rxtx.c
@@ -149,30 +149,18 @@ enic_cq_rx_flags_to_pkt_type(struct cq_desc *cqd)
uint8_t cqrd_flags = cqrd->flags;
static const uint32_t cq_type_table[128] __rte_cache_aligned = {
[0x00] = RTE_PTYPE_UNKNOWN,
-   [0x20] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN
- | RTE_PTYPE_L4_NONFRAG,
-   [0x22] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN
- | RTE_PTYPE_L4_UDP,
-   [0x24] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN
- | RTE_PTYPE_L4_TCP,
-   [0x60] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN
- | RTE_PTYPE_L4_FRAG,
-   [0x62] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN
- | RTE_PTYPE_L4_UDP,
-   [0x64] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN
- | RTE_PTYPE_L4_TCP,
-   [0x10] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN
- | RTE_PTYPE_L4_NONFRAG,
-   [0x12] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN
- | RTE_PTYPE_L4_UDP,
-   [0x14] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN
- | RTE_PTYPE_L4_TCP,
-   [0x50] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN
- | RTE_PTYPE_L4_FRAG,
-   [0x52] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN
- | RTE_PTYPE_L4_UDP,
-   [0x54] = RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV6_EXT_UNKNOWN
- | RTE_PTYPE_L4_TCP,
+   [0x20] = RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_NONFRAG,
+   [0x22] = RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_UDP,
+   [0x24] = RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP,
+   [0x60] = RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_FRAG,
+   [0x62] = RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_UDP,
+   [0x64] = RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP,
+   [0x10] = RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_NONFRAG,
+   [0x12] = RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_UDP,
+   [0x14] = RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_TCP,
+   [0x50] = RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_FRAG,
+   [0x52] = RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_UDP,
+   [0x54] = RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_TCP,
/* All others reserved */
};
cqrd_flags &= CQ_ENET_RQ_DESC_FLAGS_IPV4_FRAGMENT
@@ -185,9 +173,10 @@ static inline void
 enic_cq_rx_to_pkt_flags(struct cq_desc *cqd, struct rte_mbuf *mbuf)
 {
struct cq_enet_rq_desc *cqrd = (struct cq_enet_rq_desc *)cqd;
-   uint16_t ciflags, bwflags, pkt_flags = 0;
+   uint16_t ciflags, bwflags, pkt_flags = 0, vlan_tci;
ciflags = enic_cq_rx_desc_ciflags(cqrd);
bwflags = enic_cq_rx_desc_bwflags(cqrd);
+   vlan_tci = enic_cq_rx_desc_vlan(cqrd);

mbuf->ol_flags = 0;

@@ -195,13 +184,17 @@ enic_cq_rx_to_pkt_flags(struct cq_desc *cqd, struct 
rte_mbuf *mbuf)
if (unlikely(!enic_cq_rx_desc_eop(ciflags)))
goto mbuf_flags_done;

-   /* VLAN stripping */
+   /* VLAN STRIPPED flag. The L2 packet type updated here also 

[dpdk-dev] [PATCH] vhost: add pmd xstats

[Thomas Monjalon]

2016-08-24 13:46, Yuanhan Liu:
> On Tue, Aug 23, 2016 at 12:45:54PM +0300, Panu Matilainen wrote:
> > >>>Since collecting data of vhost_update_packet_xstats will have some
> > >>>effect on RX/TX performance, so, Setting compiling switch
> > >>>CONFIG_RTE_LIBRTE_PMD_VHOST_UPDATE_XSTATS=n by default in the
> > >>file
> > >>>config/common_base, if needing xstats data, you can enable it(y).
> > >>
> > >>NAK, such things need to be switchable at run-time.
> > >>
> > >>  - Panu -
> > >
> > >Considering the following reasons using the compiler switch, not
> > >command-line at run-time.
> > >
> > >1.Similar xstats update functions are always collecting stats data in the
> > >background when rx/tx are running, such as the physical NIC or virtio,
> > >which have no switch. Compiler switch for vhost pmd xstats is added
> > >as a option when performance is viewed as critical factor.
> > >
> > >2. No data structure and API in any layer support the xstats update switch
> > >at run-time. Common data structure (struct rte_eth_dev_data) has no
> > >device-specific data member, if implementing enable/disable of vhost_update
> > >_packet_xstats at run-time, must define a flag(device-specific) in it,
> > >because the definition of struct vhost_queue in the driver code
> > >(eth_vhost_rx/eth_vhost_tx processing)is not visible from device 
> > >perspective.
> > >
> > >3. I tested RX/TX with v1 patch (y) as reference based on Intel(R)
> > >Xeon(R) CPU E5-2699 v3 @ 2.30GHz, for 64byts packets in burst mode, 32 
> > >packets
> > >in one RX/TX processing. Overhead of vhost_update_packet_xstats is less 
> > >than
> > >3% for the rx/tx processing. It looks that vhost_update_packet_xstats has a
> > >limited effect on performance drop.
> > 
> > Well, either the performance overhead is acceptable and it should always be
> > on (like with physical NICs I think). Or it is not. In which case it needs
> > to be turnable on and off, at run-time. Rebuilding is not an option in the
> > world of distros.
> 
> I think the less than 3% overhead is acceptable here, that I agree with
> Panu we should always keep it on. If someone compains it later that even
> 3% is too big for them, let's consider to make it be switchable at
> run-time. Either we could introduce a generic eth API for that, Or
> just introduce a vhost one if that doesn't make too much sense to other
> eth drivers.

+1
It may have sense to introduce a generic run-time option for stats.

[dpdk-dev] [PATCH 7/7] vhost: simplify features set/get

[Maxime Coquelin]

On 08/18/2016 10:48 AM, Yuanhan Liu wrote:
> No need to use a pointer to store/retrieve features.
>
> Signed-off-by: Yuanhan Liu 
> ---
>  lib/librte_vhost/vhost_user.c | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> index ef4a0c1..eee99e9 100644
> --- a/lib/librte_vhost/vhost_user.c
> +++ b/lib/librte_vhost/vhost_user.c
> @@ -155,23 +155,22 @@ vhost_user_reset_owner(struct virtio_net *dev)
>  /*
>   * The features that we support are requested.
>   */
> -static int
> -vhost_user_get_features(uint64_t *pu)
> +static uint64_t
> +vhost_user_get_features(void)
>  {
> - *pu = VHOST_FEATURES;
> - return 0;
> + return VHOST_FEATURES;
>  }

This is not the topic of this series, but I wonder if it
could make sense to be able to override supported features
at device init time.

It may not match with the orignal purpose of supported features,
but could be useful at least for testing without recompilation.

For this patch:
Reviewed-by: Maxime Coquelin 

Thanks,
Maxime

[dpdk-dev] [PATCH 6/7] vhost: get device once

[Maxime Coquelin]

On 08/18/2016 10:48 AM, Yuanhan Liu wrote:
> Invoke get_device() at the beginning of vhost_user_msg_handler, so that
> we could check the return value once. Which could save tons of duplicate
> get-and-check device.
>
> Signed-off-by: Yuanhan Liu 
> ---
>  lib/librte_vhost/vhost_user.c | 160 
> +-
>  1 file changed, 47 insertions(+), 113 deletions(-)

Makes sense:
Reviewed-by: Maxime Coquelin 

Thanks,
Maxime

[dpdk-dev] [PATCH 5/7] vhost: unify function names

[Maxime Coquelin]

On 08/18/2016 10:48 AM, Yuanhan Liu wrote:
> Some functions are with prefix "user_", while others with "vhost_".
> Making them all starting with "vhost_user_" to unify the function names.
>
> Signed-off-by: Yuanhan Liu 
> ---
>  lib/librte_vhost/vhost_user.c | 60 
> +--
>  1 file changed, 30 insertions(+), 30 deletions(-)
>

Reviewed-by: Maxime Coquelin 

Thanks,
Maxime

[dpdk-dev] [PATCH 4/7] vhost: fold common message handlers

[Maxime Coquelin]

On 08/18/2016 10:48 AM, Yuanhan Liu wrote:
> Due to history reason (that we have 2 vhost implementations), some
> messages are handled in two calls: vhost specific implementation
> handles it first and then invoke the common one to do another handling.
>
> We have one implementation only now, we could write one method for
> each message. Here fold those common handles to corresponding vhost
> user handler.
>
> Signed-off-by: Yuanhan Liu 
> ---
>  lib/librte_vhost/vhost_user.c | 115 
> --
>  1 file changed, 31 insertions(+), 84 deletions(-)
>

Reviewed-by: Maxime Coquelin 

Thanks,
Maxime

[dpdk-dev] [PATCH 3/7] vhost: refactor source code structure

[Maxime Coquelin]

On 08/18/2016 10:48 AM, Yuanhan Liu wrote:
> The code structure is a bit messy now. For example, vhost-user message
> handling is spread to three different files:
>
> vhost-net-user.c  virtio-net.c  virtio-net-user.c
>
> Where, vhost-net-user.c is the entrance to handle all those messages
> and then invoke the right method for a specific message. Some of them
> are stored at virtio-net.c, while others are stored at virtio-net-user.c.
>
> The truth is all of them should be in one file, vhost_user.c.
>
> So this patch refactors the source code structure: mainly on renaming
> files and moving code from one file to another file that is more suitable
> for storing it. Thus, no functional changes are made.
>
> After the refactor, the code structure becomes to:
>
> - socket.c  handles all vhost-user socket file related stuff, such
> as, socket file creation for server mode, reconnection
> for client mode.
>
> - vhost.c   mainly on stuff like vhost device creation/destroy/reset.
> Most of the vhost API implementation are there, too.
>
> - vhost_user.c  all stuff about vhost-user messages handling goes there.
>
> - virtio_net.c  all stuff about virtio-net should go there. It has virtio
> net Rx/Tx implementation only so far: it's just a rename
> from vhost_rxtx.c
>
> Signed-off-by: Yuanhan Liu 
> ---
>  lib/librte_vhost/Makefile  |6 +-
>  lib/librte_vhost/{vhost-net-user.c => socket.c}|  209 +---
>  lib/librte_vhost/vhost.c   |  409 
>  lib/librte_vhost/{vhost-net.h => vhost.h}  |   24 +-
>  lib/librte_vhost/vhost_user.c  | 1040 
> 
>  .../{vhost-net-user.h => vhost_user.h} |   17 +-
>  lib/librte_vhost/virtio-net-user.c |  470 -
>  lib/librte_vhost/virtio-net-user.h |   62 --
>  lib/librte_vhost/virtio-net.c  |  847 
>  lib/librte_vhost/{vhost_rxtx.c => virtio_net.c}|4 +-
>  10 files changed, 1489 insertions(+), 1599 deletions(-)
>  rename lib/librte_vhost/{vhost-net-user.c => socket.c} (71%)
>  create mode 100644 lib/librte_vhost/vhost.c
>  rename lib/librte_vhost/{vhost-net.h => vhost.h} (92%)
>  create mode 100644 lib/librte_vhost/vhost_user.c
>  rename lib/librte_vhost/{vhost-net-user.h => vhost_user.h} (87%)
>  delete mode 100644 lib/librte_vhost/virtio-net-user.c
>  delete mode 100644 lib/librte_vhost/virtio-net-user.h
>  delete mode 100644 lib/librte_vhost/virtio-net.c
>  rename lib/librte_vhost/{vhost_rxtx.c => virtio_net.c} (99%)

The structure is much cleaner now, and thanks for the detailed
information.

I didn't catch any error, and agree on the change:
Reviewed-by: Maxime Coquelin 

Thanks,
Maxime

[dpdk-dev] [PATCH 2/7] vhost: remove sub source dir

[Maxime Coquelin]

On 08/18/2016 10:48 AM, Yuanhan Liu wrote:
> We now have one vhost implementation; no sub source dir is needed.
> Rmove it by move them to upper dir.
s/Rmove/Remove/
>
> Signed-off-by: Yuanhan Liu 
> ---
>  lib/librte_vhost/Makefile   | 6 +++---
>  lib/librte_vhost/{vhost_user => }/fd_man.c  | 0
>  lib/librte_vhost/{vhost_user => }/fd_man.h  | 0
>  lib/librte_vhost/{vhost_user => }/vhost-net-user.c  | 0
>  lib/librte_vhost/{vhost_user => }/vhost-net-user.h  | 0
>  lib/librte_vhost/{vhost_user => }/virtio-net-user.c | 0
>  lib/librte_vhost/{vhost_user => }/virtio-net-user.h | 0
>  7 files changed, 3 insertions(+), 3 deletions(-)
>  rename lib/librte_vhost/{vhost_user => }/fd_man.c (100%)
>  rename lib/librte_vhost/{vhost_user => }/fd_man.h (100%)
>  rename lib/librte_vhost/{vhost_user => }/vhost-net-user.c (100%)
>  rename lib/librte_vhost/{vhost_user => }/vhost-net-user.h (100%)
>  rename lib/librte_vhost/{vhost_user => }/virtio-net-user.c (100%)
>  rename lib/librte_vhost/{vhost_user => }/virtio-net-user.h (100%)

Other than this typo:
Reviewed-by: Maxime Coquelin 

Thanks,
Maxime

[dpdk-dev] [PATCH 1/7] vhost: remove vhost-cuse

[Maxime Coquelin]

On 08/18/2016 10:48 AM, Yuanhan Liu wrote:
> remove vhost-cuse code, including the eventfd_link kernel module that
> is for vhost-cuse only.
>
> The lib/virt/qemu-wrap.py is also removed, as it's mainly for vhost-cuse
> usage.
>
> As we have one vhost implementation now, one vhost config option is
> needed only. Thus, CONFIG_RTE_LIBRTE_VHOST_USER is removed.
>
> Signed-off-by: Yuanhan Liu 
> ---
>  config/common_base|   6 +-
>  lib/librte_vhost/Makefile |  13 +-
>  lib/librte_vhost/eventfd_link/Makefile|  41 ---
>  lib/librte_vhost/eventfd_link/eventfd_link.c  | 277 
>  lib/librte_vhost/eventfd_link/eventfd_link.h  |  94 --
>  lib/librte_vhost/libvirt/qemu-wrap.py | 387 ---
>  lib/librte_vhost/vhost_cuse/eventfd_copy.c| 104 ---
>  lib/librte_vhost/vhost_cuse/eventfd_copy.h|  45 ---
>  lib/librte_vhost/vhost_cuse/vhost-net-cdev.c  | 431 -
>  lib/librte_vhost/vhost_cuse/virtio-net-cdev.c | 433 
> --
>  lib/librte_vhost/vhost_cuse/virtio-net-cdev.h |  56 
>  mk/rte.app.mk |   3 -
>  12 files changed, 4 insertions(+), 1886 deletions(-)
>  delete mode 100644 lib/librte_vhost/eventfd_link/Makefile
>  delete mode 100644 lib/librte_vhost/eventfd_link/eventfd_link.c
>  delete mode 100644 lib/librte_vhost/eventfd_link/eventfd_link.h
>  delete mode 100755 lib/librte_vhost/libvirt/qemu-wrap.py
>  delete mode 100644 lib/librte_vhost/vhost_cuse/eventfd_copy.c
>  delete mode 100644 lib/librte_vhost/vhost_cuse/eventfd_copy.h
>  delete mode 100644 lib/librte_vhost/vhost_cuse/vhost-net-cdev.c
>  delete mode 100644 lib/librte_vhost/vhost_cuse/virtio-net-cdev.c
>  delete mode 100644 lib/librte_vhost/vhost_cuse/virtio-net-cdev.h

Looks good to me:
Reviewed-by: Maxime Coquelin 

Thanks,
Maxime

[dpdk-dev] [PATCH] app/testpmd: fix DCB config issue on ixgbe

[Iremonger, Bernard]

Hi Wenzhuo,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Friday, August 5, 2016 6:20 AM
> To: dev at dpdk.org
> Cc: De Lara Guarch, Pablo ; Lu, Wenzhuo
> 
> Subject: [dpdk-dev] [PATCH] app/testpmd: fix DCB config issue on ixgbe
> 
> An issue is found that DCB cannot be configured on ixgbe NICs. It's said the
> TX queue number is not right.
> On ixgbe the max TX queue number is not fixed, it depends on the multi-
> queue mode.
> 
> This patch adds the device configuration before getting info in the DCB
> configuration process. So the right info can be got depending on the
> configuration.
> 
> Fixes: 96c0450dff86 (ixgbe: fix dropping packets from unsupported Tx
> queues)
> Signed-off-by: Wenzhuo Lu 
> ---
>  app/test-pmd/testpmd.c | 39 +--
>  1 file changed, 21 insertions(+), 18 deletions(-)
> 
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> 1428974..ba41bea 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -1962,17 +1962,30 @@ init_port_dcb_config(portid_t pid,
>uint8_t pfc_en)
>  {
>   struct rte_eth_conf port_conf;
> - struct rte_eth_dev_info dev_info;
>   struct rte_port *rte_port;
>   int retval;
>   uint16_t i;
> 
> - rte_eth_dev_info_get(pid, _info);
> + rte_port = [pid];
> +
> + memset(_conf, 0, sizeof(struct rte_eth_conf));
> + /* Enter DCB configuration status */
> + dcb_config = 1;
> +
> + /*set configuration of DCB in vt mode and DCB in non-vt mode*/
> + retval = get_eth_dcb_conf(_conf, dcb_mode, num_tcs,
> pfc_en);
> + if (retval < 0)
> + return retval;
> + port_conf.rxmode.hw_vlan_filter = 1;
> +
> + (void)rte_eth_dev_configure(pid, 0, 0, _conf);

The return value of rte_eth_dev_configure() should be checked.
Calling rte_eth_dev_configure() with  parameters nb_rx_q and nb_tx_q equal to 0 
returns -EINVAL, and does nothing.
Should the values of nb_rx_q and nb_tx_q be non zero?

> + rte_eth_dev_info_get(pid, _port->dev_info);
> 
>   /* If dev_info.vmdq_pool_base is greater than 0,
>* the queue id of vmdq pools is started after pf queues.
>*/
> - if (dcb_mode == DCB_VT_ENABLED && dev_info.vmdq_pool_base >
> 0) {
> + if (dcb_mode == DCB_VT_ENABLED &&
> + rte_port->dev_info.vmdq_pool_base > 0) {
>   printf("VMDQ_DCB multi-queue mode is nonsensical"
>   " for port %d.", pid);
>   return -1;
> @@ -1982,13 +1995,13 @@ init_port_dcb_config(portid_t pid,
>* and has the same number of rxq and txq in dcb mode
>*/
>   if (dcb_mode == DCB_VT_ENABLED) {
> - nb_rxq = dev_info.max_rx_queues;
> - nb_txq = dev_info.max_tx_queues;
> + nb_rxq = rte_port->dev_info.max_rx_queues;
> + nb_txq = rte_port->dev_info.max_tx_queues;
>   } else {
>   /*if vt is disabled, use all pf queues */
> - if (dev_info.vmdq_pool_base == 0) {
> - nb_rxq = dev_info.max_rx_queues;
> - nb_txq = dev_info.max_tx_queues;
> + if (rte_port->dev_info.vmdq_pool_base == 0) {
> + nb_rxq = rte_port->dev_info.max_rx_queues;
> + nb_txq = rte_port->dev_info.max_tx_queues;
>   } else {
>   nb_rxq = (queueid_t)num_tcs;
>   nb_txq = (queueid_t)num_tcs;
> @@ -1997,16 +2010,6 @@ init_port_dcb_config(portid_t pid,
>   }
>   rx_free_thresh = 64;
> 
> - memset(_conf, 0, sizeof(struct rte_eth_conf));
> - /* Enter DCB configuration status */
> - dcb_config = 1;
> -
> - /*set configuration of DCB in vt mode and DCB in non-vt mode*/
> - retval = get_eth_dcb_conf(_conf, dcb_mode, num_tcs,
> pfc_en);
> - if (retval < 0)
> - return retval;
> -
> - rte_port = [pid];
>   memcpy(_port->dev_conf, _conf, sizeof(struct
> rte_eth_conf));
> 
>   rxtx_port_config(rte_port);
> --
> 1.9.3

Regards,

Bernard.

[dpdk-dev] vhost [query] : support for multiple ports and non VMDQ devices in vhost switch

[Maxime Coquelin]

On 08/18/2016 04:35 AM, Tan, Jianfeng wrote:
> Hi Maxime,
>
> On 8/17/2016 7:18 PM, Maxime Coquelin wrote:
>> Hi Jianfeng,
>>
>> On 08/17/2016 04:33 AM, Tan, Jianfeng wrote:
>>> Hi,
>>>
>>> Please review below proposal of Pankaj and myself after an offline
>>> discussion. (Pankaj, please correct me if I'm going somewhere wrong).
>>>
>>> a. Remove HW dependent option, --strip-vlan, because different kinds of
>>> NICs behave differently. It's a bug fix.
>>> b. Abstract switching logic into a framework, so that we can develop
>>> different kinds of switching logics. In this phase, we will have two
>>> switching logics: (1) a simple software-based mac learning switching;
>>> (2) VMDQ based switching. Any other advanced switching logics can be
>>> proposed based on this framework.
>>> c. Merge tep_termination example vxlan as a switching logic of the
>>> framework.
>>
>> I was also thinking of making physical port optional and add MAC
>> learning,
>> so this is all good for me.
>
> To make it clear, we are not proposing to eliminate physical port,
> instead, we just eliminate the binding of VMDQ and virtio ports,
> superseding it with a MAC learning switching.
>
>>
>> Let me know if I can help in implementation, I'll be happy to
>> contribute.
>
> Thank you for participating. Currently, I'm working on item a (will be a
> quick and simple fix). Pankaj is working on item b (which would be a
> huge change). Item c is depending on item b. So let's wait RFC patch
> from Pankaj and see what we can help.

Pankaj, so I organize myself , do you have an idea of when the RFC
patch will be available?

Thanks,
Maxime

[dpdk-dev] [PATCH 1/6] vhost: simplify memory regions handling

[Xu, Qian Q]

OK, it's better to claim that his patchset have the dependency on another one.  
 

-Original Message-
From: Yuanhan Liu [mailto:yuanhan@linux.intel.com] 
Sent: Wednesday, August 24, 2016 3:40 PM
To: Xu, Qian Q 
Cc: dev at dpdk.org; Maxime Coquelin 
Subject: Re: [dpdk-dev] [PATCH 1/6] vhost: simplify memory regions handling

Yes, it depends on the vhost-cuse removal patchset I sent last week.

--yliu

On Wed, Aug 24, 2016 at 07:26:07AM +, Xu, Qian Q wrote:
> I want to apply the patch on the latest DPDK, see below commit ID but failed 
> since no vhost.h and vhost-user.h files. So do you have any dependency on 
> other patches? 
> 
> commit 28d8abaf250c3fb4dcb6416518f4c54b4ae67205
> Author: Deirdre O'Connor 
> Date:   Mon Aug 22 17:20:08 2016 +0100
> 
> doc: fix patchwork link
> 
> Fixes: 58abf6e77c6b ("doc: add contributors guide")
> 
> Reported-by: Jon Loeliger 
> Signed-off-by: Deirdre O'Connor 
> Acked-by: John McNamara 
> 
> 
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yuanhan Liu
> Sent: Tuesday, August 23, 2016 4:11 PM
> To: dev at dpdk.org
> Cc: Maxime Coquelin ; Yuanhan Liu  at linux.intel.com>
> Subject: [dpdk-dev] [PATCH 1/6] vhost: simplify memory regions handling
> 
> Due to history reason (that vhost-cuse comes before vhost-user), some fields 
> for maintaining the vhost-user memory mappings (such as mmapped address and 
> size, with those we then can unmap on destroy) are kept in "orig_region_map" 
> struct, a structure that is defined only in vhost-user source file.
> 
> The right way to go is to remove the structure and move all those fields into 
> virtio_memory_region struct. But we simply can't do that before, because it 
> breaks the ABI.
> 
> Now, thanks to the ABI refactoring, it's never been a blocking issue any 
> more. And here it goes: this patch removes orig_region_map and redefines 
> virtio_memory_region, to include all necessary info.
> 
> With that, we can simplify the guest/host address convert a bit.
> 
> Signed-off-by: Yuanhan Liu 
> ---
>  lib/librte_vhost/vhost.h  |  49 ++--
>  lib/librte_vhost/vhost_user.c | 172 
> +-
>  2 files changed, 90 insertions(+), 131 deletions(-)
> 
> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h index 
> c2dfc3c..df2107b 100644
> --- a/lib/librte_vhost/vhost.h
> +++ b/lib/librte_vhost/vhost.h
> @@ -143,12 +143,14 @@ struct virtio_net {
>   * Information relating to memory regions including offsets to
>   * addresses in QEMUs memory file.
>   */
> -struct virtio_memory_regions {
> - uint64_t guest_phys_address;
> - uint64_t guest_phys_address_end;
> - uint64_t memory_size;
> - uint64_t userspace_address;
> - uint64_t address_offset;
> +struct virtio_memory_region {
> + uint64_t guest_phys_addr;
> + uint64_t guest_user_addr;
> + uint64_t host_user_addr;
> + uint64_t size;
> + void *mmap_addr;
> + uint64_t mmap_size;
> + int fd;
>  };
>  
>  
> @@ -156,12 +158,8 @@ struct virtio_memory_regions {
>   * Memory structure includes region and mapping information.
>   */
>  struct virtio_memory {
> - /* Base QEMU userspace address of the memory file. */
> - uint64_t base_address;
> - uint64_t mapped_address;
> - uint64_t mapped_size;
>   uint32_t nregions;
> - struct virtio_memory_regions regions[0];
> + struct virtio_memory_region regions[0];
>  };
>  
>  
> @@ -200,26 +198,23 @@ extern uint64_t VHOST_FEATURES;
>  #define MAX_VHOST_DEVICE 1024
>  extern struct virtio_net *vhost_devices[MAX_VHOST_DEVICE];
>  
> -/**
> - * Function to convert guest physical addresses to vhost virtual addresses.
> - * This is used to convert guest virtio buffer addresses.
> - */
> +/* Convert guest physical Address to host virtual address */
>  static inline uint64_t __attribute__((always_inline)) -gpa_to_vva(struct 
> virtio_net *dev, uint64_t guest_pa)
> +gpa_to_vva(struct virtio_net *dev, uint64_t gpa)
>  {
> - struct virtio_memory_regions *region;
> - uint32_t regionidx;
> - uint64_t vhost_va = 0;
> -
> - for (regionidx = 0; regionidx < dev->mem->nregions; regionidx++) {
> - region = >mem->regions[regionidx];
> - if ((guest_pa >= region->guest_phys_address) &&
> - (guest_pa <= region->guest_phys_address_end)) {
> - vhost_va = region->address_offset + guest_pa;
> - break;
> + struct virtio_memory_region *reg;
> + uint32_t i;
> +
> + for (i = 0; i < dev->mem->nregions; i++) {
> + reg = >mem->regions[i];
> + if (gpa >= reg->guest_phys_addr &&
> + gpa <  reg->guest_phys_addr + reg->size) {
> + return gpa - reg->guest_phys_addr +
> +reg->host_user_addr;
>   }
>   }
> - return vhost_va;
> +
> + return 0;
>  }
>  
> 

[dpdk-dev] [PATCH 0/7] vhost: vhost-cuse removal and code path refactoring

[Xu, Qian Q]

I think you need also update vhost sample guide and vhost library in the 
programmer guide for this release. 

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yuanhan Liu
Sent: Thursday, August 18, 2016 4:49 PM
To: dev at dpdk.org
Cc: Yuanhan Liu 
Subject: [dpdk-dev] [PATCH 0/7] vhost: vhost-cuse removal and code path 
refactoring

The first patch removes the vhost-cuse (see following link for the deprecate 
note)

http://dpdk.org/ml/archives/dev/2016-July/044080.html


After the removal, there is no reason to keep the vhost_user sub source dir any 
more. This also brings a chance to rename all those files in a more proper way 
(see patch 3 for details).


---
Yuanhan Liu (7):
  vhost: remove vhost-cuse
  vhost: remove sub source dir
  vhost: refactor source code structure
  vhost: fold common message handlers
  vhost: unify function names
  vhost: get device once
  vhost: simplify features set/get

 config/common_base |   6 +-
 lib/librte_vhost/Makefile  |  13 +-
 lib/librte_vhost/eventfd_link/Makefile |  41 -
 lib/librte_vhost/eventfd_link/eventfd_link.c   | 277 ---
 lib/librte_vhost/eventfd_link/eventfd_link.h   |  94 ---
 lib/librte_vhost/{vhost_user => }/fd_man.c |   0
 lib/librte_vhost/{vhost_user => }/fd_man.h |   0
 lib/librte_vhost/libvirt/qemu-wrap.py  | 387 -
 .../{vhost_user/vhost-net-user.c => socket.c}  | 209 +
 lib/librte_vhost/vhost.c   | 409 +
 lib/librte_vhost/{vhost-net.h => vhost.h}  |  24 +-
 lib/librte_vhost/vhost_cuse/eventfd_copy.c | 104 ---
 lib/librte_vhost/vhost_cuse/eventfd_copy.h |  45 -
 lib/librte_vhost/vhost_cuse/vhost-net-cdev.c   | 431 --
 lib/librte_vhost/vhost_cuse/virtio-net-cdev.c  | 433 --
 lib/librte_vhost/vhost_cuse/virtio-net-cdev.h  |  56 --
 lib/librte_vhost/vhost_user.c  | 917 +
 .../{vhost_user/vhost-net-user.h => vhost_user.h}  |  17 +-
 lib/librte_vhost/vhost_user/virtio-net-user.c  | 470 ---
 lib/librte_vhost/vhost_user/virtio-net-user.h  |  62 --
 lib/librte_vhost/virtio-net.c  | 847 ---
 lib/librte_vhost/{vhost_rxtx.c => virtio_net.c}|   4 +-
 mk/rte.app.mk  |   3 -
 23 files changed, 1367 insertions(+), 3482 deletions(-)  delete mode 100644 
lib/librte_vhost/eventfd_link/Makefile
 delete mode 100644 lib/librte_vhost/eventfd_link/eventfd_link.c
 delete mode 100644 lib/librte_vhost/eventfd_link/eventfd_link.h
 rename lib/librte_vhost/{vhost_user => }/fd_man.c (100%)  rename 
lib/librte_vhost/{vhost_user => }/fd_man.h (100%)  delete mode 100755 
lib/librte_vhost/libvirt/qemu-wrap.py
 rename lib/librte_vhost/{vhost_user/vhost-net-user.c => socket.c} (71%)  
create mode 100644 lib/librte_vhost/vhost.c  rename 
lib/librte_vhost/{vhost-net.h => vhost.h} (92%)  delete mode 100644 
lib/librte_vhost/vhost_cuse/eventfd_copy.c
 delete mode 100644 lib/librte_vhost/vhost_cuse/eventfd_copy.h
 delete mode 100644 lib/librte_vhost/vhost_cuse/vhost-net-cdev.c
 delete mode 100644 lib/librte_vhost/vhost_cuse/virtio-net-cdev.c
 delete mode 100644 lib/librte_vhost/vhost_cuse/virtio-net-cdev.h
 create mode 100644 lib/librte_vhost/vhost_user.c  rename 
lib/librte_vhost/{vhost_user/vhost-net-user.h => vhost_user.h} (87%)  delete 
mode 100644 lib/librte_vhost/vhost_user/virtio-net-user.c
 delete mode 100644 lib/librte_vhost/vhost_user/virtio-net-user.h
 delete mode 100644 lib/librte_vhost/virtio-net.c  rename 
lib/librte_vhost/{vhost_rxtx.c => virtio_net.c} (99%)

--
1.9.0

[dpdk-dev] [PATCH 1/6] vhost: simplify memory regions handling

[Xu, Qian Q]

I want to apply the patch on the latest DPDK, see below commit ID but failed 
since no vhost.h and vhost-user.h files. So do you have any dependency on other 
patches? 

commit 28d8abaf250c3fb4dcb6416518f4c54b4ae67205
Author: Deirdre O'Connor 
Date:   Mon Aug 22 17:20:08 2016 +0100

doc: fix patchwork link

Fixes: 58abf6e77c6b ("doc: add contributors guide")

Reported-by: Jon Loeliger 
Signed-off-by: Deirdre O'Connor 
Acked-by: John McNamara 


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yuanhan Liu
Sent: Tuesday, August 23, 2016 4:11 PM
To: dev at dpdk.org
Cc: Maxime Coquelin ; Yuanhan Liu 
Subject: [dpdk-dev] [PATCH 1/6] vhost: simplify memory regions handling

Due to history reason (that vhost-cuse comes before vhost-user), some fields 
for maintaining the vhost-user memory mappings (such as mmapped address and 
size, with those we then can unmap on destroy) are kept in "orig_region_map" 
struct, a structure that is defined only in vhost-user source file.

The right way to go is to remove the structure and move all those fields into 
virtio_memory_region struct. But we simply can't do that before, because it 
breaks the ABI.

Now, thanks to the ABI refactoring, it's never been a blocking issue any more. 
And here it goes: this patch removes orig_region_map and redefines 
virtio_memory_region, to include all necessary info.

With that, we can simplify the guest/host address convert a bit.

Signed-off-by: Yuanhan Liu 
---
 lib/librte_vhost/vhost.h  |  49 ++--
 lib/librte_vhost/vhost_user.c | 172 +-
 2 files changed, 90 insertions(+), 131 deletions(-)

diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h index 
c2dfc3c..df2107b 100644
--- a/lib/librte_vhost/vhost.h
+++ b/lib/librte_vhost/vhost.h
@@ -143,12 +143,14 @@ struct virtio_net {
  * Information relating to memory regions including offsets to
  * addresses in QEMUs memory file.
  */
-struct virtio_memory_regions {
-   uint64_t guest_phys_address;
-   uint64_t guest_phys_address_end;
-   uint64_t memory_size;
-   uint64_t userspace_address;
-   uint64_t address_offset;
+struct virtio_memory_region {
+   uint64_t guest_phys_addr;
+   uint64_t guest_user_addr;
+   uint64_t host_user_addr;
+   uint64_t size;
+   void *mmap_addr;
+   uint64_t mmap_size;
+   int fd;
 };


@@ -156,12 +158,8 @@ struct virtio_memory_regions {
  * Memory structure includes region and mapping information.
  */
 struct virtio_memory {
-   /* Base QEMU userspace address of the memory file. */
-   uint64_t base_address;
-   uint64_t mapped_address;
-   uint64_t mapped_size;
uint32_t nregions;
-   struct virtio_memory_regions regions[0];
+   struct virtio_memory_region regions[0];
 };


@@ -200,26 +198,23 @@ extern uint64_t VHOST_FEATURES;
 #define MAX_VHOST_DEVICE   1024
 extern struct virtio_net *vhost_devices[MAX_VHOST_DEVICE];

-/**
- * Function to convert guest physical addresses to vhost virtual addresses.
- * This is used to convert guest virtio buffer addresses.
- */
+/* Convert guest physical Address to host virtual address */
 static inline uint64_t __attribute__((always_inline)) -gpa_to_vva(struct 
virtio_net *dev, uint64_t guest_pa)
+gpa_to_vva(struct virtio_net *dev, uint64_t gpa)
 {
-   struct virtio_memory_regions *region;
-   uint32_t regionidx;
-   uint64_t vhost_va = 0;
-
-   for (regionidx = 0; regionidx < dev->mem->nregions; regionidx++) {
-   region = >mem->regions[regionidx];
-   if ((guest_pa >= region->guest_phys_address) &&
-   (guest_pa <= region->guest_phys_address_end)) {
-   vhost_va = region->address_offset + guest_pa;
-   break;
+   struct virtio_memory_region *reg;
+   uint32_t i;
+
+   for (i = 0; i < dev->mem->nregions; i++) {
+   reg = >mem->regions[i];
+   if (gpa >= reg->guest_phys_addr &&
+   gpa <  reg->guest_phys_addr + reg->size) {
+   return gpa - reg->guest_phys_addr +
+  reg->host_user_addr;
}
}
-   return vhost_va;
+
+   return 0;
 }

 struct virtio_net_device_ops const *notify_ops; diff --git 
a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c index 
eee99e9..d2071fd 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -74,18 +74,6 @@ static const char *vhost_message_str[VHOST_USER_MAX] = {
[VHOST_USER_SEND_RARP]  = "VHOST_USER_SEND_RARP",  };

-struct orig_region_map {
-   int fd;
-   uint64_t mapped_address;
-   uint64_t mapped_size;
-   uint64_t blksz;
-};
-
-#define orig_region(ptr, nregions) \
-   ((struct orig_region_map *)RTE_PTR_ADD((ptr), \
-   sizeof(struct virtio_memory) + \
-   sizeof(struct 

[dpdk-dev] [PATCH v3 0/5] vhost: optimize enqueue

[Wang, Zhihong]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, August 22, 2016 6:35 PM
> To: Maxime Coquelin ; Wang, Zhihong
> ; yuanhan.liu at linux.intel.com
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 0/5] vhost: optimize enqueue
> 
> 2016-08-22 12:01, Maxime Coquelin:
> > I forgot to add that before this series, I think we should first fix the
> windows bug.
> > Else we will need a dedicated fix for the stable branch.
> 
> This is a funny situation :)
> If Zhihong had reworked the code without mentioning it is fixing a scenario
> with Windows guests, maybe that nobody would have notice ;) That's
> probably why it is not written in v2/v3. But thanks to the v1, we all know it:
>   "It also fixes the issue working with Windows VMs."

I thought it'd be more appropriate to send a dedicated fix for stable branch.
So I removed this info.

> 
> So yes, it would be a lot better to find the root cause and try to have a
> minimal fix for 16.07, then rework the code for performance in 16.11.
> I think we must avoid silent fixes, and even more, avoid writing specific 
> fixes
> for stable branches without validating them in the master branch and its large
> users base.

Okay, that's also what Maxime and Yuanhan suggest.

BTW the root cause has been identified and fix will be in v4.

> 
> Thanks for your good works guys, DPDK vhost is improving very well.