[dpdk-dev] [PATCH v2] kni: fix vhost-kni compile errors

[Thomas Monjalon]

2016-04-11 19:30, Ferruh Yigit:
> fix vhost-kni compile errors because of Linux kernel API changes
> 
> - SOCK_ASYNC_WAITDATA renamed to SOCKWQ_ASYNC_WAITDATA
>   Linux commit id: 9cd3e072
>   Updated in Linux kernel 4.4
> 
> - sk_alloc() gets new parameter
>   Linux commit id: 11aa9c28b
>   Updated in Linux kernel 4.2
>   New parameter is: "@kern: is this to be a kernel socket?"
> 
> Reported-by: chintu hetam 
> Signed-off-by: Ferruh Yigit 

Applied, thanks

[dpdk-dev] [PATCH] librte_port: fix the buffer overflow for ring writer

[Thomas Monjalon]

2016-04-11 18:55, Jasvinder Singh:
> Fixes the buffer overflow that occurs due to following;
> 
> 1. When the input packet burst does not meet the conditions: (a) being
> contiguous (first n bits set in pkts_mask, all the other bits cleared)
> and (b) containing a full burst, i.e. at least tx_burst_sz packets
> (n >= tx_burst_size). This is the slow(er) code path taken when local
> variable expr != 0.
> 2. There are some packets already in the buffer.
> 3. The number of packets in the incoming burst (i.e. popcount(pkts_mask))
> plus the number of packets already in the buffer exceeds the buffer size
> (RTE_PORT_IN_BURST_SIZE_MAX, i.e. 64).
> 
> Fixes: bf6931b242f7 ("port: ring")
> Fixes: 5f4cd47309d6 ("port: add ring writer nodrop")
> 
> Signed-off-by: Jasvinder Singh 
> Acked-by: Cristian Dumitrescu 

Applied, thanks

[dpdk-dev] [PATCH] librte_port: fix the bsz_mask variable type

[Thomas Monjalon]

2016-04-11 18:54, Jasvinder Singh:
> Fixes the variable bsz_mask type form unit32_t to unit64_t
> 
> Fixes: 4d97e8b565cc ("port: ethdev")
> Fixes: 304c8091e90a ("port: add ethdev writer nodrop")
> Fixes: 8dceb6aa6ecf ("port: hierarchical scheduler")
> Fixes: 3e5966837a09 ("port: new Tx burst implementation of ring writer")
> Fixes: 5f4cd47309d6 ("port: add ring writer nodrop")
> 
> Signed-off-by: Jasvinder Singh 
> Acked-by: Cristian Dumitrescu 

Applied, thanks

[dpdk-dev] [PATCH] doc: fix references in guides

[Mcnamara, John]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, April 11, 2016 10:55 PM
> To: Mcnamara, John 
> Cc: dev at dpdk.org
> Subject: [PATCH] doc: fix references in guides
> 
> Replace some hard-coded section numbers by dynamic links.
> 
> Signed-off-by: Thomas Monjalon 

Acked-by: John McNamara 

[dpdk-dev] [PATCH v2] roadmap for 16.07

[Thomas Monjalon]

From: Harry van Haaren 

Add roadmap items for 16.07, remove 16.04 from schedule.

Signed-off-by: Harry van Haaren 
Signed-off-by: Thomas Monjalon 
---
 dev/roadmap.html | 67 +---
 1 file changed, 35 insertions(+), 32 deletions(-)

v2:
- add more 16.07 topics from mailing list patches
- add some 16.11 topics from discussions

diff --git a/dev/roadmap.html b/dev/roadmap.html
index 6b83e17..b479967 100644
--- a/dev/roadmap.html
+++ b/dev/roadmap.html
@@ -40,33 +40,42 @@
Development roadmap
Major known features and milestones may be noted here.
This list is obviously neither complete nor guaranteed.
-   Version 16.04 (2016 April)
+   Version 16.07 (2016 July)

-   cgroup resource awareness
-   hugetlbfs mount point size
-   external mempool manager
-   Intel resource director technology
-   improve live migration
-   tcpdump support
-   speed capability
-   generic tunneling
-   Hyper-V driver
-   ixgbe base update
-   i40e flow director extension
-   i40e VEB switching and floating VEB
-   i40e IPGRE
-   i40e VF MAC address
-   i40e PCIe extended tag rework
-   fm10k Rx interrupt
-   fm10k FTAG based forwarding
-   virtio 1.0
-   virtio for containers
-   vhost TSO
-   bonding mode 4 external state machine
-   more LPM hops
-   SNOW 3G cipher
-   IPsec example
-   packet framework enhancements for edge router
+   Dynamic Mempool Cache Allocation
+   External Mempool Cache
+   External Mempool Manager
+   Mempool Allocation Rework
+   Packet Capture Framework
+   Automatic Device Binding
+   Hotplug Notification
+   Device Objects Refactoring
+   Flattened Device Tree Access
+   XStats Enhancements
+   bnxt Driver for Broadcom NetXtreme 10/25/50G C-Series
+   qede Driver for QLogic FastLinQ QL4 25/40G CNA
+   ixgbe/i40e Automatic VF Reset from PF
+   i40e Network Service Header
+   i40e Floating VEB
+   Xen Netfront Driver
+   Vhost/Virtio Performance Loopback Utility
+   Vhost API Refactoring
+   Virtio Rx/Tx Split
+   Virtio Descriptor Index Optimization
+   Virtio in Containers
+   Live Migration for SR-IOV
+   Software implementation of KASUMI Crypto
+   Bit-Level Cryptodev for SNOW 3G
+   IPv6 and Transport Mode in IPsec Sample App
+   IP Pipeline Enhancements
+   Keep-Alive Enhancements
+   
+   Version 16.11 (2016 November)
+   
+   Rx Filtering Rework
+   QEMU Vhost backend Reconnect
+   Delay Packet Copy in Vhost-user
+   Fix library and symbol Namespace

Cycle model
A typical release should be done after 3 months (was 4 months during 
2015).
@@ -82,12 +91,6 @@
The last period is 1 month long and is dedicated to bug fixing.
Scheduling
The release cycles are progressively shorten during 2016.
-   Release 16.04
-   
-   Proposal deadline: January 31
-   Integration deadline: March 10
-   Release: April 7
-   
Release 16.07

Proposal deadline: May 8
-- 
2.7.0

[dpdk-dev] Packet drops at lower tc transmit-rates.

[Dumitrescu, Cristian]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sridhar.V.Iyer
> Sent: Thursday, April 7, 2016 8:24 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Packet drops at lower tc transmit-rates.
> 
> Hi all,
> 
> We are using DPDK 1.7 in our application.
> We are running into an issue where a lower transmit-rate configured at the
> traffic class of a subport is causing complete packet drops.
> Here are few parameters to clear up some context:
> 
> Packet length  = 728 byte
> Port rate  = 1Gbps   = 1250 bytes/s
> Subport tc_period   = 10 ms
> Configured TC0 rate   = 500 kbps   = 62500 bytes/s
> 
> This means that for the given subport tc0_credits_per_period = 10 * 62500 /
> 1000 = 625 (from rte_sched_subport_config)
> 
> Now, there is no token bucket at the subport-tc level, so there are no credits
> to accrue. The tc0_credits are just initialized to 625.
> - This means that we?ll never have ?enough_credits? in
> grinder_credits_check to process a 728 byte packet.
>- grinder_schedule will then return 0.
>  - grinder_handle will return 0.
>- which implies that the rte_sched_port_dequeue will never dequeue
> any packet.
> - After port->time exceeds the subport->tc_time, tc0_credit will be re-
> initialized back to 625 again.
> 
> Is this a bug in the logic?
> What are some of the viable workarounds?
> 
> Is this issue taken care of in the later releases?
> 
> Regards,
> Sridhar V Iyer
> 
>   


Hi Sridhar,

This case seems to take place only when the pipe TC is configured with 
relatively low rate.

One potential workaround could be to detect the case when the pipe TC credits 
per period is less than MTU size and either flag it as error or round up the 
pipe TC credits per period to at least 1x MTU:

if (pipe_params->tc_credits_per_period[i] < MTU) error(?);
if (pipe_params->tc_credits_per_period[i] < MTU) 
pipe_params->tc_credits_per_period[i] = MTU;

Another potential workaround could be to change the pipe TC credit update logic 
from straightforward re-initialization to a slightly more tuned strategy that, 
in some cases, keeps some of the existing credits, so that the existing credits 
are not completely lost but some of them (value capped to 1x MTU) are carried 
forward:

pipe->tc_credits[i] = (params->tc_credits_per_period[i] < MTU)?
((pipe->tc_credits[i] % MTU) + 
params->tc_credits_per_period[i]) : 
params->tc_credits_per_period[i];

This would give the chance to the pipe TC credits to accumulate and become 
greater than the MTU every few periods and a packet to be transmitted for this 
pipe TC. Of course, this strategy needs to be further developed.

Regards,
Cristian

[dpdk-dev] [PATCH] doc: Programmers guide IP fragmentation direct/indirect mbufs to wrong section

[Thomas Monjalon]

2016-04-11 11:24, John Guzik:
> --- a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
> +++ b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
> -For more information about direct and indirect mbufs, refer to the *DPDK 
> Programmers guide 7.7 Direct and Indirect Buffers.*
> +For more information about direct and indirect mbufs, refer to the *DPDK 
> Programmers guide 6.7 Direct and Indirect Buffers.*

We should replace it by a link.
There are some remaining hard references in the docs:
doc/guides/nics/virtio.rst:
For more details about kni, please refer to Chapter 24 "Kernel NIC 
Interface".
doc/guides/prog_guide/ip_fragment_reassembly_lib.rst:
For more information about direct and indirect mbufs, refer to the 
*DPDK Programmers guide 7.7 Direct and Indirect Buffers.*
doc/guides/sample_app_ug/multi_process.rst:
(refer to *DPDK Programmer's Guide* , Section 6.4, "Local Cache")

[dpdk-dev] librte_table build race with SYMLINK-FILE?

[Thomas Monjalon]

2016-04-11 11:15, Stephen Hemminger:
> On Mon, 11 Apr 2016 12:46:16 +0200
> Simon K?gstr?m  wrote:
> > In file included from [...]lib/librte_table/rte_table_lpm.c:43:0:
> > [...]/dpdk.build/include/rte_lpm.h:484:25: fatal error: rte_lpm_sse.h:
> > No such file or directory
> >  #include "rte_lpm_sse.h"
> 
> The issue is a missing dependency in the mk file for LPM.

There is already this line:
DEPDIRS-$(CONFIG_RTE_LIBRTE_TABLE) += lib/librte_lpm

[dpdk-dev] [PATCH 4/4] port: fix ethdev writer burst too big

[Sanford, Robert]

Hi Cristian,

Yes, I mostly agree with your suggestions:
1. We should fix the two obvious bugs (1a and 1b) right away. Jasvinder's
patches look fine.
2. We should take no immediate action on the issue I raised about PMDs
(vector IXGBE) not enqueuing more than 32 packets. We can discuss and
debate; no patch for 16.04, perhaps something in 16.07.


Let's start the discussion now, regarding vector IXGBE. You state
"Internally it handles packets in batches [of] 32 (as your code snippets
suggest), but there is no drop of excess packets taking place." I guess it
depends on your definition of "drop". If I pass 33 packets to
ixgbe_xmit_pkts_vec(), it will enqueue 32 packets, and return a value of
32. Can we agree on that?

--
Regards,
Robert


On 4/11/16 3:21 PM, "Dumitrescu, Cristian" 
wrote:

>Hi Robert,
>
>I am doing a quick summary below on the changes proposed by these patches:
>
>1. [PRIORITY 1] Bug fixing:
>a) Fix buffer overflow issue in rte_port_ring.c (writer, writer_nodrop):
>double the tx_buf buffer size (applicable for current code approach)
>b) Fix issue with handling burst sizes bigger than 32: replace all
>declarations of local variable bsz_size from uint32_t to uint64_t
>
>2. [PRIORITY 2] Treat burst size as a fixed/exact value for the TX burst
>(Approach 2) instead of minimal value (current code, Approach 1) for
>ethdev ports. Rationale is that some PMDs (like vector IXGBE) _might_
>drop the excess packets in the burst.
>
>Additional input:
>1. Bruce and I looked together at the code, it looks that vector IXGBE is
>not doing this (anymore). Internally it handles packets in batches on 32
>(as your code snippets suggest), but there is no drop of excess packets
>taking place.
>
>2. Venky also suggested to keep a larger burst as a single burst
>(Approach 1) rather than break the larger burst into a fixed/constant
>size burst while buffering the excess packets until complete burst is met
>in the future.
>
>Given this input and also the timing of the release, we think the best
>option is:
>- urgently send a quick patch to handle the bug fixes now
>- keep the existing code (burst size used as minimal burst size
>requirement, not constant) as is, at least for now, and if you feel it is
>not the best choice, we can continue to debate it for 16.7 release.
>What do you think?
>
>Jasvinder just send the bug fixing patches, hopefully they will make it
>into the 16.4 release:
>http://www.dpdk.org/ml/archives/dev/2016-April/037392.html
>http://www.dpdk.org/ml/archives/dev/2016-April/037393.html
>
>Many thanks for your work on this, Robert!
>
>Regards,
>Cristian

[dpdk-dev] [PATCH v2] kni: fix vhost-kni compile errors

[Ferruh Yigit]

fix vhost-kni compile errors because of Linux kernel API changes

- SOCK_ASYNC_WAITDATA renamed to SOCKWQ_ASYNC_WAITDATA
  Linux commit id: 9cd3e072
  Updated in Linux kernel 4.4

- sk_alloc() gets new parameter
  Linux commit id: 11aa9c28b
  Updated in Linux kernel 4.2
  New parameter is: "@kern: is this to be a kernel socket?"

Reported-by: chintu hetam 
Signed-off-by: Ferruh Yigit 

---

Patch not tested, just fixed compiler errors.

v2:
* use "#ifdef SOCKWQ_ASYNC_WAITDATA" instead of version check
---
 lib/librte_eal/linuxapp/kni/kni_vhost.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/kni_vhost.c 
b/lib/librte_eal/linuxapp/kni/kni_vhost.c
index 6f2a961..a3ca849 100644
--- a/lib/librte_eal/linuxapp/kni/kni_vhost.c
+++ b/lib/librte_eal/linuxapp/kni/kni_vhost.c
@@ -251,7 +251,11 @@ kni_sock_poll(struct file *file, struct socket *sock, 
poll_table * wait)
mask |= POLLIN | POLLRDNORM;

if (sock_writeable(>sk) ||
+#ifdef SOCKWQ_ASYNC_NOSPACE
+   (!test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, >sock->flags) &&
+#else
(!test_and_set_bit(SOCK_ASYNC_NOSPACE, >sock->flags) &&
+#endif
 sock_writeable(>sk)))
mask |= POLLOUT | POLLWRNORM;

@@ -619,8 +623,11 @@ kni_sk_write_space(struct sock *sk)
wait_queue_head_t *wqueue;

if (!sock_writeable(sk) ||
-   !test_and_clear_bit(SOCK_ASYNC_NOSPACE,
-   >sk_socket->flags))
+#ifdef SOCKWQ_ASYNC_NOSPACE
+   !test_and_clear_bit(SOCKWQ_ASYNC_NOSPACE, >sk_socket->flags))
+#else
+   !test_and_clear_bit(SOCK_ASYNC_NOSPACE, >sk_socket->flags))
+#endif
return;
wqueue = sk_sleep(sk);
if (wqueue && waitqueue_active(wqueue))
@@ -666,8 +673,14 @@ kni_vhost_backend_init(struct kni_dev *kni)
if (kni->vhost_queue != NULL)
return -1;

-   if (!(q = (struct kni_vhost_queue *)sk_alloc(
- net, AF_UNSPEC, GFP_KERNEL, _raw_proto)))
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 2, 0)
+   q = (struct kni_vhost_queue *)sk_alloc(net, AF_UNSPEC, GFP_KERNEL,
+   _raw_proto, 0);
+#else
+   q = (struct kni_vhost_queue *)sk_alloc(net, AF_UNSPEC, GFP_KERNEL,
+   _raw_proto);
+#endif
+   if (!q)
return -ENOMEM;

err = sock_create_lite(AF_UNSPEC, SOCK_RAW, IPPROTO_RAW, >sock);
-- 
2.5.5

[dpdk-dev] [PATCH 4/4] port: fix ethdev writer burst too big

[Dumitrescu, Cristian]

Hi Robert,

I am doing a quick summary below on the changes proposed by these patches:

1. [PRIORITY 1] Bug fixing:
a) Fix buffer overflow issue in rte_port_ring.c (writer, writer_nodrop): double 
the tx_buf buffer size (applicable for current code approach)
b) Fix issue with handling burst sizes bigger than 32: replace all declarations 
of local variable bsz_size from uint32_t to uint64_t

2. [PRIORITY 2] Treat burst size as a fixed/exact value for the TX burst 
(Approach 2) instead of minimal value (current code, Approach 1) for ethdev 
ports. Rationale is that some PMDs (like vector IXGBE) _might_ drop the excess 
packets in the burst.

Additional input:
1. Bruce and I looked together at the code, it looks that vector IXGBE is not 
doing this (anymore). Internally it handles packets in batches on 32 (as your 
code snippets suggest), but there is no drop of excess packets taking place.

2. Venky also suggested to keep a larger burst as a single burst (Approach 1) 
rather than break the larger burst into a fixed/constant size burst while 
buffering the excess packets until complete burst is met in the future.

Given this input and also the timing of the release, we think the best option 
is:
- urgently send a quick patch to handle the bug fixes now
- keep the existing code (burst size used as minimal burst size requirement, 
not constant) as is, at least for now, and if you feel it is not the best 
choice, we can continue to debate it for 16.7 release.
What do you think?

Jasvinder just send the bug fixing patches, hopefully they will make it into 
the 16.4 release:
http://www.dpdk.org/ml/archives/dev/2016-April/037392.html
http://www.dpdk.org/ml/archives/dev/2016-April/037393.html

Many thanks for your work on this, Robert!

Regards,
Cristian


> -Original Message-
> From: Sanford, Robert [mailto:rsanford at akamai.com]
> Sent: Friday, April 1, 2016 5:22 PM
> To: Dumitrescu, Cristian ; dev at dpdk.org
> Cc: Liang, Cunming 
> Subject: Re: [dpdk-dev] [PATCH 4/4] port: fix ethdev writer burst too big
> 
> Hi Cristian,
> 
> Please see my comments inline.
> 
> >
> >
> >> -Original Message-
> >> From: Robert Sanford [mailto:rsanford2 at gmail.com]
> >> Sent: Monday, March 28, 2016 9:52 PM
> >> To: dev at dpdk.org; Dumitrescu, Cristian  >> intel.com>
> >> Subject: [PATCH 4/4] port: fix ethdev writer burst too big
> >>
> >> For f_tx_bulk functions in rte_port_ethdev.c, we may unintentionally
> >> send bursts larger than tx_burst_sz to the underlying ethdev.
> >> Some PMDs (e.g., ixgbe) may truncate this request to their maximum
> >> burst size, resulting in unnecessary enqueuing failures or ethdev
> >> writer retries.
> >
> >Sending bursts larger than tx_burst_sz is actually intentional. The
> >assumption is that NIC performance benefits from larger burst size. So
> >the tx_burst_sz is used as a minimal burst size requirement, not as a
> >maximal or fixed burst size requirement.
> >
> >I agree with you that a while ago the vector version of IXGBE driver used
> >to work the way you describe it, but I don't think this is the case
> >anymore. As an example, if TX burst size is set to 32 and 48 packets are
> >transmitted, than the PMD will TX all the 48 packets (internally it can
> >work in batches of 4, 8, 32, etc, should not matter) rather than TXing
> >just 32 packets out of 48 and user having to either discard or retry with
> >the remaining 16 packets. I am CC-ing Steve Liang for confirming this.
> >
> >Is there any PMD that people can name that currently behaves the
> >opposite, i.e. given a burst of 48 pkts for TX, accept 32 pkts and
> >discard the other 16?
> >
> >>
> 
> Yes, I believe that IXGBE *still* truncates. What am I missing? :) My
> interpretation of the latest vector TX burst function is that it truncates
> bursts longer than txq->tx_rs_thresh. Here are relevant code snippets that
> show it lowering the number of packets (nb_pkts) to enqueue (apologies in
> advance for the email client mangling the indentation):
> 
> ---
> 
> #define IXGBE_DEFAULT_TX_RSBIT_THRESH 32
> 
> static void
> ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info
> *dev_info)
> {
>   ...
>   dev_info->default_txconf = (struct rte_eth_txconf) {
> ...
> .tx_rs_thresh = IXGBE_DEFAULT_TX_RSBIT_THRESH,
> ...
>   };
>   ...
> }
> 
> 
> uint16_t
> ixgbe_xmit_pkts_vec(void *tx_queue, struct rte_mbuf **tx_pkts,
>   uint16_t nb_pkts)
> {
>   ...
>   /* cross rx_thresh boundary is not allowed */
>   nb_pkts = RTE_MIN(nb_pkts, txq->tx_rs_thresh);
> 
>   if (txq->nb_tx_free < txq->tx_free_thresh)
> ixgbe_tx_free_bufs(txq);
> 
> 
>   nb_commit = nb_pkts = (uint16_t)RTE_MIN(txq->nb_tx_free, nb_pkts);
>   if (unlikely(nb_pkts == 0))
> return 0;
>   ...
>   return nb_pkts;
> }
> 
> ---
> 
> 
> 
> >> We propose to fix this by moving the tx buffer flushing logic from
> >> *after* the loop that puts all packets into the tx buffer, to *inside*
> >> the loop, testing for a full burst when adding 

[dpdk-dev] [PATCH v2] doc: fill nics features matrix for pcap

[Thomas Monjalon]

2016-04-11 09:52, Stephen Hemminger:
> I wonder if this matrix would be better if auto-generated some how.
> Either statically from source scan, or dynamically via simple app?

It would be a good exercise.
But I'm afraid the AI would be too complex to judge if the support is
enough to be valid (e.g. link speed capabilities for sub-devices,
support on architectures, content in the doc, etc).

[dpdk-dev] [PATCH] kni: fix vhost-kni compile errors

[Thomas Monjalon]

2016-04-11 17:54, Ferruh Yigit:
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,4,0)
> + (!test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, >sock->flags) &&
> +#else
>   (!test_and_set_bit(SOCK_ASYNC_NOSPACE, >sock->flags) &&
> +#endif

You could avoid some issues with backported feature by using
#ifdef SOCKWQ_ASYNC_NOSPACE

[dpdk-dev] [PATCH] kni: fix vhost-kni compile errors

[Ferruh Yigit]

On 4/11/2016 6:04 PM, Thomas Monjalon wrote:
> 2016-04-11 17:54, Ferruh Yigit:
>> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,4,0)
>> +(!test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, >sock->flags) &&
>> +#else
>>  (!test_and_set_bit(SOCK_ASYNC_NOSPACE, >sock->flags) &&
>> +#endif
> 
> You could avoid some issues with backported feature by using
> #ifdef SOCKWQ_ASYNC_NOSPACE
> 
Right, I am sending a new version.

Regards,
ferruh

[dpdk-dev] [PATCH] librte_port: fix the buffer overflow for ring writer

[Jasvinder Singh]

Fixes the buffer overflow that occurs due to following;

1. When the input packet burst does not meet the conditions: (a) being
contiguous (first n bits set in pkts_mask, all the other bits cleared)
and (b) containing a full burst, i.e. at least tx_burst_sz packets
(n >= tx_burst_size). This is the slow(er) code path taken when local
variable expr != 0.
2. There are some packets already in the buffer.
3. The number of packets in the incoming burst (i.e. popcount(pkts_mask))
plus the number of packets already in the buffer exceeds the buffer size
(RTE_PORT_IN_BURST_SIZE_MAX, i.e. 64).

Fixes: bf6931b242f7 ("port: ring")
Fixes: 5f4cd47309d6 ("port: add ring writer nodrop")

Signed-off-by: Jasvinder Singh 
Acked-by: Cristian Dumitrescu 
---
 lib/librte_port/rte_port_ring.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_port/rte_port_ring.c b/lib/librte_port/rte_port_ring.c
index d36e12d..3b9d3d0 100644
--- a/lib/librte_port/rte_port_ring.c
+++ b/lib/librte_port/rte_port_ring.c
@@ -179,7 +179,7 @@ rte_port_ring_reader_stats_read(void *port,
 struct rte_port_ring_writer {
struct rte_port_out_stats stats;

-   struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX];
+   struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX];
struct rte_ring *ring;
uint32_t tx_burst_sz;
uint32_t tx_buf_count;
@@ -447,7 +447,7 @@ rte_port_ring_writer_stats_read(void *port,
 struct rte_port_ring_writer_nodrop {
struct rte_port_out_stats stats;

-   struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX];
+   struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX];
struct rte_ring *ring;
uint32_t tx_burst_sz;
uint32_t tx_buf_count;
-- 
2.5.5

[dpdk-dev] [PATCH] librte_port: fix the bsz_mask variable type

[Jasvinder Singh]

Fixes the variable bsz_mask type form unit32_t to unit64_t

Fixes: 4d97e8b565cc ("port: ethdev")
Fixes: 304c8091e90a ("port: add ethdev writer nodrop")
Fixes: 8dceb6aa6ecf ("port: hierarchical scheduler")
Fixes: 3e5966837a09 ("port: new Tx burst implementation of ring writer")
Fixes: 5f4cd47309d6 ("port: add ring writer nodrop")

Signed-off-by: Jasvinder Singh 
Acked-by: Cristian Dumitrescu 
---
 lib/librte_port/rte_port_ethdev.c | 4 ++--
 lib/librte_port/rte_port_ring.c   | 4 ++--
 lib/librte_port/rte_port_sched.c  | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/librte_port/rte_port_ethdev.c 
b/lib/librte_port/rte_port_ethdev.c
index 1c34602..73e5f18 100644
--- a/lib/librte_port/rte_port_ethdev.c
+++ b/lib/librte_port/rte_port_ethdev.c
@@ -229,7 +229,7 @@ rte_port_ethdev_writer_tx_bulk(void *port,
 {
struct rte_port_ethdev_writer *p =
(struct rte_port_ethdev_writer *) port;
-   uint32_t bsz_mask = p->bsz_mask;
+   uint64_t bsz_mask = p->bsz_mask;
uint32_t tx_buf_count = p->tx_buf_count;
uint64_t expr = (pkts_mask & (pkts_mask + 1)) |
((pkts_mask & bsz_mask) ^ bsz_mask);
@@ -436,7 +436,7 @@ rte_port_ethdev_writer_nodrop_tx_bulk(void *port,
struct rte_port_ethdev_writer_nodrop *p =
(struct rte_port_ethdev_writer_nodrop *) port;

-   uint32_t bsz_mask = p->bsz_mask;
+   uint64_t bsz_mask = p->bsz_mask;
uint32_t tx_buf_count = p->tx_buf_count;
uint64_t expr = (pkts_mask & (pkts_mask + 1)) |
((pkts_mask & bsz_mask) ^ bsz_mask);
diff --git a/lib/librte_port/rte_port_ring.c b/lib/librte_port/rte_port_ring.c
index b847fea..d36e12d 100644
--- a/lib/librte_port/rte_port_ring.c
+++ b/lib/librte_port/rte_port_ring.c
@@ -300,7 +300,7 @@ rte_port_ring_writer_tx_bulk_internal(void *port,
struct rte_port_ring_writer *p =
(struct rte_port_ring_writer *) port;

-   uint32_t bsz_mask = p->bsz_mask;
+   uint64_t bsz_mask = p->bsz_mask;
uint32_t tx_buf_count = p->tx_buf_count;
uint64_t expr = (pkts_mask & (pkts_mask + 1)) |
((pkts_mask & bsz_mask) ^ bsz_mask);
@@ -614,7 +614,7 @@ rte_port_ring_writer_nodrop_tx_bulk_internal(void *port,
struct rte_port_ring_writer_nodrop *p =
(struct rte_port_ring_writer_nodrop *) port;

-   uint32_t bsz_mask = p->bsz_mask;
+   uint64_t bsz_mask = p->bsz_mask;
uint32_t tx_buf_count = p->tx_buf_count;
uint64_t expr = (pkts_mask & (pkts_mask + 1)) |
((pkts_mask & bsz_mask) ^ bsz_mask);
diff --git a/lib/librte_port/rte_port_sched.c b/lib/librte_port/rte_port_sched.c
index c5ff8ab..25217d6 100644
--- a/lib/librte_port/rte_port_sched.c
+++ b/lib/librte_port/rte_port_sched.c
@@ -214,7 +214,7 @@ rte_port_sched_writer_tx_bulk(void *port,
uint64_t pkts_mask)
 {
struct rte_port_sched_writer *p = (struct rte_port_sched_writer *) port;
-   uint32_t bsz_mask = p->bsz_mask;
+   uint64_t bsz_mask = p->bsz_mask;
uint32_t tx_buf_count = p->tx_buf_count;
uint64_t expr = (pkts_mask & (pkts_mask + 1)) |
((pkts_mask & bsz_mask) ^ bsz_mask);
-- 
2.5.5

[dpdk-dev] DPDK namespace

[Thomas Monjalon]

2016-04-11 16:10, Don Provan:
> I can't believe you guys are seriously considering changing the prefix from 
> rte_. That's a nightmare at the practical level, but it really doesn't make 
> as much sense as some of you seem to think. I've always been really impressed 
> that the names were prefixed with rte_ instead of dpdk_. While the primary 
> goal was to provide dataplane capabilities, so much of the library -- 
> mempools and rings, for example -- is general purpose, so a dpdk_ prefix 
> wouldn't be appropriate for those routines, anyway.
> 
> The idea that everything in the library should be named "dpdk" is the same 
> thinking that leads to the monolithic initialization function I've complained 
> about before. I have major applications that use the DPDK library but do 
> nothing at all with hardware, yet the library still insists on initializing 
> the PCI components because there's no concept of using the library for 
> anything other than receiving packets from hardware.

It's good news to hear that DPDK allows you to develop major applications.
The BSD license allows to build a lot of various types of applications.
You are perfectly right to give your opinion and complain.
You would also be welcome to contribute and fix your concerns.

[dpdk-dev] [PATCH v3] examples/vm_power_manager: fix build with libvirt version < 0.9.3

[Marvin Liu]

vm_power_manager utilize libvirt API virDomainGetVcpuPinInfo for
retrieve domU vcpu information. This API implemented from version 0.9.3.
Suse11 SP3 32bit default libvirt version is 0.8.8, so there'll be build
error. Add judgement in sample Makefile to alarm unsupport environment.

examples/vm_power_manager/channel_manager.c: In function
?update_pcpus_mask?:
channel_manager.c:117:3: error: implicit declaration of function
?virDomainGetVcpuPinInfo?

Fixes: 8db653ff7889 ("vm power management application")

Signed-off-by: Marvin Liu 

diff --git a/examples/Makefile b/examples/Makefile
index a8bc381..027ee57 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -87,6 +87,10 @@ DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost
 DIRS-$(CONFIG_RTE_LIBRTE_XEN_DOM0) += vhost_xen
 DIRS-y += vmdq
 DIRS-y += vmdq_dcb
+ifeq ($(shell pkg-config --atleast-version=0.9.3 libvirt; echo $$?), 0)
 DIRS-$(CONFIG_RTE_LIBRTE_POWER) += vm_power_manager
+else
+$(warning "vm_power_manager requires libvirt version >= 0.9.3")
+endif

 include $(RTE_SDK)/mk/rte.extsubdir.mk
-- 
1.9.3

[dpdk-dev] [PATCH] app/testpmd: fix strcat can overrun fixed-size string

[Tomasz Kulasek]

CID 13307 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
fixed_size_dest: You might overrun the 128 byte fixed-size string fwd_modes
by copying fwd_eng->fwd_mode_name without checking the length.

Fixes: 769ce6b17835 ("app/testpmd: list forwarding engines")

Signed-off-by: Tomasz Kulasek 
---
 app/test-pmd/config.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index b1bbec6..fff2d96 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1673,8 +1673,10 @@ list_pkt_forwarding_modes(void)

if (strlen (fwd_modes) == 0) {
while ((fwd_eng = fwd_engines[i++]) != NULL) {
-   strcat(fwd_modes, fwd_eng->fwd_mode_name);
-   strcat(fwd_modes, separator);
+   strncat(fwd_modes, fwd_eng->fwd_mode_name, 
sizeof(fwd_modes) -
+   strlen(fwd_modes) - 1);
+   strncat(fwd_modes, separator, sizeof(fwd_modes) - 
strlen(fwd_modes)
+   - 1);
}
fwd_modes[strlen(fwd_modes) - strlen(separator)] = '\0';
}
-- 
1.7.9.5

[dpdk-dev] [PATCH] kni: fix vhost-kni compile errors

[Ferruh Yigit]

fix vhost-kni compile errors because of Linux kernel API changes

- SOCK_ASYNC_WAITDATA renamed to SOCKWQ_ASYNC_WAITDATA
  Linux commit id: 9cd3e072
  Updated in Linux kernel 4.4

- sk_alloc() gets new parameter
  Linux commit id: 11aa9c28b
  Updated in Linux kernel 4.2
  New parameter is: "@kern: is this to be a kernel socket?"

Reported-by: chintu hetam 
Signed-off-by: Ferruh Yigit 

---

Patch not tested, just fixed compiler errors.
---
 lib/librte_eal/linuxapp/kni/kni_vhost.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/kni_vhost.c 
b/lib/librte_eal/linuxapp/kni/kni_vhost.c
index 6f2a961..482b384 100644
--- a/lib/librte_eal/linuxapp/kni/kni_vhost.c
+++ b/lib/librte_eal/linuxapp/kni/kni_vhost.c
@@ -251,7 +251,11 @@ kni_sock_poll(struct file *file, struct socket *sock, 
poll_table * wait)
mask |= POLLIN | POLLRDNORM;

if (sock_writeable(>sk) ||
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,4,0)
+   (!test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, >sock->flags) &&
+#else
(!test_and_set_bit(SOCK_ASYNC_NOSPACE, >sock->flags) &&
+#endif
 sock_writeable(>sk)))
mask |= POLLOUT | POLLWRNORM;

@@ -619,8 +623,11 @@ kni_sk_write_space(struct sock *sk)
wait_queue_head_t *wqueue;

if (!sock_writeable(sk) ||
-   !test_and_clear_bit(SOCK_ASYNC_NOSPACE,
-   >sk_socket->flags))
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,4,0)
+   !test_and_clear_bit(SOCKWQ_ASYNC_NOSPACE, >sk_socket->flags))
+#else
+   !test_and_clear_bit(SOCK_ASYNC_NOSPACE, >sk_socket->flags))
+#endif
return;
wqueue = sk_sleep(sk);
if (wqueue && waitqueue_active(wqueue))
@@ -666,8 +673,14 @@ kni_vhost_backend_init(struct kni_dev *kni)
if (kni->vhost_queue != NULL)
return -1;

-   if (!(q = (struct kni_vhost_queue *)sk_alloc(
- net, AF_UNSPEC, GFP_KERNEL, _raw_proto)))
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,2,0)
+   q = (struct kni_vhost_queue *)sk_alloc(net, AF_UNSPEC, GFP_KERNEL,
+   _raw_proto, 0);
+#else
+   q = (struct kni_vhost_queue *)sk_alloc(net, AF_UNSPEC, GFP_KERNEL,
+   _raw_proto);
+#endif
+   if (!q)
return -ENOMEM;

err = sock_create_lite(AF_UNSPEC, SOCK_RAW, IPPROTO_RAW, >sock);
-- 
2.5.5

[dpdk-dev] [PATCH v2] scripts: check commit formatting

[Thomas Monjalon]

The git messages have three parts:
1/ the headline
2/ the explanations
3/ the footer tags

The headline helps to quickly browse an history or catch instantly the
purpose of a commit. Making it short with some consistent wording
allows to easily parse it or match some patterns.

The explanations must give some keys like the reason of the change.
Nothing can be automatically checked for this part, except line length.

The footer contains some tags to find the origin of a bug or who
was working on it.

This script is doing some basic checks mostly on parts 1 and 3.

Signed-off-by: Thomas Monjalon 
---
 MAINTAINERS |   1 +
 doc/guides/contributing/patches.rst |   8 +++
 scripts/check-git-log.sh| 140 
 3 files changed, 149 insertions(+)
 create mode 100755 scripts/check-git-log.sh

v2:
- accept not only 12 long hash in Fixes:
- check line length
- add doc

diff --git a/MAINTAINERS b/MAINTAINERS
index f213500..1953ea2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25,6 +25,7 @@ M: Thomas Monjalon 
 T: git://dpdk.org/dpdk
 F: MAINTAINERS
 F: scripts/check-maintainers.sh
+F: scripts/check-git-log.sh
 F: scripts/checkpatches.sh
 F: scripts/load-devel-config.sh
 F: scripts/test-build.sh
diff --git a/doc/guides/contributing/patches.rst 
b/doc/guides/contributing/patches.rst
index 3ebe95b..06af91d 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -258,6 +258,14 @@ Where:
 * ``-v``: verbose.
 * ``patchX``: path to one or more patches.

+Then the git logs should be checked using the ``check-git-log.sh`` script.
+
+The script usage is::
+
+   check-git-log.sh [range]
+
+Where the range is a ``git log`` option.
+

 .. _contrib_check_compilation:

diff --git a/scripts/check-git-log.sh b/scripts/check-git-log.sh
new file mode 100755
index 000..ce6c15e
--- /dev/null
+++ b/scripts/check-git-log.sh
@@ -0,0 +1,140 @@
+#! /bin/sh
+
+# BSD LICENSE
+#
+# Copyright 2016 6WIND S.A.
+#
+# 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 6WIND S.A. 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.
+
+# Check commit logs (headlines and references)
+#
+# If any doubt about the formatting, please check in the most recent history:
+#  git log --format='%>|(15)%cr   %s' --reverse | grep -i 
+
+if [ "$1" = '-h' -o "$1" = '--help' ] ; then
+   cat <<- END_OF_HELP
+   usage: $(basename $0) [-h] [range]
+
+   Check commit log formatting.
+   The git range can be specified as a "git log" option,
+   e.g. -1 to check only the latest commit.
+   The default range starts from origin/master to HEAD.
+   END_OF_HELP
+   exit
+fi
+
+range=${1:-origin/master..}
+
+headlines=$(git log --format='%s' $range)
+bodylines=$(git log --format='%b' $range)
+tags=$(git log --format='%b' $range | grep -i -e 'by *:' -e 'fix.*:')
+fixes=$(git log --format='%h %s' $range | grep -i ': *fix' | cut -d' ' -f1)
+
+# check headline format (spacing, no punctuation, no code)
+bad=$(echo "$headlines" | grep \
+   -e '' \
+   -e '^ ' \
+   -e ' $' \
+   -e '\.$' \
+   -e '[,;!?&|]' \
+   -e ':.*_' \
+   -e '^[^:]*$' \
+   -e ':[^ ]' \
+   -e ' :' \
+   | sed 's,^,\t,')
+[ -z "$bad" ] || printf "Wrong headline format:\n$bad\n"
+
+# check headline label for common typos
+bad=$(echo "$headlines" | grep \
+   -e '^example[:/]' \
+   -e '^apps/' \
+   -e '^testpmd' \
+   -e 'test-pmd' \
+   -e '^bond:' \
+   | sed 's,^,\t,')
+[ -z "$bad" ] || printf "Wrong headline label:\n$bad\n"
+

[dpdk-dev] DPDK libraries not compiling from source

[Subbu CS]

Hi all,

I tried compiling DPDK from source using setup.sh script in tools
directory, but I get this error

[32] Remove KNI module
[33] Remove hugepage mappings

[34] Exit Script

Option: 14

/bin/sh: line 1: cc: command not found
cp: cannot stat
?/root/workspace/dpdk/x86_64-native-linuxapp-gcc/.config_tmp?: No such file
or directory
cp: cannot stat
?/root/workspace/dpdk/x86_64-native-linuxapp-gcc/.config_tmp?: No such file
or directory
make[5]: Nothing to be done for `depdirs'.
Configuration done
/root/workspace/dpdk/mk/rte.vars.mk:81: *** RTE_ARCH is not defined.  Stop.
make[2]: *** [all] Error 2
make[1]: *** [pre_install] Error 2
make: *** [install] Error 2
--
 RTE_TARGET exported as x86_64-native-linuxapp-gcc
--

Then, I set RTE_ARCH=x86_64 manually, but it did not work

please suggest appropriate way to compile DPDK libraries.

[dpdk-dev] [PATCH v2] examples/vm_power_manager: fix build with libvirt version < 0.9.3

[Marvin Liu]

vm_power_manager utilize libvirt API virDomainGetVcpuPinInfo for
retrieve domU vcpu information. This API implemented from version 0.9.3.
Suse11 SP3 32bit default libvirt version is 0.8.8, so there'll be build
error. Add judgement in sample Makefile to skip unsupport environment.

examples/vm_power_manager/channel_manager.c: In function
?update_pcpus_mask?:
channel_manager.c:117:3: error: implicit declaration of function
?virDomainGetVcpuPinInfo?

Fixes: 2e099bc5d104 ("fix split of compiler and linker options")

Signed-off-by: Marvin Liu 

diff --git a/examples/vm_power_manager/Makefile 
b/examples/vm_power_manager/Makefile
index 113dbc4..08e301f 100644
--- a/examples/vm_power_manager/Makefile
+++ b/examples/vm_power_manager/Makefile
@@ -36,6 +36,9 @@ endif
 # Default target, can be overridden by command line or environment
 RTE_TARGET ?= x86_64-native-linuxapp-gcc

+# check libvirt version >= 0.9.3
+ifeq ($(shell pkg-config --atleast-version=0.9.3 libvirt; echo $$?), 0)
+
 include $(RTE_SDK)/mk/rte.vars.mk

 # binary name
@@ -57,3 +60,10 @@ CFLAGS_main.o += -Wno-return-type
 endif

 include $(RTE_SDK)/mk/rte.extapp.mk
+
+else
+.PHONY: all clean
+all:
+$(info "vm_power_manager required libvirt version >= 0.9.3, please update 
libvirt-devel first")
+clean:
+endif
-- 
1.9.3

[dpdk-dev] [PATCH v2] testpmd: avoid only working in XEN when LIBRTE_PMD_XENVIRT is configured

[Thomas Monjalon]

2016-03-17 15:47, Christian Ehrhardt:
> With LIBRTE_PMD_XENVIRT enabled testpmd is built in a way to ONLY work
> in XEN environments.
> It will surface as:
>PMD: gntalloc: ioctl error
>EAL: Error - exiting with code: 1
>  Cause: Creation of mbuf pool for socket 0 failed
> 
> With LIBRTE_PMD_XENVIRT enabled this now tries the xen style grant
> table allocation, but falls back gracefully for the normal allocation.
> 
> The only thing left in the log will be the
>PMD: gntalloc: ioctl error
> 
> Updates in v2
> - adding missing Signed-off-by and set Pablo on --to with the patch directly
> 
> Signed-off-by: Christian Ehrhardt 

Sorry this patch has been forgotten because (wrongly?) superseded in patchwork.
Please do not hesitate to ping when your patch has no follow-up.
Thanks Olivier for reminding this patch.

Applied, thanks

[dpdk-dev] [PATCH] lib: fix DCB config issue on ixgbe

[Wenzhuo Lu]

An issue is found that DCB cannot be configged 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. The API rte_eth_dev_configure
should be used to config this mode. But the input of this
API includes TX queue number. The problem is before the
mode is configged, we cannot decide the TX queue number.

This patch adds an API to config RX & TX multi-queue mode
separately. After the mode is configged, the max RX & TX
queue number is decided. Then we can set the appropriate
RX & TX queue number.

Fixes: 96c0450dff86 (ixgbe: fix dropping packets from unsupported Tx queues)
Signed-off-by: Wenzhuo Lu 
---
 app/test-pmd/testpmd.c | 40 +++---
 lib/librte_ether/rte_ethdev.c  | 17 +++
 lib/librte_ether/rte_ethdev.h  | 19 
 lib/librte_ether/rte_ether_version.map |  1 +
 4 files changed, 59 insertions(+), 18 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 1398c6c..c726e1c 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1925,17 +1925,31 @@ 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;
+
+   rte_eth_dev_mq_mode_set(pid,
+   port_conf.rxmode.mq_mode,
+   port_conf.txmode.mq_mode);
+   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;
@@ -1945,13 +1959,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;
@@ -1960,16 +1974,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);
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a31018e..b4eaa29 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3369,3 +3369,20 @@ rte_eth_dev_l2_tunnel_offload_set(uint8_t port_id,
-ENOTSUP);
return (*dev->dev_ops->l2_tunnel_offload_set)(dev, l2_tunnel, mask, en);
 }
+
+int
+rte_eth_dev_mq_mode_set(uint8_t port_id,
+   enum rte_eth_rx_mq_mode rx_mq_mode,
+   enum rte_eth_tx_mq_mode tx_mq_mode)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+   dev = _eth_devices[port_id];
+
+   dev->data->dev_conf.rxmode.mq_mode = rx_mq_mode;
+   dev->data->dev_conf.txmode.mq_mode = tx_mq_mode;
+
+   return 0;
+}
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 022733e..852acca 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -4279,6 +4279,25 @@ 

[dpdk-dev] DPDK namespace

[Don Provan]

I can't believe you guys are seriously considering changing the prefix from 
rte_. That's a nightmare at the practical level, but it really doesn't make as 
much sense as some of you seem to think. I've always been really impressed that 
the names were prefixed with rte_ instead of dpdk_. While the primary goal was 
to provide dataplane capabilities, so much of the library -- mempools and 
rings, for example -- is general purpose, so a dpdk_ prefix wouldn't be 
appropriate for those routines, anyway.

The idea that everything in the library should be named "dpdk" is the same 
thinking that leads to the monolithic initialization function I've complained 
about before. I have major applications that use the DPDK library but do 
nothing at all with hardware, yet the library still insists on initializing the 
PCI components because there's no concept of using the library for anything 
other than receiving packets from hardware.

-don provan
dprovan at bivio.net

[dpdk-dev] [PATCH v2] doc: add section on tested platforms and nics

[Thomas Monjalon]

> > Add a new section on tested platforms and nics to the release notes.
> > 
> > Signed-off-by: Qian Xu 
> > Signed-off-by: John McNamara 
> 
> Acked-by: Pablo de Lara 

Applied, thanks

[dpdk-dev] DPDK 2.2 build failing with vhost-kni

[chintu hetam]

thanks ferruh yigit!!

cheers

On Mon, Apr 11, 2016 at 2:57 PM, chintu hetam  wrote:

> I tried vhost-user mode, and during init of ./vhost-switch it fails
> with
> PMD: eth_ixgbe_dev_init(): port 0 vendorID=0x8086 deviceID=0x1528
> pf queue num: 0, configured vmdq pool num: 64, each vmdq pool has 2 queues
> EAL: Error - exiting with code: 1
>   Cause: Cannot initialize network ports
>
> it's failing in port_init function, and it seems from
> http://dpdk.org/doc/guides-1.8/rel_notes/resolved_issues.html
>
> this has to with ixgbe checking for eeprom pba parameters. is that
> correct, coz rebuilding ixgbe 4.3.13 by disabling those lines dint help
> either?
>
> i tried enabling configure
> CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y
>  but still i don't see the log messages under /var/log nor on stdout?
>
> just to keep ball rolling i'd like to see at least kni compiling and
> working.
>
> FYI, i am using X540-AT2
>
> cheers
>
> On Mon, Apr 11, 2016 at 10:09 AM, chintu hetam 
> wrote:
>
>> Thanks Xie.
>>
>> I am trying to test FreeBSD-9.3-virtio as guest. Somewhere in the forum i
>> found virtio-kni combination reaching around 2.7 Gbps performance, which is
>> enough for my test, though i dint find equivalent driver performance
>> characterization for qemu-vhost user space combination.
>> Also, as per nics-2.2 user guide, "Linux kernel with KVM module; vhost
>> module loaded and ioeventfd supported. Qemu standard backend without vhost
>> support isn?t tested, and probably isn?t supported",which is bit different
>> from vhost user space support,but still..
>>
>> Just to be sure vhost user space = qemu virtio backend- tap-linux-bridge
>> configuration, as per nics guide, right?
>>
>> Thanking in advance, again.
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Apr 11, 2016 at 4:25 AM, Xie, Huawei 
>> wrote:
>>
>>> On 4/10/2016 7:26 AM, chintu hetam wrote:
>>> > I am compiling DPDK 2.2 on Fedora 23 and i am seeing following build
>>> error
>>> >
>>> /home/vcr/devel/dpdk/dpdk-2.2.0/build/build/lib/librte_eal/linuxapp/kni/kni_vhost.c:
>>> > In function ?kni_sock_poll?:
>>> >
>>> /home/vcr/devel/dpdk/dpdk-2.2.0/build/build/lib/librte_eal/linuxapp/kni/kni_vhost.c:254:25:
>>> > error: ?SOCK_ASYNC_NOSPACE? undeclared (first use in this function)
>>> >   (!test_and_set_bit(SOCK_ASYNC_NOSPACE, >sock->flags) &&
>>> >  ^
>>>
>>> Hi, besides the issue, now user space vhost is the preferred way to
>>> switch packets with the virtual machine, and we have plans to remove kni
>>> vhost support. Do you have any reason to use kni vhost?
>>>
>>
>>
>

[dpdk-dev] [PATCH v5] examples/vm_power_manager: fix libvirt dependency check

[Thomas Monjalon]

> vm_power_manager utilize libvirt API virDomainGetVcpuPinInfo to
> retrieve domU vcpu information. This API is implemented from version 0.9.3.
> Suse11 SP3 32bit default libvirt version is 0.8.8.
> 
> examples/vm_power_manager/channel_manager.c:
> channel_manager.c:117:3: error: implicit declaration of function
> 'virDomainGetVcpuPinInfo'
> 
> Check and skip it from examples or raise an error when trying to compile
> without libvirt or with a too old libvirt.
> 
> Fixes: e8ae9b662 ("examples/vm_power: channel manager and monitor in host")
> 
> Signed-off-by: Marvin Liu 
> Signed-off-by: Thomas Monjalon 
> Acked-by: Bruce Richardson 

Applied

[dpdk-dev] DPDK libraries not compiling from source

[Wiles, Keith]

>Hi all,
>
>I tried compiling DPDK from source using setup.sh script in tools
>directory, but I get this error
>
>[32] Remove KNI module
>[33] Remove hugepage mappings
>
>[34] Exit Script

The way I compile DPDK is this way:

# cd 
# export RTE_SDK=`pwd`
# export RTE_TARGET=x86_64-native-linuxapp-gcc
# make install T=x86_64-native-linuxapp-gcc

Strictly speaking you do not need to set the two variables, but you do need 
them later for building examples or say pktgen-dpdk.
The last command will give an warning about not being able to install, but that 
is OK unless you need the files installed. Installing the files are not 
required if you use the environment variables.

Hope that gets you started. The only concern is the ?cc? command not found, 
which makes me believe you do not have a compiler installed. The Docs do talk 
about how to install the basic required tools for ubuntu, which is what I am 
using for the above commands. After getting DPDK to build you need to setup the 
rest of the system to run DPDK and that is all covered in the Docs.

>
>Option: 14
>
>/bin/sh: line 1: cc: command not found
>cp: cannot stat
>?/root/workspace/dpdk/x86_64-native-linuxapp-gcc/.config_tmp?: No such file
>or directory
>cp: cannot stat
>?/root/workspace/dpdk/x86_64-native-linuxapp-gcc/.config_tmp?: No such file
>or directory
>make[5]: Nothing to be done for `depdirs'.
>Configuration done
>/root/workspace/dpdk/mk/rte.vars.mk:81: *** RTE_ARCH is not defined.  Stop.
>make[2]: *** [all] Error 2
>make[1]: *** [pre_install] Error 2
>make: *** [install] Error 2
>--
> RTE_TARGET exported as x86_64-native-linuxapp-gcc
>--
>
>Then, I set RTE_ARCH=x86_64 manually, but it did not work
>
>please suggest appropriate way to compile DPDK libraries.
>


Regards,
Keith

[dpdk-dev] [RFC] vhost user: add error handling for fd > 1023

[Patrik Andersson R]

Yes, that is correct. Closing the socket on failure needs to be added.

Regards,

Patrik



On 04/11/2016 11:34 AM, Christian Ehrhardt wrote:
> I like the approach as well to go for the fix for robustness first.
>
> I was accidentally able to find another testcase to hit the same root 
> cause.
> Adding guests with 15 vhost_user based NICs each while having rxq for 
> openvswitch-dpdk set to 4 and multiqueue for the guest devices at 4 
> already breaks when adding the thirds such guests.
> That is way earlier than I would have expected the fd's to be 
> exhausted but still the same root cause, so just another test for the 
> same.
>
> In prep to the wider check to the patch a minor review question from me:
> On the section of rte_vhost_driver_register that now detects if there 
> were issues we might want to close the socketfd as well when bailing out.
> Otherwise we would just have another source of fd leaks or would that 
> be reused later on even now that we have freed vserver-path and 
> vserver itself?
>
>ret = fdset_add(_vhost_server.fdset, vserver->listenfd,
>  vserver_new_vq_conn, NULL, vserver);
>if (ret < 0) {
>  pthread_mutex_unlock(_vhost_server.server_mutex);
>  RTE_LOG(ERR, VHOST_CONFIG,
>"failed to add listen fd %d to vhost server fdset\n",
>vserver->listenfd);
>  free(vserver->path);
> +  close(vserver->listenfd);
>  free(vserver);
>return -1;
>}
>
>
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>
> On Mon, Apr 11, 2016 at 8:06 AM, Patrik Andersson R 
>  > wrote:
>
> I fully agree with this course of action.
>
> Thank you,
>
> Patrik
>
>
>
> On 04/08/2016 08:47 AM, Xie, Huawei wrote:
>
> On 4/7/2016 10:52 PM, Christian Ehrhardt wrote:
>
> I totally agree to that there is no deterministic rule
> what to expect.
> The only rule is that #fd certainly always is >
> #vhost_user devices.
> In various setup variants I've crossed fd 1024 anywhere
> between 475
> and 970 vhost_user ports.
>
> Once the discussion continues and we have an updates
> version of the
> patch with some more agreement I hope I can help to test it.
>
> Thanks. Let us first temporarily fix this problem for
> robustness, then
> we consider whether upgrade to (e)poll.
> Will check the patch in detail later. Basically it should work
> but need
> check whether we need extra fixes elsewhere.
>
>
>

[dpdk-dev] librte_table build race with SYMLINK-FILE?

[Simon Kågström]

Hi!

I'm upgrading from DPDK 2.1 to 16.04-rc4, and have a new build issue
which I didn't see before. It's in the librte_table and happens from
time to time (unfrequently) in my out-of-tree build. It looks like a
race between comilation and SYMLINK-FILE:

[...]
== Build lib/librte_table
  CC rte_table_lpm_ipv6.o
  CC rte_table_lpm.o
  CC rte_table_acl.o
  CC rte_table_hash_key8.o
In file included from [...]lib/librte_table/rte_table_lpm.c:43:0:
[...]/dpdk.build/include/rte_lpm.h:484:25: fatal error: rte_lpm_sse.h:
No such file or directory
 #include "rte_lpm_sse.h"
 ^
compilation terminated.
  CC rte_table_hash_key16.o
[...]

In this case, rte_lpm_sse.h is optionally symlinked if we're not on ARM.
I've tried patching away the issue by unconditionally symlinking the
_{neon,sse}.h files, and while I don't see the problem after that, I
don't really see why it would improve the situation.

Does anyone else see this as well?

// Simon

[dpdk-dev] [PATCH v5] examples/vm_power_manager: fix libvirt dependency check

[Thomas Monjalon]

From: Marvin Liu 

vm_power_manager utilize libvirt API virDomainGetVcpuPinInfo to
retrieve domU vcpu information. This API is implemented from version 0.9.3.
Suse11 SP3 32bit default libvirt version is 0.8.8.

examples/vm_power_manager/channel_manager.c:
channel_manager.c:117:3: error: implicit declaration of function
'virDomainGetVcpuPinInfo'

Check and skip it from examples or raise an error when trying to compile
without libvirt or with a too old libvirt.

Fixes: e8ae9b662 ("examples/vm_power: channel manager and monitor in host")

Signed-off-by: Marvin Liu 
Signed-off-by: Thomas Monjalon 
Acked-by: Bruce Richardson 
---
 examples/Makefile  | 8 +++-
 examples/vm_power_manager/Makefile | 6 ++
 2 files changed, 13 insertions(+), 1 deletion(-)

v5: do not warn if CONFIG_RTE_LIBRTE_POWER is disabled

v4: mix v2 and v3 to skip in examples list but raise an error if trying
to compile directly

diff --git a/examples/Makefile b/examples/Makefile
index a8bc381..b28b30e 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -87,6 +87,12 @@ DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost
 DIRS-$(CONFIG_RTE_LIBRTE_XEN_DOM0) += vhost_xen
 DIRS-y += vmdq
 DIRS-y += vmdq_dcb
-DIRS-$(CONFIG_RTE_LIBRTE_POWER) += vm_power_manager
+ifeq ($(CONFIG_RTE_LIBRTE_POWER), y)
+ifeq ($(shell pkg-config --atleast-version=0.9.3 libvirt; echo $$?), 0)
+DIRS-y += vm_power_manager
+else
+$(info vm_power_manager requires libvirt >= 0.9.3)
+endif
+endif

 include $(RTE_SDK)/mk/rte.extsubdir.mk
diff --git a/examples/vm_power_manager/Makefile 
b/examples/vm_power_manager/Makefile
index 113dbc4..59a9641 100644
--- a/examples/vm_power_manager/Makefile
+++ b/examples/vm_power_manager/Makefile
@@ -29,6 +29,10 @@
 #   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 #   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

+ifneq ($(shell pkg-config --atleast-version=0.9.3 libvirt; echo $$?), 0)
+$(error vm_power_manager requires libvirt >= 0.9.3)
+else
+
 ifeq ($(RTE_SDK),)
 $(error "Please define RTE_SDK environment variable")
 endif
@@ -57,3 +61,5 @@ CFLAGS_main.o += -Wno-return-type
 endif

 include $(RTE_SDK)/mk/rte.extapp.mk
+
+endif # libvirt check
-- 
2.7.0

[dpdk-dev] [PATCH v4] examples/vm_power_manager: fix libvirt dependency check

[Thomas Monjalon]

From: Marvin Liu 

vm_power_manager utilize libvirt API virDomainGetVcpuPinInfo to
retrieve domU vcpu information. This API is implemented from version 0.9.3.
Suse11 SP3 32bit default libvirt version is 0.8.8.

examples/vm_power_manager/channel_manager.c:
channel_manager.c:117:3: error: implicit declaration of function
?virDomainGetVcpuPinInfo?

Check and skip it from examples or raise an error when trying to compile
without libvirt or with a too old libvirt.

Fixes: e8ae9b662 ("examples/vm_power: channel manager and monitor in host")

Signed-off-by: Marvin Liu 
Signed-off-by: Thomas Monjalon 
---
 examples/Makefile  | 4 
 examples/vm_power_manager/Makefile | 6 ++
 2 files changed, 10 insertions(+)

v4: mix v2 and v3 to skip in examples list but raise an error if trying
to compile directly

diff --git a/examples/Makefile b/examples/Makefile
index a8bc381..fcf1eb7 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -87,6 +87,10 @@ DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost
 DIRS-$(CONFIG_RTE_LIBRTE_XEN_DOM0) += vhost_xen
 DIRS-y += vmdq
 DIRS-y += vmdq_dcb
+ifeq ($(shell pkg-config --atleast-version=0.9.3 libvirt; echo $$?), 0)
 DIRS-$(CONFIG_RTE_LIBRTE_POWER) += vm_power_manager
+else
+$(info vm_power_manager requires libvirt >= 0.9.3)
+endif

 include $(RTE_SDK)/mk/rte.extsubdir.mk
diff --git a/examples/vm_power_manager/Makefile 
b/examples/vm_power_manager/Makefile
index 113dbc4..59a9641 100644
--- a/examples/vm_power_manager/Makefile
+++ b/examples/vm_power_manager/Makefile
@@ -29,6 +29,10 @@
 #   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 #   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

+ifneq ($(shell pkg-config --atleast-version=0.9.3 libvirt; echo $$?), 0)
+$(error vm_power_manager requires libvirt >= 0.9.3)
+else
+
 ifeq ($(RTE_SDK),)
 $(error "Please define RTE_SDK environment variable")
 endif
@@ -57,3 +61,5 @@ CFLAGS_main.o += -Wno-return-type
 endif

 include $(RTE_SDK)/mk/rte.extapp.mk
+
+endif # libvirt check
-- 
2.7.0

[dpdk-dev] [PATCH] autotests: fix mempool element size in func_reentrancy

[Olivier Matz]

On 04/11/2016 12:12 PM, Thomas Monjalon wrote:
> 2016-04-11 11:33, Olivier Matz:
>> --- a/app/test/test_func_reentrancy.c
>> +++ b/app/test/test_func_reentrancy.c
>> @@ -78,7 +78,7 @@ typedef void (*case_clean_t)(unsigned lcore_id);
>>  #define MAX_ITER_TIMES  (16)
>>  #define MAX_LPM_ITER_TIMES  (8)
>>  
>> -#define MEMPOOL_ELT_SIZE(0)
>> +#define MEMPOOL_ELT_SIZE(sizeof(uint32))
> 
> I understand the idea of the patch.
> Using uint32_t would probably make a good fix ;)
> Applied correctly, thanks

You perfectly got the idea :)
Thanks and sorry for the typo...

[dpdk-dev] [PATCH] autotests: fix mempool element size in func_reentrancy

[Thomas Monjalon]

2016-04-11 11:33, Olivier Matz:
> --- a/app/test/test_func_reentrancy.c
> +++ b/app/test/test_func_reentrancy.c
> @@ -78,7 +78,7 @@ typedef void (*case_clean_t)(unsigned lcore_id);
>  #define MAX_ITER_TIMES  (16)
>  #define MAX_LPM_ITER_TIMES  (8)
>  
> -#define MEMPOOL_ELT_SIZE(0)
> +#define MEMPOOL_ELT_SIZE(sizeof(uint32))

I understand the idea of the patch.
Using uint32_t would probably make a good fix ;)
Applied correctly, thanks

[dpdk-dev] [PATCH] scripts: check commit formatting

[Thomas Monjalon]

2016-03-30 15:27, Bruce Richardson:
> On Wed, Mar 30, 2016 at 09:46:34AM +0800, Yuanhan Liu wrote:
> > On Tue, Mar 29, 2016 at 11:29:46PM +0200, Thomas Monjalon wrote:
> > > The git messages have three parts:
> > > 1/ the headline
> > > 2/ the explanations
> > > 3/ the footer tags
> > > 
> > > The headline helps to quickly browse an history or catch instantly the
> > > purpose of a commit. Making it short with some consistent wording
> > > allows to easily parse it or match some patterns.
> > > 
> > > The explanations must give some keys like the reason of the change.
> > > Nothing can be automatically checked for this part.
> > 
> > Actually, I think we might be able to do 2 tests here:
> > 
> > - space line between paragraphs.
> > 
> > - lines over 80 chars.
> 
> 75 chars for commit messages, and 50 for commit titles :-)

The 75 chars limit is already checked by checkpatch.pl.
But yes we can have our own check in this script.

For the title, I think we can accept 60 chars and exceptionnaly more.

To see the history of title length:
git log --format='%s' |
awk '{lens[length($0)]++;} END {for (len in lens) print len, lens[len] 
}' |
sort -g

[dpdk-dev] [PATCH] lib: fix DCB config issue on ixgbe

[Thomas Monjalon]

2016-04-11 16:24, Wenzhuo Lu:
> An issue is found that DCB cannot be configged 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. The API rte_eth_dev_configure
> should be used to config this mode. But the input of this
> API includes TX queue number. The problem is before the
> mode is configged, we cannot decide the TX queue number.
> 
> This patch adds an API to config RX & TX multi-queue mode
> separately. After the mode is configged, the max RX & TX
> queue number is decided. Then we can set the appropriate
> RX & TX queue number.
> 
> Fixes: 96c0450dff86 (ixgbe: fix dropping packets from unsupported Tx queues)
> Signed-off-by: Wenzhuo Lu 
> ---
>  app/test-pmd/testpmd.c | 40 
> +++---
>  lib/librte_ether/rte_ethdev.c  | 17 +++
>  lib/librte_ether/rte_ethdev.h  | 19 
>  lib/librte_ether/rte_ether_version.map |  1 +
>  4 files changed, 59 insertions(+), 18 deletions(-)

Obviously, it will be considered for 16.07.

[dpdk-dev] [PATCH] eal: fix resource leak

[Daniel Mrzyglod]

CID 13289 (#1-2 of 2): Resource leak (RESOURCE_LEAK):
The system resource will not be reclaimed and reused, reducing the future 
availability of the resource.
In pci_vfio_get_group_fd: Leak of memory or pointers to system resources

Fixes: ff0b67d1c868 ("vfio: DMA mapping")

Signed-off-by: Daniel Mrzyglod 
---
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c 
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index fdfdeb4..10266f8 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -535,6 +535,7 @@ pci_vfio_get_group_fd(int iommu_group_no)
/* if the fd is valid, create a new group for it */
if (vfio_cfg.vfio_group_idx == VFIO_MAX_GROUPS) {
RTE_LOG(ERR, EAL, "Maximum number of VFIO groups 
reached!\n");
+   close(vfio_group_fd);
return -1;
}
vfio_cfg.vfio_groups[vfio_cfg.vfio_group_idx].group_no = 
iommu_group_no;
-- 
2.5.5

[dpdk-dev] [PATCH] examples/vm_power_manager: fix build with libvirt version < 0.9.3

[Marvin Liu]

vm_power_manager utilize libvirt API virDomainGetVcpuPinInfo for
retrieve domU vcpu information. This API implemented from version 0.9.3.
Suse11 SP3 32bit default libvirt version is 0.8.8, so there'll be build
error. Add judgement in sample Makefile to skip unsupport environment.

examples/vm_power_manager/channel_manager.c: In function
?update_pcpus_mask?:
channel_manager.c:117:3: error: implicit declaration of function
?virDomainGetVcpuPinInfo?

Fixes: 2e099bc5d104 ("fix split of compiler and linker options")

Signed-off-by: Marvin Liu 

diff --git a/examples/vm_power_manager/Makefile 
b/examples/vm_power_manager/Makefile
index 113dbc4..49a6b9b 100644
--- a/examples/vm_power_manager/Makefile
+++ b/examples/vm_power_manager/Makefile
@@ -33,9 +33,19 @@ ifeq ($(RTE_SDK),)
 $(error "Please define RTE_SDK environment variable")
 endif

+LIBVIRT_COMMON = libvirt-common.h
+LIBVIRT_HEADER = libvirt.h
+INCLUDE_PATH = /usr/include/libvirt/
+
+HEADER_FILE = $(shell if [ -f $(INCLUDE_PATH)$(LIBVIRT_COMMON) ]; then echo 
$(LIBVIRT_COMMON);else echo $(LIBVIRT_HEADER); fi;)
+LIBVIRT_INCLUDE = $(INCLUDE_PATH)$(HEADER_FILE)
+
+LIBVIR_VER = $(shell gawk '/LIBVIR_VERSION_NUMBER .*/{print $$3}' 
$(LIBVIRT_INCLUDE))
+
 # Default target, can be overridden by command line or environment
 RTE_TARGET ?= x86_64-native-linuxapp-gcc

+ifeq ($(shell test $(LIBVIR_VER) -ge 9003 && echo 1), 1)
 include $(RTE_SDK)/mk/rte.vars.mk

 # binary name
@@ -57,3 +67,10 @@ CFLAGS_main.o += -Wno-return-type
 endif

 include $(RTE_SDK)/mk/rte.extapp.mk
+
+else
+.PHONY: all clean
+all:
+$(warning "vm_power_manager required libvirt version >= 0.9.3, please update 
libvirt-devel first")
+clean:
+endif
-- 
1.9.3

[dpdk-dev] [PATCH v4] examples/vm_power_manager: fix libvirt dependency check

[Bruce Richardson]

On Mon, Apr 11, 2016 at 12:32:52PM +0200, Thomas Monjalon wrote:
> From: Marvin Liu 
> 
> vm_power_manager utilize libvirt API virDomainGetVcpuPinInfo to
> retrieve domU vcpu information. This API is implemented from version 0.9.3.
> Suse11 SP3 32bit default libvirt version is 0.8.8.
> 
> examples/vm_power_manager/channel_manager.c:
> channel_manager.c:117:3: error: implicit declaration of function
> ?virDomainGetVcpuPinInfo?
> 
> Check and skip it from examples or raise an error when trying to compile
> without libvirt or with a too old libvirt.
> 
> Fixes: e8ae9b662 ("examples/vm_power: channel manager and monitor in host")
> 
> Signed-off-by: Marvin Liu 
> Signed-off-by: Thomas Monjalon 
> ---
>  examples/Makefile  | 4 
>  examples/vm_power_manager/Makefile | 6 ++
>  2 files changed, 10 insertions(+)
> 
> v4: mix v2 and v3 to skip in examples list but raise an error if trying
> to compile directly
> 
Yes, that is the correct way to fix it, I believe.

Acked-by: Bruce Richardson 

[dpdk-dev] [RFC] vhost user: add error handling for fd > 1023

[Christian Ehrhardt]

I like the approach as well to go for the fix for robustness first.

I was accidentally able to find another testcase to hit the same root cause.
Adding guests with 15 vhost_user based NICs each while having rxq for
openvswitch-dpdk set to 4 and multiqueue for the guest devices at 4 already
breaks when adding the thirds such guests.
That is way earlier than I would have expected the fd's to be exhausted but
still the same root cause, so just another test for the same.

In prep to the wider check to the patch a minor review question from me:
On the section of rte_vhost_driver_register that now detects if there were
issues we might want to close the socketfd as well when bailing out.
Otherwise we would just have another source of fd leaks or would that be
reused later on even now that we have freed vserver-path and vserver itself?

   ret = fdset_add(_vhost_server.fdset, vserver->listenfd,
   vserver_new_vq_conn, NULL, vserver);
   if (ret < 0) {
   pthread_mutex_unlock(_vhost_server.server_mutex);
   RTE_LOG(ERR, VHOST_CONFIG,
   "failed to add listen fd %d to vhost server
fdset\n",
   vserver->listenfd);
   free(vserver->path);
+  close(vserver->listenfd);
   free(vserver);
   return -1;
   }


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Mon, Apr 11, 2016 at 8:06 AM, Patrik Andersson R <
patrik.r.andersson at ericsson.com> wrote:

> I fully agree with this course of action.
>
> Thank you,
>
> Patrik
>
>
>
> On 04/08/2016 08:47 AM, Xie, Huawei wrote:
>
>> On 4/7/2016 10:52 PM, Christian Ehrhardt wrote:
>>
>>> I totally agree to that there is no deterministic rule what to expect.
>>> The only rule is that #fd certainly always is > #vhost_user devices.
>>> In various setup variants I've crossed fd 1024 anywhere between 475
>>> and 970 vhost_user ports.
>>>
>>> Once the discussion continues and we have an updates version of the
>>> patch with some more agreement I hope I can help to test it.
>>>
>> Thanks. Let us first temporarily fix this problem for robustness, then
>> we consider whether upgrade to (e)poll.
>> Will check the patch in detail later. Basically it should work but need
>> check whether we need extra fixes elsewhere.
>>
>
>

[dpdk-dev] [PATCH] autotests: fix mempool element size in func_reentrancy

[Olivier Matz]

The mempool element size is set to 0, but 4 bytes are written in
my_obj_init():

  uint32_t *objnum = obj;
  memset(obj, 0, mp->elt_size);
  *objnum = i;

Change the MEMPOOL_ELT_SIZE constant to sizeof(uint32_t). This fixes
memory corruptions since we were writting outside of the object
boundaries.

Fixes: 104a92bd026 ("app: add reentrancy tests")
Signed-off-by: Olivier Matz 
---
 app/test/test_func_reentrancy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test/test_func_reentrancy.c b/app/test/test_func_reentrancy.c
index 300a3bc..e5b2821 100644
--- a/app/test/test_func_reentrancy.c
+++ b/app/test/test_func_reentrancy.c
@@ -78,7 +78,7 @@ typedef void (*case_clean_t)(unsigned lcore_id);
 #define MAX_ITER_TIMES  (16)
 #define MAX_LPM_ITER_TIMES  (8)

-#define MEMPOOL_ELT_SIZE(0)
+#define MEMPOOL_ELT_SIZE(sizeof(uint32))
 #define MEMPOOL_SIZE(4)

 #define MAX_LCORES RTE_MAX_MEMZONE / (MAX_ITER_TIMES * 4U)
-- 
2.1.4

[dpdk-dev] [PATCH v2] examples/vm_power_manager: fix build with libvirt version < 0.9.3

[Thomas Monjalon]

2016-04-11 11:26, Thomas Monjalon:
> 2016-04-11 16:50, Marvin Liu:
> > Fixes: 2e099bc5d104 ("fix split of compiler and linker options")
> 
> As commented earlier, I don't think it is the origin of the issue.
> 
> > +$(info "vm_power_manager required libvirt version >= 0.9.3, please update 
> > libvirt-devel first")
> 
> "required" should be "requires".
> libvirt-devel is the name of the package on some distributions, but
> it is not always the case. Moreover, the whole libvirt package must be
> updated atomically, not only the headers. That's why I think it's better
> to remove this part and just keep:
>   "vm_power_manager requires libvirt version >= 0.9.3"
> 
> Other issue: it would better to use $(error to generate a compilation error.
> But the example should not be skipped from examples/Makefile in this case.

Sorry I mean the example *should be* skipped from examples/Makefile,
with the small message "vm_power_manager requires libvirt >= 0.9.3".

[dpdk-dev] [PATCH v2] examples/vm_power_manager: fix build with libvirt version < 0.9.3

[Thomas Monjalon]

2016-04-11 16:50, Marvin Liu:
> Fixes: 2e099bc5d104 ("fix split of compiler and linker options")

As commented earlier, I don't think it is the origin of the issue.

> +$(info "vm_power_manager required libvirt version >= 0.9.3, please update 
> libvirt-devel first")

"required" should be "requires".
libvirt-devel is the name of the package on some distributions, but
it is not always the case. Moreover, the whole libvirt package must be
updated atomically, not only the headers. That's why I think it's better
to remove this part and just keep:
"vm_power_manager requires libvirt version >= 0.9.3"

Other issue: it would better to use $(error to generate a compilation error.
But the example should not be skipped from examples/Makefile in this case.

[dpdk-dev] [PATCH] doc: Programmers guide IP fragmentation direct/indirect mbufs to wrong section

[John Guzik]

---
 doc/guides/prog_guide/ip_fragment_reassembly_lib.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst 
b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
index 1d3d4ac..196d93c 100644
--- a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
+++ b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
@@ -54,7 +54,7 @@ Finally 'direct' and 'indirect' mbufs for each fragment are 
linked together via

 The caller has an ability to explicitly specify which mempools should be used 
to allocate 'direct' and 'indirect' mbufs from.

-For more information about direct and indirect mbufs, refer to the *DPDK 
Programmers guide 7.7 Direct and Indirect Buffers.*
+For more information about direct and indirect mbufs, refer to the *DPDK 
Programmers guide 6.7 Direct and Indirect Buffers.*

 Packet reassembly
 -
-- 
1.9.1

[dpdk-dev] librte_table build race with SYMLINK-FILE?

[Stephen Hemminger]

On Mon, 11 Apr 2016 12:46:16 +0200
Simon K?gstr?m  wrote:

> Hi!
> 
> I'm upgrading from DPDK 2.1 to 16.04-rc4, and have a new build issue
> which I didn't see before. It's in the librte_table and happens from
> time to time (unfrequently) in my out-of-tree build. It looks like a
> race between comilation and SYMLINK-FILE:
> 
> [...]
> == Build lib/librte_table
>   CC rte_table_lpm_ipv6.o
>   CC rte_table_lpm.o
>   CC rte_table_acl.o
>   CC rte_table_hash_key8.o
> In file included from [...]lib/librte_table/rte_table_lpm.c:43:0:
> [...]/dpdk.build/include/rte_lpm.h:484:25: fatal error: rte_lpm_sse.h:
> No such file or directory
>  #include "rte_lpm_sse.h"
>  ^
> compilation terminated.
>   CC rte_table_hash_key16.o
> [...]
> 
> In this case, rte_lpm_sse.h is optionally symlinked if we're not on ARM.
> I've tried patching away the issue by unconditionally symlinking the
> _{neon,sse}.h files, and while I don't see the problem after that, I
> don't really see why it would improve the situation.
> 
> Does anyone else see this as well?
> 
> // Simon

The issue is a missing dependency in the mk file for LPM.

[dpdk-dev] [PATCH] eal: fix resource leak

[Burakov, Anatoly]

> Subject: [PATCH] eal: fix resource leak
> 
> CID 13289 (#1-2 of 2): Resource leak (RESOURCE_LEAK):
> The system resource will not be reclaimed and reused, reducing the future
> availability of the resource.
> In pci_vfio_get_group_fd: Leak of memory or pointers to system resources
> 
> Fixes: ff0b67d1c868 ("vfio: DMA mapping")
> 
> Signed-off-by: Daniel Mrzyglod 
> ---
>  lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
> b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
> index fdfdeb4..10266f8 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
> @@ -535,6 +535,7 @@ pci_vfio_get_group_fd(int iommu_group_no)
>   /* if the fd is valid, create a new group for it */
>   if (vfio_cfg.vfio_group_idx == VFIO_MAX_GROUPS) {
>   RTE_LOG(ERR, EAL, "Maximum number of VFIO
> groups reached!\n");
> + close(vfio_group_fd);
>   return -1;
>   }
>   vfio_cfg.vfio_groups[vfio_cfg.vfio_group_idx].group_no =
> iommu_group_no;
> --
> 2.5.5

Acked-by: Anatoly  Burakov 

[dpdk-dev] DPDK 2.2 build failing with vhost-kni

[chintu hetam]

Thanks Xie.

I am trying to test FreeBSD-9.3-virtio as guest. Somewhere in the forum i
found virtio-kni combination reaching around 2.7 Gbps performance, which is
enough for my test, though i dint find equivalent driver performance
characterization for qemu-vhost user space combination.
Also, as per nics-2.2 user guide, "Linux kernel with KVM module; vhost
module loaded and ioeventfd supported. Qemu standard backend without vhost
support isn?t tested, and probably isn?t supported",which is bit different
from vhost user space support,but still..

Just to be sure vhost user space = qemu virtio backend- tap-linux-bridge
configuration, as per nics guide, right?

Thanking in advance, again.







On Mon, Apr 11, 2016 at 4:25 AM, Xie, Huawei  wrote:

> On 4/10/2016 7:26 AM, chintu hetam wrote:
> > I am compiling DPDK 2.2 on Fedora 23 and i am seeing following build
> error
> >
> /home/vcr/devel/dpdk/dpdk-2.2.0/build/build/lib/librte_eal/linuxapp/kni/kni_vhost.c:
> > In function ?kni_sock_poll?:
> >
> /home/vcr/devel/dpdk/dpdk-2.2.0/build/build/lib/librte_eal/linuxapp/kni/kni_vhost.c:254:25:
> > error: ?SOCK_ASYNC_NOSPACE? undeclared (first use in this function)
> >   (!test_and_set_bit(SOCK_ASYNC_NOSPACE, >sock->flags) &&
> >  ^
>
> Hi, besides the issue, now user space vhost is the preferred way to
> switch packets with the virtual machine, and we have plans to remove kni
> vhost support. Do you have any reason to use kni vhost?
>

[dpdk-dev] [PATCH v2] doc: fill nics features matrix for pcap

[Stephen Hemminger]

I wonder if this matrix would be better if auto-generated some how.
Either statically from source scan, or dynamically via simple app?

[dpdk-dev] [PATCH] examples/vm_power_manager: fix build with libvirt version < 0.9.3

[Thomas Monjalon]

2016-04-11 11:45, Marvin Liu:
> vm_power_manager utilize libvirt API virDomainGetVcpuPinInfo for
> retrieve domU vcpu information. This API implemented from version 0.9.3.
> Suse11 SP3 32bit default libvirt version is 0.8.8, so there'll be build
> error. Add judgement in sample Makefile to skip unsupport environment.
> 
> examples/vm_power_manager/channel_manager.c: In function
> ?update_pcpus_mask?:
> channel_manager.c:117:3: error: implicit declaration of function
> ?virDomainGetVcpuPinInfo?
> 
> Fixes: 2e099bc5d104 ("fix split of compiler and linker options")

I think the issue has always been there:
Fixes: e8ae9b662506 ("examples/vm_power: channel manager and monitor in host")

> +LIBVIRT_COMMON = libvirt-common.h
> +LIBVIRT_HEADER = libvirt.h
> +INCLUDE_PATH = /usr/include/libvirt/

You cannot assume it will be installed in this directory.
Please check the version with the standard pkg-config:
pkg-config --atleast-version=0.9.3 libvirt
It can work even in cross compilation environment thanks to PKG_CONFIG_PATH.

[dpdk-dev] [PATCH] examples/vm_power_manager: fix build with libvirt version < 0.9.3

[Liu, Yong]

Thanks Thomas,  I'll send v2 for it.

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, April 11, 2016 3:24 PM
> To: Liu, Yong
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] examples/vm_power_manager: fix build with
> libvirt version < 0.9.3
> 
> 2016-04-11 11:45, Marvin Liu:
> > vm_power_manager utilize libvirt API virDomainGetVcpuPinInfo for
> > retrieve domU vcpu information. This API implemented from version 0.9.3.
> > Suse11 SP3 32bit default libvirt version is 0.8.8, so there'll be build
> > error. Add judgement in sample Makefile to skip unsupport environment.
> >
> > examples/vm_power_manager/channel_manager.c: In function
> > ?update_pcpus_mask?:
> > channel_manager.c:117:3: error: implicit declaration of function
> > ?virDomainGetVcpuPinInfo?
> >
> > Fixes: 2e099bc5d104 ("fix split of compiler and linker options")
> 
> I think the issue has always been there:
> Fixes: e8ae9b662506 ("examples/vm_power: channel manager and monitor in
> host")
> 
> > +LIBVIRT_COMMON = libvirt-common.h
> > +LIBVIRT_HEADER = libvirt.h
> > +INCLUDE_PATH = /usr/include/libvirt/
> 
> You cannot assume it will be installed in this directory.
> Please check the version with the standard pkg-config:
>   pkg-config --atleast-version=0.9.3 libvirt
> It can work even in cross compilation environment thanks to
> PKG_CONFIG_PATH.

[dpdk-dev] DPDK 2.2 build failing with vhost-kni

[Xie, Huawei]

On 4/10/2016 7:26 AM, chintu hetam wrote:
> I am compiling DPDK 2.2 on Fedora 23 and i am seeing following build error
> /home/vcr/devel/dpdk/dpdk-2.2.0/build/build/lib/librte_eal/linuxapp/kni/kni_vhost.c:
> In function ?kni_sock_poll?:
> /home/vcr/devel/dpdk/dpdk-2.2.0/build/build/lib/librte_eal/linuxapp/kni/kni_vhost.c:254:25:
> error: ?SOCK_ASYNC_NOSPACE? undeclared (first use in this function)
>   (!test_and_set_bit(SOCK_ASYNC_NOSPACE, >sock->flags) &&
>  ^

Hi, besides the issue, now user space vhost is the preferred way to
switch packets with the virtual machine, and we have plans to remove kni
vhost support. Do you have any reason to use kni vhost?

[dpdk-dev] [RFC] vhost user: add error handling for fd > 1023

[Patrik Andersson R]

I fully agree with this course of action.

Thank you,

Patrik


On 04/08/2016 08:47 AM, Xie, Huawei wrote:
> On 4/7/2016 10:52 PM, Christian Ehrhardt wrote:
>> I totally agree to that there is no deterministic rule what to expect.
>> The only rule is that #fd certainly always is > #vhost_user devices.
>> In various setup variants I've crossed fd 1024 anywhere between 475
>> and 970 vhost_user ports.
>>
>> Once the discussion continues and we have an updates version of the
>> patch with some more agreement I hope I can help to test it.
> Thanks. Let us first temporarily fix this problem for robustness, then
> we consider whether upgrade to (e)poll.
> Will check the patch in detail later. Basically it should work but need
> check whether we need extra fixes elsewhere.

[dpdk-dev] [PATCH] vhost: fix mem share between VM and host

[Xie, Huawei]

On 4/11/2016 1:29 AM, Zhe Tao wrote:
>  
> +/* Check the share memory in case the QEMU doesn't set the share option
> + * as on for the memory-backend-file object in the QEMU command line.
> + */
> +
> +int
> +vhost_check_mem_shared(struct vhost_device_ctx ctx)
> +{
> + struct virtio_net *dev;
> + struct vhost_virtqueue *vq;
> + int ret = 0;
> +
> + dev = get_device(ctx);
> + if ((dev == NULL) || (dev->mem == NULL))
> + return -1;
> +
> + /* check first virtqueue 0 rxq. */
> + vq = dev->virtqueue[VIRTIO_RXQ];
> + ret = vq->desc[0].next == 0 ? -1 : 0;
> +
> + if (ret)
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "The mem is not shared between VM and host\n");
> +
> + return ret;
> +}
> +

Zhe: This is known to vhost-user users that share=on is a must-to-have
option. I think this isn't an issue.
It is OK if we could do some early check in vhost, however we couldn't
assume the value of vq->desc[0].next.
Check if there is other simple and reliable way.

[dpdk-dev] [PATCH] eal: fix resource leak

[Thomas Monjalon]

> > CID 13289 (#1-2 of 2): Resource leak (RESOURCE_LEAK):
> > The system resource will not be reclaimed and reused, reducing the future
> > availability of the resource.
> > In pci_vfio_get_group_fd: Leak of memory or pointers to system resources
> > 
> > Fixes: ff0b67d1c868 ("vfio: DMA mapping")
> > 
> > Signed-off-by: Daniel Mrzyglod 
> 
> Acked-by: Anatoly  Burakov 

Applied, thanks

[dpdk-dev] [PATCH v2] doc: add section on tested platforms and nics

[Xu, Qian Q]

Thomas
Could you help check the updated doc to see if you can merge? Thx. You asked me 
to do it quickly so John has submitted the patch for me in a short time. 

Thanks
Qian

-Original Message-
From: Mcnamara, John 
Sent: Friday, April 08, 2016 11:22 PM
To: dev at dpdk.org
Cc: thomas.monjalon at 6wind.com; Mcnamara, John; Xu, Qian Q
Subject: [PATCH v2] doc: add section on tested platforms and nics

Add a new section on tested platforms and nics to the release notes.

Signed-off-by: Qian Xu 
Signed-off-by: John McNamara 
---

V2: 
 - Moved text to release notes.
 - Made mailing list changes.

 doc/guides/rel_notes/release_16_04.rst | 120 +
 1 file changed, 120 insertions(+)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 200053c..09036c1 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -533,3 +533,123 @@ The libraries prepended with a plus sign were incremented 
in this version.
  librte_table.so.2
  librte_timer.so.1
  librte_vhost.so.2
+
+
+Tested Platforms
+
+
+#. SuperMicro 1U
+
+   - BIOS: 1.0c
+   - Processor: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz
+
+#. SuperMicro 1U
+
+   - BIOS: 1.0a
+   - Processor: Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz
+   - Onboard NIC: Intel(R) X552/X557-AT (2x10G)
+
+ - Firmware-version: 0x81cf
+ - Device ID (PF/VF): 8086:15ad /8086:15a8
+
+   - kernel driver version: 4.2.5 (ixgbe)
+
+#. SuperMicro 1U
+
+   - BIOS: 1.0a
+   - Processor: Intel(R) Xeon(R) CPU E5-4667 v3 @ 2.00GHz
+
+#. Intel(R) Server board S2600GZ
+
+   - BIOS: SE5C600.86B.02.02.0002.122320131210
+   - Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
+
+#. Intel(R) Server board W2600CR
+
+   - BIOS: SE5C600.86B.02.01.0002.082220131453
+   - Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
+
+#. Intel(R) Server board S2600CWT
+
+   - BIOS: SE5C610.86B.01.01.0009.060120151350
+   - Processor: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
+
+#. Intel(R) Server board S2600WTT
+
+   - BIOS: SE5C610.86B.01.01.0005.101720141054
+   - Processor: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
+
+#. Intel(R) Server board S2600WTT
+
+   - BIOS: SE5C610.86B.11.01.0044.090120151156
+   - Processor: Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10GHz
+
+Tested NICs
+---
+
+#. Intel(R) Ethernet Controller X540-AT2
+
+   - Firmware version: 0x8389
+   - Device id (pf): 8086:1528
+   - Driver version: 3.23.2 (ixgbe)
+
+#. Intel(R) 82599ES 10 Gigabit Ethernet Controller
+
+   - Firmware version: 0x61bf0001
+   - Device id (pf/vf): 8086:10fb / 8086:10ed
+   - Driver version: 4.0.1-k (ixgbe)
+
+#. Intel(R) Corporation Ethernet Connection X552/X557-AT 10GBASE-T
+
+   - Firmware version: 0x81cf
+   - Device id (pf/vf): 8086:15ad / 8086:15a8
+   - Driver version: 4.2.5 (ixgbe)
+
+#. Intel(R) Ethernet Converged Network Adapter X710-DA4 (4x10G)
+
+   - Firmware version: 5.02 0x80002284
+   - Device id (pf/vf): 8086:1572 / 8086:154c
+   - Driver version: 1.4.26 (i40e)
+
+#. Intel(R) Ethernet Converged Network Adapter X710-DA2 (2x10G)
+
+   - Firmware version: 5.02 0x80002282
+   - Device id (pf/vf): 8086:1572 / 8086:154c
+   - Driver version: 1.4.25 (i40e)
+
+#. Intel(R) Ethernet Converged Network Adapter XL710-QDA1 (1x40G)
+
+   - Firmware version: 5.02 0x80002281
+   - Device id (pf/vf): 8086:1584 / 8086:154c
+   - Driver version: 1.4.25 (i40e)
+
+#. Intel(R) Ethernet Converged Network Adapter XL710-QDA2 (2X40G)
+
+   - Firmware version: 5.02 0x80002285
+   - Device id (pf/vf): 8086:1583 / 8086:154c
+   - Driver version: 1.4.25 (i40e)
+
+#. Intel(R) 82576EB Gigabit Ethernet Controller
+
+   - Firmware version: 1.2.1
+   - Device id (pf): 8086:1526
+   - Driver version: 5.2.13-k (igb)
+
+#. Intel(R) Ethernet Controller I210
+
+   - Firmware version: 3.16, 0x8500, 1.304.0
+   - Device id (pf): 8086:1533
+   - Driver version: 5.2.13-k (igb)
+
+#. Intel(R) Corporation I350 Gigabit Network Connection
+
+   - Firmware version: 1.48, 0x86e7
+   - Device id (pf/vf): 8086:1521 / 8086:1520
+   - Driver version: 5.2.13-k (igb)
+
+
+#. Intel(R) Ethernet Multi-host Controller FM1
+
+   - Firmware version: N/A
+   - Device id (pf/vf): 8086:15d0
+   - Driver version: 0.17.0.9 (fm10k)
-- 
2.5.0

[dpdk-dev] [PATCH] vhost: fix mem share between VM and host

[Zhe Tao]

The reason cause this problem is that in QEMU, when assign the
memory-backend-file without share option, will cause QEMU mmap the mem file
without using the MAP_SHARED flag, so the page cache for that file will not
shared between other processes, all the upated to the mapping area in the VM
will not carry through to the vhost-user process.

According to kernel implementation, data for the new hugetlbfs file will be
all zero, so check the first RX virtqueue descriptor next field to see
whether the mem is shared or not, if the mem is shared, the next field should
not equal to zero, otherwise this mem is not shared between VM and host.

Signed-off-by: Zhe Tao 
---
 lib/librte_vhost/vhost-net.h  |  1 +
 lib/librte_vhost/vhost_user/virtio-net-user.c |  7 ---
 lib/librte_vhost/virtio-net.c | 29 ++-
 3 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/lib/librte_vhost/vhost-net.h b/lib/librte_vhost/vhost-net.h
index f193a1f..588008f 100644
--- a/lib/librte_vhost/vhost-net.h
+++ b/lib/librte_vhost/vhost-net.h
@@ -105,6 +105,7 @@ int vhost_set_backend(struct vhost_device_ctx, struct 
vhost_vring_file *);

 int vhost_set_owner(struct vhost_device_ctx);
 int vhost_reset_owner(struct vhost_device_ctx);
+int vhost_check_mem_shared(struct vhost_device_ctx);

 /*
  * Backend-specific cleanup. Defined by vhost-cuse and vhost-user.
diff --git a/lib/librte_vhost/vhost_user/virtio-net-user.c 
b/lib/librte_vhost/vhost_user/virtio-net-user.c
index f5248bc..08dd2dd 100644
--- a/lib/librte_vhost/vhost_user/virtio-net-user.c
+++ b/lib/librte_vhost/vhost_user/virtio-net-user.c
@@ -286,9 +286,10 @@ user_set_vring_kick(struct vhost_device_ctx ctx, struct 
VhostUserMsg *pmsg)
"vring kick idx:%d file:%d\n", file.index, file.fd);
vhost_set_vring_kick(ctx, );

-   if (virtio_is_ready(dev) &&
-   !(dev->flags & VIRTIO_DEV_RUNNING))
-   notify_ops->new_device(dev);
+   if (!vhost_check_mem_shared(ctx) &&
+   virtio_is_ready(dev) &&
+   !(dev->flags & VIRTIO_DEV_RUNNING))
+   notify_ops->new_device(dev);
 }

 /*
diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index 90da9ba..6b1a59d 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -712,7 +712,8 @@ vhost_set_backend(struct vhost_device_ctx ctx, struct 
vhost_vring_file *file)
 * If the device isn't already running and both backend fds are set,
 * we add the device.
 */
-   if (!(dev->flags & VIRTIO_DEV_RUNNING)) {
+   if (!vhost_check_mem_shared(ctx) &&
+   !(dev->flags & VIRTIO_DEV_RUNNING)) {
if (((int)dev->virtqueue[VIRTIO_TXQ]->backend != 
VIRTIO_DEV_STOPPED) &&
((int)dev->virtqueue[VIRTIO_RXQ]->backend != 
VIRTIO_DEV_STOPPED)) {
return notify_ops->new_device(dev);
@@ -724,6 +725,32 @@ vhost_set_backend(struct vhost_device_ctx ctx, struct 
vhost_vring_file *file)
return 0;
 }

+/* Check the share memory in case the QEMU doesn't set the share option
+ * as on for the memory-backend-file object in the QEMU command line.
+ */
+
+int
+vhost_check_mem_shared(struct vhost_device_ctx ctx)
+{
+   struct virtio_net *dev;
+   struct vhost_virtqueue *vq;
+   int ret = 0;
+
+   dev = get_device(ctx);
+   if ((dev == NULL) || (dev->mem == NULL))
+   return -1;
+
+   /* check first virtqueue 0 rxq. */
+   vq = dev->virtqueue[VIRTIO_RXQ];
+   ret = vq->desc[0].next == 0 ? -1 : 0;
+
+   if (ret)
+   RTE_LOG(ERR, VHOST_CONFIG,
+   "The mem is not shared between VM and host\n");
+
+   return ret;
+}
+
 int rte_vhost_enable_guest_notification(struct virtio_net *dev,
uint16_t queue_id, int enable)
 {
-- 
2.1.4

[dpdk-dev] ip_reassembly doesn't start

[Victor Detoni]

hi,

I'm trying to run ip_reassembly application but it is showing the error
below. please, someone knows what's happing?

The other app like l2fwd/l3fwd works fine.


root at ubuntu:~# cd dpdk-2.1.0/examples/ip_reassembly/
root at ubuntu:~/dpdk-2.1.0/examples/ip_reassembly# ./build/ip_reassembly -c
0xff -n 1 -- -p 0x3 -q 2
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: Support maximum 128 logical core(s) by configuration.
EAL: Detected 8 lcore(s)
EAL: VFIO modules not all loaded, skip VFIO support...
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2dfb40 (size = 0x20)
EAL: Ask a virtual area of 0x3f80 bytes
EAL: Virtual area found at 0x7f2dbba0 (size = 0x3f80)
EAL: Ask a virtual area of 0x4040 bytes
EAL: Virtual area found at 0x7f2d7b40 (size = 0x4040)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2d7b00 (size = 0x20)
EAL: Requesting 1024 pages of size 2MB from socket 0
EAL: TSC frequency is ~2194711 KHz
EAL: Master lcore 0 is ready (tid=fd578940;cpuset=[0])
EAL: lcore 3 is ready (tid=79ffd700;cpuset=[3])
EAL: lcore 6 is ready (tid=787fa700;cpuset=[6])
EAL: lcore 1 is ready (tid=7afff700;cpuset=[1])
EAL: lcore 4 is ready (tid=797fc700;cpuset=[4])
EAL: lcore 7 is ready (tid=77ff9700;cpuset=[7])
EAL: lcore 5 is ready (tid=78ffb700;cpuset=[5])
EAL: lcore 2 is ready (tid=7a7fe700;cpuset=[2])
EAL: PCI device :03:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   Not managed by a supported kernel driver, skipped
EAL: PCI device :0b:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   PCI memory mapped at 0x7f2dfb60
EAL:   PCI memory mapped at 0x7f2dfb601000
EAL:   PCI memory mapped at 0x7f2dfb602000
EAL: PCI device :13:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   PCI memory mapped at 0x7f2dfb604000
EAL:   PCI memory mapped at 0x7f2dfb605000
EAL:   PCI memory mapped at 0x7f2dfb606000
0x7ffc7122d8af
IP_RSMBL: Creating LPM table on socket 0
IP_RSMBL: Creating LPM6 table on socket 0
USER1: rte_ip_frag_table_create: allocated of 25165952 bytes at socket 0
Initializing port 0 ...
EAL: Error - exiting with code: 1
  Cause: rte_eth_rx_queue_setup: err=-22, port=0