[dpdk-dev] [PATCH] examples/ip_fragmentation: add fragmentation size support
Adding support for determining fragmentation size for both
ipv4 and ipv6 traffic dynamically through command line.
It is helpful in testing to configure different fragmentation
sizes and validate the packets.
Signed-off-by: Ashish Jain
Signed-off-by: Hemant Agrawal
---
examples/ip_fragmentation/main.c | 89
1 file changed, 81 insertions(+), 8 deletions(-)
diff --git a/examples/ip_fragmentation/main.c b/examples/ip_fragmentation/main.c
index 815b225..436755b 100644
--- a/examples/ip_fragmentation/main.c
+++ b/examples/ip_fragmentation/main.c
@@ -94,6 +94,16 @@
#defineIPV6_DEFAULT_PAYLOAD(IPV6_MTU_DEFAULT - sizeof(struct
ipv6_hdr))
/*
+ * Configure fragmentation size for IPv4 and IPv6 packets
+ */
+static uint32_t frag_size_v4 = IPV4_MTU_DEFAULT;
+static uint32_t frag_size_v6 = IPV6_MTU_DEFAULT;
+#define MIN_IPV4_FRAG_SIZE 64
+#define MAX_IPV4_FRAG_SIZE 9600
+#define MIN_IPV6_FRAG_SIZE 1280
+#define MAX_IPV6_FRAG_SIZE 9600
+
+/*
* Max number of fragments per packet expected - defined by config file.
*/
#defineMAX_PACKET_FRAG RTE_LIBRTE_IP_FRAG_MAX_FRAG
@@ -299,14 +309,14 @@ struct rte_lpm6_config lpm6_config = {
}
/* if we don't need to do any fragmentation */
- if (likely (IPV4_MTU_DEFAULT >= m->pkt_len)) {
+ if (likely (frag_size_v4 >= m->pkt_len)) {
qconf->tx_mbufs[port_out].m_table[len] = m;
len2 = 1;
} else {
len2 = rte_ipv4_fragment_packet(m,
&qconf->tx_mbufs[port_out].m_table[len],
(uint16_t)(MBUF_TABLE_SIZE - len),
- IPV4_MTU_DEFAULT,
+ frag_size_v4,
rxq->direct_pool, rxq->indirect_pool);
/* Free input packet */
@@ -336,14 +346,14 @@ struct rte_lpm6_config lpm6_config = {
}
/* if we don't need to do any fragmentation */
- if (likely (IPV6_MTU_DEFAULT >= m->pkt_len)) {
+ if (likely (frag_size_v6 >= m->pkt_len)) {
qconf->tx_mbufs[port_out].m_table[len] = m;
len2 = 1;
} else {
len2 = rte_ipv6_fragment_packet(m,
&qconf->tx_mbufs[port_out].m_table[len],
(uint16_t)(MBUF_TABLE_SIZE - len),
- IPV6_MTU_DEFAULT,
+ frag_size_v6,
rxq->direct_pool, rxq->indirect_pool);
/* Free input packet */
@@ -489,8 +499,14 @@ struct rte_lpm6_config lpm6_config = {
{
printf("%s [EAL options] -- -p PORTMASK [-q NQ]\n"
" -p PORTMASK: hexadecimal bitmask of ports to configure\n"
- " -q NQ: number of queue (=ports) per lcore (default is 1)\n",
- prgname);
+ " -q NQ: number of queue (=ports) per lcore (default is 1)\n"
+ " --frag_size_v4=:optional,IPv4 fragment size in decimal"
+ ",Condition:(frag_size_v4 - 20) should be a multiple of 8,"
+ " default is %d \n"
+ " --frag_size_v6=:optional,IPv6 fragment size in decimal"
+ ",Condition:(frag_size_v6 - 40) should be a multiple of 8,"
+ " default is %d\n",
+ prgname, frag_size_v4, frag_size_v6);
}
static int
@@ -528,6 +544,29 @@ struct rte_lpm6_config lpm6_config = {
return n;
}
+static int
+parse_frag_size(const char *str, uint32_t min, uint32_t max,
+ uint8_t hdr_size, uint32_t *val)
+{
+ char *end;
+ uint64_t v;
+
+ /* parse decimal string */
+ errno = 0;
+ v = strtoul(str, &end, 10);
+ if (errno != 0 || *end != '\0')
+ return -EINVAL;
+
+ if (v < min || v > max)
+ return -EINVAL;
+
+ if ((v - hdr_size) % 8)
+ return -EINVAL;
+
+ *val = (uint32_t)v;
+ return 0;
+}
+
/* Parse the argument given in the command line of the application */
static int
parse_args(int argc, char **argv)
@@ -537,6 +576,8 @@ struct rte_lpm6_config lpm6_config = {
int option_index;
char *prgname = argv[0];
static struct option lgopts[] = {
+ {"frag_size_v4", 1, 0, 0},
+ {"frag_size_v6", 1, 0, 0},
{NULL, 0, 0, 0}
};
@@ -568,8 +609,40 @@ struct rte_lpm6_config lpm6_config = {
/* long options */
case 0:
- print_usage(prgname);
- return -1;
+ if (!strncmp(lgopts[option_index].name,
+ "frag_size_v4", 12)) {
+ ret = parse_frag_size(optarg,
+
[dpdk-dev] [PATCH dpdk 1/5] vfio/ppc64/spapr: Use correct structures for add/remove windows
This copies structures passed via VFIO_IOMMU_SPAPR_TCE_CREATE and
VFIO_IOMMU_SPAPR_TCE_REMOVE ioctls. The existing ones cannot possible work.
Signed-off-by: Alexey Kardashevskiy
---
lib/librte_eal/linuxapp/eal/eal_vfio.h | 8
1 file changed, 8 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.h
b/lib/librte_eal/linuxapp/eal/eal_vfio.h
index 239ac4d8d..4a0283cb4 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.h
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.h
@@ -69,13 +69,21 @@ struct vfio_iommu_spapr_register_memory {
struct vfio_iommu_spapr_tce_create {
uint32_t argsz;
+ uint32_t flags;
+ /* in */
uint32_t page_shift;
+ uint32_t __resv1;
uint64_t window_size;
uint32_t levels;
+ uint32_t __resv2;
+ /* out */
+ uint64_t start_addr;
};
struct vfio_iommu_spapr_tce_remove {
uint32_t argsz;
+ uint32_t flags;
+ /* in */
uint64_t start_addr;
};
--
2.11.0
[dpdk-dev] [PATCH dpdk 0/5] ppc64/spapr: Attempt to use on POWER8
Hi! This is my first attempt to use DPDK on POWER8 machine and yet unsuccessful as it turned out DPDK only supports IB-Mellanox (I only got ethernet-Mellanox, and requires OFED), rmmod on Intel 40Gb module produces PCI errors (unrelated to DPDK) and Broadcom bnx2x has few issues (below) and still crashes as I suspect I got DMA mapping wrong, here is a backtrace: Configuring Port 0 (socket 0) PMD: bnx2x_issue_dmae_with_comp(): DMAE timeout! PANIC in bnx2x_write_dmae(): DMAE failed (-1)22: [/lib/powerpc64le-linux-gnu/libc.so.6(__libc_start_main+0xb8) [0x3fffb7c23298]] 21: [/lib/powerpc64le-linux-gnu/libc.so.6(+0x2309c) [0x3fffb7c2309c]] 20: [/home/aik/pbuild/dpdk_build/app/testpmd(main+0x228) [0x100255d0]] 19: [/home/aik/pbuild/dpdk_build/app/testpmd(start_port+0x5dc) [0x1002341c]] 18: [/home/aik/pbuild/dpdk_build/app/testpmd(rte_eth_dev_start+0xc4) [0x1008b3c0]] 17: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x10117550]] 16: [/home/aik/pbuild/dpdk_build/app/testpmd(bnx2x_init+0x204) [0x100f7210]] 15: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x100f6888]] 14: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x100ee7f4]] 13: [/home/aik/pbuild/dpdk_build/app/testpmd(ecore_func_state_change+0x250) [0x10127794]] 12: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x1012734c]] 11: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x10126830]] 10: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x10126618]] 9: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x10100a98]] 8: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x100ffe00]] 7: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x100de614]] 6: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x100de4cc]] 5: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x101063c0]] 4: [/home/aik/pbuild/dpdk_build/app/testpmd() [0x100e1f6c]] 3: [/home/aik/pbuild/dpdk_build/app/testpmd(bnx2x_write_dmae+0x11c) [0x100e1e40]] 2: [/home/aik/pbuild/dpdk_build/app/testpmd(__rte_panic+0x8c) [0x100b3e58]] 1: [/home/aik/pbuild/dpdk_build/app/testpmd(rte_dump_stack+0x40) [0x100b3cc4]] Thread 1 "testpmd" received signal SIGABRT, Aborted. 0x3fffb7c3edb0 in __GI_raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. Still, some fixes are quite obvious and straigtforward. This is based on sha1 2fc8e0bf0 Olivier Matz "log: fix dump of registered logs when disabled". Please comment. Thanks. Alexey Kardashevskiy (5): vfio/ppc64/spapr: Use correct structures for add/remove windows pci: Initialize common rte driver pointer RFC: bnx2x: Update firmware versions vfio: Do try setting IOMMU type if already set RFC: vfio/ppc64/spapr: Use correct bus addresses for DMA map lib/librte_eal/linuxapp/eal/eal_vfio.h | 8 + drivers/net/bnx2x/bnx2x.c | 4 +-- lib/librte_eal/common/eal_common_pci.c | 1 + lib/librte_eal/linuxapp/eal/eal_vfio.c | 62 +++--- 4 files changed, 46 insertions(+), 29 deletions(-) -- 2.11.0
[dpdk-dev] [PATCH dpdk 3/5] RFC: bnx2x: Update firmware versions
Recent kernels/distros have updated firmware images, use them.
Signed-off-by: Alexey Kardashevskiy
---
drivers/net/bnx2x/bnx2x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 1a7e1c8e1..17e8c6b4c 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -9535,8 +9535,8 @@ static void bnx2x_init_rte(struct bnx2x_softc *sc)
}
#define FW_HEADER_LEN 104
-#define FW_NAME_57711 "/lib/firmware/bnx2x/bnx2x-e1h-7.2.51.0.fw"
-#define FW_NAME_57810 "/lib/firmware/bnx2x/bnx2x-e2-7.2.51.0.fw"
+#define FW_NAME_57711 "/lib/firmware/bnx2x/bnx2x-e1h-7.13.1.0.fw"
+#define FW_NAME_57810 "/lib/firmware/bnx2x/bnx2x-e2-7.12.30.0.fw"
void bnx2x_load_firmware(struct bnx2x_softc *sc)
{
--
2.11.0
[dpdk-dev] [PATCH dpdk 2/5] pci: Initialize common rte driver pointer
The existing code initializes a PCI driver pointer but not the common one. As the result, ring_dma_zone_reserve() in drivers/net/bnx2x/bnx2x_rxtx.c crashed as dev->device->driver==NULL. This adds missing initialization. Signed-off-by: Alexey Kardashevskiy --- lib/librte_eal/common/eal_common_pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/librte_eal/common/eal_common_pci.c b/lib/librte_eal/common/eal_common_pci.c index 6f0d4d8e4..b6b41be31 100644 --- a/lib/librte_eal/common/eal_common_pci.c +++ b/lib/librte_eal/common/eal_common_pci.c @@ -244,6 +244,7 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr, /* reference driver structure */ dev->driver = dr; + dev->device.driver = &dr->driver; /* call the driver probe() function */ ret = dr->probe(dr, dev); -- 2.11.0
[dpdk-dev] [PATCH dpdk 4/5] vfio: Do try setting IOMMU type if already set
The existing code correctly checks if a container is set to a group and
does not try attaching a group to a container for a second/third/...
device from the same IOMMU group.
However it still tries to set IOMMU type to a container for every device
in a group which produces failure and closes container and group fds.
This moves vfio_set_iommu_type() and DMA mapping code under:
if (!(group_status.flags & VFIO_GROUP_FLAGS_CONTAINER_SET))
Signed-off-by: Alexey Kardashevskiy
---
lib/librte_eal/linuxapp/eal/eal_vfio.c | 50 +-
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_vfio.c
index 6e2e84ca7..46f951f4d 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -298,33 +298,33 @@ vfio_setup_device(const char *sysfs_base, const char
*dev_addr,
clear_group(vfio_group_fd);
return -1;
}
- }
- /*
-* pick an IOMMU type and set up DMA mappings for container
-*
-* needs to be done only once, only when first group is assigned to
-* a container and only in primary process. Note this can happen several
-* times with the hotplug functionality.
-*/
- if (internal_config.process_type == RTE_PROC_PRIMARY &&
- vfio_cfg.vfio_active_groups == 1) {
- /* select an IOMMU type which we will be using */
- const struct vfio_iommu_type *t =
+ /*
+* pick an IOMMU type and set up DMA mappings for container
+*
+* needs to be done only once, only when first group is
assigned to
+* a container and only in primary process. Note this can
happen several
+* times with the hotplug functionality.
+*/
+ if (internal_config.process_type == RTE_PROC_PRIMARY &&
+ vfio_cfg.vfio_active_groups == 1) {
+ /* select an IOMMU type which we will be using */
+ const struct vfio_iommu_type *t =
vfio_set_iommu_type(vfio_cfg.vfio_container_fd);
- if (!t) {
- RTE_LOG(ERR, EAL, " %s failed to select IOMMU type\n",
dev_addr);
- close(vfio_group_fd);
- clear_group(vfio_group_fd);
- return -1;
- }
- ret = t->dma_map_func(vfio_cfg.vfio_container_fd);
- if (ret) {
- RTE_LOG(ERR, EAL, " %s DMA remapping failed, "
- "error %i (%s)\n", dev_addr, errno,
strerror(errno));
- close(vfio_group_fd);
- clear_group(vfio_group_fd);
- return -1;
+ if (!t) {
+ RTE_LOG(ERR, EAL, " %s failed to select IOMMU
type\n", dev_addr);
+ close(vfio_group_fd);
+ clear_group(vfio_group_fd);
+ return -1;
+ }
+ ret = t->dma_map_func(vfio_cfg.vfio_container_fd);
+ if (ret) {
+ RTE_LOG(ERR, EAL, " %s DMA remapping failed, "
+ "error %i (%s)\n", dev_addr,
errno, strerror(errno));
+ close(vfio_group_fd);
+ clear_group(vfio_group_fd);
+ return -1;
+ }
}
}
--
2.11.0
[dpdk-dev] [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus addresses for DMA map
VFIO_IOMMU_SPAPR_TCE_CREATE ioctl() returns the actual bus address for
just created DMA window. It happens to start from zero because the default
window is removed (leaving no windows) and new window starts from zero.
However this is not guaranteed and the new window may start from another
address, this adds an error check.
Another issue is that IOVA passed to VFIO_IOMMU_MAP_DMA should be a PCI
bus address while in this case a physical address of a user page is used.
This changes IOVA to start from zero in a hope that the rest of DPDK
expects this.
Signed-off-by: Alexey Kardashevskiy
---
lib/librte_eal/linuxapp/eal/eal_vfio.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_vfio.c
index 46f951f4d..8b8e75c4f 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -658,7 +658,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
{
const struct rte_memseg *ms = rte_eal_get_physmem_layout();
int i, ret;
-
+ phys_addr_t io_offset;
struct vfio_iommu_spapr_register_memory reg = {
.argsz = sizeof(reg),
.flags = 0
@@ -702,6 +702,13 @@ vfio_spapr_dma_map(int vfio_container_fd)
return -1;
}
+ io_offset = create.start_addr;
+ if (io_offset) {
+ RTE_LOG(ERR, EAL, " DMA offsets other than zero is not
supported, "
+ "new window is created at %lx\n", io_offset);
+ return -1;
+ }
+
/* map all DPDK segments for DMA. use 1:1 PA to IOVA mapping */
for (i = 0; i < RTE_MAX_MEMSEG; i++) {
struct vfio_iommu_type1_dma_map dma_map;
@@ -723,7 +730,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
dma_map.argsz = sizeof(struct vfio_iommu_type1_dma_map);
dma_map.vaddr = ms[i].addr_64;
dma_map.size = ms[i].len;
- dma_map.iova = ms[i].phys_addr;
+ dma_map.iova = io_offset;
dma_map.flags = VFIO_DMA_MAP_FLAG_READ |
VFIO_DMA_MAP_FLAG_WRITE;
@@ -735,6 +742,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
return -1;
}
+ io_offset += dma_map.size;
}
return 0;
--
2.11.0
Re: [dpdk-dev] [PATCH 1/2] eal/ppc: fix mmap for memory initialization
06/04/2017 12:06, Chao Zhu:
> On IBM POWER platform, when mapping /dev/zero file to hugepage memory
> space, mmap will not respect the requested address hint. This will cause
> the memory initilization for the second process fails. This patch adds
> the required mmap flags to make it work. Beside this, users need to set
> the nr_overcommit_hugepages to expand the VA range. When
> doing the initilization, users need to set both nr_hugepages and
> nr_overcommit_hugepages to the same value, like 64, 128, etc.
>
> Signed-off-by: Chao Zhu
> ---
> lib/librte_eal/linuxapp/eal/eal_memory.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
> b/lib/librte_eal/linuxapp/eal/eal_memory.c index a956bb2..e06186b 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> @@ -313,7 +313,11 @@ int rte_xen_dom0_supported(void)
> }
> do {
> addr = mmap(addr,
> +#ifndef RTE_ARCH_PPC_64
> (*size) + hugepage_sz, PROT_READ, MAP_PRIVATE,
> fd, 0);
> +#else
> +(*size) + hugepage_sz, PROT_READ, MAP_PRIVATE |
> MAP_ANONYMOUS | MAP_HUGETLB, fd, 0); +#endif
> if (addr == MAP_FAILED)
> *size -= hugepage_sz;
> } while (addr == MAP_FAILED && *size > 0);
> @@ -1330,7 +1334,11 @@ static int huge_wrap_sigsetjmp(void)
>* use mmap to get identical addresses as the primary process.
>*/
> base_addr = mmap(mcfg->memseg[s].addr, mcfg->memseg[s].len,
> +#ifndef RTE_ARCH_PPC_64
>PROT_READ, MAP_PRIVATE, fd_zero, 0);
> +#else
> + PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB,
> fd_zero, 0); +#endif
> if (base_addr == MAP_FAILED ||
> base_addr != mcfg->memseg[s].addr) {
> max_seg = s;
Indentation and line length are wrong.
Changed to this:
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -331,7 +331,13 @@ get_virtual_area(size_t *size, size_t hugepage_sz)
}
do {
addr = mmap(addr,
- (*size) + hugepage_sz, PROT_READ, MAP_PRIVATE,
fd, 0);
+ (*size) + hugepage_sz, PROT_READ,
+#ifdef RTE_ARCH_PPC_64
+ MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB,
+#else
+ MAP_PRIVATE,
+#endif
+ fd, 0);
if (addr == MAP_FAILED)
*size -= hugepage_sz;
} while (addr == MAP_FAILED && *size > 0);
@@ -1359,7 +1365,13 @@ rte_eal_hugepage_attach(void)
* use mmap to get identical addresses as the primary process.
*/
base_addr = mmap(mcfg->memseg[s].addr, mcfg->memseg[s].len,
-PROT_READ, MAP_PRIVATE, fd_zero, 0);
+PROT_READ,
+#ifdef RTE_ARCH_PPC_64
+MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB,
+#else
+MAP_PRIVATE,
+#endif
+fd_zero, 0);
if (base_addr == MAP_FAILED ||
base_addr != mcfg->memseg[s].addr) {
max_seg = s;
Re: [dpdk-dev] [PATCH 1/2] eal/ppc: fix mmap for memory initialization
13/04/2017 10:14, Sergio Gonzalez Monroy: > On 06/04/2017 11:06, Chao Zhu wrote: > > On IBM POWER platform, when mapping /dev/zero file to hugepage memory > > space, mmap will not respect the requested address hint. This will cause > > the memory initilization for the second process fails. This patch adds > > the required mmap flags to make it work. Beside this, users need to set > > the nr_overcommit_hugepages to expand the VA range. When > > doing the initilization, users need to set both nr_hugepages and > > nr_overcommit_hugepages to the same value, like 64, 128, etc. > > > > Signed-off-by: Chao Zhu > > Acked-by: Sergio Gonzalez Monroy Series fixed, squashed and applied, thanks
[dpdk-dev] [PATCH] net/i40e: fix compilation error in ppc64le
From: Gowrishankar Muthukrishnan
A typo introduced in i40e_rxtx_vec_altivec.c from commit 67f038076657
("net/i40e: enable per-device packet type mapping"). This patch is to
address compilation error in ppc64le.
Signed-off-by: Gowrishankar Muthukrishnan
---
drivers/net/i40e/i40e_rxtx_vec_altivec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
index 07de31b..f4036ea 100644
--- a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
+++ b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
@@ -208,13 +208,13 @@
ptype1 = vec_sr(ptype1, (vector unsigned long){30, 30});
rx_pkts[0]->packet_type =
- ptype_tbl[(*(vector unsigned char *)&ptype0)[0])];
+ ptype_tbl[(*(vector unsigned char *)&ptype0)[0]];
rx_pkts[1]->packet_type =
- ptype_tbl[(*(vector unsigned char *)&ptype0)[8])];
+ ptype_tbl[(*(vector unsigned char *)&ptype0)[8]];
rx_pkts[2]->packet_type =
- ptype_tbl[(*(vector unsigned char *)&ptype1)[0])];
+ ptype_tbl[(*(vector unsigned char *)&ptype1)[0]];
rx_pkts[3]->packet_type =
- ptype_tbl[(*(vector unsigned char *)&ptype1)[8])];
+ ptype_tbl[(*(vector unsigned char *)&ptype1)[8]];
}
/* Notice:
--
1.9.1
Re: [dpdk-dev] [PATCH v9 10/13] doc: add NXP dpaa2 sec in cryptodev
> -Original Message- > From: akhil.go...@nxp.com [mailto:akhil.go...@nxp.com] > Sent: Thursday, April 20, 2017 6:44 AM > To: dev@dpdk.org > Cc: Doherty, Declan; De Lara Guarch, Pablo; Mcnamara, John; > hemant.agra...@nxp.com > Subject: [PATCH v9 10/13] doc: add NXP dpaa2 sec in cryptodev > > From: Akhil Goyal > > Signed-off-by: Akhil Goyal > Reviewed-by: Hemant Agrawal > Acked-by: John McNamara Hi, Could you update release notes, as this probably deserves it? :) The rest of the patchset looks good, so either send a v10 or tell me the note you want to add and I can do it for you. Thanks for the work! Pablo
[dpdk-dev] [PATCH] net/i40e: fix core dump during testpmd setup
Testpmd failed to start when CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
is disabled, the root cause is the length of sw_ring is incorrect with
the above configuration.
Fixes: 0be295312966 ("net/i40e: fix compile error")
Signed-off-by: Beilei Xing
---
drivers/net/i40e/i40e_rxtx.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index e5471b1..4244de8 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -1816,11 +1816,7 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
rxq->rx_ring_phys_addr = rte_mem_phy2mch(rz->memseg_id, rz->phys_addr);
rxq->rx_ring = (union i40e_rx_desc *)rz->addr;
-#ifdef RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
len = (uint16_t)(nb_desc + RTE_PMD_I40E_RX_MAX_BURST);
-#else
- len = nb_desc;
-#endif
/* Allocate the software ring. */
rxq->sw_ring =
--
2.5.5
Re: [dpdk-dev] [PATCH] net/i40e: fix compilation error in ppc64le
20/04/2017 09:39, Gowrishankar:
> From: Gowrishankar Muthukrishnan
>
> A typo introduced in i40e_rxtx_vec_altivec.c from commit 67f038076657
> ("net/i40e: enable per-device packet type mapping"). This patch is to
> address compilation error in ppc64le.
>
> Signed-off-by: Gowrishankar Muthukrishnan
>
Applied, thanks
Please try to avoid such compilation issue by reviewing/testing patches
before they are applied.
[dpdk-dev] CLI parsing issue
Hi Olivier,
I met a problem thar the parsing result of CLI is wrong.
I checked this function, cmdline_parse. It will check the CLI instances one by
one. Even if an instance is matched, the parsing will not stop for ambiguous
check. Seems the following check may change the parsing result of the previous
one,
/* fully parsed */
tok = match_inst(inst, buf, 0, result.buf,
sizeof(result.buf),
&dyn_tokens);
Is it better to use a temporary validate for match_inst and only store the
result when it matches, so the previous result has no chance to be changed?
Like bellow,
diff --git a/lib/librte_cmdline/cmdline_parse.c
b/lib/librte_cmdline/cmdline_parse.c
index 763c286..663efd1 100644
--- a/lib/librte_cmdline/cmdline_parse.c
+++ b/lib/librte_cmdline/cmdline_parse.c
@@ -259,6 +259,7 @@
char buf[CMDLINE_PARSE_RESULT_BUFSIZE];
long double align; /* strong alignment constraint for buf */
} result;
+ char tmp_buf[CMDLINE_PARSE_RESULT_BUFSIZE];
cmdline_parse_token_hdr_t *dyn_tokens[CMDLINE_PARSE_DYNAMIC_TOKENS];
void (*f)(void *, struct cmdline *, void *) = NULL;
void *data = NULL;
@@ -321,7 +322,7 @@
debug_printf("INST %d\n", inst_num);
/* fully parsed */
- tok = match_inst(inst, buf, 0, result.buf, sizeof(result.buf),
+ tok = match_inst(inst, buf, 0, tmp_buf, sizeof(tmp_buf),
&dyn_tokens);
if (tok > 0) /* we matched at least one token */
@@ -329,6 +330,8 @@
else if (!tok) {
debug_printf("INST fully parsed\n");
+ memcpy(result.buf, tmp_buf,
+ CMDLINE_PARSE_RESULT_BUFSIZE);
/* skip spaces */
while (isblank2(*curbuf)) {
curbuf++;
Best regards
Wenzhuo Lu
[dpdk-dev] [PATCH] doc: update release notes for dpaa2 sec pmd
From: Akhil Goyal Signed-off-by: Akhil Goyal --- doc/guides/rel_notes/release_17_05.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/guides/rel_notes/release_17_05.rst b/doc/guides/rel_notes/release_17_05.rst index 25e7144..c7fae86 100644 --- a/doc/guides/rel_notes/release_17_05.rst +++ b/doc/guides/rel_notes/release_17_05.rst @@ -175,6 +175,12 @@ New Features "Network Interface Controller Drivers" document for more details on this new driver. +* **Added NXP DPAA2 SEC crypto PMD.** + + A new "dpaa2_sec" hardware based crypto PMD for NXP DPAA2 devices has been + added. See the "Crypto Device Drivers" document for more details on this + driver. + * **Added support for the Wind River Systems AVP PMD.** Added a new networking driver for the AVP device type. Theses devices are -- 2.9.3
[dpdk-dev] [PATCH v2] net/i40e: fix testpmd setup error when bulk is disabled
Testpmd failed to start when CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
is disabled, the root cause is the length of sw_ring and queue are
incorrect with the above configuration.
Fixes: 0be295312966 ("net/i40e: fix compile error")
Signed-off-by: Beilei Xing
---
v2 change:
Correct the length of queue when BULK is disabled.
drivers/net/i40e/i40e_rxtx.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index e5471b1..9f697d7 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -1791,13 +1791,11 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
/* Allocate the maximun number of RX ring hardware descriptor. */
len = I40E_MAX_RING_DESC;
-#ifdef RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
/**
* Allocating a little more memory because vectorized/bulk_alloc Rx
* functions doesn't check boundaries each time.
*/
len += RTE_PMD_I40E_RX_MAX_BURST;
-#endif
ring_size = RTE_ALIGN(len * sizeof(union i40e_rx_desc),
I40E_DMA_MEM_ALIGN);
@@ -1816,11 +1814,7 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
rxq->rx_ring_phys_addr = rte_mem_phy2mch(rz->memseg_id, rz->phys_addr);
rxq->rx_ring = (union i40e_rx_desc *)rz->addr;
-#ifdef RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
len = (uint16_t)(nb_desc + RTE_PMD_I40E_RX_MAX_BURST);
-#else
- len = nb_desc;
-#endif
/* Allocate the software ring. */
rxq->sw_ring =
--
2.5.5
Re: [dpdk-dev] CLI parsing issue
Hi Wenzhuo,
On Thu, 20 Apr 2017 08:36:38 +, "Lu, Wenzhuo" wrote:
> Hi Olivier,
> I met a problem thar the parsing result of CLI is wrong.
> I checked this function, cmdline_parse. It will check the CLI instances one
> by one. Even if an instance is matched, the parsing will not stop for
> ambiguous check. Seems the following check may change the parsing result of
> the previous one,
> /* fully parsed */
> tok = match_inst(inst, buf, 0, result.buf,
> sizeof(result.buf),
> &dyn_tokens);
>
>
> Is it better to use a temporary validate for match_inst and only store the
> result when it matches, so the previous result has no chance to be changed?
> Like bellow,
>
>
> diff --git a/lib/librte_cmdline/cmdline_parse.c
> b/lib/librte_cmdline/cmdline_parse.c
> index 763c286..663efd1 100644
> --- a/lib/librte_cmdline/cmdline_parse.c
> +++ b/lib/librte_cmdline/cmdline_parse.c
> @@ -259,6 +259,7 @@
> char buf[CMDLINE_PARSE_RESULT_BUFSIZE];
> long double align; /* strong alignment constraint for buf */
> } result;
> + char tmp_buf[CMDLINE_PARSE_RESULT_BUFSIZE];
> cmdline_parse_token_hdr_t *dyn_tokens[CMDLINE_PARSE_DYNAMIC_TOKENS];
> void (*f)(void *, struct cmdline *, void *) = NULL;
> void *data = NULL;
> @@ -321,7 +322,7 @@
> debug_printf("INST %d\n", inst_num);
>
> /* fully parsed */
> - tok = match_inst(inst, buf, 0, result.buf, sizeof(result.buf),
> + tok = match_inst(inst, buf, 0, tmp_buf, sizeof(tmp_buf),
> &dyn_tokens);
>
> if (tok > 0) /* we matched at least one token */
> @@ -329,6 +330,8 @@
>
> else if (!tok) {
> debug_printf("INST fully parsed\n");
> + memcpy(result.buf, tmp_buf,
> + CMDLINE_PARSE_RESULT_BUFSIZE);
> /* skip spaces */
> while (isblank2(*curbuf)) {
> curbuf++;
>
>
At first glance, I think your patch doesn't hurt. Do you have an example
code that triggers the issue?
Thanks,
Olivier
Re: [dpdk-dev] [PATCH v2] net/i40e: fix testpmd setup error when bulk is disabled
> -Original Message-
> From: Xing, Beilei
> Sent: Thursday, April 20, 2017 4:52 PM
> To: Wu, Jingjing ; Zhang, Qi Z
> Cc: dev@dpdk.org
> Subject: [PATCH v2] net/i40e: fix testpmd setup error when bulk is disabled
>
> Testpmd failed to start when
> CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
> is disabled, the root cause is the length of sw_ring and queue are incorrect
> with the above configuration.
>
> Fixes: 0be295312966 ("net/i40e: fix compile error")
>
> Signed-off-by: Beilei Xing
> ---
> v2 change:
> Correct the length of queue when BULK is disabled.
>
> drivers/net/i40e/i40e_rxtx.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c index
> e5471b1..9f697d7 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -1791,13 +1791,11 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev
> *dev,
> /* Allocate the maximun number of RX ring hardware descriptor. */
> len = I40E_MAX_RING_DESC;
>
> -#ifdef RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
> /**
>* Allocating a little more memory because vectorized/bulk_alloc Rx
>* functions doesn't check boundaries each time.
>*/
> len += RTE_PMD_I40E_RX_MAX_BURST;
> -#endif
>
> ring_size = RTE_ALIGN(len * sizeof(union i40e_rx_desc),
> I40E_DMA_MEM_ALIGN);
> @@ -1816,11 +1814,7 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev
> *dev,
> rxq->rx_ring_phys_addr = rte_mem_phy2mch(rz->memseg_id,
> rz->phys_addr);
> rxq->rx_ring = (union i40e_rx_desc *)rz->addr;
>
> -#ifdef RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
> len = (uint16_t)(nb_desc + RTE_PMD_I40E_RX_MAX_BURST); -#else
> - len = nb_desc;
> -#endif
>
> /* Allocate the software ring. */
> rxq->sw_ring =
> --
> 2.5.5
Acked-by: Qi Zhang
[dpdk-dev] [PATCH v2] igb_uio: switch to pci_alloc_irq_vectors()
pci_enable_msix() will be removed in kernel 4.12. The new API is available
since linux 4.8, thus let's use it.
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aff171641d18
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=4244de1c64de
Signed-off-by: Nicolas Dichtel
Reviewed-by: David Marchand
---
v2: use compat.h and define HAVE_PCI_ENABLE_MSIX
limit commit log to 75 columns
lib/librte_eal/linuxapp/igb_uio/compat.h | 4
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 11 +++
2 files changed, 15 insertions(+)
diff --git a/lib/librte_eal/linuxapp/igb_uio/compat.h
b/lib/librte_eal/linuxapp/igb_uio/compat.h
index 0d781e482562..c396faea87d3 100644
--- a/lib/librte_eal/linuxapp/igb_uio/compat.h
+++ b/lib/librte_eal/linuxapp/igb_uio/compat.h
@@ -33,6 +33,10 @@
#define PCI_MSIX_ENTRY_CTRL_MASKBIT1
#endif
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 8, 0)
+#define HAVE_PCI_ENABLE_MSIX
+#endif
+
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34) && \
(!(defined(RHEL_RELEASE_CODE) && \
RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(5, 9)))
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 192bd4a96b68..b9d427c51c57 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -325,7 +325,9 @@ static int
igbuio_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
struct rte_uio_pci_dev *udev;
+#ifdef HAVE_PCI_ENABLE_MSIX
struct msix_entry msix_entry;
+#endif
dma_addr_t map_dma_addr;
void *map_addr;
int err;
@@ -381,6 +383,7 @@ igbuio_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
switch (igbuio_intr_mode_preferred) {
case RTE_INTR_MODE_MSIX:
/* Only 1 msi-x vector needed */
+#ifdef HAVE_PCI_ENABLE_MSIX
msix_entry.entry = 0;
if (pci_enable_msix(dev, &msix_entry, 1) == 0) {
dev_dbg(&dev->dev, "using MSI-X");
@@ -389,6 +392,14 @@ igbuio_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
udev->mode = RTE_INTR_MODE_MSIX;
break;
}
+#else
+ if (pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_MSIX) == 1) {
+ dev_dbg(&dev->dev, "using MSI-X");
+ udev->info.irq = pci_irq_vector(dev, 0);
+ udev->mode = RTE_INTR_MODE_MSIX;
+ break;
+ }
+#endif
/* fall back to INTX */
case RTE_INTR_MODE_LEGACY:
if (pci_intx_mask_supported(dev)) {
--
2.11.0
Re: [dpdk-dev] [PATCH v4 1/3] lib/librte_ether: add support for port reset
Hi, Yuanhan
> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan@linux.intel.com]
> Sent: Thursday, April 20, 2017 2:08 PM
> To: Zhao1, Wei
> Cc: Ananyev, Konstantin ; Mcnamara, John
> ; dev@dpdk.org; Lu, Wenzhuo
> ; Thomas Monjalon ; Liu,
> Yu Y
> Subject: Re: [dpdk-dev] [PATCH v4 1/3] lib/librte_ether: add support for port
> reset
>
> On Thu, Apr 06, 2017 at 02:57:29AM +, Zhao1, Wei wrote:
> > > > + * Reset an ethernet device when it's not working. One scenario
> > > > + is, after PF
> > > > + * port is down and up, the related VF port should be reset.
> > > > + * The API will stop the port, clear the rx/tx queues, re-setup
> > > > + the rx/tx
> > > > + * queues, restart the port.
> > >
> > > s/The API/This function/
> > >
> > > Please explain exactly the responsibility of this function, and how
> > > it is different from calling stop/configure/start.
> >
> > In this reset feature, reset function can do the calling
> > stop/configure/start process, but also It can also do some restore
> > work for the port, for example, it can restore the added parameters of
> vlan, mac_addrs, promisc_unicast_enabled falg and
> promisc_multicast_enabled flag.
> > Maybe , I should add this explanation in the patch comments or function
> comments?
>
> I'm curious why we have to do save & restore for a reset operation.
> Why some configures have to be saved and restored? Doesn't "reset"
> literally means reset everything?
>
Users maybe do not want to do a second configuration operation to waste time
after reset which lost all previous configuration.
But he still want these configuration valid after reset.
So, save & restore can help them to save this process time and effort.
> Even though, how do you tell what kind of configures need be restored and
> what should not? Again, even though, will all PMDs supports restoring the
> same set of configurations?
>
Yes, this is hard to say what may be need and what may be not for user.
Now, the kinds of supported is list in patch set comment. And only i40e NIC
support this feature.
> While looking at your reset implementation for i40e, it looks more complex
> than necessary: just thinking we have to call "xxx_queue_setup"
> for all PMDs.
>
> I'm thinking a simple hardware reset might be enough?
>
> /* literally reset the hardware: reset everything */
> rte_eth_reset(port)
> {
> eth_dev->ops->reset();
> }
>
You mean just do a reset and do not restore any configuration?
That may not meet the need for this feature from customer?
> Assume the application already has a function (say, port_init()) to initiate a
> specific port, it then just needs do something like following to handle the
> case you described in the commit log:
>
> rte_eth_reset(port);
> port_init(port);
>
You mean "rte_eth_reset" is the function of "rte_eth_dev_reset"?
I do not find any function named rte_eth_reset.
> Makes sense? Sorry it's completely wrong; I've limited knowledge on NIC
> pmd drivers after all :/
>
> --yliu
Re: [dpdk-dev] [PATCH] doc: update release notes for dpaa2 sec pmd
> -Original Message- > From: akhil.go...@nxp.com [mailto:akhil.go...@nxp.com] > Sent: Thursday, April 20, 2017 9:47 AM > To: dev@dpdk.org > Cc: Doherty, Declan; De Lara Guarch, Pablo; hemant.agra...@nxp.com; > Mcnamara, John; nhor...@tuxdriver.com; tho...@monjalon.net; Akhil > Goyal > Subject: [PATCH] doc: update release notes for dpaa2 sec pmd > > From: Akhil Goyal > > Signed-off-by: Akhil Goyal Squashed into the DPAA2 SEC PMD patchset.
Re: [dpdk-dev] [PATCH v9 00/13] Introducing NXP dpaa2_sec based cryptodev pmd
> -Original Message- > From: akhil.go...@nxp.com [mailto:akhil.go...@nxp.com] > Sent: Thursday, April 20, 2017 6:44 AM > To: dev@dpdk.org > Cc: Doherty, Declan; De Lara Guarch, Pablo; Mcnamara, John; > hemant.agra...@nxp.com > Subject: [PATCH v9 00/13] Introducing NXP dpaa2_sec based cryptodev > pmd > > From: Hemant Agrawal > > Based over the DPAA2 PMD driver [1], this series of patches introduces the > DPAA2_SEC PMD which provides DPDK crypto driver for NXP's DPAA2 > CAAM > Hardware accelerator. > > SEC is NXP DPAA2 SoC's security engine for cryptographic acceleration and > offloading. It implements block encryption, stream cipher, hashing and > public key algorithms. It also supports run-time integrity checking, and a > hardware random number generator. > > Besides the objects exposed in [1], another key object has been added > through this patch: Series applied to dpdk-next-crypto. Thanks for the work, Pablo
[dpdk-dev] [pull-request] next-crypto 17.05 RC2
The following changes since commit e4701c7a4eec9367819da0ea4ed8572310fe0832: net/i40e: fix build on ppc64le (2017-04-20 10:21:59 +0200) are available in the git repository at: http://dpdk.org/git/next/dpdk-next-crypto for you to fetch changes up to 37ed2fa87d38f89e2ac8132dcb7e6d4a896e2cd7: test/crypto: add dpaa2 sec crypto functional test (2017-04-20 10:32:45 +0100) Akhil Goyal (13): cryptodev: add cryptodev type for dpaa2 sec crypto/dpaa2_sec: add dpaa2 sec poll mode driver crypto/dpaa2_sec: add mc dpseci object support crypto/dpaa2_sec: add basic crypto operations crypto/dpaa2_sec: add run time assembler for descriptor formation crypto/dpaa2_sec: add sample descriptors for PMD operations bus/fslmc: add packet frame list entry definitions crypto/dpaa2_sec: add crypto operation support crypto/dpaa2_sec: statistics support doc: add NXP dpaa2 sec in cryptodev maintainers: claim responsibility for dpaa2 sec PMD test/crypto: add dpaa2 sec crypto performance test test/crypto: add dpaa2 sec crypto functional test Arek Kusztal (3): crypto/qat: fix capabilities for D15xx device crypto/qat: fix AES-GCM authentication length crypto/qat: fix IV zero physical address Fan Zhang (8): crypto/scheduler: fix capability update crypto/scheduler: add mode specific option support crypto/scheduler: fix queue pair configuration crypto/scheduler: fix Doxygen comments app/crypto-perf: fix crypto operation resubmission crypto/scheduler: improve commandline parsing examples/l2fwd-crypto: add cryptodev mask option crypto/scheduler: fix ring dequeue return handling Pablo de Lara (11): crypto/qat: fix incomplete capabilities app/crypto-perf: fix possible overflow test/crypto: create only one virtual device if needed test/crypto: create unique driver name app/crypto-perf: fix length for wireless algos app/crypto-perf: fix AEAD tests when AAD is zero examples/l2fwd-crypto: fix AEAD tests when AAD is zero drivers/crypto: check if name is NULL drivers/crypto: do not create unique name internally examples/l2fwd-crypto: fix padding calculation crypto/scheduler: fix uninitialized capability structure MAINTAINERS|6 + app/test-crypto-perf/cperf_ops.c | 32 +- app/test-crypto-perf/cperf_test_latency.c |2 +- app/test-crypto-perf/cperf_test_throughput.c | 13 + app/test-crypto-perf/cperf_test_vectors.c |2 +- config/common_base |8 + config/defconfig_arm64-dpaa2-linuxapp-gcc | 12 + doc/api/doxy-api-index.md |3 +- doc/api/doxy-api.conf |1 + doc/guides/cryptodevs/dpaa2_sec.rst| 232 ++ doc/guides/cryptodevs/features/dpaa2_sec.ini | 34 + doc/guides/cryptodevs/index.rst|1 + doc/guides/cryptodevs/scheduler.rst|7 + doc/guides/nics/dpaa2.rst |2 + doc/guides/rel_notes/release_17_05.rst |8 + doc/guides/sample_app_ug/l2_forward_crypto.rst |7 +- drivers/Makefile |1 + drivers/bus/fslmc/portal/dpaa2_hw_pvt.h| 25 + drivers/bus/fslmc/rte_bus_fslmc_version.map|1 + drivers/crypto/Makefile|2 + drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 22 +- drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 22 +- drivers/crypto/armv8/rte_armv8_pmd.c | 23 +- drivers/crypto/dpaa2_sec/Makefile | 78 + drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c| 1656 + drivers/crypto/dpaa2_sec/dpaa2_sec_logs.h | 70 + drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 368 +++ drivers/crypto/dpaa2_sec/hw/compat.h | 123 + drivers/crypto/dpaa2_sec/hw/desc.h | 2565 drivers/crypto/dpaa2_sec/hw/desc/algo.h| 431 drivers/crypto/dpaa2_sec/hw/desc/common.h | 97 + drivers/crypto/dpaa2_sec/hw/desc/ipsec.h | 1513 drivers/crypto/dpaa2_sec/hw/rta.h | 920 +++ .../crypto/dpaa2_sec/hw/rta/fifo_load_store_cmd.h | 312 +++ drivers/crypto/dpaa2_sec/hw/rta/header_cmd.h | 217 ++ drivers/crypto/dpaa2_sec/hw/rta/jump_cmd.h | 173 ++ drivers/crypto/dpaa2_sec/hw/rta/key_cmd.h | 188 ++ drivers/crypto/dpaa2_sec/hw/rta/load_cmd.h | 301 +++ drivers/crypto/dpaa2_sec/hw/rta/math_cmd.h | 368 +++ drivers/crypto/dpaa2_sec/hw/rta/move_cmd.h | 411 drivers/crypto/dpaa2_sec/hw/rta/nfifo_cmd.h| 162 ++ drivers/crypto/dpaa2_sec/hw/r
[dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped SFP/SFP+
From: Srinivasan Jayarajan
Adds support to use a different SFP/SFP+ without restarting the
DPDK app. rte_eth_dev_stop()/rte_eth_dev_start() will need
to be called on the port to detect the SFP/SFP+ change.
Signed-off-by: Srinivasan Jayarajan
---
drivers/net/ixgbe/ixgbe_ethdev.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index c226e0a..85407a9 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2520,6 +2520,19 @@ static int eth_ixgbevf_pci_remove(struct rte_pci_device
*pci_dev)
status = ixgbe_pf_reset_hw(hw);
if (status != 0)
return -1;
+
+ /* Set phy type as unknown so that PHY scan is always done */
+ hw->phy.type = ixgbe_phy_unknown;
+
+ /* Identify PHY and related function pointers */
+ status = hw->phy.ops.init(hw);
+
+ if (status == IXGBE_ERR_SFP_NOT_SUPPORTED) {
+ PMD_INIT_LOG(ERR, "Found unsupported SFP in "
+ "ixgbe_dev_start(): %d", status);
+ return -1;
+ }
+
hw->mac.ops.start_hw(hw);
hw->mac.get_link_status = true;
--
1.8.1.4
Re: [dpdk-dev] [PATCH] test/test: improve dequeue logic for crypto operation
Hi Pablo, On 4/4/2017 8:41 PM, De Lara Guarch, Pablo wrote: Hi Akhil, -Original Message- From: akhil.go...@nxp.com [mailto:akhil.go...@nxp.com] Sent: Monday, April 03, 2017 11:53 AM To: dev@dpdk.org Cc: Doherty, Declan; De Lara Guarch, Pablo; Akhil Goyal Subject: [PATCH] test/test: improve dequeue logic for crypto operation From: Akhil Goyal While enqueue/dequeue operations in test_perf_aes_sha, the underlying implementation may not be able to dequeue the same number of buffers as enqueued. So, it may be necessary to perform more dequeue operations if the gap is more than pparams->burst_size * NUM_MBUF_SETS. Other algos may also need to update the logic if required. In which way this patch improves the dequeue logic? Is it improving the performance somehow? From what I see, it is unlikely that you are going to experience the problem, as the internal ring is PERF_NUM_OPS_INFLIGHT, which is 128, higher than pparams->burst_size * NUM_MBUF_SETS, which is 256. And even if you do meet that problem, then you would be reusing mbufs, but that is OK as we are not verifying the output. Thanks, Pablo Sorry for the late response. Somehow the reply went to junk in my mail client and it got missed. The problem would arise if the underlying implementation cannot dequeue the same number of ops as were enqueued in a single dequeue command. Here we have a synchronous calls to enqueue and dequeue in the same thread, so it may happen that for every enqueue of 32 ops, there are lesser number of dequeue ops (say 16). There is no thread to dequeue the left over 16 ops. So the difference would increase slowly and gradually and the application will run out of buffers. So we need a mechanism to drain the left over dequeue ops. Regards, Akhil
Re: [dpdk-dev] [PATCH v2] igb_uio: switch to pci_alloc_irq_vectors()
On 4/20/2017 10:01 AM, Nicolas Dichtel wrote: > pci_enable_msix() will be removed in kernel 4.12. The new API is available > since linux 4.8, thus let's use it. > > Link: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aff171641d18 > Link: > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=4244de1c64de > Signed-off-by: Nicolas Dichtel > Reviewed-by: David Marchand <...> > +#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 8, 0) > +#define HAVE_PCI_ENABLE_MSIX > +#endif Would you mind moving this check to the end of the file, to preserve version check in increasing order (although I aware some doesn't fit this)? When above done: Acked-by: Ferruh Yigit
[dpdk-dev] "Cannot configure device: err=-16" resource busy error on running dpdk applications
Hi, I was trying to run l2fwd and ip_pipeline example programs. But I am getting the following error. ./build/app/l2fwd -c 0x3 --vdev=eth_af_packet0,iface=eno4 --vdev=eth_af_packet1,iface=eno3 -- -p 0x3 EAL: Detected 32 lcore(s) EAL: Probing VFIO support... PMD: Initializing pmd_af_packet for eth_af_packet0 PMD: eth_af_packet0: AF_PACKET MMAP parameters: PMD: eth_af_packet0:block size 4096 PMD: eth_af_packet0:block count 256 PMD: eth_af_packet0:frame size 2048 PMD: eth_af_packet0:frame count 512 PMD: eth_af_packet0: creating AF_PACKET-backed ethdev on numa socket 0 PMD: Initializing pmd_af_packet for eth_af_packet1 PMD: eth_af_packet1: AF_PACKET MMAP parameters: PMD: eth_af_packet1:block size 4096 PMD: eth_af_packet1:block count 256 PMD: eth_af_packet1:frame size 2048 PMD: eth_af_packet1:frame count 512 PMD: eth_af_packet1: creating AF_PACKET-backed ethdev on numa socket 0 PMD: bnxt_rte_pmd_init() called for (null) Lcore 0: RX port 0 Lcore 1: RX port 1 Initializing port 0... EAL: Error - exiting with code: 1 Cause: Cannot configure device: err=-16, port=0 IHow can I solve this issue? Thanks for your reply and help. -- Regards, Nidhia Varghese
Re: [dpdk-dev] [PATCH v2] igb_uio: switch to pci_alloc_irq_vectors()
Le 20/04/2017 à 13:59, Ferruh Yigit a écrit : > On 4/20/2017 10:01 AM, Nicolas Dichtel wrote: >> pci_enable_msix() will be removed in kernel 4.12. The new API is available >> since linux 4.8, thus let's use it. >> >> Link: >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aff171641d18 >> Link: >> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=4244de1c64de >> Signed-off-by: Nicolas Dichtel >> Reviewed-by: David Marchand > > <...> > >> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 8, 0) >> +#define HAVE_PCI_ENABLE_MSIX >> +#endif > > Would you mind moving this check to the end of the file, to preserve > version check in increasing order (although I aware some doesn't fit this)? No problem. I put this stuff here to keep pci_msix stuff together. Regards, Nicolas
[dpdk-dev] [PATCH v3] igb_uio: switch to pci_alloc_irq_vectors()
pci_enable_msix() will be removed in kernel 4.12. The new API is available
since linux 4.8, thus let's use it.
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aff171641d18
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=4244de1c64de
Signed-off-by: Nicolas Dichtel
Reviewed-by: David Marchand
Acked-by: Ferruh Yigit
---
v3: move code in compat.h at the end of the file
v2: use compat.h and define HAVE_PCI_ENABLE_MSIX
limit commit log to 75 columns
lib/librte_eal/linuxapp/igb_uio/compat.h | 4
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 11 +++
2 files changed, 15 insertions(+)
diff --git a/lib/librte_eal/linuxapp/igb_uio/compat.h
b/lib/librte_eal/linuxapp/igb_uio/compat.h
index 0d781e482562..b800a53cd30b 100644
--- a/lib/librte_eal/linuxapp/igb_uio/compat.h
+++ b/lib/librte_eal/linuxapp/igb_uio/compat.h
@@ -123,3 +123,7 @@ static bool pci_check_and_mask_intx(struct pci_dev *pdev)
}
#endif /* < 3.3.0 */
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 8, 0)
+#define HAVE_PCI_ENABLE_MSIX
+#endif
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 192bd4a96b68..b9d427c51c57 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -325,7 +325,9 @@ static int
igbuio_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
struct rte_uio_pci_dev *udev;
+#ifdef HAVE_PCI_ENABLE_MSIX
struct msix_entry msix_entry;
+#endif
dma_addr_t map_dma_addr;
void *map_addr;
int err;
@@ -381,6 +383,7 @@ igbuio_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
switch (igbuio_intr_mode_preferred) {
case RTE_INTR_MODE_MSIX:
/* Only 1 msi-x vector needed */
+#ifdef HAVE_PCI_ENABLE_MSIX
msix_entry.entry = 0;
if (pci_enable_msix(dev, &msix_entry, 1) == 0) {
dev_dbg(&dev->dev, "using MSI-X");
@@ -389,6 +392,14 @@ igbuio_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
udev->mode = RTE_INTR_MODE_MSIX;
break;
}
+#else
+ if (pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_MSIX) == 1) {
+ dev_dbg(&dev->dev, "using MSI-X");
+ udev->info.irq = pci_irq_vector(dev, 0);
+ udev->mode = RTE_INTR_MODE_MSIX;
+ break;
+ }
+#endif
/* fall back to INTX */
case RTE_INTR_MODE_LEGACY:
if (pci_intx_mask_supported(dev)) {
--
2.11.0
Re: [dpdk-dev] [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus addresses for DMA map
On 20/04/17 19:04, Jonas Pfefferle1 wrote:
> Alexey Kardashevskiy wrote on 20/04/2017 09:24:02:
>
>> From: Alexey Kardashevskiy
>> To: dev@dpdk.org
>> Cc: Alexey Kardashevskiy , j...@zurich.ibm.com,
>> Gowrishankar Muthukrishnan
>> Date: 20/04/2017 09:24
>> Subject: [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus
>> addresses for DMA map
>>
>> VFIO_IOMMU_SPAPR_TCE_CREATE ioctl() returns the actual bus address for
>> just created DMA window. It happens to start from zero because the default
>> window is removed (leaving no windows) and new window starts from zero.
>> However this is not guaranteed and the new window may start from another
>> address, this adds an error check.
>>
>> Another issue is that IOVA passed to VFIO_IOMMU_MAP_DMA should be a PCI
>> bus address while in this case a physical address of a user page is used.
>> This changes IOVA to start from zero in a hope that the rest of DPDK
>> expects this.
>
> This is not the case. DPDK expects a 1:1 mapping PA==IOVA. It will use the
> phys_addr of the memory segment it got from /proc/self/pagemap cf.
> librte_eal/linuxapp/eal/eal_memory.c. We could try setting it here to the
> actual iova which basically makes the whole virtual to phyiscal mapping
> with pagemap unnecessary which I believe should be the case for VFIO
> anyway. Pagemap should only be needed when using pci_uio.
Ah, ok, makes sense now. But it sure needs a big fat comment there as it is
not obvious why host RAM address is used there as DMA window start is not
guaranteed.
>
>>
>> Signed-off-by: Alexey Kardashevskiy
>> ---
>> lib/librte_eal/linuxapp/eal/eal_vfio.c | 12 ++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c b/lib/
>> librte_eal/linuxapp/eal/eal_vfio.c
>> index 46f951f4d..8b8e75c4f 100644
>> --- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
>> +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
>> @@ -658,7 +658,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
>> {
>> const struct rte_memseg *ms = rte_eal_get_physmem_layout();
>> int i, ret;
>> -
>> + phys_addr_t io_offset;
>> struct vfio_iommu_spapr_register_memory reg = {
>>.argsz = sizeof(reg),
>>.flags = 0
>> @@ -702,6 +702,13 @@ vfio_spapr_dma_map(int vfio_container_fd)
>>return -1;
>> }
>>
>> + io_offset = create.start_addr;
>> + if (io_offset) {
>> + RTE_LOG(ERR, EAL, " DMA offsets other than zero is not supported, "
>> +"new window is created at %lx\n", io_offset);
>> + return -1;
>> + }
>> +
>> /* map all DPDK segments for DMA. use 1:1 PA to IOVA mapping */
>> for (i = 0; i < RTE_MAX_MEMSEG; i++) {
>>struct vfio_iommu_type1_dma_map dma_map;
>> @@ -723,7 +730,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
>>dma_map.argsz = sizeof(struct vfio_iommu_type1_dma_map);
>>dma_map.vaddr = ms[i].addr_64;
>>dma_map.size = ms[i].len;
>> - dma_map.iova = ms[i].phys_addr;
>> + dma_map.iova = io_offset;
>>dma_map.flags = VFIO_DMA_MAP_FLAG_READ |
>> VFIO_DMA_MAP_FLAG_WRITE;
>>
>> @@ -735,6 +742,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
>> return -1;
>>}
>>
>> + io_offset += dma_map.size;
>> }
>>
>> return 0;
>> --
>> 2.11.0
>>
>
--
Alexey
Re: [dpdk-dev] [PATCH 0/4] update ixgbe base driver to version 2017-03-29
Hi, Ferruh The first patch is to align a fix in firmware. The second is to fix the miss of support of 2.5G PHY which is also needed by some customers. The third is to fix LED support on MAC X550em/X557. We have just verified them with fixed firmware. So if it is accepted, some customers can get these support. Thanks & Best Regards -Wei > -Original Message- > From: Yigit, Ferruh > Sent: Wednesday, April 19, 2017 9:22 PM > To: Dai, Wei > Cc: Zhang, Helin ; Ananyev, Konstantin > ; Lu, Wenzhuo ; > dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/4] update ixgbe base driver to version > 2017-03-29 > > On 4/18/2017 7:56 AM, Wei Dai wrote: > > This patch set has following 4 patches. > > No any new device id is added. > > > > net/ixgbe/base: acquire PHY semaphore before device reset > > net/ixgbe/base: add support for 2.5G KX physical layer > > net/ixgbe/base: add MAC X550em/X557 LED on/off support > > net/ixgbe/base: update base driver version to 2017.03.29 > > Hi Wei, > > This base code update received very close to RC2. I am postponing to next > release. > > If this set has a critical fix for release, please shout for RC3 inclusion. > > Thanks, > ferruh
Re: [dpdk-dev] [PATCH v3] igb_uio: switch to pci_alloc_irq_vectors()
20/04/2017 15:11, Nicolas Dichtel: > pci_enable_msix() will be removed in kernel 4.12. The new API is available > since linux 4.8, thus let's use it. > > Link: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/? > id=aff171641d18 Link: > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/? > id=4244de1c64de Signed-off-by: Nicolas Dichtel > Reviewed-by: David Marchand > Acked-by: Ferruh Yigit Applied, thanks
Re: [dpdk-dev] [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus addresses for DMA map
On 20/04/17 23:25, Alexey Kardashevskiy wrote:
> On 20/04/17 19:04, Jonas Pfefferle1 wrote:
>> Alexey Kardashevskiy wrote on 20/04/2017 09:24:02:
>>
>>> From: Alexey Kardashevskiy
>>> To: dev@dpdk.org
>>> Cc: Alexey Kardashevskiy , j...@zurich.ibm.com,
>>> Gowrishankar Muthukrishnan
>>> Date: 20/04/2017 09:24
>>> Subject: [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus
>>> addresses for DMA map
>>>
>>> VFIO_IOMMU_SPAPR_TCE_CREATE ioctl() returns the actual bus address for
>>> just created DMA window. It happens to start from zero because the default
>>> window is removed (leaving no windows) and new window starts from zero.
>>> However this is not guaranteed and the new window may start from another
>>> address, this adds an error check.
>>>
>>> Another issue is that IOVA passed to VFIO_IOMMU_MAP_DMA should be a PCI
>>> bus address while in this case a physical address of a user page is used.
>>> This changes IOVA to start from zero in a hope that the rest of DPDK
>>> expects this.
>>
>> This is not the case. DPDK expects a 1:1 mapping PA==IOVA. It will use the
>> phys_addr of the memory segment it got from /proc/self/pagemap cf.
>> librte_eal/linuxapp/eal/eal_memory.c. We could try setting it here to the
>> actual iova which basically makes the whole virtual to phyiscal mapping
>> with pagemap unnecessary which I believe should be the case for VFIO
>> anyway. Pagemap should only be needed when using pci_uio.
>
>
> Ah, ok, makes sense now. But it sure needs a big fat comment there as it is
> not obvious why host RAM address is used there as DMA window start is not
> guaranteed.
Well, either way there is some bug - ms[i].phys_addr and ms[i].addr_64 both
have exact same value, in my setup it is 3fffb33c which is a userspace
address - at least ms[i].phys_addr must be physical address.
>
>
>>
>>>
>>> Signed-off-by: Alexey Kardashevskiy
>>> ---
>>> lib/librte_eal/linuxapp/eal/eal_vfio.c | 12 ++--
>>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c b/lib/
>>> librte_eal/linuxapp/eal/eal_vfio.c
>>> index 46f951f4d..8b8e75c4f 100644
>>> --- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
>>> +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
>>> @@ -658,7 +658,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
>>> {
>>> const struct rte_memseg *ms = rte_eal_get_physmem_layout();
>>> int i, ret;
>>> -
>>> + phys_addr_t io_offset;
>>> struct vfio_iommu_spapr_register_memory reg = {
>>>.argsz = sizeof(reg),
>>>.flags = 0
>>> @@ -702,6 +702,13 @@ vfio_spapr_dma_map(int vfio_container_fd)
>>>return -1;
>>> }
>>>
>>> + io_offset = create.start_addr;
>>> + if (io_offset) {
>>> + RTE_LOG(ERR, EAL, " DMA offsets other than zero is not supported, "
>>> +"new window is created at %lx\n", io_offset);
>>> + return -1;
>>> + }
>>> +
>>> /* map all DPDK segments for DMA. use 1:1 PA to IOVA mapping */
>>> for (i = 0; i < RTE_MAX_MEMSEG; i++) {
>>>struct vfio_iommu_type1_dma_map dma_map;
>>> @@ -723,7 +730,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
>>>dma_map.argsz = sizeof(struct vfio_iommu_type1_dma_map);
>>>dma_map.vaddr = ms[i].addr_64;
>>>dma_map.size = ms[i].len;
>>> - dma_map.iova = ms[i].phys_addr;
>>> + dma_map.iova = io_offset;
>>>dma_map.flags = VFIO_DMA_MAP_FLAG_READ |
>>> VFIO_DMA_MAP_FLAG_WRITE;
>>>
>>> @@ -735,6 +742,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
>>> return -1;
>>>}
>>>
>>> + io_offset += dma_map.size;
>>> }
>>>
>>> return 0;
>>> --
>>> 2.11.0
>>>
>>
>
>
--
Alexey
[dpdk-dev] [PATCH] app/testpmd: check port is stopped for QinQ setup
Check port is stopped before configuring it for QinQ,
with the "vlan set qinq on " command.
Signed-off-by: Bernard Iremonger
---
app/test-pmd/cmdline.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index f6bd75b78..a96b8b67c 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2017 Intel Corporation. All rights reserved.
* Copyright(c) 2014 6WIND S.A.
* All rights reserved.
*
@@ -3036,6 +3036,7 @@ cmd_vlan_offload_parsed(void *parsed_result,
int i, len = 0;
portid_t port_id = 0;
unsigned int tmp;
+ struct rte_port *port;
str = res->port_id;
len = strnlen(str, STR_TOKEN_SIZE);
@@ -3053,6 +3054,7 @@ cmd_vlan_offload_parsed(void *parsed_result,
if(tmp >= RTE_MAX_ETHPORTS)
return;
port_id = (portid_t)tmp;
+ port = &ports[port_id];
if (!strcmp(res->on, "on"))
on = 1;
@@ -3079,9 +3081,13 @@ cmd_vlan_offload_parsed(void *parsed_result,
}
else if (!strcmp(res->what, "filter"))
rx_vlan_filter_set(port_id, on);
- else
+ else {
+ if (port->port_status != RTE_PORT_STOPPED) {
+ printf("Please stop port %d first\n", port_id);
+ return;
+ }
vlan_extend_set(port_id, on);
-
+ }
return;
}
--
2.11.0
[dpdk-dev] [PATCH 0/2] fixes for FreeBSD compilation
Bruce Richardson (2): examples/performance-thread: fix FreeBSD compilation net/ark: fix FreeBSD compilation drivers/net/ark/Makefile| 2 ++ examples/performance-thread/l3fwd-thread/main.c | 4 examples/performance-thread/pthread_shim/main.c | 4 examples/performance-thread/pthread_shim/pthread_shim.c | 15 +-- examples/performance-thread/pthread_shim/pthread_shim.h | 9 + 5 files changed, 32 insertions(+), 2 deletions(-) -- 2.11.0
[dpdk-dev] [PATCH 1/2] examples/performance-thread: fix FreeBSD compilation
This set of sample apps did not compile on FreeBSD due to use of a number
of Linux/glibc-specific APIs, or APIs which existed in different headers
on FreeBSD. Specifically, the following APIs has problems:
* sched_getcpu() is a glibc extension
* pthread_yield() returns int on Linux, but void on FreeBSD
* APIs for managing cpu affinity are in pthread_np.h on FreeBSD, rather
than in pthread.h
* the type for managing cpu sets is cpuset_t on FreeBSD rather than
cpu_set_t as on Linux.
Fixes: 433ba6228f9a ("examples/performance-thread: add pthread_shim app")
Fixes: d48415e1fee3 ("examples/performance-thread: add l3fwd-thread app")
CC: sta...@dpdk.org
Signed-off-by: Bruce Richardson
---
examples/performance-thread/l3fwd-thread/main.c | 4
examples/performance-thread/pthread_shim/main.c | 4
examples/performance-thread/pthread_shim/pthread_shim.c | 15 +--
examples/performance-thread/pthread_shim/pthread_shim.h | 9 +
4 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/examples/performance-thread/l3fwd-thread/main.c
b/examples/performance-thread/l3fwd-thread/main.c
index f6154ac2a..2d98473eb 100644
--- a/examples/performance-thread/l3fwd-thread/main.c
+++ b/examples/performance-thread/l3fwd-thread/main.c
@@ -90,6 +90,10 @@
#define APP_LOOKUP_METHOD APP_LOOKUP_LPM
#endif
+#ifndef __GLIBC__ /* sched_getcpu() is glibc specific */
+#define sched_getcpu() rte_lcore_id()
+#endif
+
static int
check_ptype(int portid)
{
diff --git a/examples/performance-thread/pthread_shim/main.c
b/examples/performance-thread/pthread_shim/main.c
index f03572181..f7074006e 100644
--- a/examples/performance-thread/pthread_shim/main.c
+++ b/examples/performance-thread/pthread_shim/main.c
@@ -59,6 +59,10 @@
#define DEBUG_APP 0
#define HELLOW_WORLD_MAX_LTHREADS 10
+#ifndef __GLIBC__ /* sched_getcpu() is glibc-specific */
+#define sched_getcpu() rte_lcore_id()
+#endif
+
__thread int print_count;
__thread pthread_mutex_t print_lock;
diff --git a/examples/performance-thread/pthread_shim/pthread_shim.c
b/examples/performance-thread/pthread_shim/pthread_shim.c
index 0d6100c90..1b2e1de03 100644
--- a/examples/performance-thread/pthread_shim/pthread_shim.c
+++ b/examples/performance-thread/pthread_shim/pthread_shim.c
@@ -576,15 +576,26 @@ int pthread_rwlock_wrlock(pthread_rwlock_t *a)
return _sys_pthread_funcs.f_pthread_rwlock_wrlock(a);
}
-int pthread_yield(void)
+#ifdef RTE_EXEC_ENV_LINUXAPP
+int
+pthread_yield(void)
{
if (override) {
lthread_yield();
return 0;
}
return _sys_pthread_funcs.f_pthread_yield();
-
}
+#else
+void
+pthread_yield(void)
+{
+ if (override)
+ lthread_yield();
+ else
+ _sys_pthread_funcs.f_pthread_yield();
+}
+#endif
pthread_t pthread_self(void)
{
diff --git a/examples/performance-thread/pthread_shim/pthread_shim.h
b/examples/performance-thread/pthread_shim/pthread_shim.h
index 78bbb5ac0..527640bd6 100644
--- a/examples/performance-thread/pthread_shim/pthread_shim.h
+++ b/examples/performance-thread/pthread_shim/pthread_shim.h
@@ -36,6 +36,15 @@
#include
/*
+ * on BSD, the non-std calls are in pthread_np.h,
+ * and cpuset_t has only one "_" rather than two.
+ */
+#ifdef RTE_EXEC_ENV_BSDAPP
+#include
+#define cpu_set_t cpuset_t
+#endif
+
+/*
* This pthread shim is an example that demonstrates how legacy code
* that makes use of POSIX pthread services can make use of lthreads
* with reduced porting effort.
--
2.11.0
[dpdk-dev] [PATCH 2/2] net/ark: fix FreeBSD compilation
On FreeBSD it's not necessary to use -ldl to link apps which use
dlopen. This error only showed up with a shared library gcc build,
not standard build using static libs.
Fixes: 1131cbf0fb2b ("net/ark: stub PMD for Atomic Rules Arkville")
Signed-off-by: Bruce Richardson
---
drivers/net/ark/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ark/Makefile b/drivers/net/ark/Makefile
index b3d462ff5..ca64b1957 100644
--- a/drivers/net/ark/Makefile
+++ b/drivers/net/ark/Makefile
@@ -59,6 +59,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_ARK_PMD) += ark_udm.c
# this lib depends upon:
LDLIBS += -lpthread
+ifdef CONFIG_RTE_EXEC_ENV_LINUXAPP
LDLIBS += -ldl
+endif
include $(RTE_SDK)/mk/rte.lib.mk
--
2.11.0
Re: [dpdk-dev] [PATCH 2/2] net/ark: fix FreeBSD compilation
> On Apr 20, 2017, at 12:32 PM, Bruce Richardson
> wrote:
>
> On FreeBSD it's not necessary to use -ldl to link apps which use
> dlopen. This error only showed up with a shared library gcc build,
> not standard build using static libs.
>
> Fixes: 1131cbf0fb2b ("net/ark: stub PMD for Atomic Rules Arkville")
>
> Signed-off-by: Bruce Richardson
Thanks Bruce.
Acked-by: John Miller mailto:john.mil...@atomicrules.com>>
Re: [dpdk-dev] [dpdk-stable] [PATCH 1/2] examples/performance-thread: fix FreeBSD compilation
20/04/2017 18:32, Bruce Richardson: > This set of sample apps did not compile on FreeBSD due to use of a number > of Linux/glibc-specific APIs, or APIs which existed in different headers > on FreeBSD. Specifically, the following APIs has problems: > * sched_getcpu() is a glibc extension > * pthread_yield() returns int on Linux, but void on FreeBSD > * APIs for managing cpu affinity are in pthread_np.h on FreeBSD, rather > than in pthread.h > * the type for managing cpu sets is cpuset_t on FreeBSD rather than > cpu_set_t as on Linux. It can be fixed by using rte_cpuset_t defined in lib/librte_eal/common/include/rte_lcore.h
Re: [dpdk-dev] [pull-request] next-crypto 17.05 RC2
20/04/2017 11:43, Pablo de Lara: > http://dpdk.org/git/next/dpdk-next-crypto Pulled, thanks
[dpdk-dev] DPAA2 crypto license
Hi, I'm not a lawyer but I think there may be an issue with the files in drivers/crypto/dpaa2_sec/hw/ The header of these files is: /* * Copyright 2008-2016 Freescale Semiconductor, Inc. * * SPDX-License-Identifier: BSD-3-Clause or GPL-2.0+ */ Could we make it more explicit than this SPDX tag?
[dpdk-dev] DPDK log system is not working
Hi, I've recently rebased my DPDK code from v16.07 to v17.05-rc1 and learned rte_set_log_type() API is deprecated now, so I switched to rte_log_set_level() API. My old code was as follow: #define C2CV3 RTE_LOGTYPE_USER1 #define D RTE_LOG_DEBUG #define I RTE_LOG_INFO #define N RTE_LOG_NOTICE rte_set_log_type(C2CV3, 1); rte_log(I, C2CV3, "Hello World\n"); The new code (according to the rte_set_log_type or test_log.c): rte_log_set_level(C2CV3, 0); rte_log(I, C2CV3, "Does not work\n"); Also, the test_log.c looks broken too. Patrick
[dpdk-dev] [PATCH v4] doc: fix flow validate comments
Change comments for rte_flow_validate() function to indicate that flow
rule collision and resource validation is optional for PMDs and
therefore the return codes may have different meanings.
Fixes: b1a4b4cbc0a8 ("ethdev: introduce generic flow API")
Signed-off-by: John Daley
---
v2: another crack at the comments
v3: fix typos, rewording, put back a sentence omitted in v2
v4: fixes per Adrien Mazarguil- update guide, typo, commit title
doc/guides/prog_guide/rte_flow.rst | 17 -
lib/librte_ether/rte_flow.h| 16 +++-
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst
b/doc/guides/prog_guide/rte_flow.rst
index 5ee045ee8..9f3d3b096 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1332,9 +1332,11 @@ supported and can be created.
const struct rte_flow_action actions[],
struct rte_flow_error *error);
-While this function has no effect on the target device, the flow rule is
-validated against its current configuration state and the returned value
-should be considered valid by the caller for that state only.
+The flow rule is validated for correctness and whether it could be accepted
+by the device given sufficient resources. The rule is checked against the
+current device mode and queue configuration. The flow rule may also
+optionally be validated against existing flow rules and device resources.
+This function has no effect on the target device.
The returned value is guaranteed to remain valid only as long as no
successful calls to ``rte_flow_create()`` or ``rte_flow_destroy()`` are made
@@ -1360,8 +1362,13 @@ Return values:
- ``-EINVAL``: unknown or invalid rule specification.
- ``-ENOTSUP``: valid but unsupported rule specification (e.g. partial
bit-masks are unsupported).
-- ``-EEXIST``: collision with an existing rule.
-- ``-ENOMEM``: not enough resources.
+- ``EEXIST``: collision with an existing rule. Only returned if device
+ supports flow rule collision checking and there was a flow rule
+ collision. Not receiving this return code is no guarantee that creating
+ the rule will not fail due to a collision.
+- ``ENOMEM``: not enough memory to execute the function, or if the device
+ supports resource validation, resource limitation on the device.
+
- ``-EBUSY``: action cannot be performed due to busy device resources, may
succeed if the affected queues or even the entire port are in a stopped
state (see ``rte_eth_dev_rx_queue_stop()`` and ``rte_eth_dev_stop()``).
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 8013ecab2..7749491cb 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -983,9 +983,11 @@ struct rte_flow_error {
/**
* Check whether a flow rule can be created on a given port.
*
- * While this function has no effect on the target device, the flow rule is
- * validated against its current configuration state and the returned value
- * should be considered valid by the caller for that state only.
+ * The flow rule is validated for correctness and whether it could be accepted
+ * by the device given sufficient resources. The rule is checked against the
+ * current device mode and queue configuration. The flow rule may also
+ * optionally be validated against existing flow rules and device resources.
+ * This function has no effect on the target device.
*
* The returned value is guaranteed to remain valid only as long as no
* successful calls to rte_flow_create() or rte_flow_destroy() are made in
@@ -1016,9 +1018,13 @@ struct rte_flow_error {
* -ENOTSUP: valid but unsupported rule specification (e.g. partial
* bit-masks are unsupported).
*
- * -EEXIST: collision with an existing rule.
+ * -EEXIST: collision with an existing rule. Only returned if device
+ * supports flow rule collision checking and there was a flow rule
+ * collision. Not receiving this return code is no guarantee that creating
+ * the rule will not fail due to a collision.
*
- * -ENOMEM: not enough resources.
+ * -ENOMEM: not enough memory to execute the function, or if the device
+ * supports resource validation, resource limitation on the device.
*
* -EBUSY: action cannot be performed due to busy device resources, may
* succeed if the affected queues or even the entire port are in a stopped
--
2.12.0
[dpdk-dev] [RFC 17.08] Flow classification library
DPDK works with packets, but some network administration tools works based on flow information. This library is suggested to provide helper APIs to convert packet based information to the flow records. Library header file has more comments on how library works and provided APIs. Packets to flow conversion will cause performance drop, that is why this conversion can be enabled and disabled dynamically by application. Initial implementation in mind is to provide support for IPFIX metering process but library planned to be as generic as possible. And flow information provided by this library is missing to implement full IPFIX features, but this is planned to be initial step. It is possible to define flow with various flow keys, but currently only one type of flow defined in the library, which is more generic, and it offloads fine grained flow analysis to the application. Library enables expanding for other flow types. It will be more beneficial to shape this library to cover more use cases, please feel free to comment on possible other use case and desired functionalities. Thanks, ferruh cc: John McNamara cc: Maryam Tahhan Ferruh Yigit (1): flow_classify: add librte_flow_classify library config/common_base | 5 + doc/api/doxy-api-index.md | 1 + doc/api/doxy-api.conf | 1 + doc/guides/rel_notes/release_17_05.rst | 1 + lib/Makefile | 2 + lib/librte_flow_classify/Makefile | 50 + lib/librte_flow_classify/rte_flow_classify.c | 34 lib/librte_flow_classify/rte_flow_classify.h | 202 + .../rte_flow_classify_version.map | 10 + 9 files changed, 306 insertions(+) create mode 100644 lib/librte_flow_classify/Makefile create mode 100644 lib/librte_flow_classify/rte_flow_classify.c create mode 100644 lib/librte_flow_classify/rte_flow_classify.h create mode 100644 lib/librte_flow_classify/rte_flow_classify_version.map -- 2.9.3
[dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library
Signed-off-by: Ferruh Yigit --- config/common_base | 5 + doc/api/doxy-api-index.md | 1 + doc/api/doxy-api.conf | 1 + doc/guides/rel_notes/release_17_05.rst | 1 + lib/Makefile | 2 + lib/librte_flow_classify/Makefile | 50 + lib/librte_flow_classify/rte_flow_classify.c | 34 lib/librte_flow_classify/rte_flow_classify.h | 202 + .../rte_flow_classify_version.map | 10 + 9 files changed, 306 insertions(+) create mode 100644 lib/librte_flow_classify/Makefile create mode 100644 lib/librte_flow_classify/rte_flow_classify.c create mode 100644 lib/librte_flow_classify/rte_flow_classify.h create mode 100644 lib/librte_flow_classify/rte_flow_classify_version.map diff --git a/config/common_base b/config/common_base index 412ec3f..c05a411 100644 --- a/config/common_base +++ b/config/common_base @@ -634,6 +634,11 @@ CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n CONFIG_RTE_LIBRTE_METER=y # +# Compile librte_classify +# +CONFIG_RTE_LIBRTE_FLOW_CLASSIFY=y + +# # Compile librte_sched # CONFIG_RTE_LIBRTE_SCHED=y diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index a26846a..7f0be03 100644 --- a/doc/api/doxy-api-index.md +++ b/doc/api/doxy-api-index.md @@ -97,6 +97,7 @@ There are many libraries, so their headers may be grouped by topics: [LPM IPv4 route] (@ref rte_lpm.h), [LPM IPv6 route] (@ref rte_lpm6.h), [ACL](@ref rte_acl.h), + [flow_classify] (@ref rte_flow_classify.h), [EFD](@ref rte_efd.h) - **QoS**: diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf index 97fb551..9eec10c 100644 --- a/doc/api/doxy-api.conf +++ b/doc/api/doxy-api.conf @@ -45,6 +45,7 @@ INPUT = doc/api/doxy-api-index.md \ lib/librte_efd \ lib/librte_ether \ lib/librte_eventdev \ + lib/librte_flow_classify \ lib/librte_hash \ lib/librte_ip_frag \ lib/librte_jobstats \ diff --git a/doc/guides/rel_notes/release_17_05.rst b/doc/guides/rel_notes/release_17_05.rst index 25e7144..89520e4 100644 --- a/doc/guides/rel_notes/release_17_05.rst +++ b/doc/guides/rel_notes/release_17_05.rst @@ -507,6 +507,7 @@ The libraries prepended with a plus sign were incremented in this version. librte_distributor.so.1 + librte_eal.so.4 librte_ethdev.so.6 + librte_flow_classify.so.1 librte_hash.so.2 librte_ip_frag.so.1 librte_jobstats.so.1 diff --git a/lib/Makefile b/lib/Makefile index 07e1fd0..e63cd61 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -80,6 +80,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_POWER) += librte_power DEPDIRS-librte_power := librte_eal DIRS-$(CONFIG_RTE_LIBRTE_METER) += librte_meter DEPDIRS-librte_meter := librte_eal +DIRS-$(CONFIG_RTE_LIBRTE_FLOW_CLASSIFY) += librte_flow_classify +DEPDIRS-librte_flow_classify := librte_eal librte_ether librte_net DIRS-$(CONFIG_RTE_LIBRTE_SCHED) += librte_sched DEPDIRS-librte_sched := librte_eal librte_mempool librte_mbuf librte_net DEPDIRS-librte_sched += librte_timer diff --git a/lib/librte_flow_classify/Makefile b/lib/librte_flow_classify/Makefile new file mode 100644 index 000..c57e9a3 --- /dev/null +++ b/lib/librte_flow_classify/Makefile @@ -0,0 +1,50 @@ +# BSD LICENSE +# +# Copyright(c) 2017 Intel Corporation. All rights reserved. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Intel Corporation nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEV
Re: [dpdk-dev] [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus addresses for DMA map
On Thursday 20 April 2017 07:52 PM, Alexey Kardashevskiy wrote:
On 20/04/17 23:25, Alexey Kardashevskiy wrote:
On 20/04/17 19:04, Jonas Pfefferle1 wrote:
Alexey Kardashevskiy wrote on 20/04/2017 09:24:02:
From: Alexey Kardashevskiy
To: dev@dpdk.org
Cc: Alexey Kardashevskiy , j...@zurich.ibm.com,
Gowrishankar Muthukrishnan
Date: 20/04/2017 09:24
Subject: [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus
addresses for DMA map
VFIO_IOMMU_SPAPR_TCE_CREATE ioctl() returns the actual bus address for
just created DMA window. It happens to start from zero because the default
window is removed (leaving no windows) and new window starts from zero.
However this is not guaranteed and the new window may start from another
address, this adds an error check.
Another issue is that IOVA passed to VFIO_IOMMU_MAP_DMA should be a PCI
bus address while in this case a physical address of a user page is used.
This changes IOVA to start from zero in a hope that the rest of DPDK
expects this.
This is not the case. DPDK expects a 1:1 mapping PA==IOVA. It will use the
phys_addr of the memory segment it got from /proc/self/pagemap cf.
librte_eal/linuxapp/eal/eal_memory.c. We could try setting it here to the
actual iova which basically makes the whole virtual to phyiscal mapping
with pagemap unnecessary which I believe should be the case for VFIO
anyway. Pagemap should only be needed when using pci_uio.
Ah, ok, makes sense now. But it sure needs a big fat comment there as it is
not obvious why host RAM address is used there as DMA window start is not
guaranteed.
Well, either way there is some bug - ms[i].phys_addr and ms[i].addr_64 both
have exact same value, in my setup it is 3fffb33c which is a userspace
address - at least ms[i].phys_addr must be physical address.
This patch breaks i40e_dev_init() in my server.
EAL: PCI device 0004:01:00.0 on NUMA socket 1
EAL: probe driver: 8086:1583 net_i40e
EAL: using IOMMU type 7 (sPAPR)
eth_i40e_dev_init(): Failed to init adminq: -32
EAL: Releasing pci mapped resource for 0004:01:00.0
EAL: Calling pci_unmap_resource for 0004:01:00.0 at 0x3fff82aa
EAL: Requested device 0004:01:00.0 cannot be used
EAL: PCI device 0004:01:00.1 on NUMA socket 1
EAL: probe driver: 8086:1583 net_i40e
EAL: using IOMMU type 7 (sPAPR)
eth_i40e_dev_init(): Failed to init adminq: -32
EAL: Releasing pci mapped resource for 0004:01:00.1
EAL: Calling pci_unmap_resource for 0004:01:00.1 at 0x3fff82aa
EAL: Requested device 0004:01:00.1 cannot be used
EAL: No probed ethernet devices
I have two memseg each of 1G size. Their mapped PA and VA are also
different.
(gdb) p /x ms[0]
$3 = {phys_addr = 0x1e0b00, {addr = 0x3effaf00, addr_64 =
0x3effaf00},
len = 0x4000, hugepage_sz = 0x100, socket_id = 0x1, nchannel
= 0x0, nrank = 0x0}
(gdb) p /x ms[1]
$4 = {phys_addr = 0xf6d00, {addr = 0x3efbaf00, addr_64 =
0x3efbaf00},
len = 0x4000, hugepage_sz = 0x100, socket_id = 0x0, nchannel
= 0x0, nrank = 0x0}
Could you please recheck this. May be, if new DMA window does not start
from bus address 0,
only then you reset dma_map.iova for this offset ?
Thanks,
Gowrishankar
Signed-off-by: Alexey Kardashevskiy
---
lib/librte_eal/linuxapp/eal/eal_vfio.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c b/lib/
librte_eal/linuxapp/eal/eal_vfio.c
index 46f951f4d..8b8e75c4f 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -658,7 +658,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
{
const struct rte_memseg *ms = rte_eal_get_physmem_layout();
int i, ret;
-
+ phys_addr_t io_offset;
struct vfio_iommu_spapr_register_memory reg = {
.argsz = sizeof(reg),
.flags = 0
@@ -702,6 +702,13 @@ vfio_spapr_dma_map(int vfio_container_fd)
return -1;
}
+ io_offset = create.start_addr;
+ if (io_offset) {
+ RTE_LOG(ERR, EAL, " DMA offsets other than zero is not supported, "
+"new window is created at %lx\n", io_offset);
+ return -1;
+ }
+
/* map all DPDK segments for DMA. use 1:1 PA to IOVA mapping */
for (i = 0; i < RTE_MAX_MEMSEG; i++) {
struct vfio_iommu_type1_dma_map dma_map;
@@ -723,7 +730,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
dma_map.argsz = sizeof(struct vfio_iommu_type1_dma_map);
dma_map.vaddr = ms[i].addr_64;
dma_map.size = ms[i].len;
- dma_map.iova = ms[i].phys_addr;
+ dma_map.iova = io_offset;
dma_map.flags = VFIO_DMA_MAP_FLAG_READ |
VFIO_DMA_MAP_FLAG_WRITE;
@@ -735,6 +742,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
return -1;
}
+ io_offset += dma_map.size;
}
return 0;
--
2.11.0
Re: [dpdk-dev] [PATCH dpdk 4/5] vfio: Do try setting IOMMU type if already set
On Thursday 20 April 2017 12:54 PM, Alexey Kardashevskiy wrote:
The existing code correctly checks if a container is set to a group and
does not try attaching a group to a container for a second/third/...
device from the same IOMMU group.
However it still tries to set IOMMU type to a container for every device
in a group which produces failure and closes container and group fds.
This moves vfio_set_iommu_type() and DMA mapping code under:
if (!(group_status.flags & VFIO_GROUP_FLAGS_CONTAINER_SET))
Signed-off-by: Alexey Kardashevskiy
Thanks, verified it for regression seen on current master for mentioned
scenario.
Regards,
Gowrishankar
---
lib/librte_eal/linuxapp/eal/eal_vfio.c | 50 +-
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_vfio.c
index 6e2e84ca7..46f951f4d 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -298,33 +298,33 @@ vfio_setup_device(const char *sysfs_base, const char
*dev_addr,
clear_group(vfio_group_fd);
return -1;
}
- }
- /*
-* pick an IOMMU type and set up DMA mappings for container
-*
-* needs to be done only once, only when first group is assigned to
-* a container and only in primary process. Note this can happen several
-* times with the hotplug functionality.
-*/
- if (internal_config.process_type == RTE_PROC_PRIMARY &&
- vfio_cfg.vfio_active_groups == 1) {
- /* select an IOMMU type which we will be using */
- const struct vfio_iommu_type *t =
+ /*
+* pick an IOMMU type and set up DMA mappings for container
+*
+* needs to be done only once, only when first group is
assigned to
+* a container and only in primary process. Note this can
happen several
+* times with the hotplug functionality.
+*/
+ if (internal_config.process_type == RTE_PROC_PRIMARY &&
+ vfio_cfg.vfio_active_groups == 1) {
+ /* select an IOMMU type which we will be using */
+ const struct vfio_iommu_type *t =
vfio_set_iommu_type(vfio_cfg.vfio_container_fd);
- if (!t) {
- RTE_LOG(ERR, EAL, " %s failed to select IOMMU type\n",
dev_addr);
- close(vfio_group_fd);
- clear_group(vfio_group_fd);
- return -1;
- }
- ret = t->dma_map_func(vfio_cfg.vfio_container_fd);
- if (ret) {
- RTE_LOG(ERR, EAL, " %s DMA remapping failed, "
- "error %i (%s)\n", dev_addr, errno,
strerror(errno));
- close(vfio_group_fd);
- clear_group(vfio_group_fd);
- return -1;
+ if (!t) {
+ RTE_LOG(ERR, EAL, " %s failed to select IOMMU
type\n", dev_addr);
+ close(vfio_group_fd);
+ clear_group(vfio_group_fd);
+ return -1;
+ }
+ ret = t->dma_map_func(vfio_cfg.vfio_container_fd);
+ if (ret) {
+ RTE_LOG(ERR, EAL, " %s DMA remapping failed, "
+ "error %i (%s)\n", dev_addr,
errno, strerror(errno));
+ close(vfio_group_fd);
+ clear_group(vfio_group_fd);
+ return -1;
+ }
}
}
Re: [dpdk-dev] DPDK log system is not working
20/04/2017 20:35, Lu, Patrick: > Hi, > > I've recently rebased my DPDK code from v16.07 to v17.05-rc1 and learned > rte_set_log_type() API is deprecated now, so I switched to > rte_log_set_level() API. It should be fixed with the recent patches. Please check the master branch or 17.05-rc2 when it will be out.
Re: [dpdk-dev] [PATCH v6 0/5] Extended xstats API in ethdev library to allow grouping of stats
13/04/2017 16:59, Kuba Kozak: > Extended xstats API in ethdev library to allow grouping of stats logically > so they can be retrieved per logical grouping managed by the application. > Changed existing functions rte_eth_xstats_get_names and rte_eth_xstats_get > to use a new list of arguments: array of ids and array of values. > ABI versioning mechanism was used to support backward compatibility. > Introduced two new functions rte_eth_xstats_get_all and > rte_eth_xstats_get_names_all which keeps functionality of the previous > ones (respectively rte_eth_xstats_get and rte_eth_xstats_get_names) > but use new API inside. Both functions marked as deprecated. > Introduced new function: rte_eth_xstats_get_id_by_name to retrieve > xstats ids by its names. > Extended functionality of proc_info application: > --xstats-name NAME: to display single xstat value by NAME > Updated test-pmd application to use new API. Applied, thanks
Re: [dpdk-dev] [PATCH v7 1/3] lib/librte_ether: add support for port reset
10/04/2017 05:02, Wei Zhao:
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -1509,6 +1512,9 @@ struct eth_dev_ops {
> eth_l2_tunnel_offload_set_t l2_tunnel_offload_set;
> /** Enable/disable l2 tunnel offload functions. */
>
> + /** Reset device. */
> + eth_dev_reset_t dev_reset;
> +
> eth_set_queue_rate_limit_t set_queue_rate_limit; /**< Set queue rate
> limit. */
>
> rss_hash_update_t rss_hash_update; /** Configure RSS hash
This new op should be added at the end of the structure
to avoid ABI issue.
> protocols. */ @@ -4413,6 +4419,28 @@ int
> rte_eth_dev_get_name_by_port(uint8_t port_id, char *name);
>
> /**
> + * Reset an ethernet device when it's not working. One scenario is, after
> PF + * port is down and up, the related VF port should be reset.
> + * The API will stop the port, clear the rx/tx queues, re-setup the rx/tx
> + * queues, restart the port.
> + * Before calling this API, APP should stop the rx/tx. When tx is being
> stopped, + * APP can drop the packets and release the buffer instead of
> sending them. + * This function can also do some restore work for the port,
> for example, it can + * restore the added parameters of vlan, mac_addrs,
> promisc_unicast_enabled + * flag and promisc_multicast_enabled flag.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + *
> + * @return
> + * - (0) if successful.
> + * - (-ENODEV) if port identifier is invalid.
> + * - (-ENOTSUP) if hardware doesn't support this function.
> + */
> +int
> +rte_eth_dev_reset(uint8_t port_id);
The declarations and function definitions should be better placed
after start and stop functions.
Re: [dpdk-dev] [PATCH v7 1/3] lib/librte_ether: add support for port reset
10/04/2017 05:02, Wei Zhao: > Add support for port reset in rte layer.This reset > feature can be used not only in vf port reset in the following > code develop process later, but also pf port.But in this patch > set, we only limit the discussion scope to vf reset. > This patch add an API to restart the device. > It's for VF device in this scenario, kernel PF + DPDK VF. > When the PF port state is down->up, APP should call this API to > restart VF port. Most likely, APP should call it in its > management thread and guarantee the thread safe. It means > APP should stop the rx/tx and the device, then restart > the device, then recover the device and rx/tx.This API can > also do some restore work for the port. > > Signed-off-by: Wenzhuo Lu > Signed-off-by: Wei Zhao > --- > lib/librte_ether/rte_ethdev.c | 17 + > lib/librte_ether/rte_ethdev.h | 28 > lib/librte_ether/rte_ether_version.map | 6 ++ > 3 files changed, 51 insertions(+) This new feature should be referenced in the matrix doc/guides/nics/features/default.ini
Re: [dpdk-dev] [PATCH v7 2/3] net/i40e: implement device reset on port
10/04/2017 05:02, Wei Zhao:
> + if (adapter->reset_store_data == NULL) {
> + PMD_INIT_LOG(ERR, "Failed to allocate %ld bytes needed to"
> + " to store data when reset vf",
> + sizeof(struct i40e_vf_reset_store));
Compilation fails for 32-bit.
%ld must be replaced by %zu
Re: [dpdk-dev] [PATCH v7 2/3] net/i40e: implement device reset on port
10/04/2017 05:02, Wei Zhao: > + memset(dev->data->dev_private, 0, > +(uint64_t)&adapter->reset_flag - (uint64_t)adapter); It does not compile for 32-bit. Should it be replaced by offsetof()? Does it mean that new fields should be added before reset_flag? There is no comment about position importance of this field in the struct. By the way, there is a field ptype_tbl appeared recently. Where should it be positionned after rebase?
Re: [dpdk-dev] [PATCH v7 0/3] net/i40e: vf port reset
10/04/2017 05:02, Wei Zhao: > The patches mainly finish following functions: > 1) get pf reset vf comamand falg from interrupt server function. > 2) reset vf port from testpmd app using a command. > 3) sore and restore vf related parameters. [...] > zhao wei (3): > app/testpmd: add port reset command into testpmd > lib/librte_ether: add support for port reset > net/i40e: implement device reset on port There are some misses and compilation issues in this series. As there is neither a support from other maintainers no strong nack, I was ready to apply this series. However after a better look and compilation issues revealed in RC2 phase, I think it should be postponed to 17.08. In any case, PMD maintainers are welcome to give their opinions.
Re: [dpdk-dev] [dpdk-stable] [PATCH v4 1/3] ethdev: fix adding invalid MAC addr
13/04/2017 10:21, Wei Dai:
> some customers find adding mac addr to VF sometimes can fail,
> but it is still stored in dev->data->mac_addrs[ ]. So this
> can lead to some errors that assumes the non-zero entry in
> dev->data->mac_addrs[ ] is valid.
>
> Fixes: af75078fece3 ("first public release")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> ---
> drivers/net/bnx2x/bnx2x_ethdev.c | 7 +--
> drivers/net/bnxt/bnxt_ethdev.c | 12 ++--
> drivers/net/e1000/base/e1000_api.c | 2 +-
> drivers/net/e1000/em_ethdev.c | 6 +++---
> drivers/net/e1000/igb_ethdev.c | 5 +++--
> drivers/net/enic/enic.h| 2 +-
> drivers/net/enic/enic_ethdev.c | 4 ++--
> drivers/net/enic/enic_main.c | 6 +++---
> drivers/net/fm10k/fm10k_ethdev.c | 3 ++-
> drivers/net/i40e/i40e_ethdev.c | 11 ++-
> drivers/net/i40e/i40e_ethdev_vf.c | 8
> drivers/net/ixgbe/ixgbe_ethdev.c | 27 ++-
> drivers/net/mlx4/mlx4.c| 18 +++---
> drivers/net/mlx5/mlx5.h| 4 ++--
> drivers/net/mlx5/mlx5_mac.c| 16 ++--
> drivers/net/qede/qede_ethdev.c | 6 --
> drivers/net/ring/rte_eth_ring.c| 3 ++-
> drivers/net/virtio/virtio_ethdev.c | 13 +++--
> lib/librte_ether/rte_ethdev.c | 15 +--
> lib/librte_ether/rte_ethdev.h | 2 +-
> 20 files changed, 100 insertions(+), 70 deletions(-)
Please, could you rebase and add changes to newly introduced drivers?
Thanks
Re: [dpdk-dev] [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus addresses for DMA map
On 21/04/17 01:15, Jonas Pfefferle1 wrote:
> Alexey Kardashevskiy wrote on 20/04/2017 16:22:01:
>
>> From: Alexey Kardashevskiy
>> To: Jonas Pfefferle1
>> Cc: dev@dpdk.org, Gowrishankar Muthukrishnan
>> , Adrian Schuepbach
>> Date: 20/04/2017 16:22
>> Subject: Re: [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus
>> addresses for DMA map
>>
>> On 20/04/17 23:25, Alexey Kardashevskiy wrote:
>> > On 20/04/17 19:04, Jonas Pfefferle1 wrote:
>> >> Alexey Kardashevskiy wrote on 20/04/2017 09:24:02:
>> >>
>> >>> From: Alexey Kardashevskiy
>> >>> To: dev@dpdk.org
>> >>> Cc: Alexey Kardashevskiy , j...@zurich.ibm.com,
>> >>> Gowrishankar Muthukrishnan
>> >>> Date: 20/04/2017 09:24
>> >>> Subject: [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus
>> >>> addresses for DMA map
>> >>>
>> >>> VFIO_IOMMU_SPAPR_TCE_CREATE ioctl() returns the actual bus address for
>> >>> just created DMA window. It happens to start from zero because the
> default
>> >>> window is removed (leaving no windows) and new window starts from zero.
>> >>> However this is not guaranteed and the new window may start from another
>> >>> address, this adds an error check.
>> >>>
>> >>> Another issue is that IOVA passed to VFIO_IOMMU_MAP_DMA should be a PCI
>> >>> bus address while in this case a physical address of a user page is used.
>> >>> This changes IOVA to start from zero in a hope that the rest of DPDK
>> >>> expects this.
>> >>
>> >> This is not the case. DPDK expects a 1:1 mapping PA==IOVA. It will use the
>> >> phys_addr of the memory segment it got from /proc/self/pagemap cf.
>> >> librte_eal/linuxapp/eal/eal_memory.c. We could try setting it here to the
>> >> actual iova which basically makes the whole virtual to phyiscal mapping
>> >> with pagemap unnecessary which I believe should be the case for VFIO
>> >> anyway. Pagemap should only be needed when using pci_uio.
>> >
>> >
>> > Ah, ok, makes sense now. But it sure needs a big fat comment there as it is
>> > not obvious why host RAM address is used there as DMA window start is not
>> > guaranteed.
>>
>> Well, either way there is some bug - ms[i].phys_addr and ms[i].addr_64 both
>> have exact same value, in my setup it is 3fffb33c which is a userspace
>> address - at least ms[i].phys_addr must be physical address.
>
> This might be the case if you are not using hugetlbfs i.e. passing
> "--no-huge" cf. eal_memory.c:980
>
> /* hugetlbfs can be disabled */
> if (internal_config.no_hugetlbfs) {
> addr = mmap(NULL, internal_config.memory, PROT_READ | PROT_WRITE,
> MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
> if (addr == MAP_FAILED) {
> RTE_LOG(ERR, EAL, "%s: mmap() failed: %s\n", __func__,
> strerror(errno));
> return -1;
> }
> mcfg->memseg[0].phys_addr = (phys_addr_t)(uintptr_t)addr;
> mcfg->memseg[0].addr = addr;
> mcfg->memseg[0].hugepage_sz = RTE_PGSIZE_4K;
> mcfg->memseg[0].len = internal_config.memory;
> mcfg->memseg[0].socket_id = 0;
> return 0;
> }
>
> If it fails to get the virt2phys mapping it actually assigns iovas starting
> from 0 to the memory segments, cf. set_physaddrs eal_memory.c:263
Right, this is the case here.
>
>>
>>
>> >
>> >
>> >>
>> >>>
>> >>> Signed-off-by: Alexey Kardashevskiy
>> >>> ---
>> >>> lib/librte_eal/linuxapp/eal/eal_vfio.c | 12 ++--
>> >>> 1 file changed, 10 insertions(+), 2 deletions(-)
>> >>>
>> >>> diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c b/lib/
>> >>> librte_eal/linuxapp/eal/eal_vfio.c
>> >>> index 46f951f4d..8b8e75c4f 100644
>> >>> --- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
>> >>> +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
>> >>> @@ -658,7 +658,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
>> >>> {
>> >>> const struct rte_memseg *ms = rte_eal_get_physmem_layout();
>> >>> int i, ret;
>> >>> -
>> >>> + phys_addr_t io_offset;
>> >>> struct vfio_iommu_spapr_register_memory reg = {
>> >>>.argsz = sizeof(reg),
>> >>>.flags = 0
>> >>> @@ -702,6 +702,13 @@ vfio_spapr_dma_map(int vfio_container_fd)
>> >>>return -1;
>> >>> }
>> >>>
>> >>> + io_offset = create.start_addr;
>> >>> + if (io_offset) {
>> >>> + RTE_LOG(ERR, EAL, " DMA offsets other than zero is not
>> supported, "
>> >>> +"new window is created at %lx\n", io_offset);
>> >>> + return -1;
>> >>> + }
>> >>> +
>> >>> /* map all DPDK segments for DMA. use 1:1 PA to IOVA mapping */
>> >>> for (i = 0; i < RTE_MAX_MEMSEG; i++) {
>> >>>struct vfio_iommu_type1_dma_map dma_map;
>> >>> @@ -723,7 +730,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
>> >>>dma_map.argsz = sizeof(struct vfio_iommu_type1_dma_map);
>> >>>dma_map.vaddr = ms[i].addr_64;
>> >>>dma_map.size = ms[i].len;
>> >>> - dma_map.iova = ms[i].phys_addr;
>> >>> + dma_map.iova = io_offset;
>> >>>dma_map.flags = VFIO_DMA_MAP_FLAG_READ |
>> >>> VFIO_DMA_MAP_FLAG_WRITE;
>> >>>
>> >>> @@ -735,6 +742,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
>> >>>
Re: [dpdk-dev] [PATCH v3] ether: use a default for max Rx frame size in configure()
07/04/2017 17:27, Andriy Berestovskyy: > Hey Thomas, > > On 07.04.2017 16:47, Thomas Monjalon wrote: > >> What if we add to the max_rx_pkt_len description: "the effective maximum > >> RX frame size depends on PMD, please refer the PMD guide for the > >> details"? > > > > I think the problem is not in the documentation but in the implementations > > which should be more consistent. > > The hardware is different, there is not much we can do about it. We can return an error if the max_rx_pkt_len cannot be set in the NIC. > Nevertheless, we can fix the false comment and have a default for the > jumbos, which is beneficial for the apps/examples. The examples are using a hardcoded value, so they need to be fixed anyway. > > If I understand well, the inconsistency between drivers was already an > > issue before your patch. > > Your patch fixes an inconsistency in ethdev without fixing the drivers. > > We need to know if it is a good first step and if the drivers can be > > fixed later. > > Thomas, some of the examples use a hard-coded jumbo frame size, which is > too big for the underlaying PMDs, so those examples fail. The plan was > to fix them all with this commit in ethdev but I am not sure now you are > to accept the change. This ethdev patch is about a behaviour change of the API. It is about considering 0 as a request for default value and return an error if a value cannot be set. It will require more agreements and changes in the drivers for returning an error where appropriate. > It is important for us to have those examples working in the upcoming > release, do you think it is better to send fixes for those examples > instead of this commit then? The examples can be improved independently of this patch.
Re: [dpdk-dev] [PATCH v2 0/5] add device removal event
18/04/2017 14:17, Gaetan Rivet: > This new event represents the sudden removal of a device from its bus. > The underlying resources exposed by the bus are expected not to be available > anymore. The application should thus be able to react and possibly clean up > related resources that it reserved for the removed device. > > This event is different from the current hotplug API available in the DPDK > for two reasons: > > 1. It is a reactive design: the application reacts to a device that has been > removed instead of removing a device from its pool. > > 2. The event itself is going further than the current detaching of a device >from a DPDK application. If the bus is a hardware one, it is expected of > the underlying resources to not be available anymore. > > This series adds a new event type to ethdev and implements it in mlx4. > Testpmd is also updated to report all asynchronous ethdev events including > this one for testing purposes and as a practical usage example. > > This series depends on the series titled > [PATCH 1/2] net/mlx4: split the definitions to the header file > > v1 --> v2: > * integrated the series with the new PCI rte_bus implementation. > > I planned on working out a more generic implementation of the RMV event > for the v17.05, however while writing it I found that I had to evolve the > support of interrupts in the PCI rte_bus, which did not seem wise at this > point of the release cycle. > > I consider that this event should be generalized along the LSC event, > going from pure PCI events to generic rte_bus events, given that they can > be relevant to other busses (vdev at least). I would reserve this evolution > for future release however, once a real discussion has taken place. > > Gaetan Rivet (5): > ethdev: introduce device removal event > net/mlx4: device removal event support > app/testpmd: generic event handler > app/testpmd: request link status interrupt > app/testpmd: request device removal interrupt Applied, thanks
Re: [dpdk-dev] [PATCH v2] lib/distributor: fix segfaults in flush
14/04/2017 10:59, David Hunt:
> Occasionally, the distributor single-packet-at-a-time mode will
> segfault because it inadvertently calls some burst mode code when
> flushing packets.
>
> This patch ensures that only the v20 (single mode) codepath is used, and
> returns without falling through to the burst mode code.
>
> Fixes: 775003ad2f96 ("distributor: add new burst-capable library")
>
> v2: Extented commit message. Patch remains the same.
>
> Signed-off-by: David Hunt
> Tested-by: Yong Liu
> Acked-by: Bruce Richardson
Applied, thanks
Re: [dpdk-dev] [PATCH v1] lib/bitratestats: fix integer roundoff
19/04/2017 15:26, Remy Horton:
> In the absence of traffic, it is possible for the bitrate moving average
> to get stuck at a non-zero value, due to the calculated delta being less
> than what an integer can represent.
>
> Fixes: 2ad7ba9a6567 ("bitrate: add bitrate statistics library")
>
> Signed-off-by: Remy Horton
Applied, thanks
PS: please not that the title of this patch does not match
the title of the fixed patch.
Changed to "bitrate: fix integer roundoff"
Re: [dpdk-dev] [PATCH] app/testpmd: fix duplicated rte_metrics.h include
11/04/2017 10:33, Ferruh Yigit:
> On 4/11/2017 9:22 AM, Pascal Mazon wrote:
> > Fixes: 62d3216d6194 ("app/testpmd: add latency statistics calculation")
> >
> > Signed-off-by: Pascal Mazon
>
> Acked-by: Ferruh Yigit
Applied, thanks
Re: [dpdk-dev] [PATCH] app/testpmd: consolidate two duplicate ifdefs into one.
18/04/2017 00:56, Rami Rosen: > Cnsolidate the duplicate #ifdef RTE_TEST_PMD_RECORD_CORE_CYCLES > into one #ifdef. > > Signed-off-by: Rami Rosen Applied, thanks
Re: [dpdk-dev] [PATCH] app/testpmd: enable NUMA support by default
19/04/2017 18:19, Thomas Monjalon: > 24/03/2017 18:00, Bruce Richardson: > > There is little reason for NUMA support in testpmd to be off by default, > > so > > enable it, and add in a new commandline parameter to disable it, if that > > is > > wanted by users. > > > > Signed-off-by: Bruce Richardson > > Any comment or ack? Applied, thanks
Re: [dpdk-dev] [dpdk-stable] [PATCH] kni: fix possible memory leak
18/04/2017 16:21, Ferruh Yigit:
> alloc_q and rx_q fifos holds physical address of the mbufs, and not able
> to free those mbufs explicitly.
>
> But kernel thread reads from rx_q and puts used mbufs into free_q (with
> their virtual addresses.) And kernel thread stopped when application
> close the /dev/kni file on exit. So rx_q has time to be consumed by
> kernel thread but leak is technically possible.
>
> Another fifo, alloc_q has physical addresses too, but all those coming
> from same mempool provided by application, when application quit, all
> mempool already returned back, so this leak can be ignored.
>
> Added check and wait logic for rx_q to be sure kernel consumed the fifo,
> an error message printed after some ammount of wait, and an explicit
> mempool free added for alloc_q.
>
> Fixes: 8451269e6d7b ("kni: remove continuous memory restriction")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ferruh Yigit
Applied, thanks
Re: [dpdk-dev] [PATCH] table: fix hash_ext stats update
> > Fixed stats double update. > > > > Signed-off-by: Aleksey Katargin > > --- > > Thanks, Aleksey! BTW the " rte_table_hash_lru.c " suffers from the same > symptoms, so a patch to fix this one would also be highly appreciated :) > > Ack-ed by: Cristian Dumitrescu Applied, thanks
Re: [dpdk-dev] [PATCH v2] pipeline_firewall: Fix for port range filtering
> > Firewall ACL definition need to use same input index for source and > > destination ports as these are 16 bits and would fit in one ACL > > field of 32 bits. This is required as per librte_acl API. Without this > > UDP/TCP source and destination ports filtering (and for that > > matter ICMP type/code filtering) does not work. > > > > Signed-off-by: Shyam Kumar Shrivastav > > --- > > Reviewed-by: jasvinder.si...@intel.com > Acked-by: cristian.dumitre...@intel.com > > Thanks, Shyam, for debugging this! Applied, thanks
Re: [dpdk-dev] [PATCH 1/5] examples/ip_pipeline: add support for more than 32 CPUs
31/03/2017 16:17, Dumitrescu, Cristian: > > -Original Message- > > From: Andriy Berestovskyy > > [mailto:andriy.berestovs...@caviumnetworks.com] > > Sent: Friday, March 31, 2017 2:37 PM > > To: Dumitrescu, Cristian > > Cc: dev@dpdk.org > > Subject: [PATCH 1/5] examples/ip_pipeline: add support for more than 32 > > CPUs > > > > At the moment ip_pipeline example uses 32 during the initialization, > > which leads to an error on systems with more than 32 CPUs. > > > > Signed-off-by: Andriy Berestovskyy > > > > --- > > Acked-by: Cristian Dumitrescu Series applied, thanks
Re: [dpdk-dev] [PATCH 1/3] examples/ip_fragmentation: limit max frame size
10/04/2017 16:30, Andriy Berestovskyy: > Some PMDs do not support 9,5K jumbo frames, so the example fails. > Limit the frame size to the maximum supported by the underlying NIC. > > Signed-off-by: Andriy Berestovskyy Series squashed and applied, thanks
Re: [dpdk-dev] [PATCH] ethtool: disable promiscuous mode by default
18/04/2017 16:26, Remy Horton: > Probably ought to also add a new command so that promiscuous mode can be > enabled if needed. > > On 12/04/2017 20:58, Qi Zhang wrote: > > Disable promiscuous mode by default since VLAN filter > > does not work when promiscuous mode is enabled. > > > > Signed-off-by: Qi Zhang > > --- > > > > examples/ethtool/ethtool-app/main.c | 1 - > > 1 file changed, 1 deletion(-) > > Acked-by: Remy Horton Applied, thanks
Re: [dpdk-dev] [PATCH v2] examples/performance-thread: add c++ ifdefs
16/04/2017 15:33, Keith Wiles: > Signed-off-by: Keith Wiles > --- > v2 - change ctx.h to be 664 permissions. > > examples/performance-thread/common/arch/x86/ctx.h | 8 > examples/performance-thread/common/lthread.h | 8 > examples/performance-thread/common/lthread_api.h | 8 > examples/performance-thread/common/lthread_cond.h | 8 > examples/performance-thread/common/lthread_diag.h | 9 + > examples/performance-thread/common/lthread_diag_api.h | 8 > examples/performance-thread/common/lthread_int.h | 8 > examples/performance-thread/common/lthread_mutex.h| 8 > examples/performance-thread/common/lthread_objcache.h | 7 +++ > examples/performance-thread/common/lthread_pool.h | 7 +++ > examples/performance-thread/common/lthread_queue.h| 7 +++ > examples/performance-thread/common/lthread_sched.h| 7 +++ > examples/performance-thread/common/lthread_timer.h| 7 +++ > examples/performance-thread/common/lthread_tls.h | 7 +++ > 14 files changed, 107 insertions(+) You have already acked the same patch from Hiroki SHIROKURA. Why re-sending with your authorship?
Re: [dpdk-dev] [PATCH v2] example/performance-thread: lthread support C++
22/03/2017 03:26, Hiroki SHIROKURA:
> Lthread is awesome but it doesn't support C++.
> So I write patch to support lthread to support C++.
> Added "extern C {}" to lthread-headers
>
> Signed-off-by: Hiroki SHIROKURA
> Acked-by: Keith Wiles
Applied, thanks
Re: [dpdk-dev] [PATCH] doc: pvp: fix typo in host's testpmd command line
10/04/2017 09:54, Mcnamara, John:
> > -Original Message-
> > From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
> > Sent: Friday, April 7, 2017 4:06 PM
> > To: dev@dpdk.org; Mcnamara, John
> > Cc: jfrei...@redhat.com; Maxime Coquelin
> > Subject: [PATCH] doc: pvp: fix typo in host's testpmd command line
> >
> > This patch adds missing backslash in host's testpmd command line.
> >
> > Without it the command works, but a single core is used instead of four,
> > which might create confusion.
> >
> > Fixes: 58a2551a160f ("doc: introduce PVP reference benchmark")
> >
> > Cc: John McNamara
> > Signed-off-by: Maxime Coquelin
>
> Acked-by: John McNamara
Applied, thanks
Re: [dpdk-dev] CLI parsing issue
Hi Olivier,
> -Original Message-
> From: Olivier MATZ [mailto:olivier.m...@6wind.com]
> Sent: Thursday, April 20, 2017 4:55 PM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org
> Subject: Re: CLI parsing issue
>
> Hi Wenzhuo,
>
> On Thu, 20 Apr 2017 08:36:38 +, "Lu, Wenzhuo"
> wrote:
> > Hi Olivier,
> > I met a problem thar the parsing result of CLI is wrong.
> > I checked this function, cmdline_parse. It will check the CLI
> > instances one by one. Even if an instance is matched, the parsing will
> > not stop for ambiguous check. Seems the following check may change the
> > parsing result of the previous one,
> > /* fully parsed */
> > tok = match_inst(inst, buf, 0, result.buf,
> > sizeof(result.buf),
> >
> > &dyn_tokens);
> >
> >
> > Is it better to use a temporary validate for match_inst and only store
> > the result when it matches, so the previous result has no chance to be
> > changed? Like bellow,
> >
> >
> > diff --git a/lib/librte_cmdline/cmdline_parse.c
> > b/lib/librte_cmdline/cmdline_parse.c
> > index 763c286..663efd1 100644
> > --- a/lib/librte_cmdline/cmdline_parse.c
> > +++ b/lib/librte_cmdline/cmdline_parse.c
> > @@ -259,6 +259,7 @@
> > char buf[CMDLINE_PARSE_RESULT_BUFSIZE];
> > long double align; /* strong alignment constraint for buf */
> > } result;
> > + char tmp_buf[CMDLINE_PARSE_RESULT_BUFSIZE];
> > cmdline_parse_token_hdr_t
> *dyn_tokens[CMDLINE_PARSE_DYNAMIC_TOKENS];
> > void (*f)(void *, struct cmdline *, void *) = NULL;
> > void *data = NULL;
> > @@ -321,7 +322,7 @@
> > debug_printf("INST %d\n", inst_num);
> >
> > /* fully parsed */
> > - tok = match_inst(inst, buf, 0, result.buf,
> > sizeof(result.buf),
> > + tok = match_inst(inst, buf, 0, tmp_buf,
> > + sizeof(tmp_buf),
> > &dyn_tokens);
> >
> > if (tok > 0) /* we matched at least one token */ @@
> > -329,6 +330,8 @@
> >
> > else if (!tok) {
> > debug_printf("INST fully parsed\n");
> > + memcpy(result.buf, tmp_buf,
> > + CMDLINE_PARSE_RESULT_BUFSIZE);
> > /* skip spaces */
> > while (isblank2(*curbuf)) {
> > curbuf++;
> >
> >
>
> At first glance, I think your patch doesn't hurt. Do you have an example code
> that triggers the issue?
Sorry, I didn't show you the issue we met.
It's easy to reproduce on 17.05 RC1.
"testpmd> set tx loopback 0 on
Invalid port 116"
Whatever the input port id is, it's taken as 116 after parsing the CLI.
Interesting, this issue is triggered by this patch, after I added a new CLI,
the "set tx loopback ..." is not working.
commit 22e6545fd02cab42332acd716b8921dd0aab3ad9
Author: Wenzhuo Lu
Date: Fri Feb 24 11:24:35 2017 +0800
app/testpmd: set TC strict link priority mode
I checked the implement of CLI parsing.
The implementation is going through all the instances in main_ctx to see which
instance can match the string we typed.
If typing "set tx loopback 0 on", it matches cmd_set_tx_loopback, and the
parsing result is,
$2 = {set = "set\000tx loopback 0 off \n", '\000' , tx =
"tx\000loopback 0 off \n", '\000' ,
loopback = "loopback\000\060 off \n", '\000' , port_id = 0
'\000',
on_off = "off\000\n", '\000' }
Till now, everything is fine.
Then the parsing is not stopped, it's going on to check if the string can match
any of the left instances. When checking cmd_strict_link_prio, although it
doesn't match, the parsing result is changed to,
$1 = {set = "set\000tx loopback 0 off \n", '\000' , tx =
"tx\000loopback 0 off \n", '\000' ,
loopback = "loopback\000\060 off \n", '\000' , port_id =
116 't',
on_off = "x\000loopback 0 off \n", '\000' }
You see, now the port id and on_off both are wrong. Port_id points to char 't'
of "tx loopback ...". So it's always 116, the ASCII of 't'.
>
>
> Thanks,
> Olivier
Re: [dpdk-dev] [PATCH] app/testpmd: check port is stopped for QinQ setup
Hi Bernard, > -Original Message- > From: Iremonger, Bernard > Sent: Thursday, April 20, 2017 11:14 PM > To: dev@dpdk.org; Xing, Beilei ; Zhang, Qi > > Cc: Iremonger, Bernard > Subject: [PATCH] app/testpmd: check port is stopped for QinQ setup > > Check port is stopped before configuring it for QinQ, with the "vlan set qinq > on " command. > > Signed-off-by: Bernard Iremonger Acked-by: Beilei Xing Maybe it's better to introduce why stopping port is needed now in commit log.
[dpdk-dev] [dpdk-announce] release candidate 17.05-rc2
A new DPDK release candidate is ready for testing: http://dpdk.org/browse/dpdk/tag/?id=v17.05-rc2 What's new in RC2? - progress on bus rework (PCI and VDEV) - ethdev xstats by ID - new Atomic Rules ark driver - new NXP dpaa2 drivers - a lot of fixes The release notes have been updated: http://dpdk.org/doc/guides/rel_notes/release_17_05.html It was a big RC2 with 271 patches. The next release candidate is expected to include only some bug fixes, tooling, packaging or documentation updates. This 17.05 release could be the beginning of a new process innovating by releasing on time :) Let's expect a RC3 in one week, and possibly a RC4 few days later. Please maintainers, open patchwork to check which patches lack of reviews. Thank you everyone
Re: [dpdk-dev] [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus addresses for DMA map
Alexey Kardashevskiy wrote on 20/04/2017 09:24:02:
> From: Alexey Kardashevskiy
> To: dev@dpdk.org
> Cc: Alexey Kardashevskiy , j...@zurich.ibm.com,
> Gowrishankar Muthukrishnan
> Date: 20/04/2017 09:24
> Subject: [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus
> addresses for DMA map
>
> VFIO_IOMMU_SPAPR_TCE_CREATE ioctl() returns the actual bus address for
> just created DMA window. It happens to start from zero because the
default
> window is removed (leaving no windows) and new window starts from zero.
> However this is not guaranteed and the new window may start from another
> address, this adds an error check.
>
> Another issue is that IOVA passed to VFIO_IOMMU_MAP_DMA should be a PCI
> bus address while in this case a physical address of a user page is used.
> This changes IOVA to start from zero in a hope that the rest of DPDK
> expects this.
This is not the case. DPDK expects a 1:1 mapping PA==IOVA. It will use the
phys_addr of the memory segment it got from /proc/self/pagemap cf.
librte_eal/linuxapp/eal/eal_memory.c. We could try setting it here to the
actual iova which basically makes the whole virtual to phyiscal mapping
with pagemap unnecessary which I believe should be the case for VFIO
anyway. Pagemap should only be needed when using pci_uio.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> lib/librte_eal/linuxapp/eal/eal_vfio.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c b/lib/
> librte_eal/linuxapp/eal/eal_vfio.c
> index 46f951f4d..8b8e75c4f 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
> @@ -658,7 +658,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
> {
> const struct rte_memseg *ms = rte_eal_get_physmem_layout();
> int i, ret;
> -
> + phys_addr_t io_offset;
> struct vfio_iommu_spapr_register_memory reg = {
>.argsz = sizeof(reg),
>.flags = 0
> @@ -702,6 +702,13 @@ vfio_spapr_dma_map(int vfio_container_fd)
>return -1;
> }
>
> + io_offset = create.start_addr;
> + if (io_offset) {
> + RTE_LOG(ERR, EAL, " DMA offsets other than zero is not supported,
"
> +"new window is created at %lx\n", io_offset);
> + return -1;
> + }
> +
> /* map all DPDK segments for DMA. use 1:1 PA to IOVA mapping */
> for (i = 0; i < RTE_MAX_MEMSEG; i++) {
>struct vfio_iommu_type1_dma_map dma_map;
> @@ -723,7 +730,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
>dma_map.argsz = sizeof(struct vfio_iommu_type1_dma_map);
>dma_map.vaddr = ms[i].addr_64;
>dma_map.size = ms[i].len;
> - dma_map.iova = ms[i].phys_addr;
> + dma_map.iova = io_offset;
>dma_map.flags = VFIO_DMA_MAP_FLAG_READ |
> VFIO_DMA_MAP_FLAG_WRITE;
>
> @@ -735,6 +742,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
> return -1;
>}
>
> + io_offset += dma_map.size;
> }
>
> return 0;
> --
> 2.11.0
>
Re: [dpdk-dev] [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus addresses for DMA map
Alexey Kardashevskiy wrote on 20/04/2017 16:22:01:
> From: Alexey Kardashevskiy
> To: Jonas Pfefferle1
> Cc: dev@dpdk.org, Gowrishankar Muthukrishnan
> , Adrian Schuepbach
> Date: 20/04/2017 16:22
> Subject: Re: [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus
> addresses for DMA map
>
> On 20/04/17 23:25, Alexey Kardashevskiy wrote:
> > On 20/04/17 19:04, Jonas Pfefferle1 wrote:
> >> Alexey Kardashevskiy wrote on 20/04/2017 09:24:02:
> >>
> >>> From: Alexey Kardashevskiy
> >>> To: dev@dpdk.org
> >>> Cc: Alexey Kardashevskiy , j...@zurich.ibm.com,
> >>> Gowrishankar Muthukrishnan
> >>> Date: 20/04/2017 09:24
> >>> Subject: [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus
> >>> addresses for DMA map
> >>>
> >>> VFIO_IOMMU_SPAPR_TCE_CREATE ioctl() returns the actual bus address
for
> >>> just created DMA window. It happens to start from zero because the
default
> >>> window is removed (leaving no windows) and new window starts from
zero.
> >>> However this is not guaranteed and the new window may start from
another
> >>> address, this adds an error check.
> >>>
> >>> Another issue is that IOVA passed to VFIO_IOMMU_MAP_DMA should be a
PCI
> >>> bus address while in this case a physical address of a user page is
used.
> >>> This changes IOVA to start from zero in a hope that the rest of DPDK
> >>> expects this.
> >>
> >> This is not the case. DPDK expects a 1:1 mapping PA==IOVA. It will use
the
> >> phys_addr of the memory segment it got from /proc/self/pagemap cf.
> >> librte_eal/linuxapp/eal/eal_memory.c. We could try setting it here to
the
> >> actual iova which basically makes the whole virtual to phyiscal
mapping
> >> with pagemap unnecessary which I believe should be the case for VFIO
> >> anyway. Pagemap should only be needed when using pci_uio.
> >
> >
> > Ah, ok, makes sense now. But it sure needs a big fat comment there as
it is
> > not obvious why host RAM address is used there as DMA window start is
not
> > guaranteed.
>
> Well, either way there is some bug - ms[i].phys_addr and ms[i].addr_64
both
> have exact same value, in my setup it is 3fffb33c which is a
userspace
> address - at least ms[i].phys_addr must be physical address.
This might be the case if you are not using hugetlbfs i.e. passing
"--no-huge" cf. eal_memory.c:980
/* hugetlbfs can be disabled */
if (internal_config.no_hugetlbfs) {
addr = mmap(NULL, internal_config.memory, PROT_READ |
PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
if (addr == MAP_FAILED) {
RTE_LOG(ERR, EAL, "%s: mmap() failed: %s\n", __func__,
strerror(errno));
return -1;
}
mcfg->memseg[0].phys_addr = (phys_addr_t)(uintptr_t)addr;
mcfg->memseg[0].addr = addr;
mcfg->memseg[0].hugepage_sz = RTE_PGSIZE_4K;
mcfg->memseg[0].len = internal_config.memory;
mcfg->memseg[0].socket_id = 0;
return 0;
}
If it fails to get the virt2phys mapping it actually assigns iovas starting
from 0 to the memory segments, cf. set_physaddrs eal_memory.c:263
>
>
> >
> >
> >>
> >>>
> >>> Signed-off-by: Alexey Kardashevskiy
> >>> ---
> >>> lib/librte_eal/linuxapp/eal/eal_vfio.c | 12 ++--
> >>> 1 file changed, 10 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c b/lib/
> >>> librte_eal/linuxapp/eal/eal_vfio.c
> >>> index 46f951f4d..8b8e75c4f 100644
> >>> --- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
> >>> +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
> >>> @@ -658,7 +658,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
> >>> {
> >>> const struct rte_memseg *ms = rte_eal_get_physmem_layout();
> >>> int i, ret;
> >>> -
> >>> + phys_addr_t io_offset;
> >>> struct vfio_iommu_spapr_register_memory reg = {
> >>>.argsz = sizeof(reg),
> >>>.flags = 0
> >>> @@ -702,6 +702,13 @@ vfio_spapr_dma_map(int vfio_container_fd)
> >>>return -1;
> >>> }
> >>>
> >>> + io_offset = create.start_addr;
> >>> + if (io_offset) {
> >>> + RTE_LOG(ERR, EAL, " DMA offsets other than zero is not
> supported, "
> >>> +"new window is created at %lx\n", io_offset);
> >>> + return -1;
> >>> + }
> >>> +
> >>> /* map all DPDK segments for DMA. use 1:1 PA to IOVA mapping */
> >>> for (i = 0; i < RTE_MAX_MEMSEG; i++) {
> >>>struct vfio_iommu_type1_dma_map dma_map;
> >>> @@ -723,7 +730,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
> >>>dma_map.argsz = sizeof(struct vfio_iommu_type1_dma_map);
> >>>dma_map.vaddr = ms[i].addr_64;
> >>>dma_map.size = ms[i].len;
> >>> - dma_map.iova = ms[i].phys_addr;
> >>> + dma_map.iova = io_offset;
> >>>dma_map.flags = VFIO_DMA_MAP_FLAG_READ |
> >>> VFIO_DMA_MAP_FLAG_WRITE;
> >>>
> >>> @@ -735,6 +742,7
[dpdk-dev] [dpdk-announce] release candidate 17.05-rc2
A new DPDK release candidate is ready for testing: http://dpdk.org/browse/dpdk/tag/?id=v17.05-rc2 What's new in RC2? - progress on bus rework (PCI and VDEV) - ethdev xstats by ID - new Atomic Rules ark driver - new NXP dpaa2 drivers - a lot of fixes The release notes have been updated: http://dpdk.org/doc/guides/rel_notes/release_17_05.html It was a big RC2 with 271 patches. The next release candidate is expected to include only some bug fixes, tooling, packaging or documentation updates. This 17.05 release could be the beginning of a new process innovating by releasing on time Let's expect a RC3 in one week, and possibly a RC4 few days later. Please maintainers, open patchwork to check which patches lack of reviews. Thank you everyone
Re: [dpdk-dev] [PATCH] net/ixgbe: align register setting when RSC is disabled
Hi, > -Original Message- > From: Dai, Wei > Sent: Thursday, April 20, 2017 11:06 AM > To: Zhang, Helin; Ananyev, Konstantin; Lu, Wenzhuo; Dai, Wei > Cc: dev@dpdk.org > Subject: [PATCH] net/ixgbe: align register setting when RSC is disabled > > When RSC is not used, the RSC_DIS of register RFCTL should be set according > to ixgbe datasheet. > > Signed-off-by: Wei Dai Acked-by: Wenzhuo Lu
[dpdk-dev] [PATCH] net/virtio-user: fix recognize physical devices
Segfault happens when using virtio-user after commit 7f0a669e7b04
("ethdev: add allocation helper for virtual drivers").
It's due to we use ethdev->device to recognize physical devices,
but after above commit, this field is also filled for virtual
devices. Then we obtain the wrong pci_dev pointer and accessing
its field when copying pci info results in segfault.
To fix it, we use hw->virtio_user_dev to differentiate physical
devices from virtual devices.
Fixes: 6a7c0dfcdf40 ("net/virtio: do not depend on PCI device of ethdev")
Signed-off-by: Jianfeng Tan
---
drivers/net/virtio/virtio_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index e6c57b3..3d712bd 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1348,7 +1348,7 @@ virtio_init_device(struct rte_eth_dev *eth_dev, uint64_t
req_features)
if (virtio_negotiate_features(hw, req_features) < 0)
return -1;
- if (eth_dev->device) {
+ if (!hw->virtio_user_dev) {
pci_dev = RTE_DEV_TO_PCI(eth_dev->device);
rte_eth_copy_pci_info(eth_dev, pci_dev);
}
--
2.7.4
Re: [dpdk-dev] [PATCH v4 1/3] lib/librte_ether: add support for port reset
On Thu, Apr 20, 2017 at 09:17:24AM +, Zhao1, Wei wrote:
> > > > Please explain exactly the responsibility of this function, and how
> > > > it is different from calling stop/configure/start.
> > >
> > > In this reset feature, reset function can do the calling
> > > stop/configure/start process, but also It can also do some restore
> > > work for the port, for example, it can restore the added parameters of
> > vlan, mac_addrs, promisc_unicast_enabled falg and
> > promisc_multicast_enabled flag.
> > > Maybe , I should add this explanation in the patch comments or function
> > comments?
> >
> > I'm curious why we have to do save & restore for a reset operation.
> > Why some configures have to be saved and restored? Doesn't "reset"
> > literally means reset everything?
> >
>
> Users maybe do not want to do a second configuration operation to waste time
> after reset which lost all previous configuration.
> But he still want these configuration valid after reset.
> So, save & restore can help them to save this process time and effort.
>
> > Even though, how do you tell what kind of configures need be restored and
> > what should not? Again, even though, will all PMDs supports restoring the
> > same set of configurations?
> >
>
> Yes, this is hard to say what may be need and what may be not for user.
> Now, the kinds of supported is list in patch set comment. And only i40e NIC
> support this feature.
Why it's the configurations listed in patch 2? Because they are requested
by customers?
Is that all could be saved? If not, are you going to save & restore all
possible configurations?
Assuming the configurations saved & restored may differ from different
PMD drivers, how could you keep the consistency then? And judging that the
application has no idea about the difference (yet it knows nothing about
what kind of configurations will be saved), how could the application know
that some configurations are not saved & restored by the driver that it
has to do re-configuration by itself?
> > While looking at your reset implementation for i40e, it looks more complex
> > than necessary: just thinking we have to call "xxx_queue_setup"
> > for all PMDs.
> >
> > I'm thinking a simple hardware reset might be enough?
> >
> > /* literally reset the hardware: reset everything */
> > rte_eth_reset(port)
> > {
> > eth_dev->ops->reset();
> > }
> >
>
> You mean just do a reset and do not restore any configuration?
> That may not meet the need for this feature from customer?
Right, I'm just aware of the configuration might be done by PF (but not
only by the application), that the VF port may be not aware of those
configurations. So the save & restore is needed. I don't quite like
how it is done in this patch set though. I also don't think the API is
well named: as said, reset should literally reset everything.
We may need think how to do it properly.
Thomas, Konstantin, what do you guys think of it?
--yliu
Re: [dpdk-dev] [PATCH 1/2] net/ixgbe: remove a useless item type check
Hi Wei,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> Sent: Thursday, April 20, 2017 11:28 AM
> To: dev@dpdk.org
> Cc: Zhao1, Wei
> Subject: [dpdk-dev] [PATCH 1/2] net/ixgbe: remove a useless item type check
>
> Remove a useless item type check for fdir flow rule.
>
> Fixes: 11777435c72 ("net/ixgbe: parse flow director filter")
>
> Signed-off-by: Wei Zhao
> ---
> drivers/net/ixgbe/ixgbe_flow.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
> index 7ce740e..11d8cc9 100644
> --- a/drivers/net/ixgbe/ixgbe_flow.c
> +++ b/drivers/net/ixgbe/ixgbe_flow.c
> @@ -2346,16 +2346,9 @@ ixgbe_parse_fdir_filter_tunnel(const struct
> rte_flow_attr *attr,
> RTE_FLOW_ERROR_TYPE_ITEM,
> item, "Not supported by fdir filter");
> return -rte_errno;
> - } else if (item->type != RTE_FLOW_ITEM_TYPE_END) {
> - memset(rule, 0, sizeof(struct ixgbe_fdir_rule));
> - rte_flow_error_set(error, EINVAL,
> - RTE_FLOW_ERROR_TYPE_ITEM,
> - item, "Not supported by fdir filter");
> - return -rte_errno;
> }
Seems the item type only can be END. Why not remove the VLAN check either?
> +
> /* check if the next not void item is END */
> - index++;
> - NEXT_ITEM_OF_PATTERN(item, pattern, index);
> if (item->type != RTE_FLOW_ITEM_TYPE_END) {
> memset(rule, 0, sizeof(struct ixgbe_fdir_rule));
> rte_flow_error_set(error, EINVAL,
> --
> 2.9.3
Re: [dpdk-dev] [PATCH 2/2] net/ixgbe: fix a error type check for flow type
Hi Wei,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> Sent: Thursday, April 20, 2017 11:28 AM
> To: dev@dpdk.org
> Cc: Zhao1, Wei
> Subject: [dpdk-dev] [PATCH 2/2] net/ixgbe: fix a error type check for flow
> type
>
> The type check for flow_type should be IXGBE_ATR_FLOW_TYPE_IPV4 in
> special card not RTE_ETH_FLOW_NONFRAG_IPV4_OTHER.
>
> Fixes: dc0c16105d2 ("ixgbe: fix X550 flow director check")
>
> Signed-off-by: Wei Zhao
> ---
> drivers/net/ixgbe/ixgbe_fdir.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_fdir.c b/drivers/net/ixgbe/ixgbe_fdir.c
> index 3b9d60c..6f19b91 100644
> --- a/drivers/net/ixgbe/ixgbe_fdir.c
> +++ b/drivers/net/ixgbe/ixgbe_fdir.c
> @@ -1241,7 +1241,7 @@ ixgbe_fdir_filter_program(struct rte_eth_dev *dev,
>hw->mac.type == ixgbe_mac_X550EM_x ||
>hw->mac.type == ixgbe_mac_X550EM_a) &&
> (rule->ixgbe_fdir.formatted.flow_type ==
> - RTE_ETH_FLOW_NONFRAG_IPV4_OTHER) &&
> + IXGBE_ATR_FLOW_TYPE_IPV4) &&
> (info->mask.src_port_mask != 0 ||
>info->mask.dst_port_mask != 0)) {
> PMD_DRV_LOG(ERR, "By this device,"
> --
> 2.9.3
It's a good fix. But please change the comments and error log accordingly.
[dpdk-dev] [PATCH dpdk] i40e/ppc64/altivec: Fix compile errors on POWER8
Fixes: 67f038076657 ("net/i40e: enable per-device packet type mapping")
Signed-off-by: Alexey Kardashevskiy
---
drivers/net/i40e/i40e_rxtx_vec_altivec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
index 07de31b01..f4036ea28 100644
--- a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
+++ b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
@@ -208,13 +208,13 @@ desc_to_ptype_v(vector unsigned long descs[4], struct
rte_mbuf **rx_pkts,
ptype1 = vec_sr(ptype1, (vector unsigned long){30, 30});
rx_pkts[0]->packet_type =
- ptype_tbl[(*(vector unsigned char *)&ptype0)[0])];
+ ptype_tbl[(*(vector unsigned char *)&ptype0)[0]];
rx_pkts[1]->packet_type =
- ptype_tbl[(*(vector unsigned char *)&ptype0)[8])];
+ ptype_tbl[(*(vector unsigned char *)&ptype0)[8]];
rx_pkts[2]->packet_type =
- ptype_tbl[(*(vector unsigned char *)&ptype1)[0])];
+ ptype_tbl[(*(vector unsigned char *)&ptype1)[0]];
rx_pkts[3]->packet_type =
- ptype_tbl[(*(vector unsigned char *)&ptype1)[8])];
+ ptype_tbl[(*(vector unsigned char *)&ptype1)[8]];
}
/* Notice:
--
2.11.0
Re: [dpdk-dev] [PATCH dpdk] i40e/ppc64/altivec: Fix compile errors on POWER8
On 21/04/17 13:10, Alexey Kardashevskiy wrote:
> Fixes: 67f038076657 ("net/i40e: enable per-device packet type mapping")
> Signed-off-by: Alexey Kardashevskiy
ah, never mind, fixed already.
> ---
> drivers/net/i40e/i40e_rxtx_vec_altivec.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
> b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
> index 07de31b01..f4036ea28 100644
> --- a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
> +++ b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
> @@ -208,13 +208,13 @@ desc_to_ptype_v(vector unsigned long descs[4], struct
> rte_mbuf **rx_pkts,
> ptype1 = vec_sr(ptype1, (vector unsigned long){30, 30});
>
> rx_pkts[0]->packet_type =
> - ptype_tbl[(*(vector unsigned char *)&ptype0)[0])];
> + ptype_tbl[(*(vector unsigned char *)&ptype0)[0]];
> rx_pkts[1]->packet_type =
> - ptype_tbl[(*(vector unsigned char *)&ptype0)[8])];
> + ptype_tbl[(*(vector unsigned char *)&ptype0)[8]];
> rx_pkts[2]->packet_type =
> - ptype_tbl[(*(vector unsigned char *)&ptype1)[0])];
> + ptype_tbl[(*(vector unsigned char *)&ptype1)[0]];
> rx_pkts[3]->packet_type =
> - ptype_tbl[(*(vector unsigned char *)&ptype1)[8])];
> + ptype_tbl[(*(vector unsigned char *)&ptype1)[8]];
> }
>
> /* Notice:
>
--
Alexey
Re: [dpdk-dev] [PATCH v7 1/3] lib/librte_ether: add support for port reset
Hi, Thomas
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, April 21, 2017 4:50 AM
> To: Zhao1, Wei ; Lu, Wenzhuo
>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 1/3] lib/librte_ether: add support for port
> reset
>
> 10/04/2017 05:02, Wei Zhao:
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -1509,6 +1512,9 @@ struct eth_dev_ops {
> > eth_l2_tunnel_offload_set_t l2_tunnel_offload_set;
> > /** Enable/disable l2 tunnel offload functions. */
> >
> > + /** Reset device. */
> > + eth_dev_reset_t dev_reset;
> > +
> > eth_set_queue_rate_limit_t set_queue_rate_limit; /**< Set queue
> rate
> > limit. */
> >
> > rss_hash_update_t rss_hash_update; /** Configure RSS hash
>
> This new op should be added at the end of the structure to avoid ABI issue.
Ok, I will change as your suggestion in next version.
>
> > protocols. */ @@ -4413,6 +4419,28 @@ int
> > rte_eth_dev_get_name_by_port(uint8_t port_id, char *name);
> >
> > /**
> > + * Reset an ethernet device when it's not working. One scenario is,
> > + after
> > PF + * port is down and up, the related VF port should be reset.
> > + * The API will stop the port, clear the rx/tx queues, re-setup the
> > + rx/tx
> > + * queues, restart the port.
> > + * Before calling this API, APP should stop the rx/tx. When tx is
> > + being
> > stopped, + * APP can drop the packets and release the buffer instead
> > of sending them. + * This function can also do some restore work for
> > the port, for example, it can + * restore the added parameters of
> > vlan, mac_addrs, promisc_unicast_enabled + * flag and
> promisc_multicast_enabled flag.
> > + *
> > + * @param port_id
> > + * The port identifier of the Ethernet device.
> > + *
> > + * @return
> > + * - (0) if successful.
> > + * - (-ENODEV) if port identifier is invalid.
> > + * - (-ENOTSUP) if hardware doesn't support this function.
> > + */
> > +int
> > +rte_eth_dev_reset(uint8_t port_id);
>
> The declarations and function definitions should be better placed after start
> and stop functions.
Ok, I will change as your suggestion in next version.
Re: [dpdk-dev] [PATCH dpdk] i40e/ppc64/altivec: Fix compile errors on POWER8
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Alexey
> Kardashevskiy
> Sent: Friday, April 21, 2017 11:10 AM
> To: dev@dpdk.org
> Cc: Alexey Kardashevskiy
> Subject: [dpdk-dev] [PATCH dpdk] i40e/ppc64/altivec: Fix compile errors on
> POWER8
>
> Fixes: 67f038076657 ("net/i40e: enable per-device packet type mapping")
> Signed-off-by: Alexey Kardashevskiy
> ---
> drivers/net/i40e/i40e_rxtx_vec_altivec.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
> b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
> index 07de31b01..f4036ea28 100644
> --- a/drivers/net/i40e/i40e_rxtx_vec_altivec.c
> +++ b/drivers/net/i40e/i40e_rxtx_vec_altivec.c
> @@ -208,13 +208,13 @@ desc_to_ptype_v(vector unsigned long descs[4],
> struct rte_mbuf **rx_pkts,
> ptype1 = vec_sr(ptype1, (vector unsigned long){30, 30});
>
> rx_pkts[0]->packet_type =
> - ptype_tbl[(*(vector unsigned char *)&ptype0)[0])];
> + ptype_tbl[(*(vector unsigned char *)&ptype0)[0]];
> rx_pkts[1]->packet_type =
> - ptype_tbl[(*(vector unsigned char *)&ptype0)[8])];
> + ptype_tbl[(*(vector unsigned char *)&ptype0)[8]];
> rx_pkts[2]->packet_type =
> - ptype_tbl[(*(vector unsigned char *)&ptype1)[0])];
> + ptype_tbl[(*(vector unsigned char *)&ptype1)[0]];
> rx_pkts[3]->packet_type =
> - ptype_tbl[(*(vector unsigned char *)&ptype1)[8])];
> + ptype_tbl[(*(vector unsigned char *)&ptype1)[8]];
> }
>
> /* Notice:
> --
> 2.11.0
Acked-by: Qi Zhang
Re: [dpdk-dev] [PATCH v7 2/3] net/i40e: implement device reset on port
Hi, Thomas
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, April 21, 2017 5:12 AM
> To: Zhao1, Wei ; Lu, Wenzhuo
>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 2/3] net/i40e: implement device reset on
> port
>
> 10/04/2017 05:02, Wei Zhao:
> > + if (adapter->reset_store_data == NULL) {
> > + PMD_INIT_LOG(ERR, "Failed to allocate %ld bytes needed
> to"
> > + " to store data when reset vf",
> > + sizeof(struct i40e_vf_reset_store));
>
> Compilation fails for 32-bit.
> %ld must be replaced by %zu
Ok, I will change as your suggestion in next version.
Re: [dpdk-dev] [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus addresses for DMA map
On 21/04/17 05:16, gowrishankar muthukrishnan wrote:
> On Thursday 20 April 2017 07:52 PM, Alexey Kardashevskiy wrote:
>> On 20/04/17 23:25, Alexey Kardashevskiy wrote:
>>> On 20/04/17 19:04, Jonas Pfefferle1 wrote:
Alexey Kardashevskiy wrote on 20/04/2017 09:24:02:
> From: Alexey Kardashevskiy
> To: dev@dpdk.org
> Cc: Alexey Kardashevskiy , j...@zurich.ibm.com,
> Gowrishankar Muthukrishnan
> Date: 20/04/2017 09:24
> Subject: [PATCH dpdk 5/5] RFC: vfio/ppc64/spapr: Use correct bus
> addresses for DMA map
>
> VFIO_IOMMU_SPAPR_TCE_CREATE ioctl() returns the actual bus address for
> just created DMA window. It happens to start from zero because the
> default
> window is removed (leaving no windows) and new window starts from zero.
> However this is not guaranteed and the new window may start from another
> address, this adds an error check.
>
> Another issue is that IOVA passed to VFIO_IOMMU_MAP_DMA should be a PCI
> bus address while in this case a physical address of a user page is used.
> This changes IOVA to start from zero in a hope that the rest of DPDK
> expects this.
This is not the case. DPDK expects a 1:1 mapping PA==IOVA. It will use the
phys_addr of the memory segment it got from /proc/self/pagemap cf.
librte_eal/linuxapp/eal/eal_memory.c. We could try setting it here to the
actual iova which basically makes the whole virtual to phyiscal mapping
with pagemap unnecessary which I believe should be the case for VFIO
anyway. Pagemap should only be needed when using pci_uio.
>>>
>>> Ah, ok, makes sense now. But it sure needs a big fat comment there as it is
>>> not obvious why host RAM address is used there as DMA window start is not
>>> guaranteed.
>> Well, either way there is some bug - ms[i].phys_addr and ms[i].addr_64 both
>> have exact same value, in my setup it is 3fffb33c which is a userspace
>> address - at least ms[i].phys_addr must be physical address.
>
> This patch breaks i40e_dev_init() in my server.
>
> EAL: PCI device 0004:01:00.0 on NUMA socket 1
> EAL: probe driver: 8086:1583 net_i40e
> EAL: using IOMMU type 7 (sPAPR)
> eth_i40e_dev_init(): Failed to init adminq: -32
> EAL: Releasing pci mapped resource for 0004:01:00.0
> EAL: Calling pci_unmap_resource for 0004:01:00.0 at 0x3fff82aa
> EAL: Requested device 0004:01:00.0 cannot be used
> EAL: PCI device 0004:01:00.1 on NUMA socket 1
> EAL: probe driver: 8086:1583 net_i40e
> EAL: using IOMMU type 7 (sPAPR)
> eth_i40e_dev_init(): Failed to init adminq: -32
> EAL: Releasing pci mapped resource for 0004:01:00.1
> EAL: Calling pci_unmap_resource for 0004:01:00.1 at 0x3fff82aa
> EAL: Requested device 0004:01:00.1 cannot be used
> EAL: No probed ethernet devices
>
> I have two memseg each of 1G size. Their mapped PA and VA are also different.
>
> (gdb) p /x ms[0]
> $3 = {phys_addr = 0x1e0b00, {addr = 0x3effaf00, addr_64 =
> 0x3effaf00},
> len = 0x4000, hugepage_sz = 0x100, socket_id = 0x1, nchannel =
> 0x0, nrank = 0x0}
> (gdb) p /x ms[1]
> $4 = {phys_addr = 0xf6d00, {addr = 0x3efbaf00, addr_64 =
> 0x3efbaf00},
> len = 0x4000, hugepage_sz = 0x100, socket_id = 0x0, nchannel =
> 0x0, nrank = 0x0}
>
> Could you please recheck this. May be, if new DMA window does not start
> from bus address 0,
> only then you reset dma_map.iova for this offset ?
As we figured out, it is --no-huge effect.
Another thing - as I read the code - the window size comes from
rte_eal_get_physmem_size(). On my 512GB machine, DPDK allocates only 16GB
window so it is far away from 1:1 mapping which is believed to be DPDK
expectation. Looking now for a better version of rte_eal_get_physmem_size()...
And another problem - after few unsuccessful starts of app/testpmd, all
huge pages are gone:
aik@stratton2:~$ cat /proc/meminfo
MemTotal: 535527296 kB
MemFree:516662272 kB
MemAvailable: 515501696 kB
...
HugePages_Total:1024
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize: 16384 kB
How is that possible? What is pinning these pages so testpmd process exit
does not clear that up?
>
>
> Thanks,
> Gowrishankar
>
>>
>>>
> Signed-off-by: Alexey Kardashevskiy
> ---
> lib/librte_eal/linuxapp/eal/eal_vfio.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c b/lib/
> librte_eal/linuxapp/eal/eal_vfio.c
> index 46f951f4d..8b8e75c4f 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
> @@ -658,7 +658,7 @@ vfio_spapr_dma_map(int vfio_container_fd)
> {
> const struct rte_memseg *ms = rte_eal_get_physmem_layout();
> int i, ret;
> -
> + phys_addr_t io_offset;
> struct vfio_iommu_spapr_register_memory reg = {
> .ar
Re: [dpdk-dev] [PATCH 0/4] update ixgbe base driver to version 2017-03-29
Tested-by: Peng Yuan - Tested Branch: dpdk v17.02 - Tested Commit: b9ebab26d98f61bc407572623c4bee4390a8b432 - OS: 4.4.26-yocto-standard - IFWI: HAVLCRB1.X64.0014.D76.1703170116 - NIC: Intel Corporation Device [8086:15ce] (rev 10) driver: ixgbe-5.0.7 firmware-version: 0x86f8/ 0x8714 - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 69 cases, 69 passed, 0 failed You can check the test report from attachment. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai Sent: Tuesday, April 18, 2017 2:57 PM To: Zhang, Helin ; Ananyev, Konstantin ; Lu, Wenzhuo Cc: dev@dpdk.org; Dai, Wei Subject: [dpdk-dev] [PATCH 0/4] update ixgbe base driver to version 2017-03-29 This patch set has following 4 patches. No any new device id is added. net/ixgbe/base: acquire PHY semaphore before device reset net/ixgbe/base: add support for 2.5G KX physical layer net/ixgbe/base: add MAC X550em/X557 LED on/off support net/ixgbe/base: update base driver version to 2017.03.29 drivers/net/ixgbe/base/README| 2 +- drivers/net/ixgbe/base/ixgbe_82598.c | 4 ++-- drivers/net/ixgbe/base/ixgbe_82598.h | 2 +- drivers/net/ixgbe/base/ixgbe_82599.c | 4 ++-- drivers/net/ixgbe/base/ixgbe_82599.h | 2 +- drivers/net/ixgbe/base/ixgbe_api.c | 2 +- drivers/net/ixgbe/base/ixgbe_api.h | 2 +- drivers/net/ixgbe/base/ixgbe_phy.c | 4 ++-- drivers/net/ixgbe/base/ixgbe_phy.h | 2 +- drivers/net/ixgbe/base/ixgbe_type.h | 37 ++-- drivers/net/ixgbe/base/ixgbe_x540.c | 12 ++-- drivers/net/ixgbe/base/ixgbe_x540.h | 2 +- drivers/net/ixgbe/base/ixgbe_x550.c | 33 drivers/net/ixgbe/base/ixgbe_x550.h | 2 +- 14 files changed, 72 insertions(+), 38 deletions(-) -- 2.7.4
Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped SFP/SFP+
Hi Srini,
> -Original Message-
> From: Srini J [mailto:srinid...@gmail.com]
> Sent: Thursday, April 20, 2017 6:48 PM
> To: Lu, Wenzhuo; Ananyev, Konstantin
> Cc: dev@dpdk.org; Srinivasan Jayarajan
> Subject: [PATCH] net/ixgbe: support detection of hot swapped SFP/SFP+
>
> From: Srinivasan Jayarajan
>
> Adds support to use a different SFP/SFP+ without restarting the
> DPDK app. rte_eth_dev_stop()/rte_eth_dev_start() will need
> to be called on the port to detect the SFP/SFP+ change.
>
> Signed-off-by: Srinivasan Jayarajan
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index c226e0a..85407a9 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -2520,6 +2520,19 @@ static int eth_ixgbevf_pci_remove(struct
> rte_pci_device *pci_dev)
> status = ixgbe_pf_reset_hw(hw);
> if (status != 0)
> return -1;
> +
> + /* Set phy type as unknown so that PHY scan is always done */
> + hw->phy.type = ixgbe_phy_unknown;
> +
> + /* Identify PHY and related function pointers */
> + status = hw->phy.ops.init(hw);
> +
> + if (status == IXGBE_ERR_SFP_NOT_SUPPORTED) {
> + PMD_INIT_LOG(ERR, "Found unsupported SFP in "
> + "ixgbe_dev_start(): %d", status);
> + return -1;
> + }
> +
I have the concern if it's a good idea to move the functions from dev_init to
dev_start. Especially this function named init.
Anyway, let's listen to others opinion.
> hw->mac.ops.start_hw(hw);
> hw->mac.get_link_status = true;
>
> --
> 1.8.1.4
Re: [dpdk-dev] DPAA2 crypto license
Hi Thomas, On 4/20/2017 11:13 PM, Thomas Monjalon wrote: Hi, I'm not a lawyer but I think there may be an issue with the files in drivers/crypto/dpaa2_sec/hw/ The header of these files is: /* * Copyright 2008-2016 Freescale Semiconductor, Inc. * * SPDX-License-Identifier: BSD-3-Clause or GPL-2.0+ */ Could we make it more explicit than this SPDX tag? Thanks for your comments. I would check this internally and send the patch shortly. Regards, Akhil
[dpdk-dev] Printing statistics on running passthrough pipeline in ip_pipeline application
Hi, I am running ip_pipeline application using ip_pipeline.cfg file. How can I see the statistics of the packets that is being sent and received from this pipeline? I tried running as shown below: pipeline> p 1 port in 0 enable pipeline> p 1 port in 1 enable pipeline> p 1 stats port in 1 Pipeline 1 - stats for input port 1: Pkts in: 0 Pkts dropped by AH: 0 Pkts dropped by other: 0 pipeline> p 1 stats port in 0 Pipeline 1 - stats for input port 0: Pkts in: 0 Pkts dropped by AH: 0 Pkts dropped by other: 0 pipeline> p 1 stats port out 0 Pipeline 1 - stats for output port 0: Pkts in: 0 Pkts dropped by AH: 0 Pkts dropped by other: 0 pipeline> p 1 stats port out 1 Pipeline 1 - stats for output port 1: Pkts in: 0 Pkts dropped by AH: 0 Pkts dropped by other: 0 I can see the packet being received and forwarded using wireshark. But not able to see in the statistics. Isn't this the right command to use? Thanks for your reply and help. Regards, Nidhia Varghese
Re: [dpdk-dev] Printing statistics on running passthrough pipeline in ip_pipeline application
Enable flags in dpdk/config/common_base and recompile
CONFIG_RTE_*_STATS_COLLECT=y
{* for PIPELINE,PORT,TABLE ...}
On Fri, Apr 21, 2017 at 11:58 AM, Nidhia Varghese <
nidhiavarghes...@gmail.com> wrote:
> Hi,
>
> I am running ip_pipeline application using ip_pipeline.cfg file. How can I
> see the statistics of the packets that is being sent and received from this
> pipeline?
>
> I tried running as shown below:
>
> pipeline> p 1 port in 0 enable
> pipeline> p 1 port in 1 enable
> pipeline> p 1 stats port in 1
> Pipeline 1 - stats for input port 1:
> Pkts in: 0
> Pkts dropped by AH: 0
> Pkts dropped by other: 0
> pipeline> p 1 stats port in 0
> Pipeline 1 - stats for input port 0:
> Pkts in: 0
> Pkts dropped by AH: 0
> Pkts dropped by other: 0
> pipeline> p 1 stats port out 0
> Pipeline 1 - stats for output port 0:
> Pkts in: 0
> Pkts dropped by AH: 0
> Pkts dropped by other: 0
> pipeline> p 1 stats port out 1
> Pipeline 1 - stats for output port 1:
> Pkts in: 0
> Pkts dropped by AH: 0
> Pkts dropped by other: 0
>
> I can see the packet being received and forwarded using wireshark. But not
> able to see in the statistics. Isn't this the right command to use?
>
> Thanks for your reply and help.
>
> Regards,
> Nidhia Varghese
>
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: fix adding invalid MAC addr
Hi Wei,
> -Original Message-
> From: Dai, Wei
> Sent: Thursday, April 13, 2017 4:21 PM
> To: thomas.monja...@6wind.com; harish.pa...@cavium.com;
> rasesh.m...@cavium.com; stephen.h...@broadcom.com;
> ajit.khapa...@broadcom.com; Lu, Wenzhuo; Zhang, Helin; Ananyev,
> Konstantin; Wu, Jingjing; Chen, Jing D; adrien.mazarg...@6wind.com;
> nelio.laranje...@6wind.com; Richardson, Bruce;
> yuanhan@linux.intel.com; maxime.coque...@redhat.com
> Cc: dev@dpdk.org; Dai, Wei; sta...@dpdk.org
> Subject: [PATCH v4 1/3] ethdev: fix adding invalid MAC addr
>
> some customers find adding mac addr to VF sometimes can fail, but it is still
> stored in dev->data->mac_addrs[ ]. So this can lead to some errors that
> assumes the non-zero entry in
> dev->data->mac_addrs[ ] is valid.
>
> Fixes: af75078fece3 ("first public release")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> ---
> drivers/net/bnx2x/bnx2x_ethdev.c | 7 +--
> drivers/net/bnxt/bnxt_ethdev.c | 12 ++--
> drivers/net/e1000/base/e1000_api.c | 2 +-
> drivers/net/e1000/em_ethdev.c | 6 +++---
> drivers/net/e1000/igb_ethdev.c | 5 +++--
> drivers/net/enic/enic.h| 2 +-
> drivers/net/enic/enic_ethdev.c | 4 ++--
> drivers/net/enic/enic_main.c | 6 +++---
> drivers/net/fm10k/fm10k_ethdev.c | 3 ++-
> drivers/net/i40e/i40e_ethdev.c | 11 ++-
> drivers/net/i40e/i40e_ethdev_vf.c | 8
> drivers/net/ixgbe/ixgbe_ethdev.c | 27 ++-
> drivers/net/mlx4/mlx4.c| 18 +++---
> drivers/net/mlx5/mlx5.h| 4 ++--
> drivers/net/mlx5/mlx5_mac.c| 16 ++--
> drivers/net/qede/qede_ethdev.c | 6 --
> drivers/net/ring/rte_eth_ring.c| 3 ++-
> drivers/net/virtio/virtio_ethdev.c | 13 +++--
> lib/librte_ether/rte_ethdev.c | 15 +--
> lib/librte_ether/rte_ethdev.h | 2 +-
> 20 files changed, 100 insertions(+), 70 deletions(-)
>
>
> int bnxt_link_update_op(struct rte_eth_dev *eth_dev, int
> wait_to_complete) diff --git a/drivers/net/e1000/base/e1000_api.c
> b/drivers/net/e1000/base/e1000_api.c
> index f7cf83b..dcb53f7 100644
> --- a/drivers/net/e1000/base/e1000_api.c
> +++ b/drivers/net/e1000/base/e1000_api.c
> @@ -855,7 +855,7 @@ int e1000_rar_set(struct e1000_hw *hw, u8 *addr,
> u32 index)
> if (hw->mac.ops.rar_set)
> return hw->mac.ops.rar_set(hw, addr, index);
>
> - return E1000_SUCCESS;
> + return E1000_ERR_NO_SPACE;
> }
NACK here. Normally we try to avoid changing base code. And I don't think the
change is necessary.
