[dpdk-dev] Capture packets using DPDK

[K Rahul]

Hello,

We are building a real-time application to monitor IP packets. This 
application captures packets on UDP which are received by joining 
multicast sessions.

We have downloaded DPDK v2.1.0 and built it with target 
'x86_64-native-linuxapp-gcc' using the setup.sh script provided in tools 
directory. We are using 64-bit Centos 6.5 with kernel version 2.6.32 and 
we had set the number of hugepages (per node) to 512.  Our capture card 
is *Broadcom NetXtreme II BCM5709 Gigabit Ethernet* on which we want to 
use dpdk and the system config is i7 quad-core at 3.4Ghz with 
Hyperthreading ON, which supports 2MB hugepages.

We have gone through the DPDK 
documentation(http://dpdk.readthedocs.org/en/latest). Using the 
dpdk_nic_bind.py script, We were able to bind */uio_pci_generic/* driver 
with *Broadcom NetXtreme II*, which was also reflected by the script 
using the '--status' argument.

To test dpdk, I have built pktgen v2.9.2 application and also gone 
through pktgen documentation(http://pktgen.readthedocs.org/en/latest). 
But whenever I run the command ' ./ pktgen -c 0x1f -n 3 -- -P -m 
"[1:3].0" ' I get the following error:

/>>> Packet Burst 32, RX Desc 512, TX Desc 512, mbufs/port 4096, mbuf 
cache 512//
//!PANIC!: *** *Did not find any ports to use* ***//
//PANIC in pktgen_config_ports()://
//*** Did not find any ports to use ***6: [./pktgen() [0x42f825]]//
//5: [/lib64/libc.so.6(__libc_start_main+0xfd) [0x7ff3c9727d5d]]//
//4: [./pktgen(main+0x489) [0x42e0f9]]//
//3: [./pktgen(pktgen_config_ports+0x118b) [0x4504eb]]//
//2: [./pktgen(__rte_panic+0xc9) [0x428f95]]//
//1: [./pktgen(rte_dump_stack+0x16) [0x4ef116]]//
//Aborted (core dumped)/

Is there any way to find the ports available that can be used by DPDK 
applications, or is there any way to configure ports?

 From the documentation mentioned above 
(http://dpdk.readthedocs.org/en/latest), we were not able to proceed any 
further. Any help on how to use DPDK step by step will be appreciated.

Regards,
K Rahul
Interra Systems

[dpdk-dev] DPDK v2.1.0 tilegx on TileraMDE-4.2.2.169597

[Arthas]

Hi, ZhiGang
  I checked source code and debug it , found dpdk function rte_eth_tx_burst 
with tilegx return 0 and no other error.  Can I contact 
 you directly?
Regards,
  Arthas



-- Original --
From:  "Arthas";;
Date:  Wed, Sep 23, 2015 06:35 PM
To:  "zlu"; "dev"; 

Subject:  Re: [dpdk-dev] DPDK v2.1.0 tilegx on TileraMDE-4.2.2.169597



Hi, ZhiGang
   My tilegx boot parameter is "tile-monitor --dev gxpci${1} --hv-bin-dir 
/tilegx/tile/hv-bin-dir424/ --hvx dataplane=1-64". 
and testpmd start parameter is 
tile-monitor  --dev gxpci0 --resume --upload testpmd  testpmd  --run  -+-  
./testpmd   -c 0x -m 2048 -n 1 -r 1 --vdev xgbe1 --  --rx=1  --tx=2 
--forward-mode=txonly -a --port-topology=chained -+-

 but xgbe1 can't xmit any packet.  
This is my run log:

EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 6 on socket 0
EAL: Detected lcore 7 as core 7 on socket 0
EAL: Detected lcore 8 as core 8 on socket 0
EAL: Detected lcore 9 as core 9 on socket 0
EAL: Detected lcore 10 as core 10 on socket 0
EAL: Detected lcore 11 as core 11 on socket 0
EAL: Detected lcore 12 as core 12 on socket 0
EAL: Detected lcore 13 as core 13 on socket 0
EAL: Detected lcore 14 as core 14 on socket 0
EAL: Detected lcore 15 as core 15 on socket 0
EAL: Detected lcore 16 as core 16 on socket 0
EAL: Detected lcore 17 as core 17 on socket 0
EAL: Detected lcore 18 as core 18 on socket 0
EAL: Detected lcore 19 as core 19 on socket 0
EAL: Detected lcore 20 as core 20 on socket 0
EAL: Detected lcore 21 as core 21 on socket 0
EAL: Detected lcore 22 as core 22 on socket 0
EAL: Detected lcore 23 as core 23 on socket 0
EAL: Detected lcore 24 as core 24 on socket 0
EAL: Detected lcore 25 as core 25 on socket 0
EAL: Detected lcore 26 as core 26 on socket 0
EAL: Detected lcore 27 as core 27 on socket 0
EAL: Detected lcore 28 as core 28 on socket 0
EAL: Detected lcore 29 as core 29 on socket 0
EAL: Detected lcore 30 as core 30 on socket 0
EAL: Detected lcore 31 as core 31 on socket 0
EAL: Detected lcore 32 as core 32 on socket 0
EAL: Detected lcore 33 as core 33 on socket 0
EAL: Detected lcore 34 as core 34 on socket 0
EAL: Detected lcore 35 as core 35 on socket 0
EAL: Support maximum 36 logical core(s) by configuration.
EAL: Detected 36 lcore(s)
EAL: No free hugepages reported in hugepages-1024kB
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0x1600 bytes
EAL: Virtual area found at 0x1ffd100 (size = 0x1600)
EAL: Ask a virtual area of 0x9000 bytes
EAL: Virtual area found at 0x1ff4000 (size = 0x9000)
EAL: Ask a virtual area of 0x200 bytes
EAL: Virtual area found at 0x1ff3d00 (size = 0x200)
EAL: Ask a virtual area of 0x1000 bytes
EAL: Virtual area found at 0x1ff2c00 (size = 0x1000)
EAL: Ask a virtual area of 0x4600 bytes
EAL: Virtual area found at 0x1fee500 (size = 0x4600)
EAL: Ask a virtual area of 0x200 bytes
EAL: Virtual area found at 0x1fee200 (size = 0x200)
EAL: Requesting 128 pages of size 16MB from socket 0
EAL: TSC frequency is ~119 KHz
EAL: WARNING: cpu flags constant_tsc=no nonstop_tsc=no -> using unreliable 
clock cycles !
EAL: Master lcore 0 is ready (tid=f7fa4690;cpuset=[0])
PMD: mpipe init xgbe1
PMD: xgbe1: Initialized mpipe device(mac ee:d1:53:72:82:5a).
EAL: lcore 1 is ready (tid=eb04f060;cpuset=[1])
EAL: lcore 2 is ready (tid=ea84f060;cpuset=[2])
EAL: lcore 3 is ready (tid=ea04f060;cpuset=[3])
EAL: lcore 4 is ready (tid=e984f060;cpuset=[4])
EAL: lcore 5 is ready (tid=d0fff060;cpuset=[5])
EAL: lcore 6 is ready (tid=d07ff060;cpuset=[6])
EAL: lcore 7 is ready (tid=e904f060;cpuset=[7])
EAL: lcore 8 is ready (tid=e884f060;cpuset=[8])
EAL: lcore 9 is ready (tid=e804f060;cpuset=[9])
EAL: lcore 10 is ready (tid=e784f060;cpuset=[10])
EAL: lcore 11 is ready (tid=b3fff060;cpuset=[11])
EAL: lcore 12 is ready (tid=b37ff060;cpuset=[12])
EAL: lcore 13 is ready (tid=b2fff060;cpuset=[13])
EAL: lcore 14 is ready (tid=b27ff060;cpuset=[14])
EAL: lcore 15 is ready (tid=b1fff060;cpuset=[15])
EAL: lcore 16 is ready (tid=b17ff060;cpuset=[16])
EAL: lcore 17 is ready (tid=b0fff060;cpuset=[17])
EAL: lcore 18 is ready (tid=2060;cpuset=[18])
EAL: lcore 19 is ready (tid=b07ff060;cpuset=[19])
EAL: lcore 20 is ready (tid=abfff060;cpuset=[20])
EAL: lcore 21 is ready (tid=ab7ff060;cpuset=[21])
EAL: lcore 22 is ready (tid=aafff060;cpuset=[22])
EAL: lcore 23 is ready (tid=aa7ff060;cpuset=[23])
EAL: lcore 24 is ready (tid=2f7ff060;cpuset=[24])
EAL: lcore 25 is ready (tid=2efff060;cpuset=[25])
EAL: lcore 26 is ready (tid=2e7ff060;cpuset=[26])
EAL: lcore 27 is ready (tid=2dfff060;cpuset=[27])
EAL: lcore 28 is ready (tid=2d7ff060;cpuset=[28])
EAL: lcore 29 is ready 

[dpdk-dev] DPDK v2.1.0 tilegx on TileraMDE-4.2.2.169597

[Arthas]

Hi, ZhiGang
   My tilegx boot parameter is "tile-monitor --dev gxpci${1} --hv-bin-dir 
/tilegx/tile/hv-bin-dir424/ --hvx dataplane=1-64". 
and testpmd start parameter is 
tile-monitor  --dev gxpci0 --resume --upload testpmd  testpmd  --run  -+-  
./testpmd   -c 0x -m 2048 -n 1 -r 1 --vdev xgbe1 --  --rx=1  --tx=2 
--forward-mode=txonly -a --port-topology=chained -+-

 but xgbe1 can't xmit any packet.  
This is my run log:

EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 6 on socket 0
EAL: Detected lcore 7 as core 7 on socket 0
EAL: Detected lcore 8 as core 8 on socket 0
EAL: Detected lcore 9 as core 9 on socket 0
EAL: Detected lcore 10 as core 10 on socket 0
EAL: Detected lcore 11 as core 11 on socket 0
EAL: Detected lcore 12 as core 12 on socket 0
EAL: Detected lcore 13 as core 13 on socket 0
EAL: Detected lcore 14 as core 14 on socket 0
EAL: Detected lcore 15 as core 15 on socket 0
EAL: Detected lcore 16 as core 16 on socket 0
EAL: Detected lcore 17 as core 17 on socket 0
EAL: Detected lcore 18 as core 18 on socket 0
EAL: Detected lcore 19 as core 19 on socket 0
EAL: Detected lcore 20 as core 20 on socket 0
EAL: Detected lcore 21 as core 21 on socket 0
EAL: Detected lcore 22 as core 22 on socket 0
EAL: Detected lcore 23 as core 23 on socket 0
EAL: Detected lcore 24 as core 24 on socket 0
EAL: Detected lcore 25 as core 25 on socket 0
EAL: Detected lcore 26 as core 26 on socket 0
EAL: Detected lcore 27 as core 27 on socket 0
EAL: Detected lcore 28 as core 28 on socket 0
EAL: Detected lcore 29 as core 29 on socket 0
EAL: Detected lcore 30 as core 30 on socket 0
EAL: Detected lcore 31 as core 31 on socket 0
EAL: Detected lcore 32 as core 32 on socket 0
EAL: Detected lcore 33 as core 33 on socket 0
EAL: Detected lcore 34 as core 34 on socket 0
EAL: Detected lcore 35 as core 35 on socket 0
EAL: Support maximum 36 logical core(s) by configuration.
EAL: Detected 36 lcore(s)
EAL: No free hugepages reported in hugepages-1024kB
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0x1600 bytes
EAL: Virtual area found at 0x1ffd100 (size = 0x1600)
EAL: Ask a virtual area of 0x9000 bytes
EAL: Virtual area found at 0x1ff4000 (size = 0x9000)
EAL: Ask a virtual area of 0x200 bytes
EAL: Virtual area found at 0x1ff3d00 (size = 0x200)
EAL: Ask a virtual area of 0x1000 bytes
EAL: Virtual area found at 0x1ff2c00 (size = 0x1000)
EAL: Ask a virtual area of 0x4600 bytes
EAL: Virtual area found at 0x1fee500 (size = 0x4600)
EAL: Ask a virtual area of 0x200 bytes
EAL: Virtual area found at 0x1fee200 (size = 0x200)
EAL: Requesting 128 pages of size 16MB from socket 0
EAL: TSC frequency is ~119 KHz
EAL: WARNING: cpu flags constant_tsc=no nonstop_tsc=no -> using unreliable 
clock cycles !
EAL: Master lcore 0 is ready (tid=f7fa4690;cpuset=[0])
PMD: mpipe init xgbe1
PMD: xgbe1: Initialized mpipe device(mac ee:d1:53:72:82:5a).
EAL: lcore 1 is ready (tid=eb04f060;cpuset=[1])
EAL: lcore 2 is ready (tid=ea84f060;cpuset=[2])
EAL: lcore 3 is ready (tid=ea04f060;cpuset=[3])
EAL: lcore 4 is ready (tid=e984f060;cpuset=[4])
EAL: lcore 5 is ready (tid=d0fff060;cpuset=[5])
EAL: lcore 6 is ready (tid=d07ff060;cpuset=[6])
EAL: lcore 7 is ready (tid=e904f060;cpuset=[7])
EAL: lcore 8 is ready (tid=e884f060;cpuset=[8])
EAL: lcore 9 is ready (tid=e804f060;cpuset=[9])
EAL: lcore 10 is ready (tid=e784f060;cpuset=[10])
EAL: lcore 11 is ready (tid=b3fff060;cpuset=[11])
EAL: lcore 12 is ready (tid=b37ff060;cpuset=[12])
EAL: lcore 13 is ready (tid=b2fff060;cpuset=[13])
EAL: lcore 14 is ready (tid=b27ff060;cpuset=[14])
EAL: lcore 15 is ready (tid=b1fff060;cpuset=[15])
EAL: lcore 16 is ready (tid=b17ff060;cpuset=[16])
EAL: lcore 17 is ready (tid=b0fff060;cpuset=[17])
EAL: lcore 18 is ready (tid=2060;cpuset=[18])
EAL: lcore 19 is ready (tid=b07ff060;cpuset=[19])
EAL: lcore 20 is ready (tid=abfff060;cpuset=[20])
EAL: lcore 21 is ready (tid=ab7ff060;cpuset=[21])
EAL: lcore 22 is ready (tid=aafff060;cpuset=[22])
EAL: lcore 23 is ready (tid=aa7ff060;cpuset=[23])
EAL: lcore 24 is ready (tid=2f7ff060;cpuset=[24])
EAL: lcore 25 is ready (tid=2efff060;cpuset=[25])
EAL: lcore 26 is ready (tid=2e7ff060;cpuset=[26])
EAL: lcore 27 is ready (tid=2dfff060;cpuset=[27])
EAL: lcore 28 is ready (tid=2d7ff060;cpuset=[28])
EAL: lcore 29 is ready (tid=2cfff060;cpuset=[29])
EAL: lcore 30 is ready (tid=2c7ff060;cpuset=[30])
EAL: lcore 31 is ready (tid=f3fff060;cpuset=[31])
Set txonly packet forwarding mode
Auto-start selected
Configuring Port 0 (socket 0)
PMD: xgbe1: Could not register memseg @0x1ffd100, -.
PMD: xgbe1: Could not register memseg @0x1ff4000, -.
PMD: xgbe1: Buffer stack memory 0x1ffd1c3 - 0x1ffd1c8557f.

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

[Loftus, Ciara]

> The patch introduces a new PMD. This PMD is implemented as thin wrapper
> of librte_vhost. It means librte_vhost is also needed to compile the PMD.
> The PMD can have 'iface' parameter like below to specify a path to connect
> to a virtio-net device.
> 
> $ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0' -- -i
> 
> To connect above testpmd, here is qemu command example.
> 
> $ qemu-system-x86_64 \
> 
> -chardev socket,id=chr0,path=/tmp/sock0 \
> -netdev vhost-user,id=net0,chardev=chr0,vhostforce \
> -device virtio-net-pci,netdev=net0
> 
> Signed-off-by: Tetsuya Mukawa 
> ---
>  config/common_linuxapp  |   6 +
>  drivers/net/Makefile|   4 +
>  drivers/net/vhost/Makefile  |  61 +++
>  drivers/net/vhost/rte_eth_vhost.c   | 640
> 
>  drivers/net/vhost/rte_pmd_vhost_version.map |   4 +
>  mk/rte.app.mk   |   8 +-
>  6 files changed, 722 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/net/vhost/Makefile
>  create mode 100644 drivers/net/vhost/rte_eth_vhost.c
>  create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map
> 
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 0de43d5..7310240 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -446,6 +446,12 @@ CONFIG_RTE_LIBRTE_VHOST_NUMA=n
>  CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
> 
>  #
> +# Compile vhost PMD
> +# To compile, CONFIG_RTE_LIBRTE_VHOST should be enabled.
> +#
> +CONFIG_RTE_LIBRTE_PMD_VHOST=y
> +
> +#
>  #Compile Xen domain0 support
>  #
>  CONFIG_RTE_LIBRTE_XEN_DOM0=n
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 5ebf963..e46a38e 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -49,5 +49,9 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
>  DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
>  DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
> 
> +ifeq ($(CONFIG_RTE_LIBRTE_VHOST),y)
> +DIRS-$(CONFIG_RTE_LIBRTE_PMD_VHOST) += vhost
> +endif # $(CONFIG_RTE_LIBRTE_VHOST)
> +
>  include $(RTE_SDK)/mk/rte.sharelib.mk
>  include $(RTE_SDK)/mk/rte.subdir.mk
> diff --git a/drivers/net/vhost/Makefile b/drivers/net/vhost/Makefile
> new file mode 100644
> index 000..018edde
> --- /dev/null
> +++ b/drivers/net/vhost/Makefile
> @@ -0,0 +1,61 @@
> +#   BSD LICENSE
> +#
> +#   Copyright (c) 2010-2015 Intel Corporation.
> +#   All rights reserved.
> +#
> +#   Redistribution and use in source and binary forms, with or without
> +#   modification, are permitted provided that the following conditions
> +#   are met:
> +#
> +# * Redistributions of source code must retain the above copyright
> +#   notice, this list of conditions and the following disclaimer.
> +# * Redistributions in binary form must reproduce the above copyright
> +#   notice, this list of conditions and the following disclaimer in
> +#   the documentation and/or other materials provided with the
> +#   distribution.
> +# * Neither the name of Intel corporation nor the names of its
> +#   contributors may be used to endorse or promote products derived
> +#   from this software without specific prior written permission.
> +#
> +#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> +#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> +#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> +#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> +#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> +#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> +#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> OF USE,
> +#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND ON ANY
> +#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> +#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> +#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> +
> +include $(RTE_SDK)/mk/rte.vars.mk
> +
> +#
> +# library name
> +#
> +LIB = librte_pmd_vhost.a
> +
> +CFLAGS += -O3
> +CFLAGS += $(WERROR_FLAGS)
> +
> +EXPORT_MAP := rte_pmd_vhost_version.map
> +
> +LIBABIVER := 1
> +
> +#
> +# all source are stored in SRCS-y
> +#
> +SRCS-$(CONFIG_RTE_LIBRTE_PMD_VHOST) += rte_eth_vhost.c
> +
> +#
> +# Export include files
> +#
> +SYMLINK-y-include +=
> +
> +# this lib depends upon:
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_VHOST) += lib/librte_mbuf
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_VHOST) += lib/librte_ether
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_VHOST) += lib/librte_kvargs
> +
> +include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/drivers/net/vhost/rte_eth_vhost.c
> b/drivers/net/vhost/rte_eth_vhost.c
> new file mode 100644
> index 000..679e893
> --- /dev/null
> +++ b/drivers/net/vhost/rte_eth_vhost.c
> @@ -0,0 +1,640 @@

[dpdk-dev] DPDK.org Community Call - Sept 24 - Discuss Growth, Improvements

[Dave Neary]

Hi Jim,

I see that there is a session loosely aligned with the agenda below on 
the agenda for DPDK Userspace in Dublin: 
https://dpdksummit.com/us/en/userspace2015 (current speaker is TBC). 
Will this call serve as a preparation call for that face to face 
meeting? In which case, is this the best opportunity that people who 
cannot travel to Dublin will have to make any concerns/proposals known 
so that they can be discussed there?

Thanks,
Dave.

On 09/22/2015 03:14 AM, St Leger, Jim wrote:
> I am going to host a community call on Thursday Sept 24 at 7:00am Pacific 
> daylight time.  The conference call dial-in info via GoToMeeting is pasted 
> below.  Here is the background and objective of the discussion.
>
> The DPDK community continues to grow.  Here are some stats on the 2.1 release 
> from August 17th:
> => 827 commits. A growth of ~50% over the 2.0 release.
> => 82 individual committers. A growth of ~33% over the 2.0 release.
> The number of companies contributing has also continued to grow.
>
> There is a strong desire to continue to grow and solidify the community. But 
> the growth brings up the question of how the community is structured to 
> scale.   Additionally, there are many private DPDK repositories across the 
> industry (e.g. ARM ports, for example.)  There are a myriad of reasons why 
> companies have elected to keep their DPDK code and ports private versus put 
> them into the DPDK.org community. We as a community need to understand and 
> explore these reasons and work towards enabling inclusion.
>
> During this gathering I'd like to bring together the DPDK community including:
> a) the DPDK code contributors,
> b) the consumers of DPDK downstream (VNF vendors, etc.),
> c) private branch DPDK creators/consumers, and
> d) anyone else interested in the growth and future of the DPDK open source 
> software project.
>
> The call will focus on two topics:
>
> 1)Structure for growth:
>
> Do we have the community practices, policies, and procedures in place to 
> allow us to continue to grow on our current trajectory?
>
>
>
> 2)Gaps Limiting Participation:
>
> What gaps do companies who would like to participate/contribute to DPDK.org 
> see?
>
> What changes would they like to see made to improve the project?
>
> I hope people can attend AND that they will join and speak up and be heard. 
> The success and growth of the community depends on YOU!
>
> Thanks,
> Jim
> =
> DPDK Community Call
>
> Thu, Sep 24, 2015 3:00 PM - 4:00 PM GMT Daylight Time
> Please join my meeting from your computer, tablet or smartphone.
> https://global.gotomeeting.com/join/766709085
>
> You can also dial in using your phone.
>
> Access Code: 766-709-085
> Dial-in phone numbers
> United States : +1 (312) 757-3117
> Australia : +61 2 8355 1031
> Austria : +43 (0) 7 2088 1033
> Belgium : +32 (0) 28 93 7001
> Canada : +1 (647) 497-9371
> Denmark : +45 (0) 69 91 89 33
> Finland : +358 (0) 942 41 5770
> France : +33 (0) 170 950 585
> Germany : +49 (0) 692 5736 7303
> Ireland : +353 (0) 19 030 050
> Italy : +39 0 693 38 75 50
> Netherlands : +31 (0) 208 080 208
> New Zealand : +64 9 925 0481
> Norway : +47 21 54 82 21
> Spain : +34 911 82 9890
> Sweden : +46 (0) 853 527 817
> Switzerland : +41 (0) 435 0167 65
> United Kingdom : +44 (0) 20 3713 5010
>
>

-- 
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] [PATCH v5 resend 05/12] vhost: add VHOST_USER_SET_VRING_ENABLE message

[Yuanhan Liu]

On Tue, Sep 22, 2015 at 10:21:22AM +0800, Yuanhan Liu wrote:
> On Mon, Sep 21, 2015 at 12:02:20PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Sep 21, 2015 at 10:22:52AM +0800, Yuanhan Liu wrote:
> > > On Sun, Sep 20, 2015 at 12:37:35PM +0300, Michael S. Tsirkin wrote:
> > > > On Fri, Sep 18, 2015 at 11:10:54PM +0800, Yuanhan Liu wrote:
> > > > > From: Changchun Ouyang 
> > > > > 
> > > > > This message is used to enable/disable a specific vring queue pair.
> > > > > The first queue pair is enabled by default.
> > > > > 
> > > > > Signed-off-by: Changchun Ouyang 
> > > > > Signed-off-by: Yuanhan Liu 
> > > > > ---
> > > [snip...]
> > > > >  void
> > > > >  user_destroy_device(struct vhost_device_ctx ctx)
> > > > >  {
> > > > 
> > > > It might be a good idea to flush any packets being processed
> > > > on relevant cores at this point.
> > > 
> > > They are offloaded to the application (examples/vhost/vhost-switch in
> > > this case).
> > > 
> > > user_destroy_device will invoke the application's "destroy_device()"
> > > callback in the end, which, in our case, will set "remove" flag. The
> > > core worker will then drain and free the RX queue and free TX queue
> > > once the "remove" flag is set.
> > > 
> > >   --yliu
> > 
> > 
> > Oh, I really meant user_set_vring_enable.
> 
> Will a per-vring callback help then?
> 
> We may prototype the callback to "vring_state_changed(dev, vring_index)"

It should be "vring_state_changed(dev, vring_index, enable)".

> so that the application could either, as you suggested, flushes any packets
> haven't been processed yet, or simply drops them.

After putting more thoughts on that, I guess it's also necessary to
inform the application that before receiving an "enabled" state for
a specific vring, we should never use it for data transferring, as
we just enable one queue pair by default.

And I think we could do both in vring_state_changed() callback.

Michael, what do you think of it?


--yliu

[dpdk-dev] [PATCH] librte_vhost: eventfd_link: Update the makefile to build against an arbitrary kernel

[Aaron Conole]

The vHost eventlink driver is a kernel module that requires a kernel
source/build directory to build the ko. Convert the fixed kernel build
directory specifier to one which may be user specified on the command-line.

Signed-off-by: Aaron Conole 
---
 lib/librte_vhost/eventfd_link/Makefile | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/librte_vhost/eventfd_link/Makefile 
b/lib/librte_vhost/eventfd_link/Makefile
index fc3927b..3140e8b 100644
--- a/lib/librte_vhost/eventfd_link/Makefile
+++ b/lib/librte_vhost/eventfd_link/Makefile
@@ -29,11 +29,13 @@
 #   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 #   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

+RTE_KERNELDIR ?= /lib/modules/$(shell uname -r)/build
+
 obj-m += eventfd_link.o


 all:
-   make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
+   make -C $(RTE_KERNELDIR) M=$(PWD) modules

 clean:
-   make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
+   make -C $(RTE_KERNELDIR) M=$(PWD) clean
-- 
1.8.3.1

[dpdk-dev] DPDK v2.1.0 tilegx on TileraMDE-4.2.2.169597

[Tony Lu]

Hi, Arthas

Does testpmd run OK, and what is boot parameter you used to boot Tile-Gx?

>-Original Message-
>From: Arthas [mailto:kangzy1982 at qq.com]
>Sent: Wednesday, September 23, 2015 1:21 PM
>To: dev
>Cc: zlu
>Subject: Re: [dpdk-dev] DPDK v2.1.0 tilegx on TileraMDE-4.2.2.169597
>
>and I wrote a sample RX example, got an other information.
>
>
>PMD: xgbe1: Could not register memseg @0x1ffd200, -.
>PMD: xgbe1: Could not register memseg @0x1ff4100, -.
>PMD: xgbe1: Could not register memseg @0x1ff3e00, -.
>PMD: xgbe1: Could not register memseg @0x1ff2d00, -.
>PMD: xgbe1: Could not register memseg @0x1fee600, -.
>PMD: xgbe1: Could not register memseg @0x1fee300, -.
>PMD: xgbe1: Buffer stack memory 0x1fee4b9 - 0x1fee4be557f.
>PMD: xgbe1: eDMA ring memory 0x1fee4bf - 0x1fee4bf1fff.
>PMD: xgbe1: iDMA ring 0 memory 0x1fee4bec000 - 0x1fee4bedfff.
>
>
>
>  Regards, Arthas
>
>-- Original --
>From:  "Arthas";;
>Date:  Wed, Sep 23, 2015 01:17 PM
>To:  "dev";
>Subject:  [dpdk-dev] DPDK v2.1.0 tilegx on TileraMDE-4.2.2.169597
>
>Hi, I'm working on tilegx platform.  and I wrote a sample dpdk trafgen for
tilegx.
>But I got a error with rte_mbuf rte_pktmbuf_append.
>
>PANIC in rte_mbuf_sanity_check():
>bad phys addr
>7: [/trafgen(_start+0x70) [0x100b308]]
>6: [/lib/libc.so.6(__libc_start_main+0x200) [0x1fff7a6e4c8]]
>5: [/trafgen(main+0x2148) [0x1017b78]]
>4: [/trafgen(rte_pktmbuf_dump+0x58) [0x102c7a8]]
>3: [/trafgen(rte_mbuf_sanity_check+0x1a8) [0x102c700]]
>2: [/trafgen(__rte_panic+0xc0) [0x1091e80]]
>1: [/trafgen(rte_dump_stack+0x40) [0x104cf00]]
>
>
>DPDK compiled with CONFIG_RTE_LIBRTE_MBUF_DEBUG=y!
>
> Regards, Arthas

[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install

[Arevalo, Mario Alfredo C]

Hi,

Thanks you for your feedback, I?ll send a version 2 based on last comments.

Thanks,
Mario


From: Olivier MATZ [olivier.m...@6wind.com]
Sent: Tuesday, September 22, 2015 7:40 AM
To: Panu Matilainen; Arevalo, Mario Alfredo C; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/7] Add hierarchical support to make install

Hi,

On 09/22/2015 12:14 PM, Panu Matilainen wrote:
> In my packaging of DPDK I ended up providing both: headers, libraries
> etc in the normal system paths, and then a separate dpdk-sdk directory
> holding the SDK-parts like mk bits and symlinking to the libs and
> headers as needed, so that you can actually point RTE_SDK to that
> dpdk-sdk dir and be able to build apps against the thing.

Great, it didn't know that.

>> My question is: do we want to keep the current install behavior for
>> compatibility or not? Should we consider this makefile directive as
>> an API? People may use it, and we should at least ask us it it should
>> follow a sort of API deprecation process like we do for the code.
>> That's why I talked about 2 new commands and deprecate the old one.
>
> I'd be surprised if somebody somewhere isn't relying on the current
> specific behavior, given its explicitly documented and all. Whether it
> needs to stay, and whether it needs to stay as the default ... I
> wouldn't miss it, but its a question for those using and depending on it
> really.

Ok. So if nobody else complains, I have no objection to change the
default behavior of "make install" to this which indeed looks more
usual and distribution-friendly. In this case we may remove the
old one, it's probably better than having a H=1 option.


Regards,
Olivier

[dpdk-dev] [PATCH v2] Change rte_eal_vdev_init to update port_id

[Ravi Kerur]

Hi David, Tetsuya,

I have sent V3 (changes isolated to rte_ether component) for formal review.
Please look into it and let me know your inputs.

@David: I looked at "rte_eth_dev_get_port_by_name()", this function is
similar to "rte_eth_dev_get_name_by_port" and I have used same logic. Let
me know if this not correct I can fix both.

Thanks,
Ravi


On Tue, Sep 15, 2015 at 4:28 AM, Ravi Kerur  wrote:

> Hi David,
>
>
> On Thu, Sep 3, 2015 at 7:04 AM, David Marchand 
> wrote:
>
>> Hello Ravi, Tetsuya,
>>
>> On Tue, Aug 25, 2015 at 7:59 PM, Ravi Kerur  wrote:
>>
>>> Let us know how you want us to fix this? To fix rte_eal_vdev_init and
>>> rte_eal_pci_probe_one to return allocated port_id we had 2 approaches
>>> mentioned in earlier discussion. In addition to those we have another
>>> approach with changes isolated only to rte_ether component. I am attaching
>>> diffs (preliminary) with this email. Please let us know your inputs since
>>> it involves EAL component.
>>>
>>
>> - This patch looks like a good ethdev cleanup (even if it really lacks
>> some context / commit log).
>>
>> I wonder just why you only take the first part of the name in
>> rte_eth_dev_get_port_by_name().
>> Would not this match, let's say, both toto and toto0 vdevs ?
>> Is this intended ?
>>
>> It was not intended, i will look into it.
>
>>
>> - In the end, with this patch, do we still need to update eal ?
>> Looking at the code, I am not sure anymore.
>>
>
> Approach 3 (preliminary diffs sent as an attachment) doesn't involve EAL
> but the other two solutions do. So please let us know which one you prefer.
> I will send updated patch.
>
> Thanks,
> Ravi
>
>
>>
>>
>>
>> --
>> David Marchand
>>
>
>

[dpdk-dev] [PATCH v3] Change rte_eal_vdev_init to update port_id

[Ravi Kerur]

v3:
   > Isolate changes within rte_ether component.

v2:
   > Remove tilegx changes
   > Use rte_eal_compare_pci_addr for address comparison
   > Use dpdk_2.2 in version map file for new functions

v1:
Changes include
   > Modify rte_eal_vdev_init to return allocated port_id
   > Modify rte_eal_probe_one to return allocated port_id

2. Removed following functions
   > rte_eth_dev_save and
   > rte_eth_dev_get_changed_port

3. Added 2 new functions
   > rte_eth_dev_get_port_by_name
   > rte_eth_dev_get_port_by_addr

4. Fix return error(ENOMEM) in function rte_pmd_mpipe_devinit

Compiled on Linux for following targets
   > x86_64-native-linuxapp-gcc
   > x86_64-native-linuxapp-clang
   > x86_x32-native-linuxapp-gcc

Compiled on FreeBSD for following targets
   > x86_64-native-bsdapp-clang
   > x86_64-native-bsdapp-gcc

Tested on Linux/FreeBSD:
   > port attach eth_null
   > port start all
   > port stop all
   > port close all
   > port detach 0
   > port attach eth_null
   > port start all
   > port stop all
   > port close all
   > port detach 0

Successful run of checkpatch.pl on the diffs

Successful validate_abi on Linux for following targets

   > x86_64-native-linuxapp-gcc
   > x86_64-native-linuxapp-clang

Signed-off-by: Ravi Kerur 
---
 lib/librte_ether/rte_ethdev.c | 116 +++---
 1 file changed, 63 insertions(+), 53 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index b309309..e4b8e41 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -442,32 +442,6 @@ rte_eth_dev_get_device_type(uint8_t port_id)
 }

 static int
-rte_eth_dev_save(struct rte_eth_dev *devs, size_t size)
-{
-   if ((devs == NULL) ||
-   (size != sizeof(struct rte_eth_dev) * RTE_MAX_ETHPORTS))
-   return -EINVAL;
-
-   /* save current rte_eth_devices */
-   memcpy(devs, rte_eth_devices, size);
-   return 0;
-}
-
-static int
-rte_eth_dev_get_changed_port(struct rte_eth_dev *devs, uint8_t *port_id)
-{
-   if ((devs == NULL) || (port_id == NULL))
-   return -EINVAL;
-
-   /* check which port was attached or detached */
-   for (*port_id = 0; *port_id < RTE_MAX_ETHPORTS; (*port_id)++, devs++) {
-   if (rte_eth_devices[*port_id].attached ^ devs->attached)
-   return 0;
-   }
-   return -ENODEV;
-}
-
-static int
 rte_eth_dev_get_addr_by_port(uint8_t port_id, struct rte_pci_addr *addr)
 {
VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
@@ -501,6 +475,59 @@ rte_eth_dev_get_name_by_port(uint8_t port_id, char *name)
 }

 static int
+rte_eth_dev_get_port_by_name(const char *name, uint8_t *port_id)
+{
+   int i;
+
+   if (name == NULL) {
+   PMD_DEBUG_TRACE("Null pointer is specified\n");
+   return -EINVAL;
+   }
+
+   *port_id = RTE_MAX_ETHPORTS;
+
+   for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
+
+   if (!strncmp(name,
+   rte_eth_dev_data[i].name, strlen(name))) {
+
+   *port_id = i;
+
+   return 0;
+   }
+   }
+   return -ENODEV;
+}
+
+static int
+rte_eth_dev_get_port_by_addr(const struct rte_pci_addr *addr, uint8_t *port_id)
+{
+   int i;
+   struct rte_pci_device *pci_dev = NULL;
+
+   if (addr == NULL) {
+   PMD_DEBUG_TRACE("Null pointer is specified\n");
+   return -EINVAL;
+   }
+
+   *port_id = RTE_MAX_ETHPORTS;
+
+   for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
+
+   pci_dev = rte_eth_devices[i].pci_dev;
+
+   if (pci_dev &&
+   !rte_eal_compare_pci_addr(_dev->addr, addr)) {
+
+   *port_id = i;
+
+   return 0;
+   }
+   }
+   return -ENODEV;
+}
+
+static int
 rte_eth_dev_is_detachable(uint8_t port_id)
 {
uint32_t drv_flags;
@@ -530,30 +557,19 @@ rte_eth_dev_is_detachable(uint8_t port_id)
 static int
 rte_eth_dev_attach_pdev(struct rte_pci_addr *addr, uint8_t *port_id)
 {
-   uint8_t new_port_id;
-   struct rte_eth_dev devs[RTE_MAX_ETHPORTS];
-
if ((addr == NULL) || (port_id == NULL))
goto err;

-   /* save current port status */
-   if (rte_eth_dev_save(devs, sizeof(devs)))
-   goto err;
/* re-construct pci_device_list */
if (rte_eal_pci_scan())
goto err;
-   /* invoke probe func of the driver can handle the new device.
-* TODO:
-* rte_eal_pci_probe_one() should return port_id.
-* And rte_eth_dev_save() and rte_eth_dev_get_changed_port()
-* should be removed. */
+   /* Invoke probe func of the driver can handle the new device. */
if (rte_eal_pci_probe_one(addr))
goto err;
-   /* get port_id enabled by above procedures */
-   if (rte_eth_dev_get_changed_port(devs, _port_id))
+
+   if 

[dpdk-dev] [PATCH v3] Send updated port_id in vdev_init functions

[Ravi Kerur]

Instead of executing following functions before and after vdev_init
   > rte_eth_dev_save and
   > rte_eth_dev_get_changed_port

update following functions to return allocated port_id.
   > rte_eal_vdev_init
   > rte_eal_probe_one

Ravi Kerur (1):
  Change rte_eal_vdev_init to update port_id

 lib/librte_ether/rte_ethdev.c | 116 +++---
 1 file changed, 63 insertions(+), 53 deletions(-)

-- 
1.9.1

[dpdk-dev] DPDK v2.1.0 tilegx on TileraMDE-4.2.2.169597

[Arthas]

and I wrote a sample RX example, got an other information.


PMD: xgbe1: Could not register memseg @0x1ffd200, -.
PMD: xgbe1: Could not register memseg @0x1ff4100, -.
PMD: xgbe1: Could not register memseg @0x1ff3e00, -.
PMD: xgbe1: Could not register memseg @0x1ff2d00, -.
PMD: xgbe1: Could not register memseg @0x1fee600, -.
PMD: xgbe1: Could not register memseg @0x1fee300, -.
PMD: xgbe1: Buffer stack memory 0x1fee4b9 - 0x1fee4be557f.
PMD: xgbe1: eDMA ring memory 0x1fee4bf - 0x1fee4bf1fff.
PMD: xgbe1: iDMA ring 0 memory 0x1fee4bec000 - 0x1fee4bedfff.


  Regards, Arthas


-- Original --
From:  "Arthas";;
Date:  Wed, Sep 23, 2015 01:17 PM
To:  "dev"; 

Subject:  [dpdk-dev] DPDK v2.1.0 tilegx on TileraMDE-4.2.2.169597



Hi, I'm working on tilegx platform.  and I wrote a sample dpdk trafgen for 
tilegx.  But I got a error with rte_mbuf rte_pktmbuf_append.

PANIC in rte_mbuf_sanity_check():
bad phys addr
7: [/trafgen(_start+0x70) [0x100b308]]
6: [/lib/libc.so.6(__libc_start_main+0x200) [0x1fff7a6e4c8]]
5: [/trafgen(main+0x2148) [0x1017b78]]
4: [/trafgen(rte_pktmbuf_dump+0x58) [0x102c7a8]]
3: [/trafgen(rte_mbuf_sanity_check+0x1a8) [0x102c700]]
2: [/trafgen(__rte_panic+0xc0) [0x1091e80]]
1: [/trafgen(rte_dump_stack+0x40) [0x104cf00]]


DPDK compiled with CONFIG_RTE_LIBRTE_MBUF_DEBUG=y!

 Regards, Arthas

[dpdk-dev] DPDK v2.1.0 tilegx on TileraMDE-4.2.2.169597

[Arthas]

Hi, I'm working on tilegx platform.  and I wrote a sample dpdk trafgen for 
tilegx.  But I got a error with rte_mbuf rte_pktmbuf_append.

PANIC in rte_mbuf_sanity_check():
bad phys addr
7: [/trafgen(_start+0x70) [0x100b308]]
6: [/lib/libc.so.6(__libc_start_main+0x200) [0x1fff7a6e4c8]]
5: [/trafgen(main+0x2148) [0x1017b78]]
4: [/trafgen(rte_pktmbuf_dump+0x58) [0x102c7a8]]
3: [/trafgen(rte_mbuf_sanity_check+0x1a8) [0x102c700]]
2: [/trafgen(__rte_panic+0xc0) [0x1091e80]]
1: [/trafgen(rte_dump_stack+0x40) [0x104cf00]]


DPDK compiled with CONFIG_RTE_LIBRTE_MBUF_DEBUG=y!

 Regards, Arthas

[dpdk-dev] [PATCH v1 1/3] port: add mp/mc ring ports

[Dumitrescu, Cristian]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, September 22, 2015 5:24 PM
> To: Dumitrescu, Cristian
> Cc: dev at dpdk.org; Stephen Hemminger; Azarewicz, PiotrX T
> Subject: Re: [dpdk-dev] [PATCH v1 1/3] port: add mp/mc ring ports
> 
> 2015-09-22 11:34, Dumitrescu, Cristian:
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen
> > > Hemminger
> > > Sent: Tuesday, September 22, 2015 1:36 AM
> > > To: Azarewicz, PiotrX T
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v1 1/3] port: add mp/mc ring ports
> > >
> > > On Tue, 15 Sep 2015 15:06:33 +0200
> > > Piotr Azarewicz  wrote:
> > >
> > > > +static inline void
> > > > +send_burst_mp(struct rte_port_ring_writer *p)
> > > > +{
> > >
> > > compiler will inline static functions anyway. No need to add inline 
> > > qualifier
> >
> > Hi Stephen,
> >
> > Using 'static inline' seems to be the standard practice in DPDK and a good
> practice as well.
> 
> Why do you think it is a good practice?
> Forced inlining can be a random optimization having negative effects.
> 

What I meant is this: when users want to make sure their code gets inlined by 
the compiler, it is better to explicitly state this by using the mechanisms 
provided by the C compiler (C keyword "inline" and compiler pragmas like 
"always inline") rather than hope that compiler is going to do this anyway. I 
have been burned in the past by compilers not inlining code even when 
explicitly stated, so I am a quite sceptical about compilers doing it 
proactively.

Your point is slightly different: why use code inlining at all? IMHO this 
discussion is outside the scope of this patch and should be conducted as a 
separate debate. Please feel free to start it as a separate thread if you deem 
necessary. As said, there are already 1700 instances of "static inline" in 
DPDK, as well as lots of "always inline".

In the context of this debate (outside the scope of this patch), my quick input 
is:  compilers are typically good to optimize code at the function level rather 
than cross-functions, so having more code in the same function allows the 
compiler to do a better job at code optimization. I am not a compiler expert, 
so my views could simply be biased by my past experience.

> > DPDK> grep 'static inline' `find -name '*.[hc]'` | wc -l
> > 1700

[dpdk-dev] DPDK hash function related question

[Dumitrescu, Cristian]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, September 22, 2015 4:41 PM
> To: Dumitrescu, Cristian
> Cc: dev at dpdk.org; Yeddula, Avinash; Bly, Mike
> Subject: Re: [dpdk-dev] DPDK hash function related question
> 
> 2015-09-22 10:05, Dumitrescu, Cristian:
> > Are you using a DPDK release older than 2.1?
> > In DPDK we moved away from test_hash to CRC-based hashes.
> > Please take a look at DPDK release 2.1 examples/ip_pipeline application:
> > in pipeline_flow_classification_be.c, we use CRC-based hash functions
> > defined in file hash_func.h from the same folder.
> 
> Has it already been said that these functions should be hosted elsewhere?
> e.g in librte_hash ;)

It is fine with me. Pablo, feel free to look at these functions and move them 
to librte_hash if useful.

We are looking to augment these functions to with some more for symmetric 
hashing during 2.2 (hopefully) or 2.3 development, might be better to wait for 
this until that time for a more comprehensible solution.

Regards,
Cristian

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

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, September 16, 2015 10:51 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] ethdev: add new RX/TX queue state arrays in 
> rte_eth_dev_data
> 
> Following the same approach taken with dev_started field
> in rte_eth_dev_data structure, this patch adds two new fields
> in it, rx_queue_state and tx_queue_state arrays, which track
> which queues have been started and which not.
> 
> This is important to avoid trying to start/stop twice a queue,
> which will result in undefined behaviour
> (which may cause RX/TX disruption).
> 
> Mind that only the PMDs which have queue_start/stop functions
> have been changed to update this field, as the functions will
> check the queue state before switching it.
> 
> Signed-off-by: Pablo de Lara 

Acked-by: Konstantin Ananyev 

> ---

[dpdk-dev] [PATCH v5 resend 03/12] vhost: vring queue setup for multiple queue support

[Yuanhan Liu]

On Tue, Sep 22, 2015 at 05:51:02PM +0300, Marcel Apfelbaum wrote:
> >It's proved to work after the fix (at least in my testing), but
> >it's late here and I'm gonna send a new version tomorrow, including
> >some other comments addressing. Please do more test then :)
> >

It's unlikely that I will send another version unless I have clear clue
how to address a comment from Michael about vring flush.

But anyway, you still could help me to prove the fix works. You can
apply the attachment on top of my old patchset, and it should work.

--yliu
> 
> Those are very good news!
> Tomorrow we have holidays but the day after that I'll try it for sure.

-- next part --
diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index 33bdacd..d304ee6 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -467,6 +467,8 @@ static int
 set_features(struct vhost_device_ctx ctx, uint64_t *pu)
 {
struct virtio_net *dev;
+   uint16_t vhost_hlen;
+   uint16_t i;

dev = get_device(ctx);
if (dev == NULL)
@@ -474,27 +476,26 @@ set_features(struct vhost_device_ctx ctx, uint64_t *pu)
if (*pu & ~VHOST_FEATURES)
return -1;

-   /* Store the negotiated feature list for the device. */
dev->features = *pu;
-
-   /* Set the vhost_hlen depending on if VIRTIO_NET_F_MRG_RXBUF is set. */
if (dev->features & (1 << VIRTIO_NET_F_MRG_RXBUF)) {
LOG_DEBUG(VHOST_CONFIG,
"(%"PRIu64") Mergeable RX buffers enabled\n",
dev->device_fh);
-   dev->virtqueue[VIRTIO_RXQ]->vhost_hlen =
-   sizeof(struct virtio_net_hdr_mrg_rxbuf);
-   dev->virtqueue[VIRTIO_TXQ]->vhost_hlen =
-   sizeof(struct virtio_net_hdr_mrg_rxbuf);
+   vhost_hlen = sizeof(struct virtio_net_hdr_mrg_rxbuf);
} else {
LOG_DEBUG(VHOST_CONFIG,
"(%"PRIu64") Mergeable RX buffers disabled\n",
dev->device_fh);
-   dev->virtqueue[VIRTIO_RXQ]->vhost_hlen =
-   sizeof(struct virtio_net_hdr);
-   dev->virtqueue[VIRTIO_TXQ]->vhost_hlen =
-   sizeof(struct virtio_net_hdr);
+   vhost_hlen = sizeof(struct virtio_net_hdr);
+   }
+
+   for (i = 0; i < dev->virt_qp_nb; i++) {
+   uint16_t base_idx = i * VIRTIO_QNUM;
+
+   dev->virtqueue[base_idx + VIRTIO_RXQ]->vhost_hlen = vhost_hlen;
+   dev->virtqueue[base_idx + VIRTIO_TXQ]->vhost_hlen = vhost_hlen;
}
+
return 0;
 }

[dpdk-dev] Capture packets using DPDK

[Stephen Hemminger]

On Wed, 23 Sep 2015 18:43:37 +0530
K Rahul  wrote:

> We have downloaded DPDK v2.1.0 and built it with target 
> 'x86_64-native-linuxapp-gcc' using the setup.sh script provided in tools 
> directory. We are using 64-bit Centos 6.5 with kernel version 2.6.32 and 
> we had set the number of hugepages (per node) to 512.  Our capture card 
> is *Broadcom NetXtreme II BCM5709 Gigabit Ethernet* on which we want to 
> use dpdk and the system config is i7 quad-core at 3.4Ghz with 
> Hyperthreading ON, which supports 2MB hugepages.

The bnx2x driver only supports the Broadcom 10G cards, not the 1G cards.

If you look at Linux you will see the 1G cards use a different driver (bnx2)
than the 10G cards (bnx2x).

[dpdk-dev] [RFC PATCH v1] rte: LCore heartbeat example

[Remy Horton]

On 15/09/2015 14:10, Thomas Monjalon wrote:
> 2015-09-15 13:16, Remy Horton:
>> Provides a basic framework for detecting and reporting live-ness of
>> LCores, the primary requirement of which is minimal overheads for the
>> core(s) being checked. Core failures are notified via an application
>> defined callback. As an example l2fwd with random failures is used.
> No it's not a framework, it's a sample application.
> If the feature is interesting, it must be integrated in a library.

We are looking into this and will get back.

..Remy

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

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qiu, Michael
> Sent: Wednesday, September 23, 2015 7:57 AM
> To: Stephen Hemminger; De Lara Guarch, Pablo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] ethdev: add new RX/TX queue state arrays 
> in rte_eth_dev_data
> 
> On 2015/9/22 6:40, Stephen Hemminger wrote:
> > On Wed, 16 Sep 2015 22:51:24 +0100
> > Pablo de Lara  wrote:
> >
> >> This is important to avoid trying to start/stop twice a queue,
> >> which will result in undefined behaviour
> >> (which may cause RX/TX disruption).
> >>
> >> Mind that only the PMDs which have queue_start/stop functions
> >> have been changed to update this field, as the functions will
> >> check the queue state before switching it.
> >>
> >> Signed-off-by: Pablo de Lara 
> > I agree that the DPDK API should check for buggy manipulation
> > in the control path. But this should be done in generic code.
> > Anything where you have to change any driver is making more work
> > than necessary.
> 
> I agree with you, but I have a question, why we need expose the queue
> start and stop function to app?
> 
> In my opinion, user app will hardly to start a device but stop the
> device queue. what's the purpose of it?
> 

There are use cases when application need to start/stop individual queues.
DPDK vhost app would be one of the examples.   

Konstantin

> Thanks,
> Michael

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

[De Lara Guarch, Pablo]

> -Original Message-
> From: Qiu, Michael
> Sent: Wednesday, September 23, 2015 7:57 AM
> To: Stephen Hemminger; De Lara Guarch, Pablo
> Cc: dev at dpdk.org; thomas.monjalon at 6wind.com
> Subject: Re: [dpdk-dev] [PATCH v2] ethdev: add new RX/TX queue state
> arrays in rte_eth_dev_data
> 
> On 2015/9/22 6:40, Stephen Hemminger wrote:
> > On Wed, 16 Sep 2015 22:51:24 +0100
> > Pablo de Lara  wrote:
> >
> >> This is important to avoid trying to start/stop twice a queue,
> >> which will result in undefined behaviour
> >> (which may cause RX/TX disruption).
> >>
> >> Mind that only the PMDs which have queue_start/stop functions
> >> have been changed to update this field, as the functions will
> >> check the queue state before switching it.
> >>
> >> Signed-off-by: Pablo de Lara 
> > I agree that the DPDK API should check for buggy manipulation
> > in the control path. But this should be done in generic code.
> > Anything where you have to change any driver is making more work
> > than necessary.
> 

I see little way to set the queue state without touching the PMDs.
Basically, because queues can be started either calling directly
the function from the PMDs or calling the generic function from ethdev,
therefore some code must be placed in the PMDs.

I guess  there are two possible ways to overcome this:

 - Use in all PMDs rte_eth_rx_queue_start/stop, instead of directly 
  the internal functions: first, it is necessary the port id, which I am not 
sure if it is always available
 (plus, when it is, it is available in the specific queue of that PMD, so it 
does not have to be there).
 Anyway, this option requires changing the PMDs.

- Apparently, the only function that calls these queue_start/stop functions is 
dev_start/stop.
   In some PMDs, it is possible to defer the start of some queues, so it would 
not initialize
   these queues, but in other PMDs this is not implemented.
   We will also be depending at how it is going on within the PMDs,
   so the code will not be generic either.

Any ideas to make this truly generic?

> I agree with you, but I have a question, why we need expose the queue
> start and stop function to app?
> 
> In my opinion, user app will hardly to start a device but stop the
> device queue. what's the purpose of it?

This API was added in 1.7 if I am not wrong. The purpose was that user could 
decide
not to start some of the queues in a device at start up, and then a new API to 
start 
these queues was necessary, but there were no checks of their current state,
leading to undefined behaviour.

Thanks both Stephen and Michael,

Pablo
> 
> Thanks,
> Michael

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

[Qiu, Michael]

On 2015/9/22 6:40, Stephen Hemminger wrote:
> On Wed, 16 Sep 2015 22:51:24 +0100
> Pablo de Lara  wrote:
>
>> This is important to avoid trying to start/stop twice a queue,
>> which will result in undefined behaviour
>> (which may cause RX/TX disruption).
>>
>> Mind that only the PMDs which have queue_start/stop functions
>> have been changed to update this field, as the functions will
>> check the queue state before switching it.
>>
>> Signed-off-by: Pablo de Lara 
> I agree that the DPDK API should check for buggy manipulation
> in the control path. But this should be done in generic code.
> Anything where you have to change any driver is making more work
> than necessary.

I agree with you, but I have a question, why we need expose the queue
start and stop function to app?

In my opinion, user app will hardly to start a device but stop the
device queue. what's the purpose of it?

Thanks,
Michael