[dpdk-dev] [PATCH] ivshmem: fix for modified mempool struct
2016-07-01 17:26, Ferruh Yigit:
> struct rte_mempool changed its "ring" field to "pool_data"
>
> "ring" field is accessed by ivshmem library, and updated to "pool_data"
>
> This patch fixes the compile error:
>
> == Build lib/librte_ivshmem
> CC rte_ivshmem.o
> .../lib/librte_ivshmem/rte_ivshmem.c:
> In function 'add_mempool_to_metadata':
> .../lib/librte_ivshmem/rte_ivshmem.c:584:32:
> error: 'const struct rte_mempool' has no member named 'ring'
> return add_ring_to_metadata(mp->ring, config);
> ^~
>
> Fixes: 449c49b93a6b ("mempool: support handler operations")
> Signed-off-by: Ferruh Yigit
Applied, thanks
[dpdk-dev] [PATCH] ivshmem: fix for modified mempool struct
On 1/7/2016 5:26 PM, Ferruh Yigit wrote:
> struct rte_mempool changed its "ring" field to "pool_data"
>
> "ring" field is accessed by ivshmem library, and updated to "pool_data"
>
> This patch fixes the compile error:
>
> == Build lib/librte_ivshmem
>CC rte_ivshmem.o
> .../lib/librte_ivshmem/rte_ivshmem.c:
> In function 'add_mempool_to_metadata':
> .../lib/librte_ivshmem/rte_ivshmem.c:584:32:
> error: 'const struct rte_mempool' has no member named 'ring'
>return add_ring_to_metadata(mp->ring, config);
> ^~
>
> Fixes: 449c49b93a6b ("mempool: support handler operations")
> Signed-off-by: Ferruh Yigit
> ---
> lib/librte_ivshmem/rte_ivshmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_ivshmem/rte_ivshmem.c
> b/lib/librte_ivshmem/rte_ivshmem.c
> index 5c83920..c26edb6 100644
> --- a/lib/librte_ivshmem/rte_ivshmem.c
> +++ b/lib/librte_ivshmem/rte_ivshmem.c
> @@ -581,7 +581,7 @@ add_mempool_to_metadata(const struct rte_mempool *mp,
> }
>
> /* mempool consists of memzone and ring */
> - return add_ring_to_metadata(mp->ring, config);
> + return add_ring_to_metadata(mp->pool_data, config);
> }
>
> int
Acked-by: David Hunt
[dpdk-dev] e1000: unused variable warnings with clang
On 7/1/16, 12:16 PM, "dev on behalf of Wiles, Keith" wrote: Well, after make sure I had CCACHE off and having the RTE_SDK variable set correctly, it does appear we have a problem building DPDK/e1000 directory with CLANG on my Ubuntu 16.04 updated as of today. If someone could please verify the if this is something in my system. Using T=x86_64-native-linuxapp-gcc does not have the same problem. Using the following build line: -- Sorry my bad, this is NOT a problem. Today is not my day ? woke up at 4:30am
[dpdk-dev] [PATCH] ivshmem: fix for modified mempool struct
struct rte_mempool changed its "ring" field to "pool_data"
"ring" field is accessed by ivshmem library, and updated to "pool_data"
This patch fixes the compile error:
== Build lib/librte_ivshmem
CC rte_ivshmem.o
.../lib/librte_ivshmem/rte_ivshmem.c:
In function 'add_mempool_to_metadata':
.../lib/librte_ivshmem/rte_ivshmem.c:584:32:
error: 'const struct rte_mempool' has no member named 'ring'
return add_ring_to_metadata(mp->ring, config);
^~
Fixes: 449c49b93a6b ("mempool: support handler operations")
Signed-off-by: Ferruh Yigit
---
lib/librte_ivshmem/rte_ivshmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_ivshmem/rte_ivshmem.c b/lib/librte_ivshmem/rte_ivshmem.c
index 5c83920..c26edb6 100644
--- a/lib/librte_ivshmem/rte_ivshmem.c
+++ b/lib/librte_ivshmem/rte_ivshmem.c
@@ -581,7 +581,7 @@ add_mempool_to_metadata(const struct rte_mempool *mp,
}
/* mempool consists of memzone and ring */
- return add_ring_to_metadata(mp->ring, config);
+ return add_ring_to_metadata(mp->pool_data, config);
}
int
--
2.7.4
[dpdk-dev] e1000: unused variable warnings with clang
Well, after make sure I had CCACHE off and having the RTE_SDK variable set correctly, it does appear we have a problem building DPDK/e1000 directory with CLANG on my Ubuntu 16.04 updated as of today. If someone could please verify the if this is something in my system. Using T=x86_64-native-linuxapp-gcc does not have the same problem. Using the following build line: rkwiles at supermicro (master):~/.../intel/dpdk$ CCACHE_DISABLE=true make install T=x86_64-native-linuxapp-clang -j Configuration done == Build lib == Build lib/librte_compat == Build lib/librte_eal == Build lib/librte_net == Build lib/librte_eal/common SYMLINK-FILE include/rte_compat.h SYMLINK-FILE include/rte_ip.h ---Snip--- CC igb_ethdev.o CC em_ethdev.o CC e1000_osdep.o CC i40e_ethdev_vf.o CC igb_rxtx.o CC e1000_ich8lan.o CC null_crypto_pmd_ops.o CC e1000_phy.o /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:44:38: error: unused parameter 'hw' [-Werror,-Wunused-parameter] e1000_write_pci_cfg(struct e1000_hw *hw, u32 reg, u16 *value) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:44:46: error: unused parameter 'reg' [-Werror,-Wunused-parameter] e1000_write_pci_cfg(struct e1000_hw *hw, u32 reg, u16 *value) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:44:56: error: unused parameter 'value' [-Werror,-Wunused-parameter] e1000_write_pci_cfg(struct e1000_hw *hw, u32 reg, u16 *value) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:50:37: error: unused parameter 'hw' [-Werror,-Wunused-parameter] e1000_read_pci_cfg(struct e1000_hw *hw, u32 reg, u16 *value) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:50:45: error: unused parameter 'reg' [-Werror,-Wunused-parameter] e1000_read_pci_cfg(struct e1000_hw *hw, u32 reg, u16 *value) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:57:36: error: unused parameter 'hw' [-Werror,-Wunused-parameter] e1000_pci_set_mwi(struct e1000_hw *hw) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:62:38: error: unused parameter 'hw' [-Werror,-Wunused-parameter] e1000_pci_clear_mwi(struct e1000_hw *hw) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:71:42: error: unused parameter 'hw' [-Werror,-Wunused-parameter] e1000_read_pcie_cap_reg(struct e1000_hw *hw, u32 reg, u16 *value) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:71:50: error: unused parameter 'reg' [-Werror,-Wunused-parameter] e1000_read_pcie_cap_reg(struct e1000_hw *hw, u32 reg, u16 *value) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:71:60: error: unused parameter 'value' [-Werror,-Wunused-parameter] e1000_read_pcie_cap_reg(struct e1000_hw *hw, u32 reg, u16 *value) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:80:43: error: unused parameter 'hw' [-Werror,-Wunused-parameter] e1000_write_pcie_cap_reg(struct e1000_hw *hw, u32 reg, u16 *value) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:80:51: error: unused parameter 'reg' [-Werror,-Wunused-parameter] e1000_write_pcie_cap_reg(struct e1000_hw *hw, u32 reg, u16 *value) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_osdep.c:80:61: error: unused parameter 'value' [-Werror,-Wunused-parameter] e1000_write_pcie_cap_reg(struct e1000_hw *hw, u32 reg, u16 *value) ^ 13 errors generated. /work/home/rkwiles/projects/intel/dpdk/mk/internal/rte.compile-pre.mk:126: recipe for target 'e1000_osdep.o' failed make[6]: *** [e1000_osdep.o] Error 1 make[6]: *** Waiting for unfinished jobs /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_vf.c:161:62: error: unused parameter 'hw' [-Werror,-Wunused-parameter] STATIC s32 e1000_acquire_vf(struct e1000_hw E1000_UNUSEDARG *hw) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_vf.c:175:63: error: unused parameter 'hw' [-Werror,-Wunused-parameter] STATIC void e1000_release_vf(struct e1000_hw E1000_UNUSEDARG *hw) ^ /work/home/rkwiles/projects/intel/dpdk/drivers/net/e1000/base/e1000_vf.c:187:65: error: unused parameter 'hw'
[dpdk-dev] SR-IOV/DPDK/VPP with vfio-pci
[root at localhost ~]# modinfo i40e filename: /lib/modules/3.10.0-327.18.2.el7.x86_64/updates/drivers/net/ethernet/intel/i40e/i40e.ko version:1.4.25 [root at localhost ~]# modinfo i40evf filename: /lib/modules/3.10.0-327.18.2.el7.x86_64/updates/drivers/net/ethernet/intel/i40evf/i40evf.ko version:1.4.15 dpdk ver : 16.04 nic type : 83:00.0 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 02) [root at localhost ~]# ethtool -i ens11 driver: i40e version: 1.4.25 firmware-version: 5.04 0x8000253b 0.0.0 bus-info: :83:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes [root at localhost ~]# Testcase: - Enable SRIOV # echo 4 > /sys/class/net/ens11/device/sriov_numvfs 83:00.0 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 02) 83:02.0 Ethernet controller: Intel Corporation XL710/X710 Virtual Function (rev 02) 83:02.1 Ethernet controller: Intel Corporation XL710/X710 Virtual Function (rev 02) 83:02.2 Ethernet controller: Intel Corporation XL710/X710 Virtual Function (rev 02) 83:02.3 Ethernet controller: Intel Corporation XL710/X710 Virtual Function (rev 02) 85:00.0 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 02) - modprobe vfio-pci [root at localhost ~]# /root/ckannan/vpp/build-root/build-vpp-native/dpdk/dpdk-16.04/tools/dpdk_nic_bind.py --bind=vfio-pci :83:02.0 [root at localhost ~]# /root/ckannan/vpp/build-root/build-vpp-native/dpdk/dpdk-16.04/tools/dpdk_nic_bind.py --bind=vfio-pci :83:02.1 [root at localhost ~]# /root/ckannan/vpp/build-root/build-vpp-native/dpdk/dpdk-16.04/tools/dpdk_nic_bind.py --bind=vfio-pci :83:02.2 [root at localhost ~]# /root/ckannan/vpp/build-root/build-vpp-native/dpdk/dpdk-16.04/tools/dpdk_nic_bind.py --bind=vfio-pci :83:02.3 - launch testpmd ./testpmd -l 13,14,15,16 -n 4 -- -i -a --nb-cores=3 --nb-ports=1 I start seeing errors like these... Jul 01 17:23:29 localhost.localdomain kernel: dmar: DRHD: handling fault status reg 2 Jul 01 17:23:29 localhost.localdomain kernel: dmar: DMAR:[DMA Write] Request device [83:02.0] fault addr 0 DMAR:[fault reason 05] PTE Write access is not set Jul 01 17:23:29 localhost.localdomain kernel: i40e :83:00.0: TX driver issue detected, PF reset issued Jul 01 17:23:29 localhost.localdomain kernel: i40e :83:00.0: TX driver issue detected on VF 0 On Sun, Jun 5, 2016 at 8:47 AM, Zhang, Helin wrote: > Hi Kannan > > Could you help to provide more details of your test cases? How to > reproduce that issue? It would be better to try with DPDK example > applications. > I think the kernel driver version, DPDK version, XL710 firmware version > are the basic information we want to know. > If possible, I'd suggest you to try with latest version of above and try > if the issue is still there. > Thank you very much! > > Regards, > Helin > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Chandrasekar > > Kannan > > Sent: Thursday, June 2, 2016 2:22 AM > > To: dev at dpdk.org > > Subject: [dpdk-dev] SR-IOV/DPDK/VPP with vfio-pci > > > > I have been attempting to VPP (dpdk) application with SR-IOV enabled. > > Using the vfio-pci driver/i40e/XL710nics/. > > I'm encountering a SEGV on the i40e code path. > > > > Has anyone else seen this behaviour ?. > > > > full mail thread discussion with vpp-dev is here - > > https://lists.fd.io/pipermail/vpp-dev/2016-June/001348.html > > > > > > > > here's a backtrace during vpp crash... > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x7f2b811fd700 (LWP 8725)] > > 0x00455539 in rx_recv_pkts () > > (gdb) backtrace > > #0 0x00455539 in rx_recv_pkts () > > #1 0x00455e76 in i40e_recv_pkts_bulk_alloc () > > #2 0x7f2be43d8bf7 in rte_eth_rx_burst (nb_pkts=256, > > rx_pkts=0x7f2bb1e66a80, queue_id=1, port_id=) > > at > > /w/workspace/vpp-merge-master-centos7/build-root/install-vpp- > > native/dpdk/include/rte_ethdev.h:2641 > > #3 dpdk_rx_burst (dm=0x7f2be4673980 , queue_id=1, > > xd=0x7f2bb1898540) > > at > > /w/workspace/vpp-merge-master-centos7/build- > > data/../vnet/vnet/devices/dpdk/dpdk_priv.h:64 > > #4 dpdk_device_input (dm=0x7f2be4673980 , queue_id=1, > > cpu_index=, node=0x7f2bb1ef59fc, xd=) > > at > > /w/workspace/vpp-merge-master-centos7/build- > > data/../vnet/vnet/devices/dpdk/node.c:508 > > #5 dpdk_input_rss (vm=, node=0x7f2bb1ef59fc, > > f= > out>) > > at > > /w/workspace/vpp-merge-master-centos7/build- > > data/../vnet/vnet/devices/dpdk/node.c:821 > > #6 0x7f2be47eb77a in dispatch_node (vm=vm at entry=0x7f2bb1f02cd4, > > node=node at entry=0x7f2bb1ef59fc, > > type=type at entry=VLIB_NODE_TYPE_INPUT, > > dispatch_state=dispatch_state at entry=VLIB_NODE_STATE_POLLING,
[dpdk-dev] [PATCH v3] igb_uio: fix possible mmap failure for Linux >= v4.5
mmap the iomem range of the PCI device fails for kernels that
enabled CONFIG_IO_STRICT_DEVMEM option:
EAL: pci_map_resource():
cannot mmap(39, 0x7f1c5180, 0x10, 0x0):
Invalid argument (0x)
CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.5 and not enabled
by default:
Linux commit: 90a545e restrict /dev/mem to idle io memory ranges
As a workaround igb_uio can stop reserving PCI memory resources, from
kernel point of view iomem region looks like idle and mmap works
again. This matches uio_pci_generic usage.
With this update device iomem range is not protected against any
other kernel drivers or userspace access. But this shouldn't
be a problem for dpdk usage module since purpose of the igb_uio
module is to provide userspace access.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Ferruh Yigit
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 45a5720..df41e45 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -342,16 +342,6 @@ igbuio_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
goto fail_free;
}
- /*
-* reserve device's PCI memory regions for use by this
-* module
-*/
- err = pci_request_regions(dev, "igb_uio");
- if (err != 0) {
- dev_err(>dev, "Cannot request regions\n");
- goto fail_disable;
- }
-
/* enable bus mastering on the device */
pci_set_master(dev);
@@ -441,8 +431,6 @@ fail_release_iomem:
igbuio_pci_release_iomem(>info);
if (udev->mode == RTE_INTR_MODE_MSIX)
pci_disable_msix(udev->pdev);
- pci_release_regions(dev);
-fail_disable:
pci_disable_device(dev);
fail_free:
kfree(udev);
@@ -460,7 +448,6 @@ igbuio_pci_remove(struct pci_dev *dev)
igbuio_pci_release_iomem(>info);
if (udev->mode == RTE_INTR_MODE_MSIX)
pci_disable_msix(dev);
- pci_release_regions(dev);
pci_disable_device(dev);
pci_set_drvdata(dev, NULL);
kfree(udev);
--
2.7.4
[dpdk-dev] [PATCH v2] igb_uio: fix possible mmap failure for Linux > v4.3
On 7/1/2016 4:52 PM, De Lara Guarch, Pablo wrote:
> Hi Ferruh,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ferruh Yigit
>> Sent: Friday, July 01, 2016 4:08 PM
>> To: dev at dpdk.org
>> Cc: Stephen Hemminger
>> Subject: [dpdk-dev] [PATCH v2] igb_uio: fix possible mmap failure for Linux >
>> v4.3
>>
>> mmap the iomem range of the PCI device fails for kernels that
>> enabled CONFIG_IO_STRICT_DEVMEM option:
>>
>> EAL: pci_map_resource():
>> cannot mmap(39, 0x7f1c5180, 0x10, 0x0):
>> Invalid argument (0x)
>>
>> CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.4 and not enabled
>> by default:
>
> This was introduced in kernel 4.5 (change the title as well ;))
"git describe" mislead me but you are right, I will update
$ git describe 90a545e
v4.4-rc5-2-g90a545e
Thanks
>
>> Linux commit: 90a545e restrict /dev/mem to idle io memory ranges
>>
>> As a workaround igb_uio can stop reserving PCI memory resources, from
>> kernel point of view iomem region looks like idle and mmap works
>> again. This matches uio_pci_generic usage.
>>
>> With this update device iomem range is not protected against any
>> other kernel drivers or userspace access. But this shouldn't
>> be a problem for dpdk usage module since purpose of the igb_uio
>> module is to provide userspace access.
>>
>> Fixes: af75078fece3 ("first public release")
>> Signed-off-by: Ferruh Yigit
>
[dpdk-dev] [PATCH] igb_uio: fix mmap failure
2016-07-01 15:39, Ferruh Yigit: > On 7/1/2016 1:47 PM, Thomas Monjalon wrote: > >> As a workaround igb_uio can stop reserving PCI memory resources, from > >> kernel point of view io-memory region looks like idle and mmap works > >> again. > >> > >> With this update device io-memory range is not protected against any > >> other kernel driver claim ownership on those resources, which shouldn't > >> be a problem for dpdk usage module. > > > > Why it should not be a problem? > > request_mem_region() is a way for driver informing the rest of the > kernel that memory region is used. > And with CONFIG_IO_STRICT_DEVMEM=y, userspace also prevented to touch > that ares. > But for igb_uio, we explicitly want userspace to access that memory range. > > > Please could you give an example of what could happen? > > Technically device lost a protection of its memory region against any > other driver, but I am not sure if this is real threat in practical life. > Also this is same in uio_pci_generic, it doesn't reserve the memory. OK thanks for the explanations. So we are not sure how this memory region can be stolen and we assume it won't. > > This patch fixes a problem with recent kernels (not mentioned above) > > which offer the uio_pci_generic alternative. > > Will give kernel version information. > > > That's why I think we should fix it only if there is absolutely no > > regression for older kernels. > > Totally agreed, that is why I expressed my concern, let this patch hang > around a little. It may be valuable to have in 16.07. I suggest to wait RC3 (mid-July) to integrate it. We will have a RC4 to test it.
[dpdk-dev] [PATCH v2 0/3] Virtio NEON support for ARM
This patch-set includes, 1) General cleanup of compile time dependency. 2) made vector handler section based on run-time cpuflags 2) Added NEON support for optimized Rx handling This patch-set is based on dpdk-next-virtio/master v2: - made vector handler selection based on run-time cpuflags (Suggested by Thomas) - moved vector implementations to .c file instead of .h file(Suggested by Jianbo) Jerin Jacob (3): virtio: conditional compilation cleanup virtio: move SSE based Rx implementation to separate file virtio: add neon support MAINTAINERS | 1 + doc/guides/rel_notes/release_16_07.rst | 2 + drivers/net/vision/Wakefully | 7 +- drivers/net/virtio/virtio_pci.h | 1 + drivers/net/virtio/virtio_rxtx.c | 62 +++--- drivers/net/virtio/virtio_rxtx.h | 3 +- drivers/net/virtio/virtio_rxtx_simple.c | 269 ++- drivers/net/virtio/virtio_rxtx_simple.h | 133 + drivers/net/virtio/virtio_rxtx_simple_neon.c | 235 +++ drivers/net/virtio/virtio_rxtx_simple_sse.c | 222 ++ drivers/net/virtio/virtio_user_ethdev.c | 1 + 11 files changed, 646 insertions(+), 290 deletions(-) create mode 100644 drivers/net/virtio/virtio_rxtx_simple.h create mode 100644 drivers/net/virtio/virtio_rxtx_simple_neon.c create mode 100644 drivers/net/virtio/virtio_rxtx_simple_sse.c -- 2.5.5
[dpdk-dev] [PATCH v2 3/3] virtio: add neon support
Added neon based Rx vector implementation. Selection of the new handler based neon availability at runtime. Updated the release notes and MAINTAINERS file. Signed-off-by: Jerin Jacob --- MAINTAINERS | 1 + doc/guides/rel_notes/release_16_07.rst | 2 + drivers/net/virtio/Makefile | 2 + drivers/net/virtio/virtio_rxtx.c | 3 + drivers/net/virtio/virtio_rxtx_simple_neon.c | 235 +++ 5 files changed, 243 insertions(+) create mode 100644 drivers/net/virtio/virtio_rxtx_simple_neon.c diff --git a/MAINTAINERS b/MAINTAINERS index a59191e..ab04cee 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -143,6 +143,7 @@ F: lib/librte_acl/acl_run_neon.* F: lib/librte_lpm/rte_lpm_neon.h F: lib/librte_hash/rte*_arm64.h F: drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c +F: drivers/net/virtio/virtio_rxtx_simple_neon.c EZchip TILE-Gx M: Zhigang Lu diff --git a/doc/guides/rel_notes/release_16_07.rst b/doc/guides/rel_notes/release_16_07.rst index 9e2a817..3a5add5 100644 --- a/doc/guides/rel_notes/release_16_07.rst +++ b/doc/guides/rel_notes/release_16_07.rst @@ -174,6 +174,8 @@ New Features section of the "Network Interface Controller Drivers" document. +* **Virtio NEON support for ARM.** + Resolved Issues --- diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile index c4103b7..97972a6 100644 --- a/drivers/net/virtio/Makefile +++ b/drivers/net/virtio/Makefile @@ -54,6 +54,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple.c ifeq ($(CONFIG_RTE_ARCH_X86),y) SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple_sse.c +else ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) +SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple_neon.c endif ifeq ($(CONFIG_RTE_VIRTIO_USER),y) diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c index a4d4a57..19d1742 100644 --- a/drivers/net/virtio/virtio_rxtx.c +++ b/drivers/net/virtio/virtio_rxtx.c @@ -481,6 +481,9 @@ virtio_update_rxtx_handler(struct rte_eth_dev *dev, #if defined RTE_ARCH_X86 if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SSE3)) use_simple_rxtx = 1; +#elif defined RTE_ARCH_ARM64 || defined CONFIG_RTE_ARCH_ARM + if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON)) + use_simple_rxtx = 1; #endif /* Use simple rx/tx func if single segment and no offloads */ if (use_simple_rxtx && diff --git a/drivers/net/virtio/virtio_rxtx_simple_neon.c b/drivers/net/virtio/virtio_rxtx_simple_neon.c new file mode 100644 index 000..793eefb --- /dev/null +++ b/drivers/net/virtio/virtio_rxtx_simple_neon.c @@ -0,0 +1,235 @@ +/* + * BSD LICENSE + * + * Copyright (C) Cavium networks Ltd. 2016 + * + * 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 Cavium networks nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +*/ + +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "virtio_rxtx_simple.h" + +#define RTE_VIRTIO_VPMD_RX_BURST 32 +#define RTE_VIRTIO_DESC_PER_LOOP 8 +#define RTE_VIRTIO_VPMD_RX_REARM_THRESH RTE_VIRTIO_VPMD_RX_BURST + +/* virtio vPMD receive routine, only accept(nb_pkts >= RTE_VIRTIO_DESC_PER_LOOP) + * + * This routine is for non-mergeable RX, one desc for each guest buffer. + * This routine is based on the RX
[dpdk-dev] [PATCH v2 2/3] virtio: move SSE based Rx implementation to separate file
* Introduced cpuflag based run-time detection to
select the SSE based simple Rx handler
* Split out SSE instruction based virtio simple Rx
implementation to a separate file
Signed-off-by: Jerin Jacob
---
drivers/net/virtio/Makefile | 4 +
drivers/net/virtio/virtio_rxtx.c| 35 ++--
drivers/net/virtio/virtio_rxtx_simple.c | 273 ++--
drivers/net/virtio/virtio_rxtx_simple.h | 133 ++
drivers/net/virtio/virtio_rxtx_simple_sse.c | 222 ++
5 files changed, 394 insertions(+), 273 deletions(-)
create mode 100644 drivers/net/virtio/virtio_rxtx_simple.h
create mode 100644 drivers/net/virtio/virtio_rxtx_simple_sse.c
diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile
index b9b0d8d..c4103b7 100644
--- a/drivers/net/virtio/Makefile
+++ b/drivers/net/virtio/Makefile
@@ -52,6 +52,10 @@ SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx.c
SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_ethdev.c
SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple.c
+ifeq ($(CONFIG_RTE_ARCH_X86),y)
+SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple_sse.c
+endif
+
ifeq ($(CONFIG_RTE_VIRTIO_USER),y)
SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_user/vhost_user.c
SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_user/virtio_user_dev.c
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 63b53f7..a4d4a57 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include "virtio_logs.h"
#include "virtio_ethdev.h"
@@ -470,6 +471,28 @@ virtio_dev_rx_queue_release(void *rxq)
rte_memzone_free(mz);
}
+static void
+virtio_update_rxtx_handler(struct rte_eth_dev *dev,
+ const struct rte_eth_txconf *tx_conf)
+{
+ uint8_t use_simple_rxtx = 0;
+ struct virtio_hw *hw = dev->data->dev_private;
+
+#if defined RTE_ARCH_X86
+ if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SSE3))
+ use_simple_rxtx = 1;
+#endif
+ /* Use simple rx/tx func if single segment and no offloads */
+ if (use_simple_rxtx &&
+ (tx_conf->txq_flags & VIRTIO_SIMPLE_FLAGS) == VIRTIO_SIMPLE_FLAGS &&
+ !vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
+ PMD_INIT_LOG(INFO, "Using simple rx/tx path");
+ dev->tx_pkt_burst = virtio_xmit_pkts_simple;
+ dev->rx_pkt_burst = virtio_recv_pkts_vec;
+ hw->use_simple_rxtx = use_simple_rxtx;
+ }
+}
+
/*
* struct rte_eth_dev *dev: Used to update dev
* uint16_t nb_desc: Defaults to values read from config space
@@ -499,17 +522,7 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
return -EINVAL;
}
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
- struct virtio_hw *hw = dev->data->dev_private;
- /* Use simple rx/tx func if single segment and no offloads */
- if ((tx_conf->txq_flags & VIRTIO_SIMPLE_FLAGS) == VIRTIO_SIMPLE_FLAGS &&
-!vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
- PMD_INIT_LOG(INFO, "Using simple rx/tx path");
- dev->tx_pkt_burst = virtio_xmit_pkts_simple;
- dev->rx_pkt_burst = virtio_recv_pkts_vec;
- hw->use_simple_rxtx = 1;
- }
-#endif
+ virtio_update_rxtx_handler(dev, tx_conf);
ret = virtio_dev_queue_setup(dev, VTNET_TQ, queue_idx, vtpci_queue_idx,
nb_desc, socket_id, (void **));
diff --git a/drivers/net/virtio/virtio_rxtx_simple.c
b/drivers/net/virtio/virtio_rxtx_simple.c
index 67430da..485ddce 100644
--- a/drivers/net/virtio/virtio_rxtx_simple.c
+++ b/drivers/net/virtio/virtio_rxtx_simple.c
@@ -51,14 +51,7 @@
#include
#include
-#include "virtio_logs.h"
-#include "virtio_ethdev.h"
-#include "virtqueue.h"
-#include "virtio_rxtx.h"
-
-#define RTE_VIRTIO_VPMD_RX_BURST 32
-#define RTE_VIRTIO_DESC_PER_LOOP 8
-#define RTE_VIRTIO_VPMD_RX_REARM_THRESH RTE_VIRTIO_VPMD_RX_BURST
+#include "virtio_rxtx_simple.h"
#ifndef __INTEL_COMPILER
#pragma GCC diagnostic ignored "-Wcast-qual"
@@ -89,260 +82,6 @@ virtqueue_enqueue_recv_refill_simple(struct virtqueue *vq,
return 0;
}
-static inline void
-virtio_rxq_rearm_vec(struct virtnet_rx *rxvq)
-{
- int i;
- uint16_t desc_idx;
- struct rte_mbuf **sw_ring;
- struct vring_desc *start_dp;
- int ret;
- struct virtqueue *vq = rxvq->vq;
-
- desc_idx = vq->vq_avail_idx & (vq->vq_nentries - 1);
- sw_ring = >sw_ring[desc_idx];
- start_dp = >vq_ring.desc[desc_idx];
-
- ret = rte_mempool_get_bulk(rxvq->mpool, (void **)sw_ring,
- RTE_VIRTIO_VPMD_RX_REARM_THRESH);
- if (unlikely(ret)) {
- rte_eth_devices[rxvq->port_id].data->rx_mbuf_alloc_failed +=
- RTE_VIRTIO_VPMD_RX_REARM_THRESH;
- return;
- }
-
-
[dpdk-dev] [PATCH v2 1/3] virtio: conditional compilation cleanup
Removed unnecessary compile time dependency on "use_simple_rxtx".
Signed-off-by: Jerin Jacob
---
drivers/net/virtio/Makefile | 3 ---
drivers/net/virtio/virtio_pci.h | 1 +
drivers/net/virtio/virtio_rxtx.c| 28 +---
drivers/net/virtio/virtio_rxtx.h| 3 +--
drivers/net/virtio/virtio_rxtx_simple.c | 8 ++--
drivers/net/virtio/virtio_user_ethdev.c | 1 +
6 files changed, 18 insertions(+), 26 deletions(-)
diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile
index 3020b68..b9b0d8d 100644
--- a/drivers/net/virtio/Makefile
+++ b/drivers/net/virtio/Makefile
@@ -50,10 +50,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtqueue.c
SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_pci.c
SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx.c
SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_ethdev.c
-
-ifeq ($(findstring
RTE_MACHINE_CPUFLAG_SSSE3,$(CFLAGS)),RTE_MACHINE_CPUFLAG_SSSE3)
SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple.c
-endif
ifeq ($(CONFIG_RTE_VIRTIO_USER),y)
SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_user/vhost_user.c
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index dd7693f..b8295a7 100644
--- a/drivers/net/virtio/virtio_pci.h
+++ b/drivers/net/virtio/virtio_pci.h
@@ -253,6 +253,7 @@ struct virtio_hw {
uint8_t use_msix;
uint8_t started;
uint8_t modern;
+ uint8_t use_simple_rxtx;
uint8_t mac_addr[ETHER_ADDR_LEN];
uint32_tnotify_off_multiplier;
uint8_t *isr;
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index a27208e..63b53f7 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -67,10 +67,6 @@
#define VIRTIO_SIMPLE_FLAGS ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
ETH_TXQ_FLAGS_NOOFFLOADS)
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-static int use_simple_rxtx;
-#endif
-
static void
vq_ring_free_chain(struct virtqueue *vq, uint16_t desc_idx)
{
@@ -333,6 +329,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
*/
uint16_t i;
uint16_t desc_idx;
+ struct virtio_hw *hw = dev->data->dev_private;
PMD_INIT_FUNC_TRACE();
@@ -353,8 +350,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
nbufs = 0;
error = ENOSPC;
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
- if (use_simple_rxtx) {
+ if (hw->use_simple_rxtx) {
for (desc_idx = 0; desc_idx < vq->vq_nentries;
desc_idx++) {
vq->vq_ring.avail->ring[desc_idx] = desc_idx;
@@ -362,7 +358,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
VRING_DESC_F_WRITE;
}
}
-#endif
+
memset(>fake_mbuf, 0, sizeof(rxvq->fake_mbuf));
for (desc_idx = 0; desc_idx < RTE_PMD_VIRTIO_RX_MAX_BURST;
desc_idx++) {
@@ -378,12 +374,11 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
/**
* Enqueue allocated buffers*
***/
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
- if (use_simple_rxtx)
+ if (hw->use_simple_rxtx)
error =
virtqueue_enqueue_recv_refill_simple(vq, m);
else
-#endif
error = virtqueue_enqueue_recv_refill(vq, m);
+
if (error) {
rte_pktmbuf_free(m);
break;
@@ -404,8 +399,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
struct virtqueue *vq = txvq->vq;
virtio_dev_vring_start(vq);
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
- if (use_simple_rxtx) {
+ if (hw->use_simple_rxtx) {
uint16_t mid_idx = vq->vq_nentries >> 1;
for (desc_idx = 0; desc_idx < mid_idx; desc_idx++) {
@@ -426,7 +420,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
desc_idx++)
vq->vq_ring.avail->ring[desc_idx] = desc_idx;
}
-#endif
+
VIRTQUEUE_DUMP(vq);
}
}
@@ -456,9 +450,7 @@ virtio_dev_rx_queue_setup(struct rte_eth_dev *dev,
dev->data->rx_queues[queue_idx] = rxvq;
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
virtio_rxq_vec_setup(rxvq);
-#endif
return 0;
}
@@ -494,9 +486,6 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
{
uint8_t vtpci_queue_idx = 2 * queue_idx + VTNET_SQ_TQ_QUEUE_IDX;
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
- struct virtio_hw *hw = dev->data->dev_private;
-#endif
struct virtnet_tx *txvq;
[dpdk-dev] From: Jerin Jacob <jerin.ja...@caviumnetworks.com>
This patch-set includes, 1) General cleanup of compile time dependency. 2) made vector handler section based on run-time cpuflags 2) Added NEON support for optimized Rx handling This patch-set is based on dpdk-next-virtio/master at aaaf0c005 v2: - made vector handler selection based on run-time cpuflags (Suggested by Thomas) - moved vector implementations to .c file instead of .h file(Suggested by Jianbo) Jerin Jacob (3): virtio: conditional compilation cleanup virtio: move SSE based Rx implementation to separate file virtio: add neon support MAINTAINERS | 1 + doc/guides/rel_notes/release_16_07.rst | 2 + drivers/net/vision/Wakefully | 7 +- drivers/net/virtio/virtio_pci.h | 1 + drivers/net/virtio/virtio_rxtx.c | 62 +++--- drivers/net/virtio/virtio_rxtx.h | 3 +- drivers/net/virtio/virtio_rxtx_simple.c | 269 ++- drivers/net/virtio/virtio_rxtx_simple.h | 133 + drivers/net/virtio/virtio_rxtx_simple_neon.c | 235 +++ drivers/net/virtio/virtio_rxtx_simple_sse.c | 222 ++ drivers/net/virtio/virtio_user_ethdev.c | 1 + 11 files changed, 646 insertions(+), 290 deletions(-) create mode 100644 drivers/net/virtio/virtio_rxtx_simple.h create mode 100644 drivers/net/virtio/virtio_rxtx_simple_neon.c create mode 100644 drivers/net/virtio/virtio_rxtx_simple_sse.c -- 2.5.5
[dpdk-dev] [PATCH v4 2/2] mk: fix acl library static linking
2016-07-01 15:38, Sergio Gonzalez Monroy:
> Since below commit, ACL library is outside the scope of --whole-archive
> and ACL autotest fails.
>
> RTE>>acl_autotest
> ACL: allocation of 25166728 bytes on socket 9 for ACL_acl_ctx failed
> ACL: rte_acl_add_rules(acl_ctx): rule #1 is invalid
> Line 1584: SSE classify with zero categories failed!
> Test Failed
>
> This is the result of the linker picking weak over non-weak functions.
>
> Fixes: 95dc3c3cf31c ("mk: reduce scope of whole-archive static linking")
>
> Signed-off-by: Sergio Gonzalez Monroy
Series applied, thanks
[dpdk-dev] [PATCH] ethdev: enhance api doc for getting supported packet types
2016-07-01 10:43, Olivier Matz: > As discussed in http://dpdk.org/ml/archives/dev/2016-June/042229.html, > clarify the behavior of rte_eth_dev_get_supported_ptypes(). > > Signed-off-by: Olivier Matz Konstantin had already reviewed this text in the above thread. Applied, thanks Are we sure every drivers are satisfying this new constraint?
[dpdk-dev] [PATCH v2] igb_uio: fix possible mmap failure for Linux > v4.3
mmap the iomem range of the PCI device fails for kernels that
enabled CONFIG_IO_STRICT_DEVMEM option:
EAL: pci_map_resource():
cannot mmap(39, 0x7f1c5180, 0x10, 0x0):
Invalid argument (0x)
CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.4 and not enabled
by default:
Linux commit: 90a545e restrict /dev/mem to idle io memory ranges
As a workaround igb_uio can stop reserving PCI memory resources, from
kernel point of view iomem region looks like idle and mmap works
again. This matches uio_pci_generic usage.
With this update device iomem range is not protected against any
other kernel drivers or userspace access. But this shouldn't
be a problem for dpdk usage module since purpose of the igb_uio
module is to provide userspace access.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Ferruh Yigit
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 45a5720..df41e45 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -342,16 +342,6 @@ igbuio_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
goto fail_free;
}
- /*
-* reserve device's PCI memory regions for use by this
-* module
-*/
- err = pci_request_regions(dev, "igb_uio");
- if (err != 0) {
- dev_err(>dev, "Cannot request regions\n");
- goto fail_disable;
- }
-
/* enable bus mastering on the device */
pci_set_master(dev);
@@ -441,8 +431,6 @@ fail_release_iomem:
igbuio_pci_release_iomem(>info);
if (udev->mode == RTE_INTR_MODE_MSIX)
pci_disable_msix(udev->pdev);
- pci_release_regions(dev);
-fail_disable:
pci_disable_device(dev);
fail_free:
kfree(udev);
@@ -460,7 +448,6 @@ igbuio_pci_remove(struct pci_dev *dev)
igbuio_pci_release_iomem(>info);
if (udev->mode == RTE_INTR_MODE_MSIX)
pci_disable_msix(dev);
- pci_release_regions(dev);
pci_disable_device(dev);
pci_set_drvdata(dev, NULL);
kfree(udev);
--
2.7.4
[dpdk-dev] [PATCH] ethdev: fix extended statistics description
> > The old structure rte_eth_xstats contained names and values.
> > The new structure rte_eth_xstat contains ids and values.
> >
> > Fixes: bd6aa172cf35 ("ethdev: fetch extended statistics with integer ids")
> > Fixes: e2aae1c1ced9 ("ethdev: remove name from extended statistic fetch")
> >
> > Signed-off-by: Thomas Monjalon
>
> Acked-by: Remy Horton
Applied
[dpdk-dev] [PATCH] scripts: check fixed commit branch
2016-06-29 16:47, Thomas Monjalon: > The commit id of a fixed commit must be in the current branch. > It avoids referencing a local branch or a next-* branch when > pushing in the master. > > Signed-off-by: Thomas Monjalon Applied
[dpdk-dev] [PATCH] scripts: test clean build when config have changed
2016-06-30 13:45, Thomas Monjalon: > If there is a change in the config directory the build test > will refresh the tested build config to take into account new options. > The git working directory and the last git commit are checked for a > change in config/. > > Signed-off-by: Thomas Monjalon Applied
[dpdk-dev] [PATCH v1] eal: remove redundant id field in xstats name lookups
2016-07-01 14:16, Remy Horton: > For all drivers that currently implement xstats, the id field in the > rte_eth_stats_name structure equals the entry's array index. This > patch eliminates the redundant id field as a direct index lookup is > faster than a search for the matching id field. > > Signed-off-by: Remy Horton Suggested-by: Olivier Matz Applied, thanks
[dpdk-dev] [PATCH] app/testpmd: add timer based fwd Rx queue flushing
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Reshma Pattan
> Sent: Friday, July 01, 2016 11:28 AM
> To: dev at dpdk.org
> Cc: Pattan, Reshma
> Subject: [dpdk-dev] [PATCH] app/testpmd: add timer based fwd Rx queue
> flushing
>
> Testpmd can stuck inside do while loop of the flush_fwd_rx_queues()
> function. As non-zero packets are returned always by rte_eth_rx_burst()
> function when compiled with no optimizations and if input line rate is
> high. "do while" loop must exit at one stage to proceed further to
> enable packet forwarding and forward the packets. So timer is set to
> exit the do while loop after 1 second.
>
> Fixes: af75078f ("first public release")
>
> Signed-off-by: Reshma Pattan
Acked-by: Pablo de Lara
[dpdk-dev] [PATCH v2] igb_uio: fix possible mmap failure for Linux > v4.3
Hi Ferruh,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, July 01, 2016 4:08 PM
> To: dev at dpdk.org
> Cc: Stephen Hemminger
> Subject: [dpdk-dev] [PATCH v2] igb_uio: fix possible mmap failure for Linux >
> v4.3
>
> mmap the iomem range of the PCI device fails for kernels that
> enabled CONFIG_IO_STRICT_DEVMEM option:
>
> EAL: pci_map_resource():
> cannot mmap(39, 0x7f1c5180, 0x10, 0x0):
> Invalid argument (0x)
>
> CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.4 and not enabled
> by default:
This was introduced in kernel 4.5 (change the title as well ;))
> Linux commit: 90a545e restrict /dev/mem to idle io memory ranges
>
> As a workaround igb_uio can stop reserving PCI memory resources, from
> kernel point of view iomem region looks like idle and mmap works
> again. This matches uio_pci_generic usage.
>
> With this update device iomem range is not protected against any
> other kernel drivers or userspace access. But this shouldn't
> be a problem for dpdk usage module since purpose of the igb_uio
> module is to provide userspace access.
>
> Fixes: af75078fece3 ("first public release")
> Signed-off-by: Ferruh Yigit
[dpdk-dev] [PATCH] igb_uio: fix mmap failure
On 7/1/2016 1:47 PM, Thomas Monjalon wrote: > Thank you Ferruh for taking care of igb_uio. > > 2016-07-01 12:35, Ferruh Yigit: >> With kernels enabled CONFIG_IO_STRICT_DEVMEM option mmap the iomem area >> to userspace fails: > > Maybe some words are missing. > Please check punctuation of the whole commit message to make it easier > to understand. I will re-word. > >> EAL: pci_map_resource(): >> cannot mmap(39, 0x7f1c5180, 0x10, 0x0): >> Invalid argument (0x) >> >> As a workaround igb_uio can stop reserving PCI memory resources, from >> kernel point of view io-memory region looks like idle and mmap works >> again. >> >> With this update device io-memory range is not protected against any >> other kernel driver claim ownership on those resources, which shouldn't >> be a problem for dpdk usage module. > > Why it should not be a problem? request_mem_region() is a way for driver informing the rest of the kernel that memory region is used. And with CONFIG_IO_STRICT_DEVMEM=y, userspace also prevented to touch that ares. But for igb_uio, we explicitly want userspace to access that memory range. > Please could you give an example of what could happen? Technically device lost a protection of its memory region against any other driver, but I am not sure if this is real threat in practical life. Also this is same in uio_pci_generic, it doesn't reserve the memory. > > This patch fixes a problem with recent kernels (not mentioned above) > which offer the uio_pci_generic alternative. Will give kernel version information. > That's why I think we should fix it only if there is absolutely no > regression for older kernels. > Totally agreed, that is why I expressed my concern, let this patch hang around a little.
[dpdk-dev] [PATCH v4 2/2] mk: fix acl library static linking
Since below commit, ACL library is outside the scope of --whole-archive
and ACL autotest fails.
RTE>>acl_autotest
ACL: allocation of 25166728 bytes on socket 9 for ACL_acl_ctx failed
ACL: rte_acl_add_rules(acl_ctx): rule #1 is invalid
Line 1584: SSE classify with zero categories failed!
Test Failed
This is the result of the linker picking weak over non-weak functions.
Fixes: 95dc3c3cf31c ("mk: reduce scope of whole-archive static linking")
Signed-off-by: Sergio Gonzalez Monroy
---
v4:
- keep order of acl in _LDLIBS and wrap it with --whole-archive
v3:
- patch version history
- carry Acked-by
v2:
- add comment in makefile
mk/rte.app.mk | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index bf8bcf9..ea22961 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -76,7 +76,10 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG)+= -lrte_ip_frag
_LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lrte_meter
_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrte_sched
_LDLIBS-$(CONFIG_RTE_LIBRTE_LPM)+= -lrte_lpm
+# librte_acl needs --whole-archive because of weak functions
+_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= --whole-archive
_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl
+_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= --no-whole-archive
_LDLIBS-$(CONFIG_RTE_LIBRTE_JOBSTATS) += -lrte_jobstats
_LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power
--
2.4.11
[dpdk-dev] [PATCH v4 1/2] mk: allow duplicate linker flags in libraries list
Since [1] duplicates in LDLIBS are removed. The side effect is that it
does not distinguish between libraries or linker flags.
This patch allows multiple linker flags in LDLIBS, such as
--whole-archive.
[1] Commit: edf4d331dcdb ("mk: eliminate duplicates from libraries list")
Signed-off-by: Sergio Gonzalez Monroy
---
mk/rte.app.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 83314ca..bf8bcf9 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -166,7 +166,8 @@ LDLIBS += $(_LDLIBS-y) $(CPU_LDLIBS) $(EXTRA_LDLIBS)
# Eliminate duplicates without sorting
LDLIBS := $(shell echo $(LDLIBS) | \
- awk '{for (i = 1; i <= NF; i++) { if (!seen[$$i]++) print $$i }}')
+ awk '{for (i = 1; i <= NF; i++) { \
+ if ($$i !~ /^-l.*/ || !seen[$$i]++) print $$i }}')
ifeq ($(RTE_DEVEL_BUILD)$(CONFIG_RTE_BUILD_SHARED_LIB),yy)
LDFLAGS += -rpath=$(RTE_SDK_BIN)/lib
--
2.4.11
[dpdk-dev] [PATCH] vhost: fix segfault on bad descriptor address.
Hi, Sorry for the long delay. On Fri, May 20, 2016 at 03:50:04PM +0300, Ilya Maximets wrote: > In current implementation guest application can reinitialize vrings > by executing start after stop. In the same time host application > can still poll virtqueue while device stopped in guest and it will > crash with segmentation fault while vring reinitialization because > of dereferencing of bad descriptor addresses. Yes, you are right that vring will be reinitialized after restart. But even though, I don't see the reason it will cause a vhost crash, since the reinitialization will reset all the vring memeory by 0: memset(vq->vq_ring_virt_mem, 0, vq->vq_ring_size); That means those bad descriptors will be skipped, safely, at vhost side by: if (unlikely(desc->len < dev->vhost_hlen)) return -1; > > OVS crash for example: > <> > [test-pmd inside guest VM] > > testpmd> port stop all > Stopping ports... > Checking link statuses... > Port 0 Link Up - speed 1 Mbps - full-duplex > Done > testpmd> port config all rxq 2 > testpmd> port config all txq 2 > testpmd> port start all > Configuring Port 0 (socket 0) > Port 0: 52:54:00:CB:44:C8 > Checking link statuses... > Port 0 Link Up - speed 1 Mbps - full-duplex > Done > > [OVS on host] > Program received signal SIGSEGV, Segmentation fault. > rte_memcpy (n=2056, src=0xc, dst=0x7ff4d5247000) at rte_memcpy.h Interesting, so it bypasses the above check since desc->len is non-zero while desc->addr is zero. The size (2056) also looks weird. Do you mind to check this issue a bit deeper, say why desc->addr is zero, however, desc->len is not? > (gdb) bt > #0 rte_memcpy (n=2056, src=0xc, dst=0x7ff4d5247000) > #1 copy_desc_to_mbuf > #2 rte_vhost_dequeue_burst > #3 netdev_dpdk_vhost_rxq_recv > ... > > (gdb) bt full > #0 rte_memcpy > ... > #1 copy_desc_to_mbuf > desc_addr = 0 > mbuf_offset = 0 > desc_offset = 12 > ... > <> > > Fix that by checking addresses of descriptors before using them. > > Note: For mergeable buffers this patch checks only guest's address for > zero, but in non-meargeable case host's address checked. This is done > because checking of host's address in mergeable case requires additional > refactoring to keep virtqueue in consistent state in case of error. > > Signed-off-by: Ilya Maximets > --- > > Actually, current virtio implementation looks broken for me. Because > 'virtio_dev_start' breaks virtqueue while it still available from the vhost > side. Yes, this sounds buggy. Maybe we could not reset the avail idx, in such case vhost dequeue/enqueue will just return as there are no more packets to dequeue and no more space to enqueue, respectively? --yliu
[dpdk-dev] [PATCH] doc: update release notes
add release note for live migration of a VM with SRIOV VF Signed-off-by: Bernard Iremonger --- doc/guides/rel_notes/release_16_07.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/guides/rel_notes/release_16_07.rst b/doc/guides/rel_notes/release_16_07.rst index 569f562..350b259 100644 --- a/doc/guides/rel_notes/release_16_07.rst +++ b/doc/guides/rel_notes/release_16_07.rst @@ -179,6 +179,9 @@ New Features For information on this feature, please see the "I40E Poll Mode Driver" section of the "Network Interface Controller Drivers" document. +* **Added support for live migration of a VM with SRIOV VF.** + + Live migration of a VM with Virtio and VF PMD's using the bonding PMD. Resolved Issues --- -- 2.6.3
[dpdk-dev] e1000: unused variable warnings with clang
Update: I pulled a new clone and now I do not see that problem, so please ignore. Regards, Keith
[dpdk-dev] [PATCH] igb_uio: fix mmap failure
Thank you Ferruh for taking care of igb_uio. 2016-07-01 12:35, Ferruh Yigit: > With kernels enabled CONFIG_IO_STRICT_DEVMEM option mmap the iomem area > to userspace fails: Maybe some words are missing. Please check punctuation of the whole commit message to make it easier to understand. > EAL: pci_map_resource(): > cannot mmap(39, 0x7f1c5180, 0x10, 0x0): > Invalid argument (0x) > > As a workaround igb_uio can stop reserving PCI memory resources, from > kernel point of view io-memory region looks like idle and mmap works > again. > > With this update device io-memory range is not protected against any > other kernel driver claim ownership on those resources, which shouldn't > be a problem for dpdk usage module. Why it should not be a problem? Please could you give an example of what could happen? This patch fixes a problem with recent kernels (not mentioned above) which offer the uio_pci_generic alternative. That's why I think we should fix it only if there is absolutely no regression for older kernels.
[dpdk-dev] e1000: unused variable warnings with clang
I am seeing unused variable warnings/errors when building the current repo with the clang compiler builds in the e1000/base directory. Does anyone else see this problem? Regards, Keith
[dpdk-dev] [PATCH v1] eal: remove redundant id field in xstats name lookups
For all drivers that currently implement xstats, the id field in the
rte_eth_stats_name structure equals the entry's array index. This
patch eliminates the redundant id field as a direct index lookup is
faster than a search for the matching id field.
Signed-off-by: Remy Horton
---
app/proc_info/main.c| 11 +++
app/test-pmd/config.c | 12
doc/guides/prog_guide/poll_mode_drv.rst | 18 +++---
drivers/net/e1000/igb_ethdev.c | 2 --
drivers/net/fm10k/fm10k_ethdev.c| 3 ---
drivers/net/i40e/i40e_ethdev.c | 8
drivers/net/i40e/i40e_ethdev_vf.c | 1 -
drivers/net/ixgbe/ixgbe_ethdev.c| 7 ---
drivers/net/virtio/virtio_ethdev.c | 4
lib/librte_ether/rte_ethdev.c | 3 ---
lib/librte_ether/rte_ethdev.h | 1 -
11 files changed, 14 insertions(+), 56 deletions(-)
diff --git a/app/proc_info/main.c b/app/proc_info/main.c
index f2063fa..6dc0bbb 100644
--- a/app/proc_info/main.c
+++ b/app/proc_info/main.c
@@ -246,7 +246,6 @@ nic_xstats_display(uint8_t port_id)
struct rte_eth_xstat_name *xstats_names;
struct rte_eth_xstat *xstats;
int len, ret, i;
- int idx_name;
static const char *nic_stats_border = "";
len = rte_eth_xstats_get_names(port_id, NULL, 0);
@@ -284,13 +283,9 @@ nic_xstats_display(uint8_t port_id)
}
for (i = 0; i < len; i++)
- for (idx_name = 0; idx_name < len; idx_name++)
- if (xstats_names[idx_name].id == xstats[i].id) {
- printf("%s: %"PRIu64"\n",
- xstats_names[idx_name].name,
- xstats[i].value);
- break;
- }
+ printf("%s: %"PRIu64"\n",
+ xstats_names[i].name,
+ xstats[i].value);
printf("%s\n",
nic_stats_border);
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 10f0a36..89e3f66e 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -256,7 +256,7 @@ void
nic_xstats_display(portid_t port_id)
{
struct rte_eth_xstat *xstats;
- int cnt_xstats, idx_xstat, idx_name;
+ int cnt_xstats, idx_xstat;
struct rte_eth_xstat_name *xstats_names;
printf("## NIC extended statistics for port %-2d\n", port_id);
@@ -298,13 +298,9 @@ nic_xstats_display(portid_t port_id)
/* Display xstats */
for (idx_xstat = 0; idx_xstat < cnt_xstats; idx_xstat++)
- for (idx_name = 0; idx_name < cnt_xstats; idx_name++)
- if (xstats_names[idx_name].id == xstats[idx_xstat].id) {
- printf("%s: %"PRIu64"\n",
- xstats_names[idx_name].name,
- xstats[idx_xstat].value);
- break;
- }
+ printf("%s: %"PRIu64"\n",
+ xstats_names[idx_xstat].name,
+ xstats[idx_xstat].value);
free(xstats_names);
free(xstats);
}
diff --git a/doc/guides/prog_guide/poll_mode_drv.rst
b/doc/guides/prog_guide/poll_mode_drv.rst
index 802fb8f..bf3ea9f 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
@@ -309,17 +309,13 @@ functions:
information.
Each ``struct rte_eth_xstat`` contains an identifier and value pair, and
-each ``struct rte_eth_xstat_name`` contains an identifier and string pair.
-Each identifier within ``struct rte_eth_xstat`` must have a corresponding
-entry in ``struct rte_eth_xstat_name`` with a matching identifier. These
-identifiers, as well as the number of extended statistic exposed, must
-remain constant during runtime.
-
-Note that extended statistic identifiers are driver-specific, and hence
-might not be the same for different ports. Although it is expected that
-drivers will make the identifiers used within ``struct rte_eth_xstat`` and
-``struct rte_eth_xstat_name`` entries match the entries' array index, this
-property should not be relied on by applications for lookups.
+each ``struct rte_eth_xstat_name`` contains a string. Each identifier
+within the ``struct rte_eth_xstat`` lookup array must have a corresponding
+entry in the ``struct rte_eth_xstat_name`` lookup array. Within the latter
+the index of the entry is the identifier the string is associated with.
+These identifiers, as well as the number of extended statistic exposed, must
+remain constant during runtime. Note that extended statistic identifiers are
+driver-specific, and hence might not be the same for different ports.
A naming scheme exists for the strings exposed to clients of the API. This is
to allow scraping of the API for
[dpdk-dev] [PATCH] ethdev: fix extended statistics description
On 29/06/2016 17:59, Thomas Monjalon wrote:
> The old structure rte_eth_xstats contained names and values.
> The new structure rte_eth_xstat contains ids and values.
>
> Fixes: bd6aa172cf35 ("ethdev: fetch extended statistics with integer ids")
> Fixes: e2aae1c1ced9 ("ethdev: remove name from extended statistic fetch")
>
> Signed-off-by: Thomas Monjalon
Acked-by: Remy Horton
[dpdk-dev] DMA from a NIC to memory on a PCIe device.
Hi,
I am trying to dma packets from NIC to memory on a PCIE device (not buffers
on hugepage.) Memory of the device is mapped to the physical memory via PCI
BAR.
I created a kernel module allocating/freeing memory on the device, and
applications can interact with the module via IOCTL so that apps can
allocate memory on the device and know virtual and physical address of
allocated memory. In DPDK, each mbuf contains its physical
address(buf_physaddr), which will eventually be used for dma address by a
dma engine of a NIC.
My idea is to simply replace this physical address given by a mem pool
(e.g., rte_pktmbuf_pool_create) with that from my Kernel module. This will
look like
/* allocate memory on a pci device and return its Physical address */
pci_physical_addr = myDeviceMemAlloc(...);
/* create mbuf_pool */
mbuf_pool = rte_pktmbuf_pool_create("MBUF_POOL",...);
/* retrieve mbufs to replace their physical address */
rte_mempool_get_bulk(mbuf_pool, mbufs, counts );
/* replacing the physical address */
for_each (mbuf) { mbuf[n]->buf_physaddr = pci_physical_addr + offset[n]; }
/* put all mbufs with a new physical address back to mbuf_pool */
rte_mempool_put_bulk(mbuf_pool, mbufs, counts);
/* port init and start port. This is the same as port_init in basicfwd.c */
Since rte_eth_rx_burst in dpdk doesn't help the application receive the
packets, I wrote a function to read them from the device memory.
But unfortunately, my idea seems not to work as I intended. If I
misunderstand anything in dpdk, especially DMA, please inform me. In
addition, if this idea doesn't work, please let me know how I can dma
packets from NIC to memory in a PCIe device without intervention of host
memory.
Thank you,
Minsung
--
Minsung Jang
[dpdk-dev] [PATCH] Fix misleading indentation in ethtool
On 7/1/2016 12:29 PM, De Lara Guarch, Pablo wrote: > Hi Pengyu, > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pengyu Ma >> Sent: Friday, July 01, 2016 9:53 AM >> To: thomas.monjalon at 6wind.com; dev at dpdk.org >> Subject: [dpdk-dev] [PATCH] Fix misleading indentation in ethtool > > You need to add the library that you are fixing in the title: > i.e. kni: fix misleading identation in ethtool > > >> >> gcc complains about: >> build/lib/librte_eal/linuxapp/kni/e1000_phy.c:3303:2: >> error: this 'if' clause does not guard... [-Werror=misleading-indentation] > > Could you tell me which gcc version you are using? > >> >> Code indentation is misleadingly indented as whether >> the following content is guarded by if or not. >> With the reference of the context, add the curly braces. >> >> Remove unused const variables too. > > You are fixing part of a library, so you should add a fixes line here. > Please refer to the following document to know how to do it: > http://dpdk.readthedocs.io/en/v16.04/contributing/patches.html > >> >> Signed-off-by: Pengyu Ma >> --- >> lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c | 9 ++--- >> lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c | 8 +--- Also these files fixed with following commit: "cba50f6 kni: fix build with gcc 6" Thank you for the patch, but it seems all issues addressed in this patch already solved in master branch. thanks, ferruh
[dpdk-dev] DPDK for JNI
Hi, Does anyone know DPDK works with JNI? Thanks, Junguk
[dpdk-dev] [PATCH v6 0/2] mempool: add stack mempool handler
> > David Hunt (2) > > mempool: add stack (lifo) mempool handler > > test: migrate custom handler test to stack handler > > Acked-by: Olivier Matz Applied, thanks
[dpdk-dev] [PATCH v2] mk: fix acl library static linking
2016-07-01 11:27, Sergio Gonzalez Monroy: > On 01/07/2016 11:05, Thomas Monjalon wrote: > > 2016-07-01 09:05, Sergio Gonzalez Monroy: > >> On 30/06/2016 17:22, Thomas Monjalon wrote: > >>> 2016-06-30 17:14, Sergio Gonzalez Monroy: > On 30/06/2016 17:10, Thomas Monjalon wrote: > > 2016-06-30 17:01, Sergio Gonzalez Monroy: > >> --- a/mk/rte.app.mk > >> +++ b/mk/rte.app.mk > >> @@ -76,12 +76,13 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG)+= > >> -lrte_ip_frag > >> _LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lrte_meter > >> _LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrte_sched > >> _LDLIBS-$(CONFIG_RTE_LIBRTE_LPM)+= -lrte_lpm > >> -_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl > >> _LDLIBS-$(CONFIG_RTE_LIBRTE_JOBSTATS) += -lrte_jobstats > >> _LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power > >> > >> _LDLIBS-y += --whole-archive > >> > >> +# librte_acl needs --whole-archive because of weak functions > >> +_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl > >> _LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER) += -lrte_timer > >> _LDLIBS-$(CONFIG_RTE_LIBRTE_HASH) += -lrte_hash > >> _LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost > > I was suggesting to keep -lrte_acl at the same place in the group of > > algorithms libraries, in order to keep an order satisfying this comment: > > # Order is important: from higher level to lower level > > > > But I have not tested if --whole-archive -lrte_acl --no-whole-archive > > works. > > > Sorry, I missed that. > > Why is important being before jobstats and power? > >>> It is not. > >>> But I think we need to have some groups. > >>> And ACL is probably at the same layer level as lpm, sched, etc. > >> I guess I just don't see the groups you are mentioning :) > > I define groups as separated by blank line :) > > > >> How are timer, hash and vhost in the same group? > > It is far from perfect and subject to improvements :) > > > >> Wouldn't hash be in the same group as acl and lpm? > > It makes sense to use hash in drivers (example: enic). > > You have not convinced me, but I'm not going to argue more over this. But you have convinced me (I was already convinced) that more cleanups and explanations are needed in this area :) > You would just prefer to do the following, right? > > +_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= --whole-archive > _LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl > +_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= --no-whole-archive Yes for this fix. Later we can improve few things, thanks.
[dpdk-dev] [PATCH] igb_uio: fix mmap failure
With kernels enabled CONFIG_IO_STRICT_DEVMEM option mmap the iomem area
to userspace fails:
EAL: pci_map_resource():
cannot mmap(39, 0x7f1c5180, 0x10, 0x0):
Invalid argument (0x)
As a workaround igb_uio can stop reserving PCI memory resources, from
kernel point of view io-memory region looks like idle and mmap works
again.
With this update device io-memory range is not protected against any
other kernel driver claim ownership on those resources, which shouldn't
be a problem for dpdk usage module.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Ferruh Yigit
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 45a5720..df41e45 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -342,16 +342,6 @@ igbuio_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
goto fail_free;
}
- /*
-* reserve device's PCI memory regions for use by this
-* module
-*/
- err = pci_request_regions(dev, "igb_uio");
- if (err != 0) {
- dev_err(>dev, "Cannot request regions\n");
- goto fail_disable;
- }
-
/* enable bus mastering on the device */
pci_set_master(dev);
@@ -441,8 +431,6 @@ fail_release_iomem:
igbuio_pci_release_iomem(>info);
if (udev->mode == RTE_INTR_MODE_MSIX)
pci_disable_msix(udev->pdev);
- pci_release_regions(dev);
-fail_disable:
pci_disable_device(dev);
fail_free:
kfree(udev);
@@ -460,7 +448,6 @@ igbuio_pci_remove(struct pci_dev *dev)
igbuio_pci_release_iomem(>info);
if (udev->mode == RTE_INTR_MODE_MSIX)
pci_disable_msix(dev);
- pci_release_regions(dev);
pci_disable_device(dev);
pci_set_drvdata(dev, NULL);
kfree(udev);
--
2.7.4
[dpdk-dev] [PATCH v3] mempool: rename functions with confusing names
2016-07-01 10:57, Olivier MATZ: > > On 06/30/2016 10:05 PM, Thomas Monjalon wrote: > > 2016-06-30 13:49, Bruce Richardson: > >> The mempool_count and mempool_free_count behaved contrary to what their > >> names suggested. The free_count function actually returned the number of > >> elements that were allocated from the pool, not the number unallocated as > >> the name implied. > >> > >> Fix this by introducing two new functions to replace the old ones, > >> * rte_mempool_avail_count to replace rte_mempool_count > >> * rte_mempool_in_use_count to replace rte_mempool_free_count > >> > >> In this patch, the new functions are added, and the old ones are marked > >> as deprecated. All apps and examples that use the old functions are > >> updated to use the new functions. > > > > The ThunderX driver uses rte_mempool_count and needs an update. > > Except that, it looks good. > > > > Yep, I don't see any other issue. Applied with ThunderX update, thanks
[dpdk-dev] [PATCH v2] mk: fix acl library static linking
2016-07-01 09:05, Sergio Gonzalez Monroy: > On 30/06/2016 17:22, Thomas Monjalon wrote: > > 2016-06-30 17:14, Sergio Gonzalez Monroy: > >> On 30/06/2016 17:10, Thomas Monjalon wrote: > >>> 2016-06-30 17:01, Sergio Gonzalez Monroy: > --- a/mk/rte.app.mk > +++ b/mk/rte.app.mk > @@ -76,12 +76,13 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG)+= > -lrte_ip_frag > _LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lrte_meter > _LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrte_sched > _LDLIBS-$(CONFIG_RTE_LIBRTE_LPM)+= -lrte_lpm > -_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl > _LDLIBS-$(CONFIG_RTE_LIBRTE_JOBSTATS) += -lrte_jobstats > _LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power > > _LDLIBS-y += --whole-archive > > +# librte_acl needs --whole-archive because of weak functions > +_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl > _LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER) += -lrte_timer > _LDLIBS-$(CONFIG_RTE_LIBRTE_HASH) += -lrte_hash > _LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost > >>> I was suggesting to keep -lrte_acl at the same place in the group of > >>> algorithms libraries, in order to keep an order satisfying this comment: > >>> # Order is important: from higher level to lower level > >>> > >>> But I have not tested if --whole-archive -lrte_acl --no-whole-archive > >>> works. > >>> > >> Sorry, I missed that. > >> > >> Why is important being before jobstats and power? > > It is not. > > But I think we need to have some groups. > > And ACL is probably at the same layer level as lpm, sched, etc. > > I guess I just don't see the groups you are mentioning :) I define groups as separated by blank line :) > How are timer, hash and vhost in the same group? It is far from perfect and subject to improvements :) > Wouldn't hash be in the same group as acl and lpm? It makes sense to use hash in drivers (example: enic).
[dpdk-dev] Issue with igb_uio in Fedora 24
On 7/1/2016 11:21 AM, Mcnamara, John wrote: > Hi, > > We have seen an issue when using the igb_uio module in Fedora > 24. However, it relates to kernel 4.5+ so it could occur in other > distros/oses. > > The issue occurs after binding a nic to igb_uio: > > # ./tools/dpdk_nic_bind.py -b igb_uio :03:00.0 > # ./x86_64-native-linuxapp-gcc/app/test > > EAL: Detected 8 lcore(s) > EAL: Probing VFIO support... > PMD: bnxt_rte_pmd_init() called for (null) > EAL: PCI device :03:00.0 on NUMA socket -1 > EAL: probe driver: 8086:1533 rte_igb_pmd > EAL: pci_map_resource(): > cannot mmap(39, 0x7f1c5180, 0x10, 0x0): > Invalid argument (0x) > EAL: Error - exiting with code: 1 > Cause: Requested device :03:00.0 cannot be used > > The issue is exposed when the kernel is compiled with option > CONFIG_IO_STRICT_DEVMEM turned on. > > This option is new from kernel 4.5 and is on by default in Fedora 24: > > config IO_STRICT_DEVMEM > bool "Filter I/O access to /dev/mem" > depends on STRICT_DEVMEM > ---help--- > > If this option is disabled, you allow userspace (root) access > to all io-memory regardless of whether a driver is actively > using that range. Accidental access to this is obviously > disastrous, but specific access can be used by people > debugging kernel drivers. > > If this option is switched on, the /dev/mem file only allows > userspace access to *idle* io-memory ranges (see /proc/iomem) > This may break traditional users of /dev/mem (dosemu, legacy > X, etc...) if the driver using a given range cannot be > disabled. > > If in doubt, say Y. > > This issue doesn't occur with uio_pci_generic. > > John > Thanks for Pablo figuring out the details, and related config option, otherwise I was digging same issue without success. Disabling following code in igb_uio makes it work again: "pci_request_regions(dev, "igb_uio");" This call adds device bars as active resources, and with above config option mmap fails for those addresses. uio_pci_generic already doesn't have this call, and I can send a patch to remove this from igb_uio. BUT, I don't know why that call added at first place and concerned about any corner case that requires this call. Anybody out has/knows a reason to keep this call? Thanks, ferruh
[dpdk-dev] [PATCH 0/2] doc: live migration procedure
This pachset set describes the procedure to Live migrate a VM with Virtio and VF PMD's using the bonding PMD. Bernard Iremonger (2): doc: live migration of VM with Virtio and VF doc: add live migration overview image doc/guides/how_to/img/lm_overview.svg | 666 doc/guides/how_to/index.rst| 38 ++ doc/guides/how_to/lm_bond_virtio_sriov.rst | 690 + doc/guides/index.rst | 3 +- 4 files changed, 1396 insertions(+), 1 deletion(-) create mode 100644 doc/guides/how_to/img/lm_overview.svg create mode 100644 doc/guides/how_to/index.rst create mode 100644 doc/guides/how_to/lm_bond_virtio_sriov.rst -- 2.6.3
[dpdk-dev] [PATCH 2/2] doc: add live migration overview image
This patch adds an image of the Live Migration test configuration. Signed-off-by: Bernard Iremonger --- doc/guides/how_to/img/lm_overview.svg | 666 + doc/guides/how_to/lm_bond_virtio_sriov.rst | 3 + 2 files changed, 669 insertions(+) create mode 100644 doc/guides/how_to/img/lm_overview.svg diff --git a/doc/guides/how_to/img/lm_overview.svg b/doc/guides/how_to/img/lm_overview.svg new file mode 100644 index 000..d913ae0 --- /dev/null +++ b/doc/guides/how_to/img/lm_overview.svg @@ -0,0 +1,666 @@ + + + +http://purl.org/dc/elements/1.1/; + xmlns:cc="http://creativecommons.org/ns#; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#; + xmlns:svg="http://www.w3.org/2000/svg; + xmlns="http://www.w3.org/2000/svg; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape; + width="1052.8693" + height="762.99158" + id="svg2" + version="1.1" + inkscape:version="0.48.4 r9939" + sodipodi:docname="lm_overview.svg"> + + + + + + + + + + + + + + + + + + + + + + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage; /> + + + + + + + + + + + + + +VM 1 +Switch with 10Gb ports +Server 1 +Server 2 + 10 Gb Traffic Generator +VM 2 +Linux, KVM, QEMU +Linux, KVM, QEMU +10 Gb NIC +10 Gb NIC + + +10 Gb NIC +10 Gb NIC + +DPDK Testpmd App. +bonded device withvirtio and VF slaves + +DPDK Testpmd App. +bonded device withvirtio and VF slaves +Kernel PF driver +Kernel PF driver +SW bridge with Tapand PF connected +NFS ServerVM disk image + + + + + + + + + + + + + + + +SW bridge with Tapand PF connected +10 Gb Migration Link + + diff --git a/doc/guides/how_to/lm_bond_virtio_sriov.rst b/doc/guides/how_to/lm_bond_virtio_sriov.rst index 95d5523..39ada36 100644 --- a/doc/guides/how_to/lm_bond_virtio_sriov.rst +++ b/doc/guides/how_to/lm_bond_virtio_sriov.rst @@ -57,6 +57,9 @@ The switch is configured to broadcast traffic on all the NIC ports. Live Migration with SR-IOV VF test setup: - +.. _figure_lm_overview: + +.. figure:: img/lm_overview.* Live Migration steps for VM with Virtio and VF PMD's: - -- 2.6.3
[dpdk-dev] [PATCH 1/2] doc: live migration of VM with Virtio and VF
This patch describes the procedure to be be followed to perform Live Migration of a VM with Virtio and VF PMD's using the bonding PMD. It includes sample host and VM scripts used in the procedure, and a sample switch configuration. Signed-off-by: Bernard Iremonger --- doc/guides/how_to/index.rst| 38 ++ doc/guides/how_to/lm_bond_virtio_sriov.rst | 687 + doc/guides/index.rst | 3 +- 3 files changed, 727 insertions(+), 1 deletion(-) create mode 100644 doc/guides/how_to/index.rst create mode 100644 doc/guides/how_to/lm_bond_virtio_sriov.rst diff --git a/doc/guides/how_to/index.rst b/doc/guides/how_to/index.rst new file mode 100644 index 000..4b97a32 --- /dev/null +++ b/doc/guides/how_to/index.rst @@ -0,0 +1,38 @@ +.. BSD LICENSE +Copyright(c) 2016 Intel Corporation. All rights reserved. +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. + +How To User Guide += + +.. toctree:: +:maxdepth: 3 +:numbered: + +lm_bond_virtio_sriov diff --git a/doc/guides/how_to/lm_bond_virtio_sriov.rst b/doc/guides/how_to/lm_bond_virtio_sriov.rst new file mode 100644 index 000..95d5523 --- /dev/null +++ b/doc/guides/how_to/lm_bond_virtio_sriov.rst @@ -0,0 +1,687 @@ +.. BSD LICENSE +Copyright(c) 2016 Intel Corporation. All rights reserved. +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. + + +Live Migration of VM with SR-IOV VF: + + +Live Migration overview for VM with Virtio and VF PMD's: + + +It is not possible to migrate a Virtual Machine which has an SR-IOV Virtual Function. +To get around this problem the bonding PMD is used. + +A bonded device is created in the VM. +The virtio and VF PMD's are added as slaves to the bonded device. +The VF is set as the primary slave of the bonded device. + +A bridge must be set up on the Host connecting the tap
[dpdk-dev] [PATCH] Fix misleading indentation in ethtool
Hi Pengyu,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pengyu Ma
> Sent: Friday, July 01, 2016 9:53 AM
> To: thomas.monjalon at 6wind.com; dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] Fix misleading indentation in ethtool
You need to add the library that you are fixing in the title:
i.e. kni: fix misleading identation in ethtool
>
> gcc complains about:
> build/lib/librte_eal/linuxapp/kni/e1000_phy.c:3303:2:
> error: this 'if' clause does not guard... [-Werror=misleading-indentation]
Could you tell me which gcc version you are using?
>
> Code indentation is misleadingly indented as whether
> the following content is guarded by if or not.
> With the reference of the context, add the curly braces.
>
> Remove unused const variables too.
You are fixing part of a library, so you should add a fixes line here.
Please refer to the following document to know how to do it:
http://dpdk.readthedocs.io/en/v16.04/contributing/patches.html
>
> Signed-off-by: Pengyu Ma
> ---
> lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c | 9 ++---
> lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c | 8 +---
> lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c | 5 +
> 3 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c
> b/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c
> index df22470..120e57b 100644
> --- a/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c
> +++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c
> @@ -3300,12 +3300,13 @@ s32 e1000_read_phy_reg_mphy(struct e1000_hw
> *hw, u32 address, u32 *data)
> *data = E1000_READ_REG(hw, E1000_MPHY_DATA);
>
> /* Disable access to mPHY if it was originally disabled */
> - if (locked)
> + if (locked) {
> ready = e1000_is_mphy_ready(hw);
> if (!ready)
> return -E1000_ERR_PHY;
> E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
> E1000_MPHY_DIS_ACCESS);
> + }
You are actually fixing the code flow, right?
So, not sure if you should modify the title and body of the patch.
>
> return E1000_SUCCESS;
> }
> @@ -3365,12 +3366,14 @@ s32 e1000_write_phy_reg_mphy(struct
> e1000_hw *hw, u32 address, u32 data,
> E1000_WRITE_REG(hw, E1000_MPHY_DATA, data);
>
> /* Disable access to mPHY if it was originally disabled */
> - if (locked)
> + if (locked) {
> ready = e1000_is_mphy_ready(hw);
> - if (!ready)
> + if (!ready) {
> return -E1000_ERR_PHY;
> + }
Not needed it, but harmless :)
> E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
> E1000_MPHY_DIS_ACCESS);
> + }
>
> return E1000_SUCCESS;
> }
> diff --git a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c
> b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c
> index 017dfe1..71cbf1a 100644
> --- a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c
> +++ b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c
> @@ -867,14 +867,16 @@ s32 ixgbe_setup_mac_link_82599(struct ixgbe_hw
> *hw,
> link_mode == IXGBE_AUTOC_LMS_KX4_KX_KR_SGMII) {
> /* Set KX4/KX/KR support according to speed requested */
> autoc &= ~(IXGBE_AUTOC_KX4_KX_SUPP_MASK |
> IXGBE_AUTOC_KR_SUPP);
> - if (speed & IXGBE_LINK_SPEED_10GB_FULL)
> + if (speed & IXGBE_LINK_SPEED_10GB_FULL) {
> if (orig_autoc & IXGBE_AUTOC_KX4_SUPP)
> autoc |= IXGBE_AUTOC_KX4_SUPP;
> if ((orig_autoc & IXGBE_AUTOC_KR_SUPP) &&
> - (hw->phy.smart_speed_active == false))
> + (hw->phy.smart_speed_active == false))
> autoc |= IXGBE_AUTOC_KR_SUPP;
> - if (speed & IXGBE_LINK_SPEED_1GB_FULL)
> + }
> + if (speed & IXGBE_LINK_SPEED_1GB_FULL) {
> autoc |= IXGBE_AUTOC_KX_SUPP;
> + }
> } else if ((pma_pmd_1g == IXGBE_AUTOC_1G_SFI) &&
> (link_mode == IXGBE_AUTOC_LMS_1G_LINK_NO_AN ||
> link_mode == IXGBE_AUTOC_LMS_1G_AN)) {
> diff --git a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
> b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
> index 8c1d2fe..1e9f9d1 100644
> --- a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
> +++ b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
> @@ -59,8 +59,11 @@
> #undef CONFIG_DCA_MODULE
>
> char ixgbe_driver_name[] = "ixgbe";
> +/*
> static const char ixgbe_driver_string[] =
> "Intel(R) 10 Gigabit PCI Express Network Driver";
> +*/
This line and the one below that you are commenting out have been removed in
this patch
(http://dpdk.org/dev/patchwork/patch/14276/)
[dpdk-dev] [PATCH] app/testpmd: add timer based fwd Rx queue flushing
Testpmd can stuck inside do while loop of the flush_fwd_rx_queues()
function. As non-zero packets are returned always by rte_eth_rx_burst()
function when compiled with no optimizations and if input line rate is
high. "do while" loop must exit at one stage to proceed further to
enable packet forwarding and forward the packets. So timer is set to
exit the do while loop after 1 second.
Fixes: af75078f ("first public release")
Signed-off-by: Reshma Pattan
---
app/test-pmd/testpmd.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 06885ce..b7f28e9 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -272,6 +272,9 @@ uint32_t bypass_timeout = RTE_BYPASS_TMT_OFF;
#endif
+/* default period is 1 second */
+static uint64_t timer_period = 1;
+
/*
* Ethernet device configuration.
*/
@@ -877,17 +880,35 @@ flush_fwd_rx_queues(void)
uint16_t nb_rx;
uint16_t i;
uint8_t j;
+ uint64_t prev_tsc = 0, diff_tsc, cur_tsc, timer_tsc = 0;
+
+ /* convert to number of cycles */
+ timer_period *= rte_get_timer_hz();
for (j = 0; j < 2; j++) {
for (rxp = 0; rxp < cur_fwd_config.nb_fwd_ports; rxp++) {
for (rxq = 0; rxq < nb_rxq; rxq++) {
port_id = fwd_ports_ids[rxp];
+ /**
+ * testpmd can stuck in the below do while loop
+ * if rte_eth_rx_burst() always returns nonzero
+ * packets. So timer is added to exit this loop
+ * after 1sec timer expiry.
+ */
+ prev_tsc = rte_rdtsc();
do {
nb_rx = rte_eth_rx_burst(port_id, rxq,
pkts_burst, MAX_PKT_BURST);
for (i = 0; i < nb_rx; i++)
rte_pktmbuf_free(pkts_burst[i]);
- } while (nb_rx > 0);
+
+ cur_tsc = rte_rdtsc();
+ diff_tsc = cur_tsc - prev_tsc;
+ timer_tsc += diff_tsc;
+ } while ((nb_rx > 0) &&
+ (timer_tsc < timer_period));
+ prev_tsc = cur_tsc;
+ timer_tsc = 0;
}
}
rte_delay_ms(10); /* wait 10 milli-seconds before retrying */
--
2.5.0
[dpdk-dev] [PATCH v2] mk: fix acl library static linking
On 01/07/2016 11:05, Thomas Monjalon wrote: > 2016-07-01 09:05, Sergio Gonzalez Monroy: >> On 30/06/2016 17:22, Thomas Monjalon wrote: >>> 2016-06-30 17:14, Sergio Gonzalez Monroy: On 30/06/2016 17:10, Thomas Monjalon wrote: > 2016-06-30 17:01, Sergio Gonzalez Monroy: >> --- a/mk/rte.app.mk >> +++ b/mk/rte.app.mk >> @@ -76,12 +76,13 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG)+= >> -lrte_ip_frag >> _LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lrte_meter >> _LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrte_sched >> _LDLIBS-$(CONFIG_RTE_LIBRTE_LPM)+= -lrte_lpm >> -_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl >> _LDLIBS-$(CONFIG_RTE_LIBRTE_JOBSTATS) += -lrte_jobstats >> _LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power >> >> _LDLIBS-y += --whole-archive >> >> +# librte_acl needs --whole-archive because of weak functions >> +_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl >> _LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER) += -lrte_timer >> _LDLIBS-$(CONFIG_RTE_LIBRTE_HASH) += -lrte_hash >> _LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost > I was suggesting to keep -lrte_acl at the same place in the group of > algorithms libraries, in order to keep an order satisfying this comment: > # Order is important: from higher level to lower level > > But I have not tested if --whole-archive -lrte_acl --no-whole-archive > works. > Sorry, I missed that. Why is important being before jobstats and power? >>> It is not. >>> But I think we need to have some groups. >>> And ACL is probably at the same layer level as lpm, sched, etc. >> I guess I just don't see the groups you are mentioning :) > I define groups as separated by blank line :) > >> How are timer, hash and vhost in the same group? > It is far from perfect and subject to improvements :) > >> Wouldn't hash be in the same group as acl and lpm? > It makes sense to use hash in drivers (example: enic). You have not convinced me, but I'm not going to argue more over this. You would just prefer to do the following, right? +_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= --whole-archive _LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl +_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= --no-whole-archive
[dpdk-dev] weak functions in some drivers
On 01/07/2016 11:16, Elo, Matias (Nokia - FI/Espoo) wrote: >> -Original Message- >> From: Sergio Gonzalez Monroy [mailto:sergio.gonzalez.monroy at intel.com] >> Sent: Friday, July 01, 2016 1:05 PM >> To: Elo, Matias (Nokia - FI/Espoo) ; >> dev at dpdk.org >> Cc: ferruh.yigit at intel.com; damarion at cisco.com >> Subject: Re: [dpdk-dev] weak functions in some drivers >> >> On 01/07/2016 10:42, Elo, Matias (Nokia - FI/Espoo) wrote: What is not clear to me is motivation to use weak here instead of simply > using >CONFIG_RTE_I40E_INC_VECTOR macro to exclude stubs in i40e_rxtx.c. It will make library smaller and >> avoid > issues like this one which are quite hard to troubleshoot. >>> Since this issue seen in fd.io, I didn't investigated more, but I don't >>> want to clock your valid question, this is an attempt to resurrect the >>> question ... >> Hi, >> >> We are having exactly the same problem. For us the aforementioned > workaround doesn't seem to work and vector mode is always disabled with >> the > i40e drivers. If I modify i40e_rxtx.c and exclude the stub functions using > CONFIG_RTE_I40E_INC_VECTOR everything works as expected. >> We are building DPDK with the CONFIG_RTE_BUILD_COMBINE_LIBS option > enabled and link DPDK library to our application. >> Any other ideas how this could be fixed? >> >> Regards, >> Matias >> > So you have tried to link a combined static lib with --whole-archive > -ldpdk --no-whole-archive and still get the wrong/weak function > definition? > > Sergio I actually just managed to fix the problem. In our case I had to add '-Wl,--whole-archive,-ldpdk,--no-whole-archive' to the end of AM_LDFLAGS. >>> It turned out that the problem actually wasn't fixed. >>> >>> DPDK is built with CONFIG_RTE_BUILD_COMBINE_LIBS=y and >> EXTRA_CFLAGS="-fPIC" >>> What we are linking originally: >>> -l:libdpdk.a >>> >>> This works otherwise but vector mode i40e is not enabled. >>> >>> When trying: >>> -Wl,--whole-archive,-l:libdpdk.a,--no-whole-archive >>> >>> Linking fails with ' undefined reference' errors to several dpdk functions >> (rte_eal_init, rte_cpu_get_flag_enabled, rte_eth_stats_get...). >>> Btw. there seems to be a Stack Overflow question related to this: >> http://stackoverflow.com/questions/38064021/dpdk-include-libraries-in-dpdk- >> application-compiled-as-shared-library >>> -Matias >> What DPDK version are you using? > v16.04 Ok. I was asking because there is no CONFIG_RTE_BUILD_COMBINE_LIBS in 16.04. Could you provide full link/compile command line? I'm not able to reproduce the issue so far
[dpdk-dev] weak functions in some drivers
On 01/07/2016 10:42, Elo, Matias (Nokia - FI/Espoo) wrote: >> What is not clear to me is motivation to use weak here instead of simply >>> using >CONFIG_RTE_I40E_INC_VECTOR >> macro to exclude stubs in i40e_rxtx.c. It will make library smaller and >> avoid >>> issues like this one >> which are quite hard to troubleshoot. > Since this issue seen in fd.io, I didn't investigated more, but I don't > want to clock your valid question, this is an attempt to resurrect the > question ... Hi, We are having exactly the same problem. For us the aforementioned >>> workaround doesn't seem to work and vector mode is always disabled with the >>> i40e drivers. If I modify i40e_rxtx.c and exclude the stub functions using >>> CONFIG_RTE_I40E_INC_VECTOR everything works as expected. We are building DPDK with the CONFIG_RTE_BUILD_COMBINE_LIBS option >>> enabled and link DPDK library to our application. Any other ideas how this could be fixed? Regards, Matias >>> So you have tried to link a combined static lib with --whole-archive >>> -ldpdk --no-whole-archive and still get the wrong/weak function definition? >>> >>> Sergio >> I actually just managed to fix the problem. In our case I had to add >> '-Wl,--whole-archive,-ldpdk,--no-whole-archive' to the end of AM_LDFLAGS. >> > It turned out that the problem actually wasn't fixed. > > DPDK is built with CONFIG_RTE_BUILD_COMBINE_LIBS=y and EXTRA_CFLAGS="-fPIC" > > What we are linking originally: > -l:libdpdk.a > > This works otherwise but vector mode i40e is not enabled. > > When trying: > -Wl,--whole-archive,-l:libdpdk.a,--no-whole-archive > > Linking fails with ' undefined reference' errors to several dpdk functions > (rte_eal_init, rte_cpu_get_flag_enabled, rte_eth_stats_get...). > > Btw. there seems to be a Stack Overflow question related to this: > http://stackoverflow.com/questions/38064021/dpdk-include-libraries-in-dpdk-application-compiled-as-shared-library > > -Matias What DPDK version are you using?
[dpdk-dev] [PATCH v3] mempool: rename functions with confusing names
On 06/30/2016 10:05 PM, Thomas Monjalon wrote: > 2016-06-30 13:49, Bruce Richardson: >> The mempool_count and mempool_free_count behaved contrary to what their >> names suggested. The free_count function actually returned the number of >> elements that were allocated from the pool, not the number unallocated as >> the name implied. >> >> Fix this by introducing two new functions to replace the old ones, >> * rte_mempool_avail_count to replace rte_mempool_count >> * rte_mempool_in_use_count to replace rte_mempool_free_count >> >> In this patch, the new functions are added, and the old ones are marked >> as deprecated. All apps and examples that use the old functions are >> updated to use the new functions. > > The ThunderX driver uses rte_mempool_count and needs an update. > Except that, it looks good. > Yep, I don't see any other issue.
[dpdk-dev] [PATCH] ethdev: enhance api doc for getting supported packet types
As discussed in http://dpdk.org/ml/archives/dev/2016-June/042229.html, clarify the behavior of rte_eth_dev_get_supported_ptypes(). Signed-off-by: Olivier Matz --- lib/librte_ether/rte_ethdev.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h index ad2f264..bb3dc7a 100644 --- a/lib/librte_ether/rte_ethdev.h +++ b/lib/librte_ether/rte_ethdev.h @@ -2408,6 +2408,21 @@ void rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info); /** * Retrieve the supported packet types of an Ethernet device. * + * When a packet type is announced as supported, it *must* be recognized by + * the PMD. For instance, if RTE_PTYPE_L2_ETHER, RTE_PTYPE_L2_ETHER_VLAN + * and RTE_PTYPE_L3_IPV4 are announced, the PMD must return the following + * packet types for these packets: + * - Ether/IPv4 -> RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 + * - Ether/Vlan/IPv4 -> RTE_PTYPE_L2_ETHER_VLAN | RTE_PTYPE_L3_IPV4 + * - Ether/ -> RTE_PTYPE_L2_ETHER + * - Ether/Vlan/ -> RTE_PTYPE_L2_ETHER_VLAN + * + * When a packet is received by a PMD, the most precise type must be + * returned among the ones supported. However a PMD is allowed to set + * packet type that is not in the supported list, at the condition that it + * is more precise. Therefore, a PMD announcing no supported packet types + * can still set a matching packet type in a received packet. + * * @note * Better to invoke this API after the device is already started or rx burst * function is decided, to obtain correct supported ptypes. -- 2.8.1
[dpdk-dev] Issue with igb_uio in Fedora 24
Hi, We have seen an issue when using the igb_uio module in Fedora 24. However, it relates to kernel 4.5+ so it could occur in other distros/oses. The issue occurs after binding a nic to igb_uio: # ./tools/dpdk_nic_bind.py -b igb_uio :03:00.0 # ./x86_64-native-linuxapp-gcc/app/test EAL: Detected 8 lcore(s) EAL: Probing VFIO support... PMD: bnxt_rte_pmd_init() called for (null) EAL: PCI device :03:00.0 on NUMA socket -1 EAL: probe driver: 8086:1533 rte_igb_pmd EAL: pci_map_resource(): cannot mmap(39, 0x7f1c5180, 0x10, 0x0): Invalid argument (0x) EAL: Error - exiting with code: 1 Cause: Requested device :03:00.0 cannot be used The issue is exposed when the kernel is compiled with option CONFIG_IO_STRICT_DEVMEM turned on. This option is new from kernel 4.5 and is on by default in Fedora 24: config IO_STRICT_DEVMEM bool "Filter I/O access to /dev/mem" depends on STRICT_DEVMEM ---help--- If this option is disabled, you allow userspace (root) access to all io-memory regardless of whether a driver is actively using that range. Accidental access to this is obviously disastrous, but specific access can be used by people debugging kernel drivers. If this option is switched on, the /dev/mem file only allows userspace access to *idle* io-memory ranges (see /proc/iomem) This may break traditional users of /dev/mem (dosemu, legacy X, etc...) if the driver using a given range cannot be disabled. If in doubt, say Y. This issue doesn't occur with uio_pci_generic. John
[dpdk-dev] [PATCH v6 0/2] mempool: add stack mempool handler
Hi Dave, On 07/01/2016 09:46 AM, David Hunt wrote: > This patch set adds a lifo stack handler to the external mempool > manager. > > This patch utilises the mempool handler feature which allows the addition > of new mempool handlers to DPDK. > > v6 changes: > * removed unneeded mp_ext variable. > * added in a free for mp_stack after we're finished with it. > > v5 changes: > * Added the extra parameter requred for the changed test_mempool_basic() > function for user defined caches. > > v4 changes: > * Update the test to replace the custom handler test with the > stack handler test rather than just adding a stack handler test. > The custom handler code is very similar to the stack handler, so > there's no need to have both. > > v3 changes: > * Updated based on the latest version (v15) of the Mempool Handler feature > > v2 changes: > * updated based on mailing list feedback (Thanks Stephen) > * checkpatch fixes. > > David Hunt (2) > mempool: add stack (lifo) mempool handler > test: migrate custom handler test to stack handler > Acked-by: Olivier Matz Thanks!
[dpdk-dev] weak functions in some drivers
> -Original Message- > From: Sergio Gonzalez Monroy [mailto:sergio.gonzalez.monroy at intel.com] > Sent: Friday, July 01, 2016 1:05 PM > To: Elo, Matias (Nokia - FI/Espoo) ; > dev at dpdk.org > Cc: ferruh.yigit at intel.com; damarion at cisco.com > Subject: Re: [dpdk-dev] weak functions in some drivers > > On 01/07/2016 10:42, Elo, Matias (Nokia - FI/Espoo) wrote: > >> What is not clear to me is motivation to use weak here instead of > >> simply > >>> using >CONFIG_RTE_I40E_INC_VECTOR > >> macro to exclude stubs in i40e_rxtx.c. It will make library smaller and > avoid > >>> issues like this one > >> which are quite hard to troubleshoot. > > Since this issue seen in fd.io, I didn't investigated more, but I don't > > want to clock your valid question, this is an attempt to resurrect the > > question ... > Hi, > > We are having exactly the same problem. For us the aforementioned > >>> workaround doesn't seem to work and vector mode is always disabled with > the > >>> i40e drivers. If I modify i40e_rxtx.c and exclude the stub functions using > >>> CONFIG_RTE_I40E_INC_VECTOR everything works as expected. > We are building DPDK with the CONFIG_RTE_BUILD_COMBINE_LIBS option > >>> enabled and link DPDK library to our application. > Any other ideas how this could be fixed? > > Regards, > Matias > > >>> So you have tried to link a combined static lib with --whole-archive > >>> -ldpdk --no-whole-archive and still get the wrong/weak function > >>> definition? > >>> > >>> Sergio > >> I actually just managed to fix the problem. In our case I had to add > >> '-Wl,--whole-archive,-ldpdk,--no-whole-archive' to the end of AM_LDFLAGS. > >> > > It turned out that the problem actually wasn't fixed. > > > > DPDK is built with CONFIG_RTE_BUILD_COMBINE_LIBS=y and > EXTRA_CFLAGS="-fPIC" > > > > What we are linking originally: > > -l:libdpdk.a > > > > This works otherwise but vector mode i40e is not enabled. > > > > When trying: > > -Wl,--whole-archive,-l:libdpdk.a,--no-whole-archive > > > > Linking fails with ' undefined reference' errors to several dpdk functions > (rte_eal_init, rte_cpu_get_flag_enabled, rte_eth_stats_get...). > > > > Btw. there seems to be a Stack Overflow question related to this: > http://stackoverflow.com/questions/38064021/dpdk-include-libraries-in-dpdk- > application-compiled-as-shared-library > > > > -Matias > > What DPDK version are you using? v16.04
[dpdk-dev] [PATCH 1/4] net/virtio-user: fix return value not checked
On Wed, Jun 29, 2016 at 09:05:33AM +, Jianfeng Tan wrote:
> - if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_CQ_NUM) == 1)
> - rte_kvargs_process(kvlist, VIRTIO_USER_ARG_CQ_NUM,
> -_integer_arg, );
> + if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_CQ_NUM) == 1) {
> + ret = rte_kvargs_process(kvlist, VIRTIO_USER_ARG_CQ_NUM,
> + _integer_arg, );
> + if (ret < 0) {
> + PMD_INIT_LOG(ERR, "error to parse %s",
> + VIRTIO_USER_ARG_CQ_NUM);
> + goto end;
> + }
> + }
> else if (queues > 1)
Above 2 lines should be in one line. Fixed, and series applied to
dpdk-next-virtio.
Thanks.
--yliu
[dpdk-dev] xstats performance
On 29/06/2016 17:40, Thomas Monjalon wrote: [..] > I don't think it is possible to standardize stats ids, for two reasons: > - it is hard to maintain and avoid conflicts between drivers > - the drivers would have to lookup the names which degrades performance I designed it that way to keep flexibility down the line rather than specifically for the above use-case. > I think the idea of Olivier would improve the performance of stats retrieval, > which was the idea of this rework :) > Unfortunately we need someone available to fix it quickly for RC2. For all the current drivers xstats_names[idx].id==idx so it would just involve removing the references to the id field and updating the documentation. Complication is coordinating with QLogic for the bnx2x & qede xstats patches. ..Remy
[dpdk-dev] [PATCH v2] net/virtio-user: fix build error in SUSE 11
On Wed, Jun 29, 2016 at 03:23:03AM +, Jianfeng Tan wrote:
> On some older systems, such as SUSE 11, the compiling error shows
> as:
>.../dpdk/drivers/net/virtio/virtio_user/virtio_user_dev.c:67:22:
> error: ?O_CLOEXEC? undeclared (first use in this function)
>
> The fix is to use EFD_CLOEXEC, which is defined in sys/eventfd.h,
> instead of O_CLOEXEC which needs _GNU_SOURCE defined on some old
> systems.
>
> Fixes: 37a7eb2ae816 ("net/virtio-user: add device emulation layer")
>
> Signed-off-by: Jianfeng Tan
Applied to dpdk-next-virtio.
Thanks.
--yliu
[dpdk-dev] [PATCH] net/virtio-user: fix missing default macro
On Wed, Jun 29, 2016 at 03:20:06AM +, Jianfeng Tan wrote:
> With current config structure, all configuration parameters put into
> common_base with a default value, and overwritten in environment file
> if required, CONFIG_RTE_VIRTIO_USER is missing in common_base.
>
> This fix is simple, by adding CONFIG_RTE_VIRTIO_USER=n as the default
> macro value.
>
> Fixes: ce2eabdd43ec ("net/virtio-user: add virtual device")
>
> Reported-by: Ferruh Yigit
> Signed-off-by: Jianfeng Tan
> ---
> config/common_base | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/config/common_base b/config/common_base
> index 5d9daf5..0368d59 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -269,6 +269,11 @@ CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
> CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
>
> #
> +# Compile software VIRTIO-USER PMD driver
I will not call it "PMD driver", instead, I'd say "virtio device
emulation inside virtio PMD".
Fixed and applied to dpdk-next-virtio.
--yliu
> +#
> +CONFIG_RTE_VIRTIO_USER=n
> +
> +#
> # Compile burst-oriented VMXNET3 PMD driver
> #
> CONFIG_RTE_LIBRTE_VMXNET3_PMD=y
> --
> 2.1.4
[dpdk-dev] [PATCH v2] net/ixgbe: fix compilation when offload flags disabled
The ixgbe driver does not compile if CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=n
because the macro has not the proper number of parameters. To reproduce
the issue:
make config T=x86_64-native-linuxapp-gcc
sed -i
's,CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y,CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=n,'
build/.config
make -j4
[...]
ixgbe_rxtx_vec_sse.c: In function ?_recv_raw_pkts_vec?:
ixgbe_rxtx_vec_sse.c:345:53: error: macro "desc_to_olflags_v" passed 3
arguments, but takes just 2
desc_to_olflags_v(descs, vlan_flags, _pkts[pos]);
^
ixgbe_rxtx_vec_sse.c:345:3: error: ?desc_to_olflags_v? undeclared (first use
in this function)
desc_to_olflags_v(descs, vlan_flags, _pkts[pos]);
^
ixgbe_rxtx_vec_sse.c:345:3: note: each undeclared identifier is reported
only once for each function it appears in
ixgbe_rxtx_vec_sse.c:231:10: error: variable ?vlan_flags? set but not used
[-Werror=unused-but-set-variable]
uint8_t vlan_flags;
^
cc1: all warnings being treated as errors
This patch fixes the number of arguments in th macro, and ensure that
vlan_flags is marked as used to avoid the third error.
Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
Reported-by: Amin Tootoonchian
Signed-off-by: Olivier Matz
---
drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
index 4f95deb..1c4fd7c 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
@@ -197,7 +197,9 @@ desc_to_olflags_v(__m128i descs[4], uint8_t vlan_flags,
rx_pkts[3]->ol_flags = vol.e[3];
}
#else
-#define desc_to_olflags_v(desc, rx_pkts) do {} while (0)
+#define desc_to_olflags_v(desc, vlan_flags, rx_pkts) do { \
+ RTE_SET_USED(vlan_flags); \
+ } while (0)
#endif
/*
--
2.8.1
[dpdk-dev] [PATCH 0/3] vhost coverity issue fixes
On Tue, Jun 28, 2016 at 11:58:28AM +0800, Yuanhan Liu wrote: > This is a small series fixes 3 coverity issues. Series applied to dpdk-next-virtio. --yliu > > John, I'm wondering maybe maybe we could add the next-net and > next-virtio tree into the coverity test as well? So that we could > catch those errors as earlier as possible, say, at least before > they got merged into mainline. > > --- > Yuanhan Liu (3): > vhost: fix memory leak > vhost: fix not null terminated string > vhost: fix potential NULL pointer dereference > > lib/librte_vhost/vhost_user/vhost-net-user.c | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > -- > 1.9.0
[dpdk-dev] [PATCH 0/3] vhost coverity issue fixes
On Thu, Jun 30, 2016 at 03:58:31PM +, Mcnamara, John wrote: > > -Original Message- > > From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com] > > Sent: Tuesday, June 28, 2016 4:58 AM > > To: dev at dpdk.org > > Cc: Xie, Huawei ; Mcnamara, John > > ; Yuanhan Liu > > Subject: [PATCH 0/3] vhost coverity issue fixes > > > > This is a small series fixes 3 coverity issues. > > > > John, I'm wondering maybe maybe we could add the next-net and next-virtio > > tree into the coverity test as well? So that we could catch those errors > > as earlier as possible, say, at least before they got merged into > > mainline. > > Hi Yuanhan, > > Good suggestion. I can do that. John, Great! > Are there any additional configs that should > be enabled? Currently the check runs with: > > CONFIG_RTE_LIBRTE_PMD_PCAP=y > CONFIG_RTE_LIBRTE_PMD_QAT=y > CONFIG_RTE_LIBRTE_PMD_AESNI_MB=y > CONFIG_RTE_LIBRTE_PMD_AESNI_GCM=y > CONFIG_RTE_LIBRTE_PMD_SNOW3G=y Non of them are related to vhost/virtio, thus we may don't need them for next-virtio tree. And I just think of one that should be enabled: CONFIG_RTE_LIBRTE_VHOST_NUMA=y OTOH, I'm wondering is it worth to enable those debug options, to cover more codes? One more question: will it cover all branches? I have 2 branches there, master and for-testing. It would be great if the coverity test can cover the two branches. However, it does not matter at all if it just covers one branch only: master. Thanks. --yliu
[dpdk-dev] weak functions in some drivers
> > >>> What is not clear to me is motivation to use weak here instead of simply > > using >CONFIG_RTE_I40E_INC_VECTOR > > >>> macro to exclude stubs in i40e_rxtx.c. It will make library smaller and > > >>> avoid > > issues like this one > > >>> which are quite hard to troubleshoot. > > >> Since this issue seen in fd.io, I didn't investigated more, but I don't > > >> want to clock your valid question, this is an attempt to resurrect the > > >> question ... > > > Hi, > > > > > > We are having exactly the same problem. For us the aforementioned > > workaround doesn't seem to work and vector mode is always disabled with the > > i40e drivers. If I modify i40e_rxtx.c and exclude the stub functions using > > CONFIG_RTE_I40E_INC_VECTOR everything works as expected. > > > > > > We are building DPDK with the CONFIG_RTE_BUILD_COMBINE_LIBS option > > enabled and link DPDK library to our application. > > > > > > Any other ideas how this could be fixed? > > > > > > Regards, > > > Matias > > > > > > > So you have tried to link a combined static lib with --whole-archive > > -ldpdk --no-whole-archive and still get the wrong/weak function definition? > > > > Sergio > > I actually just managed to fix the problem. In our case I had to add > '-Wl,--whole-archive,-ldpdk,--no-whole-archive' to the end of AM_LDFLAGS. > It turned out that the problem actually wasn't fixed. DPDK is built with CONFIG_RTE_BUILD_COMBINE_LIBS=y and EXTRA_CFLAGS="-fPIC" What we are linking originally: -l:libdpdk.a This works otherwise but vector mode i40e is not enabled. When trying: -Wl,--whole-archive,-l:libdpdk.a,--no-whole-archive Linking fails with ' undefined reference' errors to several dpdk functions (rte_eal_init, rte_cpu_get_flag_enabled, rte_eth_stats_get...). Btw. there seems to be a Stack Overflow question related to this: http://stackoverflow.com/questions/38064021/dpdk-include-libraries-in-dpdk-application-compiled-as-shared-library -Matias
[dpdk-dev] [PATCH v1] doc: autogenerate nic overview table from ini files
On Thu, Jun 30, 2016 at 08:25:14PM +0200, Thomas Monjalon wrote: > 2016-06-30 19:03, John McNamara: > > This patch converts the NIC feature table in the overview doc into a set of > > ini files and adds some functions into the Sphinx conf.py file to convert > > them > > back into an RST table. > > > > The reason for doing this is to make it easier for PMD maintainers to update > > the feature matrix that makes up the table and to avoid frequent and hard to > > resolve conflicts in doc/guides/nics/overview.rst. > > Great idea! Yes, indeed! The old formats also make the review hard (due to the long/messy diff). I was also kidding/wishing before that it'd be great if we could have a column-based diff file. With your proposal, we don't need it any more :) --yliu
[dpdk-dev] [PATCH v5 2/2] test: migrate custom handler test to stack handler
Hi David,
On 06/30/2016 08:05 PM, David Hunt wrote:
> After introducing the stack handler in the previous commit,
> we now have very similar code to the custom handler in test_mempool.c,
> which creates a custom mempool based on simple mallocs.
> The stack handler is a cleaner example of adding a new mempool handler,
> so this commit replaces the custom handler test with a stack
> handler test, and removes the custom handler code.
>
> Signed-off-by: David Hunt
>
> [...]
>
> -static struct rte_mempool_ops mempool_ops_custom = {
> - .name = "custom_handler",
> - .alloc = custom_mempool_alloc,
> - .free = custom_mempool_free,
> - .enqueue = custom_mempool_enqueue,
> - .dequeue = custom_mempool_dequeue,
> - .get_count = custom_mempool_get_count,
> -};
> -
> -MEMPOOL_REGISTER_OPS(mempool_ops_custom);
> -
> -/*
> * save the object number in the first 4 bytes of object data. All
> * other bytes are set to 0.
> */
> @@ -600,6 +507,7 @@ test_mempool(void)
> struct rte_mempool *mp_cache = NULL;
> struct rte_mempool *mp_nocache = NULL;
> struct rte_mempool *mp_ext = NULL;
mp_ext remains but is unused (it is just freed below).
It should be removed.
[dpdk-dev] [PATCH] vhost: reset queue state in destroy_device
Fixes a bug where rte_eth_vhost_get_queue_event would not return enabled queues
after a guest application restart.
Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
Signed-off-by: Rich Lane
---
drivers/net/vhost/rte_eth_vhost.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/vhost/rte_eth_vhost.c
b/drivers/net/vhost/rte_eth_vhost.c
index c5bbb87..33e9728 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -303,6 +303,7 @@ destroy_device(int vid)
struct internal_list *list;
char ifname[PATH_MAX];
unsigned i;
+ struct rte_vhost_vring_state *state;
rte_vhost_get_ifname(vid, ifname, sizeof(ifname));
list = find_internal_resource(ifname);
@@ -345,6 +346,15 @@ destroy_device(int vid)
vq->vid = -1;
}
+ state = vring_states[eth_dev->data->port_id];
+ rte_spinlock_lock(>lock);
+ for (i = 0; i <= state->max_vring; i++) {
+ state->cur[i] = false;
+ state->seen[i] = false;
+ }
+ state->max_vring = 0;
+ rte_spinlock_unlock(>lock);
+
RTE_LOG(INFO, PMD, "Connection closed\n");
_rte_eth_dev_callback_process(eth_dev, RTE_ETH_EVENT_INTR_LSC);
--
1.9.1
[dpdk-dev] [PATCH] cmdline: fix unchecked return value
Hi Daniel, >>> --- a/lib/librte_cmdline/cmdline_rdline.c >>> +++ b/lib/librte_cmdline/cmdline_rdline.c >>> @@ -377,7 +377,10 @@ rdline_char_in(struct rdline *rdl, char c) >>> case CMDLINE_KEY_CTRL_K: >>> cirbuf_get_buf_head(>right, rdl->kill_buf, >> RDLINE_BUF_SIZE); >>> rdl->kill_size = CIRBUF_GET_LEN(>right); >>> - cirbuf_del_buf_head(>right, rdl->kill_size); >>> + >>> + if (cirbuf_del_buf_head(>right, rdl->kill_size) < >>> 0) >>> + return -EINVAL; >>> + >>> rdline_puts(rdl, vt100_clear_right); >>> break; >>> >> >> I wonder if a better way to fix wouldn't be to remove the checks >> introduced in http://dpdk.org/browse/dpdk/commit/?id=ab971e562860 >> >> There is no reason to check that in cirbuf_get_buf_head/tail(): >>if (!cbuf || !c) >> >> The function should never fail, it just returns the number of >> copied chars. This is the responsibility of the caller to ensure >> that the pointer to the circular buffer is not NULL. >> >> Also, rdline_char_in() is not expected to return -EINVAL, but >> RDLINE_RES_* instead. >> >> So I think that partially revert ab971e562860 would fix the >> coverity warning. >> >> Regards, >> Olivier > > Removing checks probably will generate more Coverity errors somewhere. > I see that only places where we test negative values are in unit tests. > > Reverting changes I think is overhead and maybe ignoring this patch and set > is as false positive in Coverity is better idea ? We can mark the warning as false positive because this cannot happen right now (the calller checks the validity of cbuf/c). But this is probably something I'll come back on with a patch since there is no reason to check that pointers are not NULL in cirbuf_get_buf_head/tail(). Regards, Olivier
[dpdk-dev] [PATCH v2] mk: fix acl library static linking
On 30/06/2016 17:22, Thomas Monjalon wrote: > 2016-06-30 17:14, Sergio Gonzalez Monroy: >> On 30/06/2016 17:10, Thomas Monjalon wrote: >>> 2016-06-30 17:01, Sergio Gonzalez Monroy: --- a/mk/rte.app.mk +++ b/mk/rte.app.mk @@ -76,12 +76,13 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG)+= -lrte_ip_frag _LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lrte_meter _LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrte_sched _LDLIBS-$(CONFIG_RTE_LIBRTE_LPM)+= -lrte_lpm -_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl _LDLIBS-$(CONFIG_RTE_LIBRTE_JOBSTATS) += -lrte_jobstats _LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power _LDLIBS-y += --whole-archive +# librte_acl needs --whole-archive because of weak functions +_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl _LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER) += -lrte_timer _LDLIBS-$(CONFIG_RTE_LIBRTE_HASH) += -lrte_hash _LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost >>> I was suggesting to keep -lrte_acl at the same place in the group of >>> algorithms libraries, in order to keep an order satisfying this comment: >>> # Order is important: from higher level to lower level >>> >>> But I have not tested if --whole-archive -lrte_acl --no-whole-archive works. >>> >> Sorry, I missed that. >> >> Why is important being before jobstats and power? > It is not. > But I think we need to have some groups. > And ACL is probably at the same layer level as lpm, sched, etc. I guess I just don't see the groups you are mentioning :) How are timer, hash and vhost in the same group? Wouldn't hash be in the same group as acl and lpm?
[dpdk-dev] [PATCH v2] net/ixgbe: fix compilation when offload flags disabled
> The ixgbe driver does not compile if CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=n
> because the macro has not the proper number of parameters. To reproduce
> the issue:
>
> make config T=x86_64-native-linuxapp-gcc
> sed -i
> 's,CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y,CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=n,'
> build/.config
> make -j4
> [...]
>ixgbe_rxtx_vec_sse.c: In function ?_recv_raw_pkts_vec?:
>ixgbe_rxtx_vec_sse.c:345:53: error: macro "desc_to_olflags_v" passed 3
> arguments, but takes just 2
> desc_to_olflags_v(descs, vlan_flags, _pkts[pos]);
> ^
>ixgbe_rxtx_vec_sse.c:345:3: error: ?desc_to_olflags_v? undeclared (first
> use in this function)
> desc_to_olflags_v(descs, vlan_flags, _pkts[pos]);
> ^
>ixgbe_rxtx_vec_sse.c:345:3: note: each undeclared identifier is reported
> only once for each function it appears in
>ixgbe_rxtx_vec_sse.c:231:10: error: variable ?vlan_flags? set but not used
> [-Werror=unused-but-set-variable]
> uint8_t vlan_flags;
> ^
>cc1: all warnings being treated as errors
>
> This patch fixes the number of arguments in th macro, and ensure that
> vlan_flags is marked as used to avoid the third error.
>
> Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
> Reported-by: Amin Tootoonchian
> Signed-off-by: Olivier Matz
> ---
> drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
> b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
> index 4f95deb..1c4fd7c 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
> @@ -197,7 +197,9 @@ desc_to_olflags_v(__m128i descs[4], uint8_t vlan_flags,
> rx_pkts[3]->ol_flags = vol.e[3];
> }
> #else
> -#define desc_to_olflags_v(desc, rx_pkts) do {} while (0)
> +#define desc_to_olflags_v(desc, vlan_flags, rx_pkts) do { \
> + RTE_SET_USED(vlan_flags); \
> + } while (0)
> #endif
>
> /*
> --
Acked-by: Konstantin Ananyev
> 2.8.1
[dpdk-dev] [PATCH] examples/vhost: fix failure without hints
When the specified cores and memory lie on different numa socket with
physical NIC, vhost fails to set up rx queue, and exits without any
hints. This could leads to confusion of users.
This patch fixes it by adding some error messages when calling ether
APIs returns errors.
Fixes: 4796ad63ba1f ("examples/vhost: import userspace vhost application")
Reported-by: Yulong Pei
Signed-off-by: Jianfeng Tan
---
examples/vhost/main.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 3aff2cc..3b98f42 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -332,8 +332,11 @@ port_init(uint8_t port)
rx_rings = (uint16_t)dev_info.max_rx_queues;
/* Configure ethernet device. */
retval = rte_eth_dev_configure(port, rx_rings, tx_rings, _conf);
- if (retval != 0)
+ if (retval != 0) {
+ RTE_LOG(ERR, VHOST_PORT, "Failed to configure port %u: %s.\n",
+ port, strerror(-retval));
return retval;
+ }
/* Setup the queues. */
for (q = 0; q < rx_rings; q ++) {
@@ -341,21 +344,30 @@ port_init(uint8_t port)
rte_eth_dev_socket_id(port),
rxconf,
mbuf_pool);
- if (retval < 0)
+ if (retval < 0) {
+ RTE_LOG(ERR, VHOST_PORT,
+ "Failed to setup rx queue %u of port %u: %s.\n",
+ q, port, strerror(-retval));
return retval;
+ }
}
for (q = 0; q < tx_rings; q ++) {
retval = rte_eth_tx_queue_setup(port, q, tx_ring_size,
rte_eth_dev_socket_id(port),
txconf);
- if (retval < 0)
+ if (retval < 0) {
+ RTE_LOG(ERR, VHOST_PORT,
+ "Failed to setup tx queue %u of port %u: %s.\n",
+ q, port, strerror(-retval));
return retval;
+ }
}
/* Start the device. */
retval = rte_eth_dev_start(port);
if (retval < 0) {
- RTE_LOG(ERR, VHOST_DATA, "Failed to start the device.\n");
+ RTE_LOG(ERR, VHOST_PORT, "Failed to start port %u: %s\n",
+ port, strerror(-retval));
return retval;
}
--
2.1.4
[dpdk-dev] [PATCH v6 2/2] test: migrate custom handler test to stack handler
After introducing the stack handler in the previous commit,
we now have very similar code to the custom handler in test_mempool.c,
which creates a custom mempool based on simple mallocs.
The stack handler is a cleaner example of adding a new mempool handler,
so this commit replaces the custom handler test with a stack
handler test, and removes the custom handler code.
Signed-off-by: David Hunt
---
app/test/test_mempool.c | 117 ++--
1 file changed, 14 insertions(+), 103 deletions(-)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 63c61f3..4aec605 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -89,99 +89,6 @@
static rte_atomic32_t synchro;
/*
- * Simple example of custom mempool structure. Holds pointers to all the
- * elements which are simply malloc'd in this example.
- */
-struct custom_mempool {
- rte_spinlock_t lock;
- unsigned count;
- unsigned size;
- void *elts[];
-};
-
-/*
- * Loop through all the element pointers and allocate a chunk of memory, then
- * insert that memory into the ring.
- */
-static int
-custom_mempool_alloc(struct rte_mempool *mp)
-{
- struct custom_mempool *cm;
-
- cm = rte_zmalloc("custom_mempool",
- sizeof(struct custom_mempool) + mp->size * sizeof(void *), 0);
- if (cm == NULL)
- return -ENOMEM;
-
- rte_spinlock_init(>lock);
- cm->count = 0;
- cm->size = mp->size;
- mp->pool_data = cm;
- return 0;
-}
-
-static void
-custom_mempool_free(struct rte_mempool *mp)
-{
- rte_free((void *)(mp->pool_data));
-}
-
-static int
-custom_mempool_enqueue(struct rte_mempool *mp, void * const *obj_table,
- unsigned n)
-{
- struct custom_mempool *cm = (struct custom_mempool *)(mp->pool_data);
- int ret = 0;
-
- rte_spinlock_lock(>lock);
- if (cm->count + n > cm->size) {
- ret = -ENOBUFS;
- } else {
- memcpy(>elts[cm->count], obj_table, sizeof(void *) * n);
- cm->count += n;
- }
- rte_spinlock_unlock(>lock);
- return ret;
-}
-
-
-static int
-custom_mempool_dequeue(struct rte_mempool *mp, void **obj_table, unsigned n)
-{
- struct custom_mempool *cm = (struct custom_mempool *)(mp->pool_data);
- int ret = 0;
-
- rte_spinlock_lock(>lock);
- if (n > cm->count) {
- ret = -ENOENT;
- } else {
- cm->count -= n;
- memcpy(obj_table, >elts[cm->count], sizeof(void *) * n);
- }
- rte_spinlock_unlock(>lock);
- return ret;
-}
-
-static unsigned
-custom_mempool_get_count(const struct rte_mempool *mp)
-{
- struct custom_mempool *cm = (struct custom_mempool *)(mp->pool_data);
-
- return cm->count;
-}
-
-static struct rte_mempool_ops mempool_ops_custom = {
- .name = "custom_handler",
- .alloc = custom_mempool_alloc,
- .free = custom_mempool_free,
- .enqueue = custom_mempool_enqueue,
- .dequeue = custom_mempool_dequeue,
- .get_count = custom_mempool_get_count,
-};
-
-MEMPOOL_REGISTER_OPS(mempool_ops_custom);
-
-/*
* save the object number in the first 4 bytes of object data. All
* other bytes are set to 0.
*/
@@ -599,7 +506,7 @@ test_mempool(void)
{
struct rte_mempool *mp_cache = NULL;
struct rte_mempool *mp_nocache = NULL;
- struct rte_mempool *mp_ext = NULL;
+ struct rte_mempool *mp_stack = NULL;
rte_atomic32_init();
@@ -629,25 +536,25 @@ test_mempool(void)
}
/* create a mempool with an external handler */
- mp_ext = rte_mempool_create_empty("test_ext",
+ mp_stack = rte_mempool_create_empty("test_stack",
MEMPOOL_SIZE,
MEMPOOL_ELT_SIZE,
RTE_MEMPOOL_CACHE_MAX_SIZE, 0,
SOCKET_ID_ANY, 0);
- if (mp_ext == NULL) {
- printf("cannot allocate mp_ext mempool\n");
+ if (mp_stack == NULL) {
+ printf("cannot allocate mp_stack mempool\n");
goto err;
}
- if (rte_mempool_set_ops_byname(mp_ext, "custom_handler", NULL) < 0) {
- printf("cannot set custom handler\n");
+ if (rte_mempool_set_ops_byname(mp_stack, "stack", NULL) < 0) {
+ printf("cannot set stack handler\n");
goto err;
}
- if (rte_mempool_populate_default(mp_ext) < 0) {
- printf("cannot populate mp_ext mempool\n");
+ if (rte_mempool_populate_default(mp_stack) < 0) {
+ printf("cannot populate mp_stack mempool\n");
goto err;
}
- rte_mempool_obj_iter(mp_ext, my_obj_init, NULL);
+ rte_mempool_obj_iter(mp_stack, my_obj_init, NULL);
/* retrieve the mempool from its name */
if (rte_mempool_lookup("test_nocache") != mp_nocache) {
@@ -686,14 +593,18 @@ test_mempool(void)
if
[dpdk-dev] [PATCH v6 1/2] mempool: add stack (lifo) mempool handler
This is a mempool handler that is useful for pipelining apps, where
the mempool cache doesn't really work - example, where we have one
core doing rx (and alloc), and another core doing Tx (and return). In
such a case, the mempool ring simply cycles through all the mbufs,
resulting in a LLC miss on every mbuf allocated when the number of
mbufs is large. A stack recycles buffers more effectively in this
case.
Signed-off-by: David Hunt
---
lib/librte_mempool/Makefile| 1 +
lib/librte_mempool/rte_mempool_stack.c | 145 +
2 files changed, 146 insertions(+)
create mode 100644 lib/librte_mempool/rte_mempool_stack.c
diff --git a/lib/librte_mempool/Makefile b/lib/librte_mempool/Makefile
index a4c089e..057a6ab 100644
--- a/lib/librte_mempool/Makefile
+++ b/lib/librte_mempool/Makefile
@@ -44,6 +44,7 @@ LIBABIVER := 2
SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += rte_mempool.c
SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += rte_mempool_ops.c
SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += rte_mempool_ring.c
+SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += rte_mempool_stack.c
# install includes
SYMLINK-$(CONFIG_RTE_LIBRTE_MEMPOOL)-include := rte_mempool.h
diff --git a/lib/librte_mempool/rte_mempool_stack.c
b/lib/librte_mempool/rte_mempool_stack.c
new file mode 100644
index 000..a92da69
--- /dev/null
+++ b/lib/librte_mempool/rte_mempool_stack.c
@@ -0,0 +1,145 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+
+struct rte_mempool_stack {
+ rte_spinlock_t sl;
+
+ uint32_t size;
+ uint32_t len;
+ void *objs[];
+};
+
+static int
+stack_alloc(struct rte_mempool *mp)
+{
+ struct rte_mempool_stack *s;
+ unsigned n = mp->size;
+ int size = sizeof(*s) + (n+16)*sizeof(void *);
+
+ /* Allocate our local memory structure */
+ s = rte_zmalloc_socket("mempool-stack",
+ size,
+ RTE_CACHE_LINE_SIZE,
+ mp->socket_id);
+ if (s == NULL) {
+ RTE_LOG(ERR, MEMPOOL, "Cannot allocate stack!\n");
+ return -ENOMEM;
+ }
+
+ rte_spinlock_init(>sl);
+
+ s->size = n;
+ mp->pool_data = s;
+
+ return 0;
+}
+
+static int stack_enqueue(struct rte_mempool *mp, void * const *obj_table,
+ unsigned n)
+{
+ struct rte_mempool_stack *s = mp->pool_data;
+ void **cache_objs;
+ unsigned index;
+
+ rte_spinlock_lock(>sl);
+ cache_objs = >objs[s->len];
+
+ /* Is there sufficient space in the stack ? */
+ if ((s->len + n) > s->size) {
+ rte_spinlock_unlock(>sl);
+ return -ENOBUFS;
+ }
+
+ /* Add elements back into the cache */
+ for (index = 0; index < n; ++index, obj_table++)
+ cache_objs[index] = *obj_table;
+
+ s->len += n;
+
+ rte_spinlock_unlock(>sl);
+ return 0;
+}
+
+static int stack_dequeue(struct rte_mempool *mp, void **obj_table,
+ unsigned n)
+{
+ struct rte_mempool_stack *s = mp->pool_data;
+ void **cache_objs;
+ unsigned index, len;
+
+ rte_spinlock_lock(>sl);
+
+ if (unlikely(n > s->len)) {
+ rte_spinlock_unlock(>sl);
+ return -ENOENT;
+ }
+
+ cache_objs =
[dpdk-dev] [PATCH v6 0/2] mempool: add stack mempool handler
This patch set adds a lifo stack handler to the external mempool manager. This patch utilises the mempool handler feature which allows the addition of new mempool handlers to DPDK. v6 changes: * removed unneeded mp_ext variable. * added in a free for mp_stack after we're finished with it. v5 changes: * Added the extra parameter requred for the changed test_mempool_basic() function for user defined caches. v4 changes: * Update the test to replace the custom handler test with the stack handler test rather than just adding a stack handler test. The custom handler code is very similar to the stack handler, so there's no need to have both. v3 changes: * Updated based on the latest version (v15) of the Mempool Handler feature v2 changes: * updated based on mailing list feedback (Thanks Stephen) * checkpatch fixes. David Hunt (2) mempool: add stack (lifo) mempool handler test: migrate custom handler test to stack handler
[dpdk-dev] [PATCH] Fix misleading indentation in ethtool
gcc complains about:
build/lib/librte_eal/linuxapp/kni/e1000_phy.c:3303:2:
error: this 'if' clause does not guard... [-Werror=misleading-indentation]
Code indentation is misleadingly indented as whether
the following content is guarded by if or not.
With the reference of the context, add the curly braces.
Remove unused const variables too.
Signed-off-by: Pengyu Ma
---
lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c | 9 ++---
lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c | 8 +---
lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c | 5 +
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c
b/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c
index df22470..120e57b 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c
@@ -3300,12 +3300,13 @@ s32 e1000_read_phy_reg_mphy(struct e1000_hw *hw, u32
address, u32 *data)
*data = E1000_READ_REG(hw, E1000_MPHY_DATA);
/* Disable access to mPHY if it was originally disabled */
- if (locked)
+ if (locked) {
ready = e1000_is_mphy_ready(hw);
if (!ready)
return -E1000_ERR_PHY;
E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
E1000_MPHY_DIS_ACCESS);
+ }
return E1000_SUCCESS;
}
@@ -3365,12 +3366,14 @@ s32 e1000_write_phy_reg_mphy(struct e1000_hw *hw, u32
address, u32 data,
E1000_WRITE_REG(hw, E1000_MPHY_DATA, data);
/* Disable access to mPHY if it was originally disabled */
- if (locked)
+ if (locked) {
ready = e1000_is_mphy_ready(hw);
- if (!ready)
+ if (!ready) {
return -E1000_ERR_PHY;
+ }
E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
E1000_MPHY_DIS_ACCESS);
+ }
return E1000_SUCCESS;
}
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c
b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c
index 017dfe1..71cbf1a 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c
@@ -867,14 +867,16 @@ s32 ixgbe_setup_mac_link_82599(struct ixgbe_hw *hw,
link_mode == IXGBE_AUTOC_LMS_KX4_KX_KR_SGMII) {
/* Set KX4/KX/KR support according to speed requested */
autoc &= ~(IXGBE_AUTOC_KX4_KX_SUPP_MASK | IXGBE_AUTOC_KR_SUPP);
- if (speed & IXGBE_LINK_SPEED_10GB_FULL)
+ if (speed & IXGBE_LINK_SPEED_10GB_FULL) {
if (orig_autoc & IXGBE_AUTOC_KX4_SUPP)
autoc |= IXGBE_AUTOC_KX4_SUPP;
if ((orig_autoc & IXGBE_AUTOC_KR_SUPP) &&
- (hw->phy.smart_speed_active == false))
+ (hw->phy.smart_speed_active == false))
autoc |= IXGBE_AUTOC_KR_SUPP;
- if (speed & IXGBE_LINK_SPEED_1GB_FULL)
+ }
+ if (speed & IXGBE_LINK_SPEED_1GB_FULL) {
autoc |= IXGBE_AUTOC_KX_SUPP;
+ }
} else if ((pma_pmd_1g == IXGBE_AUTOC_1G_SFI) &&
(link_mode == IXGBE_AUTOC_LMS_1G_LINK_NO_AN ||
link_mode == IXGBE_AUTOC_LMS_1G_AN)) {
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
index 8c1d2fe..1e9f9d1 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
@@ -59,8 +59,11 @@
#undef CONFIG_DCA_MODULE
char ixgbe_driver_name[] = "ixgbe";
+/*
static const char ixgbe_driver_string[] =
"Intel(R) 10 Gigabit PCI Express Network Driver";
+*/
+
#define DRV_HW_PERF
#ifndef CONFIG_IXGBE_NAPI
@@ -79,8 +82,10 @@ static const char ixgbe_driver_string[] =
#define DRV_VERSION__stringify(MAJ) "." __stringify(MIN) "." \
__stringify(BUILD) DRIVERNAPI DRV_HW_PERF FPGA VMDQ_TAG
const char ixgbe_driver_version[] = DRV_VERSION;
+/*
static const char ixgbe_copyright[] =
"Copyright (c) 1999-2012 Intel Corporation.";
+*/
/* ixgbe_pci_tbl - PCI Device ID Table
*
--
2.7.4
[dpdk-dev] [PATCH] eal: add option --avail-cores to detect lcores
Hi Thomas, > > > > > > Looking at your special case, if the user did set an isolcpus option > > > for another use, with no -c/-l, I understand the dpdk application > > > won't care too much about it. > > > So, this seems like somehow rude to the rest of the system and > unwanted. > > > > The case you mentioned above is not the case I mean. But you make your > > point about this one. > > The case I originally mean: user sets an isolcpus option for DPDK > > applications. Originally, DPDK apps would be started without any > > problem. But for now, fail to start them because the required cores are > > excluded before -c/-l. As per your comments following, we can add a > > warning message (or should we quit on this situation?). But it indeed > > has an effect on old users (they should changed to use "taskset > > ./dpdk_app ..."). Do you think it's a problem? > > There is no activity on this patch. > Jianfeng, do not hesitate to ping if needed. > Should we class this patch as "changes requested"? Yes, according to latest comments, it should be classified as "changes requested" (I've done that). I'll resent a new version. Thanks, Jianfeng
[dpdk-dev] [PATCH v3] doc: virtio PMD Rx/Tx callbacks
This patch explains current virtio PMD Rx/Tx callbacks, to help understand what's the difference, and how to enable the right ones. Signed-off-by: Zhihong Wang Acked-by: John McNamara -- Changes in v3: 1. Rephrase for clearer description. -- Changes in v2: 1. Changes on format and few descriptions. --- doc/guides/nics/virtio.rst | 75 ++ 1 file changed, 69 insertions(+), 6 deletions(-) diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst index 06ca433..c6335d4 100644 --- a/doc/guides/nics/virtio.rst +++ b/doc/guides/nics/virtio.rst @@ -73,7 +73,7 @@ In this release, the virtio PMD driver provides the basic functionality of packe * It supports multicast packets and promiscuous mode. -* The descriptor number for the RX/TX queue is hard-coded to be 256 by qemu. +* The descriptor number for the Rx/Tx queue is hard-coded to be 256 by qemu. If given a different descriptor number by the upper application, the virtio PMD generates a warning and fall back to the hard-coded value. @@ -163,8 +163,9 @@ Host2VM communication example which means received packets come from vEth0, and transmitted packets is sent to vEth0. #. In the guest, bind the virtio device to the uio_pci_generic kernel module and start the forwarding application. -When the virtio port in guest bursts rx, it is getting packets from the raw socket's receive queue. -When the virtio port bursts tx, it is sending packet to the tx_q. +When the virtio port in guest bursts Rx, it is getting packets from the +raw socket's receive queue. +When the virtio port bursts Tx, it is sending packet to the tx_q. .. code-block:: console @@ -183,7 +184,9 @@ Host2VM communication example The packet reception and transmission flow path is: -IXIA packet generator->82599 PF->KNI rx queue->KNI raw socket queue->Guest VM virtio port 0 rx burst->Guest VM virtio port 0 tx burst-> KNI tx queue->82599 PF-> IXIA packet generator +IXIA packet generator->82599 PF->KNI Rx queue->KNI raw socket queue->Guest +VM virtio port 0 Rx burst->Guest VM virtio port 0 Tx burst-> KNI Tx queue +->82599 PF-> IXIA packet generator Virtio with qemu virtio Back End @@ -206,8 +209,68 @@ Virtio with qemu virtio Back End In this example, the packet reception flow path is: -IXIA packet generator->82599 PF->Linux Bridge->TAP0's socket queue-> Guest VM virtio port 0 rx burst-> Guest VM 82599 VF port1 tx burst-> IXIA packet generator +IXIA packet generator->82599 PF->Linux Bridge->TAP0's socket queue-> Guest +VM virtio port 0 Rx burst-> Guest VM 82599 VF port1 Tx burst-> IXIA packet +generator The packet transmission flow is: -IXIA packet generator-> Guest VM 82599 VF port1 rx burst-> Guest VM virtio port 0 tx burst-> tap -> Linux Bridge->82599 PF-> IXIA packet generator +IXIA packet generator-> Guest VM 82599 VF port1 Rx burst-> Guest VM virtio +port 0 Tx burst-> tap -> Linux Bridge->82599 PF-> IXIA packet generator + + +Virtio PMD Rx/Tx Callbacks +-- + +Virtio driver has 3 Rx callbacks and 2 Tx callbacks. + +Rx callbacks: + +#. ``virtio_recv_pkts``: + Regular version without mergeable Rx buffer support. + +#. ``virtio_recv_mergeable_pkts``: + Regular version with mergeable Rx buffer support. + +#. ``virtio_recv_pkts_vec``: + Vector version without mergeable Rx buffer support, also fixes the available + ring indexes and uses vector instructions to optimize performance. + +Tx callbacks: + +#. ``virtio_xmit_pkts``: + Regular version. + +#. ``virtio_xmit_pkts_simple``: + Vector version fixes the available ring indexes to optimize performance. + + +By default, the non-vector callbacks are used: + +* For Rx: If mergeable Rx buffers is disabled then ``virtio_recv_pkts`` is +used; otherwise ``virtio_recv_mergeable_pkts``. + +* For Tx: ``virtio_xmit_pkts``. + + +Vector callbacks will be used when: + +* ``txq_flags`` is set to ``VIRTIO_SIMPLE_FLAGS`` (0xF01), which implies: + +* Single segment is specified. + +* No offload support is needed. + +* Mergeable Rx buffers is disabled. + +The corresponding callbacks are: + +* For Rx: ``virtio_recv_pkts_vec``. + +* For Tx: ``virtio_xmit_pkts_simple``. + + +Example of using the vector version of the virtio poll mode driver in +``testpmd``:: + + testpmd -c 0x7 -n 4 -- -i --txqflags=0xF01 --rxq=1 --txq=1 --nb-cores=1 -- 2.5.0
