[dpdk-dev] How to test DPDK QoS sched example app
Sorry I found it. it was my mistake. You can ignore the mail Regards On Thu, Nov 19, 2015 at 3:23 PM, Incognito Man wrote: > Hi > > I've 2 boxes connected back to back. One box runs qos_sched example > app on IGB network card. I've been trying to > test the qos_sched app but I could not able to do it probably i > missing more than something. > > Could you please let me know how do i verify qos_sched app > > > > Regards > >
[dpdk-dev] [PATCH RFC v2 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
The kernel fills new allocated (huge) pages with zeros.
DPDK just has to touch the pages to trigger the allocation.
Signed-off-by: Zhihong Wang
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 0de75cd..21a5146 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -399,8 +399,10 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl,
return -1;
}
+ /* map the segment, and populate page tables,
+* the kernel fills this segment with zeros */
virtaddr = mmap(vma_addr, hugepage_sz, PROT_READ | PROT_WRITE,
- MAP_SHARED, fd, 0);
+ MAP_SHARED | MAP_POPULATE, fd, 0);
if (virtaddr == MAP_FAILED) {
RTE_LOG(ERR, EAL, "%s(): mmap failed: %s\n", __func__,
strerror(errno));
@@ -410,7 +412,6 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl,
if (orig) {
hugepg_tbl[i].orig_va = virtaddr;
- memset(virtaddr, 0, hugepage_sz);
}
else {
hugepg_tbl[i].final_va = virtaddr;
@@ -529,22 +530,16 @@ remap_all_hugepages(struct hugepage_file *hugepg_tbl,
struct hugepage_info *hpi)
old_addr = vma_addr;
- /* map new, bigger segment */
+ /* map new, bigger segment, and populate page tables,
+* the kernel fills this segment with zeros */
vma_addr = mmap(vma_addr, total_size,
- PROT_READ | PROT_WRITE, MAP_SHARED, fd,
0);
+ PROT_READ | PROT_WRITE, MAP_SHARED |
MAP_POPULATE, fd, 0);
if (vma_addr == MAP_FAILED || vma_addr != old_addr) {
RTE_LOG(ERR, EAL, "%s(): mmap failed: %s\n",
__func__, strerror(errno));
close(fd);
return -1;
}
-
- /* touch the page. this is needed because kernel
postpones mapping
-* creation until the first page fault. with this, we
pin down
-* the page and it is marked as used and gets into
process' pagemap.
-*/
- for (offset = 0; offset < total_size; offset +=
hugepage_sz)
- *((volatile uint8_t*) RTE_PTR_ADD(vma_addr,
offset));
}
/* set shared flock on the file. */
@@ -592,9 +587,6 @@ remap_all_hugepages(struct hugepage_file *hugepg_tbl,
struct hugepage_info *hpi)
}
}
- /* zero out the whole segment */
- memset(hugepg_tbl[page_idx].final_va, 0, total_size);
-
page_idx++;
}
--
2.5.0
[dpdk-dev] [PATCH RFC v2 1/2] lib/librte_eal: Reduce timer initialization time
Changing from 1/2 second to 1/10 doesn't compromise the precision, and a 4/10
second is worth saving.
Signed-off-by: Zhihong Wang
---
lib/librte_eal/linuxapp/eal/eal_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_timer.c
b/lib/librte_eal/linuxapp/eal/eal_timer.c
index e0642de..4de0353 100644
--- a/lib/librte_eal/linuxapp/eal/eal_timer.c
+++ b/lib/librte_eal/linuxapp/eal/eal_timer.c
@@ -271,7 +271,7 @@ get_tsc_freq(void)
#ifdef CLOCK_MONOTONIC_RAW
#define NS_PER_SEC 1E9
- struct timespec sleeptime = {.tv_nsec = 5E8 }; /* 1/2 second */
+ struct timespec sleeptime = {.tv_nsec = 1E8 }; /* 1/10 second */
struct timespec t_start, t_end;
uint64_t tsc_hz;
--
2.5.0
[dpdk-dev] [PATCH RFC v2 0/2] Reduce DPDK initialization time
This RFC patch aims to reduce DPDK initialization time, which is important in cases such as micro service. Changes are: 1. Reduce timer initialization time 2. Remove unnecessary hugepage zero-filling operations With this patch: 1. Timer initialization time can be reduced by 4/10 second 2. Memory initialization time can be reduced nearly by half The 2nd topic has been brought up before in this thread: http://dpdk.org/dev/patchwork/patch/4219/ -- Changes in v2: 1. Use MAP_POPULATE flag to populate page tables 2. Add comments to avoid future misunderstanding Zhihong Wang (2): lib/librte_eal: Reduce timer initialization time lib/librte_eal: Remove unnecessary hugepage zero-filling lib/librte_eal/linuxapp/eal/eal_memory.c | 20 ++-- lib/librte_eal/linuxapp/eal/eal_timer.c | 2 +- 2 files changed, 7 insertions(+), 15 deletions(-) -- 2.5.0
[dpdk-dev] [RFC PATCH 2/2] virtio: Extend virtio-net PMD to support container environment
The patch extends virtio-net PMD to work on host. Actually, we don't have virtio-net devices on host. Thus, this PMD called "cvio PMD" is for virtual device. To prepare virtio-net device on host, the users need to invoke QEMU process in special qtest mode. In this mode, no guest runs. Also, this mode is mainly used for testing QEMU devices from outer process. Here is example of command line. $ qemu-system-x86_64 -machine accel=qtest -display none \ -qtest unix:/tmp/qtest.sock,server \ -netdev type=tap,script=/etc/qemu-ifup,id=net0 \ -device virtio-net-pci,netdev=net0 \ -chardev socket,id=chr0,path=/tmp/ivshmem.sock,server \ -device ivshmem,size=1G,chardev=chr0,vectors=1 After invoking QEMU, cvio PMD can connect to QEMU process using unix domain sockets. Over these sockets, virtio-net device and ivshmem device in QEMU are probed by cvio PMD. Here is example of command line. $ testpmd -c f -n 1 -m 1024 --shm \ --vdev="eth_cvio0,qtest=/tmp/qtest.sock,ivshmem=/tmp/ivshmem.sock" \ -- --disable-hw-vlan --txqflags=0xf00 -i Please specify same unix domain sockets and memory size in both command lines like above. Also, "--shm" option is needed for cvio PMD like above. This option creates one hugepage file on hugetlbfs. It means we need enough contiguous memory. If there is no enough contiguous memory, initialization will be failed. This contiguous memory is used for sharing memory between DPDK application and ivshmem device in QEMU. Signed-off-by: Tetsuya Mukawa --- config/common_linuxapp | 5 + drivers/net/virtio/Makefile| 4 + drivers/net/virtio/qtest.c | 590 + drivers/net/virtio/virtio_ethdev.c | 214 -- drivers/net/virtio/virtio_ethdev.h | 16 + drivers/net/virtio/virtio_pci.h| 25 ++ 6 files changed, 833 insertions(+), 21 deletions(-) create mode 100644 drivers/net/virtio/qtest.c diff --git a/config/common_linuxapp b/config/common_linuxapp index 7248262..11e8fd1 100644 --- a/config/common_linuxapp +++ b/config/common_linuxapp @@ -478,3 +478,8 @@ CONFIG_RTE_APP_TEST=y CONFIG_RTE_TEST_PMD=y CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n + +# +# Enable virtio support for container +# +CONFIG_RTE_VIRTIO_VDEV=n diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile index 43835ba..5d6f69c 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_VIRTIO_VDEV),y) + SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += qtest.c +endif + # this lib depends upon: DEPDIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += lib/librte_eal lib/librte_ether DEPDIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += lib/librte_mempool lib/librte_mbuf diff --git a/drivers/net/virtio/qtest.c b/drivers/net/virtio/qtest.c new file mode 100644 index 000..005fa24 --- /dev/null +++ b/drivers/net/virtio/qtest.c @@ -0,0 +1,590 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2015 IGEL Co., Ltd. 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 IGEL Co., Ltd. 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
[dpdk-dev] [RFC PATCH 1/2] EAL: Add new EAL "--shm" option.
The patch adds new EAL "--shm" option. If the option is specified,
EAL will allocate one file from hugetlbfs. This memory is for sharing
memory between DPDK applicaiton and QEMU ivhsmem device.
Signed-off-by: Tetsuya Mukawa
---
lib/librte_eal/common/eal_common_options.c | 5 +++
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h| 2 +
lib/librte_eal/common/include/rte_memory.h | 5 +++
lib/librte_eal/linuxapp/eal/eal_memory.c | 71 ++
5 files changed, 84 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 79db608..67b4e52 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -82,6 +82,7 @@ eal_long_options[] = {
{OPT_NO_HUGE, 0, NULL, OPT_NO_HUGE_NUM },
{OPT_NO_PCI,0, NULL, OPT_NO_PCI_NUM },
{OPT_NO_SHCONF, 0, NULL, OPT_NO_SHCONF_NUM},
+ {OPT_SHM, 0, NULL, OPT_SHM_NUM },
{OPT_PCI_BLACKLIST, 1, NULL, OPT_PCI_BLACKLIST_NUM},
{OPT_PCI_WHITELIST, 1, NULL, OPT_PCI_WHITELIST_NUM},
{OPT_PROC_TYPE, 1, NULL, OPT_PROC_TYPE_NUM},
@@ -723,6 +724,10 @@ eal_parse_common_option(int opt, const char *optarg,
conf->no_hugetlbfs = 1;
break;
+ case OPT_SHM_NUM:
+ conf->shm = 1;
+ break;
+
case OPT_NO_PCI_NUM:
conf->no_pci = 1;
break;
diff --git a/lib/librte_eal/common/eal_internal_cfg.h
b/lib/librte_eal/common/eal_internal_cfg.h
index 5f1367e..362ce12 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -66,6 +66,7 @@ struct internal_config {
volatile unsigned no_hugetlbfs; /**< true to disable hugetlbfs */
unsigned hugepage_unlink; /**< true to unlink backing files */
volatile unsigned xen_dom0_support; /**< support app running on Xen
Dom0*/
+ volatile unsigned shm;/**< true to create shared memory for
ivshmem */
volatile unsigned no_pci; /**< true to disable PCI */
volatile unsigned no_hpet;/**< true to disable HPET */
volatile unsigned vmware_tsc_map; /**< true to use VMware TSC mapping
diff --git a/lib/librte_eal/common/eal_options.h
b/lib/librte_eal/common/eal_options.h
index 4245fd5..263b4f8 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -55,6 +55,8 @@ enum {
OPT_HUGE_DIR_NUM,
#define OPT_HUGE_UNLINK "huge-unlink"
OPT_HUGE_UNLINK_NUM,
+#define OPT_SHM "shm"
+ OPT_SHM_NUM,
#define OPT_LCORES"lcores"
OPT_LCORES_NUM,
#define OPT_LOG_LEVEL "log-level"
diff --git a/lib/librte_eal/common/include/rte_memory.h
b/lib/librte_eal/common/include/rte_memory.h
index 1bed415..9c1effc 100644
--- a/lib/librte_eal/common/include/rte_memory.h
+++ b/lib/librte_eal/common/include/rte_memory.h
@@ -100,6 +100,7 @@ struct rte_memseg {
int32_t socket_id; /**< NUMA socket ID. */
uint32_t nchannel; /**< Number of channels. */
uint32_t nrank; /**< Number of ranks. */
+ int fd; /**< fd used for share this memory */
#ifdef RTE_LIBRTE_XEN_DOM0
/**< store segment MFNs */
uint64_t mfn[DOM0_NUM_MEMBLOCK];
@@ -128,6 +129,10 @@ int rte_mem_lock_page(const void *virt);
*/
phys_addr_t rte_mem_virt2phy(const void *virt);
+
+int
+rte_memseg_info_get(int index, int *pfd, uint64_t *psize, void **paddr);
+
/**
* Get the layout of the available physical memory.
*
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 657d19f..c46c2cf 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -143,6 +143,21 @@ rte_mem_lock_page(const void *virt)
return mlock((void*)aligned, page_size);
}
+int
+rte_memseg_info_get(int index, int *pfd, uint64_t *psize, void **paddr)
+{
+ struct rte_mem_config *mcfg;
+ mcfg = rte_eal_get_configuration()->mem_config;
+
+ if (pfd != NULL)
+ *pfd = mcfg->memseg[index].fd;
+ if (psize != NULL)
+ *psize = (uint64_t)mcfg->memseg[index].len;
+ if (paddr != NULL)
+ *paddr = (void *)(uint64_t)mcfg->memseg[index].addr;
+ return 0;
+}
+
/*
* Get physical address of any mapped virtual address in the current process.
*/
@@ -1068,6 +1083,41 @@ calc_num_pages_per_socket(uint64_t * memory,
return total_num_pages;
}
+static void *
+rte_eal_shm_create(int *pfd, const char *hugedir)
+{
+ int ret, fd;
+ char filepath[256];
+ void *vaddr;
+ uint64_t size = internal_config.memory;
+
+
[dpdk-dev] [RFC PATCH 0/2] Virtio-net PMD Extension to work on host.
THIS IS A PoC IMPLEMENATION. [Abstraction] Normally, virtio-net PMD only works on VM, because there is no virtio-net device on host. This RFC patch extends virtio-net PMD to be able to work on host as virtual PMD. But we didn't implement virtio-net device as a part of virtio-net PMD. To prepare virtio-net device for the PMD, start QEMU process with special QTest mode, then connect it from virtio-net PMD through unix domain socket. The PMD can connect to anywhere QEMU virtio-net device can. For example, the PMD can connects to vhost-net kernel module and vhost-user backend application. Similar to virtio-net PMD on QEMU, application memory that uses virtio-net PMD will be shared between vhost backend application. But vhost backend application memory will not be shared. Main target of this PMD is container like docker, rkt, lxc and etc. We can isolate related processes(virtio-net PMD process, QEMU and vhost-user backend process) by container. But, to communicate through unix domain socket, shared directory will be needed. [How to use] So far, we need QEMU patch to connect to vhost-user backend. Please check known issue in later section. Because of this, I will describe example of using vhost-net kernel module. - Compile Set "CONFIG_RTE_VIRTIO_VDEV=y" in config/common_linux. Then compile it. - Start QEMU like below. $ sudo qemu-system-x86_64 -qtest unix:/tmp/qtest0,server -machine accel=qtest \ -display none -qtest-log /dev/null \ -netdev type=tap,script=/etc/qemu-ifup,id=net0,vhost=on \ -device virtio-net-pci,netdev=net0 \ -chardev socket,id=chr1,path=/tmp/ivshmem0,server \ -device ivshmem,size=1G,chardev=chr1,vectors=1 - Start DPDK application like below $ sudo ./testpmd -c f -n 1 -m 1024 --shm \ --vdev="eth_cvio0,qtest=/tmp/qtest0,ivshmem=/tmp/ivshmem0" -- \ --disable-hw-vlan --txqflags=0xf00 -i - Check created tap device. (*1) Please Specify same memory size in QEMU and DPDK command line. [Detailed Description] - virtio-net device implementation The PMD uses QEMU virtio-net device. To do that, QEMU QTest functionality is used. QTest is a test framework of QEMU devices. It allows us to implement a device driver outside of QEMU. With QTest, we can implement DPDK application and virtio-net PMD as standalone process on host. When QEMU is invoked as QTest mode, any guest code will not run. To know more about QTest, see below. http://wiki.qemu.org/Features/QTest - probing devices QTest provides a unix domain socket. Through this socket, driver process can access to I/O port and memory of QEMU virtual machine. The PMD will send I/O port accesses to probe pci devices. If we can find virtio-net and ivshmem device, initialize the devices. Also, I/O port accesses of virtio-net PMD will be sent through socket, and virtio-net PMD can initialize vitio-net device on QEMU correctly. - ivshmem device to share memory To share memory that virtio-net PMD process uses, ivshmem device will be used. Because ivshmem device can only handle one file descriptor, shared memory should be consist of one file. To allocate such a memory, EAL has new option called "--shm". If the option is specified, EAL will open a file and allocate memory from hugepages. While initializing ivshmem device, we can set BAR(Base Address Register). It represents which memory QEMU vcpu can access to this shared memory. We will specify host physical address of shared memory as this address. It is very useful because we don't need to apply patch to QEMU to calculate address offset. (For example, if virtio-net PMD process will allocate memory from shared memory, then specify the physical address of it to virtio-net register, QEMU virtio-net device can understand it without calculating address offset.) - Known limitation So far, the PMD doesn't handle interrupts from QEMU devices. Because of this, VIRTIO_NET_F_STATUS functionality is dropped. But without it, we can use all virtio-net functions. - Known issues So far, to use vhost-user, we need to apply vhost-user patch to QEMU and DPDK vhost library. This is because, QEMU will not send memory information and file descriptor of ivshmem device to vhost-user backend. (Anyway, vhost-net kernel module can receive the information. So vhost-user behavior will not be correct. I will submit the patch to QEMU soon) Also, we may have an issue in DPDK vhost library to handle kickfd and callfd. The patch for it is needed. (Let me check it more) If someone wants to check vhost-user behavior, I will describe it more in later email. [Addition] We can apply same manner to handle any kind of QEMU devices from DPDK application. So far, I don't have any ideas except for virtio-net device. But someone would have. Tetsuya Mukawa (2): EAL: Add new EAL "--shm" option. virtio: Extend virtio-net PMD to
[dpdk-dev] [PATCH] hash: replace libc memcmp with optimized memory compare functions for arm64
The following measurements shows improvement over the default
libc memcmp function
Length(B) by X% over libc memcmp
16 149.57%
32 122.7%
48 104.96%
64 98.21%
80 93.75%
96 90.55%
112 110.48%
128 137.24%
Signed-off-by: Jerin Jacob
---
lib/librte_hash/rte_cmp_arm64.h | 114 ++
lib/librte_hash/rte_cuckoo_hash.c | 7 ++-
2 files changed, 120 insertions(+), 1 deletion(-)
create mode 100644 lib/librte_hash/rte_cmp_arm64.h
diff --git a/lib/librte_hash/rte_cmp_arm64.h b/lib/librte_hash/rte_cmp_arm64.h
new file mode 100644
index 000..6fd937b
--- /dev/null
+++ b/lib/librte_hash/rte_cmp_arm64.h
@@ -0,0 +1,114 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Cavium networks. 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 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.
+ */
+
+/* Functions to compare multiple of 16 byte keys (up to 128 bytes) */
+static int
+rte_hash_k16_cmp_eq(const void *key1, const void *key2,
+ size_t key_len __rte_unused)
+{
+ uint64_t x0, x1, y0, y1;
+
+ asm volatile(
+ "ldp %x[x1], %x[x0], [%x[p1]]"
+ : [x1]"=r"(x1), [x0]"=r"(x0)
+ : [p1]"r"(key1)
+ );
+ asm volatile(
+ "ldp %x[y1], %x[y0], [%x[p2]]"
+ : [y1]"=r"(y1), [y0]"=r"(y0)
+ : [p2]"r"(key2)
+ );
+ x0 ^= y0;
+ x1 ^= y1;
+ return !(x0 == 0 && x1 == 0);
+}
+
+static int
+rte_hash_k32_cmp_eq(const void *key1, const void *key2, size_t key_len)
+{
+ return rte_hash_k16_cmp_eq(key1, key2, key_len) ||
+ rte_hash_k16_cmp_eq((const char *) key1 + 16,
+ (const char *) key2 + 16, key_len);
+}
+
+static int
+rte_hash_k48_cmp_eq(const void *key1, const void *key2, size_t key_len)
+{
+ return rte_hash_k16_cmp_eq(key1, key2, key_len) ||
+ rte_hash_k16_cmp_eq((const char *) key1 + 16,
+ (const char *) key2 + 16, key_len) ||
+ rte_hash_k16_cmp_eq((const char *) key1 + 32,
+ (const char *) key2 + 32, key_len);
+}
+
+static int
+rte_hash_k64_cmp_eq(const void *key1, const void *key2, size_t key_len)
+{
+ return rte_hash_k32_cmp_eq(key1, key2, key_len) ||
+ rte_hash_k32_cmp_eq((const char *) key1 + 32,
+ (const char *) key2 + 32, key_len);
+}
+
+static int
+rte_hash_k80_cmp_eq(const void *key1, const void *key2, size_t key_len)
+{
+ return rte_hash_k64_cmp_eq(key1, key2, key_len) ||
+ rte_hash_k16_cmp_eq((const char *) key1 + 64,
+ (const char *) key2 + 64, key_len);
+}
+
+static int
+rte_hash_k96_cmp_eq(const void *key1, const void *key2, size_t key_len)
+{
+ return rte_hash_k64_cmp_eq(key1, key2, key_len) ||
+ rte_hash_k32_cmp_eq((const char *) key1 + 64,
+ (const char *) key2 + 64, key_len);
+}
+
+static int
+rte_hash_k112_cmp_eq(const void *key1, const void *key2, size_t key_len)
+{
+ return rte_hash_k64_cmp_eq(key1, key2, key_len) ||
+ rte_hash_k32_cmp_eq((const char *) key1 + 64,
+ (const char *) key2 + 64, key_len) ||
+ rte_hash_k16_cmp_eq((const char *) key1 + 96,
+ (const char *)
[dpdk-dev] DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5
Thanks Rashmin for the response. The error code is -1 and the box I am doing my experiments is Cisco B200-M3 which would support CISCO VNIC 1240 or 1340 NIC. The NIC is in hypervisor but what puzzles me is if there is no dependency with ESX the NIC initialization should have passed in both ESX versions 5.5 and 6.0. Error is rte_eth_dev_start error = -1 Regards Suyash -Original Message- From: Patel, Rashmin N [mailto:rashmin.n.pa...@intel.com] Sent: Thursday, November 19, 2015 11:50 PM To: Karmarkar Suyash ; dev at dpdk.org Subject: RE: DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5 What is the error code it failed with? There is no dependency between ESXi and DPDK versions as such. But depending your VM settings, it may pop up some issues related to memory assigned to VM. When you use NIC in Hypervisor and feed packets to VM via Vmxnet3, the guest OS can use Vmxnet3-pmd and that's the sole requirement. Guest OS or DPDK API in VM are unaware and independent of the physical NIC beneath. When you use NIC in VM via Passthrough (or device direct assignment,) the guest OS can use ixgbe-pmd/igb-pmd/xyz-pmd to control them for Rx/Tx operations. ESXi can't look into such device operations like it can't see packets coming in or going out. When you enable SRIOV on a NIC, you get a PF and multiple VFs and if you use a NIC-Virtual Function via passthrough, the guest OS can use respective pmd (ixgbevf/igbvf/xyzvf) in DPDK API to control it for Rx/Tx ops. ESXi control the Physical Function through a respective driver (ixgbe/igb/xyz provided with ESXi) DPDK API doesn't have support to run in ESXi to control that PF. Thanks, Rashmin -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Karmarkar Suyash Sent: Wednesday, November 18, 2015 8:34 PM To: dev at dpdk.org Subject: [dpdk-dev] DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5 Hello All, I am trying some experiments with DPDK 1.6 and Cisco NIC - (:06:00.0 Network controller: Cisco Systems Inc. Cisco VIC Ethernet NIC [vmnic0]), on the guest I am using VMXNET3 as interface/pmd and one weird behavior that is see is with VMWare ESX 5.5 DPDK is not able to initialize the NIC and I get the error rte_eth_dev_start failed with error code as, but same NIC and with DPDK 1.6 version works fine with VMWare ESX 6.0 and with VMXNET3 PMD. Two questions: 1. Is there any dependency with VMWare version ESX (5.0/5.1/6.0) with DPDK Release version (1.6/1.7/2.x)? If yes can you please let me know? 2. If we are not using the NIC in pass-through mode and we are using it via Hypervisor - vmxnet3 or virtio pmd is there still a dependency for the list of NIC's supported by DPDK? Regards Suyash
[dpdk-dev] DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5
What is the error code it failed with? There is no dependency between ESXi and DPDK versions as such. But depending your VM settings, it may pop up some issues related to memory assigned to VM. When you use NIC in Hypervisor and feed packets to VM via Vmxnet3, the guest OS can use Vmxnet3-pmd and that's the sole requirement. Guest OS or DPDK API in VM are unaware and independent of the physical NIC beneath. When you use NIC in VM via Passthrough (or device direct assignment,) the guest OS can use ixgbe-pmd/igb-pmd/xyz-pmd to control them for Rx/Tx operations. ESXi can't look into such device operations like it can't see packets coming in or going out. When you enable SRIOV on a NIC, you get a PF and multiple VFs and if you use a NIC-Virtual Function via passthrough, the guest OS can use respective pmd (ixgbevf/igbvf/xyzvf) in DPDK API to control it for Rx/Tx ops. ESXi control the Physical Function through a respective driver (ixgbe/igb/xyz provided with ESXi) DPDK API doesn't have support to run in ESXi to control that PF. Thanks, Rashmin -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Karmarkar Suyash Sent: Wednesday, November 18, 2015 8:34 PM To: dev at dpdk.org Subject: [dpdk-dev] DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5 Hello All, I am trying some experiments with DPDK 1.6 and Cisco NIC - (:06:00.0 Network controller: Cisco Systems Inc. Cisco VIC Ethernet NIC [vmnic0]), on the guest I am using VMXNET3 as interface/pmd and one weird behavior that is see is with VMWare ESX 5.5 DPDK is not able to initialize the NIC and I get the error rte_eth_dev_start failed with error code as, but same NIC and with DPDK 1.6 version works fine with VMWare ESX 6.0 and with VMXNET3 PMD. Two questions: 1. Is there any dependency with VMWare version ESX (5.0/5.1/6.0) with DPDK Release version (1.6/1.7/2.x)? If yes can you please let me know? 2. If we are not using the NIC in pass-through mode and we are using it via Hypervisor - vmxnet3 or virtio pmd is there still a dependency for the list of NIC's supported by DPDK? Regards Suyash
[dpdk-dev] [PATCH v2] vhost: Fix reset_owner message handling not to clear callfd
The patch fixes reset_owner message handling not to clear callfd,
because callfd will be valid while connection is establihed.
Signed-off-by: Tetsuya Mukawa
---
lib/librte_vhost/virtio-net.c | 44 +--
1 file changed, 38 insertions(+), 6 deletions(-)
diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index 886c104..3907fb5 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -223,9 +223,9 @@ add_config_ll_entry(struct virtio_net_config_ll *new_ll_dev)
}
static void
-cleanup_vq(struct vhost_virtqueue *vq)
+cleanup_vq(struct vhost_virtqueue *vq, int destroy)
{
- if (vq->callfd >= 0)
+ if ((vq->callfd >= 0) && (destroy != 0))
close(vq->callfd);
if (vq->kickfd >= 0)
close(vq->kickfd);
@@ -249,8 +249,8 @@ cleanup_device(struct virtio_net *dev)
}
for (i = 0; i < dev->virt_qp_nb; i++) {
- cleanup_vq(dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ]);
- cleanup_vq(dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_TXQ]);
+ cleanup_vq(dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ], 1);
+ cleanup_vq(dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_TXQ], 1);
}
}
@@ -322,6 +322,25 @@ init_vring_queue_pair(struct virtio_net *dev, uint32_t
qp_idx)
init_vring_queue(dev->virtqueue[base_idx + VIRTIO_TXQ], qp_idx);
}
+static void
+reset_vring_queue(struct vhost_virtqueue *vq, int qp_idx)
+{
+ int callfd;
+
+ callfd = vq->callfd;
+ init_vring_queue(vq, qp_idx);
+ vq->callfd = callfd;
+}
+
+static void
+reset_vring_queue_pair(struct virtio_net *dev, uint32_t qp_idx)
+{
+ uint32_t base_idx = qp_idx * VIRTIO_QNUM;
+
+ reset_vring_queue(dev->virtqueue[base_idx + VIRTIO_RXQ], qp_idx);
+ reset_vring_queue(dev->virtqueue[base_idx + VIRTIO_TXQ], qp_idx);
+}
+
static int
alloc_vring_queue_pair(struct virtio_net *dev, uint32_t qp_idx)
{
@@ -362,7 +381,7 @@ reset_device(struct virtio_net *dev)
dev->flags = 0;
for (i = 0; i < dev->virt_qp_nb; i++)
- init_vring_queue_pair(dev, i);
+ reset_vring_queue_pair(dev, i);
}
/*
@@ -467,6 +486,7 @@ static int
reset_owner(struct vhost_device_ctx ctx)
{
struct virtio_net *dev;
+ uint32_t i;
dev = get_device(ctx);
if (dev == NULL)
@@ -475,7 +495,19 @@ reset_owner(struct vhost_device_ctx ctx)
if (dev->flags & VIRTIO_DEV_RUNNING)
notify_destroy_device(dev);
- cleanup_device(dev);
+ /* Unmap QEMU memory file if mapped. */
+ if (dev->mem) {
+ munmap((void *)(uintptr_t)dev->mem->mapped_address,
+ (size_t)dev->mem->mapped_size);
+ free(dev->mem);
+ dev->mem = NULL;
+ }
+
+ for (i = 0; i < dev->virt_qp_nb; i++) {
+ cleanup_vq(dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ], 0);
+ cleanup_vq(dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_TXQ], 0);
+ }
+
reset_device(dev);
return 0;
}
--
2.1.4
[dpdk-dev] [PATCH] eal: fix compile error for old glibc caused by pthread_setname_np()
Fixes: 67b6d3039e9e ("eal: set name to threads")
pthread_setname_np() function added in glibc 2.12, using this function
in older glibc versions cause compile error:
error: implicit declaration of function "pthread_setname_np"
This patch adds "rte_thread_setname" macro and set it according
glibc >= 2.12 check, thread naming disabled for older glibc versions,
glibc versions that support "pthread_setname_np" will keep using this
function.
Signed-off-by: Ferruh Yigit
---
examples/tep_termination/main.c| 2 +-
examples/vhost/main.c | 2 +-
examples/vhost_xen/main.c | 2 +-
lib/librte_eal/common/eal_thread.h | 6 ++
lib/librte_eal/linuxapp/eal/eal.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_timer.c| 2 +-
8 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/examples/tep_termination/main.c b/examples/tep_termination/main.c
index 2b67e64..f97d552 100644
--- a/examples/tep_termination/main.c
+++ b/examples/tep_termination/main.c
@@ -1249,7 +1249,7 @@ main(int argc, char *argv[])
if (ret != 0)
rte_exit(EXIT_FAILURE, "Cannot create print-stats
thread\n");
snprintf(thread_name, RTE_MAX_THREAD_NAME_LEN, "print-stats");
- ret = pthread_setname_np(tid, thread_name);
+ ret = rte_thread_setname(tid, thread_name);
if (ret != 0)
RTE_LOG(ERR, VHOST_CONFIG, "Cannot set print-stats
name\n");
}
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index c081b18..9bfda6d 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -3027,7 +3027,7 @@ main(int argc, char *argv[])
/* Set thread_name for aid in debugging. */
snprintf(thread_name, RTE_MAX_THREAD_NAME_LEN, "print-stats");
- ret = pthread_setname_np(tid, thread_name);
+ ret = rte_thread_setname(tid, thread_name);
if (ret != 0)
RTE_LOG(ERR, VHOST_CONFIG,
"Cannot set print-stats name\n");
diff --git a/examples/vhost_xen/main.c b/examples/vhost_xen/main.c
index 3fcc138..ca725f2 100644
--- a/examples/vhost_xen/main.c
+++ b/examples/vhost_xen/main.c
@@ -1510,7 +1510,7 @@ main(int argc, char *argv[])
/* Set thread_name for aid in debugging. */
snprintf(thread_name, RTE_MAX_THREAD_NAME_LEN,
"print-xen-stats");
- ret = pthread_setname_np(tid, thread_name);
+ ret = rte_thread_setname(tid, thread_name);
if (ret != 0)
RTE_LOG(ERR, VHOST_CONFIG,
"Cannot set print-stats name\n");
diff --git a/lib/librte_eal/common/eal_thread.h
b/lib/librte_eal/common/eal_thread.h
index e4e76b9..58e410d 100644
--- a/lib/librte_eal/common/eal_thread.h
+++ b/lib/librte_eal/common/eal_thread.h
@@ -36,6 +36,12 @@
#include
+#if __GLIBC_PREREQ(2, 12)
+#define rte_thread_setname(...) pthread_setname_np(__VA_ARGS__)
+#else
+#define rte_thread_setname(...) 0
+#endif
+
/**
* basic loop of thread, called for each thread by eal_init().
*
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 06536f2..635ec36 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -859,7 +859,7 @@ rte_eal_init(int argc, char **argv)
/* Set thread_name for aid in debugging. */
snprintf(thread_name, RTE_MAX_THREAD_NAME_LEN,
"lcore-slave-%d", i);
- ret = pthread_setname_np(lcore_config[i].thread_id,
+ ret = rte_thread_setname(lcore_config[i].thread_id,
thread_name);
if (ret != 0)
RTE_LOG(ERR, EAL,
diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
index 95beb4c..470d6a1 100644
--- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
+++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
@@ -887,7 +887,7 @@ rte_eal_intr_init(void)
/* Set thread_name for aid in debugging. */
snprintf(thread_name, RTE_MAX_THREAD_NAME_LEN,
"eal-intr-thread");
- ret_1 = pthread_setname_np(intr_thread, thread_name);
+ ret_1 = rte_thread_setname(intr_thread, thread_name);
if (ret_1 != 0)
RTE_LOG(ERR, EAL,
"Failed to set thread name for interrupt handling\n");
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
index 277565d..d9188fd 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
+++
[dpdk-dev] DPDK Community Call - ARM Support
Thank you Tim for addressing this. We are very interested in this activities. Our interest is having common API for our customer between various arch to ease the life of their sw developers. We are already writing code to contribute here. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of O'Driscoll, Tim Sent: Tuesday, November 17, 2015 11:09 AM To: dev at dpdk.org Subject: [dpdk-dev] DPDK Community Call - ARM Support There's been a lot of activity on the mailing list recently on DPDK support for ARM. It's great to see the project being enhanced to embrace a new architecture. We have seen some duplication of efforts on this, so we think it would make a good topic for a community call. This will give everybody a chance to share their plans so we can be clear on who's doing what and make sure that we avoid overlaps. We'll host a community call on this next Tuesday (24th Nov) at 15:00-16:00 GMT. Details on the proposed agenda, the time in a couple of other timezones, and how to join the online meeting are included below. Agenda: ARMv7 & v8 ports: - Summary of what's been submitted for 2.2 and what the remaining gaps are (Dave Hunt) - Discussion on plans for further contributions in this area External Memory Manager: - Summary of our plans for DPDK 2.3 (Venky Venkatesan) - Do others plan to do work in this area? Other DPDK/ARM plans: - Does anybody else have plans for ARM-related work in DPDK that they can share? When: Tue, Nov 24, 2015 15:00 - 16:00 GMT Tue, Nov 24, 2015 07:00 - 08:00 PST Tue, Nov 24, 2015 10:00 - 11:00 EST Tue, Nov 24, 2015 16:00 - 17:00 PST Meeting Details: You can join from your computer, tablet or smartphone: https://global.gotomeeting.com/join/535221101 You can also dial in using your phone. Access Code: 535-221-101 Phone numbers: United States: +1 (224) 501-3217 Australia: +61 2 9087 3605 Austria: +43 7 2088 1403 Belgium: +32 (0) 28 93 7019 Canada: +1 (647) 497-9351 Denmark: +45 69 91 88 64 Finland: +358 (0) 942 41 5781 France: +33 (0) 182 880 458 Germany: +49 (0) 692 5736 7210 Ireland +353 (0) 14 845 979 Italy: +39 0 553 98 95 67 Netherlands: +31 (0) 208 080 381 New Zealand: +64 4 974 7214 Norway: +47 21 03 58 98 Spain: +34 955 32 0845 Sweden: +46 (0) 853 527 836 Switzerland: +41 (0) 435 0167 09 United Kingdom: +44 (0) 330 221 0086
[dpdk-dev] [PATCH] Revert "eal: set name to threads"
On Thu, Nov 19, 2015 at 01:39:24PM +, Ferruh Yigit wrote: > On Thu, Nov 19, 2015 at 01:32:44PM +0100, Thomas Monjalon wrote: > > 2015-11-19 13:49, Panu Matilainen: > > > On 11/19/2015 01:22 PM, Ferruh Yigit wrote: > > > > This reverts commit 67b6d3039e9edbc4624c878c6930be5e126e8b58. > > > > > > > > Reverted patch uses pthread_setname_np() function, this function added > > > > into glibc in version 2.12 and cause a compile error in older glibc > > > > versions: > > > > error: implicit declaration of function "pthread_setname_np" > > > > > > > > Main purpose of reverted patch is to name threads, without > > > > pthread_setname_np() function, patch does not mean much, so reverting > > > > patch for sake of compatibility with older glibc versions. > > > > > > Debuggability is important too. Rather than revert, why not wrap it in > > > rte_thread_setname() or such and just make it a no-op with glibc > > > versions where pthread_setname_np() is not available? > > > > +1 > > Which means adding compile time glibc version check which I was trying to > avoid, > I believe we should not add glibc version dependencies unless feature is > really required, > but sure I can implement that way, will send v2. > I tried defining weak symbol within DPDK, and library already has strong version, this was nice try, thanks to Sergio, but this also does not work because how linker works, weak symbol in binary overrides the strong in shared library..
[dpdk-dev] [PATCH] vhost: Fix reset_owner message handling not to clear callfd
On 2015/11/19 16:03, Yuanhan Liu wrote:
> On Thu, Nov 19, 2015 at 03:23:26PM +0900, Tetsuya Mukawa wrote:
>> The patch fixes reset_owner message handling not to clear callfd,
>> because callfd will be valid while connection is establihed.
>>
>> Signed-off-by: Tetsuya Mukawa
>> ---
>> lib/librte_vhost/virtio-net.c | 21 -
>> 1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
>> index 886c104..ae1e4bd 100644
>> --- a/lib/librte_vhost/virtio-net.c
>> +++ b/lib/librte_vhost/virtio-net.c
>> @@ -322,6 +322,25 @@ init_vring_queue_pair(struct virtio_net *dev, uint32_t
>> qp_idx)
>> init_vring_queue(dev->virtqueue[base_idx + VIRTIO_TXQ], qp_idx);
>> }
>>
>> +static void
>> +reset_vring_queue(struct vhost_virtqueue *vq, int qp_idx)
>> +{
>> +int callfd;
>> +
>> +callfd = vq->callfd;
>> +init_vring_queue(vq, qp_idx);
>> +vq->callfd = callfd;
> It may fix your issue, but it's not a proper fix. As we actually closed
> callfd at cleanup_vq().
Yes, you are correct.
We also need to fix above.
>
> BTW, the name, cleanup_vq/device, is not well taken. For a name like
> cleanup, those functions should be invoked at device remove stage (say,
> shutting down a VM), but not at reset stage (which is actually treated
> as STOP in current QEMU implementation).
>
> I have a plan to correct it, but I guess it's not the right time as
> v2.2 is coming soon. However, for a fix, it could be simple: how about
> adding another arg to cleanup_vq:
>
> cleanup_vq(struct vhost_virtqueue *vq, int destory)
>
> And we only close callfd when destroy flag is set. (And of course, this
> patch is needed).
Yes I agree with it!
Let me have a few hours, I will send it by today.
Thanks,
Tetsuya
> What do you think of that?
>
> --yliu
>> +}
>> +
>> +static void
>> +reset_vring_queue_pair(struct virtio_net *dev, uint32_t qp_idx)
>> +{
>> +uint32_t base_idx = qp_idx * VIRTIO_QNUM;
>> +
>> +reset_vring_queue(dev->virtqueue[base_idx + VIRTIO_RXQ], qp_idx);
>> +reset_vring_queue(dev->virtqueue[base_idx + VIRTIO_TXQ], qp_idx);
>> +}
>> +
>> static int
>> alloc_vring_queue_pair(struct virtio_net *dev, uint32_t qp_idx)
>> {
>> @@ -362,7 +381,7 @@ reset_device(struct virtio_net *dev)
>> dev->flags = 0;
>>
>> for (i = 0; i < dev->virt_qp_nb; i++)
>> -init_vring_queue_pair(dev, i);
>> +reset_vring_queue_pair(dev, i);
>> }
>>
>> /*
>> --
>> 2.1.4
[dpdk-dev] [PATCH v6 1/7] nfp: basic initialization
Hi, 2015-11-05 10:43, Alejandro.Lucero: > +# Add extra flags for base driver files (also known as shared code) > +# to disable warnings > +# > +ifeq ($(CC), icc) > +CFLAGS_BASE_DRIVER = -wd593 > +else ifeq ($(CC), clang) > +CFLAGS_BASE_DRIVER += -Wno-sign-compare > +CFLAGS_BASE_DRIVER += -Wno-unused-value > +CFLAGS_BASE_DRIVER += -Wno-unused-parameter > +CFLAGS_BASE_DRIVER += -Wno-strict-aliasing > +CFLAGS_BASE_DRIVER += -Wno-format > +CFLAGS_BASE_DRIVER += -Wno-missing-field-initializers > +CFLAGS_BASE_DRIVER += -Wno-pointer-to-int-cast > +CFLAGS_BASE_DRIVER += -Wno-format-nonliteral > +else > +CFLAGS_BASE_DRIVER = -Wno-sign-compare > +CFLAGS_BASE_DRIVER += -Wno-unused-value > +CFLAGS_BASE_DRIVER += -Wno-unused-parameter > +CFLAGS_BASE_DRIVER += -Wno-strict-aliasing > +CFLAGS_BASE_DRIVER += -Wno-format > +CFLAGS_BASE_DRIVER += -Wno-missing-field-initializers > +CFLAGS_BASE_DRIVER += -Wno-pointer-to-int-cast > +CFLAGS_BASE_DRIVER += -Wno-format-nonliteral > +CFLAGS_BASE_DRIVER += -Wno-format-security > + > +ifeq ($(shell test $(GCC_VERSION) -ge 44 && echo 1), 1) > +CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable > +endif > + > +endif > +OBJS_BASE_DRIVER=$(patsubst %.c,%.o,$(notdir $(wildcard > $(RTE_SDK)/lib/librte_pmd_nfp/*.c))) > +$(foreach obj, $(OBJS_BASE_DRIVER), $(eval > CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER))) These flags were copied from another PMD and should apply only to base drivers which we have some restricted updates. > --- a/mk/rte.app.mk > +++ b/mk/rte.app.mk > @@ -142,6 +142,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += > -lrte_pmd_ixgbe > _LDLIBS-$(CONFIG_RTE_LIBRTE_E1000_PMD) += -lrte_pmd_e1000 > _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -lrte_pmd_mlx4 > _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += -lrte_pmd_mlx5 > +_LDLIBS-$(CONFIG_RTE_LIBRTE_NFP_PMD)+= -lrte_pmd_nfp > _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lrte_pmd_mpipe -lgxio > _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_RING) += -lrte_pmd_ring > _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += -lrte_pmd_pcap It is not too far of being alphabetically sorted.
[dpdk-dev] [PATCH v5 0/3] Keepalive monitoring & reporting
2015-11-18 14:05, Remy Horton: > This patch-set adds functions for detecting and reporting live-ness of > LCores, the primary requirement of which is minimal overheads for the > core(s) being checked. Core failures are notified via an application > defined callback. As an example l2fwd with random failures is used. Applied, thanks
[dpdk-dev] [PATCH v4 1/2] vhost: Add callback and private data for vhost PMD
On 2015/11/19 15:31, Yuanhan Liu wrote: > On Thu, Nov 19, 2015 at 02:58:56PM +0900, Tetsuya Mukawa wrote: >> On 2015/11/19 14:45, Yuanhan Liu wrote: >>> On Thu, Nov 19, 2015 at 02:14:13PM +0900, Tetsuya Mukawa wrote: On 2015/11/19 12:33, Yuanhan Liu wrote: > On Thu, Nov 19, 2015 at 12:13:38PM +0900, Tetsuya Mukawa wrote: >> On 2015/11/19 11:18, Yuanhan Liu wrote: >>> On Thu, Nov 19, 2015 at 11:03:50AM +0900, Tetsuya Mukawa wrote: On 2015/11/17 22:29, Yuanhan Liu wrote: > On Fri, Nov 13, 2015 at 02:20:30PM +0900, Tetsuya Mukawa wrote: >> These variables are needed to be able to manage one of virtio devices >> using both vhost library APIs and vhost PMD. >> For example, if vhost PMD uses current callback handler and private >> data >> provided by vhost library, A DPDK application that links vhost >> library >> cannot use some of vhost library APIs. > Can you be more specific about this? > > --yliu How about like below? commit log: Currently, when virtio device is created and destroyed, vhost library will call one of callback handlers. The vhost PMD need to use this pair of callback handlers to know which virtio devices are connected actually. Because we can register only one pair of callbacks to vhost library, if the PMD use it, DPDK applications cannot have a way to know the events. >>> Will (and why) the two co-exist at same time? >> Yes it is. Sure, I will describe below in commit log. >> >> Because we cannot map some of vhost library APIs to ethdev APIs, in some >> cases, we still >> need to use vhost library APIs for a port created by the vhost PMD. One >> of example is >> rte_vhost_enable_guest_notification(). > I don't get it why it has something to do with a standalone PMD callback. > And if you don't call rte_vhost_enable_guest_notification() inside vhost > PMD, where else can you call that? I mean, you can't start vhost-pmd > and vhost-swithc in the mean time, right? No it's not true, even after connecting to virtio-net device, you can change the flag. It's just a hint for virtio-net driver, and it will be used while queuing. (We may be able to change the flag, even while sending or receiving packets) > And, pmd callback and the old notify callback will not exist at same > time in one case, right? If so, why is that needed? > > BTW, if it's a MUST, would you provide a specific example? Actually, this patch is not a MUST. But still the users need callback handlers to know when virtio-net device is connected or disconnected. This is because the user can call rte_vhost_enable_guest_notification() only while connection is established. >>> What does "the user" mean? Is there a second user of vhost lib besides >>> vhost PMD, that he has to interact with those connected devices? If so, >>> how? >> Sorry, my English is wrong. >> Not a second user. >> >> For example, If DPDK application has a port created by vhost PMD, then >> needs to call rte_vhost_enable_guest_notification() to the port. > So, you are mixing the usage of vhost PMD and vhost lib in a DPDK > application? Say, Yes, that is my intention. Using ethdev(PMD) APIs and some library specific APIs to a same port is used in bonding PMD also. Thanks, Tetsuya > DPDK application >start_vhost_pmd > rte_vhost_driver_pmd_callback_register >rte_vhost_driver_callback_register > > I know little about PMD, and not quite sure it's a good combo. > > Huawei, comments? > > --yliu > >> DPDK application needs to know when virtio-net device is connected or >> disconnected, because the function is only valid while connecting. >> But without callback handler, DPDK application cannot know it. >> >> This is what I wanted to explain. >> >> Thanks, >> Tetsuya >> >>> --yliu Probably we can use link status changed callback of the PMD for this purpose. (The vhost PMD will notice DPDK application using link status callback) But I am not sure whether we need to implement link status changed callback for this purpose. While processing this callback handler, the users will only calls vhost library APIs that ethdev API cannot map, or store some variables related with vhost library. If so, this callback handler itself is specific for using vhost library. And it may be ok that callback itself is implemented as one of vhost library APIs. Tetsuya > --yliu >> Thanks, >> Tetsuya >> >> >>> --yliu >>> This may break legacy DPDK applications that uses vhost library. To prevent it, this patch adds one more pair of callbacks to vhost
[dpdk-dev] [PATCH] vhost: Fix reset_owner message handling not to clear callfd
The patch fixes reset_owner message handling not to clear callfd,
because callfd will be valid while connection is establihed.
Signed-off-by: Tetsuya Mukawa
---
lib/librte_vhost/virtio-net.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index 886c104..ae1e4bd 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -322,6 +322,25 @@ init_vring_queue_pair(struct virtio_net *dev, uint32_t
qp_idx)
init_vring_queue(dev->virtqueue[base_idx + VIRTIO_TXQ], qp_idx);
}
+static void
+reset_vring_queue(struct vhost_virtqueue *vq, int qp_idx)
+{
+ int callfd;
+
+ callfd = vq->callfd;
+ init_vring_queue(vq, qp_idx);
+ vq->callfd = callfd;
+}
+
+static void
+reset_vring_queue_pair(struct virtio_net *dev, uint32_t qp_idx)
+{
+ uint32_t base_idx = qp_idx * VIRTIO_QNUM;
+
+ reset_vring_queue(dev->virtqueue[base_idx + VIRTIO_RXQ], qp_idx);
+ reset_vring_queue(dev->virtqueue[base_idx + VIRTIO_TXQ], qp_idx);
+}
+
static int
alloc_vring_queue_pair(struct virtio_net *dev, uint32_t qp_idx)
{
@@ -362,7 +381,7 @@ reset_device(struct virtio_net *dev)
dev->flags = 0;
for (i = 0; i < dev->virt_qp_nb; i++)
- init_vring_queue_pair(dev, i);
+ reset_vring_queue_pair(dev, i);
}
/*
--
2.1.4
[dpdk-dev] How to test DPDK QoS sched example app
Hi I've 2 boxes connected back to back. One box runs qos_sched example app on IGB network card. I've been trying to test the qos_sched app but I could not able to do it probably i missing more than something. Could you please let me know how do i verify qos_sched app Regards
[dpdk-dev] [PATCH] vhost: Fix reset_owner message handling not to clear callfd
On Thu, Nov 19, 2015 at 03:23:26PM +0900, Tetsuya Mukawa wrote:
> The patch fixes reset_owner message handling not to clear callfd,
> because callfd will be valid while connection is establihed.
>
> Signed-off-by: Tetsuya Mukawa
> ---
> lib/librte_vhost/virtio-net.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
> index 886c104..ae1e4bd 100644
> --- a/lib/librte_vhost/virtio-net.c
> +++ b/lib/librte_vhost/virtio-net.c
> @@ -322,6 +322,25 @@ init_vring_queue_pair(struct virtio_net *dev, uint32_t
> qp_idx)
> init_vring_queue(dev->virtqueue[base_idx + VIRTIO_TXQ], qp_idx);
> }
>
> +static void
> +reset_vring_queue(struct vhost_virtqueue *vq, int qp_idx)
> +{
> + int callfd;
> +
> + callfd = vq->callfd;
> + init_vring_queue(vq, qp_idx);
> + vq->callfd = callfd;
It may fix your issue, but it's not a proper fix. As we actually closed
callfd at cleanup_vq().
BTW, the name, cleanup_vq/device, is not well taken. For a name like
cleanup, those functions should be invoked at device remove stage (say,
shutting down a VM), but not at reset stage (which is actually treated
as STOP in current QEMU implementation).
I have a plan to correct it, but I guess it's not the right time as
v2.2 is coming soon. However, for a fix, it could be simple: how about
adding another arg to cleanup_vq:
cleanup_vq(struct vhost_virtqueue *vq, int destory)
And we only close callfd when destroy flag is set. (And of course, this
patch is needed).
What do you think of that?
--yliu
> +}
> +
> +static void
> +reset_vring_queue_pair(struct virtio_net *dev, uint32_t qp_idx)
> +{
> + uint32_t base_idx = qp_idx * VIRTIO_QNUM;
> +
> + reset_vring_queue(dev->virtqueue[base_idx + VIRTIO_RXQ], qp_idx);
> + reset_vring_queue(dev->virtqueue[base_idx + VIRTIO_TXQ], qp_idx);
> +}
> +
> static int
> alloc_vring_queue_pair(struct virtio_net *dev, uint32_t qp_idx)
> {
> @@ -362,7 +381,7 @@ reset_device(struct virtio_net *dev)
> dev->flags = 0;
>
> for (i = 0; i < dev->virt_qp_nb; i++)
> - init_vring_queue_pair(dev, i);
> + reset_vring_queue_pair(dev, i);
> }
>
> /*
> --
> 2.1.4
[dpdk-dev] [PATCH v4 1/2] vhost: Add callback and private data for vhost PMD
On 2015/11/19 14:45, Yuanhan Liu wrote: > On Thu, Nov 19, 2015 at 02:14:13PM +0900, Tetsuya Mukawa wrote: >> On 2015/11/19 12:33, Yuanhan Liu wrote: >>> On Thu, Nov 19, 2015 at 12:13:38PM +0900, Tetsuya Mukawa wrote: On 2015/11/19 11:18, Yuanhan Liu wrote: > On Thu, Nov 19, 2015 at 11:03:50AM +0900, Tetsuya Mukawa wrote: >> On 2015/11/17 22:29, Yuanhan Liu wrote: >>> On Fri, Nov 13, 2015 at 02:20:30PM +0900, Tetsuya Mukawa wrote: These variables are needed to be able to manage one of virtio devices using both vhost library APIs and vhost PMD. For example, if vhost PMD uses current callback handler and private data provided by vhost library, A DPDK application that links vhost library cannot use some of vhost library APIs. >>> Can you be more specific about this? >>> >>> --yliu >> How about like below? >> >> commit log: >> Currently, when virtio device is created and destroyed, vhost library >> will call one of callback handlers. >> The vhost PMD need to use this pair of callback handlers to know which >> virtio devices are connected actually. >> Because we can register only one pair of callbacks to vhost library, if >> the PMD use it, DPDK applications >> cannot have a way to know the events. > Will (and why) the two co-exist at same time? Yes it is. Sure, I will describe below in commit log. Because we cannot map some of vhost library APIs to ethdev APIs, in some cases, we still need to use vhost library APIs for a port created by the vhost PMD. One of example is rte_vhost_enable_guest_notification(). >>> I don't get it why it has something to do with a standalone PMD callback. >>> And if you don't call rte_vhost_enable_guest_notification() inside vhost >>> PMD, where else can you call that? I mean, you can't start vhost-pmd >>> and vhost-swithc in the mean time, right? >> No it's not true, even after connecting to virtio-net device, you can >> change the flag. >> It's just a hint for virtio-net driver, and it will be used while queuing. >> (We may be able to change the flag, even while sending or receiving packets) >> >>> And, pmd callback and the old notify callback will not exist at same >>> time in one case, right? If so, why is that needed? >>> >>> BTW, if it's a MUST, would you provide a specific example? >> Actually, this patch is not a MUST. >> >> But still the users need callback handlers to know when virtio-net >> device is connected or disconnected. >> This is because the user can call rte_vhost_enable_guest_notification() >> only while connection is established. > What does "the user" mean? Is there a second user of vhost lib besides > vhost PMD, that he has to interact with those connected devices? If so, > how? Sorry, my English is wrong. Not a second user. For example, If DPDK application has a port created by vhost PMD, then needs to call rte_vhost_enable_guest_notification() to the port. DPDK application needs to know when virtio-net device is connected or disconnected, because the function is only valid while connecting. But without callback handler, DPDK application cannot know it. This is what I wanted to explain. Thanks, Tetsuya > --yliu >> Probably we can use link status changed callback of the PMD for this >> purpose. >> (The vhost PMD will notice DPDK application using link status callback) >> >> But I am not sure whether we need to implement link status changed >> callback for this purpose. >> While processing this callback handler, the users will only calls vhost >> library APIs that ethdev API cannot map, or store some variables related >> with vhost library. >> If so, this callback handler itself is specific for using vhost library. >> And it may be ok that callback itself is implemented as one of vhost >> library APIs. >> >> Tetsuya >> >>> --yliu Thanks, Tetsuya > --yliu > >> This may break legacy DPDK >> applications that uses vhost library. >> To prevent it, this patch adds one more pair of callbacks to vhost >> library especially for the vhost PMD. >> With the patch, legacy applications can use the vhost PMD even if they >> need additional specific handling >> for virtio device creation and destruction. >> For example, legacy application can call >> rte_vhost_enable_guest_notification() in callbacks to change setting. >> >> Tetsuya
[dpdk-dev] [PATCH v4 1/2] vhost: Add callback and private data for vhost PMD
On Thu, Nov 19, 2015 at 02:58:56PM +0900, Tetsuya Mukawa wrote: > On 2015/11/19 14:45, Yuanhan Liu wrote: > > On Thu, Nov 19, 2015 at 02:14:13PM +0900, Tetsuya Mukawa wrote: > >> On 2015/11/19 12:33, Yuanhan Liu wrote: > >>> On Thu, Nov 19, 2015 at 12:13:38PM +0900, Tetsuya Mukawa wrote: > On 2015/11/19 11:18, Yuanhan Liu wrote: > > On Thu, Nov 19, 2015 at 11:03:50AM +0900, Tetsuya Mukawa wrote: > >> On 2015/11/17 22:29, Yuanhan Liu wrote: > >>> On Fri, Nov 13, 2015 at 02:20:30PM +0900, Tetsuya Mukawa wrote: > These variables are needed to be able to manage one of virtio devices > using both vhost library APIs and vhost PMD. > For example, if vhost PMD uses current callback handler and private > data > provided by vhost library, A DPDK application that links vhost > library > cannot use some of vhost library APIs. > >>> Can you be more specific about this? > >>> > >>> --yliu > >> How about like below? > >> > >> commit log: > >> Currently, when virtio device is created and destroyed, vhost library > >> will call one of callback handlers. > >> The vhost PMD need to use this pair of callback handlers to know which > >> virtio devices are connected actually. > >> Because we can register only one pair of callbacks to vhost library, if > >> the PMD use it, DPDK applications > >> cannot have a way to know the events. > > Will (and why) the two co-exist at same time? > Yes it is. Sure, I will describe below in commit log. > > Because we cannot map some of vhost library APIs to ethdev APIs, in some > cases, we still > need to use vhost library APIs for a port created by the vhost PMD. One > of example is > rte_vhost_enable_guest_notification(). > >>> I don't get it why it has something to do with a standalone PMD callback. > >>> And if you don't call rte_vhost_enable_guest_notification() inside vhost > >>> PMD, where else can you call that? I mean, you can't start vhost-pmd > >>> and vhost-swithc in the mean time, right? > >> No it's not true, even after connecting to virtio-net device, you can > >> change the flag. > >> It's just a hint for virtio-net driver, and it will be used while queuing. > >> (We may be able to change the flag, even while sending or receiving > >> packets) > >> > >>> And, pmd callback and the old notify callback will not exist at same > >>> time in one case, right? If so, why is that needed? > >>> > >>> BTW, if it's a MUST, would you provide a specific example? > >> Actually, this patch is not a MUST. > >> > >> But still the users need callback handlers to know when virtio-net > >> device is connected or disconnected. > >> This is because the user can call rte_vhost_enable_guest_notification() > >> only while connection is established. > > What does "the user" mean? Is there a second user of vhost lib besides > > vhost PMD, that he has to interact with those connected devices? If so, > > how? > > Sorry, my English is wrong. > Not a second user. > > For example, If DPDK application has a port created by vhost PMD, then > needs to call rte_vhost_enable_guest_notification() to the port. So, you are mixing the usage of vhost PMD and vhost lib in a DPDK application? Say, DPDK application start_vhost_pmd rte_vhost_driver_pmd_callback_register rte_vhost_driver_callback_register I know little about PMD, and not quite sure it's a good combo. Huawei, comments? --yliu > DPDK application needs to know when virtio-net device is connected or > disconnected, because the function is only valid while connecting. > But without callback handler, DPDK application cannot know it. > > This is what I wanted to explain. > > Thanks, > Tetsuya > > > --yliu > >> Probably we can use link status changed callback of the PMD for this > >> purpose. > >> (The vhost PMD will notice DPDK application using link status callback) > >> > >> But I am not sure whether we need to implement link status changed > >> callback for this purpose. > >> While processing this callback handler, the users will only calls vhost > >> library APIs that ethdev API cannot map, or store some variables related > >> with vhost library. > >> If so, this callback handler itself is specific for using vhost library. > >> And it may be ok that callback itself is implemented as one of vhost > >> library APIs. > >> > >> Tetsuya > >> > >>> --yliu > Thanks, > Tetsuya > > > > --yliu > > > >> This may break legacy DPDK > >> applications that uses vhost library. > >> To prevent it, this patch adds one more pair of callbacks to vhost > >> library especially for the vhost PMD. > >> With the patch, legacy applications can use the vhost PMD even if they > >> need additional specific handling > >> for virtio device creation and destruction. >
[dpdk-dev] dpdk+libuinet
Hi all, I want to run libuinet on DPDK,but I can not get much information on the Internet.Any help or suggestion is greate. Best Regards, Qiwei Hu
[dpdk-dev] [PATCH v4 1/2] vhost: Add callback and private data for vhost PMD
On 2015/11/19 12:33, Yuanhan Liu wrote: > On Thu, Nov 19, 2015 at 12:13:38PM +0900, Tetsuya Mukawa wrote: >> On 2015/11/19 11:18, Yuanhan Liu wrote: >>> On Thu, Nov 19, 2015 at 11:03:50AM +0900, Tetsuya Mukawa wrote: On 2015/11/17 22:29, Yuanhan Liu wrote: > On Fri, Nov 13, 2015 at 02:20:30PM +0900, Tetsuya Mukawa wrote: >> These variables are needed to be able to manage one of virtio devices >> using both vhost library APIs and vhost PMD. >> For example, if vhost PMD uses current callback handler and private data >> provided by vhost library, A DPDK application that links vhost library >> cannot use some of vhost library APIs. > Can you be more specific about this? > > --yliu How about like below? commit log: Currently, when virtio device is created and destroyed, vhost library will call one of callback handlers. The vhost PMD need to use this pair of callback handlers to know which virtio devices are connected actually. Because we can register only one pair of callbacks to vhost library, if the PMD use it, DPDK applications cannot have a way to know the events. >>> Will (and why) the two co-exist at same time? >> Yes it is. Sure, I will describe below in commit log. >> >> Because we cannot map some of vhost library APIs to ethdev APIs, in some >> cases, we still >> need to use vhost library APIs for a port created by the vhost PMD. One >> of example is >> rte_vhost_enable_guest_notification(). > I don't get it why it has something to do with a standalone PMD callback. > And if you don't call rte_vhost_enable_guest_notification() inside vhost > PMD, where else can you call that? I mean, you can't start vhost-pmd > and vhost-swithc in the mean time, right? No it's not true, even after connecting to virtio-net device, you can change the flag. It's just a hint for virtio-net driver, and it will be used while queuing. (We may be able to change the flag, even while sending or receiving packets) > > And, pmd callback and the old notify callback will not exist at same > time in one case, right? If so, why is that needed? > > BTW, if it's a MUST, would you provide a specific example? Actually, this patch is not a MUST. But still the users need callback handlers to know when virtio-net device is connected or disconnected. This is because the user can call rte_vhost_enable_guest_notification() only while connection is established. Probably we can use link status changed callback of the PMD for this purpose. (The vhost PMD will notice DPDK application using link status callback) But I am not sure whether we need to implement link status changed callback for this purpose. While processing this callback handler, the users will only calls vhost library APIs that ethdev API cannot map, or store some variables related with vhost library. If so, this callback handler itself is specific for using vhost library. And it may be ok that callback itself is implemented as one of vhost library APIs. Tetsuya > > --yliu >> Thanks, >> Tetsuya >> >> >>> --yliu >>> This may break legacy DPDK applications that uses vhost library. To prevent it, this patch adds one more pair of callbacks to vhost library especially for the vhost PMD. With the patch, legacy applications can use the vhost PMD even if they need additional specific handling for virtio device creation and destruction. For example, legacy application can call rte_vhost_enable_guest_notification() in callbacks to change setting. Tetsuya
[dpdk-dev] [PATCH] vhost: avoid buffer overflow in update_secure_len
On Wed, Nov 18, 2015 at 11:15:25AM +, Xie, Huawei wrote:
> On 11/18/2015 4:47 PM, Yuanhan Liu wrote:
> > On Wed, Nov 18, 2015 at 07:53:24AM +, Xie, Huawei wrote:
> > ...
> >>> do {
> >>> + if (vec_id >= BUF_VECTOR_MAX)
> >>> + break;
> >>> +
> >>> next_desc = 0;
> >>> len += vq->desc[idx].len;
> >>> vq->buf_vec[vec_id].buf_addr = vq->desc[idx].addr;
> >>> @@ -519,6 +526,8 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t
> >>> queue_id,
> >>> goto merge_rx_exit;
> >>> } else {
> >>> update_secure_len(vq, res_cur_idx,
> >>> _len, _idx);
> >>> + if (secure_len == 0)
> >>> + goto merge_rx_exit;
> >> Why do we exit when secure_len is 0 rather than 1? :). Malicious guest
> > I confess it's not a proper fix. Making it return an error code, as Rich
> > suggested in early email, is better. It's generic enough, as we have to
> > check the vec_buf overflow here.
> >
> > BTW, can we move the vec_buf outside `struct vhost_virtqueue'? It makes
> > the structure huge.
> >
> >> could easily forge the desc len so that secure_len never reach pkt_len
> >> even it is not zero so that host enters into dead loop here.
> >> Generally speaking, we shouldn't fix for a specific issue,
> > Agreed.
> >
> >> and the
> >> security checks should be as few as possible.
> > Idealy, yes.
> >
> >> We need to consider
> >> refactor the code here for the generic fix.
> > What's your thougths?
> Maybe we merge the update_secure_len with the outside loop into a simple
> inline function, in which we consider both the max vector number and
> desc count to avoid trapped into dead loop. This functions returns a buf
> vec with which we could copy securely afterwards.
I agree that grouping them into a function makes the logic clearer, and
hence less error-prone.
I made a quick try. Comments?
--yliu
---
diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 4fc35d1..e270fb1 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -439,32 +439,98 @@ copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t
queue_id,
return entry_success;
}
-static inline void __attribute__((always_inline))
-update_secure_len(struct vhost_virtqueue *vq, uint32_t id,
- uint32_t *secure_len, uint32_t *vec_idx)
+static inline int
+fill_vec_buf(struct vhost_virtqueue *vq, uint32_t avail_idx,
+uint32_t *allocated, uint32_t *vec_idx)
{
- uint16_t wrapped_idx = id & (vq->size - 1);
- uint32_t idx = vq->avail->ring[wrapped_idx];
- uint8_t next_desc;
- uint32_t len = *secure_len;
+ uint16_t idx = vq->avail->ring[avail_idx & (vq->size - 1)];
uint32_t vec_id = *vec_idx;
+ uint32_t len= *allocated;
+
+ while (1) {
+ if (vec_id >= BUF_VECTOR_MAX)
+ return -1;
- do {
- next_desc = 0;
len += vq->desc[idx].len;
vq->buf_vec[vec_id].buf_addr = vq->desc[idx].addr;
vq->buf_vec[vec_id].buf_len = vq->desc[idx].len;
vq->buf_vec[vec_id].desc_idx = idx;
vec_id++;
- if (vq->desc[idx].flags & VRING_DESC_F_NEXT) {
- idx = vq->desc[idx].next;
- next_desc = 1;
+ if ((vq->desc[idx].flags & VRING_DESC_F_NEXT) == 0)
+ break;
+
+ idx = vq->desc[idx].next;
+ }
+
+ *allocated = len;
+ *vec_idx = vec_id;
+
+ return 0;
+}
+
+/*
+ * As many data cores may want to access available buffers concurrently,
+ * they need to be reserved.
+ *
+ * Returns -1 on fail, 0 on success
+ */
+static inline int
+reserve_avail_buf(struct vhost_virtqueue *vq, uint32_t size,
+ uint16_t *start, uint16_t *end)
+{
+ uint16_t res_base_idx;
+ uint16_t res_cur_idx;
+ uint16_t avail_idx;
+ uint32_t allocated;
+ uint32_t vec_idx;
+ uint16_t tries;
+
+again:
+ res_base_idx = vq->last_used_idx_res;
+ res_cur_idx = res_base_idx;
+
+ allocated = 0;
+ vec_idx = 0;
+ tries = 0;
+ while (1) {
+ avail_idx = *((volatile uint16_t *)>avail->idx);
+ if (unlikely(res_cur_idx == avail_idx)) {
+ LOG_DEBUG(VHOST_DATA, "(%"PRIu64") Failed "
+ "to get enough desc from vring\n",
+ dev->device_fh);
+ return -1;
}
- } while (next_desc);
- *secure_len = len;
- *vec_idx = vec_id;
+ if (fill_vec_buf(vq, res_cur_idx, , _idx) < 0)
+ return -1;
+
+ res_cur_idx++;
+ tries++;
+
+ if
[dpdk-dev] [PATCH] Revert "eal: set name to threads"
On 11/19/2015 01:22 PM, Ferruh Yigit wrote: > This reverts commit 67b6d3039e9edbc4624c878c6930be5e126e8b58. > > Reverted patch uses pthread_setname_np() function, this function added > into glibc in version 2.12 and cause a compile error in older glibc > versions: > error: implicit declaration of function "pthread_setname_np" > > Main purpose of reverted patch is to name threads, without > pthread_setname_np() function, patch does not mean much, so reverting > patch for sake of compatibility with older glibc versions. > Debuggability is important too. Rather than revert, why not wrap it in rte_thread_setname() or such and just make it a no-op with glibc versions where pthread_setname_np() is not available? - Panu -
[dpdk-dev] [PATCH v4 1/2] vhost: Add callback and private data for vhost PMD
On Thu, Nov 19, 2015 at 02:14:13PM +0900, Tetsuya Mukawa wrote: > On 2015/11/19 12:33, Yuanhan Liu wrote: > > On Thu, Nov 19, 2015 at 12:13:38PM +0900, Tetsuya Mukawa wrote: > >> On 2015/11/19 11:18, Yuanhan Liu wrote: > >>> On Thu, Nov 19, 2015 at 11:03:50AM +0900, Tetsuya Mukawa wrote: > On 2015/11/17 22:29, Yuanhan Liu wrote: > > On Fri, Nov 13, 2015 at 02:20:30PM +0900, Tetsuya Mukawa wrote: > >> These variables are needed to be able to manage one of virtio devices > >> using both vhost library APIs and vhost PMD. > >> For example, if vhost PMD uses current callback handler and private > >> data > >> provided by vhost library, A DPDK application that links vhost library > >> cannot use some of vhost library APIs. > > Can you be more specific about this? > > > > --yliu > How about like below? > > commit log: > Currently, when virtio device is created and destroyed, vhost library > will call one of callback handlers. > The vhost PMD need to use this pair of callback handlers to know which > virtio devices are connected actually. > Because we can register only one pair of callbacks to vhost library, if > the PMD use it, DPDK applications > cannot have a way to know the events. > >>> Will (and why) the two co-exist at same time? > >> Yes it is. Sure, I will describe below in commit log. > >> > >> Because we cannot map some of vhost library APIs to ethdev APIs, in some > >> cases, we still > >> need to use vhost library APIs for a port created by the vhost PMD. One > >> of example is > >> rte_vhost_enable_guest_notification(). > > I don't get it why it has something to do with a standalone PMD callback. > > And if you don't call rte_vhost_enable_guest_notification() inside vhost > > PMD, where else can you call that? I mean, you can't start vhost-pmd > > and vhost-swithc in the mean time, right? > > No it's not true, even after connecting to virtio-net device, you can > change the flag. > It's just a hint for virtio-net driver, and it will be used while queuing. > (We may be able to change the flag, even while sending or receiving packets) > > > > > And, pmd callback and the old notify callback will not exist at same > > time in one case, right? If so, why is that needed? > > > > BTW, if it's a MUST, would you provide a specific example? > > Actually, this patch is not a MUST. > > But still the users need callback handlers to know when virtio-net > device is connected or disconnected. > This is because the user can call rte_vhost_enable_guest_notification() > only while connection is established. What does "the user" mean? Is there a second user of vhost lib besides vhost PMD, that he has to interact with those connected devices? If so, how? --yliu > > Probably we can use link status changed callback of the PMD for this > purpose. > (The vhost PMD will notice DPDK application using link status callback) > > But I am not sure whether we need to implement link status changed > callback for this purpose. > While processing this callback handler, the users will only calls vhost > library APIs that ethdev API cannot map, or store some variables related > with vhost library. > If so, this callback handler itself is specific for using vhost library. > And it may be ok that callback itself is implemented as one of vhost > library APIs. > > Tetsuya > > > > > --yliu > >> Thanks, > >> Tetsuya > >> > >> > >>> --yliu > >>> > This may break legacy DPDK > applications that uses vhost library. > To prevent it, this patch adds one more pair of callbacks to vhost > library especially for the vhost PMD. > With the patch, legacy applications can use the vhost PMD even if they > need additional specific handling > for virtio device creation and destruction. > For example, legacy application can call > rte_vhost_enable_guest_notification() in callbacks to change setting. > > Tetsuya
[dpdk-dev] [PATCH] Revert "eal: set name to threads"
On Thu, Nov 19, 2015 at 01:32:44PM +0100, Thomas Monjalon wrote: > 2015-11-19 13:49, Panu Matilainen: > > On 11/19/2015 01:22 PM, Ferruh Yigit wrote: > > > This reverts commit 67b6d3039e9edbc4624c878c6930be5e126e8b58. > > > > > > Reverted patch uses pthread_setname_np() function, this function added > > > into glibc in version 2.12 and cause a compile error in older glibc > > > versions: > > > error: implicit declaration of function "pthread_setname_np" > > > > > > Main purpose of reverted patch is to name threads, without > > > pthread_setname_np() function, patch does not mean much, so reverting > > > patch for sake of compatibility with older glibc versions. > > > > Debuggability is important too. Rather than revert, why not wrap it in > > rte_thread_setname() or such and just make it a no-op with glibc > > versions where pthread_setname_np() is not available? > > +1 Which means adding compile time glibc version check which I was trying to avoid, I believe we should not add glibc version dependencies unless feature is really required, but sure I can implement that way, will send v2. Thanks, ferruh
[dpdk-dev] [PATCH] Revert "eal: set name to threads"
2015-11-19 13:49, Panu Matilainen: > On 11/19/2015 01:22 PM, Ferruh Yigit wrote: > > This reverts commit 67b6d3039e9edbc4624c878c6930be5e126e8b58. > > > > Reverted patch uses pthread_setname_np() function, this function added > > into glibc in version 2.12 and cause a compile error in older glibc > > versions: > > error: implicit declaration of function "pthread_setname_np" > > > > Main purpose of reverted patch is to name threads, without > > pthread_setname_np() function, patch does not mean much, so reverting > > patch for sake of compatibility with older glibc versions. > > Debuggability is important too. Rather than revert, why not wrap it in > rte_thread_setname() or such and just make it a no-op with glibc > versions where pthread_setname_np() is not available? +1
[dpdk-dev] [PATCH v5 2/3] docs: add keep alive sample app guide & release notes
2015-11-18 14:05, Remy Horton: > --- a/doc/guides/rel_notes/release_2_2.rst > +++ b/doc/guides/rel_notes/release_2_2.rst > @@ -102,6 +102,7 @@ New Features > > * **Added port hotplug support to xenvirt.** > > +* **Added keepalive support to EAL.** > > Resolved Issues > --- > @@ -207,6 +208,8 @@ Libraries > Examples > > > +* **l2fwd-keepalive: Added keep-alive demonstration.** > + It is the "Resolved Issues" section. If you agree, I'll merge it with the above entry.
[dpdk-dev] [PATCH v5 3/3] example: add keep alive sample application
2015-11-18 14:05, Remy Horton: > Modified version of l2fwd to demonstrate keep-alive functionality. > > Signed-off-by: Remy Horton > --- > MAINTAINERS | 4 + > examples/l2fwd-keepalive/Makefile | 50 +++ > examples/l2fwd-keepalive/main.c | 806 > ++ > 3 files changed, 860 insertions(+) You missed examples/Makefile. I'm going to fix it if you agree.
[dpdk-dev] [PATCH v4 1/2] vhost: Add callback and private data for vhost PMD
On 2015/11/19 11:18, Yuanhan Liu wrote: > On Thu, Nov 19, 2015 at 11:03:50AM +0900, Tetsuya Mukawa wrote: >> On 2015/11/17 22:29, Yuanhan Liu wrote: >>> On Fri, Nov 13, 2015 at 02:20:30PM +0900, Tetsuya Mukawa wrote: These variables are needed to be able to manage one of virtio devices using both vhost library APIs and vhost PMD. For example, if vhost PMD uses current callback handler and private data provided by vhost library, A DPDK application that links vhost library cannot use some of vhost library APIs. >>> Can you be more specific about this? >>> >>> --yliu >> How about like below? >> >> commit log: >> Currently, when virtio device is created and destroyed, vhost library >> will call one of callback handlers. >> The vhost PMD need to use this pair of callback handlers to know which >> virtio devices are connected actually. >> Because we can register only one pair of callbacks to vhost library, if >> the PMD use it, DPDK applications >> cannot have a way to know the events. > Will (and why) the two co-exist at same time? Yes it is. Sure, I will describe below in commit log. Because we cannot map some of vhost library APIs to ethdev APIs, in some cases, we still need to use vhost library APIs for a port created by the vhost PMD. One of example is rte_vhost_enable_guest_notification(). Thanks, Tetsuya > > --yliu > >> This may break legacy DPDK >> applications that uses vhost library. >> To prevent it, this patch adds one more pair of callbacks to vhost >> library especially for the vhost PMD. >> With the patch, legacy applications can use the vhost PMD even if they >> need additional specific handling >> for virtio device creation and destruction. >> For example, legacy application can call >> rte_vhost_enable_guest_notification() in callbacks to change setting. >> >> Tetsuya
[dpdk-dev] [PATCH v5 2/3] docs: add keep alive sample app guide & release notes
On 19/11/2015 11:32, Thomas Monjalon wrote: > 2015-11-18 14:05, Remy Horton: >> --- a/doc/guides/rel_notes/release_2_2.rst >> +++ b/doc/guides/rel_notes/release_2_2.rst >> @@ -102,6 +102,7 @@ New Features >> >> * **Added port hotplug support to xenvirt.** >> >> +* **Added keepalive support to EAL.** >> >> Resolved Issues >> --- >> @@ -207,6 +208,8 @@ Libraries >> Examples >> >> >> +* **l2fwd-keepalive: Added keep-alive demonstration.** >> + > > It is the "Resolved Issues" section. > If you agree, I'll merge it with the above entry. > Ok with me. Ditto with example/Makefile. ..Remy
[dpdk-dev] [PATCH v4 1/2] vhost: Add callback and private data for vhost PMD
On Thu, Nov 19, 2015 at 12:13:38PM +0900, Tetsuya Mukawa wrote: > On 2015/11/19 11:18, Yuanhan Liu wrote: > > On Thu, Nov 19, 2015 at 11:03:50AM +0900, Tetsuya Mukawa wrote: > >> On 2015/11/17 22:29, Yuanhan Liu wrote: > >>> On Fri, Nov 13, 2015 at 02:20:30PM +0900, Tetsuya Mukawa wrote: > These variables are needed to be able to manage one of virtio devices > using both vhost library APIs and vhost PMD. > For example, if vhost PMD uses current callback handler and private data > provided by vhost library, A DPDK application that links vhost library > cannot use some of vhost library APIs. > >>> Can you be more specific about this? > >>> > >>> --yliu > >> How about like below? > >> > >> commit log: > >> Currently, when virtio device is created and destroyed, vhost library > >> will call one of callback handlers. > >> The vhost PMD need to use this pair of callback handlers to know which > >> virtio devices are connected actually. > >> Because we can register only one pair of callbacks to vhost library, if > >> the PMD use it, DPDK applications > >> cannot have a way to know the events. > > Will (and why) the two co-exist at same time? > > Yes it is. Sure, I will describe below in commit log. > > Because we cannot map some of vhost library APIs to ethdev APIs, in some > cases, we still > need to use vhost library APIs for a port created by the vhost PMD. One > of example is > rte_vhost_enable_guest_notification(). I don't get it why it has something to do with a standalone PMD callback. And if you don't call rte_vhost_enable_guest_notification() inside vhost PMD, where else can you call that? I mean, you can't start vhost-pmd and vhost-swithc in the mean time, right? And, pmd callback and the old notify callback will not exist at same time in one case, right? If so, why is that needed? BTW, if it's a MUST, would you provide a specific example? --yliu > > Thanks, > Tetsuya > > > > > > --yliu > > > >> This may break legacy DPDK > >> applications that uses vhost library. > >> To prevent it, this patch adds one more pair of callbacks to vhost > >> library especially for the vhost PMD. > >> With the patch, legacy applications can use the vhost PMD even if they > >> need additional specific handling > >> for virtio device creation and destruction. > >> For example, legacy application can call > >> rte_vhost_enable_guest_notification() in callbacks to change setting. > >> > >> Tetsuya
[dpdk-dev] [PATCH] eal: fix compile error for old glibc caused by CLOCK_MONOTONIC_RAW
Fixes: d08d304508a8 ("eal/linux: make alarm not affected by system time
jump")
CLOCK_MONOTONIC_RAW added in glibc 2.12, using this define in older
glibc versions cause compile error:
'error: identifier "CLOCK_MONOTONIC_RAW" is undefined'
This patch replaces "CLOCK_MONOTONIC_RAW" with "CLOCK_MONOTONIC" for
older glibc versions, versions that support "CLOCK_MONOTONIC_RAW"
will keep using this clock type.
Signed-off-by: Ferruh Yigit
---
lib/librte_eal/linuxapp/eal/eal_alarm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_alarm.c
b/lib/librte_eal/linuxapp/eal/eal_alarm.c
index ff57323..8b042ab 100644
--- a/lib/librte_eal/linuxapp/eal/eal_alarm.c
+++ b/lib/librte_eal/linuxapp/eal/eal_alarm.c
@@ -63,6 +63,12 @@
#define MS_PER_S 1000
#define US_PER_S (US_PER_MS * MS_PER_S)
+#ifdef CLOCK_MONOTONIC_RAW /* Defined in glibc bits/time.h */
+#define CLOCK_TYPE_ID CLOCK_MONOTONIC_RAW
+#else
+#define CLOCK_TYPE_ID CLOCK_MONOTONIC
+#endif
+
struct alarm_entry {
LIST_ENTRY(alarm_entry) next;
struct timeval time;
@@ -104,7 +110,7 @@ eal_alarm_callback(struct rte_intr_handle *hdl __rte_unused,
rte_spinlock_lock(_list_lk);
while ((ap = LIST_FIRST(_list)) !=NULL &&
- clock_gettime(CLOCK_MONOTONIC_RAW, ) == 0 &&
+ clock_gettime(CLOCK_TYPE_ID, ) == 0 &&
(ap->time.tv_sec < now.tv_sec || (ap->time.tv_sec ==
now.tv_sec &&
(ap->time.tv_usec * NS_PER_US)
<= now.tv_nsec))) {
ap->executing = 1;
@@ -152,7 +158,7 @@ rte_eal_alarm_set(uint64_t us, rte_eal_alarm_callback
cb_fn, void *cb_arg)
return -ENOMEM;
/* use current time to calculate absolute time of alarm */
- clock_gettime(CLOCK_MONOTONIC_RAW, );
+ clock_gettime(CLOCK_TYPE_ID, );
new_alarm->cb_fn = cb_fn;
new_alarm->cb_arg = cb_arg;
--
2.5.0
[dpdk-dev] [PATCH] Revert "eal: set name to threads"
This reverts commit 67b6d3039e9edbc4624c878c6930be5e126e8b58.
Reverted patch uses pthread_setname_np() function, this function added
into glibc in version 2.12 and cause a compile error in older glibc
versions:
error: implicit declaration of function "pthread_setname_np"
Main purpose of reverted patch is to name threads, without
pthread_setname_np() function, patch does not mean much, so reverting
patch for sake of compatibility with older glibc versions.
Signed-off-by: Ferruh Yigit
---
examples/tep_termination/Makefile | 1 -
examples/tep_termination/main.c| 12 ++--
examples/vhost/Makefile| 1 -
examples/vhost/main.c | 16 ++--
examples/vhost_xen/Makefile| 1 -
examples/vhost_xen/main.c | 16 ++--
lib/librte_eal/bsdapp/eal/eal.c| 6 --
lib/librte_eal/common/include/rte_eal.h| 3 ---
lib/librte_eal/linuxapp/eal/Makefile | 2 --
lib/librte_eal/linuxapp/eal/eal.c | 10 --
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 15 ++-
lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c | 15 ++-
lib/librte_eal/linuxapp/eal/eal_timer.c| 12 +---
13 files changed, 11 insertions(+), 99 deletions(-)
diff --git a/examples/tep_termination/Makefile
b/examples/tep_termination/Makefile
index 448e618..c37e50f 100644
--- a/examples/tep_termination/Makefile
+++ b/examples/tep_termination/Makefile
@@ -51,6 +51,5 @@ SRCS-y := main.c vxlan_setup.c vxlan.c
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
-CFLAGS += -D_GNU_SOURCE
include $(RTE_SDK)/mk/rte.extapp.mk
diff --git a/examples/tep_termination/main.c b/examples/tep_termination/main.c
index 2b67e64..bd77617 100644
--- a/examples/tep_termination/main.c
+++ b/examples/tep_termination/main.c
@@ -1167,7 +1167,6 @@ main(int argc, char *argv[])
uint8_t portid;
uint16_t queue_id;
static pthread_t tid;
- char thread_name[RTE_MAX_THREAD_NAME_LEN];
/* init EAL */
ret = rte_eal_init(argc, argv);
@@ -1244,15 +1243,8 @@ main(int argc, char *argv[])
memset(_statistics, 0, sizeof(dev_statistics));
/* Enable stats if the user option is set. */
- if (enable_stats) {
- ret = pthread_create(, NULL, (void *)print_stats, NULL);
- if (ret != 0)
- rte_exit(EXIT_FAILURE, "Cannot create print-stats
thread\n");
- snprintf(thread_name, RTE_MAX_THREAD_NAME_LEN, "print-stats");
- ret = pthread_setname_np(tid, thread_name);
- if (ret != 0)
- RTE_LOG(ERR, VHOST_CONFIG, "Cannot set print-stats
name\n");
- }
+ if (enable_stats)
+ pthread_create(, NULL, (void *)print_stats, NULL);
/* Launch all data cores. */
RTE_LCORE_FOREACH_SLAVE(lcore_id) {
diff --git a/examples/vhost/Makefile b/examples/vhost/Makefile
index e95c68a..c269466 100644
--- a/examples/vhost/Makefile
+++ b/examples/vhost/Makefile
@@ -52,7 +52,6 @@ SRCS-y := main.c
CFLAGS += -O2 -D_FILE_OFFSET_BITS=64
CFLAGS += $(WERROR_FLAGS)
-CFLAGS += -D_GNU_SOURCE
include $(RTE_SDK)/mk/rte.extapp.mk
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index c081b18..9eac2d0 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -2896,7 +2896,6 @@ main(int argc, char *argv[])
uint8_t portid;
uint16_t queue_id;
static pthread_t tid;
- char thread_name[RTE_MAX_THREAD_NAME_LEN];
signal(SIGINT, sigint_handler);
@@ -3019,19 +3018,8 @@ main(int argc, char *argv[])
memset(_statistics, 0, sizeof(dev_statistics));
/* Enable stats if the user option is set. */
- if (enable_stats) {
- ret = pthread_create(, NULL, (void *)print_stats, NULL);
- if (ret != 0)
- rte_exit(EXIT_FAILURE,
- "Cannot create print-stats thread\n");
-
- /* Set thread_name for aid in debugging. */
- snprintf(thread_name, RTE_MAX_THREAD_NAME_LEN, "print-stats");
- ret = pthread_setname_np(tid, thread_name);
- if (ret != 0)
- RTE_LOG(ERR, VHOST_CONFIG,
- "Cannot set print-stats name\n");
- }
+ if (enable_stats)
+ pthread_create(, NULL, (void*)print_stats, NULL );
/* Launch all data cores. */
if (zero_copy == 0) {
diff --git a/examples/vhost_xen/Makefile b/examples/vhost_xen/Makefile
index 47e1489..e6fa1a1 100644
--- a/examples/vhost_xen/Makefile
+++ b/examples/vhost_xen/Makefile
@@ -46,7 +46,6 @@ SRCS-y := main.c vhost_monitor.c xenstore_parse.c
CFLAGS += -O2 -I/usr/local/include -D_FILE_OFFSET_BITS=64 -Wno-unused-parameter
CFLAGS += $(WERROR_FLAGS)
-CFLAGS
[dpdk-dev] DPDK Community Call - ARM Support
Thanks for following up on this Bob. It's great to see this level of engagement from the ARM ecosystem. In order to facilitate this, we'll move our call out by a week. New details for the meeting are: When: Tue, Dec 1, 2015 15:00 - 16:00 GMT Tue, Dec 1, 2015 07:00 - 08:00 PST Tue, Dec 1, 2015 10:00 - 11:00 EST Tue, Dec 1, 2015 16:00 - 17:00 PST Meeting Details: You can join from your computer, tablet or smartphone: https://global.gotomeeting.com/join/535221101 You can also dial in using your phone. Access Code: 535-221-101 Phone numbers: United States: +1 (224) 501-3217 Australia: +61 2 9087 3605 Austria: +43 7 2088 1403 Belgium: +32 (0) 28 93 7019 Canada: +1 (647) 497-9351 Denmark: +45 69 91 88 64 Finland: +358 (0) 942 41 5781 France: +33 (0) 182 880 458 Germany: +49 (0) 692 5736 7210 Ireland +353 (0) 14 845 979 Italy: +39 0 553 98 95 67 Netherlands: +31 (0) 208 080 381 New Zealand: +64 4 974 7214 Norway: +47 21 03 58 98 Spain: +34 955 32 0845 Sweden: +46 (0) 853 527 836 Switzerland: +41 (0) 435 0167 09 United Kingdom: +44 (0) 330 221 0086 Tim > -Original Message- > From: Bob Monkman [mailto:Bob.Monkman at arm.com] > Sent: Wednesday, November 18, 2015 7:27 PM > To: O'Driscoll, Tim; dev at dpdk.org > Subject: RE: DPDK Community Call - ARM Support > > Tim, et al, > Thanks for this call to the ARM community to convene to discuss > what support is out there in ARM ecosystem. I am responsible for > networking segment software strategy within ARM and, as some of your > colleagues already know, I am coordinating collaborative work on DPDK > for ARM with multiple members of our ARM ecosystem. > > My concern on this first discussion is that I, and other key > stakeholders from engineering management will be out all week for the US > Thanksgiving holiday. I suspect other key ARM stakeholder reps who may > want to join in this conversation may be in the same boat. Would the > group here be willing to consider same day and time the following week? > Tuesday Dec 1? > > We would greatly appreciate and I think you will have a better > chance of critical mass of the right people. > Regards, > Bob > > Robert (Bob) Monkman > Enterprise Segment Marketing Manager > 150 Rose Orchard Way > San Jose, Ca 95134 > M: +1.510.676.5490 > > > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim > Sent: Tuesday, November 17, 2015 9:09 AM > To: dev at dpdk.org > Subject: [dpdk-dev] DPDK Community Call - ARM Support > > There's been a lot of activity on the mailing list recently on DPDK > support for ARM. It's great to see the project being enhanced to embrace > a new architecture. > > We have seen some duplication of efforts on this, so we think it would > make a good topic for a community call. This will give everybody a > chance to share their plans so we can be clear on who's doing what and > make sure that we avoid overlaps. > > We'll host a community call on this next Tuesday (24th Nov) at 15:00- > 16:00 GMT. Details on the proposed agenda, the time in a couple of other > timezones, and how to join the online meeting are included below. > > > Agenda: > ARMv7 & v8 ports: > - Summary of what's been submitted for 2.2 and what the remaining gaps > are (Dave Hunt) > - Discussion on plans for further contributions in this area > > External Memory Manager: > - Summary of our plans for DPDK 2.3 (Venky Venkatesan) > - Do others plan to do work in this area? > > Other DPDK/ARM plans: > - Does anybody else have plans for ARM-related work in DPDK that they > can share? > > > When: > Tue, Nov 24, 2015 15:00 - 16:00 GMT > Tue, Nov 24, 2015 07:00 - 08:00 PST > Tue, Nov 24, 2015 10:00 - 11:00 EST > Tue, Nov 24, 2015 16:00 - 17:00 PST > > > Meeting Details: > You can join from your computer, tablet or smartphone: > https://global.gotomeeting.com/join/535221101 > > You can also dial in using your phone. > > Access Code: 535-221-101 > > Phone numbers: > United States: +1 (224) 501-3217 > Australia: +61 2 9087 3605 > Austria: +43 7 2088 1403 > Belgium: +32 (0) 28 93 7019 > Canada: +1 (647) 497-9351 > Denmark: +45 69 91 88 64 > Finland: +358 (0) 942 41 5781 > France: +33 (0) 182 880 458 > Germany: +49 (0) 692 5736 7210 > Ireland +353 (0) 14 845 979 > Italy: +39 0 553 98 95 67 > Netherlands: +31 (0) 208 080 381 > New Zealand: +64 4 974 7214 > Norway: +47 21 03 58 98 > Spain: +34 955 32 0845 > Sweden: +46 (0) 853 527 836 > Switzerland: +41 (0) 435 0167 09 > United Kingdom: +44 (0) 330 221 0086 > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy > the information in any medium. Thank you.
[dpdk-dev] [PATCH v4 1/2] vhost: Add callback and private data for vhost PMD
On 2015/11/17 22:29, Yuanhan Liu wrote: > On Fri, Nov 13, 2015 at 02:20:30PM +0900, Tetsuya Mukawa wrote: >> These variables are needed to be able to manage one of virtio devices >> using both vhost library APIs and vhost PMD. >> For example, if vhost PMD uses current callback handler and private data >> provided by vhost library, A DPDK application that links vhost library >> cannot use some of vhost library APIs. > Can you be more specific about this? > > --yliu How about like below? commit log: Currently, when virtio device is created and destroyed, vhost library will call one of callback handlers. The vhost PMD need to use this pair of callback handlers to know which virtio devices are connected actually. Because we can register only one pair of callbacks to vhost library, if the PMD use it, DPDK applications cannot have a way to know the events. This may break legacy DPDK applications that uses vhost library. To prevent it, this patch adds one more pair of callbacks to vhost library especially for the vhost PMD. With the patch, legacy applications can use the vhost PMD even if they need additional specific handling for virtio device creation and destruction. For example, legacy application can call rte_vhost_enable_guest_notification() in callbacks to change setting. Tetsuya
[dpdk-dev] [PATCH] kni: fix compile issue on different kernel versions
> > It fixes the compile issue on kernel version 2.6.32 or old ones.
> >
> > Error logs:
> > lib/librte_eal/linuxapp/kni/kni_misc.c:121: error: unknown field id
> > specified in initializer
> > lib/librte_eal/linuxapp/kni/kni_misc.c:121: error: excess elements in struct
> > initializer
> > lib/librte_eal/linuxapp/kni/kni_misc.c:121: error: (near initialization for
> > kni_net_ops)
> > lib/librte_eal/linuxapp/kni/kni_misc.c:122: error: unknown field size
> > specified in initializer
> > lib/librte_eal/linuxapp/kni/kni_misc.c:122: error: excess elements in struct
> > initializer
> > lib/librte_eal/linuxapp/kni/kni_misc.c:122: error: (near initialization for
> > kni_net_ops)
> >
> > Fixes: 72a7a2b2469e ("kni: allow per-net instances")
> >
> > Signed-off-by: Helin Zhang
>
> Acked-by: Pablo de Lara
Applied, thanks
[dpdk-dev] [PATCH v4 0/2] Add VHOST PMD
On 2015/11/17 22:26, Yuanhan Liu wrote: > On Fri, Nov 13, 2015 at 03:50:16PM +0900, Tetsuya Mukawa wrote: >> On 2015/11/13 14:32, Yuanhan Liu wrote: >>> On Fri, Nov 13, 2015 at 02:20:29PM +0900, Tetsuya Mukawa wrote: The patch introduces a new PMD. This PMD is implemented as thin wrapper of librte_vhost. * Known issue. We may see issues while handling RESET_OWNER message. These handlings are done in vhost library, so not a part of vhost PMD. So far, we are waiting for QEMU fixing. >>> Fix patches have already been applied. Please help test :) >>> >>> --yliu >> Hi Yuanhan, >> >> It seems there might be an another issue related with "vq->callfd" in >> vhost library. >> We may miss something to handle the value correctly. >> >> Anyway, here are steps. >> 1. Apply vhost PMD patch. >> (I guess you don't need it to reproduce the issue, but to reproduce it, >> using the PMD may be easy) >> 2. Start testpmd on host with vhost-user PMD. >> 3. Start QEMU with virtio-net device. >> 4. Login QEMU. >> 5. Bind the virtio-net device to igb_uio. >> 6. Start testpmd in QEMU. >> 7. Quit testmd in QEMU. >> 8. Start testpmd again in QEMU. >> >> It seems when last command is executed, testpmd on host doesn't receive >> SET_VRING_CALL message from QEMU. >> Because of this, testpmd on host assumes virtio-net device is not ready. >> (I made sure virtio_is_ready() was failed on host). >> >> According to QEMU source code, SET_VRING_KICK will be called when >> virtqueue starts, but SET_VRING_CALL will be called when virtqueue is >> initialized. >> Not sure exactly, might be "vq->call" will be valid while connection is >> established? > Yes, it would be valid as far as we don't reset it from another > set_vring_call. So, we should not reset it on reset_device(). > > --yliu Hi Yuanhan, Thanks for checking. I will submit the patch for this today. Tetsuya >> Also I've found a workaround. >> Please execute after step7. >> >> 8. Bind the virtio-net device to virtio-pci kernel driver. >> 9. Bind the virtio-net device to igb_uio. >> 10. Start testpmd in QEMU. >> >> When step8 is executed, connection will be re-established, and testpmd >> on host will be able to receive SET_VRING_CALL. >> Then testpmd on host can start. >> >> Thanks, >> Tetsuya
[dpdk-dev] [PATCH v4 1/2] vhost: Add callback and private data for vhost PMD
On Thu, Nov 19, 2015 at 11:03:50AM +0900, Tetsuya Mukawa wrote: > On 2015/11/17 22:29, Yuanhan Liu wrote: > > On Fri, Nov 13, 2015 at 02:20:30PM +0900, Tetsuya Mukawa wrote: > >> These variables are needed to be able to manage one of virtio devices > >> using both vhost library APIs and vhost PMD. > >> For example, if vhost PMD uses current callback handler and private data > >> provided by vhost library, A DPDK application that links vhost library > >> cannot use some of vhost library APIs. > > Can you be more specific about this? > > > > --yliu > > How about like below? > > commit log: > Currently, when virtio device is created and destroyed, vhost library > will call one of callback handlers. > The vhost PMD need to use this pair of callback handlers to know which > virtio devices are connected actually. > Because we can register only one pair of callbacks to vhost library, if > the PMD use it, DPDK applications > cannot have a way to know the events. Will (and why) the two co-exist at same time? --yliu > This may break legacy DPDK > applications that uses vhost library. > To prevent it, this patch adds one more pair of callbacks to vhost > library especially for the vhost PMD. > With the patch, legacy applications can use the vhost PMD even if they > need additional specific handling > for virtio device creation and destruction. > For example, legacy application can call > rte_vhost_enable_guest_notification() in callbacks to change setting. > > Tetsuya
[dpdk-dev] [RFC PATCH 0/2] Virtio-net PMD Extension to work on host.
What's the reason for using qemu as a middleman? Couldn't the new PMD itself open /dev/vhost-net or the vhost-user socket and send the commands to set up virtqueues? That was the approach taken by Jianfeng's earlier RFC. On Thu, Nov 19, 2015 at 2:57 AM, Tetsuya Mukawa wrote: > THIS IS A PoC IMPLEMENATION. > > [Abstraction] > > Normally, virtio-net PMD only works on VM, because there is no virtio-net > device on host. > This RFC patch extends virtio-net PMD to be able to work on host as > virtual PMD. > But we didn't implement virtio-net device as a part of virtio-net PMD. > To prepare virtio-net device for the PMD, start QEMU process with special > QTest mode, then connect it from virtio-net PMD through unix domain socket. > > The PMD can connect to anywhere QEMU virtio-net device can. > For example, the PMD can connects to vhost-net kernel module and > vhost-user backend application. > Similar to virtio-net PMD on QEMU, application memory that uses virtio-net > PMD will be shared between vhost backend application. > But vhost backend application memory will not be shared. > > Main target of this PMD is container like docker, rkt, lxc and etc. > We can isolate related processes(virtio-net PMD process, QEMU and > vhost-user backend process) by container. > But, to communicate through unix domain socket, shared directory will be > needed. > > > [How to use] > > So far, we need QEMU patch to connect to vhost-user backend. > Please check known issue in later section. > Because of this, I will describe example of using vhost-net kernel module. > > - Compile > Set "CONFIG_RTE_VIRTIO_VDEV=y" in config/common_linux. > Then compile it. > > - Start QEMU like below. > $ sudo qemu-system-x86_64 -qtest unix:/tmp/qtest0,server -machine > accel=qtest \ >-display none -qtest-log /dev/null \ >-netdev > type=tap,script=/etc/qemu-ifup,id=net0,vhost=on \ >-device virtio-net-pci,netdev=net0 \ >-chardev > socket,id=chr1,path=/tmp/ivshmem0,server \ >-device ivshmem,size=1G,chardev=chr1,vectors=1 > > - Start DPDK application like below > $ sudo ./testpmd -c f -n 1 -m 1024 --shm \ > > --vdev="eth_cvio0,qtest=/tmp/qtest0,ivshmem=/tmp/ivshmem0" -- \ > --disable-hw-vlan --txqflags=0xf00 -i > > - Check created tap device. > > (*1) Please Specify same memory size in QEMU and DPDK command line. > > > [Detailed Description] > > - virtio-net device implementation > The PMD uses QEMU virtio-net device. To do that, QEMU QTest functionality > is used. > QTest is a test framework of QEMU devices. It allows us to implement a > device driver outside of QEMU. > With QTest, we can implement DPDK application and virtio-net PMD as > standalone process on host. > When QEMU is invoked as QTest mode, any guest code will not run. > To know more about QTest, see below. > http://wiki.qemu.org/Features/QTest > > - probing devices > QTest provides a unix domain socket. Through this socket, driver process > can access to I/O port and memory of QEMU virtual machine. > The PMD will send I/O port accesses to probe pci devices. > If we can find virtio-net and ivshmem device, initialize the devices. > Also, I/O port accesses of virtio-net PMD will be sent through socket, and > virtio-net PMD can initialize vitio-net device on QEMU correctly. > > - ivshmem device to share memory > To share memory that virtio-net PMD process uses, ivshmem device will be > used. > Because ivshmem device can only handle one file descriptor, shared memory > should be consist of one file. > To allocate such a memory, EAL has new option called "--shm". > If the option is specified, EAL will open a file and allocate memory from > hugepages. > While initializing ivshmem device, we can set BAR(Base Address Register). > It represents which memory QEMU vcpu can access to this shared memory. > We will specify host physical address of shared memory as this address. > It is very useful because we don't need to apply patch to QEMU to > calculate address offset. > (For example, if virtio-net PMD process will allocate memory from shared > memory, then specify the physical address of it to virtio-net register, > QEMU virtio-net device can understand it without calculating address > offset.) > > - Known limitation > So far, the PMD doesn't handle interrupts from QEMU devices. > Because of this, VIRTIO_NET_F_STATUS functionality is dropped. > But without it, we can use all virtio-net functions. > > - Known issues > So far, to use vhost-user, we need to apply vhost-user patch to QEMU and > DPDK vhost library. > This is because, QEMU will not send memory information and file descriptor > of ivshmem device to vhost-user backend. > (Anyway, vhost-net kernel module can receive the information. So > vhost-user behavior will not be correct. I will submit the patch to QEMU > soon) > Also, we may have an issue in DPDK vhost library to
[dpdk-dev] [PATCH v2] kni: Use utsrelease.h to determine Ubuntu kernel version
> > /proc/version_signature is the version for the host machine, but in e.g., > > chroots, > > this does not necessarily match that DPDK is built for. DPDK will then > > build for the > > wrong kernel version - that of the server, and not that installed in the > > (build) > > chroot. > > > > The patch uses utsrelease.h from the kernel sources instead and fakes the > > upload version. > > > > Tested on a server with Ubuntu 12.04, building in a chroot for Ubuntu 14.04. > > > > Signed-off-by: Simon Kagstrom > > Signed-off-by: Johan Faltstrom > Acked-by: Helin Zhang It doesn't fix every cases but Ubuntu chroot in Ubuntu, so Applied, thanks
[dpdk-dev] [PATCH 1/1] config/tile: disable KNI kmod option on tile
2015-11-17 14:23, Zhigang Lu:
> Commit 36080ff96b0e causes compiling error on tile, as tile
> does not support KNI, so we disable the CONFIG_RTE_KNI_KMOD.
>
> Fixes: 36080ff96b0e ("config: add KNI kmod option")
>
> Reported-by: Guo Xin
> Signed-off-by: Zhigang Lu
Applied, thanks
[dpdk-dev] [PATCH] fm10k: fix wrong VLAN value in RX mbuf
On Wed, 18 Nov 2015 16:50:09 +0800
Shaopeng He wrote:
> VLAN value should be copied from RX descriptor to mbuf,
> this patch fixes this issue.
>
> Signed-off-by: Shaopeng He
> ---
> drivers/net/fm10k/fm10k_rxtx.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
> index 1bac28d..eeb635e 100644
> --- a/drivers/net/fm10k/fm10k_rxtx.c
> +++ b/drivers/net/fm10k/fm10k_rxtx.c
> @@ -146,6 +146,7 @@ fm10k_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
> #endif
>
> mbuf->hash.rss = desc.d.rss;
> + mbuf->vlan_tci = desc.w.vlan & FM10K_RXD_VLAN_ID_MASK;
>
> rx_pkts[count] = mbuf;
> if (++next_dd == q->nb_desc) {
> @@ -292,6 +293,7 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct rte_mbuf
> **rx_pkts,
> rx_desc_to_ol_flags(first_seg, );
> #endif
> first_seg->hash.rss = desc.d.rss;
> + first_seg->vlan_tci = desc.w.vlan & FM10K_RXD_VLAN_ID_MASK;
>
> /* Prefetch data of first segment, if configured to do so. */
> rte_packet_prefetch((char *)first_seg->buf_addr +
Good catch, this bug means VLAN's would not work right now.
But I think it isn't quite right.
By masking the VLAN you are losing the received priority bits.
Other drivers like ixgbe preserve the priority bits.
[dpdk-dev] Recap of DPDK Userspace 2015
Hi all, Thanks to everyone who responded to the survey of DPDK Userspace 2015 https://www.surveymonkey.com/r/6TN65VF. You can now view the videos of the presentations and lightning talks from the conference at https://dpdksummit.com/us/en/past-events!! Thanks Siobh?n
[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
On 19/11/2015 06:32, Wang, Zhihong wrote: >> -Original Message- >> From: Xie, Huawei >> Sent: Thursday, November 19, 2015 2:05 PM >> To: Wang, Zhihong ; Stephen Hemminger >> ; Richardson, Bruce >> >> Cc: dev at dpdk.org >> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary >> hugepage zero-filling >> >> On 11/19/2015 10:16 AM, Wang, Zhihong wrote: -Original Message- From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger Sent: Thursday, November 19, 2015 3:09 AM To: Richardson, Bruce Cc: dev at dpdk.org Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling On Wed, 18 Nov 2015 16:13:32 + "Richardson, Bruce" wrote: >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen >> Hemminger >> Sent: Wednesday, November 18, 2015 4:00 PM >> To: Xie, Huawei >> Cc: dev at dpdk.org >> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove >> unnecessary hugepage zero-filling >> >> On Wed, 18 Nov 2015 12:07:54 + >> "Xie, Huawei" wrote: >> >> The kernel fills new allocated (huge) pages with zeros. >> DPDK just has to touch the pages to trigger the allocation. >>> I think we shouldn't reply on the assumption that kernel has >>> zeroed the memory. Kernel zeroes the memory mostly to avoid >>> information leakage.It could also achieve this by setting each bit to 1. >>> What we indeed need to check is later DPDK initialization code >>> doesn't assume the memory has been zeroed. Otherwise zero only >>> that part of the memory. Does this makes sense? >> If all new pages are zero, why does DPDK have to pre-touch the >> pages at all? > The pages won't actually be mapped into the processes address space > until accessed. > /Bruce Isn't that what mmap MAP_POPULATE flag (not currently used) will do. >>> Yes, the MAP_POPULATE does literally the same thing. >>> This flag is implemented since Linux 2.5.46 according to Linux man >>> page, guess that's why DPDK fault the page tables manually in the >>> first place. :) >>> >>> I think we can use this flag since it makes the code clearer. >> The manual says MAP_POPULATE is only supported for private mappings since >> Linux 2.6.23. > I've done check before and MAP_SHARED | MAP_POPULATE worked together > correctly. Is there any implicit complication here? > None that I can see. Sergio >>> /Zhihong >>> >>>
[dpdk-dev] [PATCH] hash: add rte_hash_set_cmp_func() function.
Give user a chance to costomize the hash key compare function.
The default rte_hash_cmp_eq function is set in the rte_hash_create
function, but these builtin ones may not good enough, so the user
may call this to override the default one.
Signed-off-by: Yu Nemo Wenbin
---
lib/librte_hash/rte_cuckoo_hash.c| 7 +--
lib/librte_hash/rte_hash.h | 15 +++
lib/librte_hash/rte_hash_version.map | 1 +
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/lib/librte_hash/rte_cuckoo_hash.c
b/lib/librte_hash/rte_cuckoo_hash.c
index 1e970de..71e2419 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -98,8 +98,6 @@ EAL_REGISTER_TAILQ(rte_hash_tailq)
#define LCORE_CACHE_SIZE 8
-typedef int (*rte_hash_cmp_eq_t)(const void *key1, const void *key2, size_t
key_len);
-
struct lcore_cache {
unsigned len; /**< Cache len */
void *objs[LCORE_CACHE_SIZE]; /**< Cache objects */
@@ -183,6 +181,11 @@ rte_hash_find_existing(const char *name)
return h;
}
+void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t func)
+{
+h->rte_hash_cmp_eq = func;
+}
+
struct rte_hash *
rte_hash_create(const struct rte_hash_parameters *params)
{
diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
index b678766..8378a42 100644
--- a/lib/librte_hash/rte_hash.h
+++ b/lib/librte_hash/rte_hash.h
@@ -66,6 +66,9 @@ typedef uint32_t hash_sig_t;
typedef uint32_t (*rte_hash_function)(const void *key, uint32_t key_len,
uint32_t init_val);
+/** Type of function used to compare the key. It works like the memcmp() */
+typedef int (*rte_hash_cmp_eq_t)(const void *key1, const void *key2, size_t
key_len);
+
/**
* Parameters used when creating the hash table.
*/
@@ -104,6 +107,18 @@ struct rte_hash *
rte_hash_create(const struct rte_hash_parameters *params);
/**
+ * Set the rte_hash_set_cmp_func.
+ * Set the new hash compare function if the default one is not suitable enough.
+ *
+ * @note Function pointer does not work with multi-process, so don't use it
+ * in multi-process mode.
+ *
+ * @param h
+ * Hash table to reset
+ */
+void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t func);
+
+/**
* Find an existing hash table object and return a pointer to it.
*
* @param name
diff --git a/lib/librte_hash/rte_hash_version.map
b/lib/librte_hash/rte_hash_version.map
index 906c8ad..3bc1e2c 100644
--- a/lib/librte_hash/rte_hash_version.map
+++ b/lib/librte_hash/rte_hash_version.map
@@ -30,5 +30,6 @@ DPDK_2.1 {
rte_hash_lookup_data;
rte_hash_lookup_with_hash_data;
rte_hash_reset;
+ rte_hash_set_cmp_func;
} DPDK_2.0;
--
1.9.1
[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
On 18/11/2015 12:07, Xie, Huawei wrote:
> On 11/18/2015 6:45 PM, Wang, Zhihong wrote:
>>> -Original Message-
>>> From: Mcnamara, John
>>> Sent: Wednesday, November 18, 2015 6:40 PM
>>> To: Wang, Zhihong ; dev at dpdk.org
>>> Subject: RE: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary
>>> hugepage zero-filling
>>>
>>>
>>>
-Original Message-
From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhihong Wang
Sent: Wednesday, November 18, 2015 3:27 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary
hugepage zero-filling
The kernel fills new allocated (huge) pages with zeros.
DPDK just has to touch the pages to trigger the allocation.
> I think we shouldn't reply on the assumption that kernel has zeroed the
> memory. Kernel zeroes the memory mostly to avoid information leakage.It
> could also achieve this by setting each bit to 1.
> What we indeed need to check is later DPDK initialization code doesn't
> assume the memory has been zeroed. Otherwise zero only that part of the
> memory. Does this makes sense?
Why cannot we rely on the kernel zeroing the memory ?
If that behavior were to change, then we can zero out the memory ourselves.
Bruce pointed out to me that the semantics have changed a bit since we
introduced
rte_memzone_free.
Before that, all memzone reserve were zero out by default.
Is there code relying on that? I'm not sure, but it still is good
practice to do it.
I submitted an RFC regarding this:
http://dpdk.org/ml/archives/dev/2015-November/028416.html
The idea would be to keep the available memory we are managing zeroed at
all times.
Sergio
...
if (orig) {
hugepg_tbl[i].orig_va = virtaddr;
- memset(virtaddr, 0, hugepage_sz);
+ memset(virtaddr, 0, 8);
}
>>> Probably worth adding a one or two line comment here to avoid someone
>>> thinking that it is a bug at some later stage. The text in the commit
>>> message
>>> above is suitable.
>>>
>> Good suggestion! Will add it :)
>>
>>> John.
>>> --
[dpdk-dev] [PATCH] fm10k: fix wrong VLAN value in RX mbuf
Hi,
Worth to adding comments that vlan_tci is only valid in case
RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE is turned on and
Flag PKT_RX_VLAN_PKT is set.
Best Regards,
Mark
> -Original Message-
> From: He, Shaopeng
> Sent: Wednesday, November 18, 2015 4:50 PM
> To: dev at dpdk.org
> Cc: Chen, Jing D; Qiu, Michael; He, Shaopeng
> Subject: [PATCH] fm10k: fix wrong VLAN value in RX mbuf
>
> VLAN value should be copied from RX descriptor to mbuf,
> this patch fixes this issue.
>
> Signed-off-by: Shaopeng He
> ---
> drivers/net/fm10k/fm10k_rxtx.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/fm10k/fm10k_rxtx.c
> b/drivers/net/fm10k/fm10k_rxtx.c
> index 1bac28d..eeb635e 100644
> --- a/drivers/net/fm10k/fm10k_rxtx.c
> +++ b/drivers/net/fm10k/fm10k_rxtx.c
> @@ -146,6 +146,7 @@ fm10k_recv_pkts(void *rx_queue, struct rte_mbuf
> **rx_pkts,
> #endif
>
> mbuf->hash.rss = desc.d.rss;
> + mbuf->vlan_tci = desc.w.vlan &
> FM10K_RXD_VLAN_ID_MASK;
>
> rx_pkts[count] = mbuf;
> if (++next_dd == q->nb_desc) {
> @@ -292,6 +293,7 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct
> rte_mbuf **rx_pkts,
> rx_desc_to_ol_flags(first_seg, );
> #endif
> first_seg->hash.rss = desc.d.rss;
> + first_seg->vlan_tci = desc.w.vlan &
> FM10K_RXD_VLAN_ID_MASK;
>
> /* Prefetch data of first segment, if configured to do so. */
> rte_packet_prefetch((char *)first_seg->buf_addr +
> --
> 1.9.3
[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
> -Original Message- > From: Xie, Huawei > Sent: Thursday, November 19, 2015 2:05 PM > To: Wang, Zhihong ; Stephen Hemminger > ; Richardson, Bruce > > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary > hugepage zero-filling > > On 11/19/2015 10:16 AM, Wang, Zhihong wrote: > > > >> -Original Message- > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen > >> Hemminger > >> Sent: Thursday, November 19, 2015 3:09 AM > >> To: Richardson, Bruce > >> Cc: dev at dpdk.org > >> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove > >> unnecessary hugepage zero-filling > >> > >> On Wed, 18 Nov 2015 16:13:32 + > >> "Richardson, Bruce" wrote: > >> > >>> > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen > Hemminger > Sent: Wednesday, November 18, 2015 4:00 PM > To: Xie, Huawei > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove > unnecessary hugepage zero-filling > > On Wed, 18 Nov 2015 12:07:54 + > "Xie, Huawei" wrote: > > The kernel fills new allocated (huge) pages with zeros. > DPDK just has to touch the pages to trigger the allocation. > > I think we shouldn't reply on the assumption that kernel has > > zeroed the memory. Kernel zeroes the memory mostly to avoid > > information leakage.It could also achieve this by setting each bit to 1. > > What we indeed need to check is later DPDK initialization code > > doesn't assume the memory has been zeroed. Otherwise zero only > > that part of the memory. Does this makes sense? > If all new pages are zero, why does DPDK have to pre-touch the > pages at all? > >>> The pages won't actually be mapped into the processes address space > >>> until > >> accessed. > >>> /Bruce > >> Isn't that what mmap MAP_POPULATE flag (not currently used) will do. > > Yes, the MAP_POPULATE does literally the same thing. > > This flag is implemented since Linux 2.5.46 according to Linux man > > page, guess that's why DPDK fault the page tables manually in the > > first place. :) > > > > I think we can use this flag since it makes the code clearer. > The manual says MAP_POPULATE is only supported for private mappings since > Linux 2.6.23. I've done check before and MAP_SHARED | MAP_POPULATE worked together correctly. Is there any implicit complication here? > > > > /Zhihong > > > >
[dpdk-dev] [PATCH] i40e: fix the issue dcb cannot be configured when FW version is 5.x
Tested-by: Yulong Pei
-Original Message-
From: Wu, Jingjing
Sent: Monday, November 16, 2015 4:57 PM
To: dev at dpdk.org
Cc: Wu, Jingjing ; Zhang, Helin ; Pei, Yulong
Subject: [PATCH] i40e: fix the issue dcb cannot be configured when FW version
is 5.x
When NVM version is updated to 5.x, DCB can not be configured. This issue is
because of the FW version validation is not correct.
This patch fixed this issue.
Fixes: c8b9a3e3fe1b (i40e: support DCB mode)
Signed-off-by: Jingjing Wu
---
drivers/net/i40e/i40e_ethdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 2c51a0b..9003488 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -8316,7 +8316,8 @@ i40e_dcb_hw_configure(struct i40e_pf *pf,
uint32_t val;
/* Use the FW API if FW > v4.4*/
- if (!((hw->aq.fw_maj_ver == 4) && (hw->aq.fw_min_ver >= 4))) {
+ if (!(((hw->aq.fw_maj_ver == 4) && (hw->aq.fw_min_ver >= 4)) ||
+ (hw->aq.fw_maj_ver >= 5))) {
PMD_INIT_LOG(ERR, "FW < v4.4, can not use FW LLDP API"
" to configure DCB");
return I40E_ERR_FIRMWARE_API_VERSION;
--
2.4.0
[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
On 11/19/2015 11:54 AM, Wang, Zhihong wrote:
>
>> -Original Message-
>> From: Xie, Huawei
>> Sent: Wednesday, November 18, 2015 8:08 PM
>> To: Wang, Zhihong ; Mcnamara, John
>> ; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary
>> hugepage zero-filling
>>
>> On 11/18/2015 6:45 PM, Wang, Zhihong wrote:
-Original Message-
From: Mcnamara, John
Sent: Wednesday, November 18, 2015 6:40 PM
To: Wang, Zhihong ; dev at dpdk.org
Subject: RE: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove
unnecessary hugepage zero-filling
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhihong Wang
> Sent: Wednesday, November 18, 2015 3:27 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove
> unnecessary hugepage zero-filling
>
> The kernel fills new allocated (huge) pages with zeros.
> DPDK just has to touch the pages to trigger the allocation.
>> I think we shouldn't reply on the assumption that kernel has zeroed the
>> memory.
> I understand the concern.
> In my opinion application shouldn't assume malloced memory to be zero-filled.
> So it should be okay for DPDK even if the kernel doesn't zero the page at all.
For malloc, we shouldn't make this assumption because it might allocate
just freed memory from the heap. Hugetlbfs is different. Let us listen
to other people's opinion.
It will make life much easier if we could make this assumption.
>
> I agree that we should check if any code accidentally make that assumption.
> Currently there's rte_pktmbuf_init() for packet mbuf initialization.
>
> /Zhihong
>
>
>> Kernel zeroes the memory mostly to avoid information leakage.It could also
>> achieve this by setting each bit to 1.
>> What we indeed need to check is later DPDK initialization code doesn't assume
>> the memory has been zeroed. Otherwise zero only that part of the memory.
>> Does this makes sense?
>>
> ...
> if (orig) {
> hugepg_tbl[i].orig_va = virtaddr;
> - memset(virtaddr, 0, hugepage_sz);
> + memset(virtaddr, 0, 8);
> }
Probably worth adding a one or two line comment here to avoid someone
thinking that it is a bug at some later stage. The text in the commit
message above is suitable.
>>> Good suggestion! Will add it :)
>>>
John.
--
>
[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
On 11/19/2015 10:16 AM, Wang, Zhihong wrote: > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger >> Sent: Thursday, November 19, 2015 3:09 AM >> To: Richardson, Bruce >> Cc: dev at dpdk.org >> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary >> hugepage zero-filling >> >> On Wed, 18 Nov 2015 16:13:32 + >> "Richardson, Bruce" wrote: >> >>> -Original Message- From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger Sent: Wednesday, November 18, 2015 4:00 PM To: Xie, Huawei Cc: dev at dpdk.org Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling On Wed, 18 Nov 2015 12:07:54 + "Xie, Huawei" wrote: The kernel fills new allocated (huge) pages with zeros. DPDK just has to touch the pages to trigger the allocation. > I think we shouldn't reply on the assumption that kernel has > zeroed the memory. Kernel zeroes the memory mostly to avoid > information leakage.It could also achieve this by setting each bit to 1. > What we indeed need to check is later DPDK initialization code > doesn't assume the memory has been zeroed. Otherwise zero only > that part of the memory. Does this makes sense? If all new pages are zero, why does DPDK have to pre-touch the pages at all? >>> The pages won't actually be mapped into the processes address space until >> accessed. >>> /Bruce >> Isn't that what mmap MAP_POPULATE flag (not currently used) will do. > Yes, the MAP_POPULATE does literally the same thing. > This flag is implemented since Linux 2.5.46 according to Linux man page, > guess that's why DPDK fault the page tables manually in the first place. :) > > I think we can use this flag since it makes the code clearer. The manual says MAP_POPULATE is only supported for private mappings since Linux 2.6.23. > > /Zhihong > >
[dpdk-dev] DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5
I was looking at older thread here it mentions the kernel vmxnet3 pmd dependency with Vmware tsc map, Is this the reason why the CISCO NIC is coming up fine on ESX 6.0 which will have higher version/updated driver and ESX 5.5 has older version of the driver and because of incompatability the NIC is not coming up and initialization fails? Thanks. http://dpdk.org/ml/archives/dev/2013-July/000302.html From: Karmarkar Suyash Sent: Thursday, November 19, 2015 9:03 AM To: 'dev at dpdk.org' Subject: DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5 Hello All, I am trying some experiments with DPDK 1.6 and Cisco NIC - (:06:00.0 Network controller: Cisco Systems Inc. Cisco VIC Ethernet NIC [vmnic0]), on the guest I am using VMXNET3 as interface/pmd and one weird behavior that is see is with VMWare ESX 5.5 DPDK is not able to initialize the NIC and I get the error rte_eth_dev_start failed with error code as, but same NIC and with DPDK 1.6 version works fine with VMWare ESX 6.0 and with VMXNET3 PMD. Two questions: 1. Is there any dependency with VMWare version ESX (5.0/5.1/6.0) with DPDK Release version (1.6/1.7/2.x)? If yes can you please let me know? 2. If we are not using the NIC in pass-through mode and we are using it via Hypervisor - vmxnet3 or virtio pmd is there still a dependency for the list of NIC's supported by DPDK? Regards Suyash
[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
> -Original Message-
> From: Xie, Huawei
> Sent: Wednesday, November 18, 2015 8:08 PM
> To: Wang, Zhihong ; Mcnamara, John
> ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary
> hugepage zero-filling
>
> On 11/18/2015 6:45 PM, Wang, Zhihong wrote:
> >> -Original Message-
> >> From: Mcnamara, John
> >> Sent: Wednesday, November 18, 2015 6:40 PM
> >> To: Wang, Zhihong ; dev at dpdk.org
> >> Subject: RE: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove
> >> unnecessary hugepage zero-filling
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhihong Wang
> >>> Sent: Wednesday, November 18, 2015 3:27 AM
> >>> To: dev at dpdk.org
> >>> Subject: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove
> >>> unnecessary hugepage zero-filling
> >>>
> >>> The kernel fills new allocated (huge) pages with zeros.
> >>> DPDK just has to touch the pages to trigger the allocation.
> I think we shouldn't reply on the assumption that kernel has zeroed the
> memory.
I understand the concern.
In my opinion application shouldn't assume malloced memory to be zero-filled.
So it should be okay for DPDK even if the kernel doesn't zero the page at all.
I agree that we should check if any code accidentally make that assumption.
Currently there's rte_pktmbuf_init() for packet mbuf initialization.
/Zhihong
> Kernel zeroes the memory mostly to avoid information leakage.It could also
> achieve this by setting each bit to 1.
> What we indeed need to check is later DPDK initialization code doesn't assume
> the memory has been zeroed. Otherwise zero only that part of the memory.
> Does this makes sense?
>
> >>> ...
> >>> if (orig) {
> >>> hugepg_tbl[i].orig_va = virtaddr;
> >>> - memset(virtaddr, 0, hugepage_sz);
> >>> + memset(virtaddr, 0, 8);
> >>> }
> >> Probably worth adding a one or two line comment here to avoid someone
> >> thinking that it is a bug at some later stage. The text in the commit
> >> message above is suitable.
> >>
> > Good suggestion! Will add it :)
> >
> >> John.
> >> --
> >
[dpdk-dev] DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5
Hello All, I am trying some experiments with DPDK 1.6 and Cisco NIC - (:06:00.0 Network controller: Cisco Systems Inc. Cisco VIC Ethernet NIC [vmnic0]), on the guest I am using VMXNET3 as interface/pmd and one weird behavior that is see is with VMWare ESX 5.5 DPDK is not able to initialize the NIC and I get the error rte_eth_dev_start failed with error code as, but same NIC and with DPDK 1.6 version works fine with VMWare ESX 6.0 and with VMXNET3 PMD. Two questions: 1. Is there any dependency with VMWare version ESX (5.0/5.1/6.0) with DPDK Release version (1.6/1.7/2.x)? If yes can you please let me know? 2. If we are not using the NIC in pass-through mode and we are using it via Hypervisor - vmxnet3 or virtio pmd is there still a dependency for the list of NIC's supported by DPDK? Regards Suyash
[dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger > Sent: Thursday, November 19, 2015 3:09 AM > To: Richardson, Bruce > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary > hugepage zero-filling > > On Wed, 18 Nov 2015 16:13:32 + > "Richardson, Bruce" wrote: > > > > > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen > > > Hemminger > > > Sent: Wednesday, November 18, 2015 4:00 PM > > > To: Xie, Huawei > > > Cc: dev at dpdk.org > > > Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove > > > unnecessary hugepage zero-filling > > > > > > On Wed, 18 Nov 2015 12:07:54 + > > > "Xie, Huawei" wrote: > > > > > > > >>> The kernel fills new allocated (huge) pages with zeros. > > > > >>> DPDK just has to touch the pages to trigger the allocation. > > > > I think we shouldn't reply on the assumption that kernel has > > > > zeroed the memory. Kernel zeroes the memory mostly to avoid > > > > information leakage.It could also achieve this by setting each bit to 1. > > > > What we indeed need to check is later DPDK initialization code > > > > doesn't assume the memory has been zeroed. Otherwise zero only > > > > that part of the memory. Does this makes sense? > > > > > > If all new pages are zero, why does DPDK have to pre-touch the pages > > > at all? > > > > The pages won't actually be mapped into the processes address space until > accessed. > > > > /Bruce > > Isn't that what mmap MAP_POPULATE flag (not currently used) will do. Yes, the MAP_POPULATE does literally the same thing. This flag is implemented since Linux 2.5.46 according to Linux man page, guess that's why DPDK fault the page tables manually in the first place. :) I think we can use this flag since it makes the code clearer. /Zhihong
[dpdk-dev] [PATCH v6 1/5] ethdev: Added ETH_SPEED_CAP bitmap for ports
Hi Thomas,
2015-11-01 23:11 GMT+01:00 Thomas Monjalon :
> 2015-10-25 22:59, Marc Sune:
> > +#define ETH_SPEED_CAP_NOT_PHY(0) /*< No phy media > */
> > +#define ETH_SPEED_CAP_10M_HD (1 << 0) /*< 10 Mbps half-duplex> */
> > +#define ETH_SPEED_CAP_10M_FD (1 << 1) /*< 10 Mbps full-duplex> */
> > +#define ETH_SPEED_CAP_100M_HD(1 << 2) /*< 100 Mbps
> half-duplex> */
> > +#define ETH_SPEED_CAP_100M_FD(1 << 3) /*< 100 Mbps
> full-duplex> */
> > +#define ETH_SPEED_CAP_1G (1 << 4) /*< 1 Gbps > */
> > +#define ETH_SPEED_CAP_2_5G (1 << 5) /*< 2.5 Gbps > */
> > +#define ETH_SPEED_CAP_5G (1 << 6) /*< 5 Gbps > */
> > +#define ETH_SPEED_CAP_10G(1 << 7) /*< 10 Mbps > */
> > +#define ETH_SPEED_CAP_20G(1 << 8) /*< 20 Gbps > */
> > +#define ETH_SPEED_CAP_25G(1 << 9) /*< 25 Gbps > */
> > +#define ETH_SPEED_CAP_40G(1 << 10) /*< 40 Gbps > */
> > +#define ETH_SPEED_CAP_50G(1 << 11) /*< 50 Gbps > */
> > +#define ETH_SPEED_CAP_56G(1 << 12) /*< 56 Gbps > */
> > +#define ETH_SPEED_CAP_100G (1 << 13) /*< 100 Gbps > */
>
> In the patch 3, you rename this flags. It would be easier to understand if
> the right names were used in the first patch.
>
> > @@ -837,6 +860,7 @@ struct rte_eth_dev_info {
> > uint16_t vmdq_queue_base; /**< First queue ID for VMDQ pools. */
> > uint16_t vmdq_queue_num; /**< Queue number for VMDQ pools. */
> > uint16_t vmdq_pool_base; /**< First ID of VMDQ pools. */
> > + uint32_t speed_capa; /**< Supported speeds bitmap
> (ETH_SPEED_CAP_). */
>
> When renaming ETH_SPEED_CAP, this line is not changed later.
>
This is made in purpose.
In patch 3/5 the bitmap speeds are renamed to ETH_LINK_SPEED_XXX and
numeric values are moved ETH_SPEED_NUM_XXX, to make clear the difference. I
cannot, in this commit, rename them directly to ETH_LINK_SPEED_XXX since
they would collide with the current numeric speeds.
Thanks
Marc
