[dpdk-dev] KNI discussion in userspace event

[Vincent Jardin]

Le 28 octobre 2016 9:23:06 PM Igor Ryzhov  a ?crit :

> On Fri, Oct 28, 2016 at 9:40 PM, Thomas Monjalon  6wind.com>
> wrote:
>
>> 2016-10-28 20:29, Igor Ryzhov:
>> > On Fri, Oct 28, 2016 Thomas Monjalon wrote:
>> > > 2016-10-28 15:51, Richardson, Bruce:
>> > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
>> > > > > 2016-10-28 15:31, Ferruh Yigit:
>> > > > > > * Remove ethtool support ?
>> > > > >
>> > > > > That's the other part of KNI.
>> > > > > It works only for e1000/ixgbe. That's a niche.
>> > > >
>> > > > Yes, it's something we need to remove, but again, we need an
>> > > > alternative first.
>> > > >
>> > > > >
>> > > > > > Still there is some interest, will keep it. But not able to
>> extend it
>> > > > > > to other drivers with current design.
>> > > > >
>> > > > > It should be removed one day.
>> > > > > We must seriously think about a generic alternative.
>> > > > > Either we add DPDK support in ethtool or we create a dpdk-ethtool.
>> > > > > (or at least a library as the one in examples/).
>> > > >
>> > > > I don't view that as a great path forward. Sure, we can do our own
>> > > > ethtool, but then people will look for ifconfig to work, and "ip" to
>> work,
>> > > > etc. I view having a kernel proxy module as the best path here as it
>> is
>> > > > tool agnostic on the userspace side, rather than trying to make every
>> > > > tool for working with kernel netdevs also have support for dpdk
>> ports.
>> > >
>> > > Yes that's the ultimately best solution.
>> > > But:
>> > > - we need some cooperation of the kernel team
>> > > - ethtool manages a device (what DPDK provides) whereas iproute and
>> others
>> > > manage a TCP/IP stack so is out of control of DPDK.
>> >
>> > That's not true.
>> > iproute can control a lot of things like MAC address, promiscuous, MTU,
>> > etc. that cannot be controlled with ethtool.
>> > Just compare net_device_ops and ethtool_ops to see the difference.
>>
>> Yes you're right. iproute was not a good example :)
>>
>> > And the question is not only about tools, it is also about how Linux
>> kernel
>> > works with network devices.
>> > And it uses net_device_ops, not ethtool_ops.
>>
>> What do you mean exactly? I feel you have something in mind.
>>
>
> My main point is that if we want to control DPDK ports from Linux, it
> should be done with standard utilities.
> Every standard utility like iproute just uses existing Linux kernel
> interfaces and kernel in its turn uses net_device_ops to control the device.
>
> For example, you want to set MTU of the network device.
> Regardless of the utility you use to do that (even if you write your own),
> there are two options ? ioctl or netlink.
> And regardless of the method you choose,  Linux kernel will then call
> "ndo_change_mtu".

DPDK runs on non Linux too (FreeBSD, maybe Windows some days). So we should 
avoid creating such dependencies.

I do like the kind of bifurcated models  (? la RDMA like mlx PMDs) so port 
management is still done using plain OS drivers of the kernel. We should 
rather push toward proper bifurcated drivers:
  - so we decrease maintenance and avoid code duplication
  - we benefit of kernel's interface management

I am not expert of RDMA on FreeBSD and Windows but it seems available.

[dpdk-dev] [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK

[Vincent Jardin]

Le 26 octobre 2016 2:11:26 PM "Van Haaren, Harry" 
 a ?crit :

>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jerin Jacob
>>
>> So far, I have received constructive feedback from Intel, NXP and Linaro 
>> folks.
>> Let me know, if anyone else interested in contributing to the definition of 
>> eventdev?
>>
>> If there are no major issues in proposed spec, then Cavium would like work on
>> implementing and up-streaming the common code(lib/librte_eventdev/) and
>> an associated HW driver.(Requested minor changes of v2 will be addressed
>> in next version).
>
> Hi All,
>
> I will propose a minor change to the rte_event struct, allowing some bits 
> to be implementation specific. Currently the rte_event struct has no space 
> to allow an implementation store any metadata about the event. For software 
> performance it would be really helpful if there are some bits available for 
> the implementation to keep some flags about each event.
>
> I suggest to rework the struct as below which opens 6 bits that were 
> otherwise wasted, and define them as implementation specific. By 
> implementation specific it is understood that the implementation can 
> overwrite any information stored in those bits, and the application must 
> not expect the data to remain after the event is scheduled.
>
> OLD:
> struct rte_event {
>   uint32_t flow_id:24;
>   uint32_t queue_id:8;
>   uint8_t  sched_type; /* Note only 2 bits of 8 are required */
>
> NEW:
> struct rte_event {
>   uint32_t flow_id:24;
>   uint32_t sched_type:2; /* reduced size : but 2 bits is enough for the 
> enqueue types Ordered,Atomic,Parallel.*/
>   uint32_t implementation:6; /* available for implementation specific 
> metadata */
>   uint8_t queue_id; /* still 8 bits as before */

Bitfileds are efficients on Octeon. What's about other CPUs you have in 
mind? x86 is not as efficient.


>
>
> Thoughts? -Harry

[dpdk-dev] [PATCH] Fix KNI compilation under Wind River Linux 6.0 recent RCPLs.

[Vincent JARDIN]

Le 30/03/2016 23:50, Stephen Hemminger a ?crit :
> Do we want to require DPDK to work in the face of every weird vendor
> kernel backport. This is a road to nowhere...
+1 with Steve. No way! There is no rational.

[dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module

[Vincent JARDIN]

Le 10 mars 2016 01:06, "Thomas Monjalon"  a
?crit :
>
> 2016-03-02 23:35, Thomas Monjalon:
> > 2016-03-02 12:21, Thomas Monjalon:
> > > 2016-03-02 11:47, Vincent JARDIN:
> > > > Le 02/03/2016 09:27, Panu Matilainen a ?crit :
> > > > >>> I'd like to see these be merged.
> > > > >>>
> > > > >>> Jay
> > > > >>
> > > > >> The code is really not ready. I am okay with cooperative
development
> > > > >> but the current code needs to go into a staging type tree.
> > > > >> No compatibility, no ABI guarantees, more of an RFC.
> > > > >> Don't want vendors building products with it then screaming when
it
> > > > >> gets rebuilt/reworked/scrapped.
> > > > >>
> > > > >
> > > > > Exactly.
> > > >
> > > > +1 too
> > > >
> > > > We need to build on this innovation while there is a path for kernel
> > > > mainstream. The logic of using a staging is a good one.
> > > >
> > > > Thomas,
> > > >
> > > > can we open a staging folder into the DPDK like it is done into the
kernel?
> > >
> > > It's possible to create a staging directory if everybody agree.
> > > It is important to state in a README file or in the doc/ that
> > > there will be no guarantee (no stable ABI, no validation and can be
dropped)
> > > and that it is a work in progress, a suggestion to discuss with the
kernel
> > > community.
> > >
> > > The kernel modules must clearly target an upstream integration.
> >
> > Actually the examples directory has been used as a staging for ethtool
and
> > lthread. We also have the crypto API which is still experimental.
> > So I think we must decide among these 3 solutions:
> >   - no special directory, just mark and document an experimental
state
> >   - put only kcp/kdp in the staging directory

I do prefer this option.

> >   - put kcp/kdp in staging and move other experimental libs here
>
> Any opinion? Are we targetting upstream work without any DPDK staging?
>
> Please let's make clear the status of these patches.

[dpdk-dev] New driver (large patch) question.

[Vincent JARDIN]

Please,

Le 02/03/2016 22:30, Stephen Hurd a ?crit :
> Too many of the DPDK drivers are bloated.
>>Recall the venerable paraphrase of Pascal, "I made this so long because I
>>did not have time to make it shorter."
>>https://en.wikipedia.org/wiki/Wikipedia:Too_long;_didn%27t_read

Keep In Simple, Small Is Beautiful, the big drivers with dead codes are 
not easy to be maintained. We have lot of duplication of efforts between 
the kernel and some DPDK PMDs,

Currently, the breakdown of Lines of Codes of the PMDs are:

492 ring
522 null
666 af_packet
829 pcap
1229 szedata2
1300 mpipe
1411 xenvirt
2036 nfp
2260 vmxnet3
3074 virtio
4129 mlx4
4205 bonding
4524 mlx5
4904 enic
7654 cxgbe
7969 fm10k
27862 ixgbe
29209 e1000
31392 i40e
38031 bnx2x

(I did use cloc).

Vincent

[dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module

[Vincent JARDIN]

Le 02/03/2016 11:51, Jim Thompson a ?crit :
> Can we take it as a requirement to support FreeBSD this time around?

Of course, all OS should be on the loop, but I guess, it would be per 
kernel specific. What is ethtool on FreeBSD? Or can you start porting 
ethtool on FreeBSD?

[dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module

[Vincent JARDIN]

Le 02/03/2016 09:27, Panu Matilainen a ?crit :
>>> I'd like to see these be merged.
>>>
>>> Jay
>>
>> The code is really not ready. I am okay with cooperative development
>> but the current code needs to go into a staging type tree.
>> No compatibility, no ABI guarantees, more of an RFC.
>> Don't want vendors building products with it then screaming when it
>> gets rebuilt/reworked/scrapped.
>>
>
> Exactly.

+1 too

We need to build on this innovation while there is a path for kernel 
mainstream. The logic of using a staging is a good one.

Thomas,

can we open a staging folder into the DPDK like it is done into the kernel?

Thank you,
   Vincent

[dpdk-dev] snapshot for 2.2.0 problem?

[Vincent JARDIN]

Thomas,

> I am not sure if anyone has noticed yet this but is the dpdk snapshot
> bad today?

can you check again?

For 2 download:

$ md5sum dpdk-2.2.0*gz
22e2fd68cd5504f43fe9a5a6fd6dd938  dpdk-2.2.0 (1).tar.gz
22e2fd68cd5504f43fe9a5a6fd6dd938  dpdk-2.2.0.tar.gz

tar tvzf is ok too.

Thanks for the notice,
   Vincent

[dpdk-dev] [dpdk-announce] new project using DPDK - FD.io

[Vincent JARDIN]

A new project using DPDK is available,
   http://FD.io
said
   FiDo

You can clone it from:
   http://gerrit.fd.io/

Best regards,
   Vincent

[dpdk-dev] [PATCH] virtio: prettify log messages

[Vincent JARDIN]

On 11/02/2016 02:12, Stephen Hemminger wrote:
> I would rather the macros were aligned with ixgbe which always
> adds newline for all the PMD_XXX_LOG() macros. And then remove
> all extra newlines in virtio code.
you right

[dpdk-dev] [PATCH] virtio: prettify log messages

[Vincent JARDIN]

PMD_TX_LOG() looks better with a \n

Signed-off-by: Vincent JARDIN 
---
 drivers/net/virtio/virtio_rxtx.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 41a1366..c03d36a 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -825,7 +825,7 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, 
uint16_t nb_pkts)
if (unlikely(nb_pkts < 1))
return nb_pkts;

-   PMD_TX_LOG(DEBUG, "%d packets to xmit", nb_pkts);
+   PMD_TX_LOG(DEBUG, "%d packets to xmit\n", nb_pkts);
nb_used = VIRTQUEUE_NUSED(txvq);

virtio_rmb();
@@ -847,7 +847,7 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, 
uint16_t nb_pkts)
need = txm->nb_segs - txvq->vq_free_cnt + 1;
if (unlikely(need > 0)) {
PMD_TX_LOG(ERR,
-  "No free tx descriptors to 
transmit");
+  "No free tx descriptors to 
transmit\n");
break;
}
}
@@ -865,11 +865,11 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts, uint16_t nb_pkts)
error = virtqueue_enqueue_xmit(txvq, txm);
if (unlikely(error)) {
if (error == ENOSPC)
-   PMD_TX_LOG(ERR, "virtqueue_enqueue Free count = 
0");
+   PMD_TX_LOG(ERR, "virtqueue_enqueue Free count = 
0\n");
else if (error == EMSGSIZE)
-   PMD_TX_LOG(ERR, "virtqueue_enqueue Free count < 
1");
+   PMD_TX_LOG(ERR, "virtqueue_enqueue Free count < 
1\n");
else
-   PMD_TX_LOG(ERR, "virtqueue_enqueue error: %d", 
error);
+   PMD_TX_LOG(ERR, "virtqueue_enqueue error: 
%d\n", error);
break;
}

@@ -884,7 +884,7 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, 
uint16_t nb_pkts)

if (unlikely(virtqueue_kick_prepare(txvq))) {
virtqueue_notify(txvq);
-   PMD_TX_LOG(DEBUG, "Notified backend after xmit");
+   PMD_TX_LOG(DEBUG, "Notified backend after xmit\n");
}
}

-- 
2.1.0

[dpdk-dev] [PATCH] eal/linux: fix compilation error CONFIG_RTE_LIBEAL_USE_HPET

[Vincent JARDIN]

When CONFIG_RTE_LIBEAL_USE_HPET=y is set, eal_timer.c does not compile
anymore. Just add simple missing include.

Signed-off-by: Vincent JARDIN 
---
 lib/librte_eal/linuxapp/eal/eal_timer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_eal/linuxapp/eal/eal_timer.c 
b/lib/librte_eal/linuxapp/eal/eal_timer.c
index 6f95d8e..0115ee2 100644
--- a/lib/librte_eal/linuxapp/eal/eal_timer.c
+++ b/lib/librte_eal/linuxapp/eal/eal_timer.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "eal_private.h"
 #include "eal_internal_cfg.h"
-- 
2.1.0

[dpdk-dev] PATCH 1/2] i40e: support floating VEB config

[Vincent JARDIN]

On 21/01/2016 08:29, David Marchand wrote:
> Hello,
>
> On Thu, Jan 21, 2016 at 8:24 AM, Zhe Tao  wrote:
>> Add the new floating related argument option in the EAL.
>> using this parameter, all the samples can decide whether to use legacy 
>> VEB/VEPA,
>>   or floating VEB.
>
> Not familiar with this.
> Can you confirm this stuff make sense for anything but i40e ?

+1 with David. On Linux kernel, only i40e includes this feature.

[dpdk-dev] [PATCH 0/4] Optimize memcpy for AVX512 platforms

[Vincent JARDIN]

Le 14 janv. 2016 22:39, "Wang, Zhihong"  a ?crit :
>
>
>
> > -Original Message-
> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > Sent: Friday, January 15, 2016 12:49 AM
> > To: Wang, Zhihong 
> > Cc: dev at dpdk.org; Ananyev, Konstantin ;
> > Richardson, Bruce ; Xie, Huawei
> > 
> > Subject: Re: [PATCH 0/4] Optimize memcpy for AVX512 platforms
> >
> > On Thu, 14 Jan 2016 01:13:18 -0500
> > Zhihong Wang  wrote:
> >
> > > This patch set optimizes DPDK memcpy for AVX512 platforms, to make
full
> > > utilization of hardware resources and deliver high performance.
> > >
> > > In current DPDK, memcpy holds a large proportion of execution time in
> > > libs like Vhost, especially for large packets, and this patch can
bring
> > > considerable benefits.
> > >
> > > The implementation is based on the current DPDK memcpy framework, some
> > > background introduction can be found in these threads:
> > > http://dpdk.org/ml/archives/dev/2014-November/008158.html
> > > http://dpdk.org/ml/archives/dev/2015-January/011800.html
> > >
> > > Code changes are:
> > >
> > >   1. Read CPUID to check if AVX512 is supported by CPU
> > >
> > >   2. Predefine AVX512 macro if AVX512 is enabled by compiler
> > >
> > >   3. Implement AVX512 memcpy and choose the right implementation based
> > on
> > >  predefined macros
> > >
> > >   4. Decide alignment unit for memcpy perf test based on predefined
macros
> > >
> > > Zhihong Wang (4):
> > >   lib/librte_eal: Identify AVX512 CPU flag
> > >   mk: Predefine AVX512 macro for compiler
> > >   lib/librte_eal: Optimize memcpy for AVX512 platforms
> > >   app/test: Adjust alignment unit for memcpy perf test
> > >
> > >  app/test/test_memcpy_perf.c|   6 +
> > >  .../common/include/arch/x86/rte_cpuflags.h |   2 +
> > >  .../common/include/arch/x86/rte_memcpy.h   | 247
> > -
> > >  mk/rte.cpuflags.mk |   4 +
> > >  4 files changed, 255 insertions(+), 4 deletions(-)
> > >
> >
> > This really looks like code that could benefit from Gcc
> > function multiversioning. The current cpuflags model is useless/flawed
> > in real product deployment
>
>
> I've tried gcc function multi versioning, with a simple add() function
> which returns a + b, and a loop calling it for millions of times. Turned
> out this mechanism adds 17% extra time to execute, overall it's a lot
> of extra overhead.
>
> Quote the gcc wiki: "GCC takes care of doing the dispatching to call
> the right version at runtime". So it loses inlining and adds extra
> dispatching overhead.
>
> Also this mechanism works only for C++, right?
>
> I think using predefined macros at compile time is more efficient and
> suits DPDK more.
>

I agree with you: performance first.

So having a mix of runtime and compile time would work. For those who are
ok with some performance drops, they can go with runtime.

> Could you please give an example when the current CPU flags model
> stop working? So I can fix it.
>

[dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del

[Vincent JARDIN]

> [Wenzhuo] The udp_tunnel_add and udp_tunnel_del have already existed. I
just use them. Honestly I agree with you they are not accurate name. Better
change them to udp_tunnel_port_add and udp_tunnel_port_del. But it should
be a ABI change if I?m not wrong. I think we can announce it this release
and change them in the next release. Would you agree?  Thanks.

Yes you are right.

[dpdk-dev] [PATCH 1/4] ixgbe: support UDP tunnel add/del

[Vincent JARDIN]

see inline

Le 11 janv. 2016 08:08, "Wenzhuo Lu"  a ?crit :
>
> Add UDP tunnel add/del support on ixgbe. Now it only support
> VxLAN port configuration.
> Although the VxLAN port has a default value 4789, it can be
> changed. We support VxLAN port configuration to meet the
> change.
> Note, the default value of VxLAN port in ixgbe NICs is 0. So
> please set it when using VxLAN off-load.
>
> Signed-off-by: Wenzhuo Lu 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c | 93

>  1 file changed, 93 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 4c4c6df..381cbad 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -337,6 +337,10 @@ static int ixgbe_timesync_read_time(struct
rte_eth_dev *dev,
>struct timespec *timestamp);
>  static int ixgbe_timesync_write_time(struct rte_eth_dev *dev,
>const struct timespec *timestamp);
> +static int ixgbe_dev_udp_tunnel_add(struct rte_eth_dev *dev,
> +   struct rte_eth_udp_tunnel
*udp_tunnel);
> +static int ixgbe_dev_udp_tunnel_del(struct rte_eth_dev *dev,
> +   struct rte_eth_udp_tunnel
*udp_tunnel);
>
>  /*
>   * Define VF Stats MACRO for Non "cleared on read" register
> @@ -495,6 +499,8 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
> .timesync_adjust_time = ixgbe_timesync_adjust_time,
> .timesync_read_time   = ixgbe_timesync_read_time,
> .timesync_write_time  = ixgbe_timesync_write_time,
> +   .udp_tunnel_add   = ixgbe_dev_udp_tunnel_add,
> +   .udp_tunnel_del   = ixgbe_dev_udp_tunnel_del,
>  };
>

Your patch is not adding HW tunnel support but port management.

>  /*
> @@ -6191,6 +6197,93 @@ ixgbe_dev_get_dcb_info(struct rte_eth_dev *dev,
> return 0;
>  }
>
> +#define DEFAULT_VXLAN_PORT 4789
> +
> +/* on x550, there's only one register for VxLAN UDP port.
> + * So, we cannot add or del the port. We only update it.
> + */
> +static int
> +ixgbe_update_vxlan_port(struct ixgbe_hw *hw,
> +   uint16_t port)
> +{
> +   IXGBE_WRITE_REG(hw, IXGBE_VXLANCTRL, port);
> +   IXGBE_WRITE_FLUSH(hw);
> +
> +   return 0;
> +}
> +
> +/* Add UDP tunneling port */
> +static int
> +ixgbe_dev_udp_tunnel_add(struct rte_eth_dev *dev,
> +struct rte_eth_udp_tunnel *udp_tunnel)
> +{
> +   int ret = 0;
> +   struct ixgbe_hw *hw =
IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> +   if (hw->mac.type != ixgbe_mac_X550 &&
> +   hw->mac.type != ixgbe_mac_X550EM_x) {
> +   return -ENOTSUP;
> +   }
> +
> +   if (udp_tunnel == NULL)
> +   return -EINVAL;
> +
> +   switch (udp_tunnel->prot_type) {
> +   case RTE_TUNNEL_TYPE_VXLAN:
> +   /* cannot add a port, update the port value */
> +   ret = ixgbe_update_vxlan_port(hw, udp_tunnel->udp_port);
> +   break;
> +
> +   case RTE_TUNNEL_TYPE_GENEVE:
> +   case RTE_TUNNEL_TYPE_TEREDO:
> +   PMD_DRV_LOG(ERR, "Tunnel type is not supported now.");
> +   ret = -1;
> +   break;
> +
> +   default:
> +   PMD_DRV_LOG(ERR, "Invalid tunnel type");
> +   ret = -1;
> +   break;
> +   }
> +
> +   return ret;
> +}

Is tunnel_add a proper naming? We need to keep flexibility for NICs that
will support full HW tunneling support.

Here it is about setting registers.

> +
> +/* Remove UDP tunneling port */
> +static int
> +ixgbe_dev_udp_tunnel_del(struct rte_eth_dev *dev,
> +struct rte_eth_udp_tunnel *udp_tunnel)
> +{
> +   int ret = 0;
> +   struct ixgbe_hw *hw =
IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> +   if (hw->mac.type != ixgbe_mac_X550 &&
> +   hw->mac.type != ixgbe_mac_X550EM_x) {
> +   return -ENOTSUP;
> +   }
> +
> +   if (udp_tunnel == NULL)
> +   return -EINVAL;
> +
> +   switch (udp_tunnel->prot_type) {
> +   case RTE_TUNNEL_TYPE_VXLAN:
> +   /* cannot del the port, reset it to default */
> +   ret = ixgbe_update_vxlan_port(hw, DEFAULT_VXLAN_PORT);
> +   break;
> +   case RTE_TUNNEL_TYPE_GENEVE:
> +   case RTE_TUNNEL_TYPE_TEREDO:
> +   PMD_DRV_LOG(ERR, "Tunnel type is not supported now.");
> +   ret = -1;
> +   break;
> +   default:
> +   PMD_DRV_LOG(ERR, "Invalid tunnel type");
> +   ret = -1;
> +   break;
> +   }
> +
> +   return ret;
> +}
> +
>  static struct rte_driver rte_ixgbe_driver = {
> .type = PMD_PDEV,
> .init = rte_ixgbe_pmd_init,
> --
> 1.9.3
>

I think the semantic of this serie should be revisited. It is about adding
the support of inner/outer 

[dpdk-dev] [PATCH] hash: fix CRC32c computation

[Vincent JARDIN]

Le 23 d?c. 2015 10:12, "Qiu, Michael"  a ?crit :
>
> Is it suitable to put so many code in commit log?

It is more explicit than a text/comment. I do not think it should be
maintained code.

>
> Thanks,
> Michael
> On 12/22/2015 5:36 PM, Didier Pallard wrote:
> > As demonstrated by the following code, CRC32c computation is not valid
> > when buffer length is not a multiple of 4 bytes:
> > (Output obtained by code below)
> >
> > CRC of 1 NULL bytes expected: 0x527d5351
> > soft: 527d5351
> > rte accelerated: 48674bc7
> > rte soft: 48674bc7
> > CRC of 2 NULL bytes expected: 0xf16177d2
> > soft: f16177d2
> > rte accelerated: 48674bc7
> > rte soft: 48674bc7
> > CRC of 2x1 NULL bytes expected: 0xf16177d2
> > soft: f16177d2
> > rte accelerated: 8c28b28a
> > rte soft: 8c28b28a
> > CRC of 3 NULL bytes expected: 0x6064a37a
> > soft: 6064a37a
> > rte accelerated: 48674bc7
> > rte soft: 48674bc7
> > CRC of 4 NULL bytes expected: 0x48674bc7
> > soft: 48674bc7
> > rte accelerated: 48674bc7
> > rte soft: 48674bc7
> >
> > Values returned by rte_hash_crc functions does not match the one
> > computed by a trivial crc32c implementation.
> >
> > ARM code is a guess, it is not tested, neither compiled.
> >
> > code showing the problem:
> >
> > uint8_t null_test[32] = {0};
> >
> > static uint32_t crc32c_trivial(uint8_t *buffer, uint32_t length,
uint32_t crc)
> > {
> > uint32_t i, j;
> > for (i = 0; i < length; ++i)
> > {
> > crc = crc ^ buffer[i];
> > for (j = 0; j < 8; j++)
> > crc = (crc >> 1) ^ 0x8000 ^ ((~crc & 1) * 0x82f63b78);
> > }
> > return crc;
> > }
> >
> > void hash_test(void);
> > void hash_test(void)
> > {
> >   printf("CRC of 1 nul byte expected: 0x527d5351\n");
> >   printf("soft: %08x\n", crc32c_trivial(null_test, 1, 0));
> >   rte_hash_crc_init_alg();
> >   printf("rte accelerated: %08x\n", ~rte_hash_crc(null_test, 1,
0x));
> >   rte_hash_crc_set_alg(CRC32_SW);
> >   printf("rte soft: %08x\n", ~rte_hash_crc(null_test, 1,
0x));
> >
> >   printf("CRC of 2 nul bytes expected: 0xf16177d2\n");
> >   printf("soft: %08x\n", crc32c_trivial(null_test, 2, 0));
> >   rte_hash_crc_init_alg();
> >   printf("rte accelerated: %08x\n", ~rte_hash_crc(null_test, 2,
0x));
> >   rte_hash_crc_set_alg(CRC32_SW);
> >   printf("rte soft: %08x\n", ~rte_hash_crc(null_test, 2,
0x));
> >
> >   printf("CRC of 2x1 nul bytes expected: 0xf16177d2\n");
> >   printf("soft: %08x\n", crc32c_trivial(null_test, 1,
crc32c_trivial(null_test, 1, 0)));
> >   rte_hash_crc_init_alg();
> >   printf("rte accelerated: %08x\n", ~rte_hash_crc(null_test, 1,
rte_hash_crc(null_test, 1, 0x)));
> >   rte_hash_crc_set_alg(CRC32_SW);
> >   printf("rte soft: %08x\n", ~rte_hash_crc(null_test, 1,
rte_hash_crc(null_test, 1, 0x)));
> >
> >   printf("CRC of 3 nul bytes expected: 0x6064a37a\n");
> >   printf("soft: %08x\n", crc32c_trivial(null_test, 3, 0));
> >   rte_hash_crc_init_alg();
> >   printf("rte accelerated: %08x\n", ~rte_hash_crc(null_test, 3,
0x));
> >   rte_hash_crc_set_alg(CRC32_SW);
> >   printf("rte soft: %08x\n", ~rte_hash_crc(null_test, 3,
0x));
> >
> >   printf("CRC of 4 nul bytes expected: 0x48674bc7\n");
> >   printf("soft: %08x\n", crc32c_trivial(null_test, 4, 0));
> >   rte_hash_crc_init_alg();
> >   printf("rte accelerated: %08x\n", ~rte_hash_crc(null_test, 4,
0x));
> >   rte_hash_crc_set_alg(CRC32_SW);
> >   printf("rte soft: %08x\n", ~rte_hash_crc(null_test, 4,
0x));
> > }
> >
> > Signed-off-by: Didier Pallard 
> > Acked-by: David Marchand 
> > ---
> >  lib/librte_hash/rte_crc_arm64.h |  64 
> >  lib/librte_hash/rte_hash_crc.h  | 125
+++-
> >  2 files changed, 162 insertions(+), 27 deletions(-)
> >
> > diff --git a/lib/librte_hash/rte_crc_arm64.h
b/lib/librte_hash/rte_crc_arm64.h
> > index 02e26bc..44ef460 100644
> > --- a/lib/librte_hash/rte_crc_arm64.h
> > +++ b/lib/librte_hash/rte_crc_arm64.h
> > @@ -50,6 +50,28 @@ extern "C" {
> >  #include 
> >
> >  static inline uint32_t
> > +crc32c_arm64_u8(uint8_t data, uint32_t init_val)
> > +{
> > + asm(".arch armv8-a+crc");
> > + __asm__ volatile(
> > + "crc32cb %w[crc], %w[crc], %b[value]"
> > + : [crc] "+r" (init_val)
> > + : [value] "r" (data));
> > + return init_val;
> > +}
> > +
> > +static inline uint32_t
> > +crc32c_arm64_u16(uint16_t data, uint32_t init_val)
> > +{
> > + asm(".arch armv8-a+crc");
> > + __asm__ volatile(
> > + "crc32ch %w[crc], %w[crc], %h[value]"
> > + : [crc] "+r" (init_val)
> > + : [value] "r" (data));
> > + 

[dpdk-dev] VFIO no-iommu

[Vincent JARDIN]

On 17/12/2015 20:38, Jan Viktorin wrote:
> which platforms (or computer systems) I am targeting?

It is about VMs on IOMMU capable systems. What if you need to use SRIOV 
with IXGBE, or IGB devices?

For some DPDK cases, like Mellanox or virtio, you do not need to use 
VFIO/UIO into the guests, so no issue. But for some other PMDs, you need 
a VFIO/UIO.

Best regards,
   Vincent

[dpdk-dev] releases scheduling

[Vincent JARDIN]

On 15/12/2015 22:15, Wiles, Keith wrote:
> I see the YY.MM.PP (PP is patch number) as the simplest way to keep track of 
> when a release was done.

+1

I like it.

[dpdk-dev] VFIO no-iommu

[Vincent JARDIN]

Thanks Thomas for putting back this topic.

Alex,

I'd like to hear more about the impacts of "unsupported":
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=033291eccbdb1b70ffc02641edae19ac825dc75d
   Use of this mode, specifically binding a device without a native
   IOMMU group to a VFIO bus driver will taint the kernel and should
   therefore not be considered supported.

It means that we get ride of uio; so it is a nice code cleanup: but why 
would VFIO/NO IOMMU be better if the bottomline is "unsupported"?

Thank you,
   Vincent

On 11/12/2015 17:28, Thomas Monjalon wrote:
> Recently there were some discussions to have an upstream replacement
> for our igb_uio module.
> Several solutions were discussed (new uio driver, uio_pci_generic, vfio):
>   https://lkml.org/lkml/2015/10/16/700
>
> Alex Williamson (maintainer of VFIO driver), submitted a solution
> and was waiting some feedback. Unfortunately, nobody caught it and
> he has reverted his work:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ae5515d
>
> It is an important challenge to remove our out-of-tree modules and
> especially igb_uio. It is a long way to have a standard solution integrated
> in every distributions.
> The current cooking Linux kernel is 4.4 and will have a long term maintenance:
>   https://kernel.org/releases.html
> So it is a pity to miss this opportunity.
>
> Stephen has fixed a bug to use the IOMMU group zero:
>   http://dpdk.org/browse/dpdk/commit/?id=22215f141b1
>
> Is there someone interested to work on VFIO no-iommu and provide
> some feedbacks?
> We also need to prepare a documentation patch to explain its usage
> compared to the standard VFIO mode.
>
> Thanks
>

[dpdk-dev] 2.3 Roadmap

[Vincent JARDIN]

On 01/12/2015 15:27, Panu Matilainen wrote:
> The problem with that (unless I'm missing something here) is that KNI
> requires using out-of-tree kernel modules which makes it pretty much a
> non-option for distros.

It works fine with some distros. I do not think it should be an argument.

[dpdk-dev] [PATCH v6 0/7] support for netronome nfp-6xxx card

[Vincent JARDIN]

On 05/11/2015 11:43, Alejandro.Lucero wrote:
> From: "Alejandro.Lucero" 
>
> This patchset adds a new PMD for Netronome nfp-6xxx card.
> Just PCI Virtual Functions supported.
> Using this PMD requires previous Netronome BSP installation.
>

I understand that this PMD needs a kernel driver which is not upstream 
yet. Am I correct?

https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/drivers/net/ethernet


Best regards,
   Vincent

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Vincent JARDIN]

Le 3 nov. 2015 23:05, "Bagh Fares"  a ?crit :
>
> Tim
> Good clafication. What is the governance model. Can you point me to it?
Thanks

First sentence of
  http://dpdk.org/dev
is
" Anyone is welcome to contribute."

Best regards,

>
> -Original Message-
> From: O'Driscoll, Tim [mailto:tim.odriscoll at intel.com]
> Sent: Tuesday, November 03, 2015 6:43 AM
> To: Pradeep Kathail ; Bagh Fares-B25033 <
Fares.Bagh at freescale.com>; Dave Neary ; CHIOSI, 
MARGARET
T ; Stephen Hemminger ;
dev at dpdk.org
> Subject: RE: [dpdk-dev] Proposals from project governance meeting at DPDK
Userspace (was Notes from ...)
>
>
> > -Original Message-
> > From: Pradeep Kathail [mailto:pkathail at cisco.com]
> > Sent: Monday, November 2, 2015 11:16 PM
> > To: O'Driscoll, Tim; Bagh Fares; Dave Neary; CHIOSI, MARGARET T;
> > Stephen Hemminger
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] Proposals from project governance meeting at
> > DPDK Userspace (was Notes from ...)
> >
> > Tim and Dave,
> >
> > I agree that an architecture board membership should be based on
> > technical standing and contribution but at the same time, if you are
> > trying to bring a new hardware paradigm into a project, you need to
> > give a chance to some of those experts to participate and gain the
> > standing.
> >
> > If community is serious about supporting SOC's, my suggestion will be
> > to allow few (2?) members from SOC community for limited time (6?
> > months) and then evaluate based on their contributions.
>
> I think we might be talking about 2 slightly different things. You're
asking how new contributors can participate and gain technical credibility.
Anybody can do that via the dev at dpdk.org mailing list. I'm sure patches,
RFCs or discussions on changes required in DPDK to better facilitate SoCs
will be welcomed. There have been some good examples of this over the last
few days on ARMv7/v8 support and a NEON-based ACL implementation.
>
> The Architecture Board isn't intended as a forum for design discussions,
which I think might be what you're looking for. It's intended to meet only
occasionally to cover the items outlined in the proposal. We discussed
composition of the board recently in Dublin and the community decided that,
while users and potential contributors have an important role to play in
the project, it should be composed solely of contributors. Dave Neary
summed it up well in a previous email on this: "The TSC should be
representative of the technical contributors to the project, rather than an
aspirational body aiming to get more people involved."
>
> It would be interesting to hear the thoughts of others on whether we
should consider an exception in this case.
>
>
> Tim
>
> >
> > Pradeep
> >
> > On 11/2/15 1:44 PM, O'Driscoll, Tim wrote:
> > >> -Original Message-
> > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bagh Fares
> > >> Sent: Monday, November 2, 2015 6:03 PM
> > >> To: Dave Neary; CHIOSI, MARGARET T; Stephen Hemminger
> > >> Cc: dev at dpdk.org; Pradeep Kathail (pkathail at cisco.com)
> > >> Subject: Re: [dpdk-dev] Proposals from project governance meeting
> > >> at DPDK Userspace (was Notes from ...)
> > >>
> > >> Yes. Thank you. What we like is to get to a point where we discuss
> > API
> > >> and align on APIs for SOC as Margaret mention. As you know Arm has
> > been
> > >> driving ODP as the API for SOC.
> > >> What we like to do is to drive the APIs under DPDK even for Arm SOC.
> > >> Long term, and based on shrinking silicon geometries, and desire to
> > fill
> > >> fabs, Intel will do more SOCs. I was SOC design manager in Intel
> > >> :-) We like to spare the customers like red hat, Cisco, and ATT the
> > >> pain
> > of
> > >> supporting multiple APIs and code bases.
> > > That's our goal too, so it's good to hear that we're in agreement on
> > this.
> > >
> > >> So we need have a forum/place where this can be worked at .
> > > If you have some ideas, then the best way to get some discussion
> > > going
> > is through the mailing list. You could post a set of patches for
> > proposed changes, a higher-level RFC outlining your thoughts, or just
> > specific questions/issues that you see.
> > >
> > > On the TSC that was specifically referenced earlier in this thread,
> > there is a proposal for what we're now calling the Architecture Board
> > at: http://dpdk.org/ml/archives/dev/2015-October/026598.html. As Dave
> > mentioned, we agreed at our recent Userspace event in Dublin that
> > membership of the board should be based on contributions and technical
> > standing in the community. The board will review and approve new
> > members on an annual basis.
> > >
> > >> We are reaching out and we like to feel welcome and some love :-)
> > > As Thomas already said, new contributors are always welcome!
> > >
> > >
> > > Tim
> > >
> > >
> > >> -Original Message-
> > >> From: Dave Neary [mailto:dneary at redhat.com]
> > >> Sent: Monday, November 02, 2015 11:55 AM
> > 

[dpdk-dev] [dpdk-dev, PATCHv5, 1/8] ethdev: add new API to retrieve RX/TX queue information

[Vincent JARDIN]

On 20/10/2015 09:53, Qiu, Michael wrote:
> But as I know it is different all the time, am I right?
> If yes, I don't know what's the value of this field.

It can be used to get some snapshot/instant view informations while we 
have to monitor and debug.

[dpdk-dev] DPDK User Space: Session onUseability and Ease of Use

[Vincent JARDIN]

Thomas, John,

thanks for your notes.

Enclosed the contents of our chats,

On 13/10/2015 18:36, Mcnamara, John wrote:
> * PMD lite
>
>- Do we need a lighter PMD model? Perhaps based on the Mellanox
>  model.
>- Vincent suggested be could remove 90% of the code. I'll leave
>  Vincent explain this one.

benefits of 100% userland drivers:
   - no dependency on getting kernel patch upstreams first
   - it is possible to run on a latest HW even when the Linux host (or 
host OS) does not support the new NIC/boards supported by the DPDK

drawbacks of 100% userland drivers:
   - redundancy of source code (duplication into the kernel and userland)
   => more maintenance
   - DPDK PMDs are in fact outdated while kernel drivers are supporting 
latest HW (port management - optics - , latest HW revisions, managing 
firmware updates) more frequently
   - do not run when not root applications
   - cannot reuse port management tools from the kernels (ethtool, etc.)

ixgbe pmd
=
100% lines of userland
must be run as root
~ 40K lines
~ kernel overlaps with 
http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/base
~ mostly only 
http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/ixgbe_rxtx[_vec].c is 
needed, other files are not needed (6k lines of code)

mlx4 pmd

10% lines userland, then using kernel's ones
could be run as a non root process
~ 5.2K lines of code
~ the rxtx.c file is http://dpdk.org/browse/dpdk/tree/drivers/net/mlx4/
BUT using infiniband :( => should be cleand up to use bare minimum like,
 + /* Allocate protection domain. */
   http://dpdk.org/browse/dpdk/tree/drivers/net/mlx4/mlx4.c#n4828

 + Register memory regions -> ibv_reg_mr()
   http://dpdk.org/browse/dpdk/tree/drivers/net/mlx4/mlx4.c#n792

Best regards,
   Vincent

[dpdk-dev] DPDK User Space: Session onUseability and Ease of Use

[Vincent JARDIN]

On 13/10/2015 18:36, Mcnamara, John wrote:
> * Should DPDK applications be running as root
>
>- Clearly not a great option.
>
>- Currently required due to kernel.

It is not 100% accurate. With some systems, it shall be possible to run 
DPDK application without running them as root.

It was commented that there is a solution when PMDs are designed 
differently (verbs API => memory registration of users). Moreover, it 
would ease the cleanup of resources when a DPDK application does a segfault.

[dpdk-dev] DPDK User Space: Session onUseability and Ease of Use

[Vincent JARDIN]

On 13/10/2015 22:06, Thomas Monjalon wrote:
> 2015-10-13 16:36, Mcnamara, John:
>> >   - Move the EAL to the kernel.
> Please explain what you mean here.
> It's difficult to imagine.
>
+Martin at ARM on it. We were rising this topic with him last week.

[dpdk-dev] [PATCH 00/17] Enhance mlx5 with Mellanox OFED 3.1

[Vincent JARDIN]

Le 6 oct. 2015 09:54, "Stephen Hemminger"  a
?crit :
>
> On Mon,  5 Oct 2015 19:54:35 +0200
> Adrien Mazarguil  wrote:
>
> > Mellanox OFED 3.1 [1] comes with improved APIs that Mellanox ConnectX-4
> > (mlx5) adapters can take advantage of, such as:
> >
> > - Separate post and doorbell operations on all queues.
> > - Lightweight RX queues called Work Queues (WQs).
> > - Low-level RSS indirection table and hash key configuration.
> >
> > This patchset enhances mlx5 with all of these for better performance and
> > flexibility. Documentation is updated accordingly.
>
> Has anybody explored doing a driver without the dependency on OFED?
> It is certainly possible. The Linux kernel drivers don't depend on it.
> And dropping OFED would certainly be faster.

OFED is an established kernel API. I agree that F from infiniband should be
deprecated since it has broader scope of use.

It avoid wasting effort by duplicating kernel's code.

It provides security too that UIO could not provide.

Best regards,
  Vincent

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

[Vincent JARDIN]

On 01/10/2015 11:43, Avi Kivity wrote:
>
> That is because the device itself contains an iommu.

Yes.

It could be an option:
   - we could flag the Linux system unsafe when the device does not have 
any IOMMU
   - we flag the Linux system safe when the device has an IOMMU

[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

[Vincent JARDIN]

On 01/10/2015 11:22, Avi Kivity wrote:
>> As far as I could see, without this kind of motivation, people do not
>> even want to try.
>
> You are mistaken.  The problem is a lot harder than you think.
>
> People didn't go and write userspace drivers because they were lazy.
> They wrote them because there was no other way.

I disagree, it is possible to write a 'partial' userspace driver.

Here it is an example:
   http://dpdk.org/browse/dpdk/tree/drivers/net/mlx4

It benefits of the kernel's capabilities while the userland manages only 
the IOs.

There were some tentative to get it for other (older) drivers, named 
'bifurcated drivers', but it is stalled.

best regards,
   Vincent

[dpdk-dev] [PATCH v4 01/12] ixgbe: support VMDq RSS in non-SRIOV environment

[Vincent JARDIN]

On 12/08/2015 10:02, Ouyang Changchun wrote:
> +#define VMDQ_RSS_RX_QUEUE_NUM_MAX 4
> +
> +static int
> +rte_eth_dev_check_vmdq_rss_rxq_num(__rte_unused uint8_t port_id, uint16_t 
> nb_rx_q)
> +{
> + if (nb_rx_q > VMDQ_RSS_RX_QUEUE_NUM_MAX)
> + return -EINVAL;
> + return 0;
> +}
> +

it is an ixgbe limitation, so, it should not be a included into 
librte_ether/rte_ethdev.c

[dpdk-dev] [PATCH 2/2] virtio: allow running w/o vlan filtering

[Vincent JARDIN]

> Use '--disable-hw-vlan-filter'  in testpmd command line will allow it 
> continue to work.
> You can have a try.

Yes, but not using this flag should not imply to exit.

> I am not sure which one is better when app configures one feature but fail to 
> negotiate it with host(which means has
> no such capability to support this feature currently).
> 1)The driver cheat the app, and continue to do the rest of work(of course 
> need some hints).
> 2)give hints and exit, then user re-run app with correct configuration.

Same as Stephen:

3) give hints of capabilities, do not exit, then user app does whatever 
it wants (including exit if needed).

Thank you,

[dpdk-dev] [PATCH 2/2] virtio: allow running w/o vlan filtering

[Vincent JARDIN]

Thomas, Changchun,

On 29/07/2015 14:56, Thomas Monjalon wrote:
> Back on this old patch, it seems justified but nobody agreed.
>
> --- a/lib/librte_pmd_virtio/virtio_ethdev.c
> +++ b/lib/librte_pmd_virtio/virtio_ethdev.c
> @@ -1288,7 +1288,6 @@ virtio_dev_configure(struct rte_eth_dev *dev)
>  && !vtpci_with_feature(hw, VIRTIO_NET_F_CTRL_VLAN)) {
>  PMD_DRV_LOG(NOTICE,
>  "vlan filtering not available on this host");
> -   return -ENOTSUP;
>  }
>
> 2015-03-06 08:24, Stephen Hemminger:
>> "Ouyang, Changchun"  wrote:
 From: Stephen Hemminger
 Vlan filtering is an option, and not a requirement.
 If host does not support filtering then it can be done in software.

+1 with Stephen, remove return -ENOTSUP;

applications must not fail, software stacks will handle it. We did 
experiment some issues when testpmd was failing while it was supposed to 
run. A notice would be good enough.


>>>
>>> The question is that guest only send command, no real action to do the vlan 
>>> filter.
>>> So if both host and guest have no real action for vlan filter, who will do 
>>> it?
>>
>> The virtio driver has features.
>> Guest can not send commands to host where feature bit not enabled.
>> Application can call filter_set and check if filter worked or not.
>>
>> Our code already had to do MAC and VLAN validation of incoming packets
>> therefore if hardware can't do vlan match, there is no problem.
>> I would expect other applications would do the same thing.
>>
>> Failing during configuration is bad. DPDK API should never force
>> application to play "guess the working configuration" with the device
>> driver or do string match on "which device is this anyway"

Agree, it is not a failure of a configuration, it is a failure of 
negotiation of virtio's capabilities.

Let's use another example: we do not expect a guest kernel to panic() 
because it is not properly negotiated? So why should a DPDK application 
fail and return -ENOTSUP?

Thank you,
   Vincent

[dpdk-dev] [dpdk-announce] important design choices - statistics - ABI

[Vincent JARDIN]

On 18/06/2015 18:55, O'Driscoll, Tim wrote:
> I like Olivier's proposal on using a single option (CONFIG_RTE_NEXT_ABI) to 
> control all of these changes instead of a separate option per patch set 
> (seehttp://dpdk.org/ml/archives/dev/2015-June/019147.html), so I think we 
> should rework the affected patch sets to use that approach for 2.1.

Do we have any other options to meet the short deadlines of 2.1?

[dpdk-dev] [dpdk-announce] important design choices - statistics - ABI

[Vincent JARDIN]

On 17/06/2015 14:14, Panu Matilainen wrote:
> (initially accidentally sent to announce, resending to dev)
>
> On 06/17/2015 01:35 PM, Neil Horman wrote:
>> On Wed, Jun 17, 2015 at 01:29:47AM +0200, Thomas Monjalon wrote:
>>> Hi all,
>>>
>>> Sometimes there are some important discussions about architecture or
>>> design
>>> which require opinions from several developers. Unfortunately, we cannot
>>> read every threads. Maybe that using the announce mailing list will help
>>> to bring more audience to these discussions.
>>> Please note that
>>> - the announce@ ML is moderated to keep a low traffic,
>>> - every announce email is forwarded to dev@ ML.
>>> In case you want to reply to this email, please use dev at dpdk.org
>>> address.
>>>
>>> There were some debates about software statistics disabling.
>>> Should they be always on or possibly disabled when compiled?
>>> We need to take a decision shortly and discuss (or agree) this proposal:
>>> http://dpdk.org/ml/archives/dev/2015-June/019461.html
>>>
>>> During the development of the release 2.0, there was an agreement to
>>> keep
>>> ABI compatibility or to bring new ABI while keeping old one during
>>> one release.
>>> In case it's not possible to have this transition, the (exceptional)
>>> break
>>> should be acknowledged by several developers.
>>> http://dpdk.org/doc/guides-2.0/rel_notes/abi.html
>>> There were some interesting discussions but not a lot of participants:
>>> http://thread.gmane.org/gmane.comp.networking.dpdk.devel/8367/focus=8461
>>>
>>>
>>> During the current development cycle for the release 2.1, the ABI
>>> question
>>> arises many times in different threads.
>>> To add the hash key size field, it is proposed to use a struct
>>> padding gap:
>>> http://dpdk.org/ml/archives/dev/2015-June/019386.html
>>> To support the flow director for VF, there is no proposal yet:
>>> http://dpdk.org/ml/archives/dev/2015-June/019343.html
>>> To add the speed capability, it is proposed to break ABI in the
>>> release 2.2:
>>> http://dpdk.org/ml/archives/dev/2015-June/019225.html
>>> To support vhost-user multiqueues, it is proposed to break ABI in 2.2:
>>> http://dpdk.org/ml/archives/dev/2015-June/019443.html
>>> To add the interrupt mode, it is proposed to add a build-time option
>>> CONFIG_RTE_EAL_RX_INTR to switch between compatible and ABI breaking
>>> binary:
>>> http://dpdk.org/ml/archives/dev/2015-June/018947.html
>>> To add the packet type, there is a proposal to add a build-time option
>>> CONFIG_RTE_NEXT_ABI common to every ABI breaking features:
>>> http://dpdk.org/ml/archives/dev/2015-June/019172.html
>>> We must also better document how to remove a deprecated ABI:
>>> http://dpdk.org/ml/archives/dev/2015-June/019465.html
>>> The ABI compatibility is a new constraint and we need to better
>>> understand
>>> what it means and how to proceed. Even the macros are not yet well
>>> documented:
>>> http://dpdk.org/ml/archives/dev/2015-June/019357.html
>>>
>>> Thanks for your attention and your participation in these important
>>> choices.
>>>
>>
>> Thomas-
>> Just to re-iterate what you said earlier, and what was discussed
>> in the
>> previous ABI discussions
>>
>> 1) ABI stability was introduced to promote DPDK's ability to be
>> included with
>> various linux and BSD distributions.  Distributions, by and large, favor
>> building libraries as DSO's, favoring security and updatability in
>> favor of all
>> out performance.
>>
>> 2) The desire was to put DPDK developers in a mindset whereby ABI
>> stability was
>> something they needed to think about during development, as the DPDK
>> exposes
>> many data structures and instances that cannot be changed without
>> breaking ABI
>>
>> 3) The versioning mechanism was introduced to allow for backward
>> compatibility
>> during periods in which we needed to support both an old an new ABI
>>
>> 4) As Stephan and others point out, its not expected that we will
>> always be able
>> to maintain ABI, and as such an easy library versioning mechanism was
>> introduced
>> to prevent the loading of an incompatible library with an older
>> application
>>
>> 5) The ABI policy was introduced to create a method by which new ABI
>> facets
>> could be scheduled while allowing distros to prepare their downstream
>> users for
>> the upcomming changes.
>>
>>
>> It seems to me, looking back over these last few months, that we're
>> falling down
>> a bit on our use of (3).  I've seen several people take advantage of
>> the ABI
>> scheduled updates, but no one has tried the versioning interface, and
>> as a
>> result patches are getting delayed, which was never my intent.  Not
>> sure whats
>> to be done about that, but we should probably address it.  Is use of the
>> versionnig interface just too hard or convoluted?
>
> To me it seems that by far the biggest problem with ABI stability in
> DPDK is features requiring changes to public structs (often directly
> 

[dpdk-dev] [PATCH v9 12/12] abi: fix v2.1 abi broken issue

[Vincent JARDIN]

On 29/05/2015 10:45, Cunming Liang wrote:
> RTE_EAL_RX_INTR will be removed from v2.2. It's only used to avoid 
> ABI(unannounced) broken in v2.1.
> The usrs should make sure understand the impact before turning on the feature.
> There are two abi changes required in this interrupt patch set.
> They're 1) struct rte_intr_handle; 2) struct rte_intr_conf.
>
> Signed-off-by: Cunming Liang

Acked-by: vincent jardin 

[dpdk-dev] DPDK: Proposal for a patch patch-test integration tree

[Vincent JARDIN]

On 27/05/2015 22:48, Thomas F Herbert wrote:
> Work Flow and Process:
>
> All patches will be taken from from public submissions to dpdk-dev.org
> scraped from dpdk patchwork. Patches will be applied to the patch-test
> tree and tested against HEAD as they are received. The feedback from the
> testing will be provided to the community. The patch-test tree will
> periodically be git pull'ed from dpdk.
>
> Longer term goal:
>
> Initially, the patches will be applied along with some simple smoke
> tests. The longer term goal is to automate this process, apply more
> extensive tests and post the results in dpdk patchwork,
> http://dpdk.org/dev/patchwork/project/dpdk/list/ which would have an
> accompanying mailing list for distribution of a results summary of the
> tests.

thanks for helping.

It could be broken into two parts:
   - patch-test-net-next,
http://dpdk.org/browse/dpdk/tree/MAINTAINERS#n190
http://dpdk.org/browse/dpdk/tree/drivers/net

   - patch-test-other-next,
all, excepted drivers

Best regards,
   Vincent

[dpdk-dev] dev@DPDK Hackathon Proposal

[Vincent JARDIN]

On 19/05/2015 07:18, Butler, Siobhan A wrote:
>> Also related to this, I would hope to participate in any discussion about OVS
>> >acceration and vhost/guest access acceleration.

We need to have this track with both:
   - Qemu/kvm/libvirt session during the LinuxCon,
   - virtio session during the LinuxConf

[dpdk-dev] dev@DPDK Hackathon Proposal

[Vincent JARDIN]

On 19/05/2015 05:59, O'Driscoll, Tim wrote:
> a) Save the date. October 8th/9th, immediately after the European LinuxCon, 
> in Dublin Ireland.
> b) Think about topics that you'd like to see covered. We'll solicit for 
> inputs when the formal announcement is made, but it's good for people to 
> begin thinking about this now.

Good idea, thanks for the reminders.

Some topics on top of my head:
   - community updates & workflow
   - status of PMDs: where are we comming from and where does it go
   -> should it converge with OS' drivers?
   - status of bifurcated drivers & security issues raised on netdev, 
any alternative?
   - status of testing:
   -> dts
   -> smoking tests

Best regards,
   Vincent

[dpdk-dev] [PATCH v4 17/26] virtio: Use port IO to get PCI resource.

[Vincent JARDIN]

On 11/02/2015 05:50, Ouyang, Changchun wrote:
> As we know proc/ioports hasn't interrupt, 6wind implementation also don't 
> introduce interrupt in it.
correct, it is running without interrupt, they are not mandatory.

[dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct

[Vincent JARDIN]

>> +charifname[32]; /** Name of the tap device **/
>
> Linux and BSD the maximum network device name size is 16
>
In any case, please, use IF_NAMESIZE or IFNAMSIZ

see:
http://fxr.watson.org/fxr/ident?v=FREEBSD51;im=bigexcerpts;i=IF_NAMESIZE

[dpdk-dev] Fwd: FOSDEM conference - call for participation

[Vincent JARDIN]

Le 17 d?c. 2014 04:15, "Stephen Hemminger"  a
?crit :
>
> On Fri, 31 Oct 2014 15:53:19 -0700 (PDT)
> Thomas Monjalon  wrote:
>
> > Hi,
> >
> > Talks related to DPDK can be proposed for FOSDEM 2015:
> >   https://fosdem.org/2015/
> > This conference will take place in Belgium on 31 January & 1 February.
> >
>
> Did DPDK make it in the schedule or not?

Still waiting for the schedule as far as I know.

[dpdk-dev] virtio merging - no UIO

[Vincent JARDIN]

 From today's call, I'd like to highlight that virtio-net-pmd (said code 
B - from 6WIND) does not require UIO; it was required for some security 
reasons of the guest Linux OS:
   http://dpdk.org/browse/virtio-net-pmd/tree/virtio_user.c#n1494

Thank you,
   Vincent

[dpdk-dev] [PATCH v4 00/10] VM Power Management

[Vincent JARDIN]

Tim,

cc-ing Paolo and qemu-devel@ again in order to get their take on it.

>>> Did you make any progress in Qemu/KVM community?
>>> We need to be sync'ed up with them to be sure we share the same goal.
>>> I want also to avoid using a solution which doesn't fit with their plan.
>>> Remember that we already had this problem with ivshmem which was
>>> planned to be dropped.
>>>

>> Unfortunately, I have not yet received any feedback:
>> http://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg01103.html
>
> Just to add to what Alan said above, this capability does not exist in qemu 
> at the moment, and based on there having been no feedback on the qemu mailing 
> list so far, I think it's reasonable to assume that it will not be 
> implemented in the immediate future. The VM Power Management feature has also 
> been designed to allow easy migration to a qemu-based solution when this is 
> supported in future. Therefore, I'd be in favour of accepting this feature 
> into DPDK now.
>
> It's true that the implementation is a work-around, but there have been 
> similar cases in DPDK in the past. One recent example that comes to mind is 
> userspace vhost. The original implementation could also be considered a 
> work-around, but it met the needs of many in the community. Now, with support 
> for vhost-user in qemu 2.1, that implementation is being improved. I'd see VM 
> Power Management following a similar path when this capability is supported 
> in qemu.

Best regards,
   Vincent

[dpdk-dev] bifurcated driver

[Vincent JARDIN]

+Or

On 05/11/2014 23:48, Zhou, Danny wrote:
> Hi Thomas,
>
> Thanks for sharing the links to ibverbs, I will take a close look at it and 
> compare it to bifurcated driver. My take
> after a rough review is that idea is very much similar, but bifurcated driver 
> implementation is generic for any
> Ethernet device based on existing af_packet mechanism, with extension of 
> exchanging the messages between
> user space and kernel space driver.
>
> I have an internal document to summary the pros and cons of below solutions, 
> except for ibvers, but
> will be adding it shortly.
>
> - igb_uio
> - uio_pci_generic
> - VFIO
> - bifurcated driver
>
> Short answers to your questions:
>>  - upstream status
> Adding IOMMU based memory protection and generic descriptor description 
> support now, into version 2
> kernel patches.
>
>>  - usable with kernel netdev
> af_packet based, and relevant patchset will be submitted to netdev for sure.
>
>>  - usable in a vm
> No, it does no coexist with SRIOV for number of reasons. but if you 
> pass-through a PF to a VM, it works perfect.
>
>>  - usable for Ethernet
> It could work with all Ethernet NICs, as flow director is available and NIC 
> driver support new net_ops to split off
> queue pairs for user space.
>
>>  - hardware requirements
> No specific hardware requirements. All mainstream NICs have multiple qpairs 
> and flow director support.
>
>>  - security protection
> Leverage IOMMU to provide memory protection on Intel platform. Other archs 
> provide similar memory protection
> mechanism, so we only use arch-agnostic DMA memory allocation APIs in kernel 
> to support memory protection.
>
>>  - performance
> DPDK native performance on user space queues, as long as drop_en is enabled 
> to avoid head-of-line blocking.
>
> -Danny
>
>> -Original Message-
>> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> Sent: Wednesday, November 05, 2014 9:01 PM
>> To: Zhou, Danny
>> Cc: dev at dpdk.org; Fastabend, John R
>> Subject: Re: [dpdk-dev] bifurcated driver
>>
>> Hi Danny,
>>
>> 2014-10-31 17:36, O'driscoll, Tim:
>>> Bifurcated Driver (Danny.Zhou at intel.com)
>>
>> Thanks for the presentation of bifurcated driver during the community call.
>> I asked if you looked at ibverbs and you wanted a link to check.
>> The kernel module is here:
>>  
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/infiniband/core
>> The userspace library:
>>  http://git.kernel.org/cgit/libs/infiniband/libibverbs.git
>>
>> Extract from Kconfig:
>> "
>> config INFINIBAND_USER_ACCESS
>>  tristate "InfiniBand userspace access (verbs and CM)"
>>  select ANON_INODES
>>  ---help---
>>Userspace InfiniBand access support.  This enables the
>>kernel side of userspace verbs and the userspace
>>communication manager (CM).  This allows userspace processes
>>to set up connections and directly access InfiniBand
>>hardware for fast-path operations.  You will also need
>>libibverbs, libibcm and a hardware driver library from
>>.
>> "
>>
>> It seems to be close to the bifurcated driver needs.
>> Not sure if it can solve the security issues if there is no dedicated MMU
>> in the NIC.
>>
>> I feel we should sum up pros and cons of
>>  - igb_uio
>>  - uio_pci_generic
>>  - VFIO
>>  - ibverbs
>>  - bifurcated driver
>> I suggest to consider these criterias:
>>  - upstream status
>>  - usable with kernel netdev
>>  - usable in a vm
>>  - usable for ethernet
>>  - hardware requirements
>>  - security protection
>>  - performance
>>
>> --
>> Thomas

[dpdk-dev] Fwd: FOSDEM conference - call for participation

[Vincent JARDIN]

Stephen,

According to Dave (cc'd): it cannot be applied for FOSDEM; the 
organizers would not be happy if we proposed that.

Best regards,
   Vincent

On 01/11/2014 22:43, Stephen Hemminger wrote:
> Rather than individual talks what about getting them to schedule a 1/2 day
> unconference?
>
> On Fri, Oct 31, 2014 at 3:53 PM, Thomas Monjalon  6wind.com>
> wrote:
>
>> Hi,
>>
>> Talks related to DPDK can be proposed for FOSDEM 2015:
>>  https://fosdem.org/2015/
>> This conference will take place in Belgium on 31 January & 1 February.
>>
>> --
>> Thomas
>>
>>  Forwarded Message 
>> Subject: Network devroom call for participation
>> Date: Fri, 31 Oct 2014 17:33:33 -0400
>> From: Dave Neary 
>> To: Pavel Simerda ,
>> network-devroom at lists.fosdem.org, fosdem at lists.fosdem.org
>>
>> Hi everyone,
>>
>> We are pleased to announce the Call for Participation in the FOSDEM
>> 2015 Networking DevRoom!
>>
>> Important dates:
>> * Nov 25: Deadline for submissions
>> * Dec  1: Speakers notified of acceptance
>> * Dec  5: Schedule published
>>
>> This is the first time that networking has been included as a
>> stand-alone DevRoom, and this year the topics will cover two distinct
>> fields:
>> * Software Defined Networking (SDN), covering virtual switching, open
>> source SDN controllers, virtual routing
>> * Network management, covering host-level networking - NetworkManager,
>> ConnMan, systemd, wicked, kernel network services, network security, etc
>>
>>
>> We are now inviting proposals for talks about Free/Libre/Open-source
>> Software on the topics of SDN and network management. This is an
>> exciting and growing field, and this is a unique opportunity to show
>> novel ideas and developments to a very knowledgeable technical audience.
>>
>> Topics accepted include, but are not limited to:
>>
>> SDN:
>> * SDN controllers - OpenDaylight, OpenContrail, OpenStack Neutron
>> * Dataplane processing: DPDK, OpenDataplane, netdev, netfilter
>> * Virtual switches: Open vSwitch, Snabb Switch, VDE
>> * Open network protocols: OpenFlow, NETCONF, OpenLISP
>>
>> Network management:
>> * Network management: NetworkManager, ConnMan, systemd-networkd,
>> interoperability among these projects
>> * Common code infrastructure: libnl, libmnl, libsystemd, ell, pyroute2
>> * Network services: DHCP, DNS, DNSSEC, PPP
>> * Connection management: Wifi, tethering, connection sharing, metric and
>> source based routing,
>>
>> Talks should be aimed at a technical audience, but should not assume
>> that attendees are already familiar with your project or how it solves a
>> general problem. Talk proposals can be very specific solutions to a
>> problem, or can be higher level project overviews for lesser known
>> projects.
>>
>> Please include the following information when submitting a proposal:
>>
>>  Your name
>>  The title of your talk (please be descriptive, as titles will be
>> listed with around 250 from other projects)
>>  Short abstract of one or two paragraphs
>>  Short bio (with photo)
>>
>> The deadline for submissions is November 25th 2014. FOSDEM will be held
>> on the weekend of January 31st-February 1st 2015 and the Networking
>> DevRoom will take place on Saturday, January 31st 2015. Please use the
>> following website to submit your proposals:
>> https://penta.fosdem.org/submission/FOSDEM15 (you do not need to create
>> a new Pentabarf account if you already have one from past years).
>>
>> You can also join the devroom?s mailing list, which is the official
>> communication channel for the DevRoom: network-devroom at lists.fosdem.org
>> (subscription page: https://lists.fosdem.org/listinfo/network-devroom)
>>
>> ? The Networking DevRoom 2015 Organization Team
>>
>> --
>> Dave Neary - NFV/SDN Community Strategy
>> Open Source and Standards, Red Hat - http://community.redhat.com
>> Ph: +1-978-399-2182 / Cell: +1-978-799-3338
>>

[dpdk-dev] DPDK Community Conference Call - Friday 31st October

[Vincent JARDIN]

+1 for hangout
Le 1 nov. 2014 13:59, "Neil Horman"  a ?crit :

> On Fri, Oct 31, 2014 at 05:36:59PM +, O'driscoll, Tim wrote:
> > Thanks again to those who attended the call earlier. Hopefully people
> found it useful.
> >
> > We'll schedule a follow-up call for 2 weeks' time. One thing that we do
> want to look into is an easy way to allow screen sharing, so that we can
> use some slides to guide the discussion. Internally within Intel we use MS
> Lync. We can try that, but it's not always very user-friendly for external
> participants, and doesn't have a Linux client. Other options would include
> GoToMeeting or WebEx. If anybody has input on a good tool for this, let me
> know.
> >
> Don't use Lync, its a horrid tool.  As you note, there is no linux client
> (nor a
> mac client that I'm aware of).  Google hangouts offers screen sharing, and
> is
> free for anyone to use.
>
> > We covered the following features from our 2.0 list today, and will
> discuss the remainder on the next call. I've called out below who on our
> side was describing each of the features, and included their email
> addresses. If anybody has further questions on these, feel free to either
> ask openly on the mailing list, or else contact the relevant person
> directly.
> >
> > Bifurcated Driver (Danny.Zhou at intel.com)
> > Packet Reordering/Packet Distributor (Bruce.Richardson at intel.com)
> > New Hardware Support (Walter.E.Gilmore at intel.com)
> > Fortville features (Heqing.Zhu at intel.com)
> > Support Multiple Threads per Core (Venky.Venkatesan at intel.com)
> > Cuckoo Hash (Bruce.Richardson at intel.com, Venky.Venkatesan at intel.com)
> >
> > The Cuckoo Hash paper that was mentioned is available at:
> http://www.cs.cmu.edu/~dongz/papers/cuckooswitch.pdf.
> >
> > Finally, if anybody has suggestions for topics for future calls, please
> let me know.
> >
> ABI versioning, in support of packaging the DPDK for non-rebuilding users.
>
> Neil
>
> >
> > Thanks,
> > Tim
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'driscoll, Tim
> > > Sent: Friday, October 31, 2014 3:35 PM
> > > To: 'dev at dpdk.org'
> > > Subject: Re: [dpdk-dev] DPDK Community Conference Call - Friday 31st
> > > October
> > >
> > > This is just a reminder for anybody who's interested that this will be
> on in 30
> > > minutes, and that we'll be discussing the feature list for the DPDK
> 2.0 release
> > > in March 2015.
> > >
> > > Audio bridge details are:
> > > France: +33 1588 77298
> > > Germany:+49 8999 143191
> > > Israel: +972 2589 6577
> > > Russia: +7 495 641 4663
> > > UK: +44 1793 402663
> > > USA/Canada: +1 916 356 2663 or +1-888-875-9370
> > >
> > > Bridge: 5
> > > Conference ID: 1264677285
> > >
> > >
> > > Tim
> > >
> > > > -Original Message-
> > > > From: O'driscoll, Tim
> > > > Sent: Friday, October 24, 2014 10:22 AM
> > > > To: dev at dpdk.org
> > > > Subject: DPDK Community Conference Call - Friday 31st October
> > > >
> > > > We're planning to hold our first community conference call on Friday
> > > > 31st October. It's impossible to find a time that suits everybody, so
> > > > we've chosen to do this in the afternoon/evening in Europe, which is
> > > > the morning in the USA. This does unfortunately limit participation
> > > > from PRC, Japan and other parts of the world. Here's the time and
> date in a
> > > variety of time zones:
> > > >
> > > > Dublin (Ireland)  Friday, October 31, 2014 at
> > > > 4:00:00 PMGMT UTC
> > > > Paris (France)Friday, October 31, 2014
> at 5:00:00
> > > > PMCET UTC+1 hour
> > > > San Francisco (U.S.A. - California)   Friday, October 31, 2014
> at 9:00:00
> > > > AMPDT UTC-7 hours
> > > > New York (U.S.A. - New York)  Friday, October 31, 2014 at
> > > 12:00:00
> > > > Noon EDT UTC-4 hours
> > > > Tel Aviv (Israel) Friday, October 31, 2014 at
> > > 6:00:00
> > > > PMIST UTC+2 hours
> > > > Moscow (Russia)   Friday, October 31, 2014 at 7:00:00
> > > > PMMSK UTC+3 hours
> > > >
> > > >
> > > > Audio bridge details are:
> > > > France:   +33 1588 77298
> > > > Germany:  +49 8999 143191
> > > > Israel:   +972 2589 6577
> > > > Russia:   +7 495 641 4663
> > > > UK:   +44 1793 402663
> > > > USA:  +1 916 356 2663
> > > >
> > > > Bridge: 5
> > > > Conference ID: 1264677285
> > > >
> > > > If anybody needs an access number for another country, let me know.
> > > >
> > > >
> > > > Agenda:
> > > > Discuss feature list for DPDK 2.0 (Q1 2015).
> > > > Suggestions for topics for future calls.
> > > >
> > > >
> > > > Thanks,
> > > > Tim
> >
>

[dpdk-dev] [dpdk-announce] LinuxConf in Europe on Monday

[Vincent JARDIN]

FYI, on Monday, there will be a presentation of DPDK applications 
running with Openstack:
   http://sched.co/XnatsK

Best regards,
   Vincent

[dpdk-dev] MIT Fastpass: A Centralized "Zero-Queue" Datacenter Network

[Vincent JARDIN]

Good paper to read using DPDK:
http://fastpass.mit.edu/

[dpdk-dev] Is VFIO driver's performance better than IGB_UIO?

[Vincent JARDIN]

> My cpu is "Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz"

It is a Westmere if I am correct. So,use UIO.

[dpdk-dev] Is VFIO driver's performance better than IGB_UIO?

[Vincent JARDIN]

On 08/08/2014 09:41, Linhaifeng wrote:
> I have test the VFIO driver and IGB_UIO driver by l2fwd for many times. I 
> find that the VFIO driver?s performance is not better than the IGB_UIO.

You are right, under some conditions UIO is faster, VFIO provides
safety. The best solution is a PMD without UIO, neither VFIO.

which CPU are you using?

Best regards,
  Vincent

[dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of some isolated features

[Vincent JARDIN]

On 01/08/2014 16:06, Neil Horman wrote:
> Thats a multi year effort, and not something I'm prepared to even
> consider undertaking.

Sorry: I am not pushing you, it was just an open comment. I do agree 
that it is a multi year effort to get it down into a wide "agreed" 
community. DPDK community cannot manage it.

[dpdk-dev] [PATCH] skeleton app: Very simple code for l2fwding

[Vincent JARDIN]

> +#ifdef RTE_EXEC_ENV_BAREMETAL
>>+#define MAIN _main
>>+#else
>>+#define MAIN main
>>+#endif
>>+
>>+int MAIN(int argc, char *argv[]);
>>+
>>+#endif /* ifndef_MAIN_H_  */

why keeping the baremetal? It was dropped for a while.

Best regards,
   Vincent

[dpdk-dev] Ethtool support in DPDK pmd

[Vincent JARDIN]

On 02/06/2014 22:37, Chris Wright wrote:
> If drivers stayed in kernel and kernel drivers exposed a mechansim for
> registering application dma buffers for dpdk apps, then ethtool would
> simply work as-is.

Yes, that's the right way to go. Currently, the kernel does not provide 
a generic framework for that and I am not aware of any projects in order 
to define it. Could it be something to discuss on netdev@?

So, as a workaround, some proprietary solutions get implemented in order 
to get ethtool running with any DPDK PMD.

Best regards,
   Vincent

[dpdk-dev] Heads up: Fedora packaging plans

[Vincent JARDIN]

Neil,

 > Please find here:
 >   http://people.redhat.com/nhorman/dpdk-1.7.0-0.1.gitb20539d68.src.rpm

Your spec file is broken:

A simple patch:
--- dpdk.spec   2014-05-13 22:43:15.89200 +
+++ ../dpdk.spec.vj 2014-05-13 22:42:40.22100 +
@@ -75,7 +75,7 @@

  %build
  make O=%{target} T=%{target} config
-sed -ri 's,(RTE_MACHINE=).*,\1%{machine},  %{target}/.config
+sed -ri 's,(RTE_MACHINE=).*,\1%{machine},' %{target}/.config
  sed -ri 's,(RTE_APP_TEST=).*,\1n,' %{target}/.config
  sed -ri 's,(RTE_BUILD_SHARED_LIB=).*,\1y,' %{target}/.config
  make O=%{target} %{?_smp_mflags}

Best regards,
   Vincent

[dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to DPDK

[Vincent JARDIN]

On 02/05/2014 11:00, Burakov, Anatoly wrote:
> Hi Chris,
>
>> hmm, vfio requires iommu support, however virtio pmd?
>
> That's correct, virtio will not work with VFIO as it stands. However it's not 
> the fault of this patch but rather lack of emulated IOMMU on the guest :-)

My 2 cents:
   http://dpdk.org/browse/virtio-net-pmd/tree/README.rst
it works without UIO.

Best regards,
   Vincent

[dpdk-dev] hardware neutral driver for DPDK

[Vincent JARDIN]

librte_pmd_pcap
   http://dpdk.org/browse/dpdk/tree/lib/librte_pmd_pcap

On 06/03/2014 22:25, Neil Horman wrote:
> Hey there-
>   I'm interested in doing some work on the DPDK, specifically in creating
> a driver backend that interfaces to the kernel using AF_PACKET rather than a
> specific card for which a UIO or VFIO driver is available in kernel.  I think 
> it
> would be nice for the DPDK to have a hardware agnostic driver for development
> purposes.  Before I begin I wanted to make sure that something like this 
> hasn't
> already been done. I don't see any clear reference to one in the git repo, 
> but I
> figured I'd ask just to be sure there wasn't some external project in the 
> works
> already.
>
> Thanks & Regards
> Neil
>

[dpdk-dev] igb_uio fails on VirtualBox virtio

[Vincent JARDIN]

> I guess the referenced virtio-net-PMD below is dpdk1.3 compatible but
> not necessarily a newer version. So I assume will need to update it for
> 1.6, etc.

Where do you see that it does not support the latest on dpdk.org?
   http://dpdk.org/browse/virtio-net-pmd/log/virtio_user.c

About 1.6, stay tuned.

> So, can anyone confirm that the intel-provided virtio pmd with dpdk 1.6
> does NOT work with virtual box?

you have the source code...

Best regards,
   Vincent

[dpdk-dev] igb_uio fails on VirtualBox virtio

[Vincent JARDIN]

You should use another virtio because it avoids uio constraints.

I have been using it to run testpmd on Virtualbox longtime ago.

See http://dpdk.org/browse/virtio-net-pmd/

Best regards,
   Vincent
Le 8 f?vr. 2014 01:35, "Reda Haddad"  a ?crit :

> Hi,
>
> I am getting a "write error: No such device" when:
> echo  :00:08.0 > /sys/bus/pci/drivers/igb_uio/bind
>
> This is on Virtualbox with a virtio based adapter.
>
> This also fails when using the dpdk pci_unbind:
> ./tools/pci_unbind.py --bind=igb_uio 00:08.0
> Cannot bind to driver igb_uio
>
> I have read (http://dpdk.org/doc) that the dpdk (I am using version 1.6)
> supports virtio on virtual box. Is it truly supported?
> If yes, any clue on what is the problem?
>
> Thanks,
>
> Reda
>

[dpdk-dev] [ovs-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports.

[Vincent JARDIN]

Thomas,

First and easy answer: it is open source, so anyone can recompile. So, 
what's the issue?

> Without a concept of stable interfaces, it will be difficult to
> package and distribute RTE libraries, PMD, and DPDK applications. Right
> now, the obvious path would include packaging the PMD bits together
> with each DPDK application depending on the version of DPDK the binary
> was compiled against. This is clearly not ideal.

>
>> I agree that some areas could be improved since they are not into the
>> critical datapath of packets, but still other areas remain very CPU
>> constraints. For instance:
>> http://dpdk.org/browse/dpdk/commit/lib/librte_ether/rte_ethdev.h?id=c3d0564cf0f00c3c9a61cf72bd4bd1c441740637
>>
>> is bad:
>> struct eth_dev_ops
>> is churned, no comment, and a #ifdef that changes the structure
>> according to compilation!
>
> This is a very good example as it outlines the difference between
> control structures and the fast path. We have this same exact trade off
> in the kernel a lot where we have highly optimized internal APIs
> towards modules and drivers but want to provide binary compatibility to
> a certain extend.

As long as we agree on this limited scope, we'll think about it and 
provide a proposal on dev at dpdk.org mailing list.

> As for the specific example you mention, it is relatively trivial to
> make eth_dev_ops backwards compatible by appending appropriate padding
> to the struct before a new major release and ensure that new members
> are added by replacing the padding accordingly. Obviously no ifdefs
> would be allowed anymore.

Of course, it is basic C!

>> Should an application use the librte libraries of the DPDK:
>>- you can use RTE_VERSION and RTE_VERSION_NUM :
>> http://dpdk.org/doc/api/rte__version_8h.html#a8775053b0f721b9fa0457494cfbb7ed9
>
> Right. This would be more or less identical to requiring a specific
> DPDK version in OVS_CHEC_DPDK. It's not ideal to require application to
> clutter their code with #ifdefs all over for every new minor release
> though.
>
>>- you can write your own wrapper (with CPU overhead) in order to have
>> a stable ABI, that wrapper should be tight to the versions of the librte
>> => the overhead is part of your application instead of the DPDK,
>>- *otherwise recompile your software, it is opensource, what's the
>> issue?*
>>
>> We are opened to any suggestion to have stable ABI, but it should never
>> remove the options to have fast/efficient/compilation/CPU execution
>> processing.
>
> Absolutely agreed. We also don't want to add tons of abstraction and
> overcomplicate everything. Still, I strongly believe that the definition
> of stable interfaces towards applications and especially PMD is
> essential.
>
> I'm not proposing to standardize all the APIs towards applications on
> the level of POSIX. DPDK is in early stages and disruptive changes will
> come along. What I would propose on an abstract level is:
>
> 1. Extend but not break API between minor releases. Postpone API
> breakages to the next major release. High cadence of major
> releases initially, lower cadence as DPDK matures.
>
> 2. Define ABI stability towards PMD for minor releases to allow
> isolated packaging of PMD by padding control structures and keeping
> functions ABI stable.

I get lost: do you mean ABI + API toward the PMDs or towards the 
applications using the librte ?

Best regards,
   Vincent

[dpdk-dev] [ovs-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports.

[Vincent JARDIN]

Hi Thomas,

On 29/01/2014 09:15, Thomas Graf wrote:

 > The obvious and usual best practise would be for DPDK to guarantee
 > ABI stability between minor releases.
 >
 > Since dpdk-dev is copied as well, any comments?

DPDK's ABIs are not Kernel's ABIs, they are not POSIX, there is no 
standard. Currently, there is no such plan to have a stable ABI since we 
need to keep freedom to chase CPU cycles over having a stable ABI. For 
instance, some applications on top of the DPDK process the packets in 
less than 150 CPU cycles (have a look at testpmd:
   http://dpdk.org/browse/dpdk/tree/app/test-pmd )

I agree that some areas could be improved since they are not into the 
critical datapath of packets, but still other areas remain very CPU 
constraints. For instance:
http://dpdk.org/browse/dpdk/commit/lib/librte_ether/rte_ethdev.h?id=c3d0564cf0f00c3c9a61cf72bd4bd1c441740637
is bad:
struct eth_dev_ops
is churned, no comment, and a #ifdef that changes the structure 
according to compilation!

Should an application use the librte libraries of the DPDK:
   - you can use RTE_VERSION and RTE_VERSION_NUM :
http://dpdk.org/doc/api/rte__version_8h.html#a8775053b0f721b9fa0457494cfbb7ed9
   - you can write your own wrapper (with CPU overhead) in order to have 
a stable ABI, that wrapper should be tight to the versions of the librte 
=> the overhead is part of your application instead of the DPDK,
   - *otherwise recompile your software, it is opensource, what's the 
issue?*

We are opened to any suggestion to have stable ABI, but it should never 
remove the options to have fast/efficient/compilation/CPU execution 
processing.

Best regards,
   Vincent

[dpdk-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports.

[Vincent JARDIN]

Hi Pravin,

 >> Few feature questions:
>>- what's about the vNIC supports (toward the guests)?
>>- what's about IPsec support (VxLAN over IPsec for instance)?
>> I do not understand how your patch will solve those 2 cases.
>>
> At this point I wanted to get basic DPDK support in OVS, once that is
> done we can add support for vNIC.

For vNIC, did you notice:
   http://dpdk.org/browse/memnic/
?

> IPsec and vxlan or any L3 tunneling requires IP stack in userspace and
> needs more design work.

OK, understood.

> This is based a patch from Gerald Rogers.
>>
>> Please which patch? I cannot find it into the archives.
>>
> It was directly sent to Jesse at Nicira. If you want I can send it out for 
> ref.

Yes, please.

Thank you,
   Vincent

[dpdk-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports.

[Vincent JARDIN]

Hi Pravin,

Yes, it is a good integration with http://dpdk.org

Few feature questions:
   - what's about the vNIC supports (toward the guests)?
   - what's about IPsec support (VxLAN over IPsec for instance)?
I do not understand how your patch will solve those 2 cases.

>>> This is based a patch from Gerald Rogers.

Please which patch? I cannot find it into the archives.

>>>
>>> Signed-off-by: Pravin B Shelar 
>>> CC: "Gerald Rogers" 
>>
>> I haven't looked at the patch yet (it does sound awesome) but if it's
>> based on Gerald's code then I'd expect to get his Signed-off-by too.
>
> Right.
>
> Gerald's Patch did not had any signed-off. So If he send me signed-off
> now, I will update the commit msg.

Best regards,
   Vincent

[dpdk-dev] Scenario of dpdk-iokit //Re: Fwd: dpdk-iokit: Turn dpdk into the IO field.

[Vincent JARDIN]

so on the list if you prefer to do so ;) did you try a "perf top" on 
your system under load?


On 19/11/2013 10:56, March Jane wrote:
>
>   Gratitude to reply.
>   
>   FCP and Full-offload iSCSI will be nice, for example Qlogic 16Gbps FCP.
>   
>   But IO scenario is very different from IP scenario as my understanding.
>
>   March   
>
>   BTW: Do you have people at Bay Area?
>
>
>   PS:
>   Already finished header file for dpdk-iokit/libiokit_sctgt
>
>   
>
>
>
>
>   
>   
>
>
>
>
>
>
>
> On Nov 19, 2013, at 5:45 PM, Vincent JARDIN  
> wrote:
>
>> (off list since it coul become a troll ;) )
>>
>> At 6WIND, we developed a librte_crypto as a generic framework to manage any 
>> crypto framework:
>>   - Intel's QuickAssist
>>   - Cavium' Nitrox II
>>   - AES/NI SW crypto
>>
>> it was required in order to manage high rate of PCI IOs for Cryptos (IPsec, 
>> SSL, etc...)
>>
>> So, after the librte_pmd_mlx4, Virtio, Vmxnet3, that's more than 6 ultra low 
>> latency/very efficient drivers that we added into the DPDK and promoted.
>>
>> Which storage drivers would you foresee first to be run in userland?
>>
>> Best regards,
>>
>>
>> On 19/11/2013 02:22, March Jane wrote:
>>>
>>>   ? Nowadays dilemmas in enterprise-class storage system & motivation --
>>>
>>> The model of most storage system is ?Front-end cards + CPU + 
>>> back-end magnetic media hard drive?, in such system, the hard drive is very 
>>> slow in terms of its capability in random accessing - roughly 200IO per 
>>> second, in contrast, the processor is very fast, therefore many software 
>>> stack can tolerate waste of CPU cycle for exploiting capabilities of hard 
>>> drive.
>>> 
>>> In addition, regularly software for SAN is developed under kernel space 
>>> in order to achieve low latency - few milliseconds per request, and IO 
>>> pressure in scenario of heavy workload. Usually software in user-space with 
>>> POSIX is slow. However kernel-space developing is nightmare for engineers, 
>>> even we have approaches to simulate these code under user-space.
>>>
>>>  However, so far flash is coming to popular, the gap between CPU and 
>>> media is overturned, a single flash card can be easy to reach 1M iops, if 
>>> plug 10 such cards inside a server, the processor is hard to back. Thus, 
>>> today?s challenge in flash storage is to exploit the capability of 
>>> processor, ironically.  In addition to this purpose, move to user-space is 
>>> also a motivation, if move to user-space is OS-bypass rather than moving to 
>>> POSIX.
>>>
>>>
>>> Best
>>>
>>> - March
>>>
>>>
>>>
>

[dpdk-dev] L2fwd Performance issue with Virtual Machine

[Vincent JARDIN]

I disagree Rashmin. We did measurements with 64 bytes packets: the Linux 
kernel of the guest is the bottleneck, so the vmxnet3 PMD helps to 
increase the packet rate of the Linux guests.

PMD helps within guest for packet rate until you rich (of course) the 
bottleneck of the host's vSwitch.

In order to accelerate the host's vSwitch, you have to run a fast path 
based vSwitch on the host too.

Best regards,
   Vincent

On 04/10/2013 23:36, Selvaganapathy Chidambaram wrote:
> Thanks Rashmin for your time and help!
>
> So it looks like with the given hardware config, we could probably only
> achieve around 8 Gbps in VM without using SRIOV. Once DPDK is used in
> vSwitch design, we could gain more performance.
>
>
> Thanks,
> Selvaganapathy.C.
>
>
> On Fri, Oct 4, 2013 at 11:02 AM, Patel, Rashmin N  intel.com
>> wrote:
>
>> Correction: "you would NOT get optimal performance benefit having PMD"
>>
>> Thanks,
>> Rashmin
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Patel, Rashmin N
>> Sent: Friday, October 04, 2013 10:47 AM
>> To: Selvaganapathy Chidambaram
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] L2fwd Performance issue with Virtual Machine
>>
>> Hi,
>>
>> If you are not using SRIOV or direct device assignment to VM, your traffic
>> hits vSwitch(via vmware native ixgbe driver and network stack) in the ESX
>> and switched to your E1000/VMXNET3 interface connected to a VM. The vSwitch
>> is not optimized for PMD at present so you would get optimal performance
>> benefit having PMD, I believe.
>>
>> For the RSS front, I would say you won't see much difference with RSS
>> enabled for 1500 bytes frames. In fact, core is capable of handling such
>> traffic in VM, but the bottleneck is in ESXi software switching layer,
>> that's what my initial research shows across multiple hypervisors.
>>
>> Thanks,
>> Rashmin
>>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Selvaganapathy
>> Chidambaram
>> Sent: Thursday, October 03, 2013 2:39 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] L2fwd Performance issue with Virtual Machine
>>
>> Hello Everyone,
>>
>> I have tried to run DPDK sample application l2fwd(modified to support
>> multiple queues) in my ESX Virtual Machine. I see that performance is not
>> scaling with cores. [My apologies for the long email]
>>
>> *Setup:*
>>
>> Connected VM to two ports of Spirent with 10Gig link. Sent 10 Gig traffic
>> of L3 packet of length 1500 bytes (with four different flows) from Spirent
>> through one port and received at the second port. Also sent traffic from
>> reverse direction so that net traffic is 20 Gbps. Haven't enabled SR-IOV or
>>   Direct path I/O.
>>
>> *Emulated Driver:*
>>
>> With default emulated driver, I got 7.3 Gbps for 1 core. Adding multiple
>> cores did not improve the performance. On debugging I noticed that function
>> eth_em_infos_get() says RSS is not supported.
>>
>> *vmxnet3_usermap:*
>>
>> Then I tried extension vmxnet3_usermap and got 8.7 Gbps for 1 core. Again
>> adding another core did not help. On debugging, I noticed that in vmxnet3
>> kernel driver (in function vmxnet3_probe_device) , RSS is disabled if *
>> adapter->is_shm* is non zero. In our case, its
>> adapter->VMXNET3_SHM_USERMAP_DRIVER
>> which is non zero.
>>
>> Before trying to enable it, I would like to know if there is any known
>> limitation why RSS is not enabled in both the drivers. Please help me
>> understand.
>>
>> *Hardware Configuration:*
>> Hardware  : Intel Xeon 2.4 Ghz 4 CPUs
>> Hyperthreading  : No
>> RAM : 16 GB
>> Hypervisor : ESXi 5.1
>> Ethernet: Intel 82599EB 10 Gig SFP
>>
>>
>> Guest VM : 2 vCPU, 2 GB RAM
>> GuestOS  : Centos 6.2 32 bit
>>
>> Thanks in advance for your time and help!!!
>>
>> Thanks,
>> Selva.
>>

[dpdk-dev] [dpdk-announce] seminar - get started with dpdk.org

[Vincent JARDIN]

FYI, there will be a seminar on Tuesday November the 5th in the San 
Francisco bay area.

Register at:
   http://www.6wind.com/seminars/dpdk/

It is for engineers who need a deep dive into the Intel(r) DPDK: the 
seminar will cover its design, the details of available protocol stack 
enhancements and options for interfacing with high-performance 
extensions such as Mellanox 40G NICs and some crypto offload engines 
(Intel Cave Creek, Cavium Nitrox, etc.).

You need a good knowledge of C programming and packet processing in 
order to fully benefit from the seminar.

Best regards,
   Vincent

[dpdk-dev] L3FWD LPM IP lookup performance question

[Vincent JARDIN]

On 26/09/2013 23:16, Chris Pappas wrote:
> we are having some numbers regarding the performance of L3FWD and would
> like to confirm that they make sense.
> So, for L3FWD and 1500byte packets we get 120Gbps out of 12x10Gbps ports
> (so we get full throughput) and for 64byte packets we get 80Gbps.

12x10 with 80Gbps at 64 bytes => 119Mpps
You did not describe your system: number of cores, sockets, PCIe slots, etc.

Whatever the HW environment you are using, you should run the same tests 
but with testpmd in order to qualify the limits of the IOs for your 
platform.

Best regards,
   Vincent

[dpdk-dev] L3FWD LPM IP lookup performance question

[Vincent JARDIN]

I do not know any open source implementation of an efficient LPM. FYI, 
some data with a commercial one:
   -> up to 160Mpps, the bottleneck was the IOs, not the CPU.
   http://www.6wind.com/products/6windgate-protocols/ip-forwarding/

Best regards,
   Vincent

On 24/09/2013 15:53, Jun Han wrote:
> Hello,
>
> We are trying to benchmark L3FWD application and have a question regarding
> the IP lookup algorithm as we expect the bottleneck to be at the lookup.
> Could someone let us know how efficient the lookup algorithm that L3FWD is
> using (e.g, LPM)? We are asking because we want to obtain highest L3
> forwarding performance number, and we might need to change the lookup
> method if the current LPM method is not as efficient.
>
> Thank you very much,
>
> Jun
>

[dpdk-dev] [PATCH] doc: minor rewording

[Vincent JARDIN]

Yes, it helps to avoid confusions, just push it.

Acked-by: vincent.jardin at 6wind.com

On 16/07/2013 10:35, Thomas Monjalon wrote:
> There is no network stack in DPDK API but only helpers for different layers.
>
> Signed-off-by: Thomas Monjalon 
> ---
>   doc/doxy-api-index.md |2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/doxy-api-index.md b/doc/doxy-api-index.md
> index d46c07e..ad83410 100644
> --- a/doc/doxy-api-index.md
> +++ b/doc/doxy-api-index.md
> @@ -69,7 +69,7 @@ There are many libraries, so their headers may be grouped 
> by topics:
> [lcore]  (@ref rte_lcore.h),
> [per-lcore]  (@ref rte_per_lcore.h)
>
> -- **network stack**:
> +- **layers**:
> [ethernet]   (@ref rte_ether.h),
> [IP] (@ref rte_ip.h),
> [SCTP]   (@ref rte_sctp.h),
>

[dpdk-dev] [PATCH 1/2] mk: add rule to print version number

[Vincent JARDIN]

it is just look n feel, just push it.

Acked-by: vincent.jardin at 6wind.com

On 19/07/2013 16:19, Thomas Monjalon wrote:
> The version string is extracted from rte_version.h.
> RTE_VER_* macros are concatenated and separators " . . r " are inserted.
>
> Signed-off-by: Thomas Monjalon 
> ---
>   mk/rte.sdkconfig.mk |6 ++
>   mk/rte.sdkroot.mk   |4 ++--
>   2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
> index 2c071a2..6eb389c 100644
> --- a/mk/rte.sdkconfig.mk
> +++ b/mk/rte.sdkconfig.mk
> @@ -31,6 +31,12 @@
>   #
>   #  version: DPDK.L.1.2.3-3
>
> +.PHONY: showversion
> +showversion:
> + @sed -rn 's,^#define RTE_VER_[A-Z_]*[[:space:]]+([0-9]+).*,\1,p' \
> + $(RTE_SRCDIR)/lib/librte_eal/common/include/rte_version.h | \
> + tr '\n' '.' | sed -r 's,\.([0-9]+)\.$$,r\1\n,'
> +
>   INSTALL_CONFIGS := $(filter-out %~,\
>   $(patsubst $(RTE_SRCDIR)/config/defconfig_%,%,\
>   $(wildcard $(RTE_SRCDIR)/config/defconfig_*)))
> diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
> index 905b678..b5126c0 100644
> --- a/mk/rte.sdkroot.mk
> +++ b/mk/rte.sdkroot.mk
> @@ -87,8 +87,8 @@ export ROOTDIRS-y ROOTDIRS- ROOTDIRS-n
>   .PHONY: default
>   default: all
>
> -.PHONY: config showconfigs
> -config showconfigs:
> +.PHONY: config showconfigs showversion
> +config showconfigs showversion:
>   $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkconfig.mk $@
>
>   .PHONY: test fast_test ring_test mempool_test
>

[dpdk-dev] rte_eth_dev_count() returns 0

[Vincent JARDIN]

> The rte_eth_dev_count() call returns 0, I am using a CentOS 6.3 Virtual
> Machine on VMWare esxi 5.0 on a Cisco UCS C220 M3 which comes with Xeon
> E5-2600.

Can you run lspci -vt and send us the output?

Best regards,
   Vincent

[dpdk-dev] DPDK community

[Vincent JARDIN]

Welcome to the DPDK community. Please, use this mailing list to share 
your patches, your questions and we'll provide you a best effort follow 
up. Please, note that this mailing list cannot be used for a commercial 
support. It is provided as-is.

Anyone can contribute, you are welcomed.

Best regards,
   Vincent