[dpdk-dev] Issue with l2fwd in kvm guest
Hi, I am just trying out DPDK in a fedora 18 KVM guest and have an issue when I am trying l2fwd application. I am binding eth1, eth2 interfaces using below commands ./igb_uio_bind.py --bind=igb_uio eth1 ./igb_uio_bind.py --bind=igb_uio eth2 When I run l2fwd app I get following error ./l2fwd -c 1 -n 4 EAL: Cannot read numa node link for lcore 0 - using physical package id instead EAL: Detected lcore 0 as core 0 on socket 0 EAL: Setting up memory... EAL: cannot open /proc/self/numa_maps, consider that all memory is in socket_id 0 EAL: Ask a virtual area of 0x1880 bytes EAL: Virtual area found at 0x9dc0 (size = 0x1880) EAL: Ask a virtual area of 0x40 bytes EAL: Virtual area found at 0x9d40 (size = 0x40) EAL: Ask a virtual area of 0x40 bytes EAL: Virtual area found at 0x9cc0 (size = 0x40) EAL: Requesting 100 pages of size 4MB from socket 0 EAL: TSC frequency is ~3191735 KHz EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clock cycles ! EAL: Master core 0 is ready (tid=b7782800) EAL: PCI device :00:03.0 on NUMA socket -1 EAL: probe driver: 1af4:1000 rte_virtio_pmd EAL: :00:03.0 not managed by UIO driver, skipping EAL: PCI device :00:07.0 on NUMA socket -1 EAL: probe driver: 8086:100e rte_em_pmd EAL: PCI memory mapped at 0xb7732000 EAL: PCI device :00:08.0 on NUMA socket -1 EAL: probe driver: 8086:100e rte_em_pmd EAL: PCI memory mapped at 0xb7712000 Skipping disabled port 0 Skipping disabled port 1 EAL: Error - exiting with code: 1 Cause: All available ports are disabled. Please set portmask. Dmesg logs after binding eth1 and eth2 to igb_uio [5.700591] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [5.733457] e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 55.835017] igb_uio: module verification failed: signature and/or required key missing - tainting kernel [ 55.835888] Use MSIX interrupt by default [ 56.035098] igb_uio :00:07.0: setting latency timer to 64 [ 56.035123] fail to enable pci msix, or not enough msix entries [ 56.035492] uio device registered with irq a [ 56.184789] igb_uio :00:08.0: setting latency timer to 64 [ 56.184811] fail to enable pci msix, or not enough msix entries [ 56.184969] uio device registered with irq b [ 589.675041] Bits 55-60 of /proc/PID/pagemap entries are about to stop being page-shift some time soon. See the linux/Documentation/vm/pagemap.txt for details. Can anyone point me to right direction regarding where I am doing the mistake ? Regards, Ajith
[dpdk-dev] Issue with l2fwd in kvm guest
Ajith, You are missing "-p PORTMASK" command line argument. Since you are binding two ports to IGB_UIO, you should add -p 0x3 to the command line. You can check the example command from sample applications user guide. $ ./build/l2fwd -c 1 -n 4 -- -p 3 Regards, Vivek On Fri, Apr 11, 2014 at 9:34 AM, Ajith Adapa wrote: > Hi, > > I am just trying out DPDK in a fedora 18 KVM guest and have an issue when I > am trying l2fwd application. > > I am binding eth1, eth2 interfaces using below commands > > ./igb_uio_bind.py --bind=igb_uio eth1 > ./igb_uio_bind.py --bind=igb_uio eth2 > > When I run l2fwd app I get following error > > ./l2fwd -c 1 -n 4 > EAL: Cannot read numa node link for lcore 0 - using physical package id > instead > EAL: Detected lcore 0 as core 0 on socket 0 > EAL: Setting up memory... > EAL: cannot open /proc/self/numa_maps, consider that all memory is in > socket_id 0 > EAL: Ask a virtual area of 0x1880 bytes > EAL: Virtual area found at 0x9dc0 (size = 0x1880) > EAL: Ask a virtual area of 0x40 bytes > EAL: Virtual area found at 0x9d40 (size = 0x40) > EAL: Ask a virtual area of 0x40 bytes > EAL: Virtual area found at 0x9cc0 (size = 0x40) > EAL: Requesting 100 pages of size 4MB from socket 0 > EAL: TSC frequency is ~3191735 KHz > EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable > clock cycles ! > EAL: Master core 0 is ready (tid=b7782800) > EAL: PCI device :00:03.0 on NUMA socket -1 > EAL: probe driver: 1af4:1000 rte_virtio_pmd > EAL: :00:03.0 not managed by UIO driver, skipping > EAL: PCI device :00:07.0 on NUMA socket -1 > EAL: probe driver: 8086:100e rte_em_pmd > EAL: PCI memory mapped at 0xb7732000 > EAL: PCI device :00:08.0 on NUMA socket -1 > EAL: probe driver: 8086:100e rte_em_pmd > EAL: PCI memory mapped at 0xb7712000 > Skipping disabled port 0 > Skipping disabled port 1 > EAL: Error - exiting with code: 1 > Cause: All available ports are disabled. Please set portmask. > > Dmesg logs after binding eth1 and eth2 to igb_uio > > [5.700591] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: RX > [5.733457] e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: RX > [ 55.835017] igb_uio: module verification failed: signature and/or > required key missing - tainting kernel > [ 55.835888] Use MSIX interrupt by default > [ 56.035098] igb_uio :00:07.0: setting latency timer to 64 > [ 56.035123] fail to enable pci msix, or not enough msix entries > [ 56.035492] uio device registered with irq a > [ 56.184789] igb_uio :00:08.0: setting latency timer to 64 > [ 56.184811] fail to enable pci msix, or not enough msix entries > [ 56.184969] uio device registered with irq b > [ 589.675041] Bits 55-60 of /proc/PID/pagemap entries are about to stop > being page-shift some time soon. See the linux/Documentation/vm/pagemap.txt > for details. > > Can anyone point me to right direction regarding where I am doing the > mistake ? > > Regards, > Ajith >
[dpdk-dev] I350 drops packet on rte_eth_tx_burst()
Hi friends, Even after installing all the required igb drivers for I350 (the device seems to work perfect on the host machine), am unable to transmit packets using the same device (on Intel DPDK) using ret = rte_eth_tx_burst(port_ids[lcore_id], 0, m_pool, burst_size); At times it might transfer 10 or 15 packets in a burst_size of 64 At times all packets are getting dropped I'm using 64 bit Ubuntu 12.04 Kernel : 3.2.0-29-generic I have built the kernel and library modules(Intel DPDK) with make config T=x86_64-default-linuxapp-gcc make loaded modules with sudo modprobe uio sudo insmod ./x86_64-default-linuxapp-gcc/kmod/igb_uio.ko Any help would be appreciated. Thanks and regards
[dpdk-dev] [PATCH v2 06/11] vdev: rename nonpci_devs as vdev
The name "nonpci_devs" for virtual devices is ambiguous as a physical
device can also be non-PCI (ex: usb, sata, ...). A better name for this
file is "vded" as it only deals with virtual devices.
This patch doesn't introduce any change except renaming.
Signed-off-by: Olivier Matz
---
lib/librte_eal/common/eal_common_nonpci_devs.c | 111 -
lib/librte_eal/common/eal_common_vdev.c| 111 +
lib/librte_eal/common/include/eal_private.h| 4 +-
lib/librte_eal/linuxapp/eal/Makefile | 2 +-
lib/librte_eal/linuxapp/eal/eal.c | 4 +-
5 files changed, 116 insertions(+), 116 deletions(-)
delete mode 100644 lib/librte_eal/common/eal_common_nonpci_devs.c
create mode 100644 lib/librte_eal/common/eal_common_vdev.c
Hi Thomas,
Here is the new version, thanks for reviewing.
diff --git a/lib/librte_eal/common/eal_common_nonpci_devs.c
b/lib/librte_eal/common/eal_common_nonpci_devs.c
deleted file mode 100644
index 71cbb1e..000
--- a/lib/librte_eal/common/eal_common_nonpci_devs.c
+++ /dev/null
@@ -1,111 +0,0 @@
-/*-
- * BSD LICENSE
- *
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
- * Copyright(c) 2014 6WIND S.A.
- * 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
-#ifdef RTE_LIBRTE_PMD_RING
-#include
-#endif
-#ifdef RTE_LIBRTE_PMD_PCAP
-#include
-#endif
-#ifdef RTE_LIBRTE_PMD_XENVIRT
-#include
-#endif
-#include
-#include
-#include "eal_private.h"
-
-struct device_init {
- const char *dev_prefix;
- int (*init_fn)(const char*, const char *);
-};
-
-#define NUM_DEV_TYPES (sizeof(dev_types)/sizeof(dev_types[0]))
-struct device_init dev_types[] = {
-#ifdef RTE_LIBRTE_PMD_RING
- {
- .dev_prefix = RTE_ETH_RING_PARAM_NAME,
- .init_fn = rte_pmd_ring_init
- },
-#endif
-#ifdef RTE_LIBRTE_PMD_PCAP
- {
- .dev_prefix = RTE_ETH_PCAP_PARAM_NAME,
- .init_fn = rte_pmd_pcap_init
- },
-#endif
-#ifdef RTE_LIBRTE_PMD_XENVIRT
- {
- .dev_prefix = RTE_ETH_XENVIRT_PARAM_NAME,
- .init_fn = rte_pmd_xenvirt_init
- },
-#endif
- {
- .dev_prefix = "-nodev-",
- .init_fn = NULL
- }
-};
-
-int
-rte_eal_non_pci_ethdev_init(void)
-{
- struct rte_devargs *devargs;
- uint8_t i;
-
- /* call the init function for each virtual device */
- TAILQ_FOREACH(devargs, &devargs_list, next) {
-
- if (devargs->type != RTE_DEVTYPE_VIRTUAL)
- continue;
-
- for (i = 0; i < NUM_DEV_TYPES; i++) {
- /* search a driver prefix in virtual device name */
- if (!strncmp(dev_types[i].dev_prefix,
- devargs->virtual.drv_name,
-sizeof(dev_types[i].dev_prefix) - 1)) {
- dev_types[i].init_fn(devargs->virtual.drv_name,
-devargs->args);
- break;
- }
- }
-
- if (i == NUM_DEV_TYPES) {
- rte_panic("no driver found for %s\n",
-
[dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API
Instead of having a list of virtual device drivers in EAL code, add an
API to register drivers. Thanks to this new registration method, we can
remove the references to pmd_ring, pmd_pcap and pmd_xenvirt in EAL code.
This also enables the ability to register a virtual device driver as
a shared library.
The registration is done in an init function flaged with
__attribute__((constructor)). The new convention is to name this
function rte_pmd_xyz_init(). The per-device init function is renamed
rte_pmd_xyz_devinit().
By the way the internal PMDs are now also .so/standalone ready. Let's do
it later on. It will be required to ease maintenance.
Signed-off-by: Olivier Matz
---
app/test/test_pmd_ring.c | 6 +--
lib/librte_eal/common/Makefile | 2 +-
lib/librte_eal/common/eal_common_vdev.c | 80
lib/librte_eal/common/include/rte_vdev.h | 90
lib/librte_pmd_pcap/Makefile | 2 +-
lib/librte_pmd_pcap/rte_eth_pcap.c | 18 +--
lib/librte_pmd_pcap/rte_eth_pcap.h | 54 ---
lib/librte_pmd_ring/rte_eth_ring.c | 15 +-
lib/librte_pmd_ring/rte_eth_ring.h | 6 +--
lib/librte_pmd_xenvirt/rte_eth_xenvirt.c | 16 +-
lib/librte_pmd_xenvirt/rte_eth_xenvirt.h | 8 ---
11 files changed, 173 insertions(+), 124 deletions(-)
create mode 100644 lib/librte_eal/common/include/rte_vdev.h
delete mode 100644 lib/librte_pmd_pcap/rte_eth_pcap.h
Hi Thomas,
You are right, I splitted the previous commit as requested. I also
completely remove rte_eth_pcap.h which is not used anymore.
diff --git a/app/test/test_pmd_ring.c b/app/test/test_pmd_ring.c
index c8242b3..4d9c2ba 100644
--- a/app/test/test_pmd_ring.c
+++ b/app/test/test_pmd_ring.c
@@ -315,12 +315,12 @@ test_pmd_ring_init(void)
printf("Testing ring pmd init\n");
- if (rte_pmd_ring_init(name1, params_null) < 0) {
+ if (rte_pmd_ring_devinit(name1, params_null) < 0) {
printf("Testing ring pmd init fail\n");
return -1;
}
- if (rte_pmd_ring_init(name2, params) < 0) {
+ if (rte_pmd_ring_devinit(name2, params) < 0) {
printf("Testing ring pmd init fail\n");
return -1;
}
@@ -372,7 +372,7 @@ test_pmd_ring_init(void)
rte_eth_dev_stop(RXTX_PORT2);
/* Test init same name pmd ring */
- rte_pmd_ring_init(name1, params_null);
+ rte_pmd_ring_devinit(name1, params_null);
return 0;
}
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index b9f3b88..2f99bf4 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -38,7 +38,7 @@ INC += rte_pci_dev_ids.h rte_per_lcore.h rte_prefetch.h
rte_random.h
INC += rte_rwlock.h rte_spinlock.h rte_tailq.h rte_interrupts.h rte_alarm.h
INC += rte_string_fns.h rte_cpuflags.h rte_version.h rte_tailq_elem.h
INC += rte_eal_memconfig.h rte_malloc_heap.h
-INC += rte_hexdump.h rte_devargs.h
+INC += rte_hexdump.h rte_devargs.h rte_vdev.h
ifeq ($(CONFIG_RTE_INSECURE_FUNCTION_WARNING),y)
INC += rte_warnings.h
diff --git a/lib/librte_eal/common/eal_common_vdev.c
b/lib/librte_eal/common/eal_common_vdev.c
index 02d3fd6..62d0302 100644
--- a/lib/librte_eal/common/eal_common_vdev.c
+++ b/lib/librte_eal/common/eal_common_vdev.c
@@ -34,56 +34,43 @@
#include
#include
-#include
-#ifdef RTE_LIBRTE_PMD_RING
-#include
-#endif
-#ifdef RTE_LIBRTE_PMD_PCAP
-#include
-#endif
-#ifdef RTE_LIBRTE_PMD_XENVIRT
-#include
-#endif
+#include
+
+#include
+#include
#include
#include
+
#include "eal_private.h"
-struct device_init {
- const char *dev_prefix;
- int (*init_fn)(const char*, const char *);
-};
+/** Global list of virtual device drivers. */
+static struct rte_vdev_driver_list vdev_driver_list =
+ TAILQ_HEAD_INITIALIZER(vdev_driver_list);
-#define NUM_DEV_TYPES (sizeof(dev_types)/sizeof(dev_types[0]))
-struct device_init dev_types[] = {
-#ifdef RTE_LIBRTE_PMD_RING
- {
- .dev_prefix = RTE_ETH_RING_PARAM_NAME,
- .init_fn = rte_pmd_ring_init
- },
-#endif
-#ifdef RTE_LIBRTE_PMD_PCAP
- {
- .dev_prefix = RTE_ETH_PCAP_PARAM_NAME,
- .init_fn = rte_pmd_pcap_init
- },
-#endif
-#ifdef RTE_LIBRTE_PMD_XENVIRT
- {
- .dev_prefix = RTE_ETH_XENVIRT_PARAM_NAME,
- .init_fn = rte_pmd_xenvirt_init
- },
-#endif
- {
- .dev_prefix = "-nodev-",
- .init_fn = NULL
- }
-};
+/* register a driver */
+void
+rte_eal_vdev_driver_register(struct rte_vdev_driver *driver)
+{
+ TAILQ_INSERT_TAIL(&vdev_driver_list, driver, next);
+}
+
+/* unregister a driver */
+void
+rte_eal_vdev_driver_unregister(struct rte_vdev_driver *driver)
+{
+ TAIL
[dpdk-dev] [PATCH v2 07/11 2/2] vdev: allow external registration of virtual device drivers
The registration of an external vdev driver (a .so library) is done in a
function that has the ((constructor)) attribute. This function is called
when dlopen(driver.so) is invoked.
As a result, we need to do the dlopen() before calling
rte_eal_vdev_init() that calls the initialization functions of all
registered drivers.
Signed-off-by: Olivier Matz
---
lib/librte_eal/linuxapp/eal/eal.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index c015a65..3ded563 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -1046,10 +1046,8 @@ rte_eal_init(int argc, char **argv)
rte_eal_mcfg_complete();
- if (rte_eal_vdev_init() < 0)
- rte_panic("Cannot init virtual devices\n");
-
TAILQ_FOREACH(solib, &solib_list, next) {
+ RTE_LOG(INFO, EAL, "open shared lib %s\n", solib->name);
solib->lib_handle = dlopen(solib->name, RTLD_NOW);
if ((solib->lib_handle == NULL) && (solib->name[0] != '/')) {
/* relative path: try again with "./" prefix */
@@ -1061,6 +1059,9 @@ rte_eal_init(int argc, char **argv)
RTE_LOG(WARNING, EAL, "%s\n", dlerror());
}
+ if (rte_eal_vdev_init() < 0)
+ rte_panic("Cannot init virtual devices\n");
+
RTE_LOG(DEBUG, EAL, "Master core %u is ready (tid=%x)\n",
rte_config.master_lcore, (int)thread_id);
--
1.8.5.3
[dpdk-dev] I350 drops packet on rte_eth_tx_burst()
Hi, 2014-04-11 11:29, sabu kurian: > Even after installing all the required igb drivers for I350 (the device > seems to work perfect on the host machine), am unable to transmit packets > using the same device (on Intel DPDK) using Please follow this documentation to setup your environment and do some basic tests with testpmd: http://dpdk.org/doc/quick-start -- Thomas
[dpdk-dev] IGB_UIO port unbinding
Hi, 2014-04-10 21:34, Prashant Upadhyaya: > There was a usecase with ESXi VMXNET3 NIC where I had to use this parameter > set to Y to make it work. So kindly ensure that the initialization of > vmxnet3 NIC is not vulnerable. This issue is fixed by this commit: http://dpdk.org/browse/dpdk/commit/?id=18f02ff75949de9c2468 So it's not a blocker for removing RTE_EAL_UNBIND_PORTS. -- Thomas
[dpdk-dev] IGB_UIO port unbinding
Hi Prashant, > There was a usecase with ESXi VMXNET3 NIC where I had to use this > parameter set to Y to make it work. > So kindly ensure that the initialization of vmxnet3 NIC is not vulnerable. > Did you try it on the latest 1.6.x code (that option was removed)? More to the point, I can't see how this would be relevant to vmxnet3 initialization. All this config option does is automatically unbinds NICs for you, which is something you can do manually with the included igb_uio_bind.py/pci_unbind.py script anyway. Could you please elaborate on how exactly this option helped with vmxnet3 initialization? Best regards, Anatoly Burakov DPDK SW Engineer -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare
[dpdk-dev] IGB_UIO port unbinding
Hi Anatoly, I might have used the term 'initialization' in a wrong fashion. But I have confirmed, the issue was related to this commit (which Thomas brought to my notice) -- http://dpdk.org/browse/dpdk/commit/?id=18f02ff75949de9c2468 The above should get you the context for the original issue. Regards -Prashant -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Burakov, Anatoly Sent: Friday, April 11, 2014 2:29 PM To: dev at dpdk.org Subject: Re: [dpdk-dev] IGB_UIO port unbinding Hi Prashant, > There was a usecase with ESXi VMXNET3 NIC where I had to use this > parameter set to Y to make it work. > So kindly ensure that the initialization of vmxnet3 NIC is not vulnerable. > Did you try it on the latest 1.6.x code (that option was removed)? More to the point, I can't see how this would be relevant to vmxnet3 initialization. All this config option does is automatically unbinds NICs for you, which is something you can do manually with the included igb_uio_bind.py/pci_unbind.py script anyway. Could you please elaborate on how exactly this option helped with vmxnet3 initialization? Best regards, Anatoly Burakov DPDK SW Engineer -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
[dpdk-dev] IGB_UIO port unbinding
Hi Prashant, > I might have used the term 'initialization' in a wrong fashion. > But I have confirmed, the issue was related to this commit (which Thomas > brought to my notice) -- > > http://dpdk.org/browse/dpdk/commit/?id=18f02ff75949de9c2468 > > The above should get you the context for the original issue. Thanks, that gives me some context. I'm not familiar enough with dpdk.org codebase, so I wasn't aware of these issues. However, from the looks of it, I doubt that vmxnet3 initialization would be affected - the RTE_PCI_DRV_NEED_IGB_UIO flag will be set regardless (in fact, the commit you linked to has removed dependency on RTE_EAL_UNBIND_PORTS config option for vmxnet3), and vmxnet3 should initialize correctly just like the rest of the NICs with or without that config option. I am open to correction on that one however :-) Best regards, Anatoly Burakov DPDK SW Engineer -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare
[dpdk-dev] [memnic PATCH] common: add Dual BSD/GPL license line
Hi Hiroshi, On Thursday, April 03, 2014 07:33:42 AM Hiroshi Shimamoto wrote: > From: Hiroshi Shimamoto > > The MEMNIC header file should be under Dual BSD/GPL license. > Put the license text "Dual BSD/GPL" into the file header. > > Signed-off-by: Hiroshi Shimamoto > --- > common/memnic.h | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Olivier Matz
[dpdk-dev] [memnic PATCH] pmd: use rte_atomic32_cmpset instead of cmpxchg
On Thursday, April 03, 2014 07:34:56 AM Hiroshi Shimamoto wrote: > From: Hiroshi Shimamoto > > Because DPDK has its own compare and set function to optimize to > dedicated processor type, use that rte_atomic32_cmpset() instead of > cmpxchg macro which is specially introduced for MEMNIC. > > Signed-off-by: Hiroshi Shimamoto > --- > common/memnic.h | 12 > pmd/pmd_memnic.c | 10 ++ > 2 files changed, 6 insertions(+), 16 deletions(-) Reviewed-by: Olivier Matz
[dpdk-dev] [memnic PATCH] linux: fix race condition
On Thursday, April 03, 2014 07:35:50 AM Hiroshi Shimamoto wrote: > From: Hiroshi Shimamoto > > Same as PMD, there is a race condition between host and guest > in the guest MEMNIC kernel driver. > > Guest PMD Host > Thread-A Thread-B vSwitch > >|idx=0 |idx=0 |p[0] st!=2 >|cmpxchg || >|p[0] st->1 || >|idx=1 || >|fill data || >|p[0] st->2 ||p[0] st==2 >| >|||receive data >|||p[0] st->0 >|| >||cmpxchg | >||success |p[1] st!=2 >||p[0] st->1 | > > This is BAD > > Signed-off-by: Hiroshi Shimamoto > --- > linux/memnic_net.c | 9 + > 1 file changed, 9 insertions(+) Reviewed-by: Olivier Matz
[dpdk-dev] I350 drops packet on rte_eth_tx_burst()
Hi Friends,
Thanks for the reply.
This is the portion of the code where the I350 fails to send packet:
for(;;){
ret = rte_eth_tx_burst(port_ids[lcore_id], 0, m_pool,
burst_size);
if (unlikely(ret < burst_size)) {
for(j=ret;j<(burst_size-ret);j++)
{
rte_pktmbuf_free(m_pool[j]);
}
}
else
{
lcore_stats[lcore_id].tx += (uint64_t)burst_size;
}
}
all of the m_pool were allocated using
for(j=0;jwrote:
> Hi,
>
> 2014-04-11 11:29, sabu kurian:
> > Even after installing all the required igb drivers for I350 (the device
> > seems to work perfect on the host machine), am unable to transmit packets
> > using the same device (on Intel DPDK) using
>
> Please follow this documentation to setup your environment and do some
> basic
> tests with testpmd:
> http://dpdk.org/doc/quick-start
>
> --
> Thomas
>
[dpdk-dev] I350 drops packet on rte_eth_tx_burst()
To add to my previous mail.
only upto 544 packets are actually sent... then it fails
On Fri, Apr 11, 2014 at 3:34 PM, sabu kurian wrote:
> Hi Friends,
>
> Thanks for the reply.
>
> This is the portion of the code where the I350 fails to send packet:
>
> for(;;){
>
> ret = rte_eth_tx_burst(port_ids[lcore_id], 0, m_pool,
> burst_size);
>
> if (unlikely(ret < burst_size)) {
> for(j=ret;j<(burst_size-ret);j++)
> {
> rte_pktmbuf_free(m_pool[j]);
> }
> }
> else
> {
>
> lcore_stats[lcore_id].tx += (uint64_t)burst_size;
> }
>
> }
>
> all of the m_pool were allocated using
>
> for(j=0;j {
> m_pool[j] = rte_pktmbuf_alloc(pktmbuf_pool);
>
> }
>
>
>
>
> On Fri, Apr 11, 2014 at 1:26 PM, Thomas Monjalon <
> thomas.monjalon at 6wind.com> wrote:
>
>> Hi,
>>
>> 2014-04-11 11:29, sabu kurian:
>> > Even after installing all the required igb drivers for I350 (the device
>> > seems to work perfect on the host machine), am unable to transmit
>> packets
>> > using the same device (on Intel DPDK) using
>>
>> Please follow this documentation to setup your environment and do some
>> basic
>> tests with testpmd:
>> http://dpdk.org/doc/quick-start
>>
>> --
>> Thomas
>>
>
>
[dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API
On Fri, Apr 11, 2014 at 09:36:52AM +0200, Olivier Matz wrote: > Instead of having a list of virtual device drivers in EAL code, add an > API to register drivers. Thanks to this new registration method, we can > remove the references to pmd_ring, pmd_pcap and pmd_xenvirt in EAL code. > This also enables the ability to register a virtual device driver as > a shared library. > > The registration is done in an init function flaged with > __attribute__((constructor)). The new convention is to name this > function rte_pmd_xyz_init(). The per-device init function is renamed > rte_pmd_xyz_devinit(). > > By the way the internal PMDs are now also .so/standalone ready. Let's do > it later on. It will be required to ease maintenance. > > Signed-off-by: Olivier Matz I just posted a patch to separate pmd linkage from the applications yesterday, which will work with the existing API. See my series on the introduction of the PMD_INIT and PMD_INIT_NONPCI macros. Neil
[dpdk-dev] [PATCH v2 06/11] vdev: rename nonpci_devs as vdev
2014-04-11 09:36, Olivier Matz: > The name "nonpci_devs" for virtual devices is ambiguous as a physical > device can also be non-PCI (ex: usb, sata, ...). A better name for this > file is "vded" as it only deals with virtual devices. > > This patch doesn't introduce any change except renaming. > > Signed-off-by: Olivier Matz You probably should change the BSD Makefile also: lib/librte_eal/bsdapp/eal/Makefile:SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_nonpci_devs.c Thanks -- Thomas
[dpdk-dev] [PATCH v3 06/11] vdev: rename nonpci_devs as vdev
The name "nonpci_devs" for virtual devices is ambiguous as a physical
device can also be non-PCI (ex: usb, sata, ...). A better name for this
file is "vdev" as it only deals with virtual devices.
This patch doesn't introduce any change except renaming.
Signed-off-by: Olivier Matz
---
lib/librte_eal/bsdapp/eal/Makefile | 2 +-
lib/librte_eal/bsdapp/eal/eal.c| 4 +-
lib/librte_eal/common/eal_common_nonpci_devs.c | 111 -
lib/librte_eal/common/eal_common_vdev.c| 111 +
lib/librte_eal/common/include/eal_private.h| 4 +-
lib/librte_eal/linuxapp/eal/Makefile | 2 +-
lib/librte_eal/linuxapp/eal/eal.c | 4 +-
7 files changed, 119 insertions(+), 119 deletions(-)
delete mode 100644 lib/librte_eal/common/eal_common_nonpci_devs.c
create mode 100644 lib/librte_eal/common/eal_common_vdev.c
diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index 73facae..4c2a4f1 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -69,7 +69,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_errno.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_cpuflags.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_hexdump.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_whitelist.c
-SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_nonpci_devs.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_vdev.c
CFLAGS_eal.o := -D_GNU_SOURCE
#CFLAGS_eal_thread.o := -D_GNU_SOURCE
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index be00f91..e944aba 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -854,8 +854,8 @@ rte_eal_init(int argc, char **argv)
rte_eal_mcfg_complete();
- if (rte_eal_non_pci_ethdev_init() < 0)
- rte_panic("Cannot init non-PCI eth_devs\n");
+ if (rte_eal_vdev_init() < 0)
+ rte_panic("Cannot init virtual devices\n");
RTE_LCORE_FOREACH_SLAVE(i) {
diff --git a/lib/librte_eal/common/eal_common_nonpci_devs.c
b/lib/librte_eal/common/eal_common_nonpci_devs.c
deleted file mode 100644
index 71cbb1e..000
--- a/lib/librte_eal/common/eal_common_nonpci_devs.c
+++ /dev/null
@@ -1,111 +0,0 @@
-/*-
- * BSD LICENSE
- *
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
- * Copyright(c) 2014 6WIND S.A.
- * 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
-#ifdef RTE_LIBRTE_PMD_RING
-#include
-#endif
-#ifdef RTE_LIBRTE_PMD_PCAP
-#include
-#endif
-#ifdef RTE_LIBRTE_PMD_XENVIRT
-#include
-#endif
-#include
-#include
-#include "eal_private.h"
-
-struct device_init {
- const char *dev_prefix;
- int (*init_fn)(const char*, const char *);
-};
-
-#define NUM_DEV_TYPES (sizeof(dev_types)/sizeof(dev_types[0]))
-struct device_init dev_types[] = {
-#ifdef RTE_LIBRTE_PMD_RING
- {
- .dev_prefix = RTE_ETH_RING_PARAM_NAME,
- .init_fn = rte_pmd_ring_init
- },
-#endif
-#ifdef RTE_LIBRTE_PMD_PCAP
- {
- .dev_prefix = RTE_ETH_PCAP_PARAM_NAME,
- .init_fn = rte_pmd_pcap_init
- },
-#endif
-#ifdef RTE_LIBRTE_PMD_XENVIRT
- {
- .dev_p
[dpdk-dev] [PATCH] Remove RTE_EAL_UNBIND_PORTS-related code
RTE_EAL_UNBIND_PORTS was deprecated in DPDK 1.4.0 and removed in 1.6.0, but the
code was not removed.
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/linuxapp/eal/eal_pci.c | 221 --
1 file changed, 221 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 5fa466e..9e5a139 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -109,199 +109,6 @@ static int pci_parse_sysfs_value(const char *filename,
uint64_t *val);
/* forward prototype of function called in pci_switch_module below */
static int pci_uio_map_resource(struct rte_pci_device *dev);
-#ifdef RTE_EAL_UNBIND_PORTS
-#define PROC_MODULES "/proc/modules"
-
-#define IGB_UIO_NAME "igb_uio"
-
-#define UIO_DRV_PATH "/sys/bus/pci/drivers/%s"
-
-/* maximum time to wait that /dev/uioX appears */
-#define UIO_DEV_WAIT_TIMEOUT 3 /* seconds */
-
-/*
- * Check that a kernel module is loaded. Returns 0 on success, or if the
- * parameter is NULL, or -1 if the module is not loaded.
- */
-static int
-pci_uio_check_module(const char *module_name)
-{
- FILE *f;
- unsigned i;
- char buf[BUFSIZ];
-
- if (module_name == NULL)
- return 0;
-
- f = fopen(PROC_MODULES, "r");
- if (f == NULL) {
- RTE_LOG(ERR, EAL, "Cannot open "PROC_MODULES": %s\n",
- strerror(errno));
- return -1;
- }
-
- while(fgets(buf, sizeof(buf), f) != NULL) {
-
- for (i = 0; i < sizeof(buf) && buf[i] != '\0'; i++) {
- if (isspace(buf[i]))
- buf[i] = '\0';
- }
-
- if (strncmp(buf, module_name, sizeof(buf)) == 0) {
- fclose(f);
- return 0;
- }
- }
- fclose(f);
- return -1;
-}
-
-/* bind a PCI to the kernel module driver */
-static int
-pci_bind_device(struct rte_pci_device *dev, char dr_path[])
-{
- FILE *f;
- int n;
- char buf[BUFSIZ];
- char dev_bind[PATH_MAX];
- struct rte_pci_addr *loc = &dev->addr;
-
- n = rte_snprintf(dev_bind, sizeof(dev_bind), "%s/bind", dr_path);
- if ((n < 0) || (n >= (int)sizeof(buf))) {
- RTE_LOG(ERR, EAL, "Cannot rte_snprintf device bind path\n");
- return -1;
- }
-
- f = fopen(dev_bind, "w");
- if (f == NULL) {
- RTE_LOG(ERR, EAL, "Cannot open %s\n", dev_bind);
- return -1;
- }
- n = rte_snprintf(buf, sizeof(buf), PCI_PRI_FMT "\n",
-loc->domain, loc->bus, loc->devid, loc->function);
- if ((n < 0) || (n >= (int)sizeof(buf))) {
- RTE_LOG(ERR, EAL, "Cannot rte_snprintf PCI infos\n");
- fclose(f);
- return -1;
- }
- if (fwrite(buf, n, 1, f) == 0) {
- fclose(f);
- return -1;
- }
-
- fclose(f);
- return 0;
-}
-
-static int
-pci_uio_bind_device(struct rte_pci_device *dev, const char *module_name)
-{
- FILE *f;
- int n;
- char buf[BUFSIZ];
- char uio_newid[PATH_MAX];
- char uio_bind[PATH_MAX];
-
- n = rte_snprintf(uio_newid, sizeof(uio_newid), UIO_DRV_PATH "/new_id",
module_name);
- if ((n < 0) || (n >= (int)sizeof(uio_newid))) {
- RTE_LOG(ERR, EAL, "Cannot rte_snprintf uio_newid name\n");
- return -1;
- }
-
- n = rte_snprintf(uio_bind, sizeof(uio_bind), UIO_DRV_PATH, module_name);
- if ((n < 0) || (n >= (int)sizeof(uio_bind))) {
- RTE_LOG(ERR, EAL, "Cannot rte_snprintf uio_bind name\n");
- return -1;
- }
-
- n = rte_snprintf(buf, sizeof(buf), "%x %x\n",
- dev->id.vendor_id, dev->id.device_id);
- if ((n < 0) || (n >= (int)sizeof(buf))) {
- RTE_LOG(ERR, EAL, "Cannot rte_snprintf vendor_id/device_id\n");
- return -1;
- }
-
- f = fopen(uio_newid, "w");
- if (f == NULL) {
- RTE_LOG(ERR, EAL, "Cannot open %s\n", uio_newid);
- return -1;
- }
- if (fwrite(buf, n, 1, f) == 0) {
- fclose(f);
- return -1;
- }
- fclose(f);
-
- pci_bind_device(dev, uio_bind);
- return 0;
-}
-
-/* unbind kernel driver for this device */
-static int
-pci_unbind_kernel_driver(struct rte_pci_device *dev)
-{
- int n;
- FILE *f;
- char filename[PATH_MAX];
- char buf[BUFSIZ];
- struct rte_pci_addr *loc = &dev->addr;
-
- /* open /sys/bus/pci/devices/:BB:CC.D/driver */
- rte_snprintf(filename, sizeof(filename),
-SYSFS_PCI_DEVICES "/" PCI_PRI_FMT "/driver/unbind",
-loc->domain, loc->bus, loc->devid, loc->function);
-
- f = fopen(filename, "w");
- if (f == NULL) /* d
[dpdk-dev] [PATCH v3 06/11] vdev: rename nonpci_devs as vdev
2014-04-11 13:45, Olivier Matz: > The name "nonpci_devs" for virtual devices is ambiguous as a physical > device can also be non-PCI (ex: usb, sata, ...). A better name for this > file is "vdev" as it only deals with virtual devices. > > This patch doesn't introduce any change except renaming. > > Signed-off-by: Olivier Matz Acked-by: Thomas Monjalon Applied for version 1.6.0r2. Thanks -- Thomas
[dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API
Hi Neil, 2014-04-11 06:49, Neil Horman: > On Fri, Apr 11, 2014 at 09:36:52AM +0200, Olivier Matz wrote: > > Instead of having a list of virtual device drivers in EAL code, add an > > API to register drivers. Thanks to this new registration method, we can > > remove the references to pmd_ring, pmd_pcap and pmd_xenvirt in EAL code. > > This also enables the ability to register a virtual device driver as > > a shared library. > > > > The registration is done in an init function flaged with > > __attribute__((constructor)). The new convention is to name this > > function rte_pmd_xyz_init(). The per-device init function is renamed > > rte_pmd_xyz_devinit(). > > > > By the way the internal PMDs are now also .so/standalone ready. Let's do > > it later on. It will be required to ease maintenance. > > > > Signed-off-by: Olivier Matz > > I just posted a patch to separate pmd linkage from the applications > yesterday, which will work with the existing API. See my series on the > introduction of the PMD_INIT and PMD_INIT_NONPCI macros. This patch serie was posted weeks ago and has been reviewed. It's a good approach because code is simpler like this and it's a first step before removing rte_pmd_init_all(). Your patches are using rte_pmd_init_all() which is an useless function. Neil, next time, don't hesitate to discuss the design approaches before doing such big changes. By the way, your patches have to be reviewed carefully because there are other insteresting changes. Thanks -- Thomas
[dpdk-dev] [PATCH] rte_pmd_init_all: initialize non-PCI PMDs provided by EAL
Hi John, 2014-04-10 10:41, John W. Linville: > These PMDs were being initialized by the EAL layer, but many apps were > relying on the return value of rte_pmd_init_all to indicate that > ethernet interfaces were available for use. Move the initialization of > the non-PCI PMDs to this centralized function to have all of the PMDs > treated equally. > > Signed-off-by: John W. Linville We are using constuctors to initialize these drivers. See the patches from Olivier Matz. The function rte_pmd_init_all() should be removed. So this patch won't be applied. Your help to continue cleaning this area is welcome. -- Thomas
[dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API
2014-04-11 09:36, Olivier Matz: > Instead of having a list of virtual device drivers in EAL code, add an > API to register drivers. Thanks to this new registration method, we can > remove the references to pmd_ring, pmd_pcap and pmd_xenvirt in EAL code. > This also enables the ability to register a virtual device driver as > a shared library. > > The registration is done in an init function flaged with > __attribute__((constructor)). The new convention is to name this > function rte_pmd_xyz_init(). The per-device init function is renamed > rte_pmd_xyz_devinit(). > > By the way the internal PMDs are now also .so/standalone ready. Let's do > it later on. It will be required to ease maintenance. > > Signed-off-by: Olivier Matz Acked-by: Thomas Monjalon Applied for version 1.6.0r2. Thank you -- Thomas
[dpdk-dev] [PATCH v2 07/11 2/2] vdev: allow external registration of virtual device drivers
2014-04-11 09:36, Olivier Matz: > The registration of an external vdev driver (a .so library) is done in a > function that has the ((constructor)) attribute. This function is called > when dlopen(driver.so) is invoked. > > As a result, we need to do the dlopen() before calling > rte_eal_vdev_init() that calls the initialization functions of all > registered drivers. > > Signed-off-by: Olivier Matz Acked-by: Thomas Monjalon Applied for version 1.6.0r2. Thank you -- Thomas
[dpdk-dev] [memnic PATCH v2] pmd: fix race condition
On Thursday, April 03, 2014 06:35:06 AM Hiroshi Shimamoto wrote: > From: Hiroshi Shimamoto > > There is a race condition, on transmit to host. > > Guest PMD Host > Thread-A Thread-B vSwitch > >|idx=0 |idx=0 |p[0] st!=2 >|cmpxchg || >|p[0] st->1 || >|idx=1 || >|fill data || >|p[0] st->2 ||p[0] st==2 >| >|||receive data >|||p[0] st->0 >|| >||cmpxchg | >||success |p[1] st!=2 >||p[0] st->1 | > > This is BAD > > That causes traffic stop. > > We have to take care about that race condition with checking > whether current index is correct. > > Signed-off-by: Hiroshi Shimamoto > Reviewed-by: Hayato Momma > --- > pmd/pmd_memnic.c | 9 + > 1 file changed, 9 insertions(+) Reviewed-by: Olivier Matz
[dpdk-dev] [memnic PATCH] pmd: use rte_atomic32_cmpset instead of cmpxchg
2014-04-11 11:37, Olivier MATZ: > On Thursday, April 03, 2014 07:34:56 AM Hiroshi Shimamoto wrote: > > From: Hiroshi Shimamoto > > > > Because DPDK has its own compare and set function to optimize to > > dedicated processor type, use that rte_atomic32_cmpset() instead of > > cmpxchg macro which is specially introduced for MEMNIC. > > > > Signed-off-by: Hiroshi Shimamoto > > Reviewed-by: Olivier Matz Applied Thanks -- Thomas
[dpdk-dev] [memnic PATCH v2] pmd: fix race condition
2014-04-11 16:41, Olivier MATZ: > On Thursday, April 03, 2014 06:35:06 AM Hiroshi Shimamoto wrote: > > From: Hiroshi Shimamoto > > > > There is a race condition, on transmit to host. > > > > Guest PMD Host > > Thread-A Thread-B vSwitch > > > >|idx=0 |idx=0 |p[0] st!=2 > >|cmpxchg || > >|p[0] st->1 || > >|idx=1 || > >|fill data || > >|p[0] st->2 ||p[0] st==2 > >| > >|||receive data > >|||p[0] st->0 > >|| > >||cmpxchg | > >||success |p[1] st!=2 > >||p[0] st->1 | > >|| > > This is BAD > > > > That causes traffic stop. > > > > We have to take care about that race condition with checking > > whether current index is correct. > > > > Signed-off-by: Hiroshi Shimamoto > > Reviewed-by: Hayato Momma > > Reviewed-by: Olivier Matz Applied Thanks -- Thomas
[dpdk-dev] [memnic PATCH] linux: fix race condition
2014-04-11 11:41, Olivier MATZ: > On Thursday, April 03, 2014 07:35:50 AM Hiroshi Shimamoto wrote: > > From: Hiroshi Shimamoto > > > > Same as PMD, there is a race condition between host and guest > > in the guest MEMNIC kernel driver. > > > > Guest PMD Host > > Thread-A Thread-B vSwitch > > > >|idx=0 |idx=0 |p[0] st!=2 > >|cmpxchg || > >|p[0] st->1 || > >|idx=1 || > >|fill data || > >|p[0] st->2 ||p[0] st==2 > >| > >|||receive data > >|||p[0] st->0 > >|| > >||cmpxchg | > >||success |p[1] st!=2 > >||p[0] st->1 | > >|| > > This is BAD > > > > Signed-off-by: Hiroshi Shimamoto > > --- > > > > linux/memnic_net.c | 9 + > > 1 file changed, 9 insertions(+) > > Reviewed-by: Olivier Matz Applied Thanks -- Thomas
[dpdk-dev] [memnic PATCH] common: add Dual BSD/GPL license line
2014-04-11 11:35, Olivier MATZ: > Hi Hiroshi, > > On Thursday, April 03, 2014 07:33:42 AM Hiroshi Shimamoto wrote: > > From: Hiroshi Shimamoto > > > > The MEMNIC header file should be under Dual BSD/GPL license. > > Put the license text "Dual BSD/GPL" into the file header. > > > > Signed-off-by: Hiroshi Shimamoto > > Reviewed-by: Olivier Matz Applied Thanks -- Thomas
[dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API
On Fri, Apr 11, 2014 at 03:11:56PM +0200, Thomas Monjalon wrote: > Hi Neil, > > 2014-04-11 06:49, Neil Horman: > > On Fri, Apr 11, 2014 at 09:36:52AM +0200, Olivier Matz wrote: > > > Instead of having a list of virtual device drivers in EAL code, add an > > > API to register drivers. Thanks to this new registration method, we can > > > remove the references to pmd_ring, pmd_pcap and pmd_xenvirt in EAL code. > > > This also enables the ability to register a virtual device driver as > > > a shared library. > > > > > > The registration is done in an init function flaged with > > > __attribute__((constructor)). The new convention is to name this > > > function rte_pmd_xyz_init(). The per-device init function is renamed > > > rte_pmd_xyz_devinit(). > > > > > > By the way the internal PMDs are now also .so/standalone ready. Let's do > > > it later on. It will be required to ease maintenance. > > > > > > Signed-off-by: Olivier Matz > > > > I just posted a patch to separate pmd linkage from the applications > > yesterday, which will work with the existing API. See my series on the > > introduction of the PMD_INIT and PMD_INIT_NONPCI macros. > > This patch serie was posted weeks ago and has been reviewed. When and where? You are correct, this series was posted about 1.5 months ago: http://dpdk.org/ml/archives/dev/2014-February/001466.html To which there was a single comment, and no other traffic until last night, when a few bits of the series were posted to git, followed by the remaining bits several hours later. I don't see any acks or indications that, after 1.5 months, this was still an active patch series. Note also that whatever review was done, was not particularly through. There are still problems with the libraries after Oliviers patch series: [nhorman at hmsreliant lib]$ ldd librte_pmd_pcap.so statically linked The DSO's built by dpdk are not actually build as shared libraries but rather statically linked together. My patch series corrects that Also, the build system fails to recognize the fact applications no longer need to link against specific pmd libraries. testpmd for example still links to every single pmd libraryin dpdk, despite the fact that doesn't need to happen (at least not with my patch series) [nhorman at hmsreliant app]$ ldd testpmd ... librte_pmd_e1000.so librte_pmd_ixgbe.so librte_pmd_virtio_uio.so librte_pmd_vmxnet3_uio.so ... Thats just a sample, but none of the pmds need to be explicitly referenced at link time when using DSO's. They can be specified at run time with the -d option. They only need to be linked when you want to avoid having to use the -d option at run time. My patch series corrects that. > It's a good approach because code is simpler like this and it's a first step > before removing rte_pmd_init_all(). > Your patches are using rte_pmd_init_all() which is an useless function. > Thats not at all true. rte_pmd_init_all is adventageous because it is agnostic toward the pmd that is in use. If you use constructors in the pmds (which is good), you don't need to reference the specific libraries in your application code, but Oliviers approach will require that you do so. Needing to specify a specific pmd init function in your application destroys the usefulness of the -d option in the eal option parsing code. That is to say, if I have an application that wants to use the ring_pmd, it needs to call the ring_pmd init function. Once that is coded into the application, no other pmd can be loaded, because the application doesn't call that pmds init function (i.e. -d is made useless). Conversely, if an application uses rte_pmd_init_all (the way my patch series codes it), any pmd that is either statically/dynamically loaded by the application, or opened via a dlopen call, will be registered and initalized, allowing any application to control which pmd is used during the build process or at run time, without having to hard code any initalization. > Neil, next time, don't hesitate to discuss the design approaches before doing > such big changes. By the way, your patches have to be reviewed carefully > because there are other insteresting changes. > I didn't hesitate, Im happy to reach out and discuss large changes, I just thought I would do so with code in hand (this change set only took a few days to write). I think my major failing was to assume that the git tree was reasonably up to date with the mailing list. I joined the mailing list about a month ago (2 weeks after this patch series went up). About a week ago I started tinkering with this, under the impression that what was in the git tree (having seem my assembly patch go in) was reasonably current with the mailing list. Having a patch sit on a mailing list without comment for a month is not condusive to doing upstream development. Checking the mailing list for prior work isn't helpful either, as mailman doesn't allow for the easy extract
[dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API
2014-04-11 11:50, Neil Horman: > There are still problems with the libraries after Oliviers patch series: > > [nhorman at hmsreliant lib]$ ldd librte_pmd_pcap.so > statically linked > > The DSO's built by dpdk are not actually build as shared libraries but > rather statically linked together. My patch series corrects that Yes, that's why I said that "your patches have to be reviewed carefully because there are other insteresting changes" > Also, the build system fails to recognize the fact applications no longer > need to link against specific pmd libraries. testpmd for example still > links to every single pmd libraryin dpdk, despite the fact that doesn't > need to happen (at least not with my patch series) > [nhorman at hmsreliant app]$ ldd testpmd > ... > librte_pmd_e1000.so > librte_pmd_ixgbe.so > librte_pmd_virtio_uio.so > librte_pmd_vmxnet3_uio.so > ... > > Thats just a sample, but none of the pmds need to be explicitly referenced > at link time when using DSO's. They can be specified at run time with the > -d option. They only need to be linked when you want to avoid having to use > the -d option at run time. My patch series corrects that. I agree. > > It's a good approach because code is simpler like this and it's a first > > step before removing rte_pmd_init_all(). > > Your patches are using rte_pmd_init_all() which is an useless function. > > Thats not at all true. rte_pmd_init_all is adventageous because it is > agnostic toward the pmd that is in use. Not having rte_pmd_init_all() at all is a bit more agnostic :) > If you use constructors in the > pmds (which is good), you don't need to reference the specific libraries in > your application code, but Oliviers approach will require that you do so. > Needing to specify a specific pmd init function in your application > destroys the usefulness of the -d option in the eal option parsing code. Could you point where we need to call a specific pmd init function? If it's the case, it must simply be fixed. > That is to say, if I have an application that wants to use the ring_pmd, it > needs to call the ring_pmd init function. Once that is coded into the > application, no other pmd can be loaded, because the application doesn't > call that pmds init function (i.e. -d is made useless). I agree that ring_pmd init should be fixed. > Conversely, if an > application uses rte_pmd_init_all (the way my patch series codes it), any > pmd that is either statically/dynamically loaded by the application, or > opened via a dlopen call, will be registered and initalized, allowing any > application to control which pmd is used during the build process or at run > time, without having to hard code any initalization. It seems that your patch is not removing rte_eth_ring_pair_create/rte_eth_ring_pair_attach so I'm not sure you can dynamically change the PMD in this case. > > Neil, next time, don't hesitate to discuss the design approaches before > > doing such big changes. By the way, your patches have to be reviewed > > carefully because there are other insteresting changes. > > I didn't hesitate, Im happy to reach out and discuss large changes, I just > thought I would do so with code in hand (this change set only took a few > days to write). I think my major failing was to assume that the git tree > was reasonably up to date with the mailing list. I joined the mailing list > about a month ago (2 weeks after this patch series went up). About a week > ago I started tinkering with this, under the impression that what was in > the git tree (having seem my assembly patch go in) was reasonably current > with the mailing list. Having a patch sit on a mailing list without comment > for a month is not condusive to doing upstream development. Checking the > mailing list for prior work isn't helpful either, as mailman doesn't allow > for the easy extraction of patches (they're all served as html), and > patches that sit for that long begin to look suspect (are they going in or > not?). You're right. It shouldn't stay so long without being integrated. Using patchwork should help us here. > If I can make a suggestion: If you're planning on delaying patches like this > for that length of time, create a devel branch for unstable changes, which > accepts changes from the mailing list in a timely fashion. Allow public > testing to weed out the problems, not off-list review. Set stabilization > periods for said devel-branch and merge them to the latest release branch > during those times. Also, please don't push larger series piecemeal out to > the git tree. Stage them all on your copy of the repo and push them at > once. As it is, my patch series is rebased to a point that is halfway > through Oliviers patch series. I know John Linville is on this list that > maintains the wireless tree, and I'm sure he can offer lots of good git > workflow pointers. I understand your comment. This workflow worked w
[dpdk-dev] IGB_UIO port unbinding
On Thu, 10 Apr 2014 09:39:35 + "Burakov, Anatoly" wrote: > Hi everyone > > As you may or may not know, the CONFIG_RTE_EAL_UNBIND_PORTS was deprecated in > the official Intel(r) DPDK 1.6.0 release package. However, the code itself > (e.g. in lib/librte_eal/linuxapp/eal_pci.c and other places) to support that > config option was not removed. My question would be, would anyone be opposed > to a patch to remove that code entirely? E.g. does anyone use that > functionality? > > Best regards, > Anatoly Burakov > DPDK SW Engineer I actually liked the unbind code that was there. It meant that additional logic did not have to be added to the startup script to do PCI discovery and finding/mapping devices. As it is the EAL startup process is a bit of a mess. It assumes that various bits of information and infrastructure are already in place prior to starting the DPDK application. Other silly DPDK environment issues are: why does DPDK have to know the number of memory channels in the system? How is the end user of an application supposed to know this? Sure your hacker might but not end user. It is difficult to impossible to determine this information at runtime. The best I could find is to use DMI decode to count number of memory banks and guess! The CPU mask is also something that should "do the right thing" and use all CPU's unless told otherwise. Having to wrap every DPDK application in a shell script makes the application more brittle and creates overlapping effort.
[dpdk-dev] Where can you get cheap hardware to run dpdk ?
1) anywhere on amazon or elsewhere on the cloud. 2) If you have a specific hw configuration that you can buy off the shelf i would appreciate
[dpdk-dev] Poor device abstraction's
One of my pet peeve's is that the device driver config does not abstract the properties of the Ethernet device. The existing parameters match those of Intel's Ethernet hardware but not much else. It also makes it hard to write generic applications. If the application has to query the device driver name string and insert different parameters for igb, igbvf, ixgbe and vmxnet3 then the API was designed wrong. Specific examples: * the "descriptors" argument to rx/tx is interpreted as a hardware resource not the number of packets. An application really wants to say "you may buffer up to 100us of packets" not have to guess what the underlying driver does. * the rthresh/wthresh/pthresh are PCI device artifacts and correct value is different for each HW device shouldn't be exposed to application. The API should be something like "device may burst up to N packets and/or T latency". These seems like issues of a transition from a cool toy to talk to Intel hardware to a useful application infrastructure. That is why I would hate to see the existing Intel device centric API frozen.
[dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API
On Fri, Apr 11, 2014 at 06:18:08PM +0200, Thomas Monjalon wrote: > 2014-04-11 11:50, Neil Horman: > > There are still problems with the libraries after Oliviers patch series: > > > > [nhorman at hmsreliant lib]$ ldd librte_pmd_pcap.so > > statically linked > > > > The DSO's built by dpdk are not actually build as shared libraries but > > rather statically linked together. My patch series corrects that > > Yes, that's why I said that "your patches have to be reviewed carefully > because there are other insteresting changes" > Ok, But you also said that the previous patchset was reviewed carefully. Apologies for any confusion. > > Also, the build system fails to recognize the fact applications no longer > > need to link against specific pmd libraries. testpmd for example still > > links to every single pmd libraryin dpdk, despite the fact that doesn't > > need to happen (at least not with my patch series) > > [nhorman at hmsreliant app]$ ldd testpmd > > ... > > librte_pmd_e1000.so > > librte_pmd_ixgbe.so > > librte_pmd_virtio_uio.so > > librte_pmd_vmxnet3_uio.so > > ... > > > > Thats just a sample, but none of the pmds need to be explicitly referenced > > at link time when using DSO's. They can be specified at run time with the > > -d option. They only need to be linked when you want to avoid having to use > > the -d option at run time. My patch series corrects that. > > I agree. > > > > It's a good approach because code is simpler like this and it's a first > > > step before removing rte_pmd_init_all(). > > > Your patches are using rte_pmd_init_all() which is an useless function. > > > > Thats not at all true. rte_pmd_init_all is adventageous because it is > > agnostic toward the pmd that is in use. > > Not having rte_pmd_init_all() at all is a bit more agnostic :) > Well, that would be great, I presume you are proposing tucking the driver initalization into the eal library as part of the eal library init, so as to protect it from the application? > > If you use constructors in the > > pmds (which is good), you don't need to reference the specific libraries in > > your application code, but Oliviers approach will require that you do so. > > Needing to specify a specific pmd init function in your application > > destroys the usefulness of the -d option in the eal option parsing code. > > Could you point where we need to call a specific pmd init function? > If it's the case, it must simply be fixed. > Sorry, I misread here. I was convoluted the previous approach in which some of the sample apps called pmd initalization functions directly. Looking at the patches in a web browser, I thought that was still being done in the test app. > > That is to say, if I have an application that wants to use the ring_pmd, it > > needs to call the ring_pmd init function. Once that is coded into the > > application, no other pmd can be loaded, because the application doesn't > > call that pmds init function (i.e. -d is made useless). > > I agree that ring_pmd init should be fixed. > > > Conversely, if an > > application uses rte_pmd_init_all (the way my patch series codes it), any > > pmd that is either statically/dynamically loaded by the application, or > > opened via a dlopen call, will be registered and initalized, allowing any > > application to control which pmd is used during the build process or at run > > time, without having to hard code any initalization. > > It seems that your patch is not removing > rte_eth_ring_pair_create/rte_eth_ring_pair_attach so I'm not sure you can > dynamically change the PMD in this case. > Ew, I had missed those calls. Yes, those should be encapsulated as some driver ops or some such. I'll look at that when I rebase. Regardless however, I didn't mean to state that pmds could be switched while running, only that the pmd to use could be specified at run time. Though, you're correct, pmd_ring doesn't seem to hold in line with the other pmds in their isolation. > > > Neil, next time, don't hesitate to discuss the design approaches before > > > doing such big changes. By the way, your patches have to be reviewed > > > carefully because there are other insteresting changes. > > > > I didn't hesitate, Im happy to reach out and discuss large changes, I just > > thought I would do so with code in hand (this change set only took a few > > days to write). I think my major failing was to assume that the git tree > > was reasonably up to date with the mailing list. I joined the mailing list > > about a month ago (2 weeks after this patch series went up). About a week > > ago I started tinkering with this, under the impression that what was in > > the git tree (having seem my assembly patch go in) was reasonably current > > with the mailing list. Having a patch sit on a mailing list without comment > > for a month is not condusive to doing upstream development. Checking the > > mailing list for prior work isn't hel
[dpdk-dev] Poor device abstraction's
On Fri, Apr 11, 2014 at 10:33:31AM -0700, Stephen Hemminger wrote: > One of my pet peeve's is that the device driver config does not abstract > the properties of the Ethernet device. The existing parameters match those > of Intel's Ethernet hardware but not much else. It also makes it hard > to write generic applications. If the application has to query the > device driver name string and insert different parameters for igb, igbvf, > ixgbe > and vmxnet3 then the API was designed wrong. > I agree. I think the patches that recently got integrated from Olivier are a step toward fixing that, but theres some more work to be done. Neil > Specific examples: > * the "descriptors" argument to rx/tx is interpreted as a hardware resource > not the number of packets. An application really wants to say "you may > buffer > up to 100us of packets" not have to guess what the underlying driver does. > > * the rthresh/wthresh/pthresh are PCI device artifacts and correct value is > different for each HW device shouldn't be exposed to application. The API > should be something like "device may burst up to N packets and/or T > latency". > > These seems like issues of a transition from a cool toy to talk to Intel > hardware > to a useful application infrastructure. > > That is why I would hate to see the existing Intel device centric API frozen. >
[dpdk-dev] Poor device abstraction's
Agree that the patch sets are a step towards fixing that, but there is a lot more to be done on this. Could we start discussion on what the "ideal" abstraction should be? I'd like to pool those into a formal proposal that we can discuss and drive through a series of patches to make that happen. Even semi-freezing anything prior to that would be premature. -Venky -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Neil Horman Sent: Friday, April 11, 2014 10:47 AM To: Stephen Hemminger Cc: dev at dpdk.org Subject: Re: [dpdk-dev] Poor device abstraction's On Fri, Apr 11, 2014 at 10:33:31AM -0700, Stephen Hemminger wrote: > One of my pet peeve's is that the device driver config does not > abstract the properties of the Ethernet device. The existing > parameters match those of Intel's Ethernet hardware but not much else. > It also makes it hard to write generic applications. If the > application has to query the device driver name string and insert > different parameters for igb, igbvf, ixgbe and vmxnet3 then the API was > designed wrong. > I agree. I think the patches that recently got integrated from Olivier are a step toward fixing that, but theres some more work to be done. Neil > Specific examples: > * the "descriptors" argument to rx/tx is interpreted as a hardware resource > not the number of packets. An application really wants to say "you may > buffer > up to 100us of packets" not have to guess what the underlying driver does. > > * the rthresh/wthresh/pthresh are PCI device artifacts and correct value is > different for each HW device shouldn't be exposed to application. The API > should be something like "device may burst up to N packets and/or T > latency". > > These seems like issues of a transition from a cool toy to talk to > Intel hardware to a useful application infrastructure. > > That is why I would hate to see the existing Intel device centric API frozen. >
[dpdk-dev] Poor device abstraction's
On Fri, Apr 11, 2014 at 05:57:41PM +, Venkatesan, Venky wrote: > Agree that the patch sets are a step towards fixing that, but there is a lot > more to be done on this. Could we start discussion on what the "ideal" > abstraction should be? I'd like to pool those into a formal proposal that we > can discuss and drive through a series of patches to make that happen. Even > semi-freezing anything prior to that would be premature. > Well, just to throw something out there, what about starting with the net_device structure in the kernel, and removing things that are unnecessecary? That might give us a good starting point to see what else is needed Neil > -Venky > > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman > Sent: Friday, April 11, 2014 10:47 AM > To: Stephen Hemminger > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] Poor device abstraction's > > On Fri, Apr 11, 2014 at 10:33:31AM -0700, Stephen Hemminger wrote: > > One of my pet peeve's is that the device driver config does not > > abstract the properties of the Ethernet device. The existing > > parameters match those of Intel's Ethernet hardware but not much else. > > It also makes it hard to write generic applications. If the > > application has to query the device driver name string and insert > > different parameters for igb, igbvf, ixgbe and vmxnet3 then the API was > > designed wrong. > > > I agree. I think the patches that recently got integrated from Olivier are a > step toward fixing that, but theres some more work to be done. > > Neil > > > Specific examples: > > * the "descriptors" argument to rx/tx is interpreted as a hardware > > resource > > not the number of packets. An application really wants to say "you may > > buffer > > up to 100us of packets" not have to guess what the underlying driver > > does. > > > > * the rthresh/wthresh/pthresh are PCI device artifacts and correct value > > is > > different for each HW device shouldn't be exposed to application. The > > API > > should be something like "device may burst up to N packets and/or T > > latency". > > > > These seems like issues of a transition from a cool toy to talk to > > Intel hardware to a useful application infrastructure. > > > > That is why I would hate to see the existing Intel device centric API > > frozen. > > >
[dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman > Sent: Friday, April 11, 2014 6:45 PM > To: Thomas Monjalon > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API > > On Fri, Apr 11, 2014 at 06:18:08PM +0200, Thomas Monjalon wrote: > > 2014-04-11 11:50, Neil Horman: > > > > It seems that your patch is not removing > > rte_eth_ring_pair_create/rte_eth_ring_pair_attach so I'm not sure you > > can dynamically change the PMD in this case. > > > Ew, I had missed those calls. Yes, those should be encapsulated as some > driver > ops or some such. I'll look at that when I rebase. Regardless however, I > didn't > mean to state that pmds could be switched while running, only that the pmd to > use could be specified at run time. Though, you're correct, pmd_ring doesn't > seem to hold in line with the other pmds in their isolation. > The ring PMD is probably best treated separately from the other PMDs as it's not really a device poll-mode driver. Instead, it's a general library that presents an API to make a ring, or set of rings, appear as a poll-mode driver ethdev. The EAL command to have one created at startup time was just an addon after-the-fact in case someone might find it useful :-). However, it's primary purpose was to allow applications to be written which could use physical NICs or rings interchangeably. For example, an app with multiple stages in a pipeline, where each stage just reads from an ethdev without caring if it's actually reading from a port or from packets sent from another lcore/function etc. Another example might be where an application wishes to sometimes loop packets back to itself, in this case it uses the C API to create an additional ring ethdev which it uses as output port for any packets it wants looped back - no special handling needed, everything is an ethdev to it on which it calls rx_burst or tx_burst. It's also likely that in future we will develop other libraries which wish to present their functionality via rx_burst/tx_burst functions i.e. as an ethdev. Regards, /Bruce
[dpdk-dev] [PATCH] rte_pmd_init_all: initialize non-PCI PMDs provided by EAL
On Fri, Apr 11, 2014 at 03:23:27PM +0200, Thomas Monjalon wrote: > Hi John, > > 2014-04-10 10:41, John W. Linville: > > These PMDs were being initialized by the EAL layer, but many apps were > > relying on the return value of rte_pmd_init_all to indicate that > > ethernet interfaces were available for use. Move the initialization of > > the non-PCI PMDs to this centralized function to have all of the PMDs > > treated equally. > > > > Signed-off-by: John W. Linville > > We are using constuctors to initialize these drivers. See the patches from > Olivier Matz. > The function rte_pmd_init_all() should be removed. So long as you make DPDK-based apps not die when only using non-PCI (i.e. "virtual") PMDs, I'll be happy... -- John W. LinvilleSomeday the world will need a hero, and you linville at tuxdriver.com might be all we have. Be ready.
