* [dpdk-dev] [PATCH v5 14/15] mk: Introduce ARMv7 architecture
@ 2015-10-30 0:25 3% ` Jan Viktorin
0 siblings, 0 replies; 200+ results
From: Jan Viktorin @ 2015-10-30 0:25 UTC (permalink / raw)
To: david.marchand, David Hunt, Thomas Monjalon; +Cc: Vlastimil Kosar, dev
From: Vlastimil Kosar <kosar@rehivetech.com>
Make DPDK run on ARMv7-A architecture. This patch assumes
ARM Cortex-A9. However, it is known to be working on Cortex-A7
and Cortex-A15.
Signed-off-by: Vlastimil Kosar <kosar@rehivetech.com>
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
---
v2:
* the -mtune parameter of GCC is configurable now
* the -mfpu=neon can be turned off
v3: XMM_SIZE is defined in rte_vect.h in a following patch
v4:
* update release notes for 2.2
* get rid of CONFIG_RTE_BITMAP_OPTIMIZATIONS=0 setting
* rename arm defconfig: "armv7-a" -> "arvm7a"
* disable pipeline and table modules unless lpm is fixed
---
config/defconfig_arm-armv7a-linuxapp-gcc | 74 ++++++++++++++++++++++++++++++++
doc/guides/rel_notes/release_2_2.rst | 5 +++
mk/arch/arm/rte.vars.mk | 39 +++++++++++++++++
mk/machine/armv7-a/rte.vars.mk | 67 +++++++++++++++++++++++++++++
4 files changed, 185 insertions(+)
create mode 100644 config/defconfig_arm-armv7a-linuxapp-gcc
create mode 100644 mk/arch/arm/rte.vars.mk
create mode 100644 mk/machine/armv7-a/rte.vars.mk
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc
new file mode 100644
index 0000000..d623222
--- /dev/null
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -0,0 +1,74 @@
+# BSD LICENSE
+#
+# Copyright (C) 2015 RehiveTech. All right 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 RehiveTech nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+#include "common_linuxapp"
+
+CONFIG_RTE_MACHINE="armv7-a"
+
+CONFIG_RTE_ARCH="arm"
+CONFIG_RTE_ARCH_ARM=y
+CONFIG_RTE_ARCH_ARMv7=y
+CONFIG_RTE_ARCH_ARM_TUNE="cortex-a9"
+CONFIG_RTE_ARCH_ARM_NEON=y
+
+CONFIG_RTE_TOOLCHAIN="gcc"
+CONFIG_RTE_TOOLCHAIN_GCC=y
+
+# ARM doesn't have support for vmware TSC map
+CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
+
+# KNI is not supported on 32-bit
+CONFIG_RTE_LIBRTE_KNI=n
+
+# PCI is usually not used on ARM
+CONFIG_RTE_EAL_IGB_UIO=n
+
+# fails to compile on ARM
+CONFIG_RTE_LIBRTE_ACL=n
+CONFIG_RTE_LIBRTE_LPM=n
+CONFIG_RTE_LIBRTE_TABLE=n
+CONFIG_RTE_LIBRTE_PIPELINE=n
+
+# cannot use those on ARM
+CONFIG_RTE_KNI_KMOD=n
+CONFIG_RTE_LIBRTE_EM_PMD=n
+CONFIG_RTE_LIBRTE_IGB_PMD=n
+CONFIG_RTE_LIBRTE_CXGBE_PMD=n
+CONFIG_RTE_LIBRTE_E1000_PMD=n
+CONFIG_RTE_LIBRTE_ENIC_PMD=n
+CONFIG_RTE_LIBRTE_FM10K_PMD=n
+CONFIG_RTE_LIBRTE_I40E_PMD=n
+CONFIG_RTE_LIBRTE_IXGBE_PMD=n
+CONFIG_RTE_LIBRTE_MLX4_PMD=n
+CONFIG_RTE_LIBRTE_MPIPE_PMD=n
+CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
+CONFIG_RTE_LIBRTE_VMXNET3_PMD=n
+CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
+CONFIG_RTE_LIBRTE_PMD_BNX2X=n
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index be6f827..43a3a3c 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -23,6 +23,11 @@ New Features
* **Added vhost-user multiple queue support.**
+* **Introduce ARMv7 architecture**
+
+ It is now possible to build DPDK for the ARMv7 platform and test with
+ virtual PMD drivers.
+
Resolved Issues
---------------
diff --git a/mk/arch/arm/rte.vars.mk b/mk/arch/arm/rte.vars.mk
new file mode 100644
index 0000000..df0c043
--- /dev/null
+++ b/mk/arch/arm/rte.vars.mk
@@ -0,0 +1,39 @@
+# BSD LICENSE
+#
+# Copyright (C) 2015 RehiveTech. 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 RehiveTech nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+ARCH ?= arm
+CROSS ?=
+
+CPU_CFLAGS ?= -marm -DRTE_CACHE_LINE_SIZE=64 -munaligned-access
+CPU_LDFLAGS ?=
+CPU_ASFLAGS ?= -felf
+
+export ARCH CROSS CPU_CFLAGS CPU_LDFLAGS CPU_ASFLAGS
diff --git a/mk/machine/armv7-a/rte.vars.mk b/mk/machine/armv7-a/rte.vars.mk
new file mode 100644
index 0000000..48d3979
--- /dev/null
+++ b/mk/machine/armv7-a/rte.vars.mk
@@ -0,0 +1,67 @@
+# BSD LICENSE
+#
+# Copyright (C) 2015 RehiveTech. 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 RehiveTech nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+#
+# machine:
+#
+# - can define ARCH variable (overridden by cmdline value)
+# - can define CROSS variable (overridden by cmdline value)
+# - define MACHINE_CFLAGS variable (overridden by cmdline value)
+# - define MACHINE_LDFLAGS variable (overridden by cmdline value)
+# - define MACHINE_ASFLAGS variable (overridden by cmdline value)
+# - can define CPU_CFLAGS variable (overridden by cmdline value) that
+# overrides the one defined in arch.
+# - can define CPU_LDFLAGS variable (overridden by cmdline value) that
+# overrides the one defined in arch.
+# - can define CPU_ASFLAGS variable (overridden by cmdline value) that
+# overrides the one defined in arch.
+# - may override any previously defined variable
+#
+
+# ARCH =
+# CROSS =
+# MACHINE_CFLAGS =
+# MACHINE_LDFLAGS =
+# MACHINE_ASFLAGS =
+# CPU_CFLAGS =
+# CPU_LDFLAGS =
+# CPU_ASFLAGS =
+
+CPU_CFLAGS += -mfloat-abi=softfp
+
+MACHINE_CFLAGS += -march=armv7-a
+
+ifdef CONFIG_RTE_ARCH_ARM_TUNE
+MACHINE_CFLAGS += -mtune=$(CONFIG_RTE_ARCH_ARM_TUNE)
+endif
+
+ifeq ($(CONFIG_RTE_ARCH_ARM_NEON),y)
+MACHINE_CFLAGS += -mfpu=neon
+endif
--
2.6.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 1/3] i40e: RSS/FD granularity configuration
@ 2015-10-30 1:58 4% ` Zhang, Helin
0 siblings, 0 replies; 200+ results
From: Zhang, Helin @ 2015-10-30 1:58 UTC (permalink / raw)
To: Richardson, Bruce; +Cc: dev
> -----Original Message-----
> From: Richardson, Bruce
> Sent: Thursday, October 29, 2015 5:39 PM
> To: Zhang, Helin
> Cc: dev@dpdk.org; Pei, Yulong
> Subject: Re: [dpdk-dev] [PATCH v6 1/3] i40e: RSS/FD granularity configuration
>
> On Thu, Oct 29, 2015 at 02:02:50PM +0800, Helin Zhang wrote:
> > The default input set of fields of a received packet are loaded from
> > firmware, which cannot be modified even users want to use different
> > fields for RSS or flow director. Here adds more flexibilities of
> > selecting packet fields for hash calculation or flow director for
> > users.
> >
> > Signed-off-by: Helin Zhang <helin.zhang@intel.com>
> > Signed-off-by: Andrey Chilikin <andrey.chilikin@intel.com>
> > ---
> > drivers/net/i40e/i40e_ethdev.c | 742
> ++++++++++++++++++++++++++++++++++++++++
> > drivers/net/i40e/i40e_ethdev.h | 7 +
> > drivers/net/i40e/i40e_fdir.c | 31 ++
> > lib/librte_ether/rte_eth_ctrl.h | 114 +++++-
> > 4 files changed, 890 insertions(+), 4 deletions(-)
> >
> <snip>
> > @@ -672,6 +776,8 @@ struct rte_eth_hash_filter_info {
> > uint8_t enable;
> > /** Global configurations of hash filter */
> > struct rte_eth_hash_global_conf global_conf;
> > + /** Global configurations of hash filter input set */
> > + struct rte_eth_input_set_conf input_set_conf;
> > } info;
> > };
> >
> Hi Helin,
>
> Just to check: Does this change affect the size of the structure and cause ABI
> issues?
Bruce, you are right, there should be ABI issue with the structure size. Thank you very much!
I will change the size of ' struct rte_eth_input_set_conf ' to smaller one, and then no ABI issue this time.
But I will announce ABI change to support configuring more than one input sets, and then make the change next time.
/Helin
>
> /Bruce
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v7 0/2] i40e: RSS/FD granularity configuration
@ 2015-10-30 3:11 3% ` Helin Zhang
2015-10-30 3:11 4% ` [dpdk-dev] [PATCH v7 1/2] " Helin Zhang
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Helin Zhang @ 2015-10-30 3:11 UTC (permalink / raw)
To: dev
v2 changes:
Solved the compilation issues.
v3 changes:
Support selecting more input set fields.
v4 changes:
Removed operation of 'delete', as it is not necessary.
Added FD granularity in both pmd and testpmd, as it is similar to RSS granularity.
v5 changes:
Fixed issue of generating wrong input set for registers on ipv6-udp and ipv6-tcp pc types.
Added clear masking operations during checking if MASK registers are opcupied or not.
Reworked several annotations.
v6 changes:
Updated documentation.
v7 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
Split documentation into pieces and put them directly into the patch of code changes directly.
Helin Zhang (2):
i40e: RSS/FD granularity configuration
app/testpmd: add test commands for RSS/FD granularity
app/test-pmd/cmdline.c | 218 ++++++++
doc/guides/rel_notes/deprecation.rst | 5 +
doc/guides/rel_notes/release_2_2.rst | 3 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 33 ++
drivers/net/i40e/i40e_ethdev.c | 742 ++++++++++++++++++++++++++++
drivers/net/i40e/i40e_ethdev.h | 7 +
drivers/net/i40e/i40e_fdir.c | 31 ++
lib/librte_ether/rte_eth_ctrl.h | 114 ++++-
8 files changed, 1149 insertions(+), 4 deletions(-)
--
1.9.3
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v7 1/2] i40e: RSS/FD granularity configuration
2015-10-30 3:11 3% ` [dpdk-dev] [PATCH v7 0/2] " Helin Zhang
@ 2015-10-30 3:11 4% ` Helin Zhang
2015-10-30 13:46 4% ` Thomas Monjalon
2015-10-30 7:59 0% ` [dpdk-dev] [PATCH v7 0/2] " Wu, Jingjing
2015-11-02 14:32 4% ` [dpdk-dev] [PATCH v8 " Helin Zhang
2 siblings, 1 reply; 200+ results
From: Helin Zhang @ 2015-10-30 3:11 UTC (permalink / raw)
To: dev
The default input set of fields of a received packet are loaded from
firmware, which cannot be modified even users want to use different
fields for RSS or flow director. Here adds more flexibilities of
selecting packet fields for hash calculation or flow director for
users.
Signed-off-by: Helin Zhang <helin.zhang@intel.com>
Signed-off-by: Andrey Chilikin <andrey.chilikin@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 5 +
doc/guides/rel_notes/release_2_2.rst | 3 +
drivers/net/i40e/i40e_ethdev.c | 742 +++++++++++++++++++++++++++++++++++
drivers/net/i40e/i40e_ethdev.h | 7 +
drivers/net/i40e/i40e_fdir.c | 31 ++
lib/librte_ether/rte_eth_ctrl.h | 114 +++++-
6 files changed, 898 insertions(+), 4 deletions(-)
v2 changes:
Solved the compilation issues.
v3 changes:
Support selecting more input set fields.
v4 changes:
Removed operation of 'delete', as it is not necessary.
Added FD granularity, as it is similar to RSS granularity.
v5 changes:
Fixed issue of generating wrong input set for registers on ipv6-udp and ipv6-tcp pc types.
Added clear masking operations during checking if MASK registers are opcupied or not.
Reworked several annotations.
v7 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
Moved documentation as part of this patch.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index a391ff0..856cb0f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -52,3 +52,8 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
+
+* ABI changes are planned in release 2.3 for macro of RTE_ETH_INSET_SIZE_MAX,
+ struct rte_eth_input_set_conf, to support selecting more than one input set
+ items, and which will affect struct rte_eth_fdir_filter_info and
+ struct rte_eth_hash_filter_info.
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 89e4d58..2a54ce6 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -31,6 +31,9 @@ New Features
* **Added vhost-user multiple queue support.**
+* **Added RSS/FD input set granularity on Intel X710/XL710.**
+
+
Resolved Issues
---------------
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 478e94d..fb262a5 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -113,6 +113,142 @@
#define I40E_PRTTSYN_TSYNENA 0x80000000
#define I40E_PRTTSYN_TSYNTYPE 0x0e000000
+#define I40E_PRTQF_FD_INSET(_i, _j) (0x00250000 + ((_i) * 64 + (_j) * 32))
+#define I40E_GLQF_FD_MSK(_i, _j) (0x00267200 + ((_i) * 4 + (_j) * 8))
+#define I40E_GLQF_FD_MSK_FIELD 0x0000FFFF
+#define I40E_GLQF_HASH_INSET(_i, _j) (0x00267600 + ((_i) * 4 + (_j) * 8))
+#define I40E_GLQF_HASH_MSK(_i, _j) (0x00267A00 + ((_i) * 4 + (_j) * 8))
+#define I40E_GLQF_HASH_MSK_FIELD 0x0000FFFF
+
+#define I40E_INSET_NONE 0x00000000000000000ULL
+
+/* bit0 ~ bit 7 */
+#define I40E_INSET_DMAC 0x0000000000000001ULL
+#define I40E_INSET_SMAC 0x0000000000000002ULL
+#define I40E_INSET_VLAN_OUTER 0x0000000000000004ULL
+#define I40E_INSET_VLAN_INNER 0x0000000000000008ULL
+#define I40E_INSET_VLAN_TUNNEL 0x0000000000000010ULL
+
+/* bit 8 ~ bit 15 */
+#define I40E_INSET_IPV4_SRC 0x0000000000000100ULL
+#define I40E_INSET_IPV4_DST 0x0000000000000200ULL
+#define I40E_INSET_IPV6_SRC 0x0000000000000400ULL
+#define I40E_INSET_IPV6_DST 0x0000000000000800ULL
+#define I40E_INSET_SRC_PORT 0x0000000000001000ULL
+#define I40E_INSET_DST_PORT 0x0000000000002000ULL
+#define I40E_INSET_SCTP_VT 0x0000000000004000ULL
+
+/* bit 16 ~ bit 31 */
+#define I40E_INSET_IPV4_TOS 0x0000000000010000ULL
+#define I40E_INSET_IPV4_PROTO 0x0000000000020000ULL
+#define I40E_INSET_IPV4_TTL 0x0000000000040000ULL
+#define I40E_INSET_IPV6_TC 0x0000000000080000ULL
+#define I40E_INSET_IPV6_FLOW 0x0000000000100000ULL
+#define I40E_INSET_IPV6_NEXT_HDR 0x0000000000200000ULL
+#define I40E_INSET_IPV6_HOP_LIMIT 0x0000000000400000ULL
+#define I40E_INSET_TCP_FLAGS 0x0000000000800000ULL
+
+/* bit 32 ~ bit 47, tunnel fields */
+#define I40E_INSET_TUNNEL_IPV4_DST 0x0000000100000000ULL
+#define I40E_INSET_TUNNEL_IPV6_DST 0x0000000200000000ULL
+#define I40E_INSET_TUNNEL_DMAC 0x0000000400000000ULL
+#define I40E_INSET_TUNNEL_SRC_PORT 0x0000000800000000ULL
+#define I40E_INSET_TUNNEL_DST_PORT 0x0000001000000000ULL
+#define I40E_INSET_TUNNEL_ID 0x0000002000000000ULL
+
+/* bit 48 ~ bit 55 */
+#define I40E_INSET_LAST_ETHER_TYPE 0x0001000000000000ULL
+
+/* bit 56 ~ bit 63, Flex Payload */
+#define I40E_INSET_FLEX_PAYLOAD_W1 0x0100000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W2 0x0200000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W3 0x0400000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W4 0x0800000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W5 0x1000000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W6 0x2000000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W7 0x4000000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W8 0x8000000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD \
+ (I40E_INSET_FLEX_PAYLOAD_W1 | I40E_INSET_FLEX_PAYLOAD_W2 | \
+ I40E_INSET_FLEX_PAYLOAD_W3 | I40E_INSET_FLEX_PAYLOAD_W3 | \
+ I40E_INSET_FLEX_PAYLOAD_W5 | I40E_INSET_FLEX_PAYLOAD_W6 | \
+ I40E_INSET_FLEX_PAYLOAD_W7 | I40E_INSET_FLEX_PAYLOAD_W8)
+
+/**
+ * Below are values for writing un-exposed registers suggested
+ * by silicon experts
+ */
+/* Destination MAC address */
+#define I40E_REG_INSET_L2_DMAC 0xE000000000000000ULL
+/* Source MAC address */
+#define I40E_REG_INSET_L2_SMAC 0x1C00000000000000ULL
+/* VLAN tag in the outer L2 header */
+#define I40E_REG_INSET_L2_OUTER_VLAN 0x0000000000800000ULL
+/* VLAN tag in the inner L2 header */
+#define I40E_REG_INSET_L2_INNER_VLAN 0x0000000001000000ULL
+/* Source IPv4 address */
+#define I40E_REG_INSET_L3_SRC_IP4 0x0001800000000000ULL
+/* Destination IPv4 address */
+#define I40E_REG_INSET_L3_DST_IP4 0x0000001800000000ULL
+/* IPv4 Type of Service (TOS) */
+#define I40E_REG_INSET_L3_IP4_TOS 0x0040000000000000ULL
+/* IPv4 Protocol */
+#define I40E_REG_INSET_L3_IP4_PROTO 0x0004000000000000ULL
+/* Source IPv6 address */
+#define I40E_REG_INSET_L3_SRC_IP6 0x0007F80000000000ULL
+/* Destination IPv6 address */
+#define I40E_REG_INSET_L3_DST_IP6 0x000007F800000000ULL
+/* IPv6 Traffic Class (TC) */
+#define I40E_REG_INSET_L3_IP6_TC 0x0040000000000000ULL
+/* IPv6 Next Header */
+#define I40E_REG_INSET_L3_IP6_NEXT_HDR 0x0008000000000000ULL
+/* Source L4 port */
+#define I40E_REG_INSET_L4_SRC_PORT 0x0000000400000000ULL
+/* Destination L4 port */
+#define I40E_REG_INSET_L4_DST_PORT 0x0000000200000000ULL
+/* SCTP verification tag */
+#define I40E_REG_INSET_L4_SCTP_VERIFICATION_TAG 0x0000000180000000ULL
+/* Inner destination MAC address (MAC-in-UDP/MAC-in-GRE)*/
+#define I40E_REG_INSET_TUNNEL_L2_INNER_DST_MAC 0x0000000001C00000ULL
+/* Source port of tunneling UDP */
+#define I40E_REG_INSET_TUNNEL_L4_UDP_SRC_PORT 0x0000000000200000ULL
+/* Destination port of tunneling UDP */
+#define I40E_REG_INSET_TUNNEL_L4_UDP_DST_PORT 0x0000000000100000ULL
+/* UDP Tunneling ID, NVGRE/GRE key */
+#define I40E_REG_INSET_TUNNEL_ID 0x00000000000C0000ULL
+/* Last ether type */
+#define I40E_REG_INSET_LAST_ETHER_TYPE 0x0000000000004000ULL
+/* Tunneling outer destination IPv4 address */
+#define I40E_REG_INSET_TUNNEL_L3_DST_IP4 0x00000000000000C0ULL
+/* Tunneling outer destination IPv6 address */
+#define I40E_REG_INSET_TUNNEL_L3_DST_IP6 0x0000000000003FC0ULL
+/* 1st word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD1 0x0000000000002000ULL
+/* 2nd word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD2 0x0000000000001000ULL
+/* 3rd word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD3 0x0000000000000800ULL
+/* 4th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD4 0x0000000000000400ULL
+/* 5th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD5 0x0000000000000200ULL
+/* 6th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD6 0x0000000000000100ULL
+/* 7th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD7 0x0000000000000080ULL
+/* 8th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD8 0x0000000000000040ULL
+
+#define I40E_REG_INSET_MASK_DEFAULT 0x0000000000000000ULL
+
+#define I40E_TRANSLATE_INSET 0
+#define I40E_TRANSLATE_REG 1
+
+#define I40E_INSET_IPV4_TOS_MASK 0x0009FF00UL
+#define I40E_INSET_IPV4_PROTO_MASK 0x000DFF00UL
+#define I40E_INSET_IPV6_TC_MASK 0x0009F00FUL
+#define I40E_INSET_IPV6_NEXT_HDR_MASK 0x000C00FFUL
+
static int eth_i40e_dev_init(struct rte_eth_dev *eth_dev);
static int eth_i40e_dev_uninit(struct rte_eth_dev *eth_dev);
static int i40e_dev_configure(struct rte_eth_dev *dev);
@@ -5455,6 +5591,606 @@ out:
return 0;
}
+/**
+ * Valid input sets for hash and flow director filters per PCTYPE
+ */
+static uint64_t
+i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
+ enum rte_filter_type filter)
+{
+ uint64_t valid;
+
+ static const uint64_t valid_hash_inset_table[] = {
+ [I40E_FILTER_PCTYPE_FRAG_IPV4] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_SRC |
+ I40E_INSET_IPV4_DST | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_TCP_FLAGS | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_FRAG_IPV6] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_TUNNEL_DMAC |
+ I40E_INSET_TUNNEL_ID | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
+ I40E_INSET_DST_PORT | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
+ I40E_INSET_DST_PORT | I40E_INSET_TCP_FLAGS |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
+ I40E_INSET_DST_PORT | I40E_INSET_SCTP_VT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_L2_PAYLOAD] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_LAST_ETHER_TYPE |
+ I40E_INSET_FLEX_PAYLOAD,
+ };
+
+ /**
+ * Flow director supports only fields defined in
+ * union rte_eth_fdir_flow.
+ */
+ static const uint64_t valid_fdir_inset_table[] = {
+ [I40E_FILTER_PCTYPE_FRAG_IPV4] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_FRAG_IPV6] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_L2_PAYLOAD] =
+ I40E_INSET_LAST_ETHER_TYPE | I40E_INSET_FLEX_PAYLOAD,
+ };
+
+ if (pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD)
+ return 0;
+ if (filter == RTE_ETH_FILTER_HASH)
+ valid = valid_hash_inset_table[pctype];
+ else
+ valid = valid_fdir_inset_table[pctype];
+
+ return valid;
+}
+
+/**
+ * Validate if the input set is allowed for a specific PCTYPE
+ */
+static int
+i40e_validate_input_set(enum i40e_filter_pctype pctype,
+ enum rte_filter_type filter, uint64_t inset)
+{
+ uint64_t valid;
+
+ valid = i40e_get_valid_input_set(pctype, filter);
+ if (inset & (~valid))
+ return -EINVAL;
+
+ return 0;
+}
+
+/* default input set fields combination per pctype */
+static uint64_t
+i40e_get_default_input_set(uint16_t pctype)
+{
+ static const uint64_t default_inset_table[] = {
+ [I40E_FILTER_PCTYPE_FRAG_IPV4] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
+ [I40E_FILTER_PCTYPE_FRAG_IPV6] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+ [I40E_FILTER_PCTYPE_L2_PAYLOAD] =
+ I40E_INSET_LAST_ETHER_TYPE,
+ };
+
+ if (pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD)
+ return 0;
+
+ return default_inset_table[pctype];
+}
+
+/**
+ * Parse the input set from index to logical bit masks
+ */
+static int
+i40e_parse_input_set(uint64_t *inset,
+ enum i40e_filter_pctype pctype,
+ enum rte_eth_input_set_field *field,
+ uint16_t size)
+{
+ uint16_t i, j;
+ int ret = -EINVAL;
+
+ static const struct {
+ enum rte_eth_input_set_field field;
+ uint64_t inset;
+ } inset_convert_table[] = {
+ {RTE_ETH_INPUT_SET_NONE, I40E_INSET_NONE},
+ {RTE_ETH_INPUT_SET_L2_SRC_MAC, I40E_INSET_SMAC},
+ {RTE_ETH_INPUT_SET_L2_DST_MAC, I40E_INSET_DMAC},
+ {RTE_ETH_INPUT_SET_L2_OUTER_VLAN, I40E_INSET_VLAN_OUTER},
+ {RTE_ETH_INPUT_SET_L2_INNER_VLAN, I40E_INSET_VLAN_INNER},
+ {RTE_ETH_INPUT_SET_L2_ETHERTYPE, I40E_INSET_LAST_ETHER_TYPE},
+ {RTE_ETH_INPUT_SET_L3_SRC_IP4, I40E_INSET_IPV4_SRC},
+ {RTE_ETH_INPUT_SET_L3_DST_IP4, I40E_INSET_IPV4_DST},
+ {RTE_ETH_INPUT_SET_L3_IP4_TOS, I40E_INSET_IPV4_TOS},
+ {RTE_ETH_INPUT_SET_L3_IP4_PROTO, I40E_INSET_IPV4_PROTO},
+ {RTE_ETH_INPUT_SET_L3_SRC_IP6, I40E_INSET_IPV6_SRC},
+ {RTE_ETH_INPUT_SET_L3_DST_IP6, I40E_INSET_IPV6_DST},
+ {RTE_ETH_INPUT_SET_L3_IP6_TC, I40E_INSET_IPV6_TC},
+ {RTE_ETH_INPUT_SET_L3_IP6_NEXT_HEADER,
+ I40E_INSET_IPV6_NEXT_HDR},
+ {RTE_ETH_INPUT_SET_L4_UDP_SRC_PORT, I40E_INSET_SRC_PORT},
+ {RTE_ETH_INPUT_SET_L4_TCP_SRC_PORT, I40E_INSET_SRC_PORT},
+ {RTE_ETH_INPUT_SET_L4_SCTP_SRC_PORT, I40E_INSET_SRC_PORT},
+ {RTE_ETH_INPUT_SET_L4_UDP_DST_PORT, I40E_INSET_DST_PORT},
+ {RTE_ETH_INPUT_SET_L4_TCP_DST_PORT, I40E_INSET_DST_PORT},
+ {RTE_ETH_INPUT_SET_L4_SCTP_DST_PORT, I40E_INSET_DST_PORT},
+ {RTE_ETH_INPUT_SET_L4_SCTP_VERIFICATION_TAG,
+ I40E_INSET_SCTP_VT},
+ {RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_DST_MAC,
+ I40E_INSET_TUNNEL_DMAC},
+ {RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_VLAN,
+ I40E_INSET_VLAN_TUNNEL},
+ {RTE_ETH_INPUT_SET_TUNNEL_L4_UDP_KEY,
+ I40E_INSET_TUNNEL_ID},
+ {RTE_ETH_INPUT_SET_TUNNEL_GRE_KEY, I40E_INSET_TUNNEL_ID},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_1ST_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W1},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_2ND_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W2},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_3RD_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W3},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_4TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W4},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_5TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W5},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_6TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W6},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_7TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W7},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_8TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W8},
+ };
+
+ if (!inset || !field || size > RTE_ETH_INSET_SIZE_MAX)
+ return ret;
+
+ /* Only one item allowed for default or all */
+ if (size == 1) {
+ if (field[0] == RTE_ETH_INPUT_SET_DEFAULT) {
+ *inset = i40e_get_default_input_set(pctype);
+ return 0;
+ } else if (field[0] == RTE_ETH_INPUT_SET_NONE) {
+ *inset = I40E_INSET_NONE;
+ return 0;
+ }
+ }
+
+ for (i = 0, *inset = 0; i < size; i++) {
+ for (j = 0; j < RTE_DIM(inset_convert_table); j++) {
+ if (field[i] == inset_convert_table[j].field) {
+ *inset |= inset_convert_table[j].inset;
+ break;
+ }
+ }
+
+ /* It contains unsupported input set, return 0 immediately */
+ if (j == RTE_DIM(inset_convert_table))
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * Translate the input set from bit masks to register aware bit masks
+ * and vice versa
+ */
+static uint64_t
+i40e_translate_input_set_reg(uint64_t input)
+{
+ uint64_t val = 0;
+ uint16_t i;
+
+ static const struct {
+ uint64_t inset;
+ uint64_t inset_reg;
+ } inset_map[] = {
+ {I40E_INSET_DMAC, I40E_REG_INSET_L2_DMAC},
+ {I40E_INSET_SMAC, I40E_REG_INSET_L2_SMAC},
+ {I40E_INSET_VLAN_OUTER, I40E_REG_INSET_L2_OUTER_VLAN},
+ {I40E_INSET_VLAN_INNER, I40E_REG_INSET_L2_INNER_VLAN},
+ {I40E_INSET_LAST_ETHER_TYPE, I40E_REG_INSET_LAST_ETHER_TYPE},
+ {I40E_INSET_IPV4_SRC, I40E_REG_INSET_L3_SRC_IP4},
+ {I40E_INSET_IPV4_DST, I40E_REG_INSET_L3_DST_IP4},
+ {I40E_INSET_IPV4_TOS, I40E_REG_INSET_L3_IP4_TOS},
+ {I40E_INSET_IPV4_PROTO, I40E_REG_INSET_L3_IP4_PROTO},
+ {I40E_INSET_IPV6_SRC, I40E_REG_INSET_L3_SRC_IP6},
+ {I40E_INSET_IPV6_DST, I40E_REG_INSET_L3_DST_IP6},
+ {I40E_INSET_IPV6_TC, I40E_REG_INSET_L3_IP6_TC},
+ {I40E_INSET_IPV6_NEXT_HDR, I40E_REG_INSET_L3_IP6_NEXT_HDR},
+ {I40E_INSET_SRC_PORT, I40E_REG_INSET_L4_SRC_PORT},
+ {I40E_INSET_DST_PORT, I40E_REG_INSET_L4_DST_PORT},
+ {I40E_INSET_SCTP_VT, I40E_REG_INSET_L4_SCTP_VERIFICATION_TAG},
+ {I40E_INSET_TUNNEL_ID, I40E_REG_INSET_TUNNEL_ID},
+ {I40E_INSET_TUNNEL_DMAC,
+ I40E_REG_INSET_TUNNEL_L2_INNER_DST_MAC},
+ {I40E_INSET_TUNNEL_IPV4_DST, I40E_REG_INSET_TUNNEL_L3_DST_IP4},
+ {I40E_INSET_TUNNEL_IPV6_DST, I40E_REG_INSET_TUNNEL_L3_DST_IP6},
+ {I40E_INSET_TUNNEL_SRC_PORT,
+ I40E_REG_INSET_TUNNEL_L4_UDP_SRC_PORT},
+ {I40E_INSET_TUNNEL_DST_PORT,
+ I40E_REG_INSET_TUNNEL_L4_UDP_DST_PORT},
+ {I40E_INSET_TUNNEL_ID, I40E_REG_INSET_TUNNEL_ID},
+ {I40E_INSET_FLEX_PAYLOAD_W1, I40E_REG_INSET_FLEX_PAYLOAD_WORD1},
+ {I40E_INSET_FLEX_PAYLOAD_W2, I40E_REG_INSET_FLEX_PAYLOAD_WORD2},
+ {I40E_INSET_FLEX_PAYLOAD_W3, I40E_REG_INSET_FLEX_PAYLOAD_WORD3},
+ {I40E_INSET_FLEX_PAYLOAD_W4, I40E_REG_INSET_FLEX_PAYLOAD_WORD4},
+ {I40E_INSET_FLEX_PAYLOAD_W5, I40E_REG_INSET_FLEX_PAYLOAD_WORD5},
+ {I40E_INSET_FLEX_PAYLOAD_W6, I40E_REG_INSET_FLEX_PAYLOAD_WORD6},
+ {I40E_INSET_FLEX_PAYLOAD_W7, I40E_REG_INSET_FLEX_PAYLOAD_WORD7},
+ {I40E_INSET_FLEX_PAYLOAD_W8, I40E_REG_INSET_FLEX_PAYLOAD_WORD8},
+ };
+
+ if (input == 0)
+ return val;
+
+ /* Translate input set to register aware inset */
+ for (i = 0; i < RTE_DIM(inset_map); i++) {
+ if (input & inset_map[i].inset)
+ val |= inset_map[i].inset_reg;
+ }
+
+ return val;
+}
+
+static uint8_t
+i40e_generate_inset_mask_reg(uint64_t inset, uint32_t *mask, uint8_t nb_elem)
+{
+ uint8_t i, idx = 0;
+
+ static const struct {
+ uint64_t inset;
+ uint32_t mask;
+ } inset_mask_map[] = {
+ {I40E_INSET_IPV4_TOS, I40E_INSET_IPV4_TOS_MASK},
+ {I40E_INSET_IPV4_PROTO, I40E_INSET_IPV4_PROTO_MASK},
+ {I40E_INSET_IPV6_TC, I40E_INSET_IPV6_TC_MASK},
+ {I40E_INSET_IPV6_NEXT_HDR, I40E_INSET_IPV6_NEXT_HDR_MASK},
+ };
+
+ if (!inset || !mask || !nb_elem)
+ return 0;
+
+ if (!inset && nb_elem >= I40E_INSET_MASK_NUM_REG) {
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++)
+ mask[i] = 0;
+ return I40E_INSET_MASK_NUM_REG;
+ }
+
+ for (i = 0, idx = 0; i < RTE_DIM(inset_mask_map); i++) {
+ if (idx >= nb_elem)
+ break;
+ if (inset & inset_mask_map[i].inset) {
+ mask[idx] = inset_mask_map[i].mask;
+ idx++;
+ }
+ }
+
+ return idx;
+}
+
+static uint64_t
+i40e_get_reg_inset(struct i40e_hw *hw, enum rte_filter_type filter,
+ enum i40e_filter_pctype pctype)
+{
+ uint64_t reg = 0;
+
+ if (filter == RTE_ETH_FILTER_HASH) {
+ reg = I40E_READ_REG(hw, I40E_GLQF_HASH_INSET(1, pctype));
+ reg <<= I40E_32_BIT_WIDTH;
+ reg |= I40E_READ_REG(hw, I40E_GLQF_HASH_INSET(0, pctype));
+ } else if (filter == RTE_ETH_FILTER_FDIR) {
+ reg = I40E_READ_REG(hw, I40E_PRTQF_FD_INSET(pctype, 1));
+ reg <<= I40E_32_BIT_WIDTH;
+ reg |= I40E_READ_REG(hw, I40E_PRTQF_FD_INSET(pctype, 0));
+ }
+
+ return reg;
+}
+
+static void
+i40e_check_write_reg(struct i40e_hw *hw, uint32_t addr, uint32_t val)
+{
+ uint32_t reg = I40E_READ_REG(hw, addr);
+
+ PMD_DRV_LOG(DEBUG, "[0x%08x] original: 0x%08x\n", addr, reg);
+ if (reg != val)
+ I40E_WRITE_REG(hw, addr, val);
+ PMD_DRV_LOG(DEBUG, "[0x%08x] after: 0x%08x\n", addr,
+ (uint32_t)I40E_READ_REG(hw, addr));
+}
+
+static int
+i40e_set_hash_inset_mask(struct i40e_hw *hw,
+ enum i40e_filter_pctype pctype,
+ enum rte_filter_input_set_op op,
+ uint32_t *mask_reg,
+ uint8_t num)
+{
+ uint32_t reg;
+ uint8_t i;
+
+ if (!mask_reg || num > RTE_ETH_INPUT_SET_SELECT)
+ return -EINVAL;
+
+ if (op == RTE_ETH_INPUT_SET_SELECT) {
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+ 0);
+ if (i >= num)
+ continue;
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+ mask_reg[i]);
+ }
+ } else if (op == RTE_ETH_INPUT_SET_ADD) {
+ uint8_t j, count = 0;
+
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
+ reg = I40E_READ_REG(hw, I40E_GLQF_HASH_MSK(i, pctype));
+ if (reg & I40E_GLQF_HASH_MSK_FIELD)
+ count++;
+ }
+ if (count + num > I40E_INSET_MASK_NUM_REG)
+ return -EINVAL;
+
+ for (i = count, j = 0; i < I40E_INSET_MASK_NUM_REG; i++, j++)
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+ mask_reg[j]);
+ }
+
+ return 0;
+}
+
+static int
+i40e_set_fd_inset_mask(struct i40e_hw *hw,
+ enum i40e_filter_pctype pctype,
+ enum rte_filter_input_set_op op,
+ uint32_t *mask_reg,
+ uint8_t num)
+{
+ uint32_t reg;
+ uint8_t i;
+
+ if (!mask_reg || num > RTE_ETH_INPUT_SET_SELECT)
+ return -EINVAL;
+
+ if (op == RTE_ETH_INPUT_SET_SELECT) {
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
+ i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+ 0);
+ if (i >= num)
+ continue;
+ i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+ mask_reg[i]);
+ }
+ } else if (op == RTE_ETH_INPUT_SET_ADD) {
+ uint8_t j, count = 0;
+
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
+ reg = I40E_READ_REG(hw, I40E_GLQF_FD_MSK(i, pctype));
+ if (reg & I40E_GLQF_FD_MSK_FIELD)
+ count++;
+ }
+ if (count + num > I40E_INSET_MASK_NUM_REG)
+ return -EINVAL;
+
+ for (i = count, j = 0; i < I40E_INSET_MASK_NUM_REG; i++, j++)
+ i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+ mask_reg[j]);
+ }
+
+ return 0;
+}
+
+int
+i40e_filter_inset_select(struct i40e_hw *hw,
+ struct rte_eth_input_set_conf *conf,
+ enum rte_filter_type filter)
+{
+ enum i40e_filter_pctype pctype;
+ uint64_t inset_reg = 0, input_set;
+ uint32_t mask_reg[I40E_INSET_MASK_NUM_REG];
+ uint8_t num;
+ int ret;
+
+ if (!hw || !conf) {
+ PMD_DRV_LOG(ERR, "Invalid pointer");
+ return -EFAULT;
+ }
+
+ pctype = i40e_flowtype_to_pctype(conf->flow_type);
+ if (pctype == 0 || pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD) {
+ PMD_DRV_LOG(ERR, "Not supported flow type (%u)",
+ conf->flow_type);
+ return -EINVAL;
+ }
+ if (filter != RTE_ETH_FILTER_HASH && filter != RTE_ETH_FILTER_FDIR) {
+ PMD_DRV_LOG(ERR, "Not supported filter type (%u)", filter);
+ return -EINVAL;
+ }
+
+ ret = i40e_parse_input_set(&input_set, pctype, conf->field,
+ conf->inset_size);
+ if (ret) {
+ PMD_DRV_LOG(ERR, "Failed to parse input set");
+ return -EINVAL;
+ }
+ if (i40e_validate_input_set(pctype, filter, input_set) != 0) {
+ PMD_DRV_LOG(ERR, "Invalid input set");
+ return -EINVAL;
+ }
+
+ if (conf->op == RTE_ETH_INPUT_SET_ADD) {
+ inset_reg |= i40e_get_reg_inset(hw, filter, pctype);
+ } else if (conf->op != RTE_ETH_INPUT_SET_SELECT) {
+ PMD_DRV_LOG(ERR, "Unsupported input set operation");
+ return -EINVAL;
+ }
+ num = i40e_generate_inset_mask_reg(input_set, mask_reg,
+ I40E_INSET_MASK_NUM_REG);
+ inset_reg |= i40e_translate_input_set_reg(input_set);
+
+ if (filter == RTE_ETH_FILTER_HASH) {
+ ret = i40e_set_hash_inset_mask(hw, pctype, conf->op, mask_reg,
+ num);
+ if (ret)
+ return -EINVAL;
+
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_INSET(0, pctype),
+ (uint32_t)(inset_reg & UINT32_MAX));
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_INSET(1, pctype),
+ (uint32_t)((inset_reg >>
+ I40E_32_BIT_WIDTH) & UINT32_MAX));
+ } else if (filter == RTE_ETH_FILTER_FDIR) {
+ ret = i40e_set_fd_inset_mask(hw, pctype, conf->op, mask_reg,
+ num);
+ if (ret)
+ return -EINVAL;
+
+ i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 0),
+ (uint32_t)(inset_reg & UINT32_MAX));
+ i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 1),
+ (uint32_t)((inset_reg >>
+ I40E_32_BIT_WIDTH) & UINT32_MAX));
+ } else {
+ PMD_DRV_LOG(ERR, "Not supported filter type (%u)", filter);
+ return -EINVAL;
+ }
+ I40E_WRITE_FLUSH(hw);
+
+ return 0;
+}
+
static int
i40e_hash_filter_get(struct i40e_hw *hw, struct rte_eth_hash_filter_info *info)
{
@@ -5502,6 +6238,12 @@ i40e_hash_filter_set(struct i40e_hw *hw, struct rte_eth_hash_filter_info *info)
ret = i40e_set_hash_filter_global_config(hw,
&(info->info.global_conf));
break;
+ case RTE_ETH_HASH_FILTER_INPUT_SET_SELECT:
+ ret = i40e_filter_inset_select(hw,
+ &(info->info.input_set_conf),
+ RTE_ETH_FILTER_HASH);
+ break;
+
default:
PMD_DRV_LOG(ERR, "Hash filter info type (%d) not supported",
info->info_type);
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 6185657..32e968c 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -102,6 +102,7 @@ enum i40e_flxpld_layer_idx {
#define I40E_FDIR_BITMASK_NUM_WORD 2 /* max number of bitmask words */
#define I40E_FDIR_MAX_FLEXWORD_NUM 8 /* max number of flexpayload words */
#define I40E_FDIR_MAX_FLEX_LEN 16 /* len in bytes of flex payload */
+#define I40E_INSET_MASK_NUM_REG 2 /* number of input set mask registers */
/* i40e flags */
#define I40E_FLAG_RSS (1ULL << 0)
@@ -501,6 +502,12 @@ uint16_t i40e_pctype_to_flowtype(enum i40e_filter_pctype pctype);
int i40e_fdir_ctrl_func(struct rte_eth_dev *dev,
enum rte_filter_op filter_op,
void *arg);
+int i40e_select_filter_input_set(struct i40e_hw *hw,
+ struct rte_eth_input_set_conf *conf,
+ enum rte_filter_type filter);
+int i40e_filter_inset_select(struct i40e_hw *hw,
+ struct rte_eth_input_set_conf *conf,
+ enum rte_filter_type filter);
/* I40E_DEV_PRIVATE_TO */
#define I40E_DEV_PRIVATE_TO_PF(adapter) \
diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c
index c9ce98f..ba18c9d 100644
--- a/drivers/net/i40e/i40e_fdir.c
+++ b/drivers/net/i40e/i40e_fdir.c
@@ -1342,6 +1342,33 @@ i40e_fdir_stats_get(struct rte_eth_dev *dev, struct rte_eth_fdir_stats *stat)
I40E_PFQF_FDSTAT_BEST_CNT_SHIFT);
}
+static int
+i40e_fdir_filter_set(struct rte_eth_dev *dev,
+ struct rte_eth_hash_filter_info *info)
+{
+ struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+ struct i40e_hw *hw = I40E_PF_TO_HW(pf);
+ int ret = 0;
+
+ if (!info) {
+ PMD_DRV_LOG(ERR, "Invalid pointer");
+ return -EFAULT;
+ }
+
+ switch (info->info_type) {
+ case RTE_ETH_FDIR_FILTER_INPUT_SET_SELECT:
+ ret = i40e_filter_inset_select(hw,
+ &(info->info.input_set_conf), RTE_ETH_FILTER_FDIR);
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "FD filter info type (%d) not supported",
+ info->info_type);
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
/*
* i40e_fdir_ctrl_func - deal with all operations on flow director.
* @pf: board private structure
@@ -1382,6 +1409,10 @@ i40e_fdir_ctrl_func(struct rte_eth_dev *dev,
case RTE_ETH_FILTER_INFO:
i40e_fdir_info_get(dev, (struct rte_eth_fdir_info *)arg);
break;
+ case RTE_ETH_FILTER_SET:
+ ret = i40e_fdir_filter_set(dev,
+ (struct rte_eth_hash_filter_info *)arg);
+ break;
case RTE_ETH_FILTER_STATS:
i40e_fdir_stats_get(dev, (struct rte_eth_fdir_stats *)arg);
break;
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 770c76c..3dc10db 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -295,7 +295,84 @@ struct rte_eth_tunnel_filter_conf {
uint16_t queue_id; /** < queue number. */
};
-#define RTE_ETH_FDIR_MAX_FLEXLEN 16 /** < Max length of flexbytes. */
+#define RTE_ETH_FDIR_MAX_FLEXLEN 16 /** < Max length of flexbytes. */
+#define RTE_ETH_INSET_SIZE_MAX 1 /** < Max length of input set. */
+
+/**
+ * Input set fields for Flow Director and Hash filters
+ */
+enum rte_eth_input_set_field {
+ RTE_ETH_INPUT_SET_UNKNOWN = 0,
+
+ /* L2 */
+ RTE_ETH_INPUT_SET_L2_SRC_MAC = 1,
+ RTE_ETH_INPUT_SET_L2_DST_MAC,
+ RTE_ETH_INPUT_SET_L2_OUTER_VLAN,
+ RTE_ETH_INPUT_SET_L2_INNER_VLAN,
+ RTE_ETH_INPUT_SET_L2_ETHERTYPE,
+
+ /* L3 */
+ RTE_ETH_INPUT_SET_L3_SRC_IP4 = 129,
+ RTE_ETH_INPUT_SET_L3_DST_IP4,
+ RTE_ETH_INPUT_SET_L3_SRC_IP6,
+ RTE_ETH_INPUT_SET_L3_DST_IP6,
+ RTE_ETH_INPUT_SET_L3_IP4_TOS,
+ RTE_ETH_INPUT_SET_L3_IP4_PROTO,
+ RTE_ETH_INPUT_SET_L3_IP6_TC,
+ RTE_ETH_INPUT_SET_L3_IP6_NEXT_HEADER,
+
+ /* L4 */
+ RTE_ETH_INPUT_SET_L4_UDP_SRC_PORT = 257,
+ RTE_ETH_INPUT_SET_L4_UDP_DST_PORT,
+ RTE_ETH_INPUT_SET_L4_TCP_SRC_PORT,
+ RTE_ETH_INPUT_SET_L4_TCP_DST_PORT,
+ RTE_ETH_INPUT_SET_L4_SCTP_SRC_PORT,
+ RTE_ETH_INPUT_SET_L4_SCTP_DST_PORT,
+ RTE_ETH_INPUT_SET_L4_SCTP_VERIFICATION_TAG,
+
+ /* Tunnel */
+ RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_DST_MAC = 385,
+ RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_SRC_MAC,
+ RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_VLAN,
+ RTE_ETH_INPUT_SET_TUNNEL_L4_UDP_KEY,
+ RTE_ETH_INPUT_SET_TUNNEL_GRE_KEY,
+
+ /* Flexible Payload */
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_1ST_WORD = 641,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_2ND_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_3RD_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_4TH_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_5TH_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_6TH_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_7TH_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_8TH_WORD,
+
+ RTE_ETH_INPUT_SET_DEFAULT = 65533,
+ RTE_ETH_INPUT_SET_NONE = 65534,
+ RTE_ETH_INPUT_SET_MAX = 65535,
+};
+
+/**
+ * Filters input set operations
+ */
+enum rte_filter_input_set_op {
+ RTE_ETH_INPUT_SET_OP_UNKNOWN,
+ RTE_ETH_INPUT_SET_SELECT, /**< select input set */
+ RTE_ETH_INPUT_SET_ADD, /**< add input set entry */
+ RTE_ETH_INPUT_SET_OP_MAX
+};
+
+
+/**
+ * A structure used to define the input set configuration for
+ * flow director and hash filters
+ */
+struct rte_eth_input_set_conf {
+ uint16_t flow_type;
+ uint16_t inset_size;
+ enum rte_eth_input_set_field field[RTE_ETH_INSET_SIZE_MAX];
+ enum rte_filter_input_set_op op;
+};
/**
* A structure used to define the input for L2 flow
@@ -535,7 +612,7 @@ struct rte_eth_fdir_flex_mask {
/**
* A structure used to define all flexible payload related setting
- * include flexpay load and flex mask
+ * include flex payload and flex mask
*/
struct rte_eth_fdir_flex_conf {
uint16_t nb_payloads; /**< The number of following payload cfg */
@@ -615,12 +692,37 @@ struct rte_eth_fdir_stats {
};
/**
+ * Flow Director filter information types.
+ */
+enum rte_eth_fdir_filter_info_type {
+ RTE_ETH_FDIR_FILTER_INFO_TYPE_UNKNOWN = 0,
+ /** Flow Director filter input set configuration */
+ RTE_ETH_FDIR_FILTER_INPUT_SET_SELECT,
+ RTE_ETH_FDIR_FILTER_INFO_TYPE_MAX,
+};
+
+/**
+ * A structure used to set FDIR filter information, to support filter type
+ * of 'RTE_ETH_FILTER_FDIR' RTE_ETH_FDIR_FILTER_INPUT_SET_SELECT operation.
+ */
+struct rte_eth_fdir_filter_info {
+ enum rte_eth_fdir_filter_info_type info_type; /**< Information type */
+ /** Details of fdir filter information */
+ union {
+ /** Flow Director input set configuration per port */
+ struct rte_eth_input_set_conf input_set_conf;
+ } info;
+};
+
+/**
* Hash filter information types.
* - RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT is for getting/setting the
* information/configuration of 'symmetric hash enable' per port.
* - RTE_ETH_HASH_FILTER_GLOBAL_CONFIG is for getting/setting the global
* configurations of hash filters. Those global configurations are valid
* for all ports of the same NIC.
+ * - RTE_ETH_HASH_FILTER_INPUT_SET_SELECT is for setting the global
+ * hash input set fields
*/
enum rte_eth_hash_filter_info_type {
RTE_ETH_HASH_FILTER_INFO_TYPE_UNKNOWN = 0,
@@ -628,6 +730,8 @@ enum rte_eth_hash_filter_info_type {
RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT,
/** Configure globally for hash filter */
RTE_ETH_HASH_FILTER_GLOBAL_CONFIG,
+ /** Global Hash filter input set configuration */
+ RTE_ETH_HASH_FILTER_INPUT_SET_SELECT,
RTE_ETH_HASH_FILTER_INFO_TYPE_MAX,
};
@@ -647,7 +751,7 @@ enum rte_eth_hash_function {
* A structure used to set or get global hash function configurations which
* include symmetric hash enable per flow type and hash function type.
* Each bit in sym_hash_enable_mask[] indicates if the symmetric hash of the
- * coresponding flow type is enabled or not.
+ * corresponding flow type is enabled or not.
* Each bit in valid_bit_mask[] indicates if the corresponding bit in
* sym_hash_enable_mask[] is valid or not. For the configurations gotten, it
* also means if the flow type is supported by hardware or not.
@@ -672,6 +776,8 @@ struct rte_eth_hash_filter_info {
uint8_t enable;
/** Global configurations of hash filter */
struct rte_eth_hash_global_conf global_conf;
+ /** Global configurations of hash filter input set */
+ struct rte_eth_input_set_conf input_set_conf;
} info;
};
--
1.9.3
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 0/4] extend flow director to support VF filtering in i40e driver
@ 2015-10-30 7:42 0% ` Zhang, Helin
1 sibling, 0 replies; 200+ results
From: Zhang, Helin @ 2015-10-30 7:42 UTC (permalink / raw)
To: Wu, Jingjing, dev
> -----Original Message-----
> From: Wu, Jingjing
> Sent: Wednesday, October 28, 2015 4:41 PM
> To: dev@dpdk.org
> Cc: Wu, Jingjing; Zhang, Helin; Pei, Yulong
> Subject: [PATCH v2 0/4] extend flow director to support VF filtering in i40e driver
>
> This patch set extends flow director to VF filtering in i40e driver.
>
> v2 change:
> - rework the doc, including release notes and testpmd guide
>
> Jingjing Wu (4):
> ethdev: extend struct to support flow director in VFs
> i40e: extend flow diretcor to support filtering in VFs
> testpmd: extend commands
> doc: extend commands in testpmd and remove related ABI deprecation
>
> app/test-pmd/cmdline.c | 41
> ++++++++++++++++++++++++++---
> doc/guides/rel_notes/deprecation.rst | 4 ---
> doc/guides/rel_notes/release_2_2.rst | 2 ++
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 15 ++++++-----
> drivers/net/i40e/i40e_ethdev.c | 4 +--
> drivers/net/i40e/i40e_fdir.c | 15 ++++++++---
> lib/librte_ether/rte_eth_ctrl.h | 2 ++
> 7 files changed, 64 insertions(+), 19 deletions(-)
>
> --
> 2.4.0
Acked-by: Helin Zhang <helin.zhang@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 0/2] i40e: RSS/FD granularity configuration
2015-10-30 3:11 3% ` [dpdk-dev] [PATCH v7 0/2] " Helin Zhang
2015-10-30 3:11 4% ` [dpdk-dev] [PATCH v7 1/2] " Helin Zhang
@ 2015-10-30 7:59 0% ` Wu, Jingjing
2015-11-02 14:32 4% ` [dpdk-dev] [PATCH v8 " Helin Zhang
2 siblings, 0 replies; 200+ results
From: Wu, Jingjing @ 2015-10-30 7:59 UTC (permalink / raw)
To: Zhang, Helin, dev
> -----Original Message-----
> From: Zhang, Helin
> Sent: Friday, October 30, 2015 11:11 AM
> To: dev@dpdk.org
> Cc: Pei, Yulong; Liu, Yong; Wu, Jingjing; Zhang, Helin
> Subject: [PATCH v7 0/2] i40e: RSS/FD granularity configuration
>
> v2 changes:
> Solved the compilation issues.
>
> v3 changes:
> Support selecting more input set fields.
>
> v4 changes:
> Removed operation of 'delete', as it is not necessary.
> Added FD granularity in both pmd and testpmd, as it is similar to RSS
> granularity.
>
> v5 changes:
> Fixed issue of generating wrong input set for registers on ipv6-udp and ipv6-
> tcp pc types.
> Added clear masking operations during checking if MASK registers are
> opcupied or not.
> Reworked several annotations.
>
> v6 changes:
> Updated documentation.
>
> v7 changes:
> Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
> Split documentation into pieces and put them directly into the patch of code
> changes directly.
>
> Helin Zhang (2):
> i40e: RSS/FD granularity configuration
> app/testpmd: add test commands for RSS/FD granularity
>
> app/test-pmd/cmdline.c | 218 ++++++++
> doc/guides/rel_notes/deprecation.rst | 5 +
> doc/guides/rel_notes/release_2_2.rst | 3 +
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 33 ++
> drivers/net/i40e/i40e_ethdev.c | 742
> ++++++++++++++++++++++++++++
> drivers/net/i40e/i40e_ethdev.h | 7 +
> drivers/net/i40e/i40e_fdir.c | 31 ++
> lib/librte_ether/rte_eth_ctrl.h | 114 ++++-
> 8 files changed, 1149 insertions(+), 4 deletions(-)
>
> --
> 1.9.3
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 1/6] ethdev: add additional ieee1588 support functions
@ 2015-10-30 9:43 4% ` Daniel Mrzyglod
0 siblings, 0 replies; 200+ results
From: Daniel Mrzyglod @ 2015-10-30 9:43 UTC (permalink / raw)
To: dev
Add additional functions to support the existing IEEE1588
functionality.
* rte_eth_timesync_settime(), function to set the device clock time.
* rte_eth_timesync_gettime, function to get the device clock time.
* rte_eth_timesync_adjust, function to adjust the device clock time.
Signed-off-by: Daniel Mrzyglod <danielx.t.mrzyglod@intel.com>
---
doc/guides/rel_notes/release_2_2.rst | 3 ++
lib/librte_ether/rte_ethdev.c | 36 +++++++++++++++++++
lib/librte_ether/rte_ethdev.h | 64 ++++++++++++++++++++++++++++++++++
lib/librte_ether/rte_ether_version.map | 9 +++++
4 files changed, 112 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 89e4d58..b83ef7f 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -123,6 +123,9 @@ API Changes
* The devargs union field virtual is renamed to virt for C++ compatibility.
+* Add new functions in ethdev to support IEEE1588: rte_eth_timesync_time_adjust()
+ rte_eth_timesync_time_get(), rte_eth_timesync_time_set()
+
ABI Changes
-----------
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index f593f6e..d7d2714 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3284,6 +3284,42 @@ rte_eth_timesync_read_tx_timestamp(uint8_t port_id, struct timespec *timestamp)
}
int
+rte_eth_timesync_time_adjust(uint8_t port_id, int64_t delta)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_time_adjust, -ENOTSUP);
+ return (*dev->dev_ops->timesync_time_adjust)(dev, delta);
+}
+
+int
+rte_eth_timesync_time_get(uint8_t port_id, struct timespec *timestamp)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_time_get, -ENOTSUP);
+ return (*dev->dev_ops->timesync_time_get)(dev, timestamp);
+}
+
+int
+rte_eth_timesync_time_set(uint8_t port_id, struct timespec *timestamp)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_time_set, -ENOTSUP);
+ return (*dev->dev_ops->timesync_time_set)(dev, timestamp);
+}
+
+int
rte_eth_dev_get_reg_length(uint8_t port_id)
{
struct rte_eth_dev *dev;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 8a8c82b..c639064 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1129,6 +1129,17 @@ typedef int (*eth_timesync_read_tx_timestamp_t)(struct rte_eth_dev *dev,
struct timespec *timestamp);
/**< @internal Function used to read a TX IEEE1588/802.1AS timestamp. */
+typedef int (*eth_timesync_time_adjust)(struct rte_eth_dev *dev, int64_t);
+/**< @internal Function used to adjust device clock */
+
+typedef int (*eth_timesync_time_get)(struct rte_eth_dev *dev,
+ struct timespec *timestamp);
+/**< @internal Function used to get time from device clock. */
+
+typedef int (*eth_timesync_time_set)(struct rte_eth_dev *dev,
+ struct timespec *timestamp);
+/**< @internal Function used to get time from device clock */
+
typedef int (*eth_get_reg_length_t)(struct rte_eth_dev *dev);
/**< @internal Retrieve device register count */
@@ -1312,6 +1323,12 @@ struct eth_dev_ops {
eth_timesync_read_rx_timestamp_t timesync_read_rx_timestamp;
/** Read the IEEE1588/802.1AS TX timestamp. */
eth_timesync_read_tx_timestamp_t timesync_read_tx_timestamp;
+ /** Adjust the device clock */
+ eth_timesync_time_adjust timesync_time_adjust;
+ /** Get the device clock timespec */
+ eth_timesync_time_get timesync_time_get;
+ /** Set the device clock timespec */
+ eth_timesync_time_set timesync_time_set;
};
/**
@@ -3598,6 +3615,53 @@ extern int rte_eth_timesync_read_rx_timestamp(uint8_t port_id,
extern int rte_eth_timesync_read_tx_timestamp(uint8_t port_id,
struct timespec *timestamp);
+/**
+ * Adjust the timesync clock on an Ethernet device..
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param delta
+ * The adjustment in nanoseconds
+ *
+ * @return
+ * - 0: Success.
+ * - -ENODEV: The port ID is invalid.
+ * - -ENOTSUP: The function is not supported by the Ethernet driver.
+ */
+extern int rte_eth_timesync_time_adjust(uint8_t port_id, int64_t delta);
+
+/**
+ * Read the time from the timesync clock on an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param time
+ * Pointer to the timespec struct.
+ *
+ * @return
+ * - 0: Success.
+ */
+extern int rte_eth_timesync_time_get(uint8_t port_id,
+ struct timespec *time);
+
+
+/**
+ * Set the time of the timesync clock on an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param time
+ * Pointer to the timespec struct.
+ *
+ * @return
+ * - 0: Success.
+ * - -EINVAL: No timestamp is available.
+ * - -ENODEV: The port ID is invalid.
+ * - -ENOTSUP: The function is not supported by the Ethernet driver.
+ */
+extern int rte_eth_timesync_time_set(uint8_t port_id,
+ struct timespec *time);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_ether/rte_ether_version.map b/lib/librte_ether/rte_ether_version.map
index 8345a6c..78b46c1 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -127,3 +127,12 @@ DPDK_2.1 {
rte_eth_timesync_read_tx_timestamp;
} DPDK_2.0;
+
+DPDK_2.2 {
+ global:
+
+ rte_eth_timesync_time_adjust;
+ rte_eth_timesync_time_get;
+ rte_eth_timesync_time_set;
+
+} DPDK_2.1;
--
2.1.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] lpm patches
@ 2015-10-30 12:00 4% Bruce Richardson
2015-10-30 17:59 0% ` Matthew Hall
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2015-10-30 12:00 UTC (permalink / raw)
To: dev, thomas.monjalon, mhall, michalx.k.jastrzebski, medvedkinv, stephen
Hi all,
there have been a lot of patches submitted in the 2.2 release cycle with
extensions to the LPM library. [Referring to just LPM for IPv4 here]
Given the fact that we now have - by my count - four different patchsets
to extend this lib, we probably need to take some time to reconcile the
differences between these submissions and determine what, if anything, can be
applied for 2.2, and what should be done for 2.3.
References:
>From Vladimir Medvedkin - http://dpdk.org/dev/patchwork/patch/8065/
>From Stephen Hemminger - http://dpdk.org/dev/patchwork/patch/7981/
>From Michal K. & Michal J. - http://dpdk.org/dev/patchwork/patch/7937/
>From Matthew Hall - http://dpdk.org/dev/patchwork/patch/7984/ [since
Matthew's patches were attachments, I don't think they came through in patchwork
correctly :-(, but that is the relevant link there anyway.]
What's common:
* increasing the number of bits in the next-hop field
However, just about everything else seems to be different [thanks to Michal
Jastrzebski for doing some analysis on the patches to help me out]:
* Some patches increase the next-hop to 16 bits, others to 24-bits. In both cases
a single entry still only occupies 32-bits, so can be read/written to
atomically
* Only Michal's set appears to take into account ABI versioning, which is
a difficult problem for this lib, with inlined functions.
* Matthew's patchset moves the lookup functions to be non-inlined, which will
make future updates easier from ABI compatibility - at the cost of lookup
performance.
* Vladimir's patchset merges in the tbl24 and tbl8 entries into a single data
type.
* That patchset also introduces an extra optional 32-bit field "as_num", allowing
64-bit lpm table entries - obviously at a cost of increased memory/cache
footprint.
* Stephen's patchset includes a range of other fixes e.g. for more efficient
management of the rules array, and dynamic allocation of the TBL8s.
* Matthew's patchset also includes change to LPM for IPv6, which I'm considering
out-of-scope for now, so as to focus on LPM v4 only.
Overall, most of the above changes seem reasonable, so therefore, I would suggest
that a combined approach would be:
* Increase next hops to be the full 24 bits, so as to allow maximum flexibility
and not waste the extra 8 bits of space in the 32-bit entries.
* Move the lookup functions which work on multiple packets to be non-inlined
* Merge in the tbl24 and tbl8 structures to make the code that little bit shorter
* Look to pull in as many of Stephen's other improvements as possible - though
this may be in a separate patchset to the other changes.
Other suggestions that I'd look for feedback on would be:
* I would recommend keeping the single value lpm lookup function as a static
inline function in the header file. For a single packet the cost of the
function call overhead will be significant, so I don't believe we should move
this to be an API call in the library.
* I'm uncertain as to the extra 32-bit as_num field. Adding it as an extra
#define is trivial, but adds to the compile-time config. Having it as a run-time
option is possible, but likely will make the code a lot more complicated, as
we no longer have arrays of a fixed size.
Naturally, with whatever solution is come up with, ABI compatibility must be
taken into account and functions versionned appropriately!
Question:
---------
do we want to have some of these changes in 2.2? If so, having Michal's
patch merged looks like the only viable option as it takes ABI into account,
and does not preclude any other changes being made to add the extra features
(merged structures, optimized rule handling, moving functions to non-inline etc.)
in the 2.3 timeframe.
Matthew, Stephen, Vladimir, Michal, Thomas - thoughts on this?
[do I accurately sum up the situation?]
Regards,
/Bruce
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 1/2] i40e: RSS/FD granularity configuration
2015-10-30 3:11 4% ` [dpdk-dev] [PATCH v7 1/2] " Helin Zhang
@ 2015-10-30 13:46 4% ` Thomas Monjalon
2015-11-02 2:11 4% ` Zhang, Helin
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-10-30 13:46 UTC (permalink / raw)
To: Helin Zhang; +Cc: dev
2015-10-30 11:11, Helin Zhang:
> v7 changes:
> Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
Why it would avoid ABI changes?
Have you passed the ABI checker?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] lpm patches
2015-10-30 12:00 4% [dpdk-dev] lpm patches Bruce Richardson
@ 2015-10-30 17:59 0% ` Matthew Hall
2015-10-30 19:34 0% ` Vladimir Medvedkin
0 siblings, 1 reply; 200+ results
From: Matthew Hall @ 2015-10-30 17:59 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
On Fri, Oct 30, 2015 at 12:00:18PM +0000, Bruce Richardson wrote:
> Matthew's patches were attachments, I don't think they came through in patchwork
> correctly :-(, but that is the relevant link there anyway.]
Let me know if there is something I can do better there. I was having a
difficult time figuring out how to preserve the thread ID in the middle of the
thread and not cause a new thread. The git email workflows are very confusing
and I figured it was better to send something as soon as I could.
> * Some patches increase the next-hop to 16 bits, others to 24-bits. In both cases
> a single entry still only occupies 32-bits, so can be read/written to
> atomically
I went with 24 because it was the biggest amount I could get that still had
this property.
> * Only Michal's set appears to take into account ABI versioning, which is
> a difficult problem for this lib, with inlined functions.
Agreed. His patches are the most professional from this perspective. This is
why I was trying to contribute to you and to him so we get the most
professional result for the customers.
> * Matthew's patchset moves the lookup functions to be non-inlined, which will
> make future updates easier from ABI compatibility - at the cost of lookup
> performance.
This point is optional for me. I did it, because without it, it was totally
impossible for me to work on the code in a debugger as I am a security
engineering guy not a crazy embedded C coder or kernel hacker.
> * Vladimir's patchset merges in the tbl24 and tbl8 entries into a single data
> type.
I really liked this feature of Vladimir's patches, it makes it easier to
maintain and less confusing. I had a lot of headaches keeping all those
structs straight with the separate types, but I didn't know we had the chance
for a great big MEGA-REFACTOR. I love this community!
> * That patchset also introduces an extra optional 32-bit field "as_num", allowing
> 64-bit lpm table entries - obviously at a cost of increased memory/cache
> footprint.
Is there a way we could test it? Vladimir, did you test the performance? If
so, what happened?
> * Stephen's patchset includes a range of other fixes e.g. for more efficient
> management of the rules array, and dynamic allocation of the TBL8s.
> * Matthew's patchset also includes change to LPM for IPv6, which I'm considering
> out-of-scope for now, so as to focus on LPM v4 only.
Any chance that is inconsistent betwen LPM4 and LPM6 really hoses me, because
I am writing green-field code which treats both protocols as first-class
citizens and I'd really not like to have totally inconsistent and inferior
support in one versus the other.
> * Increase next hops to be the full 24 bits, so as to allow maximum flexibility
> and not waste the extra 8 bits of space in the 32-bit entries.
+1
> * Move the lookup functions which work on multiple packets to be non-inlined
Open to opinions on the performance of this. I am not an expert on this area.
> * Merge in the tbl24 and tbl8 structures to make the code that little bit shorter
+1
> * Look to pull in as many of Stephen's other improvements as possible - though
> this may be in a separate patchset to the other changes.
+1. Perhaps if we get a pre-release on a branch with everything else, we could
see if Stephen is willing to rebase his non-duplicate changes.
> * I'm uncertain as to the extra 32-bit as_num field. Adding it as an extra
> #define is trivial, but adds to the compile-time config. Having it as a run-time
> option is possible, but likely will make the code a lot more complicated, as
> we no longer have arrays of a fixed size.
>
> Naturally, with whatever solution is come up with, ABI compatibility must be
> taken into account and functions versionned appropriately!
Normally I am not a big define guy. But it seems like a define is good here.
Somebody is going to need to know beforehand if they are making a Core Router
where they want this, or a Security Inspection system like mine, etc.
So it seems easier than doing a bunch of crazy size-juggling in the code.
> do we want to have some of these changes in 2.2?
Personally I am OK to wait as I have it working in my copy. I am just trying
to be a good citizen of the community and contribute back when I see some core
engineers going after the same code.
In particular, for me, having LPM4 only with no LPM6 is not worth much so I'd
be happy to wait for a single upgrade to both of them.
> Matthew, Stephen, Vladimir, Michal, Thomas - thoughts on this?
> [do I accurately sum up the situation?]
This email was top-quality and very well done by you guys.
Matthew.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 0/3] Add RETA configuration to mlx5
@ 2015-10-30 18:58 3% ` Adrien Mazarguil
0 siblings, 0 replies; 200+ results
From: Adrien Mazarguil @ 2015-10-30 18:58 UTC (permalink / raw)
To: dev
mlx5 devices support indirection tables of variable size up to 512 entries,
which requires a larger configuration structure (requiring a change in the
ABI).
This patchset can be considered as a first RFC step because the current API
is not very practical due to the following limitations:
- Configuration with chunks of 64 entries.
- Fixed total number of entries (previously 128, now 512).
- RETA configuration with testpmd is quite tedious (all entries must be
specified with really long lines).
Changes in v2:
- None, but sending again anyway following v2 of previous patchsets
("Mellanox ConnectX-4 PMD (mlx5)",
"Enhance mlx5 with Mellanox OFED 3.1" and
"Add link status notification support to Mellanox PMDs").
Nelio Laranjeiro (3):
cmdline: increase command line buffer
ethdev: change RETA type in rte_eth_rss_reta_entry64
mlx5: RETA query/update support
drivers/net/mlx5/mlx5.c | 4 +
drivers/net/mlx5/mlx5.h | 7 ++
drivers/net/mlx5/mlx5_ethdev.c | 29 ++++++
drivers/net/mlx5/mlx5_rss.c | 163 ++++++++++++++++++++++++++++++
drivers/net/mlx5/mlx5_rxq.c | 53 ++--------
drivers/net/mlx5/mlx5_utils.h | 20 ++++
lib/librte_cmdline/cmdline_parse.h | 2 +-
lib/librte_cmdline/cmdline_parse_string.h | 2 +-
lib/librte_cmdline/cmdline_rdline.h | 2 +-
lib/librte_ether/rte_ethdev.h | 2 +-
10 files changed, 235 insertions(+), 49 deletions(-)
--
2.1.0
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] lpm patches
2015-10-30 17:59 0% ` Matthew Hall
@ 2015-10-30 19:34 0% ` Vladimir Medvedkin
2015-10-30 21:55 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Vladimir Medvedkin @ 2015-10-30 19:34 UTC (permalink / raw)
To: Matthew Hall; +Cc: dev
Hi all,
2015-10-30 20:59 GMT+03:00 Matthew Hall <mhall@mhcomputing.net>:
> On Fri, Oct 30, 2015 at 12:00:18PM +0000, Bruce Richardson wrote:
> > Matthew's patches were attachments, I don't think they came through in
> patchwork
> > correctly :-(, but that is the relevant link there anyway.]
>
> Let me know if there is something I can do better there. I was having a
> difficult time figuring out how to preserve the thread ID in the middle of
> the
> thread and not cause a new thread. The git email workflows are very
> confusing
> and I figured it was better to send something as soon as I could.
>
> > * Some patches increase the next-hop to 16 bits, others to 24-bits. In
> both cases
> > a single entry still only occupies 32-bits, so can be read/written to
> > atomically
>
> I went with 24 because it was the biggest amount I could get that still had
> this property.
>
> > * Only Michal's set appears to take into account ABI versioning, which is
> > a difficult problem for this lib, with inlined functions.
>
> Agreed. His patches are the most professional from this perspective. This
> is
> why I was trying to contribute to you and to him so we get the most
> professional result for the customers.
>
> > * Matthew's patchset moves the lookup functions to be non-inlined, which
> will
> > make future updates easier from ABI compatibility - at the cost of
> lookup
> > performance.
>
> This point is optional for me. I did it, because without it, it was totally
> impossible for me to work on the code in a debugger as I am a security
> engineering guy not a crazy embedded C coder or kernel hacker.
>
> > * Vladimir's patchset merges in the tbl24 and tbl8 entries into a single
> data
> > type.
>
> I really liked this feature of Vladimir's patches, it makes it easier to
> maintain and less confusing. I had a lot of headaches keeping all those
> structs straight with the separate types, but I didn't know we had the
> chance
> for a great big MEGA-REFACTOR. I love this community!
>
> > * That patchset also introduces an extra optional 32-bit field "as_num",
> allowing
> > 64-bit lpm table entries - obviously at a cost of increased
> memory/cache
> > footprint.
>
> Is there a way we could test it? Vladimir, did you test the performance? If
> so, what happened?
>
Performance regression depends on the traffic pattern and cache size.
>
> > * Stephen's patchset includes a range of other fixes e.g. for more
> efficient
> > management of the rules array, and dynamic allocation of the TBL8s.
> > * Matthew's patchset also includes change to LPM for IPv6, which I'm
> considering
> > out-of-scope for now, so as to focus on LPM v4 only.
>
> Any chance that is inconsistent betwen LPM4 and LPM6 really hoses me,
> because
> I am writing green-field code which treats both protocols as first-class
> citizens and I'd really not like to have totally inconsistent and inferior
> support in one versus the other.
>
> > * Increase next hops to be the full 24 bits, so as to allow maximum
> flexibility
> > and not waste the extra 8 bits of space in the 32-bit entries.
>
> +1
>
+1. Split of next hop and forwarding class I can do in app logic.
>
> > * Move the lookup functions which work on multiple packets to be
> non-inlined
>
> Open to opinions on the performance of this. I am not an expert on this
> area.
>
> > * Merge in the tbl24 and tbl8 structures to make the code that little
> bit shorter
>
> +1
>
> > * Look to pull in as many of Stephen's other improvements as possible -
> though
> > this may be in a separate patchset to the other changes.
>
> +1. Perhaps if we get a pre-release on a branch with everything else, we
> could
> see if Stephen is willing to rebase his non-duplicate changes.
>
> > * I'm uncertain as to the extra 32-bit as_num field. Adding it as an
> extra
> > #define is trivial, but adds to the compile-time config. Having it as
> a run-time
> > option is possible, but likely will make the code a lot more
> complicated, as
> > we no longer have arrays of a fixed size.
> >
> > Naturally, with whatever solution is come up with, ABI compatibility
> must be
> > taken into account and functions versionned appropriately!
>
> Normally I am not a big define guy. But it seems like a define is good
> here.
> Somebody is going to need to know beforehand if they are making a Core
> Router
> where they want this, or a Security Inspection system like mine, etc.
>
For example in case of core router as_num feature can be necessary for
netflow. It can be necessary in case of security device such as my ddos
mitigation system.
>
> So it seems easier than doing a bunch of crazy size-juggling in the code.
>
> > do we want to have some of these changes in 2.2?
>
> Personally I am OK to wait as I have it working in my copy. I am just
> trying
> to be a good citizen of the community and contribute back when I see some
> core
> engineers going after the same code.
>
> In particular, for me, having LPM4 only with no LPM6 is not worth much so
> I'd
> be happy to wait for a single upgrade to both of them.
>
> > Matthew, Stephen, Vladimir, Michal, Thomas - thoughts on this?
> > [do I accurately sum up the situation?]
>
> This email was top-quality and very well done by you guys.
>
> Matthew.
>
Regards,
Vladimir
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] lpm patches
2015-10-30 19:34 0% ` Vladimir Medvedkin
@ 2015-10-30 21:55 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2015-10-30 21:55 UTC (permalink / raw)
To: Vladimir Medvedkin; +Cc: dev
On Fri, Oct 30, 2015 at 10:34:54PM +0300, Vladimir Medvedkin wrote:
> Hi all,
>
> 2015-10-30 20:59 GMT+03:00 Matthew Hall <mhall@mhcomputing.net>:
>
> > On Fri, Oct 30, 2015 at 12:00:18PM +0000, Bruce Richardson wrote:
> > > Matthew's patches were attachments, I don't think they came through in
> > patchwork
> > > correctly :-(, but that is the relevant link there anyway.]
> >
> > Let me know if there is something I can do better there. I was having a
> > difficult time figuring out how to preserve the thread ID in the middle of
> > the
> > thread and not cause a new thread. The git email workflows are very
> > confusing
> > and I figured it was better to send something as soon as I could.
> >
> > > * Some patches increase the next-hop to 16 bits, others to 24-bits. In
> > both cases
> > > a single entry still only occupies 32-bits, so can be read/written to
> > > atomically
> >
> > I went with 24 because it was the biggest amount I could get that still had
> > this property.
> >
> > > * Only Michal's set appears to take into account ABI versioning, which is
> > > a difficult problem for this lib, with inlined functions.
> >
> > Agreed. His patches are the most professional from this perspective. This
> > is
> > why I was trying to contribute to you and to him so we get the most
> > professional result for the customers.
> >
> > > * Matthew's patchset moves the lookup functions to be non-inlined, which
> > will
> > > make future updates easier from ABI compatibility - at the cost of
> > lookup
> > > performance.
> >
> > This point is optional for me. I did it, because without it, it was totally
> > impossible for me to work on the code in a debugger as I am a security
> > engineering guy not a crazy embedded C coder or kernel hacker.
> >
> > > * Vladimir's patchset merges in the tbl24 and tbl8 entries into a single
> > data
> > > type.
> >
> > I really liked this feature of Vladimir's patches, it makes it easier to
> > maintain and less confusing. I had a lot of headaches keeping all those
> > structs straight with the separate types, but I didn't know we had the
> > chance
> > for a great big MEGA-REFACTOR. I love this community!
> >
> > > * That patchset also introduces an extra optional 32-bit field "as_num",
> > allowing
> > > 64-bit lpm table entries - obviously at a cost of increased
> > memory/cache
> > > footprint.
> >
> > Is there a way we could test it? Vladimir, did you test the performance? If
> > so, what happened?
> >
> Performance regression depends on the traffic pattern and cache size.
>
> >
> > > * Stephen's patchset includes a range of other fixes e.g. for more
> > efficient
> > > management of the rules array, and dynamic allocation of the TBL8s.
> > > * Matthew's patchset also includes change to LPM for IPv6, which I'm
> > considering
> > > out-of-scope for now, so as to focus on LPM v4 only.
> >
> > Any chance that is inconsistent betwen LPM4 and LPM6 really hoses me,
> > because
> > I am writing green-field code which treats both protocols as first-class
> > citizens and I'd really not like to have totally inconsistent and inferior
> > support in one versus the other.
> >
> > > * Increase next hops to be the full 24 bits, so as to allow maximum
> > flexibility
> > > and not waste the extra 8 bits of space in the 32-bit entries.
> >
> > +1
> >
> +1. Split of next hop and forwarding class I can do in app logic.
>
> >
> > > * Move the lookup functions which work on multiple packets to be
> > non-inlined
> >
> > Open to opinions on the performance of this. I am not an expert on this
> > area.
> >
> > > * Merge in the tbl24 and tbl8 structures to make the code that little
> > bit shorter
> >
> > +1
> >
> > > * Look to pull in as many of Stephen's other improvements as possible -
> > though
> > > this may be in a separate patchset to the other changes.
> >
> > +1. Perhaps if we get a pre-release on a branch with everything else, we
> > could
> > see if Stephen is willing to rebase his non-duplicate changes.
> >
> > > * I'm uncertain as to the extra 32-bit as_num field. Adding it as an
> > extra
> > > #define is trivial, but adds to the compile-time config. Having it as
> > a run-time
> > > option is possible, but likely will make the code a lot more
> > complicated, as
> > > we no longer have arrays of a fixed size.
> > >
> > > Naturally, with whatever solution is come up with, ABI compatibility
> > must be
> > > taken into account and functions versionned appropriately!
> >
> > Normally I am not a big define guy. But it seems like a define is good
> > here.
> > Somebody is going to need to know beforehand if they are making a Core
> > Router
> > where they want this, or a Security Inspection system like mine, etc.
> >
> For example in case of core router as_num feature can be necessary for
> netflow. It can be necessary in case of security device such as my ddos
> mitigation system.
>
> >
> > So it seems easier than doing a bunch of crazy size-juggling in the code.
> >
> > > do we want to have some of these changes in 2.2?
> >
> > Personally I am OK to wait as I have it working in my copy. I am just
> > trying
> > to be a good citizen of the community and contribute back when I see some
> > core
> > engineers going after the same code.
> >
> > In particular, for me, having LPM4 only with no LPM6 is not worth much so
> > I'd
> > be happy to wait for a single upgrade to both of them.
> >
> > > Matthew, Stephen, Vladimir, Michal, Thomas - thoughts on this?
> > > [do I accurately sum up the situation?]
> >
> > This email was top-quality and very well done by you guys.
> >
> > Matthew.
> >
>
> Regards,
> Vladimir
Thanks for the feedback guys. Looks like we need to find a way to get the ability
to have either 32-bit or 64-bit LPM entries supported, as well as the additional
enhancements proposed :-)
We'll see what we can do in 2.3 timeframe.
Regards,
/Bruce
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 1/9] ethdev: rename dcb_queue to dcb_tc in dcb config struct
@ 2015-10-31 15:57 4% ` Jingjing Wu
0 siblings, 0 replies; 200+ results
From: Jingjing Wu @ 2015-10-31 15:57 UTC (permalink / raw)
To: dev
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
app/test-pmd/testpmd.c | 8 ++++----
doc/guides/rel_notes/release_2_2.rst | 4 ++++
drivers/net/ixgbe/ixgbe_rxtx.c | 10 +++++-----
examples/vmdq_dcb/main.c | 4 ++--
lib/librte_ether/rte_ethdev.h | 14 +++++++-------
5 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 3cd3cd0..4c6aec6 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1878,8 +1878,8 @@ get_eth_dcb_conf(struct rte_eth_conf *eth_conf, struct dcb_config *dcb_conf)
vmdq_rx_conf.pool_map[i].pools = 1 << (i % vmdq_rx_conf.nb_queue_pools);
}
for (i = 0; i < ETH_DCB_NUM_USER_PRIORITIES; i++) {
- vmdq_rx_conf.dcb_queue[i] = i;
- vmdq_tx_conf.dcb_queue[i] = i;
+ vmdq_rx_conf.dcb_tc[i] = i;
+ vmdq_tx_conf.dcb_tc[i] = i;
}
/*set DCB mode of RX and TX of multiple queues*/
@@ -1909,8 +1909,8 @@ get_eth_dcb_conf(struct rte_eth_conf *eth_conf, struct dcb_config *dcb_conf)
tx_conf.nb_tcs = dcb_conf->num_tcs;
for (i = 0; i < ETH_DCB_NUM_USER_PRIORITIES; i++){
- rx_conf.dcb_queue[i] = i;
- tx_conf.dcb_queue[i] = i;
+ rx_conf.dcb_tc[i] = i;
+ tx_conf.dcb_tc[i] = i;
}
eth_conf->rxmode.mq_mode = ETH_MQ_RX_DCB;
eth_conf->txmode.mq_mode = ETH_MQ_TX_DCB;
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 116162e..1857e1d 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -138,6 +138,10 @@ API Changes
* The devargs union field virtual is renamed to virt for C++ compatibility.
+* The dcb_queue is renamed to dcb_tc in following dcb configuration
+ structures: rte_eth_dcb_rx_conf, rte_eth_vmdq_dcb_tx_conf,
+ rte_eth_dcb_tx_conf, rte_eth_vmdq_dcb_conf.
+
ABI Changes
-----------
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 1158562..6a62d67 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -2928,7 +2928,7 @@ ixgbe_vmdq_dcb_configure(struct rte_eth_dev *dev)
* mapping is done with 3 bits per priority,
* so shift by i*3 each time
*/
- queue_mapping |= ((cfg->dcb_queue[i] & 0x07) << (i * 3));
+ queue_mapping |= ((cfg->dcb_tc[i] & 0x07) << (i * 3));
IXGBE_WRITE_REG(hw, IXGBE_RTRUP2TC, queue_mapping);
@@ -3063,7 +3063,7 @@ ixgbe_vmdq_dcb_rx_config(struct rte_eth_dev *dev,
}
/* User Priority to Traffic Class mapping */
for (i = 0; i < ETH_DCB_NUM_USER_PRIORITIES; i++) {
- j = vmdq_rx_conf->dcb_queue[i];
+ j = vmdq_rx_conf->dcb_tc[i];
tc = &dcb_config->tc_config[j];
tc->path[IXGBE_DCB_RX_CONFIG].up_to_tc_bitmap =
(uint8_t)(1 << j);
@@ -3091,7 +3091,7 @@ ixgbe_dcb_vt_tx_config(struct rte_eth_dev *dev,
/* User Priority to Traffic Class mapping */
for (i = 0; i < ETH_DCB_NUM_USER_PRIORITIES; i++) {
- j = vmdq_tx_conf->dcb_queue[i];
+ j = vmdq_tx_conf->dcb_tc[i];
tc = &dcb_config->tc_config[j];
tc->path[IXGBE_DCB_TX_CONFIG].up_to_tc_bitmap =
(uint8_t)(1 << j);
@@ -3113,7 +3113,7 @@ ixgbe_dcb_rx_config(struct rte_eth_dev *dev,
/* User Priority to Traffic Class mapping */
for (i = 0; i < ETH_DCB_NUM_USER_PRIORITIES; i++) {
- j = rx_conf->dcb_queue[i];
+ j = rx_conf->dcb_tc[i];
tc = &dcb_config->tc_config[j];
tc->path[IXGBE_DCB_RX_CONFIG].up_to_tc_bitmap =
(uint8_t)(1 << j);
@@ -3134,7 +3134,7 @@ ixgbe_dcb_tx_config(struct rte_eth_dev *dev,
/* User Priority to Traffic Class mapping */
for (i = 0; i < ETH_DCB_NUM_USER_PRIORITIES; i++) {
- j = tx_conf->dcb_queue[i];
+ j = tx_conf->dcb_tc[i];
tc = &dcb_config->tc_config[j];
tc->path[IXGBE_DCB_TX_CONFIG].up_to_tc_bitmap =
(uint8_t)(1 << j);
diff --git a/examples/vmdq_dcb/main.c b/examples/vmdq_dcb/main.c
index c31c2ce..b90ac28 100644
--- a/examples/vmdq_dcb/main.c
+++ b/examples/vmdq_dcb/main.c
@@ -107,7 +107,7 @@ static const struct rte_eth_conf vmdq_dcb_conf_default = {
.default_pool = 0,
.nb_pool_maps = 0,
.pool_map = {{0, 0},},
- .dcb_queue = {0},
+ .dcb_tc = {0},
},
},
};
@@ -144,7 +144,7 @@ get_eth_conf(struct rte_eth_conf *eth_conf, enum rte_eth_nb_pools num_pools)
conf.pool_map[i].pools = 1 << (i % num_pools);
}
for (i = 0; i < ETH_DCB_NUM_USER_PRIORITIES; i++){
- conf.dcb_queue[i] = (uint8_t)(i % (NUM_QUEUES/num_pools));
+ conf.dcb_tc[i] = (uint8_t)(i % (NUM_QUEUES/num_pools));
}
(void)(rte_memcpy(eth_conf, &vmdq_dcb_conf_default, sizeof(*eth_conf)));
(void)(rte_memcpy(ð_conf->rx_adv_conf.vmdq_dcb_conf, &conf,
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 8a8c82b..377da6a 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -543,20 +543,20 @@ enum rte_eth_nb_pools {
/* This structure may be extended in future. */
struct rte_eth_dcb_rx_conf {
enum rte_eth_nb_tcs nb_tcs; /**< Possible DCB TCs, 4 or 8 TCs */
- uint8_t dcb_queue[ETH_DCB_NUM_USER_PRIORITIES];
- /**< Possible DCB queue,4 or 8. */
+ /** Traffic class each UP mapped to. */
+ uint8_t dcb_tc[ETH_DCB_NUM_USER_PRIORITIES];
};
struct rte_eth_vmdq_dcb_tx_conf {
enum rte_eth_nb_pools nb_queue_pools; /**< With DCB, 16 or 32 pools. */
- uint8_t dcb_queue[ETH_DCB_NUM_USER_PRIORITIES];
- /**< Possible DCB queue,4 or 8. */
+ /** Traffic class each UP mapped to. */
+ uint8_t dcb_tc[ETH_DCB_NUM_USER_PRIORITIES];
};
struct rte_eth_dcb_tx_conf {
enum rte_eth_nb_tcs nb_tcs; /**< Possible DCB TCs, 4 or 8 TCs. */
- uint8_t dcb_queue[ETH_DCB_NUM_USER_PRIORITIES];
- /**< Possible DCB queue,4 or 8. */
+ /** Traffic class each UP mapped to. */
+ uint8_t dcb_tc[ETH_DCB_NUM_USER_PRIORITIES];
};
struct rte_eth_vmdq_tx_conf {
@@ -583,7 +583,7 @@ struct rte_eth_vmdq_dcb_conf {
uint16_t vlan_id; /**< The vlan id of the received frame */
uint64_t pools; /**< Bitmask of pools for packet rx */
} pool_map[ETH_VMDQ_MAX_VLAN_FILTERS]; /**< VMDq vlan pool maps. */
- uint8_t dcb_queue[ETH_DCB_NUM_USER_PRIORITIES];
+ uint8_t dcb_tc[ETH_DCB_NUM_USER_PRIORITIES];
/**< Selects a queue in a pool */
};
--
2.4.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v3 1/3] ethdev: extend struct to support flow director in VFs
@ 2015-10-31 16:24 17% ` Jingjing Wu
1 sibling, 0 replies; 200+ results
From: Jingjing Wu @ 2015-10-31 16:24 UTC (permalink / raw)
To: dev
This patch extends struct rte_eth_fdir_flow_ext to support flow
director in VFs.
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_2_2.rst | 3 +++
lib/librte_ether/rte_eth_ctrl.h | 2 ++
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index a391ff0..cd2b80c 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -17,10 +17,6 @@ Deprecation Notices
imissed, ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
-* ABI changes are planned for struct rte_eth_fdir_flow_ext in order to support
- flow director filtering in VF. The release 2.1 does not contain these ABI
- changes, but release 2.2 will, and no backwards compatibility is planned.
-
* ABI changes are planned for struct rte_eth_fdir_filter and
rte_eth_fdir_masks in order to support new flow director modes,
MAC VLAN and Cloud, on x550. The MAC VLAN mode means the MAC and
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 116162e..8ca3872 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -164,6 +164,9 @@ ABI Changes
* librte_cfgfile: Allow longer names and values by increasing the constants
CFG_NAME_LEN and CFG_VALUE_LEN to 64 and 256 respectively.
+* The rte_eth_fdir_flow_ext structure is changed. New fields are added to
+ support flow director filtering in VF.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 770c76c..3f86094 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -426,6 +426,8 @@ struct rte_eth_fdir_flow_ext {
uint16_t vlan_tci;
uint8_t flexbytes[RTE_ETH_FDIR_MAX_FLEXLEN];
/**< It is filled by the flexible payload to match. */
+ uint8_t is_vf; /**< 1 for VF, 0 for port dev */
+ uint16_t dst_id; /**< VF ID, available when is_vf is 1*/
};
/**
--
2.4.0
^ permalink raw reply [relevance 17%]
* [dpdk-dev] [PATCH] mk: fix ABI versioning compile error for combined shared library
@ 2015-11-01 23:17 4% ` Ferruh Yigit
2015-11-01 23:24 4% ` Thomas Monjalon
2015-11-02 10:23 3% ` [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine Panu Matilainen
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-11-01 23:17 UTC (permalink / raw)
To: dev; +Cc: Eric Kinzie
Fixes following error:
LD libdpdk.so
/usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
for symbol <function>@DPDK_x.y
Defines version symbols in a fixed path libdpdk.map file and this
value hardcoded into makefile
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
lib/libdpdk.map | 12 ++++++++++++
mk/rte.sharelib.mk | 5 +++--
2 files changed, 15 insertions(+), 2 deletions(-)
create mode 100644 lib/libdpdk.map
diff --git a/lib/libdpdk.map b/lib/libdpdk.map
new file mode 100644
index 0000000..3988a3f
--- /dev/null
+++ b/lib/libdpdk.map
@@ -0,0 +1,12 @@
+DPDK_2.0 {
+
+};
+
+DPDK_2.1 {
+
+} DPDK_2.0;
+
+DPDK_2.2 {
+
+} DPDK_2.1;
+
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
index 7bb7219..e206ce1 100644
--- a/mk/rte.sharelib.mk
+++ b/mk/rte.sharelib.mk
@@ -40,6 +40,7 @@ LIB_ONE := lib$(RTE_LIBNAME).so
else
LIB_ONE := lib$(RTE_LIBNAME).a
endif
+SHARED_LDFLAGS += --version-script=./lib/libdpdk.map
endif
.PHONY:sharelib
@@ -50,10 +51,10 @@ OBJS = $(wildcard $(RTE_OUTPUT)/build/lib/*.o)
ifeq ($(LINK_USING_CC),1)
# Override the definition of LD here, since we're linking with CC
LD := $(CC) $(CPU_CFLAGS)
-O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \
+O_TO_S = $(LD) $(call linkerprefix,$(SHARED_LDFLAGS)) \
-shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
else
-O_TO_S = $(LD) $(CPU_LDFLAGS) \
+O_TO_S = $(LD) $(SHARED_LDFLAGS) \
-shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
endif
--
1.9.3
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] mk: fix ABI versioning compile error for combined shared library
2015-11-01 23:17 4% ` [dpdk-dev] [PATCH] mk: fix ABI versioning compile error for combined shared library Ferruh Yigit
@ 2015-11-01 23:24 4% ` Thomas Monjalon
2015-11-02 0:05 4% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-01 23:24 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, Eric Kinzie
2015-11-01 23:17, Ferruh Yigit:
> Fixes following error:
> LD libdpdk.so
> /usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
> for symbol <function>@DPDK_x.y
> --- a/mk/rte.sharelib.mk
> +++ b/mk/rte.sharelib.mk
> @@ -40,6 +40,7 @@ LIB_ONE := lib$(RTE_LIBNAME).so
> else
> LIB_ONE := lib$(RTE_LIBNAME).a
> endif
> +SHARED_LDFLAGS += --version-script=./lib/libdpdk.map
> endif
It looks to be the right thing to do.
> ifeq ($(LINK_USING_CC),1)
> # Override the definition of LD here, since we're linking with CC
> LD := $(CC) $(CPU_CFLAGS)
> -O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \
> +O_TO_S = $(LD) $(call linkerprefix,$(SHARED_LDFLAGS)) \
> -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
> else
> -O_TO_S = $(LD) $(CPU_LDFLAGS) \
> +O_TO_S = $(LD) $(SHARED_LDFLAGS) \
> -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
> endif
Why do you remove CPU_LDFLAGS?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] mk: fix ABI versioning compile error for combined shared library
2015-11-01 23:24 4% ` Thomas Monjalon
@ 2015-11-02 0:05 4% ` Ferruh Yigit
2015-11-02 7:10 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-11-02 0:05 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Eric Kinzie
On Mon, Nov 02, 2015 at 12:24:51AM +0100, Thomas Monjalon wrote:
> > ifeq ($(LINK_USING_CC),1)
> > # Override the definition of LD here, since we're linking with CC
> > LD := $(CC) $(CPU_CFLAGS)
> > -O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \
> > +O_TO_S = $(LD) $(call linkerprefix,$(SHARED_LDFLAGS)) \
> > -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
> > else
> > -O_TO_S = $(LD) $(CPU_LDFLAGS) \
> > +O_TO_S = $(LD) $(SHARED_LDFLAGS) \
> > -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
> > endif
>
> Why do you remove CPU_LDFLAGS?
CPU_LDFLAGS shared by other libraries and confilicts with this usage.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 1/2] i40e: RSS/FD granularity configuration
2015-10-30 13:46 4% ` Thomas Monjalon
@ 2015-11-02 2:11 4% ` Zhang, Helin
2015-11-02 7:27 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Zhang, Helin @ 2015-11-02 2:11 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, October 30, 2015 9:47 PM
> To: Zhang, Helin
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 1/2] i40e: RSS/FD granularity configuration
>
> 2015-10-30 11:11, Helin Zhang:
> > v7 changes:
> > Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
>
> Why it would avoid ABI changes?
> Have you passed the ABI checker?
Hi Thomas
The only structure modified is ' struct rte_eth_hash_filter_info ', where a new
element (struct rte_eth_input_set_conf input_set_conf) was added. But I kept its
structure the same size as another one (struct rte_eth_hash_global_conf global_conf)
already in that union, they are both in 12 bytes. That means nothing changed for
' struct rte_eth_hash_filter_info'.
In addition, macro of ' RTE_ETH_INSET_SIZE_MAX ' was added by me in this patch set,
and I modified its default value from 128 to 1 in the latest version, which does not affect
ABI, as it is a totally new macro.
A new element was added at the last of ' enum rte_eth_hash_filter_info_type ', I don't
think it will affect ABI as well.
struct rte_eth_hash_filter_info {
enum rte_eth_hash_filter_info_type info_type; /**< Information type */
/** Details of hash filter information */
union {
/** For RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT */
uint8_t enable;
/** Global configurations of hash filter */
struct rte_eth_hash_global_conf global_conf;
/** Global configurations of hash filter input set */
struct rte_eth_input_set_conf input_set_conf;
} info;
};
I did ABI check, but it seems that something wrong in running that check on all PMDs,
like below. While all other checks are quite well.
I am not sure if anybody else can run it successfully.
preparation, please wait ...
ERROR: the input dump d1 is invalid
preparation, please wait ...
ERROR: the input dump d1 is invalid
preparation, please wait ...
ERROR: the input dump d1 is invalid
preparation, please wait ...
ERROR: the input dump d1 is invalid
preparation, please wait ...
ERROR: the input dump d1 is invalid
preparation, please wait ...
ERROR: the input dump d1 is invalid
preparation, please wait ...
ERROR: the input dump d1 is invalid
preparation, please wait ...
Regards,
Helin
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 1/2] i40e: RSS/FD granularity configuration
2015-11-02 2:11 4% ` Zhang, Helin
@ 2015-11-02 7:27 3% ` Thomas Monjalon
2015-11-02 7:59 0% ` Zhang, Helin
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-02 7:27 UTC (permalink / raw)
To: Zhang, Helin; +Cc: dev
2015-11-02 02:11, Zhang, Helin:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2015-10-30 11:11, Helin Zhang:
> > > v7 changes:
> > > Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
> >
> > Why it would avoid ABI changes?
> > Have you passed the ABI checker?
>
> Hi Thomas
>
> The only structure modified is ' struct rte_eth_hash_filter_info ', where a new
> element (struct rte_eth_input_set_conf input_set_conf) was added. But I kept its
> structure the same size as another one (struct rte_eth_hash_global_conf global_conf)
> already in that union, they are both in 12 bytes. That means nothing changed for
> ' struct rte_eth_hash_filter_info'.
First, it should be justified in the commit message.
Second, I think it's wrong:
The union has struct rte_eth_hash_global_conf = enum + uint32_t + uint32_t
You are adding struct rte_eth_input_set_conf = uint16_t + uint16_t + enum + enum
I'm not sure we can assume the sizes are the same.
The ethdev ABI is already broken in this release. So maybe we can agree that
it's not a big deal but it should be notified in the release notes and,
in this case, you could keep your original patch with 128 enums.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] mk: fix ABI versioning compile error for combined shared library
2015-11-02 0:05 4% ` Ferruh Yigit
@ 2015-11-02 7:10 4% ` Thomas Monjalon
2015-11-02 10:20 4% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-02 7:10 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, Eric Kinzie
2015-11-02 00:05, Ferruh Yigit:
> On Mon, Nov 02, 2015 at 12:24:51AM +0100, Thomas Monjalon wrote:
> > > ifeq ($(LINK_USING_CC),1)
> > > # Override the definition of LD here, since we're linking with CC
> > > LD := $(CC) $(CPU_CFLAGS)
> > > -O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \
> > > +O_TO_S = $(LD) $(call linkerprefix,$(SHARED_LDFLAGS)) \
> > > -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
> > > else
> > > -O_TO_S = $(LD) $(CPU_LDFLAGS) \
> > > +O_TO_S = $(LD) $(SHARED_LDFLAGS) \
> > > -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
> > > endif
> >
> > Why do you remove CPU_LDFLAGS?
>
> CPU_LDFLAGS shared by other libraries and confilicts with this usage.
Sorry I don't understand.
CPU_LDFLAGS is -melf_i386 for Intel 32-bit.
Why removing it for combined library? What is the conflict?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 1/2] i40e: RSS/FD granularity configuration
2015-11-02 7:27 3% ` Thomas Monjalon
@ 2015-11-02 7:59 0% ` Zhang, Helin
2015-11-02 8:23 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Zhang, Helin @ 2015-11-02 7:59 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Monday, November 2, 2015 3:28 PM
> To: Zhang, Helin
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 1/2] i40e: RSS/FD granularity configuration
>
> 2015-11-02 02:11, Zhang, Helin:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > 2015-10-30 11:11, Helin Zhang:
> > > > v7 changes:
> > > > Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
> > >
> > > Why it would avoid ABI changes?
> > > Have you passed the ABI checker?
> >
> > Hi Thomas
> >
> > The only structure modified is ' struct rte_eth_hash_filter_info ',
> > where a new element (struct rte_eth_input_set_conf input_set_conf) was
> > added. But I kept its structure the same size as another one (struct
> > rte_eth_hash_global_conf global_conf) already in that union, they are
> > both in 12 bytes. That means nothing changed for ' struct
> rte_eth_hash_filter_info'.
>
> First, it should be justified in the commit message.
> Second, I think it's wrong:
> The union has struct rte_eth_hash_global_conf = enum + uint32_t + uint32_t You
> are adding struct rte_eth_input_set_conf = uint16_t + uint16_t + enum + enum
> I'm not sure we can assume the sizes are the same.
Oh, yes, the size might not be the same on all platforms.
>
> The ethdev ABI is already broken in this release. So maybe we can agree that it's
> not a big deal but it should be notified in the release notes and, in this case, you
> could keep your original patch with 128 enums.
That's bad, but good for me. Can I just enable v6 as 'new', and disable 'v7'?
Or I need a new version?
Thank you very much!
Helin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 1/2] i40e: RSS/FD granularity configuration
2015-11-02 7:59 0% ` Zhang, Helin
@ 2015-11-02 8:23 3% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-11-02 8:23 UTC (permalink / raw)
To: Zhang, Helin; +Cc: dev
2015-11-02 07:59, Zhang, Helin:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2015-11-02 02:11, Zhang, Helin:
> > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > > 2015-10-30 11:11, Helin Zhang:
> > > > > v7 changes:
> > > > > Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
> > > >
> > > > Why it would avoid ABI changes?
> > > > Have you passed the ABI checker?
> > >
> > > Hi Thomas
> > >
> > > The only structure modified is ' struct rte_eth_hash_filter_info ',
> > > where a new element (struct rte_eth_input_set_conf input_set_conf) was
> > > added. But I kept its structure the same size as another one (struct
> > > rte_eth_hash_global_conf global_conf) already in that union, they are
> > > both in 12 bytes. That means nothing changed for ' struct
> > rte_eth_hash_filter_info'.
> >
> > First, it should be justified in the commit message.
> > Second, I think it's wrong:
> > The union has struct rte_eth_hash_global_conf = enum + uint32_t + uint32_t You
> > are adding struct rte_eth_input_set_conf = uint16_t + uint16_t + enum + enum
> > I'm not sure we can assume the sizes are the same.
> Oh, yes, the size might not be the same on all platforms.
>
> >
> > The ethdev ABI is already broken in this release. So maybe we can agree that it's
> > not a big deal but it should be notified in the release notes and, in this case, you
> > could keep your original patch with 128 enums.
> That's bad, but good for me. Can I just enable v6 as 'new', and disable 'v7'?
> Or I need a new version?
I think you need a new version to notify ABI change in the release notes.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] mk: fix ABI versioning compile error for combined shared library
2015-11-02 7:10 4% ` Thomas Monjalon
@ 2015-11-02 10:20 4% ` Ferruh Yigit
2015-11-02 15:23 4% ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-11-02 10:20 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Eric Kinzie
On Mon, Nov 02, 2015 at 08:10:25AM +0100, Thomas Monjalon wrote:
> 2015-11-02 00:05, Ferruh Yigit:
> > On Mon, Nov 02, 2015 at 12:24:51AM +0100, Thomas Monjalon wrote:
> > > > ifeq ($(LINK_USING_CC),1)
> > > > # Override the definition of LD here, since we're linking with CC
> > > > LD := $(CC) $(CPU_CFLAGS)
> > > > -O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \
> > > > +O_TO_S = $(LD) $(call linkerprefix,$(SHARED_LDFLAGS)) \
> > > > -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
> > > > else
> > > > -O_TO_S = $(LD) $(CPU_LDFLAGS) \
> > > > +O_TO_S = $(LD) $(SHARED_LDFLAGS) \
> > > > -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
> > > > endif
> > >
> > > Why do you remove CPU_LDFLAGS?
> >
> > CPU_LDFLAGS shared by other libraries and confilicts with this usage.
>
> Sorry I don't understand.
> CPU_LDFLAGS is -melf_i386 for Intel 32-bit.
> Why removing it for combined library? What is the conflict?
When combined shared option enabled, CPP_LDFLAGS will be processed and other libraries
CPU_LDFLAGS value will contain this value, and generate an compilation eroor like following:
"
gcc -m64 -Wl,--version-script=./lib/libdpdk.map -Wl,--version-script=/root/dpdk/lib/librte_eal/linuxapp/eal/rte_eal_version.map -shared <objs> -Wl,-soname,librte_eal.so.2.1 -o librte_eal.so.2.1
/usr/bin/ld: cannot open linker script file ./lib/libdpdk.map: No such file or directory
collect2: error: ld returned 1 exit status
"
That is why I have created a new variable, and CPU_LDFLAGS was empty,
but with double check what CPU_LDFLAGS is, it should stay there,
I will update the patch, at worst I can add a new flag instead of replacing CPU_LDFLAGS
Regards,
ferruh
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine
2015-11-01 23:17 4% ` [dpdk-dev] [PATCH] mk: fix ABI versioning compile error for combined shared library Ferruh Yigit
@ 2015-11-02 10:23 3% ` Panu Matilainen
2015-11-02 16:42 0% ` Eric Kinzie
1 sibling, 1 reply; 200+ results
From: Panu Matilainen @ 2015-11-02 10:23 UTC (permalink / raw)
To: Thomas Monjalon, Eric Kinzie; +Cc: dev
On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
> 2015-10-19 08:36, Eric Kinzie:
>> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER
>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
>> functions.
> [...]
>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
> [...]
>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \
>> + bond_mode_8023ad_setup_v22);
>
> I'm sorry it doesn't work well when trying to build a combined lib:
>
> ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2
>
> The symbols are OK in the .o file:
> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2
> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0
> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20
> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22
> 0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
>
> I don't understand the problem and I am considering disabling versioning in
> combined library.
>
> Any idea?
>
The .map additions look incorrect to me:
> diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
> index 22bd920..7f78717 100644
> --- a/drivers/net/bonding/rte_eth_bond_version.map
> +++ b/drivers/net/bonding/rte_eth_bond_version.map
> @@ -17,6 +17,9 @@ DPDK_2.0 {
> rte_eth_bond_slaves_get;
> rte_eth_bond_xmit_policy_get;
> rte_eth_bond_xmit_policy_set;
> + rte_eth_bond_8023ad_ext_collect;
> + rte_eth_bond_8023ad_ext_distrib;
> + rte_eth_bond_8023ad_ext_slowtx;
These symbols didn't exist in DPDK 2.0 but are only being added here. So
why are they being added to the 2.0 section?
>
> local: *;
> };
> @@ -27,3 +30,10 @@ DPDK_2.1 {
> rte_eth_bond_free;
>
> } DPDK_2.0;
> +
> +DPDK_2.2 {
> + local
> +
> + bond_mode_8023ad_conf_get;
> + bond_mode_8023ad_setup;
> +} DPDK_2.1;
These are marked local, as in, "not exported" which doesn't seem right.
Also they're lacking the rte_eth_ prefix. AFAICS this is what the symbol
export map should look like here:
DPDK_2.2 {
global:
rte_eth_bond_8023ad_ext_collect;
rte_eth_bond_8023ad_ext_distrib;
rte_eth_bond_8023ad_ext_slowtx;
rte_eth_bond_mode_8023ad_conf_get;
rte_eth_bond_mode_8023ad_setup;
} DPDK_2.1;
That said, problems with symbol versioning and the combined library were
predicted from the start, once the individual library versions start
advancing. For one, the combined library itself is not versioned at all
it is offending the ABI policy all the time.
Replacing the library with a linker script, as suggested before by Neil
Horman and Sergio Gonzales Monroy would eliminate these problems.
- Panu -
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v8 0/2] i40e: RSS/FD granularity configuration
2015-10-30 3:11 3% ` [dpdk-dev] [PATCH v7 0/2] " Helin Zhang
2015-10-30 3:11 4% ` [dpdk-dev] [PATCH v7 1/2] " Helin Zhang
2015-10-30 7:59 0% ` [dpdk-dev] [PATCH v7 0/2] " Wu, Jingjing
@ 2015-11-02 14:32 4% ` Helin Zhang
2015-11-02 14:32 5% ` [dpdk-dev] [PATCH v8 1/2] " Helin Zhang
2015-11-03 16:07 4% ` [dpdk-dev] [PATCH v9 0/2] " Helin Zhang
2 siblings, 2 replies; 200+ results
From: Helin Zhang @ 2015-11-02 14:32 UTC (permalink / raw)
To: dev
The default input set of fields of a received packet are loaded from firmware,
which cannot be modified even users want to use different fields for RSS or flow
director. Here adds more flexibilities of selecting or adding packet fields for
hash calculation or flow director to users. It also includes the modifications
in testpmd to support the testing.
v2 changes:
Solved the compilation issues.
v3 changes:
Support selecting more input set fields.
v4 changes:
Removed operation of 'delete', as it is not necessary.
Added FD granularity in both pmd and testpmd, as it is similar to RSS granularity.
v5 changes:
Fixed issue of generating wrong input set for registers on ipv6-udp and ipv6-tcp pc types.
Added clear masking operations during checking if MASK registers are opcupied or not.
Reworked several annotations.
v6 changes:
Updated documentation.
v7 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
Split documentation into pieces and put them directly into the patch of code changes directly.
v8 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 1 to 128, as ABI changes is allowed in ethdev.
Updated release notes.
Helin Zhang (2):
i40e: RSS/FD granularity configuration
app/testpmd: add test commands for RSS/FD granularity
app/test-pmd/cmdline.c | 218 ++++++++
doc/guides/rel_notes/deprecation.rst | 5 +
doc/guides/rel_notes/release_2_2.rst | 2 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 33 ++
drivers/net/i40e/i40e_ethdev.c | 742 ++++++++++++++++++++++++++++
drivers/net/i40e/i40e_ethdev.h | 7 +
drivers/net/i40e/i40e_fdir.c | 31 ++
lib/librte_ether/rte_eth_ctrl.h | 114 ++++-
8 files changed, 1148 insertions(+), 4 deletions(-)
--
1.9.3
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v8 1/2] i40e: RSS/FD granularity configuration
2015-11-02 14:32 4% ` [dpdk-dev] [PATCH v8 " Helin Zhang
@ 2015-11-02 14:32 5% ` Helin Zhang
2015-11-03 16:07 4% ` [dpdk-dev] [PATCH v9 0/2] " Helin Zhang
1 sibling, 0 replies; 200+ results
From: Helin Zhang @ 2015-11-02 14:32 UTC (permalink / raw)
To: dev
The default input set of fields of a received packet are loaded from
firmware, which cannot be modified even users want to use different
fields for RSS or flow director. Here adds more flexibilities of
selecting packet fields for hash calculation or flow director for
users.
Signed-off-by: Helin Zhang <helin.zhang@intel.com>
Signed-off-by: Andrey Chilikin <andrey.chilikin@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 5 +
doc/guides/rel_notes/release_2_2.rst | 2 +
drivers/net/i40e/i40e_ethdev.c | 742 +++++++++++++++++++++++++++++++++++
drivers/net/i40e/i40e_ethdev.h | 7 +
drivers/net/i40e/i40e_fdir.c | 31 ++
lib/librte_ether/rte_eth_ctrl.h | 114 +++++-
6 files changed, 897 insertions(+), 4 deletions(-)
v2 changes:
Solved the compilation issues.
v3 changes:
Support selecting more input set fields.
v4 changes:
Removed operation of 'delete', as it is not necessary.
Added FD granularity, as it is similar to RSS granularity.
v5 changes:
Fixed issue of generating wrong input set for registers on ipv6-udp and ipv6-tcp pc types.
Added clear masking operations during checking if MASK registers are opcupied or not.
Reworked several annotations.
v7 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
Moved documentation as part of this patch.
v8 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 1 to 128, as ABI changes is allowed in ethdev.
Updated release notes.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index a391ff0..a4c5b51 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -52,3 +52,8 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
+
+* ABI changes are planned in release 2.2 for macro of RTE_ETH_INSET_SIZE_MAX,
+ struct rte_eth_input_set_conf, to support selecting more input set items at
+ a time, and which will affect struct rte_eth_fdir_filter_info and
+ struct rte_eth_hash_filter_info.
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 8a20044..f42f0d4 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -59,6 +59,8 @@ New Features
* **Added port hotplug support to xenvirt.**
+* **Added RSS/FD input set granularity on Intel X710/XL710.**
+
Resolved Issues
---------------
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 8381c8e..75c368f 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -139,6 +139,142 @@
#define I40E_DEFAULT_DCB_APP_NUM 1
#define I40E_DEFAULT_DCB_APP_PRIO 3
+#define I40E_PRTQF_FD_INSET(_i, _j) (0x00250000 + ((_i) * 64 + (_j) * 32))
+#define I40E_GLQF_FD_MSK(_i, _j) (0x00267200 + ((_i) * 4 + (_j) * 8))
+#define I40E_GLQF_FD_MSK_FIELD 0x0000FFFF
+#define I40E_GLQF_HASH_INSET(_i, _j) (0x00267600 + ((_i) * 4 + (_j) * 8))
+#define I40E_GLQF_HASH_MSK(_i, _j) (0x00267A00 + ((_i) * 4 + (_j) * 8))
+#define I40E_GLQF_HASH_MSK_FIELD 0x0000FFFF
+
+#define I40E_INSET_NONE 0x00000000000000000ULL
+
+/* bit0 ~ bit 7 */
+#define I40E_INSET_DMAC 0x0000000000000001ULL
+#define I40E_INSET_SMAC 0x0000000000000002ULL
+#define I40E_INSET_VLAN_OUTER 0x0000000000000004ULL
+#define I40E_INSET_VLAN_INNER 0x0000000000000008ULL
+#define I40E_INSET_VLAN_TUNNEL 0x0000000000000010ULL
+
+/* bit 8 ~ bit 15 */
+#define I40E_INSET_IPV4_SRC 0x0000000000000100ULL
+#define I40E_INSET_IPV4_DST 0x0000000000000200ULL
+#define I40E_INSET_IPV6_SRC 0x0000000000000400ULL
+#define I40E_INSET_IPV6_DST 0x0000000000000800ULL
+#define I40E_INSET_SRC_PORT 0x0000000000001000ULL
+#define I40E_INSET_DST_PORT 0x0000000000002000ULL
+#define I40E_INSET_SCTP_VT 0x0000000000004000ULL
+
+/* bit 16 ~ bit 31 */
+#define I40E_INSET_IPV4_TOS 0x0000000000010000ULL
+#define I40E_INSET_IPV4_PROTO 0x0000000000020000ULL
+#define I40E_INSET_IPV4_TTL 0x0000000000040000ULL
+#define I40E_INSET_IPV6_TC 0x0000000000080000ULL
+#define I40E_INSET_IPV6_FLOW 0x0000000000100000ULL
+#define I40E_INSET_IPV6_NEXT_HDR 0x0000000000200000ULL
+#define I40E_INSET_IPV6_HOP_LIMIT 0x0000000000400000ULL
+#define I40E_INSET_TCP_FLAGS 0x0000000000800000ULL
+
+/* bit 32 ~ bit 47, tunnel fields */
+#define I40E_INSET_TUNNEL_IPV4_DST 0x0000000100000000ULL
+#define I40E_INSET_TUNNEL_IPV6_DST 0x0000000200000000ULL
+#define I40E_INSET_TUNNEL_DMAC 0x0000000400000000ULL
+#define I40E_INSET_TUNNEL_SRC_PORT 0x0000000800000000ULL
+#define I40E_INSET_TUNNEL_DST_PORT 0x0000001000000000ULL
+#define I40E_INSET_TUNNEL_ID 0x0000002000000000ULL
+
+/* bit 48 ~ bit 55 */
+#define I40E_INSET_LAST_ETHER_TYPE 0x0001000000000000ULL
+
+/* bit 56 ~ bit 63, Flex Payload */
+#define I40E_INSET_FLEX_PAYLOAD_W1 0x0100000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W2 0x0200000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W3 0x0400000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W4 0x0800000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W5 0x1000000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W6 0x2000000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W7 0x4000000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W8 0x8000000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD \
+ (I40E_INSET_FLEX_PAYLOAD_W1 | I40E_INSET_FLEX_PAYLOAD_W2 | \
+ I40E_INSET_FLEX_PAYLOAD_W3 | I40E_INSET_FLEX_PAYLOAD_W3 | \
+ I40E_INSET_FLEX_PAYLOAD_W5 | I40E_INSET_FLEX_PAYLOAD_W6 | \
+ I40E_INSET_FLEX_PAYLOAD_W7 | I40E_INSET_FLEX_PAYLOAD_W8)
+
+/**
+ * Below are values for writing un-exposed registers suggested
+ * by silicon experts
+ */
+/* Destination MAC address */
+#define I40E_REG_INSET_L2_DMAC 0xE000000000000000ULL
+/* Source MAC address */
+#define I40E_REG_INSET_L2_SMAC 0x1C00000000000000ULL
+/* VLAN tag in the outer L2 header */
+#define I40E_REG_INSET_L2_OUTER_VLAN 0x0000000000800000ULL
+/* VLAN tag in the inner L2 header */
+#define I40E_REG_INSET_L2_INNER_VLAN 0x0000000001000000ULL
+/* Source IPv4 address */
+#define I40E_REG_INSET_L3_SRC_IP4 0x0001800000000000ULL
+/* Destination IPv4 address */
+#define I40E_REG_INSET_L3_DST_IP4 0x0000001800000000ULL
+/* IPv4 Type of Service (TOS) */
+#define I40E_REG_INSET_L3_IP4_TOS 0x0040000000000000ULL
+/* IPv4 Protocol */
+#define I40E_REG_INSET_L3_IP4_PROTO 0x0004000000000000ULL
+/* Source IPv6 address */
+#define I40E_REG_INSET_L3_SRC_IP6 0x0007F80000000000ULL
+/* Destination IPv6 address */
+#define I40E_REG_INSET_L3_DST_IP6 0x000007F800000000ULL
+/* IPv6 Traffic Class (TC) */
+#define I40E_REG_INSET_L3_IP6_TC 0x0040000000000000ULL
+/* IPv6 Next Header */
+#define I40E_REG_INSET_L3_IP6_NEXT_HDR 0x0008000000000000ULL
+/* Source L4 port */
+#define I40E_REG_INSET_L4_SRC_PORT 0x0000000400000000ULL
+/* Destination L4 port */
+#define I40E_REG_INSET_L4_DST_PORT 0x0000000200000000ULL
+/* SCTP verification tag */
+#define I40E_REG_INSET_L4_SCTP_VERIFICATION_TAG 0x0000000180000000ULL
+/* Inner destination MAC address (MAC-in-UDP/MAC-in-GRE)*/
+#define I40E_REG_INSET_TUNNEL_L2_INNER_DST_MAC 0x0000000001C00000ULL
+/* Source port of tunneling UDP */
+#define I40E_REG_INSET_TUNNEL_L4_UDP_SRC_PORT 0x0000000000200000ULL
+/* Destination port of tunneling UDP */
+#define I40E_REG_INSET_TUNNEL_L4_UDP_DST_PORT 0x0000000000100000ULL
+/* UDP Tunneling ID, NVGRE/GRE key */
+#define I40E_REG_INSET_TUNNEL_ID 0x00000000000C0000ULL
+/* Last ether type */
+#define I40E_REG_INSET_LAST_ETHER_TYPE 0x0000000000004000ULL
+/* Tunneling outer destination IPv4 address */
+#define I40E_REG_INSET_TUNNEL_L3_DST_IP4 0x00000000000000C0ULL
+/* Tunneling outer destination IPv6 address */
+#define I40E_REG_INSET_TUNNEL_L3_DST_IP6 0x0000000000003FC0ULL
+/* 1st word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD1 0x0000000000002000ULL
+/* 2nd word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD2 0x0000000000001000ULL
+/* 3rd word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD3 0x0000000000000800ULL
+/* 4th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD4 0x0000000000000400ULL
+/* 5th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD5 0x0000000000000200ULL
+/* 6th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD6 0x0000000000000100ULL
+/* 7th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD7 0x0000000000000080ULL
+/* 8th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD8 0x0000000000000040ULL
+
+#define I40E_REG_INSET_MASK_DEFAULT 0x0000000000000000ULL
+
+#define I40E_TRANSLATE_INSET 0
+#define I40E_TRANSLATE_REG 1
+
+#define I40E_INSET_IPV4_TOS_MASK 0x0009FF00UL
+#define I40E_INSET_IPV4_PROTO_MASK 0x000DFF00UL
+#define I40E_INSET_IPV6_TC_MASK 0x0009F00FUL
+#define I40E_INSET_IPV6_NEXT_HDR_MASK 0x000C00FFUL
+
static int eth_i40e_dev_init(struct rte_eth_dev *eth_dev);
static int eth_i40e_dev_uninit(struct rte_eth_dev *eth_dev);
static int i40e_dev_configure(struct rte_eth_dev *dev);
@@ -5708,6 +5844,606 @@ out:
return 0;
}
+/**
+ * Valid input sets for hash and flow director filters per PCTYPE
+ */
+static uint64_t
+i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
+ enum rte_filter_type filter)
+{
+ uint64_t valid;
+
+ static const uint64_t valid_hash_inset_table[] = {
+ [I40E_FILTER_PCTYPE_FRAG_IPV4] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_SRC |
+ I40E_INSET_IPV4_DST | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_TCP_FLAGS | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_FRAG_IPV6] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_TUNNEL_DMAC |
+ I40E_INSET_TUNNEL_ID | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
+ I40E_INSET_DST_PORT | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
+ I40E_INSET_DST_PORT | I40E_INSET_TCP_FLAGS |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
+ I40E_INSET_DST_PORT | I40E_INSET_SCTP_VT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_L2_PAYLOAD] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_LAST_ETHER_TYPE |
+ I40E_INSET_FLEX_PAYLOAD,
+ };
+
+ /**
+ * Flow director supports only fields defined in
+ * union rte_eth_fdir_flow.
+ */
+ static const uint64_t valid_fdir_inset_table[] = {
+ [I40E_FILTER_PCTYPE_FRAG_IPV4] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_FRAG_IPV6] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_L2_PAYLOAD] =
+ I40E_INSET_LAST_ETHER_TYPE | I40E_INSET_FLEX_PAYLOAD,
+ };
+
+ if (pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD)
+ return 0;
+ if (filter == RTE_ETH_FILTER_HASH)
+ valid = valid_hash_inset_table[pctype];
+ else
+ valid = valid_fdir_inset_table[pctype];
+
+ return valid;
+}
+
+/**
+ * Validate if the input set is allowed for a specific PCTYPE
+ */
+static int
+i40e_validate_input_set(enum i40e_filter_pctype pctype,
+ enum rte_filter_type filter, uint64_t inset)
+{
+ uint64_t valid;
+
+ valid = i40e_get_valid_input_set(pctype, filter);
+ if (inset & (~valid))
+ return -EINVAL;
+
+ return 0;
+}
+
+/* default input set fields combination per pctype */
+static uint64_t
+i40e_get_default_input_set(uint16_t pctype)
+{
+ static const uint64_t default_inset_table[] = {
+ [I40E_FILTER_PCTYPE_FRAG_IPV4] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
+ [I40E_FILTER_PCTYPE_FRAG_IPV6] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+ [I40E_FILTER_PCTYPE_L2_PAYLOAD] =
+ I40E_INSET_LAST_ETHER_TYPE,
+ };
+
+ if (pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD)
+ return 0;
+
+ return default_inset_table[pctype];
+}
+
+/**
+ * Parse the input set from index to logical bit masks
+ */
+static int
+i40e_parse_input_set(uint64_t *inset,
+ enum i40e_filter_pctype pctype,
+ enum rte_eth_input_set_field *field,
+ uint16_t size)
+{
+ uint16_t i, j;
+ int ret = -EINVAL;
+
+ static const struct {
+ enum rte_eth_input_set_field field;
+ uint64_t inset;
+ } inset_convert_table[] = {
+ {RTE_ETH_INPUT_SET_NONE, I40E_INSET_NONE},
+ {RTE_ETH_INPUT_SET_L2_SRC_MAC, I40E_INSET_SMAC},
+ {RTE_ETH_INPUT_SET_L2_DST_MAC, I40E_INSET_DMAC},
+ {RTE_ETH_INPUT_SET_L2_OUTER_VLAN, I40E_INSET_VLAN_OUTER},
+ {RTE_ETH_INPUT_SET_L2_INNER_VLAN, I40E_INSET_VLAN_INNER},
+ {RTE_ETH_INPUT_SET_L2_ETHERTYPE, I40E_INSET_LAST_ETHER_TYPE},
+ {RTE_ETH_INPUT_SET_L3_SRC_IP4, I40E_INSET_IPV4_SRC},
+ {RTE_ETH_INPUT_SET_L3_DST_IP4, I40E_INSET_IPV4_DST},
+ {RTE_ETH_INPUT_SET_L3_IP4_TOS, I40E_INSET_IPV4_TOS},
+ {RTE_ETH_INPUT_SET_L3_IP4_PROTO, I40E_INSET_IPV4_PROTO},
+ {RTE_ETH_INPUT_SET_L3_SRC_IP6, I40E_INSET_IPV6_SRC},
+ {RTE_ETH_INPUT_SET_L3_DST_IP6, I40E_INSET_IPV6_DST},
+ {RTE_ETH_INPUT_SET_L3_IP6_TC, I40E_INSET_IPV6_TC},
+ {RTE_ETH_INPUT_SET_L3_IP6_NEXT_HEADER,
+ I40E_INSET_IPV6_NEXT_HDR},
+ {RTE_ETH_INPUT_SET_L4_UDP_SRC_PORT, I40E_INSET_SRC_PORT},
+ {RTE_ETH_INPUT_SET_L4_TCP_SRC_PORT, I40E_INSET_SRC_PORT},
+ {RTE_ETH_INPUT_SET_L4_SCTP_SRC_PORT, I40E_INSET_SRC_PORT},
+ {RTE_ETH_INPUT_SET_L4_UDP_DST_PORT, I40E_INSET_DST_PORT},
+ {RTE_ETH_INPUT_SET_L4_TCP_DST_PORT, I40E_INSET_DST_PORT},
+ {RTE_ETH_INPUT_SET_L4_SCTP_DST_PORT, I40E_INSET_DST_PORT},
+ {RTE_ETH_INPUT_SET_L4_SCTP_VERIFICATION_TAG,
+ I40E_INSET_SCTP_VT},
+ {RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_DST_MAC,
+ I40E_INSET_TUNNEL_DMAC},
+ {RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_VLAN,
+ I40E_INSET_VLAN_TUNNEL},
+ {RTE_ETH_INPUT_SET_TUNNEL_L4_UDP_KEY,
+ I40E_INSET_TUNNEL_ID},
+ {RTE_ETH_INPUT_SET_TUNNEL_GRE_KEY, I40E_INSET_TUNNEL_ID},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_1ST_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W1},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_2ND_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W2},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_3RD_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W3},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_4TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W4},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_5TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W5},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_6TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W6},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_7TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W7},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_8TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W8},
+ };
+
+ if (!inset || !field || size > RTE_ETH_INSET_SIZE_MAX)
+ return ret;
+
+ /* Only one item allowed for default or all */
+ if (size == 1) {
+ if (field[0] == RTE_ETH_INPUT_SET_DEFAULT) {
+ *inset = i40e_get_default_input_set(pctype);
+ return 0;
+ } else if (field[0] == RTE_ETH_INPUT_SET_NONE) {
+ *inset = I40E_INSET_NONE;
+ return 0;
+ }
+ }
+
+ for (i = 0, *inset = 0; i < size; i++) {
+ for (j = 0; j < RTE_DIM(inset_convert_table); j++) {
+ if (field[i] == inset_convert_table[j].field) {
+ *inset |= inset_convert_table[j].inset;
+ break;
+ }
+ }
+
+ /* It contains unsupported input set, return immediately */
+ if (j == RTE_DIM(inset_convert_table))
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * Translate the input set from bit masks to register aware bit masks
+ * and vice versa
+ */
+static uint64_t
+i40e_translate_input_set_reg(uint64_t input)
+{
+ uint64_t val = 0;
+ uint16_t i;
+
+ static const struct {
+ uint64_t inset;
+ uint64_t inset_reg;
+ } inset_map[] = {
+ {I40E_INSET_DMAC, I40E_REG_INSET_L2_DMAC},
+ {I40E_INSET_SMAC, I40E_REG_INSET_L2_SMAC},
+ {I40E_INSET_VLAN_OUTER, I40E_REG_INSET_L2_OUTER_VLAN},
+ {I40E_INSET_VLAN_INNER, I40E_REG_INSET_L2_INNER_VLAN},
+ {I40E_INSET_LAST_ETHER_TYPE, I40E_REG_INSET_LAST_ETHER_TYPE},
+ {I40E_INSET_IPV4_SRC, I40E_REG_INSET_L3_SRC_IP4},
+ {I40E_INSET_IPV4_DST, I40E_REG_INSET_L3_DST_IP4},
+ {I40E_INSET_IPV4_TOS, I40E_REG_INSET_L3_IP4_TOS},
+ {I40E_INSET_IPV4_PROTO, I40E_REG_INSET_L3_IP4_PROTO},
+ {I40E_INSET_IPV6_SRC, I40E_REG_INSET_L3_SRC_IP6},
+ {I40E_INSET_IPV6_DST, I40E_REG_INSET_L3_DST_IP6},
+ {I40E_INSET_IPV6_TC, I40E_REG_INSET_L3_IP6_TC},
+ {I40E_INSET_IPV6_NEXT_HDR, I40E_REG_INSET_L3_IP6_NEXT_HDR},
+ {I40E_INSET_SRC_PORT, I40E_REG_INSET_L4_SRC_PORT},
+ {I40E_INSET_DST_PORT, I40E_REG_INSET_L4_DST_PORT},
+ {I40E_INSET_SCTP_VT, I40E_REG_INSET_L4_SCTP_VERIFICATION_TAG},
+ {I40E_INSET_TUNNEL_ID, I40E_REG_INSET_TUNNEL_ID},
+ {I40E_INSET_TUNNEL_DMAC,
+ I40E_REG_INSET_TUNNEL_L2_INNER_DST_MAC},
+ {I40E_INSET_TUNNEL_IPV4_DST, I40E_REG_INSET_TUNNEL_L3_DST_IP4},
+ {I40E_INSET_TUNNEL_IPV6_DST, I40E_REG_INSET_TUNNEL_L3_DST_IP6},
+ {I40E_INSET_TUNNEL_SRC_PORT,
+ I40E_REG_INSET_TUNNEL_L4_UDP_SRC_PORT},
+ {I40E_INSET_TUNNEL_DST_PORT,
+ I40E_REG_INSET_TUNNEL_L4_UDP_DST_PORT},
+ {I40E_INSET_TUNNEL_ID, I40E_REG_INSET_TUNNEL_ID},
+ {I40E_INSET_FLEX_PAYLOAD_W1, I40E_REG_INSET_FLEX_PAYLOAD_WORD1},
+ {I40E_INSET_FLEX_PAYLOAD_W2, I40E_REG_INSET_FLEX_PAYLOAD_WORD2},
+ {I40E_INSET_FLEX_PAYLOAD_W3, I40E_REG_INSET_FLEX_PAYLOAD_WORD3},
+ {I40E_INSET_FLEX_PAYLOAD_W4, I40E_REG_INSET_FLEX_PAYLOAD_WORD4},
+ {I40E_INSET_FLEX_PAYLOAD_W5, I40E_REG_INSET_FLEX_PAYLOAD_WORD5},
+ {I40E_INSET_FLEX_PAYLOAD_W6, I40E_REG_INSET_FLEX_PAYLOAD_WORD6},
+ {I40E_INSET_FLEX_PAYLOAD_W7, I40E_REG_INSET_FLEX_PAYLOAD_WORD7},
+ {I40E_INSET_FLEX_PAYLOAD_W8, I40E_REG_INSET_FLEX_PAYLOAD_WORD8},
+ };
+
+ if (input == 0)
+ return val;
+
+ /* Translate input set to register aware inset */
+ for (i = 0; i < RTE_DIM(inset_map); i++) {
+ if (input & inset_map[i].inset)
+ val |= inset_map[i].inset_reg;
+ }
+
+ return val;
+}
+
+static uint8_t
+i40e_generate_inset_mask_reg(uint64_t inset, uint32_t *mask, uint8_t nb_elem)
+{
+ uint8_t i, idx = 0;
+
+ static const struct {
+ uint64_t inset;
+ uint32_t mask;
+ } inset_mask_map[] = {
+ {I40E_INSET_IPV4_TOS, I40E_INSET_IPV4_TOS_MASK},
+ {I40E_INSET_IPV4_PROTO, I40E_INSET_IPV4_PROTO_MASK},
+ {I40E_INSET_IPV6_TC, I40E_INSET_IPV6_TC_MASK},
+ {I40E_INSET_IPV6_NEXT_HDR, I40E_INSET_IPV6_NEXT_HDR_MASK},
+ };
+
+ if (!inset || !mask || !nb_elem)
+ return 0;
+
+ if (!inset && nb_elem >= I40E_INSET_MASK_NUM_REG) {
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++)
+ mask[i] = 0;
+ return I40E_INSET_MASK_NUM_REG;
+ }
+
+ for (i = 0, idx = 0; i < RTE_DIM(inset_mask_map); i++) {
+ if (idx >= nb_elem)
+ break;
+ if (inset & inset_mask_map[i].inset) {
+ mask[idx] = inset_mask_map[i].mask;
+ idx++;
+ }
+ }
+
+ return idx;
+}
+
+static uint64_t
+i40e_get_reg_inset(struct i40e_hw *hw, enum rte_filter_type filter,
+ enum i40e_filter_pctype pctype)
+{
+ uint64_t reg = 0;
+
+ if (filter == RTE_ETH_FILTER_HASH) {
+ reg = I40E_READ_REG(hw, I40E_GLQF_HASH_INSET(1, pctype));
+ reg <<= I40E_32_BIT_WIDTH;
+ reg |= I40E_READ_REG(hw, I40E_GLQF_HASH_INSET(0, pctype));
+ } else if (filter == RTE_ETH_FILTER_FDIR) {
+ reg = I40E_READ_REG(hw, I40E_PRTQF_FD_INSET(pctype, 1));
+ reg <<= I40E_32_BIT_WIDTH;
+ reg |= I40E_READ_REG(hw, I40E_PRTQF_FD_INSET(pctype, 0));
+ }
+
+ return reg;
+}
+
+static void
+i40e_check_write_reg(struct i40e_hw *hw, uint32_t addr, uint32_t val)
+{
+ uint32_t reg = I40E_READ_REG(hw, addr);
+
+ PMD_DRV_LOG(DEBUG, "[0x%08x] original: 0x%08x\n", addr, reg);
+ if (reg != val)
+ I40E_WRITE_REG(hw, addr, val);
+ PMD_DRV_LOG(DEBUG, "[0x%08x] after: 0x%08x\n", addr,
+ (uint32_t)I40E_READ_REG(hw, addr));
+}
+
+static int
+i40e_set_hash_inset_mask(struct i40e_hw *hw,
+ enum i40e_filter_pctype pctype,
+ enum rte_filter_input_set_op op,
+ uint32_t *mask_reg,
+ uint8_t num)
+{
+ uint32_t reg;
+ uint8_t i;
+
+ if (!mask_reg || num > RTE_ETH_INPUT_SET_SELECT)
+ return -EINVAL;
+
+ if (op == RTE_ETH_INPUT_SET_SELECT) {
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+ 0);
+ if (i >= num)
+ continue;
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+ mask_reg[i]);
+ }
+ } else if (op == RTE_ETH_INPUT_SET_ADD) {
+ uint8_t j, count = 0;
+
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
+ reg = I40E_READ_REG(hw, I40E_GLQF_HASH_MSK(i, pctype));
+ if (reg & I40E_GLQF_HASH_MSK_FIELD)
+ count++;
+ }
+ if (count + num > I40E_INSET_MASK_NUM_REG)
+ return -EINVAL;
+
+ for (i = count, j = 0; i < I40E_INSET_MASK_NUM_REG; i++, j++)
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+ mask_reg[j]);
+ }
+
+ return 0;
+}
+
+static int
+i40e_set_fd_inset_mask(struct i40e_hw *hw,
+ enum i40e_filter_pctype pctype,
+ enum rte_filter_input_set_op op,
+ uint32_t *mask_reg,
+ uint8_t num)
+{
+ uint32_t reg;
+ uint8_t i;
+
+ if (!mask_reg || num > RTE_ETH_INPUT_SET_SELECT)
+ return -EINVAL;
+
+ if (op == RTE_ETH_INPUT_SET_SELECT) {
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
+ i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+ 0);
+ if (i >= num)
+ continue;
+ i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+ mask_reg[i]);
+ }
+ } else if (op == RTE_ETH_INPUT_SET_ADD) {
+ uint8_t j, count = 0;
+
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
+ reg = I40E_READ_REG(hw, I40E_GLQF_FD_MSK(i, pctype));
+ if (reg & I40E_GLQF_FD_MSK_FIELD)
+ count++;
+ }
+ if (count + num > I40E_INSET_MASK_NUM_REG)
+ return -EINVAL;
+
+ for (i = count, j = 0; i < I40E_INSET_MASK_NUM_REG; i++, j++)
+ i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+ mask_reg[j]);
+ }
+
+ return 0;
+}
+
+int
+i40e_filter_inset_select(struct i40e_hw *hw,
+ struct rte_eth_input_set_conf *conf,
+ enum rte_filter_type filter)
+{
+ enum i40e_filter_pctype pctype;
+ uint64_t inset_reg = 0, input_set;
+ uint32_t mask_reg[I40E_INSET_MASK_NUM_REG];
+ uint8_t num;
+ int ret;
+
+ if (!hw || !conf) {
+ PMD_DRV_LOG(ERR, "Invalid pointer");
+ return -EFAULT;
+ }
+
+ pctype = i40e_flowtype_to_pctype(conf->flow_type);
+ if (pctype == 0 || pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD) {
+ PMD_DRV_LOG(ERR, "Not supported flow type (%u)",
+ conf->flow_type);
+ return -EINVAL;
+ }
+ if (filter != RTE_ETH_FILTER_HASH && filter != RTE_ETH_FILTER_FDIR) {
+ PMD_DRV_LOG(ERR, "Not supported filter type (%u)", filter);
+ return -EINVAL;
+ }
+
+ ret = i40e_parse_input_set(&input_set, pctype, conf->field,
+ conf->inset_size);
+ if (ret) {
+ PMD_DRV_LOG(ERR, "Failed to parse input set");
+ return -EINVAL;
+ }
+ if (i40e_validate_input_set(pctype, filter, input_set) != 0) {
+ PMD_DRV_LOG(ERR, "Invalid input set");
+ return -EINVAL;
+ }
+
+ if (conf->op == RTE_ETH_INPUT_SET_ADD) {
+ inset_reg |= i40e_get_reg_inset(hw, filter, pctype);
+ } else if (conf->op != RTE_ETH_INPUT_SET_SELECT) {
+ PMD_DRV_LOG(ERR, "Unsupported input set operation");
+ return -EINVAL;
+ }
+ num = i40e_generate_inset_mask_reg(input_set, mask_reg,
+ I40E_INSET_MASK_NUM_REG);
+ inset_reg |= i40e_translate_input_set_reg(input_set);
+
+ if (filter == RTE_ETH_FILTER_HASH) {
+ ret = i40e_set_hash_inset_mask(hw, pctype, conf->op, mask_reg,
+ num);
+ if (ret)
+ return -EINVAL;
+
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_INSET(0, pctype),
+ (uint32_t)(inset_reg & UINT32_MAX));
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_INSET(1, pctype),
+ (uint32_t)((inset_reg >>
+ I40E_32_BIT_WIDTH) & UINT32_MAX));
+ } else if (filter == RTE_ETH_FILTER_FDIR) {
+ ret = i40e_set_fd_inset_mask(hw, pctype, conf->op, mask_reg,
+ num);
+ if (ret)
+ return -EINVAL;
+
+ i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 0),
+ (uint32_t)(inset_reg & UINT32_MAX));
+ i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 1),
+ (uint32_t)((inset_reg >>
+ I40E_32_BIT_WIDTH) & UINT32_MAX));
+ } else {
+ PMD_DRV_LOG(ERR, "Not supported filter type (%u)", filter);
+ return -EINVAL;
+ }
+ I40E_WRITE_FLUSH(hw);
+
+ return 0;
+}
+
static int
i40e_hash_filter_get(struct i40e_hw *hw, struct rte_eth_hash_filter_info *info)
{
@@ -5755,6 +6491,12 @@ i40e_hash_filter_set(struct i40e_hw *hw, struct rte_eth_hash_filter_info *info)
ret = i40e_set_hash_filter_global_config(hw,
&(info->info.global_conf));
break;
+ case RTE_ETH_HASH_FILTER_INPUT_SET_SELECT:
+ ret = i40e_filter_inset_select(hw,
+ &(info->info.input_set_conf),
+ RTE_ETH_FILTER_HASH);
+ break;
+
default:
PMD_DRV_LOG(ERR, "Hash filter info type (%d) not supported",
info->info_type);
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 062878b..fe79030 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -107,6 +107,7 @@ enum i40e_flxpld_layer_idx {
#define I40E_FDIR_BITMASK_NUM_WORD 2 /* max number of bitmask words */
#define I40E_FDIR_MAX_FLEXWORD_NUM 8 /* max number of flexpayload words */
#define I40E_FDIR_MAX_FLEX_LEN 16 /* len in bytes of flex payload */
+#define I40E_INSET_MASK_NUM_REG 2 /* number of input set mask registers */
/* i40e flags */
#define I40E_FLAG_RSS (1ULL << 0)
@@ -538,6 +539,12 @@ uint16_t i40e_pctype_to_flowtype(enum i40e_filter_pctype pctype);
int i40e_fdir_ctrl_func(struct rte_eth_dev *dev,
enum rte_filter_op filter_op,
void *arg);
+int i40e_select_filter_input_set(struct i40e_hw *hw,
+ struct rte_eth_input_set_conf *conf,
+ enum rte_filter_type filter);
+int i40e_filter_inset_select(struct i40e_hw *hw,
+ struct rte_eth_input_set_conf *conf,
+ enum rte_filter_type filter);
void i40e_rxq_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
struct rte_eth_rxq_info *qinfo);
diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c
index c9ce98f..ba18c9d 100644
--- a/drivers/net/i40e/i40e_fdir.c
+++ b/drivers/net/i40e/i40e_fdir.c
@@ -1342,6 +1342,33 @@ i40e_fdir_stats_get(struct rte_eth_dev *dev, struct rte_eth_fdir_stats *stat)
I40E_PFQF_FDSTAT_BEST_CNT_SHIFT);
}
+static int
+i40e_fdir_filter_set(struct rte_eth_dev *dev,
+ struct rte_eth_hash_filter_info *info)
+{
+ struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+ struct i40e_hw *hw = I40E_PF_TO_HW(pf);
+ int ret = 0;
+
+ if (!info) {
+ PMD_DRV_LOG(ERR, "Invalid pointer");
+ return -EFAULT;
+ }
+
+ switch (info->info_type) {
+ case RTE_ETH_FDIR_FILTER_INPUT_SET_SELECT:
+ ret = i40e_filter_inset_select(hw,
+ &(info->info.input_set_conf), RTE_ETH_FILTER_FDIR);
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "FD filter info type (%d) not supported",
+ info->info_type);
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
/*
* i40e_fdir_ctrl_func - deal with all operations on flow director.
* @pf: board private structure
@@ -1382,6 +1409,10 @@ i40e_fdir_ctrl_func(struct rte_eth_dev *dev,
case RTE_ETH_FILTER_INFO:
i40e_fdir_info_get(dev, (struct rte_eth_fdir_info *)arg);
break;
+ case RTE_ETH_FILTER_SET:
+ ret = i40e_fdir_filter_set(dev,
+ (struct rte_eth_hash_filter_info *)arg);
+ break;
case RTE_ETH_FILTER_STATS:
i40e_fdir_stats_get(dev, (struct rte_eth_fdir_stats *)arg);
break;
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 770c76c..ae73c36 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -295,7 +295,84 @@ struct rte_eth_tunnel_filter_conf {
uint16_t queue_id; /** < queue number. */
};
-#define RTE_ETH_FDIR_MAX_FLEXLEN 16 /** < Max length of flexbytes. */
+#define RTE_ETH_FDIR_MAX_FLEXLEN 16 /** < Max length of flexbytes. */
+#define RTE_ETH_INSET_SIZE_MAX 128 /** < Max length of input set. */
+
+/**
+ * Input set fields for Flow Director and Hash filters
+ */
+enum rte_eth_input_set_field {
+ RTE_ETH_INPUT_SET_UNKNOWN = 0,
+
+ /* L2 */
+ RTE_ETH_INPUT_SET_L2_SRC_MAC = 1,
+ RTE_ETH_INPUT_SET_L2_DST_MAC,
+ RTE_ETH_INPUT_SET_L2_OUTER_VLAN,
+ RTE_ETH_INPUT_SET_L2_INNER_VLAN,
+ RTE_ETH_INPUT_SET_L2_ETHERTYPE,
+
+ /* L3 */
+ RTE_ETH_INPUT_SET_L3_SRC_IP4 = 129,
+ RTE_ETH_INPUT_SET_L3_DST_IP4,
+ RTE_ETH_INPUT_SET_L3_SRC_IP6,
+ RTE_ETH_INPUT_SET_L3_DST_IP6,
+ RTE_ETH_INPUT_SET_L3_IP4_TOS,
+ RTE_ETH_INPUT_SET_L3_IP4_PROTO,
+ RTE_ETH_INPUT_SET_L3_IP6_TC,
+ RTE_ETH_INPUT_SET_L3_IP6_NEXT_HEADER,
+
+ /* L4 */
+ RTE_ETH_INPUT_SET_L4_UDP_SRC_PORT = 257,
+ RTE_ETH_INPUT_SET_L4_UDP_DST_PORT,
+ RTE_ETH_INPUT_SET_L4_TCP_SRC_PORT,
+ RTE_ETH_INPUT_SET_L4_TCP_DST_PORT,
+ RTE_ETH_INPUT_SET_L4_SCTP_SRC_PORT,
+ RTE_ETH_INPUT_SET_L4_SCTP_DST_PORT,
+ RTE_ETH_INPUT_SET_L4_SCTP_VERIFICATION_TAG,
+
+ /* Tunnel */
+ RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_DST_MAC = 385,
+ RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_SRC_MAC,
+ RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_VLAN,
+ RTE_ETH_INPUT_SET_TUNNEL_L4_UDP_KEY,
+ RTE_ETH_INPUT_SET_TUNNEL_GRE_KEY,
+
+ /* Flexible Payload */
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_1ST_WORD = 641,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_2ND_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_3RD_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_4TH_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_5TH_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_6TH_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_7TH_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_8TH_WORD,
+
+ RTE_ETH_INPUT_SET_DEFAULT = 65533,
+ RTE_ETH_INPUT_SET_NONE = 65534,
+ RTE_ETH_INPUT_SET_MAX = 65535,
+};
+
+/**
+ * Filters input set operations
+ */
+enum rte_filter_input_set_op {
+ RTE_ETH_INPUT_SET_OP_UNKNOWN,
+ RTE_ETH_INPUT_SET_SELECT, /**< select input set */
+ RTE_ETH_INPUT_SET_ADD, /**< add input set entry */
+ RTE_ETH_INPUT_SET_OP_MAX
+};
+
+
+/**
+ * A structure used to define the input set configuration for
+ * flow director and hash filters
+ */
+struct rte_eth_input_set_conf {
+ uint16_t flow_type;
+ uint16_t inset_size;
+ enum rte_eth_input_set_field field[RTE_ETH_INSET_SIZE_MAX];
+ enum rte_filter_input_set_op op;
+};
/**
* A structure used to define the input for L2 flow
@@ -535,7 +612,7 @@ struct rte_eth_fdir_flex_mask {
/**
* A structure used to define all flexible payload related setting
- * include flexpay load and flex mask
+ * include flex payload and flex mask
*/
struct rte_eth_fdir_flex_conf {
uint16_t nb_payloads; /**< The number of following payload cfg */
@@ -615,12 +692,37 @@ struct rte_eth_fdir_stats {
};
/**
+ * Flow Director filter information types.
+ */
+enum rte_eth_fdir_filter_info_type {
+ RTE_ETH_FDIR_FILTER_INFO_TYPE_UNKNOWN = 0,
+ /** Flow Director filter input set configuration */
+ RTE_ETH_FDIR_FILTER_INPUT_SET_SELECT,
+ RTE_ETH_FDIR_FILTER_INFO_TYPE_MAX,
+};
+
+/**
+ * A structure used to set FDIR filter information, to support filter type
+ * of 'RTE_ETH_FILTER_FDIR' RTE_ETH_FDIR_FILTER_INPUT_SET_SELECT operation.
+ */
+struct rte_eth_fdir_filter_info {
+ enum rte_eth_fdir_filter_info_type info_type; /**< Information type */
+ /** Details of fdir filter information */
+ union {
+ /** Flow Director input set configuration per port */
+ struct rte_eth_input_set_conf input_set_conf;
+ } info;
+};
+
+/**
* Hash filter information types.
* - RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT is for getting/setting the
* information/configuration of 'symmetric hash enable' per port.
* - RTE_ETH_HASH_FILTER_GLOBAL_CONFIG is for getting/setting the global
* configurations of hash filters. Those global configurations are valid
* for all ports of the same NIC.
+ * - RTE_ETH_HASH_FILTER_INPUT_SET_SELECT is for setting the global
+ * hash input set fields
*/
enum rte_eth_hash_filter_info_type {
RTE_ETH_HASH_FILTER_INFO_TYPE_UNKNOWN = 0,
@@ -628,6 +730,8 @@ enum rte_eth_hash_filter_info_type {
RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT,
/** Configure globally for hash filter */
RTE_ETH_HASH_FILTER_GLOBAL_CONFIG,
+ /** Global Hash filter input set configuration */
+ RTE_ETH_HASH_FILTER_INPUT_SET_SELECT,
RTE_ETH_HASH_FILTER_INFO_TYPE_MAX,
};
@@ -647,7 +751,7 @@ enum rte_eth_hash_function {
* A structure used to set or get global hash function configurations which
* include symmetric hash enable per flow type and hash function type.
* Each bit in sym_hash_enable_mask[] indicates if the symmetric hash of the
- * coresponding flow type is enabled or not.
+ * corresponding flow type is enabled or not.
* Each bit in valid_bit_mask[] indicates if the corresponding bit in
* sym_hash_enable_mask[] is valid or not. For the configurations gotten, it
* also means if the flow type is supported by hardware or not.
@@ -672,6 +776,8 @@ struct rte_eth_hash_filter_info {
uint8_t enable;
/** Global configurations of hash filter */
struct rte_eth_hash_global_conf global_conf;
+ /** Global configurations of hash filter input set */
+ struct rte_eth_input_set_conf input_set_conf;
} info;
};
--
1.9.3
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v2] mk: fix ABI versioning compile error for combined shared library
2015-11-02 10:20 4% ` Ferruh Yigit
@ 2015-11-02 15:23 4% ` Ferruh Yigit
2015-11-02 16:26 4% ` Thomas Monjalon
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Ferruh Yigit @ 2015-11-02 15:23 UTC (permalink / raw)
To: dev; +Cc: Eric Kinzie
Fixes following error:
LD libdpdk.so
/usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
for symbol <function>@DPDK_x.y
Defines version symbols in a fixed path libdpdk.map file and this
value hardcoded into makefile
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
drivers/net/Makefile | 3 +++
lib/Makefile | 3 +++
lib/libdpdk.map | 12 ++++++++++++
mk/rte.sdkbuild.mk | 2 +-
mk/rte.sharelib.mk | 1 +
5 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 lib/libdpdk.map
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 6da1ce2..d30018c 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -50,5 +50,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
+ifeq ($(COMBINED_BUILD),1)
include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/lib/Makefile b/lib/Makefile
index 9727b83..33d76a6 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -62,5 +62,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
endif
+ifeq ($(COMBINED_BUILD),1)
include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/lib/libdpdk.map b/lib/libdpdk.map
new file mode 100644
index 0000000..3988a3f
--- /dev/null
+++ b/lib/libdpdk.map
@@ -0,0 +1,12 @@
+DPDK_2.0 {
+
+};
+
+DPDK_2.1 {
+
+} DPDK_2.0;
+
+DPDK_2.2 {
+
+} DPDK_2.1;
+
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 38ec7bd..d4e3abf 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -94,7 +94,7 @@ $(ROOTDIRS-y):
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
@if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
- $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
+ COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
fi
%_clean:
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
index 7bb7219..1f71fcb 100644
--- a/mk/rte.sharelib.mk
+++ b/mk/rte.sharelib.mk
@@ -40,6 +40,7 @@ LIB_ONE := lib$(RTE_LIBNAME).so
else
LIB_ONE := lib$(RTE_LIBNAME).a
endif
+CPU_LDFLAGS += --version-script=$(SRCDIR)/lib/libdpdk.map
endif
.PHONY:sharelib
--
1.9.3
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] mk: fix ABI versioning compile error for combined shared library
2015-11-02 15:23 4% ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
@ 2015-11-02 16:26 4% ` Thomas Monjalon
2015-11-02 19:18 4% ` Ferruh Yigit
2015-11-03 7:06 4% ` Panu Matilainen
2015-11-06 13:58 7% ` [dpdk-dev] [PATCH] " Ferruh Yigit
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-02 16:26 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, Eric Kinzie
2015-11-02 15:23, Ferruh Yigit:
> +ifeq ($(COMBINED_BUILD),1)
> include $(RTE_SDK)/mk/rte.sharelib.mk
> +endif
Why this ifeq?
rte.sharelib.mk is always used for combined lib.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine
2015-11-02 10:23 3% ` [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine Panu Matilainen
@ 2015-11-02 16:42 0% ` Eric Kinzie
2015-11-03 6:48 4% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Eric Kinzie @ 2015-11-02 16:42 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Eric Kinzie
On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
> On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
> >2015-10-19 08:36, Eric Kinzie:
> >> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER
> >> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
> >> functions.
> >[...]
> >>+VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
> >[...]
> >>+BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
> >>+MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \
> >>+ bond_mode_8023ad_setup_v22);
> >
> >I'm sorry it doesn't work well when trying to build a combined lib:
> >
> >ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2
> >
> >The symbols are OK in the .o file:
> >0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2
> >0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0
> >0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20
> >0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22
> >0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
> >
> >I don't understand the problem and I am considering disabling versioning in
> >combined library.
> >
> >Any idea?
> >
>
> The .map additions look incorrect to me:
>
> >diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
> >index 22bd920..7f78717 100644
> >--- a/drivers/net/bonding/rte_eth_bond_version.map
> >+++ b/drivers/net/bonding/rte_eth_bond_version.map
> >@@ -17,6 +17,9 @@ DPDK_2.0 {
> > rte_eth_bond_slaves_get;
> > rte_eth_bond_xmit_policy_get;
> > rte_eth_bond_xmit_policy_set;
> >+ rte_eth_bond_8023ad_ext_collect;
> >+ rte_eth_bond_8023ad_ext_distrib;
> >+ rte_eth_bond_8023ad_ext_slowtx;
>
> These symbols didn't exist in DPDK 2.0 but are only being added
> here. So why are they being added to the 2.0 section?
Yes, I think these should probably be moved.
> >
> > local: *;
> > };
> >@@ -27,3 +30,10 @@ DPDK_2.1 {
> > rte_eth_bond_free;
> >
> > } DPDK_2.0;
> >+
> >+DPDK_2.2 {
> >+ local
> >+
> >+ bond_mode_8023ad_conf_get;
> >+ bond_mode_8023ad_setup;
> >+} DPDK_2.1;
>
> These are marked local, as in, "not exported" which doesn't seem
> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
> the symbol export map should look like here:
These were not exported to begin with. But after versioning these
functions, they are exported unless explicitly declared to be local here.
> DPDK_2.2 {
> global:
>
> rte_eth_bond_8023ad_ext_collect;
> rte_eth_bond_8023ad_ext_distrib;
> rte_eth_bond_8023ad_ext_slowtx;
> rte_eth_bond_mode_8023ad_conf_get;
> rte_eth_bond_mode_8023ad_setup;
> } DPDK_2.1;
>
> That said, problems with symbol versioning and the combined library
> were predicted from the start, once the individual library versions
> start advancing. For one, the combined library itself is not
> versioned at all it is offending the ABI policy all the time.
>
> Replacing the library with a linker script, as suggested before by
> Neil Horman and Sergio Gonzales Monroy would eliminate these
> problems.
>
> - Panu -
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: fix ABI versioning compile error for combined shared library
2015-11-02 16:26 4% ` Thomas Monjalon
@ 2015-11-02 19:18 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2015-11-02 19:18 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Eric Kinzie
On Mon, Nov 02, 2015 at 05:26:21PM +0100, Thomas Monjalon wrote:
> 2015-11-02 15:23, Ferruh Yigit:
> > +ifeq ($(COMBINED_BUILD),1)
> > include $(RTE_SDK)/mk/rte.sharelib.mk
> > +endif
>
> Why this ifeq?
> rte.sharelib.mk is always used for combined lib.
>
When combine lib config selected, other libraries still build
And all libraris include sharelib.mk
This cause CPU_LDFLAGS conflict, the CPU_LDFLAGS set specially for combined lib used by all libraries.
When not linking combined library, there is no need/benefit of including sharelib.mk
COMBINED_BUILD only set when linking combined library and that is when sharelib.mk included
I can try to prevent linking other libraries when combined library enabled, then sharelib.mk included only for combined lib, and we can remove that check.
But I am not sure how hard it is, and does it worth spending extra effort to it?
Thanks,
ferruh
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 14/15] mk: Introduce ARMv7 architecture
@ 2015-11-02 23:47 3% ` Jan Viktorin
0 siblings, 0 replies; 200+ results
From: Jan Viktorin @ 2015-11-02 23:47 UTC (permalink / raw)
To: david.marchand, David Hunt, Thomas Monjalon, Jerin Jacob
Cc: Vlastimil Kosar, dev
From: Vlastimil Kosar <kosar@rehivetech.com>
Make DPDK run on ARMv7-A architecture. This patch assumes
ARM Cortex-A9. However, it is known to be working on Cortex-A7
and Cortex-A15.
Signed-off-by: Vlastimil Kosar <kosar@rehivetech.com>
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
---
v2:
* the -mtune parameter of GCC is configurable now
* the -mfpu=neon can be turned off
v3: XMM_SIZE is defined in rte_vect.h in a following patch
v4:
* update release notes for 2.2
* get rid of CONFIG_RTE_BITMAP_OPTIMIZATIONS=0 setting
* rename arm defconfig: "armv7-a" -> "arvm7a"
* disable pipeline and table modules unless lpm is fixed
---
config/defconfig_arm-armv7a-linuxapp-gcc | 76 ++++++++++++++++++++++++++++++++
doc/guides/rel_notes/release_2_2.rst | 5 +++
mk/arch/arm/rte.vars.mk | 39 ++++++++++++++++
mk/machine/armv7-a/rte.vars.mk | 67 ++++++++++++++++++++++++++++
4 files changed, 187 insertions(+)
create mode 100644 config/defconfig_arm-armv7a-linuxapp-gcc
create mode 100644 mk/arch/arm/rte.vars.mk
create mode 100644 mk/machine/armv7-a/rte.vars.mk
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc
new file mode 100644
index 0000000..82143af
--- /dev/null
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -0,0 +1,76 @@
+# BSD LICENSE
+#
+# Copyright (C) 2015 RehiveTech. All right 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 RehiveTech nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+#include "common_linuxapp"
+
+CONFIG_RTE_MACHINE="armv7-a"
+
+CONFIG_RTE_ARCH="arm"
+CONFIG_RTE_ARCH_ARM=y
+CONFIG_RTE_ARCH_ARMv7=y
+CONFIG_RTE_ARCH_ARM_TUNE="cortex-a9"
+CONFIG_RTE_ARCH_ARM_NEON=y
+
+CONFIG_RTE_FORCE_INTRINSICS=y
+
+CONFIG_RTE_TOOLCHAIN="gcc"
+CONFIG_RTE_TOOLCHAIN_GCC=y
+
+# ARM doesn't have support for vmware TSC map
+CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
+
+# KNI is not supported on 32-bit
+CONFIG_RTE_LIBRTE_KNI=n
+
+# PCI is usually not used on ARM
+CONFIG_RTE_EAL_IGB_UIO=n
+
+# fails to compile on ARM
+CONFIG_RTE_LIBRTE_ACL=n
+CONFIG_RTE_LIBRTE_LPM=n
+CONFIG_RTE_LIBRTE_TABLE=n
+CONFIG_RTE_LIBRTE_PIPELINE=n
+
+# cannot use those on ARM
+CONFIG_RTE_KNI_KMOD=n
+CONFIG_RTE_LIBRTE_EM_PMD=n
+CONFIG_RTE_LIBRTE_IGB_PMD=n
+CONFIG_RTE_LIBRTE_CXGBE_PMD=n
+CONFIG_RTE_LIBRTE_E1000_PMD=n
+CONFIG_RTE_LIBRTE_ENIC_PMD=n
+CONFIG_RTE_LIBRTE_FM10K_PMD=n
+CONFIG_RTE_LIBRTE_I40E_PMD=n
+CONFIG_RTE_LIBRTE_IXGBE_PMD=n
+CONFIG_RTE_LIBRTE_MLX4_PMD=n
+CONFIG_RTE_LIBRTE_MPIPE_PMD=n
+CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
+CONFIG_RTE_LIBRTE_VMXNET3_PMD=n
+CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
+CONFIG_RTE_LIBRTE_PMD_BNX2X=n
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index be6f827..43a3a3c 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -23,6 +23,11 @@ New Features
* **Added vhost-user multiple queue support.**
+* **Introduce ARMv7 architecture**
+
+ It is now possible to build DPDK for the ARMv7 platform and test with
+ virtual PMD drivers.
+
Resolved Issues
---------------
diff --git a/mk/arch/arm/rte.vars.mk b/mk/arch/arm/rte.vars.mk
new file mode 100644
index 0000000..df0c043
--- /dev/null
+++ b/mk/arch/arm/rte.vars.mk
@@ -0,0 +1,39 @@
+# BSD LICENSE
+#
+# Copyright (C) 2015 RehiveTech. 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 RehiveTech nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+ARCH ?= arm
+CROSS ?=
+
+CPU_CFLAGS ?= -marm -DRTE_CACHE_LINE_SIZE=64 -munaligned-access
+CPU_LDFLAGS ?=
+CPU_ASFLAGS ?= -felf
+
+export ARCH CROSS CPU_CFLAGS CPU_LDFLAGS CPU_ASFLAGS
diff --git a/mk/machine/armv7-a/rte.vars.mk b/mk/machine/armv7-a/rte.vars.mk
new file mode 100644
index 0000000..48d3979
--- /dev/null
+++ b/mk/machine/armv7-a/rte.vars.mk
@@ -0,0 +1,67 @@
+# BSD LICENSE
+#
+# Copyright (C) 2015 RehiveTech. 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 RehiveTech nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+#
+# machine:
+#
+# - can define ARCH variable (overridden by cmdline value)
+# - can define CROSS variable (overridden by cmdline value)
+# - define MACHINE_CFLAGS variable (overridden by cmdline value)
+# - define MACHINE_LDFLAGS variable (overridden by cmdline value)
+# - define MACHINE_ASFLAGS variable (overridden by cmdline value)
+# - can define CPU_CFLAGS variable (overridden by cmdline value) that
+# overrides the one defined in arch.
+# - can define CPU_LDFLAGS variable (overridden by cmdline value) that
+# overrides the one defined in arch.
+# - can define CPU_ASFLAGS variable (overridden by cmdline value) that
+# overrides the one defined in arch.
+# - may override any previously defined variable
+#
+
+# ARCH =
+# CROSS =
+# MACHINE_CFLAGS =
+# MACHINE_LDFLAGS =
+# MACHINE_ASFLAGS =
+# CPU_CFLAGS =
+# CPU_LDFLAGS =
+# CPU_ASFLAGS =
+
+CPU_CFLAGS += -mfloat-abi=softfp
+
+MACHINE_CFLAGS += -march=armv7-a
+
+ifdef CONFIG_RTE_ARCH_ARM_TUNE
+MACHINE_CFLAGS += -mtune=$(CONFIG_RTE_ARCH_ARM_TUNE)
+endif
+
+ifeq ($(CONFIG_RTE_ARCH_ARM_NEON),y)
+MACHINE_CFLAGS += -mfpu=neon
+endif
--
2.6.2
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 2/2] i40e: Enlarge the number of supported queues
@ 2015-11-03 1:16 3% ` Thomas Monjalon
2015-11-03 2:49 0% ` Zhang, Helin
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-03 1:16 UTC (permalink / raw)
To: Helin Zhang; +Cc: dev
2015-10-22 15:28, Helin Zhang:
> It enlarges the number of supported queues to hardware allowed
> maximum. There was a software limitation of 64 per physical port
> which is not reasonable.
>
> Signed-off-by: Helin Zhang <helin.zhang@intel.com>
> ---
> config/common_bsdapp | 3 +-
> config/common_linuxapp | 3 +-
> drivers/net/i40e/i40e_ethdev.c | 138 +++++++++++++++++------------------------
> drivers/net/i40e/i40e_ethdev.h | 8 +++
Please update the release notes (remove deprecation notice and add ABI change).
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 2/2] i40e: Enlarge the number of supported queues
2015-11-03 1:16 3% ` Thomas Monjalon
@ 2015-11-03 2:49 0% ` Zhang, Helin
0 siblings, 0 replies; 200+ results
From: Zhang, Helin @ 2015-11-03 2:49 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, November 3, 2015 9:17 AM
> To: Zhang, Helin
> Cc: dev@dpdk.org; Pei, Yulong
> Subject: Re: [dpdk-dev] [PATCH v2 2/2] i40e: Enlarge the number of supported
> queues
>
> 2015-10-22 15:28, Helin Zhang:
> > It enlarges the number of supported queues to hardware allowed
> > maximum. There was a software limitation of 64 per physical port which
> > is not reasonable.
> >
> > Signed-off-by: Helin Zhang <helin.zhang@intel.com>
> > ---
> > config/common_bsdapp | 3 +-
> > config/common_linuxapp | 3 +-
> > drivers/net/i40e/i40e_ethdev.c | 138
> +++++++++++++++++------------------------
> > drivers/net/i40e/i40e_ethdev.h | 8 +++
>
> Please update the release notes (remove deprecation notice and add ABI
> change).
OK. Sorry for the missing! Thank you very much for the reminder!
Regards,
Helin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine
2015-11-02 16:42 0% ` Eric Kinzie
@ 2015-11-03 6:48 4% ` Panu Matilainen
2015-11-03 8:16 0% ` Thomas Monjalon
2015-11-03 11:02 0% ` Ferruh Yigit
0 siblings, 2 replies; 200+ results
From: Panu Matilainen @ 2015-11-03 6:48 UTC (permalink / raw)
To: Eric Kinzie; +Cc: dev, Eric Kinzie
On 11/02/2015 06:42 PM, Eric Kinzie wrote:
> On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
>> On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
>>> 2015-10-19 08:36, Eric Kinzie:
>>>> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER
>>>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
>>>> functions.
>>> [...]
>>>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
>>> [...]
>>>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>>>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \
>>>> + bond_mode_8023ad_setup_v22);
>>>
>>> I'm sorry it doesn't work well when trying to build a combined lib:
>>>
>>> ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2
>>>
>>> The symbols are OK in the .o file:
>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2
>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0
>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20
>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22
>>> 0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
>>>
>>> I don't understand the problem and I am considering disabling versioning in
>>> combined library.
>>>
>>> Any idea?
>>>
>>
>> The .map additions look incorrect to me:
>>
>>> diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
>>> index 22bd920..7f78717 100644
>>> --- a/drivers/net/bonding/rte_eth_bond_version.map
>>> +++ b/drivers/net/bonding/rte_eth_bond_version.map
>>> @@ -17,6 +17,9 @@ DPDK_2.0 {
>>> rte_eth_bond_slaves_get;
>>> rte_eth_bond_xmit_policy_get;
>>> rte_eth_bond_xmit_policy_set;
>>> + rte_eth_bond_8023ad_ext_collect;
>>> + rte_eth_bond_8023ad_ext_distrib;
>>> + rte_eth_bond_8023ad_ext_slowtx;
>>
>> These symbols didn't exist in DPDK 2.0 but are only being added
>> here. So why are they being added to the 2.0 section?
>
> Yes, I think these should probably be moved.
>
>
>>>
>>> local: *;
>>> };
>>> @@ -27,3 +30,10 @@ DPDK_2.1 {
>>> rte_eth_bond_free;
>>>
>>> } DPDK_2.0;
>>> +
>>> +DPDK_2.2 {
>>> + local
>>> +
>>> + bond_mode_8023ad_conf_get;
>>> + bond_mode_8023ad_setup;
>>> +} DPDK_2.1;
>>
>> These are marked local, as in, "not exported" which doesn't seem
>> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
>> the symbol export map should look like here:
>
>
> These were not exported to begin with. But after versioning these
> functions, they are exported unless explicitly declared to be local here.
>
And this does not ring any warning bells? :)
Sorry, I was not looking at the patch as a whole. You're declaring these
symbols as exported with the versioning macros, eg
BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
...and then explicitly telling it to not export them by declaring local,
and then we wonder why it has trouble finding the symbols.
The versioning macros wont invent the librte_ prefix for you, you need
to rename the functions accordingly.
But all this versioning gymnastics is moot anyway because you declare
the ABI incompatible:
-LIBABIVER := 1
+LIBABIVER := 2
This changes the library soname, so no binary compiled against the
previous version can possibly use it anymore. As in, by definition there
can be no callers of the _v20 variants after this ABI version bump.
- Panu -
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] mk: fix ABI versioning compile error for combined shared library
2015-11-02 15:23 4% ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
2015-11-02 16:26 4% ` Thomas Monjalon
@ 2015-11-03 7:06 4% ` Panu Matilainen
2015-11-03 9:20 8% ` Ferruh Yigit
2015-11-06 13:58 7% ` [dpdk-dev] [PATCH] " Ferruh Yigit
2 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-11-03 7:06 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: Eric Kinzie
On 11/02/2015 05:23 PM, Ferruh Yigit wrote:
> Fixes following error:
> LD libdpdk.so
> /usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
> for symbol <function>@DPDK_x.y
>
> Defines version symbols in a fixed path libdpdk.map file and this
> value hardcoded into makefile
Hold on. What problem is this supposed to be fixing? If its for the
bonding thing (as it'd appear from the threading), NAK. The symbol
versioning in that patch is confused needs to be fixed there instead of
inventing strange workarounds elsewhere.
- Panu -
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine
2015-11-03 6:48 4% ` Panu Matilainen
@ 2015-11-03 8:16 0% ` Thomas Monjalon
2015-11-03 8:30 0% ` Panu Matilainen
2015-11-03 11:02 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-03 8:16 UTC (permalink / raw)
To: Panu Matilainen, Eric Kinzie; +Cc: dev
2015-11-03 08:48, Panu Matilainen:
> On 11/02/2015 06:42 PM, Eric Kinzie wrote:
> > On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
> >> On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
> >>> 2015-10-19 08:36, Eric Kinzie:
> >>>> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER
> >>>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
> >>>> functions.
> >>> [...]
> >>>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
> >>> [...]
> >>>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
> >>>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \
> >>>> + bond_mode_8023ad_setup_v22);
> >>>
> >>> I'm sorry it doesn't work well when trying to build a combined lib:
> >>>
> >>> ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2
> >>>
> >>> The symbols are OK in the .o file:
> >>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2
> >>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0
> >>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20
> >>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22
> >>> 0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
> >>>
> >>> I don't understand the problem and I am considering disabling versioning in
> >>> combined library.
> >>>
> >>> Any idea?
> >>>
> >>
> >> The .map additions look incorrect to me:
> >>
> >>> diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
> >>> index 22bd920..7f78717 100644
> >>> --- a/drivers/net/bonding/rte_eth_bond_version.map
> >>> +++ b/drivers/net/bonding/rte_eth_bond_version.map
> >>> @@ -17,6 +17,9 @@ DPDK_2.0 {
> >>> rte_eth_bond_slaves_get;
> >>> rte_eth_bond_xmit_policy_get;
> >>> rte_eth_bond_xmit_policy_set;
> >>> + rte_eth_bond_8023ad_ext_collect;
> >>> + rte_eth_bond_8023ad_ext_distrib;
> >>> + rte_eth_bond_8023ad_ext_slowtx;
> >>
> >> These symbols didn't exist in DPDK 2.0 but are only being added
> >> here. So why are they being added to the 2.0 section?
> >
> > Yes, I think these should probably be moved.
> >
> >
> >>>
> >>> local: *;
> >>> };
> >>> @@ -27,3 +30,10 @@ DPDK_2.1 {
> >>> rte_eth_bond_free;
> >>>
> >>> } DPDK_2.0;
> >>> +
> >>> +DPDK_2.2 {
> >>> + local
> >>> +
> >>> + bond_mode_8023ad_conf_get;
> >>> + bond_mode_8023ad_setup;
> >>> +} DPDK_2.1;
> >>
> >> These are marked local, as in, "not exported" which doesn't seem
> >> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
> >> the symbol export map should look like here:
> >
> >
> > These were not exported to begin with. But after versioning these
> > functions, they are exported unless explicitly declared to be local here.
> >
>
> And this does not ring any warning bells? :)
>
> Sorry, I was not looking at the patch as a whole. You're declaring these
> symbols as exported with the versioning macros, eg
>
> BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>
> ...and then explicitly telling it to not export them by declaring local,
> and then we wonder why it has trouble finding the symbols.
> The versioning macros wont invent the librte_ prefix for you, you need
> to rename the functions accordingly.
>
> But all this versioning gymnastics is moot anyway because you declare
> the ABI incompatible:
>
> -LIBABIVER := 1
> +LIBABIVER := 2
>
> This changes the library soname, so no binary compiled against the
> previous version can possibly use it anymore. As in, by definition there
> can be no callers of the _v20 variants after this ABI version bump.
Panu, thanks for your careful review.
We must remove the private functions from the export map.and not bump LIBABIVER.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine
2015-11-03 8:16 0% ` Thomas Monjalon
@ 2015-11-03 8:30 0% ` Panu Matilainen
2015-11-03 9:38 0% ` Thomas Monjalon
2015-11-03 17:12 0% ` Eric Kinzie
0 siblings, 2 replies; 200+ results
From: Panu Matilainen @ 2015-11-03 8:30 UTC (permalink / raw)
To: Thomas Monjalon, Eric Kinzie; +Cc: dev
On 11/03/2015 10:16 AM, Thomas Monjalon wrote:
> 2015-11-03 08:48, Panu Matilainen:
>> On 11/02/2015 06:42 PM, Eric Kinzie wrote:
>>> On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
>>>> On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
>>>>> 2015-10-19 08:36, Eric Kinzie:
>>>>>> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER
>>>>>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
>>>>>> functions.
>>>>> [...]
>>>>>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
>>>>> [...]
>>>>>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>>>>>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \
>>>>>> + bond_mode_8023ad_setup_v22);
>>>>>
>>>>> I'm sorry it doesn't work well when trying to build a combined lib:
>>>>>
>>>>> ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2
>>>>>
>>>>> The symbols are OK in the .o file:
>>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2
>>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0
>>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20
>>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22
>>>>> 0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
>>>>>
>>>>> I don't understand the problem and I am considering disabling versioning in
>>>>> combined library.
>>>>>
>>>>> Any idea?
>>>>>
>>>>
>>>> The .map additions look incorrect to me:
>>>>
>>>>> diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
>>>>> index 22bd920..7f78717 100644
>>>>> --- a/drivers/net/bonding/rte_eth_bond_version.map
>>>>> +++ b/drivers/net/bonding/rte_eth_bond_version.map
>>>>> @@ -17,6 +17,9 @@ DPDK_2.0 {
>>>>> rte_eth_bond_slaves_get;
>>>>> rte_eth_bond_xmit_policy_get;
>>>>> rte_eth_bond_xmit_policy_set;
>>>>> + rte_eth_bond_8023ad_ext_collect;
>>>>> + rte_eth_bond_8023ad_ext_distrib;
>>>>> + rte_eth_bond_8023ad_ext_slowtx;
>>>>
>>>> These symbols didn't exist in DPDK 2.0 but are only being added
>>>> here. So why are they being added to the 2.0 section?
>>>
>>> Yes, I think these should probably be moved.
>>>
>>>
>>>>>
>>>>> local: *;
>>>>> };
>>>>> @@ -27,3 +30,10 @@ DPDK_2.1 {
>>>>> rte_eth_bond_free;
>>>>>
>>>>> } DPDK_2.0;
>>>>> +
>>>>> +DPDK_2.2 {
>>>>> + local
>>>>> +
>>>>> + bond_mode_8023ad_conf_get;
>>>>> + bond_mode_8023ad_setup;
>>>>> +} DPDK_2.1;
>>>>
>>>> These are marked local, as in, "not exported" which doesn't seem
>>>> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
>>>> the symbol export map should look like here:
>>>
>>>
>>> These were not exported to begin with. But after versioning these
>>> functions, they are exported unless explicitly declared to be local here.
>>>
>>
>> And this does not ring any warning bells? :)
>>
>> Sorry, I was not looking at the patch as a whole. You're declaring these
>> symbols as exported with the versioning macros, eg
>>
>> BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>>
>> ...and then explicitly telling it to not export them by declaring local,
>> and then we wonder why it has trouble finding the symbols.
>> The versioning macros wont invent the librte_ prefix for you, you need
>> to rename the functions accordingly.
>>
>> But all this versioning gymnastics is moot anyway because you declare
>> the ABI incompatible:
>>
>> -LIBABIVER := 1
>> +LIBABIVER := 2
>>
>> This changes the library soname, so no binary compiled against the
>> previous version can possibly use it anymore. As in, by definition there
>> can be no callers of the _v20 variants after this ABI version bump.
>
> Panu, thanks for your careful review.
> We must remove the private functions from the export map.and not bump LIBABIVER.
>
Actually the LIBABIVER bump seems appropriate since a public struct
(rte_eth_bond_8023ad_conf) changes size.
As for the rest, I'm not quite sure what the patch is trying to achieve.
I initially assumed its trying to add a new incompatible version of
rte_bond_mode_8023ad_setup() and rte_eth_bond_8023ad_conf_get() which
could be a perfectly reasonable thing to do in some circumstances. As it
is, the patch actually adds versioning to an internal symbol which just
doesn't make sense at all. Symbol versioning is only meaningful for
public symbols.
- Panu -
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: fix ABI versioning compile error for combined shared library
2015-11-03 7:06 4% ` Panu Matilainen
@ 2015-11-03 9:20 8% ` Ferruh Yigit
2015-11-03 10:41 4% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-11-03 9:20 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Eric Kinzie
On Tue, Nov 03, 2015 at 09:06:05AM +0200, Panu Matilainen wrote:
> On 11/02/2015 05:23 PM, Ferruh Yigit wrote:
>> Fixes following error:
>> LD libdpdk.so
>> /usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
>> for symbol <function>@DPDK_x.y
>>
>> Defines version symbols in a fixed path libdpdk.map file and this
>> value hardcoded into makefile
>
> Hold on. What problem is this supposed to be fixing?
This patch is to fix combined library compilation error when ABI versining used.
Currently if ABI version macros used (VERSION_SYMBOL), we are not able to compile combined shared library.
> If its for the bonding thing (as it'd appear from the threading), NAK.
Nothing directly related to the bonding, just issue observed in this thread.
> The symbol versioning in
> that patch is confused needs to be fixed there instead of inventing strange
> workarounds elsewhere.
>
This is not intented to be a workaround but a fix, unless you have a better idea.
ferruh
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine
2015-11-03 8:30 0% ` Panu Matilainen
@ 2015-11-03 9:38 0% ` Thomas Monjalon
2015-11-03 17:12 0% ` Eric Kinzie
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-11-03 9:38 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Eric Kinzie
2015-11-03 10:30, Panu Matilainen:
> On 11/03/2015 10:16 AM, Thomas Monjalon wrote:
> > 2015-11-03 08:48, Panu Matilainen:
> >> On 11/02/2015 06:42 PM, Eric Kinzie wrote:
> >>> On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
> >>>> On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
> >>>>> 2015-10-19 08:36, Eric Kinzie:
> >>>>>> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER
> >>>>>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
> >>>>>> functions.
> >>>>> [...]
> >>>>>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
> >>>>> [...]
> >>>>>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
> >>>>>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \
> >>>>>> + bond_mode_8023ad_setup_v22);
> >>>>>
> >>>>> I'm sorry it doesn't work well when trying to build a combined lib:
> >>>>>
> >>>>> ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2
> >>>>>
> >>>>> The symbols are OK in the .o file:
> >>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2
> >>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0
> >>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20
> >>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22
> >>>>> 0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
> >>>>>
> >>>>> I don't understand the problem and I am considering disabling versioning in
> >>>>> combined library.
> >>>>>
> >>>>> Any idea?
> >>>>>
> >>>>
> >>>> The .map additions look incorrect to me:
> >>>>
> >>>>> diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
> >>>>> index 22bd920..7f78717 100644
> >>>>> --- a/drivers/net/bonding/rte_eth_bond_version.map
> >>>>> +++ b/drivers/net/bonding/rte_eth_bond_version.map
> >>>>> @@ -17,6 +17,9 @@ DPDK_2.0 {
> >>>>> rte_eth_bond_slaves_get;
> >>>>> rte_eth_bond_xmit_policy_get;
> >>>>> rte_eth_bond_xmit_policy_set;
> >>>>> + rte_eth_bond_8023ad_ext_collect;
> >>>>> + rte_eth_bond_8023ad_ext_distrib;
> >>>>> + rte_eth_bond_8023ad_ext_slowtx;
> >>>>
> >>>> These symbols didn't exist in DPDK 2.0 but are only being added
> >>>> here. So why are they being added to the 2.0 section?
> >>>
> >>> Yes, I think these should probably be moved.
> >>>
> >>>
> >>>>>
> >>>>> local: *;
> >>>>> };
> >>>>> @@ -27,3 +30,10 @@ DPDK_2.1 {
> >>>>> rte_eth_bond_free;
> >>>>>
> >>>>> } DPDK_2.0;
> >>>>> +
> >>>>> +DPDK_2.2 {
> >>>>> + local
> >>>>> +
> >>>>> + bond_mode_8023ad_conf_get;
> >>>>> + bond_mode_8023ad_setup;
> >>>>> +} DPDK_2.1;
> >>>>
> >>>> These are marked local, as in, "not exported" which doesn't seem
> >>>> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
> >>>> the symbol export map should look like here:
> >>>
> >>>
> >>> These were not exported to begin with. But after versioning these
> >>> functions, they are exported unless explicitly declared to be local here.
> >>>
> >>
> >> And this does not ring any warning bells? :)
> >>
> >> Sorry, I was not looking at the patch as a whole. You're declaring these
> >> symbols as exported with the versioning macros, eg
> >>
> >> BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
> >>
> >> ...and then explicitly telling it to not export them by declaring local,
> >> and then we wonder why it has trouble finding the symbols.
> >> The versioning macros wont invent the librte_ prefix for you, you need
> >> to rename the functions accordingly.
> >>
> >> But all this versioning gymnastics is moot anyway because you declare
> >> the ABI incompatible:
> >>
> >> -LIBABIVER := 1
> >> +LIBABIVER := 2
> >>
> >> This changes the library soname, so no binary compiled against the
> >> previous version can possibly use it anymore. As in, by definition there
> >> can be no callers of the _v20 variants after this ABI version bump.
> >
> > Panu, thanks for your careful review.
> > We must remove the private functions from the export map.and not bump LIBABIVER.
>
> Actually the LIBABIVER bump seems appropriate since a public struct
> (rte_eth_bond_8023ad_conf) changes size.
Not sure. It is added at the end of a struct which is not embedded elsewhere.
> As for the rest, I'm not quite sure what the patch is trying to achieve.
> I initially assumed its trying to add a new incompatible version of
> rte_bond_mode_8023ad_setup() and rte_eth_bond_8023ad_conf_get() which
> could be a perfectly reasonable thing to do in some circumstances. As it
> is, the patch actually adds versioning to an internal symbol which just
> doesn't make sense at all. Symbol versioning is only meaningful for
> public symbols.
Yes
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: fix ABI versioning compile error for combined shared library
2015-11-03 9:20 8% ` Ferruh Yigit
@ 2015-11-03 10:41 4% ` Panu Matilainen
2015-11-03 11:33 4% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-11-03 10:41 UTC (permalink / raw)
To: dev, Eric Kinzie
On 11/03/2015 11:20 AM, Ferruh Yigit wrote:
> On Tue, Nov 03, 2015 at 09:06:05AM +0200, Panu Matilainen wrote:
>> On 11/02/2015 05:23 PM, Ferruh Yigit wrote:
>>> Fixes following error:
>>> LD libdpdk.so
>>> /usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
>>> for symbol <function>@DPDK_x.y
>>>
>>> Defines version symbols in a fixed path libdpdk.map file and this
>>> value hardcoded into makefile
>>
>> Hold on. What problem is this supposed to be fixing?
> This patch is to fix combined library compilation error when ABI versining used.
> Currently if ABI version macros used (VERSION_SYMBOL), we are not able to compile combined shared library.
>
>> If its for the bonding thing (as it'd appear from the threading), NAK.
> Nothing directly related to the bonding, just issue observed in this thread.
Okay, understood, it was just not clear from the description. Since
there are no users of VERSION_SYMBOL etc macros this error has not come
up until now.
>
>> The symbol versioning in
>> that patch is confused needs to be fixed there instead of inventing strange
>> workarounds elsewhere.
>>
> This is not intented to be a workaround but a fix, unless you have a better idea.
The problem is, it undoes the other benefit of symbol versioning: hiding
the internal symbols. So in my eyes its more of a hack or a workaround
than a fix.
I'd much much rather see this as a solution:
http://dpdk.org/dev/patchwork/patch/4262/
- Panu -
>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine
2015-11-03 6:48 4% ` Panu Matilainen
2015-11-03 8:16 0% ` Thomas Monjalon
@ 2015-11-03 11:02 0% ` Ferruh Yigit
2015-11-03 11:31 0% ` Panu Matilainen
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-11-03 11:02 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Eric Kinzie
On Tue, Nov 03, 2015 at 08:48:16AM +0200, Panu Matilainen wrote:
> On 11/02/2015 06:42 PM, Eric Kinzie wrote:
>> On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
>>> On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
>>>> 2015-10-19 08:36, Eric Kinzie:
>>>>> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER
>>>>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
>>>>> functions.
>>>> [...]
>>>>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
>>>> [...]
>>>>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>>>>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \
>>>>> + bond_mode_8023ad_setup_v22);
>>>>
>>>> I'm sorry it doesn't work well when trying to build a combined lib:
>>>>
>>>> ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2
>>>>
>>>> The symbols are OK in the .o file:
>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2
>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0
>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20
>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22
>>>> 0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
>>>>
>>>> I don't understand the problem and I am considering disabling versioning in
>>>> combined library.
>>>>
>>>> Any idea?
>>>>
>>>
>>> The .map additions look incorrect to me:
>>>
>>>> diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
>>>> index 22bd920..7f78717 100644
>>>> --- a/drivers/net/bonding/rte_eth_bond_version.map
>>>> +++ b/drivers/net/bonding/rte_eth_bond_version.map
>>>> @@ -17,6 +17,9 @@ DPDK_2.0 {
>>>> rte_eth_bond_slaves_get;
>>>> rte_eth_bond_xmit_policy_get;
>>>> rte_eth_bond_xmit_policy_set;
>>>> + rte_eth_bond_8023ad_ext_collect;
>>>> + rte_eth_bond_8023ad_ext_distrib;
>>>> + rte_eth_bond_8023ad_ext_slowtx;
>>>
>>> These symbols didn't exist in DPDK 2.0 but are only being added
>>> here. So why are they being added to the 2.0 section?
>>
>> Yes, I think these should probably be moved.
>>
>>
>>>>
>>>> local: *;
>>>> };
>>>> @@ -27,3 +30,10 @@ DPDK_2.1 {
>>>> rte_eth_bond_free;
>>>>
>>>> } DPDK_2.0;
>>>> +
>>>> +DPDK_2.2 {
>>>> + local
>>>> +
>>>> + bond_mode_8023ad_conf_get;
>>>> + bond_mode_8023ad_setup;
>>>> +} DPDK_2.1;
>>>
>>> These are marked local, as in, "not exported" which doesn't seem
>>> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
>>> the symbol export map should look like here:
>>
>>
>> These were not exported to begin with. But after versioning these
>> functions, they are exported unless explicitly declared to be local here.
>>
>
> And this does not ring any warning bells? :)
>
> Sorry, I was not looking at the patch as a whole. You're declaring these
> symbols as exported with the versioning macros, eg
>
> BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>
> ...and then explicitly telling it to not export them by declaring local, and
> then we wonder why it has trouble finding the symbols.
> The versioning macros wont invent the librte_ prefix for you, you need to
> rename the functions accordingly.
>
> But all this versioning gymnastics is moot anyway because you declare the
> ABI incompatible:
>
> -LIBABIVER := 1
> +LIBABIVER := 2
>
> This changes the library soname, so no binary compiled against the previous
> version can possibly use it anymore. As in, by definition there can be no
> callers of the _v20 variants after this ABI version bump.
>
An observation: even soname is different, just renaming .so file itself works.
And this can be useful for the case:
libx.so.1 provides functions A, B, C
app1 compiled against libx.so.1, using only function B
libx.so.1 updated only thefunction A and become libx.so.2
app1 still can run successfully by re-naming lib to libx.so.1 (even soname is libx.so.2)
But for this usage, user needs to know which function updated and is it safe or not to use this library,
I wonder if there is an automatic way of resolving this dependency.
> - Panu -
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine
2015-11-03 11:02 0% ` Ferruh Yigit
@ 2015-11-03 11:31 0% ` Panu Matilainen
2015-11-03 11:48 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-11-03 11:31 UTC (permalink / raw)
To: Eric Kinzie, dev, Eric Kinzie, Ferruh Yigit
On 11/03/2015 01:02 PM, Ferruh Yigit wrote:
> On Tue, Nov 03, 2015 at 08:48:16AM +0200, Panu Matilainen wrote:
>> On 11/02/2015 06:42 PM, Eric Kinzie wrote:
>>> On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
>>>> On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
>>>>> 2015-10-19 08:36, Eric Kinzie:
>>>>>> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER
>>>>>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
>>>>>> functions.
>>>>> [...]
>>>>>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
>>>>> [...]
>>>>>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>>>>>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \
>>>>>> + bond_mode_8023ad_setup_v22);
>>>>>
>>>>> I'm sorry it doesn't work well when trying to build a combined lib:
>>>>>
>>>>> ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2
>>>>>
>>>>> The symbols are OK in the .o file:
>>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2
>>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0
>>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20
>>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22
>>>>> 0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
>>>>>
>>>>> I don't understand the problem and I am considering disabling versioning in
>>>>> combined library.
>>>>>
>>>>> Any idea?
>>>>>
>>>>
>>>> The .map additions look incorrect to me:
>>>>
>>>>> diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
>>>>> index 22bd920..7f78717 100644
>>>>> --- a/drivers/net/bonding/rte_eth_bond_version.map
>>>>> +++ b/drivers/net/bonding/rte_eth_bond_version.map
>>>>> @@ -17,6 +17,9 @@ DPDK_2.0 {
>>>>> rte_eth_bond_slaves_get;
>>>>> rte_eth_bond_xmit_policy_get;
>>>>> rte_eth_bond_xmit_policy_set;
>>>>> + rte_eth_bond_8023ad_ext_collect;
>>>>> + rte_eth_bond_8023ad_ext_distrib;
>>>>> + rte_eth_bond_8023ad_ext_slowtx;
>>>>
>>>> These symbols didn't exist in DPDK 2.0 but are only being added
>>>> here. So why are they being added to the 2.0 section?
>>>
>>> Yes, I think these should probably be moved.
>>>
>>>
>>>>>
>>>>> local: *;
>>>>> };
>>>>> @@ -27,3 +30,10 @@ DPDK_2.1 {
>>>>> rte_eth_bond_free;
>>>>>
>>>>> } DPDK_2.0;
>>>>> +
>>>>> +DPDK_2.2 {
>>>>> + local
>>>>> +
>>>>> + bond_mode_8023ad_conf_get;
>>>>> + bond_mode_8023ad_setup;
>>>>> +} DPDK_2.1;
>>>>
>>>> These are marked local, as in, "not exported" which doesn't seem
>>>> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
>>>> the symbol export map should look like here:
>>>
>>>
>>> These were not exported to begin with. But after versioning these
>>> functions, they are exported unless explicitly declared to be local here.
>>>
>>
>> And this does not ring any warning bells? :)
>>
>> Sorry, I was not looking at the patch as a whole. You're declaring these
>> symbols as exported with the versioning macros, eg
>>
>> BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>>
>> ...and then explicitly telling it to not export them by declaring local, and
>> then we wonder why it has trouble finding the symbols.
>> The versioning macros wont invent the librte_ prefix for you, you need to
>> rename the functions accordingly.
>>
>> But all this versioning gymnastics is moot anyway because you declare the
>> ABI incompatible:
>>
>> -LIBABIVER := 1
>> +LIBABIVER := 2
>>
>> This changes the library soname, so no binary compiled against the previous
>> version can possibly use it anymore. As in, by definition there can be no
>> callers of the _v20 variants after this ABI version bump.
>>
> An observation: even soname is different, just renaming .so file itself works.
>
> And this can be useful for the case:
> libx.so.1 provides functions A, B, C
> app1 compiled against libx.so.1, using only function B
>
> libx.so.1 updated only thefunction A and become libx.so.2
> app1 still can run successfully by re-naming lib to libx.so.1 (even soname is libx.so.2)
>
> But for this usage, user needs to know which function updated and is it safe or not to use this library,
> I wonder if there is an automatic way of resolving this dependency.
Erm, no. The whole point of changing soname and the physical filename is
to tell others it is incompatible with earlier versions. Yes you can
rename the file and get lucky (or not), just like you can play Russian
roulette. Neither are particularly healthy ideas.
Symbol version exists in part to allow libraries to evolve while
maintaining compatibility, but it requires careful planning and
programming. When public structs change, the structs would have to be
versioned too, and from there on it starts getting more and more
complicated.
- Panu -
>
>
>> - Panu -
>>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: fix ABI versioning compile error for combined shared library
2015-11-03 10:41 4% ` Panu Matilainen
@ 2015-11-03 11:33 4% ` Ferruh Yigit
2015-11-03 11:43 4% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-11-03 11:33 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Eric Kinzie
On Tue, Nov 03, 2015 at 12:41:10PM +0200, Panu Matilainen wrote:
> On 11/03/2015 11:20 AM, Ferruh Yigit wrote:
>> On Tue, Nov 03, 2015 at 09:06:05AM +0200, Panu Matilainen wrote:
>>> On 11/02/2015 05:23 PM, Ferruh Yigit wrote:
>>>> Fixes following error:
>>>> LD libdpdk.so
>>>> /usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
>>>> for symbol <function>@DPDK_x.y
>>>>
>>>> Defines version symbols in a fixed path libdpdk.map file and this
>>>> value hardcoded into makefile
>>>
>>> Hold on. What problem is this supposed to be fixing?
>> This patch is to fix combined library compilation error when ABI versining used.
>> Currently if ABI version macros used (VERSION_SYMBOL), we are not able to compile combined shared library.
>>
>>> If its for the bonding thing (as it'd appear from the threading), NAK.
>> Nothing directly related to the bonding, just issue observed in this thread.
>
> Okay, understood, it was just not clear from the description. Since there
> are no users of VERSION_SYMBOL etc macros this error has not come up until
> now.
>
>>
>>> The symbol versioning in
>>> that patch is confused needs to be fixed there instead of inventing strange
>>> workarounds elsewhere.
>>>
>> This is not intented to be a workaround but a fix, unless you have a better idea.
>
> The problem is, it undoes the other benefit of symbol versioning: hiding the
> internal symbols. So in my eyes its more of a hack or a workaround than a
> fix.
>
> I'd much much rather see this as a solution:
> http://dpdk.org/dev/patchwork/patch/4262/
>
What I observed from this, how/why combined library should be generated is under question, from that perspective I agree this patch is a hack.
If current method is used, this patch just fixes compile error, also patch is not related to versioning in combined library, which is still broken.
Thanks,
ferruh
> - Panu -
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] mk: fix ABI versioning compile error for combined shared library
2015-11-03 11:33 4% ` Ferruh Yigit
@ 2015-11-03 11:43 4% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2015-11-03 11:43 UTC (permalink / raw)
To: dev, Eric Kinzie, Ferruh Yigit
On 11/03/2015 01:33 PM, Ferruh Yigit wrote:
> On Tue, Nov 03, 2015 at 12:41:10PM +0200, Panu Matilainen wrote:
>> On 11/03/2015 11:20 AM, Ferruh Yigit wrote:
>>> On Tue, Nov 03, 2015 at 09:06:05AM +0200, Panu Matilainen wrote:
>>>> On 11/02/2015 05:23 PM, Ferruh Yigit wrote:
>>>>> Fixes following error:
>>>>> LD libdpdk.so
>>>>> /usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
>>>>> for symbol <function>@DPDK_x.y
>>>>>
>>>>> Defines version symbols in a fixed path libdpdk.map file and this
>>>>> value hardcoded into makefile
>>>>
>>>> Hold on. What problem is this supposed to be fixing?
>>> This patch is to fix combined library compilation error when ABI versining used.
>>> Currently if ABI version macros used (VERSION_SYMBOL), we are not able to compile combined shared library.
>>>
>>>> If its for the bonding thing (as it'd appear from the threading), NAK.
>>> Nothing directly related to the bonding, just issue observed in this thread.
>>
>> Okay, understood, it was just not clear from the description. Since there
>> are no users of VERSION_SYMBOL etc macros this error has not come up until
>> now.
>>
>>>
>>>> The symbol versioning in
>>>> that patch is confused needs to be fixed there instead of inventing strange
>>>> workarounds elsewhere.
>>>>
>>> This is not intented to be a workaround but a fix, unless you have a better idea.
>>
>> The problem is, it undoes the other benefit of symbol versioning: hiding the
>> internal symbols. So in my eyes its more of a hack or a workaround than a
>> fix.
>>
>> I'd much much rather see this as a solution:
>> http://dpdk.org/dev/patchwork/patch/4262/
>>
> What I observed from this, how/why combined library should be generated is under question, from that perspective I agree this patch is a hack.
> If current method is used, this patch just fixes compile error, also patch is not related to versioning in combined library, which is still broken.
The linker script eliminates the whole versioning problem because it
just makes the actual individual libraries *appear* as a single entity
during build-time, whereas the current approach physically lumps it all
together.
- Panu -
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine
2015-11-03 11:31 0% ` Panu Matilainen
@ 2015-11-03 11:48 0% ` Ferruh Yigit
2015-11-20 19:46 0% ` Eric Kinzie
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-11-03 11:48 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Eric Kinzie
On Tue, Nov 03, 2015 at 01:31:45PM +0200, Panu Matilainen wrote:
> On 11/03/2015 01:02 PM, Ferruh Yigit wrote:
>> On Tue, Nov 03, 2015 at 08:48:16AM +0200, Panu Matilainen wrote:
>>> On 11/02/2015 06:42 PM, Eric Kinzie wrote:
>>>> On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
>>>>> On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
>>>>>> 2015-10-19 08:36, Eric Kinzie:
>>>>>>> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER
>>>>>>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
>>>>>>> functions.
>>>>>> [...]
>>>>>>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
>>>>>> [...]
>>>>>>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>>>>>>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \
>>>>>>> + bond_mode_8023ad_setup_v22);
>>>>>>
>>>>>> I'm sorry it doesn't work well when trying to build a combined lib:
>>>>>>
>>>>>> ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2
>>>>>>
>>>>>> The symbols are OK in the .o file:
>>>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2
>>>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0
>>>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20
>>>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22
>>>>>> 0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
>>>>>>
>>>>>> I don't understand the problem and I am considering disabling versioning in
>>>>>> combined library.
>>>>>>
>>>>>> Any idea?
>>>>>>
>>>>>
>>>>> The .map additions look incorrect to me:
>>>>>
>>>>>> diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
>>>>>> index 22bd920..7f78717 100644
>>>>>> --- a/drivers/net/bonding/rte_eth_bond_version.map
>>>>>> +++ b/drivers/net/bonding/rte_eth_bond_version.map
>>>>>> @@ -17,6 +17,9 @@ DPDK_2.0 {
>>>>>> rte_eth_bond_slaves_get;
>>>>>> rte_eth_bond_xmit_policy_get;
>>>>>> rte_eth_bond_xmit_policy_set;
>>>>>> + rte_eth_bond_8023ad_ext_collect;
>>>>>> + rte_eth_bond_8023ad_ext_distrib;
>>>>>> + rte_eth_bond_8023ad_ext_slowtx;
>>>>>
>>>>> These symbols didn't exist in DPDK 2.0 but are only being added
>>>>> here. So why are they being added to the 2.0 section?
>>>>
>>>> Yes, I think these should probably be moved.
>>>>
>>>>
>>>>>>
>>>>>> local: *;
>>>>>> };
>>>>>> @@ -27,3 +30,10 @@ DPDK_2.1 {
>>>>>> rte_eth_bond_free;
>>>>>>
>>>>>> } DPDK_2.0;
>>>>>> +
>>>>>> +DPDK_2.2 {
>>>>>> + local
>>>>>> +
>>>>>> + bond_mode_8023ad_conf_get;
>>>>>> + bond_mode_8023ad_setup;
>>>>>> +} DPDK_2.1;
>>>>>
>>>>> These are marked local, as in, "not exported" which doesn't seem
>>>>> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
>>>>> the symbol export map should look like here:
>>>>
>>>>
>>>> These were not exported to begin with. But after versioning these
>>>> functions, they are exported unless explicitly declared to be local here.
>>>>
>>>
>>> And this does not ring any warning bells? :)
>>>
>>> Sorry, I was not looking at the patch as a whole. You're declaring these
>>> symbols as exported with the versioning macros, eg
>>>
>>> BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>>>
>>> ...and then explicitly telling it to not export them by declaring local, and
>>> then we wonder why it has trouble finding the symbols.
>>> The versioning macros wont invent the librte_ prefix for you, you need to
>>> rename the functions accordingly.
>>>
>>> But all this versioning gymnastics is moot anyway because you declare the
>>> ABI incompatible:
>>>
>>> -LIBABIVER := 1
>>> +LIBABIVER := 2
>>>
>>> This changes the library soname, so no binary compiled against the previous
>>> version can possibly use it anymore. As in, by definition there can be no
>>> callers of the _v20 variants after this ABI version bump.
>>>
>> An observation: even soname is different, just renaming .so file itself works.
>>
>> And this can be useful for the case:
>> libx.so.1 provides functions A, B, C
>> app1 compiled against libx.so.1, using only function B
>>
>> libx.so.1 updated only thefunction A and become libx.so.2
>> app1 still can run successfully by re-naming lib to libx.so.1 (even soname is libx.so.2)
>>
>> But for this usage, user needs to know which function updated and is it safe or not to use this library,
>> I wonder if there is an automatic way of resolving this dependency.
>
> Erm, no. The whole point of changing soname and the physical filename is to
> tell others it is incompatible with earlier versions. Yes you can rename the
> file and get lucky (or not), just like you can play Russian roulette.
> Neither are particularly healthy ideas.
>
> Symbol version exists in part to allow libraries to evolve while maintaining
> compatibility, but it requires careful planning and programming. When public
> structs change, the structs would have to be versioned too, and from there
> on it starts getting more and more complicated.
>
If we strictly want to prevent using old library, whenever LIBABIVER increased, we should update .map as following, right?
FROM: (dpdk2.1)
================
DPDK_2.0 {
A;
B;
C;
};
DPDK_2.1 {
D;
E;
};
LIBABIVER=1
================
TO: (dpdk2.2)
================
DPDK_2.2 {
A;
B;
C;
D;
E;
};
LIBABIVER=2
================
So this won't work for anybody without luck factor, I think currently we are not doing this.
thanks,
ferruh
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 2/2] i40e: Enlarge the number of supported queues
@ 2015-11-03 15:40 9% ` Helin Zhang
0 siblings, 0 replies; 200+ results
From: Helin Zhang @ 2015-11-03 15:40 UTC (permalink / raw)
To: dev
It enlarges the number of supported queues to hardware allowed
maximum. There was a software limitation of 64 per physical port
which is not reasonable.
Signed-off-by: Helin Zhang <helin.zhang@intel.com>
---
config/common_bsdapp | 3 +-
config/common_linuxapp | 3 +-
doc/guides/rel_notes/deprecation.rst | 5 --
doc/guides/rel_notes/release_2_2.rst | 12 +++
drivers/net/i40e/i40e_ethdev.c | 138 +++++++++++++++--------------------
drivers/net/i40e/i40e_ethdev.h | 8 ++
6 files changed, 81 insertions(+), 88 deletions(-)
v2 changes:
Fixed issues of using wrong configured number of VF queues.
v3 changes:
Updated release notes.
diff --git a/config/common_bsdapp b/config/common_bsdapp
index f202d2f..fba29e5 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -141,7 +141,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y
CONFIG_RTE_LIBRTE_ETHER=y
CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
CONFIG_RTE_MAX_ETHPORTS=32
-CONFIG_RTE_MAX_QUEUES_PER_PORT=256
+CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
CONFIG_RTE_LIBRTE_IEEE1588=n
CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
@@ -189,6 +189,7 @@ CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=y
CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
+CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
# interval up to 8160 us, aligned to 2 (or default value)
diff --git a/config/common_linuxapp b/config/common_linuxapp
index c1d4bbd..7248262 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -139,7 +139,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y
CONFIG_RTE_LIBRTE_ETHER=y
CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
CONFIG_RTE_MAX_ETHPORTS=32
-CONFIG_RTE_MAX_QUEUES_PER_PORT=256
+CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
CONFIG_RTE_LIBRTE_IEEE1588=n
CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
@@ -187,6 +187,7 @@ CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=y
CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE=y
CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
+CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
# interval up to 8160 us, aligned to 2 (or default value)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index f099ac0..730c3b7 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -8,11 +8,6 @@ API and ABI deprecation notices are to be posted here.
Deprecation Notices
-------------------
-* Significant ABI changes are planned for struct rte_eth_dev to support up to
- 1024 queues per port. This change will be in release 2.2.
- There is no backward compatibility planned from release 2.2.
- All binaries will need to be rebuilt from release 2.2.
-
* The following fields have been deprecated in rte_eth_stats:
ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 16fcc89..5d119f4 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -116,6 +116,13 @@ Drivers
Fixed i40e issue that occurred when a DPDK application didn't initialize
ports if memory wasn't available on socket 0.
+* **i40e: Fixed issue of cannot supporting more than 64 queues per port.**
+
+ Fixed the issue in i40e of cannot supporting more than 64 queues per port,
+ though hardware actually supports that. The real number of queues may vary,
+ as long as the total number of queues used in PF, VFs, VMDq and FD does not
+ exceeds the hardware maximum.
+
* **vhost: Fixed Qemu shutdown.**
Fixed issue with libvirt ``virsh destroy`` not killing the VM.
@@ -205,6 +212,11 @@ ABI Changes
* librte_cfgfile: Allow longer names and values by increasing the constants
CFG_NAME_LEN and CFG_VALUE_LEN to 64 and 256 respectively.
+* i40e: From 2.2, enlarge the maximum number of queues per port by increasing
+ the config parameter of CONFIG_RTE_MAX_QUEUES_PER_PORT to 1024. Also an new
+ config parameter of CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF will be added to
+ configure the maximum number of queues per PF.
+
Shared Library Versions
-----------------------
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 66dfdba..1e8de7b 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2748,9 +2748,8 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
{
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct i40e_hw *hw = I40E_PF_TO_HW(pf);
- uint16_t sum_queues = 0, sum_vsis, left_queues;
+ uint16_t qp_count = 0, vsi_count = 0;
- /* First check if FW support SRIOV */
if (dev->pci_dev->max_vfs && !hw->func_caps.sr_iov_1_1) {
PMD_INIT_LOG(ERR, "HW configuration doesn't support SRIOV");
return -EINVAL;
@@ -2761,109 +2760,85 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
pf->fc_conf.low_water[I40E_MAX_TRAFFIC_CLASS] = I40E_DEFAULT_LOW_WATER;
pf->flags = I40E_FLAG_HEADER_SPLIT_DISABLED;
- pf->max_num_vsi = RTE_MIN(hw->func_caps.num_vsis, I40E_MAX_NUM_VSIS);
- PMD_INIT_LOG(INFO, "Max supported VSIs:%u", pf->max_num_vsi);
- /* Allocate queues for pf */
- if (hw->func_caps.rss) {
+ pf->max_num_vsi = hw->func_caps.num_vsis;
+ pf->lan_nb_qp_max = RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF;
+ pf->vmdq_nb_qp_max = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM;
+ pf->vf_nb_qp_max = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF;
+
+ /* FDir queue/VSI allocation */
+ pf->fdir_qp_offset = 0;
+ if (hw->func_caps.fd) {
+ pf->flags |= I40E_FLAG_FDIR;
+ pf->fdir_nb_qps = I40E_DEFAULT_QP_NUM_FDIR;
+ } else {
+ pf->fdir_nb_qps = 0;
+ }
+ qp_count += pf->fdir_nb_qps;
+ vsi_count += 1;
+
+ /* LAN queue/VSI allocation */
+ pf->lan_qp_offset = pf->fdir_qp_offset + pf->fdir_nb_qps;
+ if (!hw->func_caps.rss) {
+ pf->lan_nb_qps = 1;
+ } else {
pf->flags |= I40E_FLAG_RSS;
if (hw->mac.type == I40E_MAC_X722)
pf->flags |= I40E_FLAG_RSS_AQ_CAPABLE;
- pf->lan_nb_qps = RTE_MIN(hw->func_caps.num_tx_qp,
- (uint32_t)(1 << hw->func_caps.rss_table_entry_width));
- pf->lan_nb_qps = i40e_align_floor(pf->lan_nb_qps);
- } else
- pf->lan_nb_qps = 1;
- sum_queues = pf->lan_nb_qps;
- /* Default VSI is not counted in */
- sum_vsis = 0;
- PMD_INIT_LOG(INFO, "PF queue pairs:%u", pf->lan_nb_qps);
+ pf->lan_nb_qps = pf->lan_nb_qp_max;
+ }
+ qp_count += pf->lan_nb_qps;
+ vsi_count += 1;
+ /* VF queue/VSI allocation */
+ pf->vf_qp_offset = pf->lan_qp_offset + pf->lan_nb_qps;
if (hw->func_caps.sr_iov_1_1 && dev->pci_dev->max_vfs) {
pf->flags |= I40E_FLAG_SRIOV;
pf->vf_nb_qps = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF;
- if (dev->pci_dev->max_vfs > hw->func_caps.num_vfs) {
- PMD_INIT_LOG(ERR, "Config VF number %u, "
- "max supported %u.",
- dev->pci_dev->max_vfs,
- hw->func_caps.num_vfs);
- return -EINVAL;
- }
- if (pf->vf_nb_qps > I40E_MAX_QP_NUM_PER_VF) {
- PMD_INIT_LOG(ERR, "FVL VF queue %u, "
- "max support %u queues.",
- pf->vf_nb_qps, I40E_MAX_QP_NUM_PER_VF);
- return -EINVAL;
- }
pf->vf_num = dev->pci_dev->max_vfs;
- sum_queues += pf->vf_nb_qps * pf->vf_num;
- sum_vsis += pf->vf_num;
- PMD_INIT_LOG(INFO, "Max VF num:%u each has queue pairs:%u",
- pf->vf_num, pf->vf_nb_qps);
- } else
+ PMD_DRV_LOG(DEBUG, "%u VF VSIs, %u queues per VF VSI, "
+ "in total %u queues", pf->vf_num, pf->vf_nb_qps,
+ pf->vf_nb_qps * pf->vf_num);
+ } else {
+ pf->vf_nb_qps = 0;
pf->vf_num = 0;
+ }
+ qp_count += pf->vf_nb_qps * pf->vf_num;
+ vsi_count += pf->vf_num;
+ /* VMDq queue/VSI allocation */
+ pf->vmdq_qp_offset = pf->vf_qp_offset + pf->vf_nb_qps * pf->vf_num;
if (hw->func_caps.vmdq) {
pf->flags |= I40E_FLAG_VMDQ;
- pf->vmdq_nb_qps = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM;
+ pf->vmdq_nb_qps = pf->vmdq_nb_qp_max;
pf->max_nb_vmdq_vsi = 1;
- /*
- * If VMDQ available, assume a single VSI can be created. Will adjust
- * later.
- */
- sum_queues += pf->vmdq_nb_qps * pf->max_nb_vmdq_vsi;
- sum_vsis += pf->max_nb_vmdq_vsi;
+ PMD_DRV_LOG(DEBUG, "%u VMDQ VSIs, %u queues per VMDQ VSI, "
+ "in total %u queues", pf->max_nb_vmdq_vsi,
+ pf->vmdq_nb_qps,
+ pf->vmdq_nb_qps * pf->max_nb_vmdq_vsi);
} else {
pf->vmdq_nb_qps = 0;
pf->max_nb_vmdq_vsi = 0;
}
- pf->nb_cfg_vmdq_vsi = 0;
-
- if (hw->func_caps.fd) {
- pf->flags |= I40E_FLAG_FDIR;
- pf->fdir_nb_qps = I40E_DEFAULT_QP_NUM_FDIR;
- /**
- * Each flow director consumes one VSI and one queue,
- * but can't calculate out predictably here.
- */
- }
+ qp_count += pf->vmdq_nb_qps * pf->max_nb_vmdq_vsi;
+ vsi_count += pf->max_nb_vmdq_vsi;
if (hw->func_caps.dcb)
pf->flags |= I40E_FLAG_DCB;
- if (sum_vsis > pf->max_num_vsi ||
- sum_queues > hw->func_caps.num_rx_qp) {
- PMD_INIT_LOG(ERR, "VSI/QUEUE setting can't be satisfied");
- PMD_INIT_LOG(ERR, "Max VSIs: %u, asked:%u",
- pf->max_num_vsi, sum_vsis);
- PMD_INIT_LOG(ERR, "Total queue pairs:%u, asked:%u",
- hw->func_caps.num_rx_qp, sum_queues);
+ if (qp_count > hw->func_caps.num_tx_qp) {
+ PMD_DRV_LOG(ERR, "Failed to allocate %u queues, which exceeds "
+ "the hardware maximum %u", qp_count,
+ hw->func_caps.num_tx_qp);
return -EINVAL;
}
-
- /* Adjust VMDQ setting to support as many VMs as possible */
- if (pf->flags & I40E_FLAG_VMDQ) {
- left_queues = hw->func_caps.num_rx_qp - sum_queues;
-
- pf->max_nb_vmdq_vsi += RTE_MIN(left_queues / pf->vmdq_nb_qps,
- pf->max_num_vsi - sum_vsis);
-
- /* Limit the max VMDQ number that rte_ether that can support */
- pf->max_nb_vmdq_vsi = RTE_MIN(pf->max_nb_vmdq_vsi,
- ETH_64_POOLS - 1);
-
- PMD_INIT_LOG(INFO, "Max VMDQ VSI num:%u",
- pf->max_nb_vmdq_vsi);
- PMD_INIT_LOG(INFO, "VMDQ queue pairs:%u", pf->vmdq_nb_qps);
- }
-
- /* Each VSI occupy 1 MSIX interrupt at least, plus IRQ0 for misc intr
- * cause */
- if (sum_vsis > hw->func_caps.num_msix_vectors - 1) {
- PMD_INIT_LOG(ERR, "Too many VSIs(%u), MSIX intr(%u) not enough",
- sum_vsis, hw->func_caps.num_msix_vectors);
+ if (vsi_count > hw->func_caps.num_vsis) {
+ PMD_DRV_LOG(ERR, "Failed to allocate %u VSIs, which exceeds "
+ "the hardware maximum %u", vsi_count,
+ hw->func_caps.num_vsis);
return -EINVAL;
}
- return I40E_SUCCESS;
+
+ return 0;
}
static int
@@ -3253,7 +3228,8 @@ i40e_vsi_config_tc_queue_mapping(struct i40e_vsi *vsi,
bsf = rte_bsf32(qpnum_per_tc);
/* Adjust the queue number to actual queues that can be applied */
- vsi->nb_qps = qpnum_per_tc * total_tc;
+ if (!(vsi->type == I40E_VSI_MAIN && total_tc == 1))
+ vsi->nb_qps = qpnum_per_tc * total_tc;
/**
* Configure TC and queue mapping parameters, for enabled TC,
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index de3b9d9..fe3d331 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -402,10 +402,18 @@ struct i40e_pf {
uint16_t vf_num;
/* Each of below queue pairs should be power of 2 since it's the
precondition after TC configuration applied */
+ uint16_t lan_nb_qp_max;
uint16_t lan_nb_qps; /* The number of queue pairs of LAN */
+ uint16_t lan_qp_offset;
+ uint16_t vmdq_nb_qp_max;
uint16_t vmdq_nb_qps; /* The number of queue pairs of VMDq */
+ uint16_t vmdq_qp_offset;
+ uint16_t vf_nb_qp_max;
uint16_t vf_nb_qps; /* The number of queue pairs of VF */
+ uint16_t vf_qp_offset;
uint16_t fdir_nb_qps; /* The number of queue pairs of Flow Director */
+ uint16_t fdir_qp_offset;
+
uint16_t hash_lut_size; /* The size of hash lookup table */
/* store VXLAN UDP ports */
uint16_t vxlan_ports[I40E_MAX_PF_UDP_OFFLOAD_PORTS];
--
1.9.3
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v9 0/2] i40e: RSS/FD granularity configuration
2015-11-02 14:32 4% ` [dpdk-dev] [PATCH v8 " Helin Zhang
2015-11-02 14:32 5% ` [dpdk-dev] [PATCH v8 1/2] " Helin Zhang
@ 2015-11-03 16:07 4% ` Helin Zhang
2015-11-03 16:07 5% ` [dpdk-dev] [PATCH v9 1/2] " Helin Zhang
1 sibling, 1 reply; 200+ results
From: Helin Zhang @ 2015-11-03 16:07 UTC (permalink / raw)
To: dev
The default input set of fields of a received packet are loaded from firmware,
which cannot be modified even users want to use different fields for RSS or
flow director. Here adds more flexibilities of selecting or adding packet
fields for hash calculation or flow director to users. It also includes the
modifications in testpmd to support the testing.
v2 changes:
Solved the compilation issues.
v3 changes:
Support selecting more input set fields.
v4 changes:
Removed operation of 'delete', as it is not necessary.
Added FD granularity in both pmd and testpmd, as it is similar to RSS granularity.
v5 changes:
Fixed issue of generating wrong input set for registers on ipv6-udp and ipv6-tcp pc types.
Added clear masking operations during checking if MASK registers are opcupied or not.
Reworked several annotations.
v6 changes:
Updated documentation.
v7 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
Split documentation into pieces and put them directly into the patch of code changes directly.
v8 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 1 to 128, as ABI changes is allowed in ethdev.
Updated release notes.
v9 changes:
Updated release notes.
Helin Zhang (2):
i40e: RSS/FD granularity configuration
app/testpmd: add test commands for RSS/FD granularity
app/test-pmd/cmdline.c | 218 ++++++++
doc/guides/rel_notes/release_2_2.rst | 6 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 33 ++
drivers/net/i40e/i40e_ethdev.c | 742 ++++++++++++++++++++++++++++
drivers/net/i40e/i40e_ethdev.h | 7 +
drivers/net/i40e/i40e_fdir.c | 31 ++
lib/librte_ether/rte_eth_ctrl.h | 114 ++++-
7 files changed, 1147 insertions(+), 4 deletions(-)
--
1.9.3
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v9 1/2] i40e: RSS/FD granularity configuration
2015-11-03 16:07 4% ` [dpdk-dev] [PATCH v9 0/2] " Helin Zhang
@ 2015-11-03 16:07 5% ` Helin Zhang
0 siblings, 0 replies; 200+ results
From: Helin Zhang @ 2015-11-03 16:07 UTC (permalink / raw)
To: dev
The default input set of fields of a received packet are loaded from
firmware, which cannot be modified even users want to use different
fields for RSS or flow director. Here adds more flexibilities of
selecting packet fields for hash calculation or flow director for
users.
Signed-off-by: Helin Zhang <helin.zhang@intel.com>
Signed-off-by: Andrey Chilikin <andrey.chilikin@intel.com>
---
doc/guides/rel_notes/release_2_2.rst | 6 +
drivers/net/i40e/i40e_ethdev.c | 742 +++++++++++++++++++++++++++++++++++
drivers/net/i40e/i40e_ethdev.h | 7 +
drivers/net/i40e/i40e_fdir.c | 31 ++
lib/librte_ether/rte_eth_ctrl.h | 114 +++++-
5 files changed, 896 insertions(+), 4 deletions(-)
v2 changes:
Solved the compilation issues.
v3 changes:
Support selecting more input set fields.
v4 changes:
Removed operation of 'delete', as it is not necessary.
Added FD granularity, as it is similar to RSS granularity.
v5 changes:
Fixed issue of generating wrong input set for registers on ipv6-udp and ipv6-tcp pc types.
Added clear masking operations during checking if MASK registers are opcupied or not.
Reworked several annotations.
v7 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 128 to 1, to avoid ABI changes.
Moved documentation as part of this patch.
v8 changes:
Modified RTE_ETH_INSET_SIZE_MAX from 1 to 128, as ABI changes is allowed in ethdev.
Updated release notes.
v9 changes:
Updated release notes.
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 16fcc89..bbca629 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -79,6 +79,8 @@ New Features
* **Added port hotplug support to xenvirt.**
+* **Added RSS/FD input set granularity on Intel X710/XL710.**
+
Resolved Issues
---------------
@@ -205,6 +207,10 @@ ABI Changes
* librte_cfgfile: Allow longer names and values by increasing the constants
CFG_NAME_LEN and CFG_VALUE_LEN to 64 and 256 respectively.
+* librte_ether: New union element of struct rte_eth_input_set_conf
+ input_set_conf will be added into struct rte_eth_hash_filter_info from 2.2,
+ which result in changing the size of struct rte_eth_hash_filter_info.
+
Shared Library Versions
-----------------------
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index d852bf1..e8fd7f1 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -139,6 +139,142 @@
#define I40E_DEFAULT_DCB_APP_NUM 1
#define I40E_DEFAULT_DCB_APP_PRIO 3
+#define I40E_PRTQF_FD_INSET(_i, _j) (0x00250000 + ((_i) * 64 + (_j) * 32))
+#define I40E_GLQF_FD_MSK(_i, _j) (0x00267200 + ((_i) * 4 + (_j) * 8))
+#define I40E_GLQF_FD_MSK_FIELD 0x0000FFFF
+#define I40E_GLQF_HASH_INSET(_i, _j) (0x00267600 + ((_i) * 4 + (_j) * 8))
+#define I40E_GLQF_HASH_MSK(_i, _j) (0x00267A00 + ((_i) * 4 + (_j) * 8))
+#define I40E_GLQF_HASH_MSK_FIELD 0x0000FFFF
+
+#define I40E_INSET_NONE 0x00000000000000000ULL
+
+/* bit0 ~ bit 7 */
+#define I40E_INSET_DMAC 0x0000000000000001ULL
+#define I40E_INSET_SMAC 0x0000000000000002ULL
+#define I40E_INSET_VLAN_OUTER 0x0000000000000004ULL
+#define I40E_INSET_VLAN_INNER 0x0000000000000008ULL
+#define I40E_INSET_VLAN_TUNNEL 0x0000000000000010ULL
+
+/* bit 8 ~ bit 15 */
+#define I40E_INSET_IPV4_SRC 0x0000000000000100ULL
+#define I40E_INSET_IPV4_DST 0x0000000000000200ULL
+#define I40E_INSET_IPV6_SRC 0x0000000000000400ULL
+#define I40E_INSET_IPV6_DST 0x0000000000000800ULL
+#define I40E_INSET_SRC_PORT 0x0000000000001000ULL
+#define I40E_INSET_DST_PORT 0x0000000000002000ULL
+#define I40E_INSET_SCTP_VT 0x0000000000004000ULL
+
+/* bit 16 ~ bit 31 */
+#define I40E_INSET_IPV4_TOS 0x0000000000010000ULL
+#define I40E_INSET_IPV4_PROTO 0x0000000000020000ULL
+#define I40E_INSET_IPV4_TTL 0x0000000000040000ULL
+#define I40E_INSET_IPV6_TC 0x0000000000080000ULL
+#define I40E_INSET_IPV6_FLOW 0x0000000000100000ULL
+#define I40E_INSET_IPV6_NEXT_HDR 0x0000000000200000ULL
+#define I40E_INSET_IPV6_HOP_LIMIT 0x0000000000400000ULL
+#define I40E_INSET_TCP_FLAGS 0x0000000000800000ULL
+
+/* bit 32 ~ bit 47, tunnel fields */
+#define I40E_INSET_TUNNEL_IPV4_DST 0x0000000100000000ULL
+#define I40E_INSET_TUNNEL_IPV6_DST 0x0000000200000000ULL
+#define I40E_INSET_TUNNEL_DMAC 0x0000000400000000ULL
+#define I40E_INSET_TUNNEL_SRC_PORT 0x0000000800000000ULL
+#define I40E_INSET_TUNNEL_DST_PORT 0x0000001000000000ULL
+#define I40E_INSET_TUNNEL_ID 0x0000002000000000ULL
+
+/* bit 48 ~ bit 55 */
+#define I40E_INSET_LAST_ETHER_TYPE 0x0001000000000000ULL
+
+/* bit 56 ~ bit 63, Flex Payload */
+#define I40E_INSET_FLEX_PAYLOAD_W1 0x0100000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W2 0x0200000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W3 0x0400000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W4 0x0800000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W5 0x1000000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W6 0x2000000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W7 0x4000000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD_W8 0x8000000000000000ULL
+#define I40E_INSET_FLEX_PAYLOAD \
+ (I40E_INSET_FLEX_PAYLOAD_W1 | I40E_INSET_FLEX_PAYLOAD_W2 | \
+ I40E_INSET_FLEX_PAYLOAD_W3 | I40E_INSET_FLEX_PAYLOAD_W3 | \
+ I40E_INSET_FLEX_PAYLOAD_W5 | I40E_INSET_FLEX_PAYLOAD_W6 | \
+ I40E_INSET_FLEX_PAYLOAD_W7 | I40E_INSET_FLEX_PAYLOAD_W8)
+
+/**
+ * Below are values for writing un-exposed registers suggested
+ * by silicon experts
+ */
+/* Destination MAC address */
+#define I40E_REG_INSET_L2_DMAC 0xE000000000000000ULL
+/* Source MAC address */
+#define I40E_REG_INSET_L2_SMAC 0x1C00000000000000ULL
+/* VLAN tag in the outer L2 header */
+#define I40E_REG_INSET_L2_OUTER_VLAN 0x0000000000800000ULL
+/* VLAN tag in the inner L2 header */
+#define I40E_REG_INSET_L2_INNER_VLAN 0x0000000001000000ULL
+/* Source IPv4 address */
+#define I40E_REG_INSET_L3_SRC_IP4 0x0001800000000000ULL
+/* Destination IPv4 address */
+#define I40E_REG_INSET_L3_DST_IP4 0x0000001800000000ULL
+/* IPv4 Type of Service (TOS) */
+#define I40E_REG_INSET_L3_IP4_TOS 0x0040000000000000ULL
+/* IPv4 Protocol */
+#define I40E_REG_INSET_L3_IP4_PROTO 0x0004000000000000ULL
+/* Source IPv6 address */
+#define I40E_REG_INSET_L3_SRC_IP6 0x0007F80000000000ULL
+/* Destination IPv6 address */
+#define I40E_REG_INSET_L3_DST_IP6 0x000007F800000000ULL
+/* IPv6 Traffic Class (TC) */
+#define I40E_REG_INSET_L3_IP6_TC 0x0040000000000000ULL
+/* IPv6 Next Header */
+#define I40E_REG_INSET_L3_IP6_NEXT_HDR 0x0008000000000000ULL
+/* Source L4 port */
+#define I40E_REG_INSET_L4_SRC_PORT 0x0000000400000000ULL
+/* Destination L4 port */
+#define I40E_REG_INSET_L4_DST_PORT 0x0000000200000000ULL
+/* SCTP verification tag */
+#define I40E_REG_INSET_L4_SCTP_VERIFICATION_TAG 0x0000000180000000ULL
+/* Inner destination MAC address (MAC-in-UDP/MAC-in-GRE)*/
+#define I40E_REG_INSET_TUNNEL_L2_INNER_DST_MAC 0x0000000001C00000ULL
+/* Source port of tunneling UDP */
+#define I40E_REG_INSET_TUNNEL_L4_UDP_SRC_PORT 0x0000000000200000ULL
+/* Destination port of tunneling UDP */
+#define I40E_REG_INSET_TUNNEL_L4_UDP_DST_PORT 0x0000000000100000ULL
+/* UDP Tunneling ID, NVGRE/GRE key */
+#define I40E_REG_INSET_TUNNEL_ID 0x00000000000C0000ULL
+/* Last ether type */
+#define I40E_REG_INSET_LAST_ETHER_TYPE 0x0000000000004000ULL
+/* Tunneling outer destination IPv4 address */
+#define I40E_REG_INSET_TUNNEL_L3_DST_IP4 0x00000000000000C0ULL
+/* Tunneling outer destination IPv6 address */
+#define I40E_REG_INSET_TUNNEL_L3_DST_IP6 0x0000000000003FC0ULL
+/* 1st word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD1 0x0000000000002000ULL
+/* 2nd word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD2 0x0000000000001000ULL
+/* 3rd word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD3 0x0000000000000800ULL
+/* 4th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD4 0x0000000000000400ULL
+/* 5th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD5 0x0000000000000200ULL
+/* 6th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD6 0x0000000000000100ULL
+/* 7th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD7 0x0000000000000080ULL
+/* 8th word of flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORD8 0x0000000000000040ULL
+
+#define I40E_REG_INSET_MASK_DEFAULT 0x0000000000000000ULL
+
+#define I40E_TRANSLATE_INSET 0
+#define I40E_TRANSLATE_REG 1
+
+#define I40E_INSET_IPV4_TOS_MASK 0x0009FF00UL
+#define I40E_INSET_IPV4_PROTO_MASK 0x000DFF00UL
+#define I40E_INSET_IPV6_TC_MASK 0x0009F00FUL
+#define I40E_INSET_IPV6_NEXT_HDR_MASK 0x000C00FFUL
+
static int eth_i40e_dev_init(struct rte_eth_dev *eth_dev);
static int eth_i40e_dev_uninit(struct rte_eth_dev *eth_dev);
static int i40e_dev_configure(struct rte_eth_dev *dev);
@@ -6022,6 +6158,606 @@ out:
return 0;
}
+/**
+ * Valid input sets for hash and flow director filters per PCTYPE
+ */
+static uint64_t
+i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
+ enum rte_filter_type filter)
+{
+ uint64_t valid;
+
+ static const uint64_t valid_hash_inset_table[] = {
+ [I40E_FILTER_PCTYPE_FRAG_IPV4] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_SRC |
+ I40E_INSET_IPV4_DST | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_TCP_FLAGS | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV4_TOS |
+ I40E_INSET_IPV4_PROTO | I40E_INSET_IPV4_TTL |
+ I40E_INSET_TUNNEL_DMAC | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_FRAG_IPV6] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_TUNNEL_DMAC |
+ I40E_INSET_TUNNEL_ID | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
+ I40E_INSET_DST_PORT | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
+ I40E_INSET_DST_PORT | I40E_INSET_TCP_FLAGS |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
+ I40E_INSET_DST_PORT | I40E_INSET_SCTP_VT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_IPV6_TC |
+ I40E_INSET_IPV6_FLOW | I40E_INSET_IPV6_NEXT_HDR |
+ I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
+ I40E_INSET_IPV6_DST | I40E_INSET_TUNNEL_ID |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_L2_PAYLOAD] =
+ I40E_INSET_DMAC | I40E_INSET_SMAC |
+ I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
+ I40E_INSET_VLAN_TUNNEL | I40E_INSET_LAST_ETHER_TYPE |
+ I40E_INSET_FLEX_PAYLOAD,
+ };
+
+ /**
+ * Flow director supports only fields defined in
+ * union rte_eth_fdir_flow.
+ */
+ static const uint64_t valid_fdir_inset_table[] = {
+ [I40E_FILTER_PCTYPE_FRAG_IPV4] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_FRAG_IPV6] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_FLEX_PAYLOAD,
+ [I40E_FILTER_PCTYPE_L2_PAYLOAD] =
+ I40E_INSET_LAST_ETHER_TYPE | I40E_INSET_FLEX_PAYLOAD,
+ };
+
+ if (pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD)
+ return 0;
+ if (filter == RTE_ETH_FILTER_HASH)
+ valid = valid_hash_inset_table[pctype];
+ else
+ valid = valid_fdir_inset_table[pctype];
+
+ return valid;
+}
+
+/**
+ * Validate if the input set is allowed for a specific PCTYPE
+ */
+static int
+i40e_validate_input_set(enum i40e_filter_pctype pctype,
+ enum rte_filter_type filter, uint64_t inset)
+{
+ uint64_t valid;
+
+ valid = i40e_get_valid_input_set(pctype, filter);
+ if (inset & (~valid))
+ return -EINVAL;
+
+ return 0;
+}
+
+/* default input set fields combination per pctype */
+static uint64_t
+i40e_get_default_input_set(uint16_t pctype)
+{
+ static const uint64_t default_inset_table[] = {
+ [I40E_FILTER_PCTYPE_FRAG_IPV4] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT,
+ [I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+ I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
+ [I40E_FILTER_PCTYPE_FRAG_IPV6] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+ I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
+ I40E_INSET_SCTP_VT,
+ [I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+ I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+ [I40E_FILTER_PCTYPE_L2_PAYLOAD] =
+ I40E_INSET_LAST_ETHER_TYPE,
+ };
+
+ if (pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD)
+ return 0;
+
+ return default_inset_table[pctype];
+}
+
+/**
+ * Parse the input set from index to logical bit masks
+ */
+static int
+i40e_parse_input_set(uint64_t *inset,
+ enum i40e_filter_pctype pctype,
+ enum rte_eth_input_set_field *field,
+ uint16_t size)
+{
+ uint16_t i, j;
+ int ret = -EINVAL;
+
+ static const struct {
+ enum rte_eth_input_set_field field;
+ uint64_t inset;
+ } inset_convert_table[] = {
+ {RTE_ETH_INPUT_SET_NONE, I40E_INSET_NONE},
+ {RTE_ETH_INPUT_SET_L2_SRC_MAC, I40E_INSET_SMAC},
+ {RTE_ETH_INPUT_SET_L2_DST_MAC, I40E_INSET_DMAC},
+ {RTE_ETH_INPUT_SET_L2_OUTER_VLAN, I40E_INSET_VLAN_OUTER},
+ {RTE_ETH_INPUT_SET_L2_INNER_VLAN, I40E_INSET_VLAN_INNER},
+ {RTE_ETH_INPUT_SET_L2_ETHERTYPE, I40E_INSET_LAST_ETHER_TYPE},
+ {RTE_ETH_INPUT_SET_L3_SRC_IP4, I40E_INSET_IPV4_SRC},
+ {RTE_ETH_INPUT_SET_L3_DST_IP4, I40E_INSET_IPV4_DST},
+ {RTE_ETH_INPUT_SET_L3_IP4_TOS, I40E_INSET_IPV4_TOS},
+ {RTE_ETH_INPUT_SET_L3_IP4_PROTO, I40E_INSET_IPV4_PROTO},
+ {RTE_ETH_INPUT_SET_L3_SRC_IP6, I40E_INSET_IPV6_SRC},
+ {RTE_ETH_INPUT_SET_L3_DST_IP6, I40E_INSET_IPV6_DST},
+ {RTE_ETH_INPUT_SET_L3_IP6_TC, I40E_INSET_IPV6_TC},
+ {RTE_ETH_INPUT_SET_L3_IP6_NEXT_HEADER,
+ I40E_INSET_IPV6_NEXT_HDR},
+ {RTE_ETH_INPUT_SET_L4_UDP_SRC_PORT, I40E_INSET_SRC_PORT},
+ {RTE_ETH_INPUT_SET_L4_TCP_SRC_PORT, I40E_INSET_SRC_PORT},
+ {RTE_ETH_INPUT_SET_L4_SCTP_SRC_PORT, I40E_INSET_SRC_PORT},
+ {RTE_ETH_INPUT_SET_L4_UDP_DST_PORT, I40E_INSET_DST_PORT},
+ {RTE_ETH_INPUT_SET_L4_TCP_DST_PORT, I40E_INSET_DST_PORT},
+ {RTE_ETH_INPUT_SET_L4_SCTP_DST_PORT, I40E_INSET_DST_PORT},
+ {RTE_ETH_INPUT_SET_L4_SCTP_VERIFICATION_TAG,
+ I40E_INSET_SCTP_VT},
+ {RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_DST_MAC,
+ I40E_INSET_TUNNEL_DMAC},
+ {RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_VLAN,
+ I40E_INSET_VLAN_TUNNEL},
+ {RTE_ETH_INPUT_SET_TUNNEL_L4_UDP_KEY,
+ I40E_INSET_TUNNEL_ID},
+ {RTE_ETH_INPUT_SET_TUNNEL_GRE_KEY, I40E_INSET_TUNNEL_ID},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_1ST_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W1},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_2ND_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W2},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_3RD_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W3},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_4TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W4},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_5TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W5},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_6TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W6},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_7TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W7},
+ {RTE_ETH_INPUT_SET_FLEX_PAYLOAD_8TH_WORD,
+ I40E_INSET_FLEX_PAYLOAD_W8},
+ };
+
+ if (!inset || !field || size > RTE_ETH_INSET_SIZE_MAX)
+ return ret;
+
+ /* Only one item allowed for default or all */
+ if (size == 1) {
+ if (field[0] == RTE_ETH_INPUT_SET_DEFAULT) {
+ *inset = i40e_get_default_input_set(pctype);
+ return 0;
+ } else if (field[0] == RTE_ETH_INPUT_SET_NONE) {
+ *inset = I40E_INSET_NONE;
+ return 0;
+ }
+ }
+
+ for (i = 0, *inset = 0; i < size; i++) {
+ for (j = 0; j < RTE_DIM(inset_convert_table); j++) {
+ if (field[i] == inset_convert_table[j].field) {
+ *inset |= inset_convert_table[j].inset;
+ break;
+ }
+ }
+
+ /* It contains unsupported input set, return immediately */
+ if (j == RTE_DIM(inset_convert_table))
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * Translate the input set from bit masks to register aware bit masks
+ * and vice versa
+ */
+static uint64_t
+i40e_translate_input_set_reg(uint64_t input)
+{
+ uint64_t val = 0;
+ uint16_t i;
+
+ static const struct {
+ uint64_t inset;
+ uint64_t inset_reg;
+ } inset_map[] = {
+ {I40E_INSET_DMAC, I40E_REG_INSET_L2_DMAC},
+ {I40E_INSET_SMAC, I40E_REG_INSET_L2_SMAC},
+ {I40E_INSET_VLAN_OUTER, I40E_REG_INSET_L2_OUTER_VLAN},
+ {I40E_INSET_VLAN_INNER, I40E_REG_INSET_L2_INNER_VLAN},
+ {I40E_INSET_LAST_ETHER_TYPE, I40E_REG_INSET_LAST_ETHER_TYPE},
+ {I40E_INSET_IPV4_SRC, I40E_REG_INSET_L3_SRC_IP4},
+ {I40E_INSET_IPV4_DST, I40E_REG_INSET_L3_DST_IP4},
+ {I40E_INSET_IPV4_TOS, I40E_REG_INSET_L3_IP4_TOS},
+ {I40E_INSET_IPV4_PROTO, I40E_REG_INSET_L3_IP4_PROTO},
+ {I40E_INSET_IPV6_SRC, I40E_REG_INSET_L3_SRC_IP6},
+ {I40E_INSET_IPV6_DST, I40E_REG_INSET_L3_DST_IP6},
+ {I40E_INSET_IPV6_TC, I40E_REG_INSET_L3_IP6_TC},
+ {I40E_INSET_IPV6_NEXT_HDR, I40E_REG_INSET_L3_IP6_NEXT_HDR},
+ {I40E_INSET_SRC_PORT, I40E_REG_INSET_L4_SRC_PORT},
+ {I40E_INSET_DST_PORT, I40E_REG_INSET_L4_DST_PORT},
+ {I40E_INSET_SCTP_VT, I40E_REG_INSET_L4_SCTP_VERIFICATION_TAG},
+ {I40E_INSET_TUNNEL_ID, I40E_REG_INSET_TUNNEL_ID},
+ {I40E_INSET_TUNNEL_DMAC,
+ I40E_REG_INSET_TUNNEL_L2_INNER_DST_MAC},
+ {I40E_INSET_TUNNEL_IPV4_DST, I40E_REG_INSET_TUNNEL_L3_DST_IP4},
+ {I40E_INSET_TUNNEL_IPV6_DST, I40E_REG_INSET_TUNNEL_L3_DST_IP6},
+ {I40E_INSET_TUNNEL_SRC_PORT,
+ I40E_REG_INSET_TUNNEL_L4_UDP_SRC_PORT},
+ {I40E_INSET_TUNNEL_DST_PORT,
+ I40E_REG_INSET_TUNNEL_L4_UDP_DST_PORT},
+ {I40E_INSET_TUNNEL_ID, I40E_REG_INSET_TUNNEL_ID},
+ {I40E_INSET_FLEX_PAYLOAD_W1, I40E_REG_INSET_FLEX_PAYLOAD_WORD1},
+ {I40E_INSET_FLEX_PAYLOAD_W2, I40E_REG_INSET_FLEX_PAYLOAD_WORD2},
+ {I40E_INSET_FLEX_PAYLOAD_W3, I40E_REG_INSET_FLEX_PAYLOAD_WORD3},
+ {I40E_INSET_FLEX_PAYLOAD_W4, I40E_REG_INSET_FLEX_PAYLOAD_WORD4},
+ {I40E_INSET_FLEX_PAYLOAD_W5, I40E_REG_INSET_FLEX_PAYLOAD_WORD5},
+ {I40E_INSET_FLEX_PAYLOAD_W6, I40E_REG_INSET_FLEX_PAYLOAD_WORD6},
+ {I40E_INSET_FLEX_PAYLOAD_W7, I40E_REG_INSET_FLEX_PAYLOAD_WORD7},
+ {I40E_INSET_FLEX_PAYLOAD_W8, I40E_REG_INSET_FLEX_PAYLOAD_WORD8},
+ };
+
+ if (input == 0)
+ return val;
+
+ /* Translate input set to register aware inset */
+ for (i = 0; i < RTE_DIM(inset_map); i++) {
+ if (input & inset_map[i].inset)
+ val |= inset_map[i].inset_reg;
+ }
+
+ return val;
+}
+
+static uint8_t
+i40e_generate_inset_mask_reg(uint64_t inset, uint32_t *mask, uint8_t nb_elem)
+{
+ uint8_t i, idx = 0;
+
+ static const struct {
+ uint64_t inset;
+ uint32_t mask;
+ } inset_mask_map[] = {
+ {I40E_INSET_IPV4_TOS, I40E_INSET_IPV4_TOS_MASK},
+ {I40E_INSET_IPV4_PROTO, I40E_INSET_IPV4_PROTO_MASK},
+ {I40E_INSET_IPV6_TC, I40E_INSET_IPV6_TC_MASK},
+ {I40E_INSET_IPV6_NEXT_HDR, I40E_INSET_IPV6_NEXT_HDR_MASK},
+ };
+
+ if (!inset || !mask || !nb_elem)
+ return 0;
+
+ if (!inset && nb_elem >= I40E_INSET_MASK_NUM_REG) {
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++)
+ mask[i] = 0;
+ return I40E_INSET_MASK_NUM_REG;
+ }
+
+ for (i = 0, idx = 0; i < RTE_DIM(inset_mask_map); i++) {
+ if (idx >= nb_elem)
+ break;
+ if (inset & inset_mask_map[i].inset) {
+ mask[idx] = inset_mask_map[i].mask;
+ idx++;
+ }
+ }
+
+ return idx;
+}
+
+static uint64_t
+i40e_get_reg_inset(struct i40e_hw *hw, enum rte_filter_type filter,
+ enum i40e_filter_pctype pctype)
+{
+ uint64_t reg = 0;
+
+ if (filter == RTE_ETH_FILTER_HASH) {
+ reg = I40E_READ_REG(hw, I40E_GLQF_HASH_INSET(1, pctype));
+ reg <<= I40E_32_BIT_WIDTH;
+ reg |= I40E_READ_REG(hw, I40E_GLQF_HASH_INSET(0, pctype));
+ } else if (filter == RTE_ETH_FILTER_FDIR) {
+ reg = I40E_READ_REG(hw, I40E_PRTQF_FD_INSET(pctype, 1));
+ reg <<= I40E_32_BIT_WIDTH;
+ reg |= I40E_READ_REG(hw, I40E_PRTQF_FD_INSET(pctype, 0));
+ }
+
+ return reg;
+}
+
+static void
+i40e_check_write_reg(struct i40e_hw *hw, uint32_t addr, uint32_t val)
+{
+ uint32_t reg = I40E_READ_REG(hw, addr);
+
+ PMD_DRV_LOG(DEBUG, "[0x%08x] original: 0x%08x\n", addr, reg);
+ if (reg != val)
+ I40E_WRITE_REG(hw, addr, val);
+ PMD_DRV_LOG(DEBUG, "[0x%08x] after: 0x%08x\n", addr,
+ (uint32_t)I40E_READ_REG(hw, addr));
+}
+
+static int
+i40e_set_hash_inset_mask(struct i40e_hw *hw,
+ enum i40e_filter_pctype pctype,
+ enum rte_filter_input_set_op op,
+ uint32_t *mask_reg,
+ uint8_t num)
+{
+ uint32_t reg;
+ uint8_t i;
+
+ if (!mask_reg || num > RTE_ETH_INPUT_SET_SELECT)
+ return -EINVAL;
+
+ if (op == RTE_ETH_INPUT_SET_SELECT) {
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+ 0);
+ if (i >= num)
+ continue;
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+ mask_reg[i]);
+ }
+ } else if (op == RTE_ETH_INPUT_SET_ADD) {
+ uint8_t j, count = 0;
+
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
+ reg = I40E_READ_REG(hw, I40E_GLQF_HASH_MSK(i, pctype));
+ if (reg & I40E_GLQF_HASH_MSK_FIELD)
+ count++;
+ }
+ if (count + num > I40E_INSET_MASK_NUM_REG)
+ return -EINVAL;
+
+ for (i = count, j = 0; i < I40E_INSET_MASK_NUM_REG; i++, j++)
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+ mask_reg[j]);
+ }
+
+ return 0;
+}
+
+static int
+i40e_set_fd_inset_mask(struct i40e_hw *hw,
+ enum i40e_filter_pctype pctype,
+ enum rte_filter_input_set_op op,
+ uint32_t *mask_reg,
+ uint8_t num)
+{
+ uint32_t reg;
+ uint8_t i;
+
+ if (!mask_reg || num > RTE_ETH_INPUT_SET_SELECT)
+ return -EINVAL;
+
+ if (op == RTE_ETH_INPUT_SET_SELECT) {
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
+ i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+ 0);
+ if (i >= num)
+ continue;
+ i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+ mask_reg[i]);
+ }
+ } else if (op == RTE_ETH_INPUT_SET_ADD) {
+ uint8_t j, count = 0;
+
+ for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
+ reg = I40E_READ_REG(hw, I40E_GLQF_FD_MSK(i, pctype));
+ if (reg & I40E_GLQF_FD_MSK_FIELD)
+ count++;
+ }
+ if (count + num > I40E_INSET_MASK_NUM_REG)
+ return -EINVAL;
+
+ for (i = count, j = 0; i < I40E_INSET_MASK_NUM_REG; i++, j++)
+ i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+ mask_reg[j]);
+ }
+
+ return 0;
+}
+
+int
+i40e_filter_inset_select(struct i40e_hw *hw,
+ struct rte_eth_input_set_conf *conf,
+ enum rte_filter_type filter)
+{
+ enum i40e_filter_pctype pctype;
+ uint64_t inset_reg = 0, input_set;
+ uint32_t mask_reg[I40E_INSET_MASK_NUM_REG];
+ uint8_t num;
+ int ret;
+
+ if (!hw || !conf) {
+ PMD_DRV_LOG(ERR, "Invalid pointer");
+ return -EFAULT;
+ }
+
+ pctype = i40e_flowtype_to_pctype(conf->flow_type);
+ if (pctype == 0 || pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD) {
+ PMD_DRV_LOG(ERR, "Not supported flow type (%u)",
+ conf->flow_type);
+ return -EINVAL;
+ }
+ if (filter != RTE_ETH_FILTER_HASH && filter != RTE_ETH_FILTER_FDIR) {
+ PMD_DRV_LOG(ERR, "Not supported filter type (%u)", filter);
+ return -EINVAL;
+ }
+
+ ret = i40e_parse_input_set(&input_set, pctype, conf->field,
+ conf->inset_size);
+ if (ret) {
+ PMD_DRV_LOG(ERR, "Failed to parse input set");
+ return -EINVAL;
+ }
+ if (i40e_validate_input_set(pctype, filter, input_set) != 0) {
+ PMD_DRV_LOG(ERR, "Invalid input set");
+ return -EINVAL;
+ }
+
+ if (conf->op == RTE_ETH_INPUT_SET_ADD) {
+ inset_reg |= i40e_get_reg_inset(hw, filter, pctype);
+ } else if (conf->op != RTE_ETH_INPUT_SET_SELECT) {
+ PMD_DRV_LOG(ERR, "Unsupported input set operation");
+ return -EINVAL;
+ }
+ num = i40e_generate_inset_mask_reg(input_set, mask_reg,
+ I40E_INSET_MASK_NUM_REG);
+ inset_reg |= i40e_translate_input_set_reg(input_set);
+
+ if (filter == RTE_ETH_FILTER_HASH) {
+ ret = i40e_set_hash_inset_mask(hw, pctype, conf->op, mask_reg,
+ num);
+ if (ret)
+ return -EINVAL;
+
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_INSET(0, pctype),
+ (uint32_t)(inset_reg & UINT32_MAX));
+ i40e_check_write_reg(hw, I40E_GLQF_HASH_INSET(1, pctype),
+ (uint32_t)((inset_reg >>
+ I40E_32_BIT_WIDTH) & UINT32_MAX));
+ } else if (filter == RTE_ETH_FILTER_FDIR) {
+ ret = i40e_set_fd_inset_mask(hw, pctype, conf->op, mask_reg,
+ num);
+ if (ret)
+ return -EINVAL;
+
+ i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 0),
+ (uint32_t)(inset_reg & UINT32_MAX));
+ i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 1),
+ (uint32_t)((inset_reg >>
+ I40E_32_BIT_WIDTH) & UINT32_MAX));
+ } else {
+ PMD_DRV_LOG(ERR, "Not supported filter type (%u)", filter);
+ return -EINVAL;
+ }
+ I40E_WRITE_FLUSH(hw);
+
+ return 0;
+}
+
static int
i40e_hash_filter_get(struct i40e_hw *hw, struct rte_eth_hash_filter_info *info)
{
@@ -6069,6 +6805,12 @@ i40e_hash_filter_set(struct i40e_hw *hw, struct rte_eth_hash_filter_info *info)
ret = i40e_set_hash_filter_global_config(hw,
&(info->info.global_conf));
break;
+ case RTE_ETH_HASH_FILTER_INPUT_SET_SELECT:
+ ret = i40e_filter_inset_select(hw,
+ &(info->info.input_set_conf),
+ RTE_ETH_FILTER_HASH);
+ break;
+
default:
PMD_DRV_LOG(ERR, "Hash filter info type (%d) not supported",
info->info_type);
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index de3b9d9..d480c26 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -107,6 +107,7 @@ enum i40e_flxpld_layer_idx {
#define I40E_FDIR_BITMASK_NUM_WORD 2 /* max number of bitmask words */
#define I40E_FDIR_MAX_FLEXWORD_NUM 8 /* max number of flexpayload words */
#define I40E_FDIR_MAX_FLEX_LEN 16 /* len in bytes of flex payload */
+#define I40E_INSET_MASK_NUM_REG 2 /* number of input set mask registers */
/* i40e flags */
#define I40E_FLAG_RSS (1ULL << 0)
@@ -541,6 +542,12 @@ uint16_t i40e_pctype_to_flowtype(enum i40e_filter_pctype pctype);
int i40e_fdir_ctrl_func(struct rte_eth_dev *dev,
enum rte_filter_op filter_op,
void *arg);
+int i40e_select_filter_input_set(struct i40e_hw *hw,
+ struct rte_eth_input_set_conf *conf,
+ enum rte_filter_type filter);
+int i40e_filter_inset_select(struct i40e_hw *hw,
+ struct rte_eth_input_set_conf *conf,
+ enum rte_filter_type filter);
void i40e_rxq_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
struct rte_eth_rxq_info *qinfo);
diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c
index c9ce98f..ba18c9d 100644
--- a/drivers/net/i40e/i40e_fdir.c
+++ b/drivers/net/i40e/i40e_fdir.c
@@ -1342,6 +1342,33 @@ i40e_fdir_stats_get(struct rte_eth_dev *dev, struct rte_eth_fdir_stats *stat)
I40E_PFQF_FDSTAT_BEST_CNT_SHIFT);
}
+static int
+i40e_fdir_filter_set(struct rte_eth_dev *dev,
+ struct rte_eth_hash_filter_info *info)
+{
+ struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+ struct i40e_hw *hw = I40E_PF_TO_HW(pf);
+ int ret = 0;
+
+ if (!info) {
+ PMD_DRV_LOG(ERR, "Invalid pointer");
+ return -EFAULT;
+ }
+
+ switch (info->info_type) {
+ case RTE_ETH_FDIR_FILTER_INPUT_SET_SELECT:
+ ret = i40e_filter_inset_select(hw,
+ &(info->info.input_set_conf), RTE_ETH_FILTER_FDIR);
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "FD filter info type (%d) not supported",
+ info->info_type);
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
/*
* i40e_fdir_ctrl_func - deal with all operations on flow director.
* @pf: board private structure
@@ -1382,6 +1409,10 @@ i40e_fdir_ctrl_func(struct rte_eth_dev *dev,
case RTE_ETH_FILTER_INFO:
i40e_fdir_info_get(dev, (struct rte_eth_fdir_info *)arg);
break;
+ case RTE_ETH_FILTER_SET:
+ ret = i40e_fdir_filter_set(dev,
+ (struct rte_eth_hash_filter_info *)arg);
+ break;
case RTE_ETH_FILTER_STATS:
i40e_fdir_stats_get(dev, (struct rte_eth_fdir_stats *)arg);
break;
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 770c76c..ae73c36 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -295,7 +295,84 @@ struct rte_eth_tunnel_filter_conf {
uint16_t queue_id; /** < queue number. */
};
-#define RTE_ETH_FDIR_MAX_FLEXLEN 16 /** < Max length of flexbytes. */
+#define RTE_ETH_FDIR_MAX_FLEXLEN 16 /** < Max length of flexbytes. */
+#define RTE_ETH_INSET_SIZE_MAX 128 /** < Max length of input set. */
+
+/**
+ * Input set fields for Flow Director and Hash filters
+ */
+enum rte_eth_input_set_field {
+ RTE_ETH_INPUT_SET_UNKNOWN = 0,
+
+ /* L2 */
+ RTE_ETH_INPUT_SET_L2_SRC_MAC = 1,
+ RTE_ETH_INPUT_SET_L2_DST_MAC,
+ RTE_ETH_INPUT_SET_L2_OUTER_VLAN,
+ RTE_ETH_INPUT_SET_L2_INNER_VLAN,
+ RTE_ETH_INPUT_SET_L2_ETHERTYPE,
+
+ /* L3 */
+ RTE_ETH_INPUT_SET_L3_SRC_IP4 = 129,
+ RTE_ETH_INPUT_SET_L3_DST_IP4,
+ RTE_ETH_INPUT_SET_L3_SRC_IP6,
+ RTE_ETH_INPUT_SET_L3_DST_IP6,
+ RTE_ETH_INPUT_SET_L3_IP4_TOS,
+ RTE_ETH_INPUT_SET_L3_IP4_PROTO,
+ RTE_ETH_INPUT_SET_L3_IP6_TC,
+ RTE_ETH_INPUT_SET_L3_IP6_NEXT_HEADER,
+
+ /* L4 */
+ RTE_ETH_INPUT_SET_L4_UDP_SRC_PORT = 257,
+ RTE_ETH_INPUT_SET_L4_UDP_DST_PORT,
+ RTE_ETH_INPUT_SET_L4_TCP_SRC_PORT,
+ RTE_ETH_INPUT_SET_L4_TCP_DST_PORT,
+ RTE_ETH_INPUT_SET_L4_SCTP_SRC_PORT,
+ RTE_ETH_INPUT_SET_L4_SCTP_DST_PORT,
+ RTE_ETH_INPUT_SET_L4_SCTP_VERIFICATION_TAG,
+
+ /* Tunnel */
+ RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_DST_MAC = 385,
+ RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_SRC_MAC,
+ RTE_ETH_INPUT_SET_TUNNEL_L2_INNER_VLAN,
+ RTE_ETH_INPUT_SET_TUNNEL_L4_UDP_KEY,
+ RTE_ETH_INPUT_SET_TUNNEL_GRE_KEY,
+
+ /* Flexible Payload */
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_1ST_WORD = 641,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_2ND_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_3RD_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_4TH_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_5TH_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_6TH_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_7TH_WORD,
+ RTE_ETH_INPUT_SET_FLEX_PAYLOAD_8TH_WORD,
+
+ RTE_ETH_INPUT_SET_DEFAULT = 65533,
+ RTE_ETH_INPUT_SET_NONE = 65534,
+ RTE_ETH_INPUT_SET_MAX = 65535,
+};
+
+/**
+ * Filters input set operations
+ */
+enum rte_filter_input_set_op {
+ RTE_ETH_INPUT_SET_OP_UNKNOWN,
+ RTE_ETH_INPUT_SET_SELECT, /**< select input set */
+ RTE_ETH_INPUT_SET_ADD, /**< add input set entry */
+ RTE_ETH_INPUT_SET_OP_MAX
+};
+
+
+/**
+ * A structure used to define the input set configuration for
+ * flow director and hash filters
+ */
+struct rte_eth_input_set_conf {
+ uint16_t flow_type;
+ uint16_t inset_size;
+ enum rte_eth_input_set_field field[RTE_ETH_INSET_SIZE_MAX];
+ enum rte_filter_input_set_op op;
+};
/**
* A structure used to define the input for L2 flow
@@ -535,7 +612,7 @@ struct rte_eth_fdir_flex_mask {
/**
* A structure used to define all flexible payload related setting
- * include flexpay load and flex mask
+ * include flex payload and flex mask
*/
struct rte_eth_fdir_flex_conf {
uint16_t nb_payloads; /**< The number of following payload cfg */
@@ -615,12 +692,37 @@ struct rte_eth_fdir_stats {
};
/**
+ * Flow Director filter information types.
+ */
+enum rte_eth_fdir_filter_info_type {
+ RTE_ETH_FDIR_FILTER_INFO_TYPE_UNKNOWN = 0,
+ /** Flow Director filter input set configuration */
+ RTE_ETH_FDIR_FILTER_INPUT_SET_SELECT,
+ RTE_ETH_FDIR_FILTER_INFO_TYPE_MAX,
+};
+
+/**
+ * A structure used to set FDIR filter information, to support filter type
+ * of 'RTE_ETH_FILTER_FDIR' RTE_ETH_FDIR_FILTER_INPUT_SET_SELECT operation.
+ */
+struct rte_eth_fdir_filter_info {
+ enum rte_eth_fdir_filter_info_type info_type; /**< Information type */
+ /** Details of fdir filter information */
+ union {
+ /** Flow Director input set configuration per port */
+ struct rte_eth_input_set_conf input_set_conf;
+ } info;
+};
+
+/**
* Hash filter information types.
* - RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT is for getting/setting the
* information/configuration of 'symmetric hash enable' per port.
* - RTE_ETH_HASH_FILTER_GLOBAL_CONFIG is for getting/setting the global
* configurations of hash filters. Those global configurations are valid
* for all ports of the same NIC.
+ * - RTE_ETH_HASH_FILTER_INPUT_SET_SELECT is for setting the global
+ * hash input set fields
*/
enum rte_eth_hash_filter_info_type {
RTE_ETH_HASH_FILTER_INFO_TYPE_UNKNOWN = 0,
@@ -628,6 +730,8 @@ enum rte_eth_hash_filter_info_type {
RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT,
/** Configure globally for hash filter */
RTE_ETH_HASH_FILTER_GLOBAL_CONFIG,
+ /** Global Hash filter input set configuration */
+ RTE_ETH_HASH_FILTER_INPUT_SET_SELECT,
RTE_ETH_HASH_FILTER_INFO_TYPE_MAX,
};
@@ -647,7 +751,7 @@ enum rte_eth_hash_function {
* A structure used to set or get global hash function configurations which
* include symmetric hash enable per flow type and hash function type.
* Each bit in sym_hash_enable_mask[] indicates if the symmetric hash of the
- * coresponding flow type is enabled or not.
+ * corresponding flow type is enabled or not.
* Each bit in valid_bit_mask[] indicates if the corresponding bit in
* sym_hash_enable_mask[] is valid or not. For the configurations gotten, it
* also means if the flow type is supported by hardware or not.
@@ -672,6 +776,8 @@ struct rte_eth_hash_filter_info {
uint8_t enable;
/** Global configurations of hash filter */
struct rte_eth_hash_global_conf global_conf;
+ /** Global configurations of hash filter input set */
+ struct rte_eth_input_set_conf input_set_conf;
} info;
};
--
1.9.3
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v3 1/7] ethdev: add additional ieee1588 support functions
@ 2015-11-03 16:38 4% ` Daniel Mrzyglod
0 siblings, 0 replies; 200+ results
From: Daniel Mrzyglod @ 2015-11-03 16:38 UTC (permalink / raw)
To: dev
Add additional functions to support the existing IEEE1588
functionality.
* rte_eth_timesync_settime(), function to set the device clock time.
* rte_eth_timesync_gettime, function to get the device clock time.
* rte_eth_timesync_adjust, function to adjust the device clock time.
Signed-off-by: Daniel Mrzyglod <danielx.t.mrzyglod@intel.com>
---
doc/guides/rel_notes/release_2_2.rst | 3 ++
lib/librte_ether/rte_ethdev.c | 36 +++++++++++++++++++
lib/librte_ether/rte_ethdev.h | 64 ++++++++++++++++++++++++++++++++++
lib/librte_ether/rte_ether_version.map | 3 ++
4 files changed, 106 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 16fcc89..09fd642 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -176,6 +176,9 @@ API Changes
* The devargs union field virtual is renamed to virt for C++ compatibility.
+* Add new functions in ethdev to support IEEE1588: rte_eth_timesync_time_adjust()
+ rte_eth_timesync_time_get(), rte_eth_timesync_time_set()
+
ABI Changes
-----------
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 58aaeb2..a1e7eac 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3171,6 +3171,42 @@ rte_eth_timesync_read_tx_timestamp(uint8_t port_id, struct timespec *timestamp)
}
int
+rte_eth_timesync_time_adjust(uint8_t port_id, int64_t delta)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_time_adjust, -ENOTSUP);
+ return (*dev->dev_ops->timesync_time_adjust)(dev, delta);
+}
+
+int
+rte_eth_timesync_time_get(uint8_t port_id, struct timespec *timestamp)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_time_get, -ENOTSUP);
+ return (*dev->dev_ops->timesync_time_get)(dev, timestamp);
+}
+
+int
+rte_eth_timesync_time_set(uint8_t port_id, struct timespec *timestamp)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_time_set, -ENOTSUP);
+ return (*dev->dev_ops->timesync_time_set)(dev, timestamp);
+}
+
+int
rte_eth_dev_get_reg_length(uint8_t port_id)
{
struct rte_eth_dev *dev;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 7cf4af8..75cc742 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1200,6 +1200,17 @@ typedef int (*eth_timesync_read_tx_timestamp_t)(struct rte_eth_dev *dev,
struct timespec *timestamp);
/**< @internal Function used to read a TX IEEE1588/802.1AS timestamp. */
+typedef int (*eth_timesync_time_adjust)(struct rte_eth_dev *dev, int64_t);
+/**< @internal Function used to adjust device clock */
+
+typedef int (*eth_timesync_time_get)(struct rte_eth_dev *dev,
+ struct timespec *timestamp);
+/**< @internal Function used to get time from device clock. */
+
+typedef int (*eth_timesync_time_set)(struct rte_eth_dev *dev,
+ struct timespec *timestamp);
+/**< @internal Function used to get time from device clock */
+
typedef int (*eth_get_reg_length_t)(struct rte_eth_dev *dev);
/**< @internal Retrieve device register count */
@@ -1394,6 +1405,12 @@ struct eth_dev_ops {
/** Get DCB information */
eth_get_dcb_info get_dcb_info;
+ /** Adjust the device clock */
+ eth_timesync_time_adjust timesync_time_adjust;
+ /** Get the device clock timespec */
+ eth_timesync_time_get timesync_time_get;
+ /** Set the device clock timespec */
+ eth_timesync_time_set timesync_time_set;
};
/**
@@ -3735,6 +3752,53 @@ extern int rte_eth_timesync_read_rx_timestamp(uint8_t port_id,
extern int rte_eth_timesync_read_tx_timestamp(uint8_t port_id,
struct timespec *timestamp);
+/**
+ * Adjust the timesync clock on an Ethernet device..
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param delta
+ * The adjustment in nanoseconds
+ *
+ * @return
+ * - 0: Success.
+ * - -ENODEV: The port ID is invalid.
+ * - -ENOTSUP: The function is not supported by the Ethernet driver.
+ */
+extern int rte_eth_timesync_time_adjust(uint8_t port_id, int64_t delta);
+
+/**
+ * Read the time from the timesync clock on an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param time
+ * Pointer to the timespec struct.
+ *
+ * @return
+ * - 0: Success.
+ */
+extern int rte_eth_timesync_time_get(uint8_t port_id,
+ struct timespec *time);
+
+
+/**
+ * Set the time of the timesync clock on an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param time
+ * Pointer to the timespec struct.
+ *
+ * @return
+ * - 0: Success.
+ * - -EINVAL: No timestamp is available.
+ * - -ENODEV: The port ID is invalid.
+ * - -ENOTSUP: The function is not supported by the Ethernet driver.
+ */
+extern int rte_eth_timesync_time_set(uint8_t port_id,
+ struct timespec *time);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_ether/rte_ether_version.map b/lib/librte_ether/rte_ether_version.map
index 7b04e95..24d5e0a 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -134,5 +134,8 @@ DPDK_2.2 {
rte_eth_dev_get_dcb_info;
rte_eth_rx_queue_info_get;
rte_eth_tx_queue_info_get;
+ rte_eth_timesync_time_adjust;
+ rte_eth_timesync_time_get;
+ rte_eth_timesync_time_set;
} DPDK_2.1;
--
2.1.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine
2015-11-03 8:30 0% ` Panu Matilainen
2015-11-03 9:38 0% ` Thomas Monjalon
@ 2015-11-03 17:12 0% ` Eric Kinzie
1 sibling, 0 replies; 200+ results
From: Eric Kinzie @ 2015-11-03 17:12 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Eric Kinzie
On Tue Nov 03 10:30:56 +0200 2015, Panu Matilainen wrote:
> On 11/03/2015 10:16 AM, Thomas Monjalon wrote:
> >2015-11-03 08:48, Panu Matilainen:
> >>On 11/02/2015 06:42 PM, Eric Kinzie wrote:
> >>>On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
> >>>>On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
> >>>>>2015-10-19 08:36, Eric Kinzie:
> >>>>>> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER
> >>>>>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
> >>>>>> functions.
> >>>>>[...]
> >>>>>>+VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
> >>>>>[...]
> >>>>>>+BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
> >>>>>>+MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \
> >>>>>>+ bond_mode_8023ad_setup_v22);
> >>>>>
> >>>>>I'm sorry it doesn't work well when trying to build a combined lib:
> >>>>>
> >>>>>ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2
> >>>>>
> >>>>>The symbols are OK in the .o file:
> >>>>>0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2
> >>>>>0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0
> >>>>>0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20
> >>>>>0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22
> >>>>>0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
> >>>>>
> >>>>>I don't understand the problem and I am considering disabling versioning in
> >>>>>combined library.
> >>>>>
> >>>>>Any idea?
> >>>>>
> >>>>
> >>>>The .map additions look incorrect to me:
> >>>>
> >>>>>diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
> >>>>>index 22bd920..7f78717 100644
> >>>>>--- a/drivers/net/bonding/rte_eth_bond_version.map
> >>>>>+++ b/drivers/net/bonding/rte_eth_bond_version.map
> >>>>>@@ -17,6 +17,9 @@ DPDK_2.0 {
> >>>>> rte_eth_bond_slaves_get;
> >>>>> rte_eth_bond_xmit_policy_get;
> >>>>> rte_eth_bond_xmit_policy_set;
> >>>>>+ rte_eth_bond_8023ad_ext_collect;
> >>>>>+ rte_eth_bond_8023ad_ext_distrib;
> >>>>>+ rte_eth_bond_8023ad_ext_slowtx;
> >>>>
> >>>>These symbols didn't exist in DPDK 2.0 but are only being added
> >>>>here. So why are they being added to the 2.0 section?
> >>>
> >>>Yes, I think these should probably be moved.
> >>>
> >>>
> >>>>>
> >>>>> local: *;
> >>>>>};
> >>>>>@@ -27,3 +30,10 @@ DPDK_2.1 {
> >>>>> rte_eth_bond_free;
> >>>>>
> >>>>>} DPDK_2.0;
> >>>>>+
> >>>>>+DPDK_2.2 {
> >>>>>+ local
> >>>>>+
> >>>>>+ bond_mode_8023ad_conf_get;
> >>>>>+ bond_mode_8023ad_setup;
> >>>>>+} DPDK_2.1;
> >>>>
> >>>>These are marked local, as in, "not exported" which doesn't seem
> >>>>right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
> >>>>the symbol export map should look like here:
> >>>
> >>>
> >>>These were not exported to begin with. But after versioning these
> >>>functions, they are exported unless explicitly declared to be local here.
> >>>
> >>
> >>And this does not ring any warning bells? :)
> >>
> >>Sorry, I was not looking at the patch as a whole. You're declaring these
> >>symbols as exported with the versioning macros, eg
> >>
> >>BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
> >>
> >>...and then explicitly telling it to not export them by declaring local,
> >>and then we wonder why it has trouble finding the symbols.
> >>The versioning macros wont invent the librte_ prefix for you, you need
> >>to rename the functions accordingly.
> >>
> >>But all this versioning gymnastics is moot anyway because you declare
> >>the ABI incompatible:
> >>
> >>-LIBABIVER := 1
> >>+LIBABIVER := 2
> >>
> >>This changes the library soname, so no binary compiled against the
> >>previous version can possibly use it anymore. As in, by definition there
> >>can be no callers of the _v20 variants after this ABI version bump.
> >
> >Panu, thanks for your careful review.
> >We must remove the private functions from the export map.and not bump LIBABIVER.
> >
>
> Actually the LIBABIVER bump seems appropriate since a public struct
> (rte_eth_bond_8023ad_conf) changes size.
>
> As for the rest, I'm not quite sure what the patch is trying to
> achieve. I initially assumed its trying to add a new incompatible
> version of rte_bond_mode_8023ad_setup() and
> rte_eth_bond_8023ad_conf_get() which could be a perfectly reasonable
> thing to do in some circumstances. As it is, the patch actually adds
> versioning to an internal symbol which just doesn't make sense at
> all. Symbol versioning is only meaningful for public symbols.
>
> - Panu -
It's likely I misintepreted some advice from an ealier review of
this code. The intention was to prevent an application accidentally
reading/writing past the end of a struct rte_eth_bond_8023ad_conf after
upgrading the library.
I can send another version of these patches that, instead,
adds new versions of rte_bond_mode_8023ad_setup() and
rte_eth_bond_8023ad_conf_get().
Eric
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4 1/3] ethdev: extend struct to support flow director in VFs
@ 2015-11-04 3:29 17% ` Jingjing Wu
0 siblings, 0 replies; 200+ results
From: Jingjing Wu @ 2015-11-04 3:29 UTC (permalink / raw)
To: dev
This patch extends struct rte_eth_fdir_flow_ext to support flow
director in VFs.
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_2_2.rst | 3 +++
lib/librte_ether/rte_eth_ctrl.h | 2 ++
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 730c3b7..9fdd25c 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -12,10 +12,6 @@ Deprecation Notices
ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
-* ABI changes are planned for struct rte_eth_fdir_flow_ext in order to support
- flow director filtering in VF. The release 2.1 does not contain these ABI
- changes, but release 2.2 will, and no backwards compatibility is planned.
-
* ABI changes are planned for struct rte_eth_fdir_filter and
rte_eth_fdir_masks in order to support new flow director modes,
MAC VLAN and Cloud, on x550. The MAC VLAN mode means the MAC and
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index ca8471b..7d2c2bb 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -240,6 +240,9 @@ ABI Changes
* librte_cfgfile: Allow longer names and values by increasing the constants
CFG_NAME_LEN and CFG_VALUE_LEN to 64 and 256 respectively.
+* The rte_eth_fdir_flow_ext structure is changed. New fields are added to
+ support flow director filtering in VF.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index f71669c..228183e 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -523,6 +523,8 @@ struct rte_eth_fdir_flow_ext {
uint16_t vlan_tci;
uint8_t flexbytes[RTE_ETH_FDIR_MAX_FLEXLEN];
/**< It is filled by the flexible payload to match. */
+ uint8_t is_vf; /**< 1 for VF, 0 for port dev */
+ uint16_t dst_id; /**< VF ID, available when is_vf is 1*/
};
/**
--
2.4.0
^ permalink raw reply [relevance 17%]
* [dpdk-dev] [PATCH v4 1/7] ethdev: add additional ieee1588 support functions
@ 2015-11-04 10:06 4% ` Daniel Mrzyglod
0 siblings, 0 replies; 200+ results
From: Daniel Mrzyglod @ 2015-11-04 10:06 UTC (permalink / raw)
To: dev
Add additional functions to support the existing IEEE1588
functionality.
* rte_eth_timesync_settime(), function to set the device clock time.
* rte_eth_timesync_gettime, function to get the device clock time.
* rte_eth_timesync_adjust, function to adjust the device clock time.
Signed-off-by: Daniel Mrzyglod <danielx.t.mrzyglod@intel.com>
---
doc/guides/rel_notes/release_2_2.rst | 3 ++
lib/librte_ether/rte_ethdev.c | 36 +++++++++++++++++++
lib/librte_ether/rte_ethdev.h | 65 +++++++++++++++++++++++++++++++++-
lib/librte_ether/rte_ether_version.map | 3 ++
4 files changed, 106 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index ca8471b..e39d422 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -205,6 +205,9 @@ API Changes
* The devargs union field virtual is renamed to virt for C++ compatibility.
+* Add new functions in ethdev to support IEEE1588: rte_eth_timesync_time_adjust()
+ rte_eth_timesync_time_get(), rte_eth_timesync_time_set()
+
ABI Changes
-----------
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index fcc9e0f..759a731 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3165,6 +3165,42 @@ rte_eth_timesync_read_tx_timestamp(uint8_t port_id, struct timespec *timestamp)
}
int
+rte_eth_timesync_time_adjust(uint8_t port_id, int64_t delta)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_time_adjust, -ENOTSUP);
+ return (*dev->dev_ops->timesync_time_adjust)(dev, delta);
+}
+
+int
+rte_eth_timesync_time_get(uint8_t port_id, struct timespec *timestamp)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_time_get, -ENOTSUP);
+ return (*dev->dev_ops->timesync_time_get)(dev, timestamp);
+}
+
+int
+rte_eth_timesync_time_set(uint8_t port_id, struct timespec *timestamp)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_time_set, -ENOTSUP);
+ return (*dev->dev_ops->timesync_time_set)(dev, timestamp);
+}
+
+int
rte_eth_dev_get_reg_length(uint8_t port_id)
{
struct rte_eth_dev *dev;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 4f7b64b..f9d282b 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1200,6 +1200,17 @@ typedef int (*eth_timesync_read_tx_timestamp_t)(struct rte_eth_dev *dev,
struct timespec *timestamp);
/**< @internal Function used to read a TX IEEE1588/802.1AS timestamp. */
+typedef int (*eth_timesync_time_adjust)(struct rte_eth_dev *dev, int64_t);
+/**< @internal Function used to adjust device clock */
+
+typedef int (*eth_timesync_time_get)(struct rte_eth_dev *dev,
+ struct timespec *timestamp);
+/**< @internal Function used to get time from device clock. */
+
+typedef int (*eth_timesync_time_set)(struct rte_eth_dev *dev,
+ struct timespec *timestamp);
+/**< @internal Function used to get time from device clock */
+
typedef int (*eth_get_reg_length_t)(struct rte_eth_dev *dev);
/**< @internal Retrieve device register count */
@@ -1394,6 +1405,12 @@ struct eth_dev_ops {
/** Get DCB information */
eth_get_dcb_info get_dcb_info;
+ /** Adjust the device clock */
+ eth_timesync_time_adjust timesync_time_adjust;
+ /** Get the device clock timespec */
+ eth_timesync_time_get timesync_time_get;
+ /** Set the device clock timespec */
+ eth_timesync_time_set timesync_time_set;
};
/**
@@ -3745,6 +3762,53 @@ extern int rte_eth_timesync_read_tx_timestamp(uint8_t port_id,
struct timespec *timestamp);
/**
+ * Adjust the timesync clock on an Ethernet device..
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param delta
+ * The adjustment in nanoseconds
+ *
+ * @return
+ * - 0: Success.
+ * - -ENODEV: The port ID is invalid.
+ * - -ENOTSUP: The function is not supported by the Ethernet driver.
+ */
+extern int rte_eth_timesync_time_adjust(uint8_t port_id, int64_t delta);
+
+/**
+ * Read the time from the timesync clock on an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param time
+ * Pointer to the timespec struct.
+ *
+ * @return
+ * - 0: Success.
+ */
+extern int rte_eth_timesync_time_get(uint8_t port_id,
+ struct timespec *time);
+
+
+/**
+ * Set the time of the timesync clock on an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param time
+ * Pointer to the timespec struct.
+ *
+ * @return
+ * - 0: Success.
+ * - -EINVAL: No timestamp is available.
+ * - -ENODEV: The port ID is invalid.
+ * - -ENOTSUP: The function is not supported by the Ethernet driver.
+ */
+extern int rte_eth_timesync_time_set(uint8_t port_id,
+ struct timespec *time);
+
+/**
* Copy pci device info to the Ethernet device data.
*
* @param eth_dev
@@ -3757,7 +3821,6 @@ extern int rte_eth_timesync_read_tx_timestamp(uint8_t port_id,
*/
extern void rte_eth_copy_pci_info(struct rte_eth_dev *eth_dev, struct rte_pci_device *pci_dev);
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_ether/rte_ether_version.map b/lib/librte_ether/rte_ether_version.map
index 9149aa7..bb9c808 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -135,5 +135,8 @@ DPDK_2.2 {
rte_eth_dev_get_dcb_info;
rte_eth_rx_queue_info_get;
rte_eth_tx_queue_info_get;
+ rte_eth_timesync_time_adjust;
+ rte_eth_timesync_time_get;
+ rte_eth_timesync_time_set;
} DPDK_2.1;
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: Add missing new line before code block
@ 2015-11-05 2:11 0% ` Tetsuya Mukawa
0 siblings, 0 replies; 200+ results
From: Tetsuya Mukawa @ 2015-11-05 2:11 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
Hi Thomas,
Could you please merge below patch?
Thanks,
Tetsuya
On 2015/10/28 18:33, Mcnamara, John wrote:
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tetsuya Mukawa
>> Sent: Tuesday, October 20, 2015 3:42 AM
>> To: dev@dpdk.org
>> Subject: [dpdk-dev] [PATCH] doc: Add missing new line before code block
>>
>> The patch adds missing new line to "Managing ABI updates" section.
>>
>> Signed-off-by: Tetsuya Mukawa <mukawa@igel.co.jp>
> Acked-by: John McNamara <john.mcnamara@intel.com>
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 1/7] ethdev: add additional ieee1588 support functions
@ 2015-11-05 14:06 4% ` Daniel Mrzyglod
0 siblings, 0 replies; 200+ results
From: Daniel Mrzyglod @ 2015-11-05 14:06 UTC (permalink / raw)
To: dev
Add additional functions to support the existing IEEE1588
functionality.
* rte_eth_timesync_settime(), function to set the device clock time.
* rte_eth_timesync_gettime, function to get the device clock time.
* rte_eth_timesync_adjust, function to adjust the device clock time.
Signed-off-by: Daniel Mrzyglod <danielx.t.mrzyglod@intel.com>
---
doc/guides/rel_notes/release_2_2.rst | 3 ++
lib/librte_ether/rte_ethdev.c | 36 +++++++++++++++++++
lib/librte_ether/rte_ethdev.h | 65 +++++++++++++++++++++++++++++++++-
lib/librte_ether/rte_ether_version.map | 3 ++
4 files changed, 106 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 59dda59..17b281c 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -222,6 +222,9 @@ API Changes
* The devargs union field virtual is renamed to virt for C++ compatibility.
+* Add new functions in ethdev to support IEEE1588: rte_eth_timesync_time_adjust()
+ rte_eth_timesync_time_get(), rte_eth_timesync_time_set()
+
ABI Changes
-----------
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index e0e1dca..20cf013 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3193,6 +3193,42 @@ rte_eth_timesync_read_tx_timestamp(uint8_t port_id, struct timespec *timestamp)
}
int
+rte_eth_timesync_time_adjust(uint8_t port_id, int64_t delta)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_time_adjust, -ENOTSUP);
+ return (*dev->dev_ops->timesync_time_adjust)(dev, delta);
+}
+
+int
+rte_eth_timesync_time_get(uint8_t port_id, struct timespec *timestamp)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_time_get, -ENOTSUP);
+ return (*dev->dev_ops->timesync_time_get)(dev, timestamp);
+}
+
+int
+rte_eth_timesync_time_set(uint8_t port_id, struct timespec *timestamp)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_time_set, -ENOTSUP);
+ return (*dev->dev_ops->timesync_time_set)(dev, timestamp);
+}
+
+int
rte_eth_dev_get_reg_length(uint8_t port_id)
{
struct rte_eth_dev *dev;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 48a540d..585d980 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1206,6 +1206,17 @@ typedef int (*eth_timesync_read_tx_timestamp_t)(struct rte_eth_dev *dev,
struct timespec *timestamp);
/**< @internal Function used to read a TX IEEE1588/802.1AS timestamp. */
+typedef int (*eth_timesync_time_adjust)(struct rte_eth_dev *dev, int64_t);
+/**< @internal Function used to adjust device clock */
+
+typedef int (*eth_timesync_time_get)(struct rte_eth_dev *dev,
+ struct timespec *timestamp);
+/**< @internal Function used to get time from device clock. */
+
+typedef int (*eth_timesync_time_set)(struct rte_eth_dev *dev,
+ struct timespec *timestamp);
+/**< @internal Function used to get time from device clock */
+
typedef int (*eth_get_reg_length_t)(struct rte_eth_dev *dev);
/**< @internal Retrieve device register count */
@@ -1400,6 +1411,12 @@ struct eth_dev_ops {
/** Get DCB information */
eth_get_dcb_info get_dcb_info;
+ /** Adjust the device clock */
+ eth_timesync_time_adjust timesync_time_adjust;
+ /** Get the device clock timespec */
+ eth_timesync_time_get timesync_time_get;
+ /** Set the device clock timespec */
+ eth_timesync_time_set timesync_time_set;
};
/**
@@ -3755,6 +3772,53 @@ extern int rte_eth_timesync_read_tx_timestamp(uint8_t port_id,
struct timespec *timestamp);
/**
+ * Adjust the timesync clock on an Ethernet device..
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param delta
+ * The adjustment in nanoseconds
+ *
+ * @return
+ * - 0: Success.
+ * - -ENODEV: The port ID is invalid.
+ * - -ENOTSUP: The function is not supported by the Ethernet driver.
+ */
+extern int rte_eth_timesync_time_adjust(uint8_t port_id, int64_t delta);
+
+/**
+ * Read the time from the timesync clock on an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param time
+ * Pointer to the timespec struct.
+ *
+ * @return
+ * - 0: Success.
+ */
+extern int rte_eth_timesync_time_get(uint8_t port_id,
+ struct timespec *time);
+
+
+/**
+ * Set the time of the timesync clock on an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param time
+ * Pointer to the timespec struct.
+ *
+ * @return
+ * - 0: Success.
+ * - -EINVAL: No timestamp is available.
+ * - -ENODEV: The port ID is invalid.
+ * - -ENOTSUP: The function is not supported by the Ethernet driver.
+ */
+extern int rte_eth_timesync_time_set(uint8_t port_id,
+ struct timespec *time);
+
+/**
* Copy pci device info to the Ethernet device data.
*
* @param eth_dev
@@ -3767,7 +3831,6 @@ extern int rte_eth_timesync_read_tx_timestamp(uint8_t port_id,
*/
extern void rte_eth_copy_pci_info(struct rte_eth_dev *eth_dev, struct rte_pci_device *pci_dev);
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_ether/rte_ether_version.map b/lib/librte_ether/rte_ether_version.map
index 9149aa7..bb9c808 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -135,5 +135,8 @@ DPDK_2.2 {
rte_eth_dev_get_dcb_info;
rte_eth_rx_queue_info_get;
rte_eth_tx_queue_info_get;
+ rte_eth_timesync_time_adjust;
+ rte_eth_timesync_time_get;
+ rte_eth_timesync_time_set;
} DPDK_2.1;
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] cmdline: increase commandline buffer size to 512
@ 2015-11-05 16:50 3% ` Nélio Laranjeiro
2015-11-09 11:45 4% ` Mcnamara, John
0 siblings, 1 reply; 200+ results
From: Nélio Laranjeiro @ 2015-11-05 16:50 UTC (permalink / raw)
To: John McNamara, Olivier Matz, Thomas Monjalon; +Cc: dev
On Thu, Nov 05, 2015 at 09:58:36AM +0000, John McNamara wrote:
> Increase commandline buffer size to 512 to allow for longer
> commandlines required by testpmd when dealing with flow
> director and IPv6 addresses.
>
> Signed-off-by: John McNamara <john.mcnamara@intel.com>
> ---
> lib/librte_cmdline/cmdline_rdline.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
> index b9aad9b..72e2dad 100644
> --- a/lib/librte_cmdline/cmdline_rdline.h
> +++ b/lib/librte_cmdline/cmdline_rdline.h
> @@ -93,7 +93,7 @@ extern "C" {
> #endif
>
> /* configuration */
> -#define RDLINE_BUF_SIZE 256
> +#define RDLINE_BUF_SIZE 512
> #define RDLINE_PROMPT_SIZE 32
> #define RDLINE_VT100_BUF_SIZE 8
> #define RDLINE_HISTORY_BUF_SIZE BUFSIZ
> --
> 1.8.1.4
>
I have faced the same issue. For some commands this value is still too
low. For example, RETA update can not be used, the command line limits
he configuration to 34 entries.
See http://dpdk.org/ml/archives/dev/2015-October/024681.html
and particularly
http://dpdk.org/ml/archives/dev/2015-October/024682.html
It was too late to announce an ABI change so we left out the cmdline
size update.
Olivier, Thomas, what do you think about this? It seems this is really
blocking.
--
Nélio Laranjeiro
6WIND
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC PATCH] vhost: remove lockless enqueue to virt ring
@ 2015-11-06 5:33 3% ` Xie, Huawei
0 siblings, 0 replies; 200+ results
From: Xie, Huawei @ 2015-11-06 5:33 UTC (permalink / raw)
To: Tetsuya Mukawa, dev; +Cc: ann.zhuangyanying
On 11/6/2015 9:43 AM, Tetsuya Mukawa wrote:
> On 2015/11/05 19:21, Xie, Huawei wrote:
>> If no objections, would remove the internal cmpset enqueue, should get
>> some improved performance.
>>
>> No idea why commit message is lost:
>> DPDK doesn't support receiving/transmitting packets from/to the same
>> port/queue.
>> Vhost pmd wraps vhost device as normal dpdk port. dpdkvhost based
>> applications/switch
>> also treate virtio port and physical port both as ports, and have
>> their own
>> lock implmentation when to enqueue packets to the same port. This patch
>> removes
>> the internal lockless vhost enqueue implmentation.
>> On 11/5/2015 5:38 PM, Huawei Xie wrote:
>>> Signed-off-by: Huawei Xie <huawei.xie@intel.com>
> Hi Xie,
>
> I think it's a good optimization.
> But I guess the patch will changes behavior of vhost library API.
> For example, if someone has already implemented an application based on
> the assumption that vhost library has internal lock, I doubt their
> application will face an issue with this patch.
Yes, i understand. If we have an improper implementation, we fix it as
early as possible. I prefer to remove the internal lock currently. The
last thing i want to do is maintain two APIs.
Would follow the ABI process.
>
> If it's correct, we might need to follow below steps.
> http://dpdk.org/doc/guides/contributing/versioning.html
>
> Thanks,
> Tetsuya
>
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] mk: rename 'make install' to 'make sdk'
@ 2015-11-06 10:24 2% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2015-11-06 10:24 UTC (permalink / raw)
To: dev
Since 'make install' is the standard command for installing packages
into the filesystem of a system - generally in /usr/local/ - it's use to
trigger compilation of the DPDK SDK was both confusing and preventing a
"true" 'make install' command from being implemented.
As a first step to improving our build and install system, this patch
renames the 'make install' and 'make uninstall' commands to 'make sdk'
and 'make clean-sdk' respectively.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
doc/build-sdk-quick.txt | 4 +-
doc/guides/freebsd_gsg/build_dpdk.rst | 16 ++---
doc/guides/linux_gsg/build_dpdk.rst | 22 +++---
doc/guides/nics/intel_vf.rst | 2 +-
doc/guides/prog_guide/dev_kit_root_make_help.rst | 18 ++---
doc/guides/rel_notes/deprecation.rst | 4 ++
doc/guides/rel_notes/release_2_2.rst | 7 ++
doc/guides/sample_app_ug/tep_termination.rst | 3 +-
doc/guides/sample_app_ug/vhost.rst | 3 +-
doc/guides/testpmd_app_ug/build_app.rst | 2 +-
doc/guides/xen/pkt_switch.rst | 2 +-
mk/rte.sdk.mk | 88 ++++++++++++++++++++++++
mk/rte.sdkinstall.mk | 87 -----------------------
mk/rte.sdkroot.mk | 13 +++-
scripts/gen-build-mk.sh | 2 +-
tools/setup.sh | 6 +-
16 files changed, 149 insertions(+), 130 deletions(-)
create mode 100644 mk/rte.sdk.mk
delete mode 100644 mk/rte.sdkinstall.mk
diff --git a/doc/build-sdk-quick.txt b/doc/build-sdk-quick.txt
index bf18b48..c91b664 100644
--- a/doc/build-sdk-quick.txt
+++ b/doc/build-sdk-quick.txt
@@ -5,8 +5,8 @@ Build commands
all same as build (default rule)
build build in a configured directory
clean remove files but keep configuration
- install build many targets (wildcard allowed) and install in DESTDIR
- uninstall remove all installed targets
+ sdk build many targets (wildcard allowed) in DESTDIR
+ clean-sdk remove all built targets
examples build examples for given targets (T=)
examples_clean clean examples for given targets (T=)
Build variables
diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst b/doc/guides/freebsd_gsg/build_dpdk.rst
index 8eff599..d03dfe3 100644
--- a/doc/guides/freebsd_gsg/build_dpdk.rst
+++ b/doc/guides/freebsd_gsg/build_dpdk.rst
@@ -114,7 +114,7 @@ user. For the installation of the DPDK, the default options were used.
make config -recursive command until no more dialogs are seen.
-Install the DPDK and Browse Sources
+Prepare the DPDK and Browse Sources
-----------------------------------
First, uncompress the archive and move to the DPDK source directory:
@@ -136,8 +136,8 @@ The DPDK is composed of several directories:
* config, tools, scripts, mk: Framework-related makefiles, scripts and configuration
-Installation of the DPDK Target Environments
---------------------------------------------
+Compiling the DPDK SDK for a Target Environment
+-----------------------------------------------
The format of a DPDK target is:
@@ -168,23 +168,23 @@ directory in the form of:
on which it is built. For more information on this setting, and its
possible values, see the *DPDK Programmers Guide*.
-To install and make the target, use "gmake install T=<target>".
+To make the target, use "gmake sdk T=<target>".
For example to compile for FreeBSD* use:
.. code-block:: console
- gmake install T=x86_64-native-bsdapp-clang
+ gmake sdk T=x86_64-native-bsdapp-clang
.. note::
If the compiler binary to be used does not correspond to that given in the
TOOLCHAIN part of the target, the compiler command may need to be explicitly
specified. For example, if compiling for gcc, where the gcc binary is called
- gcc4.8, the command would need to be "gmake install T=<target> CC=gcc4.8".
+ gcc4.8, the command would need to be "gmake sdk T=<target> CC=gcc4.8".
-Browsing the Installed DPDK Environment Target
-----------------------------------------------
+Browsing the Compiled DPDK SDK
+------------------------------
Once a target is created, it contains all the libraries and header files for the
DPDK environment that are required to build customer applications.
diff --git a/doc/guides/linux_gsg/build_dpdk.rst b/doc/guides/linux_gsg/build_dpdk.rst
index 2680e66..13230f9 100644
--- a/doc/guides/linux_gsg/build_dpdk.rst
+++ b/doc/guides/linux_gsg/build_dpdk.rst
@@ -35,8 +35,8 @@ Compiling the DPDK Target from Source
Parts of this process can also be done using the setup script described in Chapter 6 of this document.
-Install the DPDK and Browse Sources
------------------------------------
+Prepare DPDK and Browse Sources
+-------------------------------
First, uncompress the archive and move to the uncompressed DPDK source directory:
@@ -59,8 +59,8 @@ The DPDK is composed of several directories:
* config, tools, scripts, mk: Framework-related makefiles, scripts and configuration
-Installation of DPDK Target Environments
-----------------------------------------
+Compile DPDK SDK for a Target Environment
+-----------------------------------------
The format of a DPDK target is:
@@ -96,31 +96,31 @@ Also, verify the compiler's installation directory since the path may be differe
source /opt/intel/bin/iccvars.sh intel64
source /opt/intel/bin/iccvars.sh ia32
-To install and make targets, use the make install T=<target> command in the top-level DPDK directory.
+To install and make targets, use the make sdk T=<target> command in the top-level DPDK directory.
For example, to compile a 64-bit target using icc, run:
.. code-block:: console
- make install T=x86_64-native-linuxapp-icc
+ make sdk T=x86_64-native-linuxapp-icc
To compile a 32-bit build using gcc, the make command should be:
.. code-block:: console
- make install T=i686-native-linuxapp-gcc
+ make sdk T=i686-native-linuxapp-gcc
To compile all 64-bit targets using gcc, use:
.. code-block:: console
- make install T=x86_64*gcc
+ make sdk T=x86_64*gcc
To compile all 64-bit targets using both gcc and icc, use:
.. code-block:: console
- make install T=x86_64-*
+ make sdk T=x86_64-*
.. note::
@@ -152,8 +152,8 @@ The user may also make modifications to the compile-time DPDK configuration by e
In addition, the make clean command can be used to remove any existing compiled files for a subsequent full, clean rebuild of the code.
-Browsing the Installed DPDK Environment Target
-----------------------------------------------
+Browsing the Compiled DPDK SDK
+------------------------------
Once a target is created it contains all libraries, including poll-mode drivers, and header files for the DPDK environment that are required to build customer applications.
In addition, the test and testpmd applications are built under the build/app directory, which may be used for testing.
diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst
index db86c64..01bd641 100644
--- a/doc/guides/nics/intel_vf.rst
+++ b/doc/guides/nics/intel_vf.rst
@@ -512,7 +512,7 @@ The setup procedure is as follows:
.. code-block:: console
- make install T=x86_64-native-linuxapp-gcc
+ make sdk T=x86_64-native-linuxapp-gcc
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -- -i
#. Finally, access the Guest OS using vncviewer with the localhost:5900 port and check the lspci command output in the Guest OS.
diff --git a/doc/guides/prog_guide/dev_kit_root_make_help.rst b/doc/guides/prog_guide/dev_kit_root_make_help.rst
index e522c12..c84874e 100644
--- a/doc/guides/prog_guide/dev_kit_root_make_help.rst
+++ b/doc/guides/prog_guide/dev_kit_root_make_help.rst
@@ -102,15 +102,15 @@ The default output directory is build.
make lib/librte_eal_clean O=mybuild
-Install Targets
----------------
+SDK Compilation Targets
+-----------------------
-* Install
+* sdk
Build the DPDK binary.
Actually, this builds each supported target in a separate directory.
The name of each directory is the name of the target.
- The name of the targets to install can be optionally specified using T=mytarget.
+ The name of the targets to build can be optionally specified using T=mytarget.
The target name can contain wildcard \* characters.
The list of available targets are in $(RTE_SDK)/config (remove the defconfig\_ prefix).
@@ -118,11 +118,11 @@ Install Targets
.. code-block:: console
- make install T=x86_64-*
+ make sdk T=x86_64-*
-* Uninstall
+* clean-sdk
- Remove installed target directories.
+ Remove previously built target directories.
Test Targets
------------
@@ -140,7 +140,7 @@ Test Targets
* testall
- Launch automatic tests for all installed target directories (after a make install).
+ Launch automatic tests for all installed target directories (after a make sdk).
The name of the targets to test can be optionally specified using T=mytarget.
The target name can contain wildcard (\*) characters.
The list of available targets are in $(RTE_SDK)/config (remove the defconfig\_ prefix).
@@ -265,4 +265,4 @@ For example:
.. code-block:: console
- make install T=x86_64-native-linuxapp-gcc make -C examples/<theapp>
+ make sdk T=x86_64-native-linuxapp-gcc make -C examples/<theapp>
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 549ecb9..9e31073 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -8,6 +8,10 @@ API and ABI deprecation notices are to be posted here.
Deprecation Notices
-------------------
+* The commands "make install" and "make uninstall" used to build, and clean up
+ the DPDK SDK have been renamed in this release to "make sdk" and "make
+ sdk-clean" respectively.
+
* The following fields have been deprecated in rte_eth_stats:
ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 59dda59..1c879e3 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -196,6 +196,13 @@ Known Issues
------------
+Build Changes
+-------------
+
+* The commands "make install" and "make uninstall" to build and subsequently
+ clean-up the DPDK SDK have been renamed to "make sdk" and "make sdk-clean" in
+ this release.
+
API Changes
-----------
diff --git a/doc/guides/sample_app_ug/tep_termination.rst b/doc/guides/sample_app_ug/tep_termination.rst
index 6beb6f6..ac1fcc7 100644
--- a/doc/guides/sample_app_ug/tep_termination.rst
+++ b/doc/guides/sample_app_ug/tep_termination.rst
@@ -162,8 +162,7 @@ Compiling the Sample Code
.. code-block:: console
cd ${RTE_SDK}
- make config ${RTE_TARGET}
- make install ${RTE_TARGET}
+ make sdk ${RTE_TARGET}
cd ${RTE_SDK}/examples/tep_termination
make
diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst
index ceeaf52..4c7ae22 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -334,8 +334,7 @@ Compiling the Sample Code
.. code-block:: console
cd ${RTE_SDK}
- make config ${RTE_TARGET}
- make install ${RTE_TARGET}
+ make sdk ${RTE_TARGET}
cd ${RTE_SDK}/examples/vhost
make
diff --git a/doc/guides/testpmd_app_ug/build_app.rst b/doc/guides/testpmd_app_ug/build_app.rst
index 7f32a7c..a5b4837 100644
--- a/doc/guides/testpmd_app_ug/build_app.rst
+++ b/doc/guides/testpmd_app_ug/build_app.rst
@@ -52,7 +52,7 @@ The basic compilation steps are:
.. code-block:: console
- make install T=$RTE_TARGET
+ make sdk T=$RTE_TARGET
The compiled application will be located at:
diff --git a/doc/guides/xen/pkt_switch.rst b/doc/guides/xen/pkt_switch.rst
index 3a6fc47..48a4475 100644
--- a/doc/guides/xen/pkt_switch.rst
+++ b/doc/guides/xen/pkt_switch.rst
@@ -295,7 +295,7 @@ Building and Running the Switching Backend
.. code-block:: console
- make install T=x86_64-native-linuxapp-gcc
+ make sdk T=x86_64-native-linuxapp-gcc
#. Ensure that RTE_SDK and RTE_TARGET are correctly set. Build the switching example:
diff --git a/mk/rte.sdk.mk b/mk/rte.sdk.mk
new file mode 100644
index 0000000..7372733
--- /dev/null
+++ b/mk/rte.sdk.mk
@@ -0,0 +1,88 @@
+# BSD LICENSE
+#
+# Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+#
+# * Redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in
+# the documentation and/or other materials provided with the
+# distribution.
+# * Neither the name of Intel Corporation nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+# Build directory is given with O=
+ifdef O
+BUILD_DIR=$(O)
+else
+BUILD_DIR=.
+endif
+
+# Targets to install can be specified in command line. It can be a
+# target name or a name containing jokers "*". Example:
+# x86_64-native-*-gcc
+ifndef T
+T=*
+endif
+
+#
+# sdk: build sdk for all supported targets
+#
+SDK_CONFIGS := $(patsubst $(RTE_SRCDIR)/config/defconfig_%,%,\
+ $(wildcard $(RTE_SRCDIR)/config/defconfig_$(T)))
+SDK_TARGETS := $(addsuffix _sdkbuild,\
+ $(filter-out %~,$(SDK_CONFIGS)))
+
+.PHONY: sdk sdkbuild
+sdk: sdkbuild
+sdkbuild: $(SDK_TARGETS)
+
+%_sdkbuild:
+ @echo ================== Building $*
+ $(Q)if [ ! -f $(BUILD_DIR)/$*/.config ]; then \
+ $(MAKE) config T=$* O=$(BUILD_DIR)/$*; \
+ elif cmp -s $(BUILD_DIR)/$*/.config.orig $(BUILD_DIR)/$*/.config; then \
+ $(MAKE) config T=$* O=$(BUILD_DIR)/$*; \
+ else \
+ if [ -f $(BUILD_DIR)/$*/.config.orig ] ; then \
+ tmp_build=$(BUILD_DIR)/$*/.config.tmp; \
+ $(MAKE) config T=$* O=$$tmp_build; \
+ if ! cmp -s $(BUILD_DIR)/$*/.config.orig $$tmp_build/.config ; then \
+ echo "Conflict: local config and template config have both changed"; \
+ exit 1; \
+ fi; \
+ fi; \
+ echo "Using local configuration"; \
+ fi
+ $(Q)$(MAKE) all O=$(BUILD_DIR)/$*
+
+#
+# clean-sdk: remove all built sdk
+#
+CLEAN_SDK_TARGETS := $(addsuffix _clean_sdk,\
+ $(filter-out %~,$(SDK_CONFIGS)))
+
+.PHONY: clean-sdk
+clean-sdk: $(CLEAN_SDK_TARGETS)
+
+%_clean_sdk:
+ @echo ================== Cleaning $*
+ $(Q)rm -rf $(BUILD_DIR)/$*
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
deleted file mode 100644
index 86c98a5..0000000
--- a/mk/rte.sdkinstall.mk
+++ /dev/null
@@ -1,87 +0,0 @@
-# BSD LICENSE
-#
-# Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-# All rights reserved.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions
-# are met:
-#
-# * Redistributions of source code must retain the above copyright
-# notice, this list of conditions and the following disclaimer.
-# * Redistributions in binary form must reproduce the above copyright
-# notice, this list of conditions and the following disclaimer in
-# the documentation and/or other materials provided with the
-# distribution.
-# * Neither the name of Intel Corporation nor the names of its
-# contributors may be used to endorse or promote products derived
-# from this software without specific prior written permission.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-# Build directory is given with O=
-ifdef O
-BUILD_DIR=$(O)
-else
-BUILD_DIR=.
-endif
-
-# Targets to install can be specified in command line. It can be a
-# target name or a name containing jokers "*". Example:
-# x86_64-native-*-gcc
-ifndef T
-T=*
-endif
-
-#
-# install: build sdk for all supported targets
-#
-INSTALL_CONFIGS := $(patsubst $(RTE_SRCDIR)/config/defconfig_%,%,\
- $(wildcard $(RTE_SRCDIR)/config/defconfig_$(T)))
-INSTALL_TARGETS := $(addsuffix _install,\
- $(filter-out %~,$(INSTALL_CONFIGS)))
-
-.PHONY: install
-install: $(INSTALL_TARGETS)
-
-%_install:
- @echo ================== Installing $*
- $(Q)if [ ! -f $(BUILD_DIR)/$*/.config ]; then \
- $(MAKE) config T=$* O=$(BUILD_DIR)/$*; \
- elif cmp -s $(BUILD_DIR)/$*/.config.orig $(BUILD_DIR)/$*/.config; then \
- $(MAKE) config T=$* O=$(BUILD_DIR)/$*; \
- else \
- if [ -f $(BUILD_DIR)/$*/.config.orig ] ; then \
- tmp_build=$(BUILD_DIR)/$*/.config.tmp; \
- $(MAKE) config T=$* O=$$tmp_build; \
- if ! cmp -s $(BUILD_DIR)/$*/.config.orig $$tmp_build/.config ; then \
- echo "Conflict: local config and template config have both changed"; \
- exit 1; \
- fi; \
- fi; \
- echo "Using local configuration"; \
- fi
- $(Q)$(MAKE) all O=$(BUILD_DIR)/$*
-
-#
-# uninstall: remove all built sdk
-#
-UNINSTALL_TARGETS := $(addsuffix _uninstall,\
- $(filter-out %~,$(INSTALL_CONFIGS)))
-
-.PHONY: uninstall
-uninstall: $(UNINSTALL_TARGETS)
-
-%_uninstall:
- @echo ================== Uninstalling $*
- $(Q)rm -rf $(BUILD_DIR)/$*
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index e8423b0..7f451d5 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -98,8 +98,17 @@ testall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@
.PHONY: install uninstall
-install uninstall:
- $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
+#install uninstall:
+# $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
+install:
+ $(Q)echo "'make install' is deprecated. Use 'make sdk' instead"
+
+uninstall:
+ $(Q)echo "'make uninstall' is deprecated. Use 'make clean-sdk' instead"
+
+.PHONY: sdk clean-sdk
+sdk clean-sdk:
+ $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdk.mk $@
.PHONY: doc help
doc: doc-all
diff --git a/scripts/gen-build-mk.sh b/scripts/gen-build-mk.sh
index 5c12813..37ec771 100755
--- a/scripts/gen-build-mk.sh
+++ b/scripts/gen-build-mk.sh
@@ -46,7 +46,7 @@ echo "endif"
echo
echo "MAKEFLAGS += --no-print-directory"
echo
-echo "all:"
+echo "all sdk:"
echo " @\$(MAKE) -C $1 O=$2"
echo
echo "%::"
diff --git a/tools/setup.sh b/tools/setup.sh
index 5a8b2f3..eb7a461 100755
--- a/tools/setup.sh
+++ b/tools/setup.sh
@@ -80,7 +80,7 @@ setup_icc()
}
#
-# Sets RTE_TARGET and does a "make install".
+# Sets RTE_TARGET and does a "make sdk".
#
setup_target()
{
@@ -97,7 +97,7 @@ setup_target()
fi
fi
if [ "$QUIT" == "0" ] ; then
- make install T=${RTE_TARGET}
+ make sdk T=${RTE_TARGET}
fi
echo "------------------------------------------------------------------------------"
echo " RTE_TARGET exported as $RTE_TARGET"
@@ -109,7 +109,7 @@ setup_target()
#
uninstall_targets()
{
- make uninstall
+ make clean-sdk
}
#
--
2.5.0
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH] mk: fix ABI versioning compile error for combined shared library
2015-11-02 15:23 4% ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
2015-11-02 16:26 4% ` Thomas Monjalon
2015-11-03 7:06 4% ` Panu Matilainen
@ 2015-11-06 13:58 7% ` Ferruh Yigit
2015-11-06 13:58 4% ` Ferruh Yigit
2 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-11-06 13:58 UTC (permalink / raw)
To: dev
Sorry for duplication, previous patch is not in the patchwork, this is the
exact same patch and re-sent for patchwork.
Ferruh Yigit (1):
mk: fix ABI versioning compile error for combined shared library
drivers/net/Makefile | 3 +++
lib/Makefile | 3 +++
lib/libdpdk.map | 12 ++++++++++++
mk/rte.sdkbuild.mk | 2 +-
mk/rte.sharelib.mk | 1 +
5 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 lib/libdpdk.map
--
2.5.0
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [PATCH] mk: fix ABI versioning compile error for combined shared library
2015-11-06 13:58 7% ` [dpdk-dev] [PATCH] " Ferruh Yigit
@ 2015-11-06 13:58 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2015-11-06 13:58 UTC (permalink / raw)
To: dev
Fixes following error:
LD libdpdk.so
/usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
for symbol <function>@DPDK_x.y
Defines version symbols in a fixed path libdpdk.map file and this
value hardcoded into makefile
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
drivers/net/Makefile | 3 +++
lib/Makefile | 3 +++
lib/libdpdk.map | 12 ++++++++++++
mk/rte.sdkbuild.mk | 2 +-
mk/rte.sharelib.mk | 1 +
5 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 lib/libdpdk.map
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 6da1ce2..d30018c 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -50,5 +50,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
+ifeq ($(COMBINED_BUILD),1)
include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/lib/Makefile b/lib/Makefile
index 9727b83..33d76a6 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -62,5 +62,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
endif
+ifeq ($(COMBINED_BUILD),1)
include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/lib/libdpdk.map b/lib/libdpdk.map
new file mode 100644
index 0000000..3988a3f
--- /dev/null
+++ b/lib/libdpdk.map
@@ -0,0 +1,12 @@
+DPDK_2.0 {
+
+};
+
+DPDK_2.1 {
+
+} DPDK_2.0;
+
+DPDK_2.2 {
+
+} DPDK_2.1;
+
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 38ec7bd..d4e3abf 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -94,7 +94,7 @@ $(ROOTDIRS-y):
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
@if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
- $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
+ COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
fi
%_clean:
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
index 7bb7219..1f71fcb 100644
--- a/mk/rte.sharelib.mk
+++ b/mk/rte.sharelib.mk
@@ -40,6 +40,7 @@ LIB_ONE := lib$(RTE_LIBNAME).so
else
LIB_ONE := lib$(RTE_LIBNAME).a
endif
+CPU_LDFLAGS += --version-script=$(SRCDIR)/lib/libdpdk.map
endif
.PHONY:sharelib
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] cmdline: increase commandline buffer size to 512
2015-11-05 16:50 3% ` Nélio Laranjeiro
@ 2015-11-09 11:45 4% ` Mcnamara, John
2015-11-09 15:54 0% ` Nélio Laranjeiro
0 siblings, 1 reply; 200+ results
From: Mcnamara, John @ 2015-11-09 11:45 UTC (permalink / raw)
To: Nélio Laranjeiro, Olivier Matz, Thomas Monjalon; +Cc: dev
> -----Original Message-----
> From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> Sent: Thursday, November 5, 2015 4:51 PM
> To: Mcnamara, John; Olivier Matz; Thomas Monjalon
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] cmdline: increase commandline buffer size
> to 512
>
> On Thu, Nov 05, 2015 at 09:58:36AM +0000, John McNamara wrote:
> > Increase commandline buffer size to 512 to allow for longer
> > commandlines required by testpmd when dealing with flow director and
> > IPv6 addresses.
> >
> > ...
> >
> > /* configuration */
> > -#define RDLINE_BUF_SIZE 256
> > +#define RDLINE_BUF_SIZE 512
> >
>
> I have faced the same issue. For some commands this value is still too
> low. For example, RETA update can not be used, the command line limits
> he configuration to 34 entries.
>
> See http://dpdk.org/ml/archives/dev/2015-October/024681.html
> and particularly
> http://dpdk.org/ml/archives/dev/2015-October/024682.html
>
> It was too late to announce an ABI change so we left out the cmdline
> size update.
>
> Olivier, Thomas, what do you think about this? It seems this is really
> blocking.
Hi,
Since the change breaks ABI I'll self nack.
However, this is something that should be fixed since it will affect any DPDK application with a long commandline.
I can put a warning of future ABI breakage in the release notes but I see that there are other #defines that you need to increase in your patchset so do you want to submit the ABI deprecation notice?
John.
--
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] cmdline: increase commandline buffer size to 512
2015-11-09 11:45 4% ` Mcnamara, John
@ 2015-11-09 15:54 0% ` Nélio Laranjeiro
0 siblings, 0 replies; 200+ results
From: Nélio Laranjeiro @ 2015-11-09 15:54 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev
On Mon, Nov 09, 2015 at 11:45:04AM +0000, Mcnamara, John wrote:
>
>
> > -----Original Message-----
> > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > Sent: Thursday, November 5, 2015 4:51 PM
> > To: Mcnamara, John; Olivier Matz; Thomas Monjalon
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] cmdline: increase commandline buffer size
> > to 512
> >
> > On Thu, Nov 05, 2015 at 09:58:36AM +0000, John McNamara wrote:
> > > Increase commandline buffer size to 512 to allow for longer
> > > commandlines required by testpmd when dealing with flow director and
> > > IPv6 addresses.
> > >
> > > ...
> > >
> > > /* configuration */
> > > -#define RDLINE_BUF_SIZE 256
> > > +#define RDLINE_BUF_SIZE 512
> > >
> >
> > I have faced the same issue. For some commands this value is still too
> > low. For example, RETA update can not be used, the command line limits
> > he configuration to 34 entries.
> >
> > See http://dpdk.org/ml/archives/dev/2015-October/024681.html
> > and particularly
> > http://dpdk.org/ml/archives/dev/2015-October/024682.html
> >
> > It was too late to announce an ABI change so we left out the cmdline
> > size update.
> >
> > Olivier, Thomas, what do you think about this? It seems this is really
> > blocking.
>
> Hi,
>
> Since the change breaks ABI I'll self nack.
>
> However, this is something that should be fixed since it will affect any DPDK application with a long commandline.
>
> I can put a warning of future ABI breakage in the release notes but I see that there are other #defines that you need to increase in your patchset so do you want to submit the ABI deprecation notice?
>
> John.
> --
Hi John,
I will do it, I have another depreciation related to RETA.
Thanks.
--
Nélio Laranjeiro
6WIND
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size
@ 2015-11-09 16:48 9% Nelio Laranjeiro
2015-11-09 16:48 9% ` [dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA configuration Nelio Laranjeiro
2015-11-10 17:29 4% ` [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size Mcnamara, John
0 siblings, 2 replies; 200+ results
From: Nelio Laranjeiro @ 2015-11-09 16:48 UTC (permalink / raw)
To: dev
Current buffer size are not enough for a few testpmd commands.
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 730c3b7..c75b4b4 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -47,3 +47,8 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
+
+* ABI changes are planned in cmdline buffer size to allow the use of long
+ commands (such as RETA update in testpmd). This should impact
+ CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
+ It should be integrated in release 2.3.
--
2.1.4
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA configuration
2015-11-09 16:48 9% [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size Nelio Laranjeiro
@ 2015-11-09 16:48 9% ` Nelio Laranjeiro
2015-11-10 17:29 4% ` [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size Mcnamara, John
1 sibling, 0 replies; 200+ results
From: Nelio Laranjeiro @ 2015-11-09 16:48 UTC (permalink / raw)
To: dev
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index c75b4b4..8554c53 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -52,3 +52,8 @@ Deprecation Notices
commands (such as RETA update in testpmd). This should impact
CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
It should be integrated in release 2.3.
+
+* ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
+ which handles at most 256 entries (8 bits) while newer NICs support larger
+ tables (512 entries).
+ It should be integrated in release 2.3.
--
2.1.4
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v3 1/2] vhost: Add callback and private data for vhost PMD
@ 2015-11-09 18:16 3% ` Aaron Conole
2015-11-10 3:13 0% ` Tetsuya Mukawa
0 siblings, 1 reply; 200+ results
From: Aaron Conole @ 2015-11-09 18:16 UTC (permalink / raw)
To: Tetsuya Mukawa; +Cc: dev, ann.zhuangyanying
Greetings,
Tetsuya Mukawa <mukawa@igel.co.jp> writes:
> These variables are needed to be able to manage one of virtio devices
> using both vhost library APIs and vhost PMD.
> For example, if vhost PMD uses current callback handler and private data
> provided by vhost library, A DPDK application that links vhost library
> cannot use some of vhost library APIs. To avoid it, callback and private
> data for vhost PMD are needed.
>
> Signed-off-by: Tetsuya Mukawa <mukawa@igel.co.jp>
> ---
> lib/librte_vhost/rte_vhost_version.map | 6 +++
> lib/librte_vhost/rte_virtio_net.h | 3 ++
> lib/librte_vhost/vhost_user/virtio-net-user.c | 13 +++----
> lib/librte_vhost/virtio-net.c | 56 +++++++++++++++++++++++++--
> lib/librte_vhost/virtio-net.h | 4 +-
> 5 files changed, 70 insertions(+), 12 deletions(-)
>
> diff --git a/lib/librte_vhost/rte_vhost_version.map b/lib/librte_vhost/rte_vhost_version.map
> index 3d8709e..00a9ce5 100644
> --- a/lib/librte_vhost/rte_vhost_version.map
> +++ b/lib/librte_vhost/rte_vhost_version.map
> @@ -20,3 +20,9 @@ DPDK_2.1 {
> rte_vhost_driver_unregister;
>
> } DPDK_2.0;
> +
> +DPDK_2.2 {
> + global:
> +
> + rte_vhost_driver_pmd_callback_register;
> +} DPDK_2.1;
> diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
> index 5687452..3ef6e58 100644
> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -128,6 +128,7 @@ struct virtio_net {
> char ifname[IF_NAME_SZ]; /**< Name of the tap device or socket path. */
> uint32_t virt_qp_nb; /**< number of queue pair we have allocated */
> void *priv; /**< private context */
> + void *pmd_priv; /**< private context for vhost PMD */
> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
> } __rte_cache_aligned;
Sorry if I'm missing something, but this is an ABI breaker, isn't it? I
think this needs the RTE_NEXT_ABI tag around it.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow
@ 2015-11-10 3:11 11% Jingjing Wu
2015-11-12 3:10 4% ` Lu, Wenzhuo
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Jingjing Wu @ 2015-11-10 3:11 UTC (permalink / raw)
To: dev
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 549ecb9..1a4614d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -32,3 +32,7 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
+
+* ABI changes are planned for struct rte_eth_fdir_flow in order to support
+ extend flow director's input set. The release 2.2 does not contain these ABI
+ changes, but release 2.3 will, and no backwards compatibility is planned.
--
2.4.0
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH v3 1/2] vhost: Add callback and private data for vhost PMD
2015-11-09 18:16 3% ` Aaron Conole
@ 2015-11-10 3:13 0% ` Tetsuya Mukawa
2015-11-10 7:16 3% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Tetsuya Mukawa @ 2015-11-10 3:13 UTC (permalink / raw)
To: Aaron Conole; +Cc: dev, ann.zhuangyanying
On 2015/11/10 3:16, Aaron Conole wrote:
> Greetings,
>
> Tetsuya Mukawa <mukawa@igel.co.jp> writes:
>> These variables are needed to be able to manage one of virtio devices
>> using both vhost library APIs and vhost PMD.
>> For example, if vhost PMD uses current callback handler and private data
>> provided by vhost library, A DPDK application that links vhost library
>> cannot use some of vhost library APIs. To avoid it, callback and private
>> data for vhost PMD are needed.
>>
>> Signed-off-by: Tetsuya Mukawa <mukawa@igel.co.jp>
>> ---
>> lib/librte_vhost/rte_vhost_version.map | 6 +++
>> lib/librte_vhost/rte_virtio_net.h | 3 ++
>> lib/librte_vhost/vhost_user/virtio-net-user.c | 13 +++----
>> lib/librte_vhost/virtio-net.c | 56 +++++++++++++++++++++++++--
>> lib/librte_vhost/virtio-net.h | 4 +-
>> 5 files changed, 70 insertions(+), 12 deletions(-)
>>
>> diff --git a/lib/librte_vhost/rte_vhost_version.map b/lib/librte_vhost/rte_vhost_version.map
>> index 3d8709e..00a9ce5 100644
>> --- a/lib/librte_vhost/rte_vhost_version.map
>> +++ b/lib/librte_vhost/rte_vhost_version.map
>> @@ -20,3 +20,9 @@ DPDK_2.1 {
>> rte_vhost_driver_unregister;
>>
>> } DPDK_2.0;
>> +
>> +DPDK_2.2 {
>> + global:
>> +
>> + rte_vhost_driver_pmd_callback_register;
>> +} DPDK_2.1;
>> diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
>> index 5687452..3ef6e58 100644
>> --- a/lib/librte_vhost/rte_virtio_net.h
>> +++ b/lib/librte_vhost/rte_virtio_net.h
>> @@ -128,6 +128,7 @@ struct virtio_net {
>> char ifname[IF_NAME_SZ]; /**< Name of the tap device or socket path. */
>> uint32_t virt_qp_nb; /**< number of queue pair we have allocated */
>> void *priv; /**< private context */
>> + void *pmd_priv; /**< private context for vhost PMD */
>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
>> } __rte_cache_aligned;
> Sorry if I'm missing something, but this is an ABI breaker, isn't it? I
> think this needs the RTE_NEXT_ABI tag around it.
Hi Aaron,
Thanks for reviewing. Yes, your are correct.
I guess I can implement vhost PMD without this variable, so I will
remove it.
Thanks,
Tetsuya
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_filter_conf
@ 2015-11-10 3:49 11% Jingjing Wu
2015-11-12 3:11 4% ` Lu, Wenzhuo
2015-11-12 3:23 4% ` Zhang, Helin
0 siblings, 2 replies; 200+ results
From: Jingjing Wu @ 2015-11-10 3:49 UTC (permalink / raw)
To: dev
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 549ecb9..57c8b7a 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -32,3 +32,8 @@ Deprecation Notices
and table action handlers will be updated:
the pipeline parameter will be added, the packets mask parameter will be
either removed (for input port action handler) or made input-only.
+
+* ABI changes are planned for rte_eth_tunnel_filter_conf. Change the fields
+ of outer_mac and inner_mac from pointer to struct in order to keep the
+ code's readability. The release 2.2 does not contain these ABI changes, but
+ release 2.3 will, and no backwards compatibility is planned.
--
2.4.0
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH v3 1/2] vhost: Add callback and private data for vhost PMD
2015-11-10 3:13 0% ` Tetsuya Mukawa
@ 2015-11-10 7:16 3% ` Panu Matilainen
2015-11-10 9:48 3% ` Tetsuya Mukawa
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-11-10 7:16 UTC (permalink / raw)
To: Tetsuya Mukawa, Aaron Conole; +Cc: dev, ann.zhuangyanying
On 11/10/2015 05:13 AM, Tetsuya Mukawa wrote:
> On 2015/11/10 3:16, Aaron Conole wrote:
>> Greetings,
>>
>> Tetsuya Mukawa <mukawa@igel.co.jp> writes:
>>> These variables are needed to be able to manage one of virtio devices
>>> using both vhost library APIs and vhost PMD.
>>> For example, if vhost PMD uses current callback handler and private data
>>> provided by vhost library, A DPDK application that links vhost library
>>> cannot use some of vhost library APIs. To avoid it, callback and private
>>> data for vhost PMD are needed.
>>>
>>> Signed-off-by: Tetsuya Mukawa <mukawa@igel.co.jp>
>>> ---
>>> lib/librte_vhost/rte_vhost_version.map | 6 +++
>>> lib/librte_vhost/rte_virtio_net.h | 3 ++
>>> lib/librte_vhost/vhost_user/virtio-net-user.c | 13 +++----
>>> lib/librte_vhost/virtio-net.c | 56 +++++++++++++++++++++++++--
>>> lib/librte_vhost/virtio-net.h | 4 +-
>>> 5 files changed, 70 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/lib/librte_vhost/rte_vhost_version.map b/lib/librte_vhost/rte_vhost_version.map
>>> index 3d8709e..00a9ce5 100644
>>> --- a/lib/librte_vhost/rte_vhost_version.map
>>> +++ b/lib/librte_vhost/rte_vhost_version.map
>>> @@ -20,3 +20,9 @@ DPDK_2.1 {
>>> rte_vhost_driver_unregister;
>>>
>>> } DPDK_2.0;
>>> +
>>> +DPDK_2.2 {
>>> + global:
>>> +
>>> + rte_vhost_driver_pmd_callback_register;
>>> +} DPDK_2.1;
>>> diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
>>> index 5687452..3ef6e58 100644
>>> --- a/lib/librte_vhost/rte_virtio_net.h
>>> +++ b/lib/librte_vhost/rte_virtio_net.h
>>> @@ -128,6 +128,7 @@ struct virtio_net {
>>> char ifname[IF_NAME_SZ]; /**< Name of the tap device or socket path. */
>>> uint32_t virt_qp_nb; /**< number of queue pair we have allocated */
>>> void *priv; /**< private context */
>>> + void *pmd_priv; /**< private context for vhost PMD */
>>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
>>> } __rte_cache_aligned;
>> Sorry if I'm missing something, but this is an ABI breaker, isn't it? I
>> think this needs the RTE_NEXT_ABI tag around it.
>
> Hi Aaron,
>
> Thanks for reviewing. Yes, your are correct.
> I guess I can implement vhost PMD without this variable, so I will
> remove it.
No need to.
The librte_vhost ABI has already been broken during the DPDK 2.2 cycle
by the multiqueue changes, but that's okay since it was announced during
2.1 cycle (in commit 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d).
What is missing right now is bumping the library version, and that must
happen before 2.2 is released.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3 1/2] vhost: Add callback and private data for vhost PMD
2015-11-10 7:16 3% ` Panu Matilainen
@ 2015-11-10 9:48 3% ` Tetsuya Mukawa
2015-11-10 10:05 3% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Tetsuya Mukawa @ 2015-11-10 9:48 UTC (permalink / raw)
To: Panu Matilainen, Aaron Conole; +Cc: dev, ann.zhuangyanying
On 2015/11/10 16:16, Panu Matilainen wrote:
> On 11/10/2015 05:13 AM, Tetsuya Mukawa wrote:
>> On 2015/11/10 3:16, Aaron Conole wrote:
>>> Greetings,
>>>
>>> Tetsuya Mukawa <mukawa@igel.co.jp> writes:
>>>> These variables are needed to be able to manage one of virtio devices
>>>> using both vhost library APIs and vhost PMD.
>>>> For example, if vhost PMD uses current callback handler and private
>>>> data
>>>> provided by vhost library, A DPDK application that links vhost library
>>>> cannot use some of vhost library APIs. To avoid it, callback and
>>>> private
>>>> data for vhost PMD are needed.
>>>>
>>>> Signed-off-by: Tetsuya Mukawa <mukawa@igel.co.jp>
>>>> ---
>>>> lib/librte_vhost/rte_vhost_version.map | 6 +++
>>>> lib/librte_vhost/rte_virtio_net.h | 3 ++
>>>> lib/librte_vhost/vhost_user/virtio-net-user.c | 13 +++----
>>>> lib/librte_vhost/virtio-net.c | 56
>>>> +++++++++++++++++++++++++--
>>>> lib/librte_vhost/virtio-net.h | 4 +-
>>>> 5 files changed, 70 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/lib/librte_vhost/rte_vhost_version.map
>>>> b/lib/librte_vhost/rte_vhost_version.map
>>>> index 3d8709e..00a9ce5 100644
>>>> --- a/lib/librte_vhost/rte_vhost_version.map
>>>> +++ b/lib/librte_vhost/rte_vhost_version.map
>>>> @@ -20,3 +20,9 @@ DPDK_2.1 {
>>>> rte_vhost_driver_unregister;
>>>>
>>>> } DPDK_2.0;
>>>> +
>>>> +DPDK_2.2 {
>>>> + global:
>>>> +
>>>> + rte_vhost_driver_pmd_callback_register;
>>>> +} DPDK_2.1;
>>>> diff --git a/lib/librte_vhost/rte_virtio_net.h
>>>> b/lib/librte_vhost/rte_virtio_net.h
>>>> index 5687452..3ef6e58 100644
>>>> --- a/lib/librte_vhost/rte_virtio_net.h
>>>> +++ b/lib/librte_vhost/rte_virtio_net.h
>>>> @@ -128,6 +128,7 @@ struct virtio_net {
>>>> char ifname[IF_NAME_SZ]; /**< Name of the tap
>>>> device or socket path. */
>>>> uint32_t virt_qp_nb; /**< number of queue pair we
>>>> have allocated */
>>>> void *priv; /**< private context */
>>>> + void *pmd_priv; /**< private context for vhost
>>>> PMD */
>>>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS *
>>>> 2]; /**< Contains all virtqueue information. */
>>>> } __rte_cache_aligned;
>>> Sorry if I'm missing something, but this is an ABI breaker, isn't it? I
>>> think this needs the RTE_NEXT_ABI tag around it.
>>
>> Hi Aaron,
>>
>> Thanks for reviewing. Yes, your are correct.
>> I guess I can implement vhost PMD without this variable, so I will
>> remove it.
>
> No need to.
>
> The librte_vhost ABI has already been broken during the DPDK 2.2 cycle
> by the multiqueue changes, but that's okay since it was announced
> during 2.1 cycle (in commit 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d).
>
> What is missing right now is bumping the library version, and that
> must happen before 2.2 is released.
>
> - Panu -
>
>
Hi Panu,
Thank you so much. Let me make sure what you mean.
I guess I need to add RTE_NEXT_ABI tags where pmd_priv is used. This is
because we don't break DPDK-2.1 ABI.
Anyway, the tag will be removed when DPDK-2.2 is released, then we can
use vhost PMD.
Is this correct?
Thanks,
Tetsuya
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3 1/2] vhost: Add callback and private data for vhost PMD
2015-11-10 9:48 3% ` Tetsuya Mukawa
@ 2015-11-10 10:05 3% ` Panu Matilainen
2015-11-10 10:15 0% ` Tetsuya Mukawa
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-11-10 10:05 UTC (permalink / raw)
To: Tetsuya Mukawa, Aaron Conole; +Cc: dev, ann.zhuangyanying
On 11/10/2015 11:48 AM, Tetsuya Mukawa wrote:
> On 2015/11/10 16:16, Panu Matilainen wrote:
>> On 11/10/2015 05:13 AM, Tetsuya Mukawa wrote:
>>> On 2015/11/10 3:16, Aaron Conole wrote:
>>>> Greetings,
>>>>
>>>> Tetsuya Mukawa <mukawa@igel.co.jp> writes:
>>>>> These variables are needed to be able to manage one of virtio devices
>>>>> using both vhost library APIs and vhost PMD.
>>>>> For example, if vhost PMD uses current callback handler and private
>>>>> data
>>>>> provided by vhost library, A DPDK application that links vhost library
>>>>> cannot use some of vhost library APIs. To avoid it, callback and
>>>>> private
>>>>> data for vhost PMD are needed.
>>>>>
>>>>> Signed-off-by: Tetsuya Mukawa <mukawa@igel.co.jp>
>>>>> ---
>>>>> lib/librte_vhost/rte_vhost_version.map | 6 +++
>>>>> lib/librte_vhost/rte_virtio_net.h | 3 ++
>>>>> lib/librte_vhost/vhost_user/virtio-net-user.c | 13 +++----
>>>>> lib/librte_vhost/virtio-net.c | 56
>>>>> +++++++++++++++++++++++++--
>>>>> lib/librte_vhost/virtio-net.h | 4 +-
>>>>> 5 files changed, 70 insertions(+), 12 deletions(-)
>>>>>
>>>>> diff --git a/lib/librte_vhost/rte_vhost_version.map
>>>>> b/lib/librte_vhost/rte_vhost_version.map
>>>>> index 3d8709e..00a9ce5 100644
>>>>> --- a/lib/librte_vhost/rte_vhost_version.map
>>>>> +++ b/lib/librte_vhost/rte_vhost_version.map
>>>>> @@ -20,3 +20,9 @@ DPDK_2.1 {
>>>>> rte_vhost_driver_unregister;
>>>>>
>>>>> } DPDK_2.0;
>>>>> +
>>>>> +DPDK_2.2 {
>>>>> + global:
>>>>> +
>>>>> + rte_vhost_driver_pmd_callback_register;
>>>>> +} DPDK_2.1;
>>>>> diff --git a/lib/librte_vhost/rte_virtio_net.h
>>>>> b/lib/librte_vhost/rte_virtio_net.h
>>>>> index 5687452..3ef6e58 100644
>>>>> --- a/lib/librte_vhost/rte_virtio_net.h
>>>>> +++ b/lib/librte_vhost/rte_virtio_net.h
>>>>> @@ -128,6 +128,7 @@ struct virtio_net {
>>>>> char ifname[IF_NAME_SZ]; /**< Name of the tap
>>>>> device or socket path. */
>>>>> uint32_t virt_qp_nb; /**< number of queue pair we
>>>>> have allocated */
>>>>> void *priv; /**< private context */
>>>>> + void *pmd_priv; /**< private context for vhost
>>>>> PMD */
>>>>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS *
>>>>> 2]; /**< Contains all virtqueue information. */
>>>>> } __rte_cache_aligned;
>>>> Sorry if I'm missing something, but this is an ABI breaker, isn't it? I
>>>> think this needs the RTE_NEXT_ABI tag around it.
>>>
>>> Hi Aaron,
>>>
>>> Thanks for reviewing. Yes, your are correct.
>>> I guess I can implement vhost PMD without this variable, so I will
>>> remove it.
>>
>> No need to.
>>
>> The librte_vhost ABI has already been broken during the DPDK 2.2 cycle
>> by the multiqueue changes, but that's okay since it was announced
>> during 2.1 cycle (in commit 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d).
>>
>> What is missing right now is bumping the library version, and that
>> must happen before 2.2 is released.
>>
>> - Panu -
>>
>>
>
> Hi Panu,
>
> Thank you so much. Let me make sure what you mean.
> I guess I need to add RTE_NEXT_ABI tags where pmd_priv is used. This is
> because we don't break DPDK-2.1 ABI.
> Anyway, the tag will be removed when DPDK-2.2 is released, then we can
> use vhost PMD.
> Is this correct?
Not quite. Because the ABI has already been broken between 2.1 and 2.2,
you can ride the same wave without messing with NEXT_ABI and such.
Like said, librte_vhost is pending a LIBABIVER bump to 2, but that is
regardless of this patch.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3 1/2] vhost: Add callback and private data for vhost PMD
2015-11-10 10:05 3% ` Panu Matilainen
@ 2015-11-10 10:15 0% ` Tetsuya Mukawa
0 siblings, 0 replies; 200+ results
From: Tetsuya Mukawa @ 2015-11-10 10:15 UTC (permalink / raw)
To: Panu Matilainen, Aaron Conole; +Cc: dev, ann.zhuangyanying
On 2015/11/10 19:05, Panu Matilainen wrote:
> On 11/10/2015 11:48 AM, Tetsuya Mukawa wrote:
>> On 2015/11/10 16:16, Panu Matilainen wrote:
>>> On 11/10/2015 05:13 AM, Tetsuya Mukawa wrote:
>>>> On 2015/11/10 3:16, Aaron Conole wrote:
>>>>> Greetings,
>>>>>
>>>>> Tetsuya Mukawa <mukawa@igel.co.jp> writes:
>>>>>> These variables are needed to be able to manage one of virtio
>>>>>> devices
>>>>>> using both vhost library APIs and vhost PMD.
>>>>>> For example, if vhost PMD uses current callback handler and private
>>>>>> data
>>>>>> provided by vhost library, A DPDK application that links vhost
>>>>>> library
>>>>>> cannot use some of vhost library APIs. To avoid it, callback and
>>>>>> private
>>>>>> data for vhost PMD are needed.
>>>>>>
>>>>>> Signed-off-by: Tetsuya Mukawa <mukawa@igel.co.jp>
>>>>>> ---
>>>>>> lib/librte_vhost/rte_vhost_version.map | 6 +++
>>>>>> lib/librte_vhost/rte_virtio_net.h | 3 ++
>>>>>> lib/librte_vhost/vhost_user/virtio-net-user.c | 13 +++----
>>>>>> lib/librte_vhost/virtio-net.c | 56
>>>>>> +++++++++++++++++++++++++--
>>>>>> lib/librte_vhost/virtio-net.h | 4 +-
>>>>>> 5 files changed, 70 insertions(+), 12 deletions(-)
>>>>>>
>>>>>> diff --git a/lib/librte_vhost/rte_vhost_version.map
>>>>>> b/lib/librte_vhost/rte_vhost_version.map
>>>>>> index 3d8709e..00a9ce5 100644
>>>>>> --- a/lib/librte_vhost/rte_vhost_version.map
>>>>>> +++ b/lib/librte_vhost/rte_vhost_version.map
>>>>>> @@ -20,3 +20,9 @@ DPDK_2.1 {
>>>>>> rte_vhost_driver_unregister;
>>>>>>
>>>>>> } DPDK_2.0;
>>>>>> +
>>>>>> +DPDK_2.2 {
>>>>>> + global:
>>>>>> +
>>>>>> + rte_vhost_driver_pmd_callback_register;
>>>>>> +} DPDK_2.1;
>>>>>> diff --git a/lib/librte_vhost/rte_virtio_net.h
>>>>>> b/lib/librte_vhost/rte_virtio_net.h
>>>>>> index 5687452..3ef6e58 100644
>>>>>> --- a/lib/librte_vhost/rte_virtio_net.h
>>>>>> +++ b/lib/librte_vhost/rte_virtio_net.h
>>>>>> @@ -128,6 +128,7 @@ struct virtio_net {
>>>>>> char ifname[IF_NAME_SZ]; /**< Name of the tap
>>>>>> device or socket path. */
>>>>>> uint32_t virt_qp_nb; /**< number of queue pair we
>>>>>> have allocated */
>>>>>> void *priv; /**< private context */
>>>>>> + void *pmd_priv; /**< private context for vhost
>>>>>> PMD */
>>>>>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS *
>>>>>> 2]; /**< Contains all virtqueue information. */
>>>>>> } __rte_cache_aligned;
>>>>> Sorry if I'm missing something, but this is an ABI breaker, isn't
>>>>> it? I
>>>>> think this needs the RTE_NEXT_ABI tag around it.
>>>>
>>>> Hi Aaron,
>>>>
>>>> Thanks for reviewing. Yes, your are correct.
>>>> I guess I can implement vhost PMD without this variable, so I will
>>>> remove it.
>>>
>>> No need to.
>>>
>>> The librte_vhost ABI has already been broken during the DPDK 2.2 cycle
>>> by the multiqueue changes, but that's okay since it was announced
>>> during 2.1 cycle (in commit 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d).
>>>
>>> What is missing right now is bumping the library version, and that
>>> must happen before 2.2 is released.
>>>
>>> - Panu -
>>>
>>>
>>
>> Hi Panu,
>>
>> Thank you so much. Let me make sure what you mean.
>> I guess I need to add RTE_NEXT_ABI tags where pmd_priv is used. This is
>> because we don't break DPDK-2.1 ABI.
>> Anyway, the tag will be removed when DPDK-2.2 is released, then we can
>> use vhost PMD.
>> Is this correct?
>
> Not quite. Because the ABI has already been broken between 2.1 and
> 2.2, you can ride the same wave without messing with NEXT_ABI and such.
>
> Like said, librte_vhost is pending a LIBABIVER bump to 2, but that is
> regardless of this patch.
>
> - Panu -
>
Thanks. I can clearly understand.
Tetsuya
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size
2015-11-09 16:48 9% [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size Nelio Laranjeiro
2015-11-09 16:48 9% ` [dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA configuration Nelio Laranjeiro
@ 2015-11-10 17:29 4% ` Mcnamara, John
2015-11-20 16:28 4% ` Olivier MATZ
1 sibling, 1 reply; 200+ results
From: Mcnamara, John @ 2015-11-10 17:29 UTC (permalink / raw)
To: Nelio Laranjeiro, dev
> -----Original Message-----
> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> Sent: Monday, November 9, 2015 4:48 PM
> To: dev@dpdk.org
> Cc: olivier.matz@6wind.com; thomas.monjalon@6wind.com; Mcnamara, John; Lu,
> Wenzhuo
> Subject: [PATCH 1/2] doc: announce ABI change for cmdline buffer size
>
> Current buffer size are not enough for a few testpmd commands.
>
> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 0/3 v2] Minor abi-validator improvements
@ 2015-11-11 7:07 4% ` Panu Matilainen
2015-11-11 10:16 4% ` Thomas Monjalon
2015-12-03 19:38 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Panu Matilainen @ 2015-11-11 7:07 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On 09/24/2015 01:23 PM, Neil Horman wrote:
> On Thu, Sep 24, 2015 at 10:50:56AM +0300, Panu Matilainen wrote:
>> For giggles, tried running abi-validator between 2.0 and 2.1 on
>> my Fedora 22 laptop, didn't work due to various build failures.
>> With this patch series the following now succeeds:
>>
>> EXTRA_CFLAGS="-Wno-error" scripts/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linuxapp-gcc
>>
>> Panu Matilainen (3):
>> scripts: permit passing extra compiler & linker flags to ABI validator
>> scripts: move two identical config fixups into a function
>> scripts: teach ABI validator about CONFIG_RTE_KNI_KMOD
>>
>> scripts/validate-abi.sh | 28 ++++++++++++++--------------
>> 1 file changed, 14 insertions(+), 14 deletions(-)
>>
>> --
>> 2.4.3
>>
>>
>
> series
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Thomas, any particular reason this hasn't been applied yet?
- Panu -
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 0/3 v2] Minor abi-validator improvements
2015-11-11 7:07 4% ` Panu Matilainen
@ 2015-11-11 10:16 4% ` Thomas Monjalon
2015-11-11 10:24 4% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-11 10:16 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
2015-11-11 09:07, Panu Matilainen:
> On 09/24/2015 01:23 PM, Neil Horman wrote:
> > On Thu, Sep 24, 2015 at 10:50:56AM +0300, Panu Matilainen wrote:
> >> For giggles, tried running abi-validator between 2.0 and 2.1 on
> >> my Fedora 22 laptop, didn't work due to various build failures.
> >> With this patch series the following now succeeds:
> >>
> >> EXTRA_CFLAGS="-Wno-error" scripts/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linuxapp-gcc
> >>
> >> Panu Matilainen (3):
> >> scripts: permit passing extra compiler & linker flags to ABI validator
> >> scripts: move two identical config fixups into a function
> >> scripts: teach ABI validator about CONFIG_RTE_KNI_KMOD
> >>
> >> scripts/validate-abi.sh | 28 ++++++++++++++--------------
> >> 1 file changed, 14 insertions(+), 14 deletions(-)
> >>
> >> --
> >> 2.4.3
> >>
> >>
> >
> > series
> > Acked-by: Neil Horman <nhorman@tuxdriver.com>
>
> Thomas, any particular reason this hasn't been applied yet?
It was not the priority until now. I was busy with the drivers.
For next release, the integration should be easier because Bruce
will help with a drivers tree.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 0/3 v2] Minor abi-validator improvements
2015-11-11 10:16 4% ` Thomas Monjalon
@ 2015-11-11 10:24 4% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2015-11-11 10:24 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On 11/11/2015 12:16 PM, Thomas Monjalon wrote:
> 2015-11-11 09:07, Panu Matilainen:
>> On 09/24/2015 01:23 PM, Neil Horman wrote:
>>> On Thu, Sep 24, 2015 at 10:50:56AM +0300, Panu Matilainen wrote:
>>>> For giggles, tried running abi-validator between 2.0 and 2.1 on
>>>> my Fedora 22 laptop, didn't work due to various build failures.
>>>> With this patch series the following now succeeds:
>>>>
>>>> EXTRA_CFLAGS="-Wno-error" scripts/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linuxapp-gcc
>>>>
>>>> Panu Matilainen (3):
>>>> scripts: permit passing extra compiler & linker flags to ABI validator
>>>> scripts: move two identical config fixups into a function
>>>> scripts: teach ABI validator about CONFIG_RTE_KNI_KMOD
>>>>
>>>> scripts/validate-abi.sh | 28 ++++++++++++++--------------
>>>> 1 file changed, 14 insertions(+), 14 deletions(-)
>>>>
>>>> --
>>>> 2.4.3
>>>>
>>>>
>>>
>>> series
>>> Acked-by: Neil Horman <nhorman@tuxdriver.com>
>>
>> Thomas, any particular reason this hasn't been applied yet?
>
> It was not the priority until now. I was busy with the drivers.
> For next release, the integration should be easier because Bruce
> will help with a drivers tree.
>
Understood, no worries. Just checking it hasn't fallen through the
cracks due to some submission error on my behalf or something.
- Panu -
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow
2015-11-10 3:11 11% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow Jingjing Wu
@ 2015-11-12 3:10 4% ` Lu, Wenzhuo
2015-11-12 3:23 4% ` Zhang, Helin
2015-11-12 10:09 4% ` Chilikin, Andrey
2 siblings, 0 replies; 200+ results
From: Lu, Wenzhuo @ 2015-11-12 3:10 UTC (permalink / raw)
To: Wu, Jingjing, dev
Hi,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jingjing Wu
> Sent: Tuesday, November 10, 2015 11:11 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: announce ABI change for struct
> rte_eth_fdir_flow
>
> Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_filter_conf
2015-11-10 3:49 11% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_filter_conf Jingjing Wu
@ 2015-11-12 3:11 4% ` Lu, Wenzhuo
2015-11-12 3:23 4% ` Zhang, Helin
1 sibling, 0 replies; 200+ results
From: Lu, Wenzhuo @ 2015-11-12 3:11 UTC (permalink / raw)
To: Wu, Jingjing, dev
Hi,
> -----Original Message-----
> From: Wu, Jingjing
> Sent: Tuesday, November 10, 2015 11:50 AM
> To: dev@dpdk.org
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Zhang, Helin
> <helin.zhang@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>
> Subject: [PATCH] doc: announce ABI change for struct
> rte_eth_tunnel_filter_conf
>
> Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow
2015-11-10 3:11 11% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow Jingjing Wu
2015-11-12 3:10 4% ` Lu, Wenzhuo
@ 2015-11-12 3:23 4% ` Zhang, Helin
2015-11-12 10:09 4% ` Chilikin, Andrey
2 siblings, 0 replies; 200+ results
From: Zhang, Helin @ 2015-11-12 3:23 UTC (permalink / raw)
To: Wu, Jingjing, dev
> -----Original Message-----
> From: Wu, Jingjing
> Sent: Tuesday, November 10, 2015 11:11 AM
> To: dev@dpdk.org
> Cc: Wu, Jingjing; Zhang, Helin; Chilikin, Andrey
> Subject: [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow
>
> Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
Acked-by: Helin Zhang <helin.zhang@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_filter_conf
2015-11-10 3:49 11% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_filter_conf Jingjing Wu
2015-11-12 3:11 4% ` Lu, Wenzhuo
@ 2015-11-12 3:23 4% ` Zhang, Helin
1 sibling, 0 replies; 200+ results
From: Zhang, Helin @ 2015-11-12 3:23 UTC (permalink / raw)
To: Wu, Jingjing, dev
> -----Original Message-----
> From: Wu, Jingjing
> Sent: Tuesday, November 10, 2015 11:50 AM
> To: dev@dpdk.org
> Cc: Wu, Jingjing; Zhang, Helin; Lu, Wenzhuo
> Subject: [PATCH] doc: announce ABI change for struct rte_eth_tunnel_filter_conf
>
> Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
Acked-by: Helin Zhang <helin.zhang@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow
2015-11-10 3:11 11% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow Jingjing Wu
2015-11-12 3:10 4% ` Lu, Wenzhuo
2015-11-12 3:23 4% ` Zhang, Helin
@ 2015-11-12 10:09 4% ` Chilikin, Andrey
2 siblings, 0 replies; 200+ results
From: Chilikin, Andrey @ 2015-11-12 10:09 UTC (permalink / raw)
To: Wu, Jingjing, dev
> -----Original Message-----
> From: Wu, Jingjing
> Sent: Tuesday, November 10, 2015 3:11 AM
> To: dev@dpdk.org
> Cc: Wu, Jingjing; Zhang, Helin; Chilikin, Andrey
> Subject: [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow
>
> Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
Acked-by: Andrey Chilikin <andrey.chilikin@intel.com>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 00/10] rte_sched: enhancements and cleanups
@ 2015-11-13 17:54 3% Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2015-11-13 17:54 UTC (permalink / raw)
To: cristian.dumitrescu; +Cc: dev
Hierarchal scheduler changes.
Most of these are cleanups for existing code to make it more compatiable
with coding style, and eliminate #ifdefs.
The only substantive change is to allow more subports per scheduler
instance. This was submitted for DPDK 2.1 but since it required some
ABI finesse to change; the real part of this was held off for 2.2.
Stephen Hemminger (10):
qos: drop deprecated port hierarchy structure
qos: cleanup comments
qos: make debugging configurable
qos: drop debug #ifdef's for credit check
qos: remove debug conditional code around ENQUEUE
qos: drop RTE_SCHED_WRR #define
qos: cleanup defined constants
qos: allow enabling SSE optimizations in config
sched: fix coding style
sched: allow more subports
config/common_bsdapp | 2 +
config/common_linuxapp | 2 +
lib/librte_mbuf/rte_mbuf.h | 5 +-
lib/librte_sched/rte_sched.c | 565 +++++++++++++++++++------------------------
lib/librte_sched/rte_sched.h | 235 ++++++++++--------
5 files changed, 385 insertions(+), 424 deletions(-)
--
2.1.4
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2 00/10] rte_sched: enhancements and cleanups
@ 2015-11-13 17:58 3% Stephen Hemminger
2015-11-13 17:58 3% ` [dpdk-dev] [PATCH v2 10/10] sched: allow more subports Stephen Hemminger
2015-11-24 23:34 0% ` [dpdk-dev] [PATCH v2 00/10] rte_sched: enhancements and cleanups Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2015-11-13 17:58 UTC (permalink / raw)
To: cristian.dumitrescu; +Cc: dev
Hierarchal scheduler changes (resend)
Most of these are cleanups for existing code to make it more compatiable
with coding style, and eliminate #ifdefs.
The only substantive change is to allow more subports per scheduler
instance. This was submitted for DPDK 2.1 but since it required some
ABI finesse to change; the real part of this was held off for 2.2.
Stephen Hemminger (10):
qos: drop deprecated port hierarchy structure
qos: cleanup comments
qos: make debugging configurable
qos: drop debug #ifdef's for credit check
qos: remove debug conditional code around ENQUEUE
qos: drop RTE_SCHED_WRR #define
qos: cleanup defined constants
qos: allow enabling SSE optimizations in config
sched: fix coding style
sched: allow more subports
config/common_bsdapp | 2 +
config/common_linuxapp | 2 +
lib/librte_mbuf/rte_mbuf.h | 5 +-
lib/librte_sched/rte_sched.c | 565 +++++++++++++++++++------------------------
lib/librte_sched/rte_sched.h | 235 ++++++++++--------
5 files changed, 385 insertions(+), 424 deletions(-)
--
2.1.4
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2 10/10] sched: allow more subports
2015-11-13 17:58 3% [dpdk-dev] [PATCH v2 " Stephen Hemminger
@ 2015-11-13 17:58 3% ` Stephen Hemminger
2015-11-24 23:34 0% ` [dpdk-dev] [PATCH v2 00/10] rte_sched: enhancements and cleanups Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2015-11-13 17:58 UTC (permalink / raw)
To: cristian.dumitrescu; +Cc: dev, Stephen Hemminger
From: Stephen Hemminger <shemming@brocade.com>
Increase the number of possible subports per port to allow up to 16 bits.
It is still possible that this will require excessive RAM.
Although mbuf structure is changed, it is ABI compatiable since it
just expands existing sched part of structure to overlap pre-existing hole
in the hash element of structure.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_mbuf/rte_mbuf.h | 5 ++++-
lib/librte_sched/rte_sched.c | 14 +++++++++-----
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 4a93189..2dfcfef 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -799,7 +799,10 @@ struct rte_mbuf {
/**< First 4 flexible bytes or FD ID, dependent on
PKT_RX_FDIR_* flag in ol_flags. */
} fdir; /**< Filter identifier if FDIR enabled */
- uint32_t sched; /**< Hierarchical scheduler */
+ struct {
+ uint32_t lo;
+ uint32_t hi;
+ } sched; /**< Hierarchical scheduler */
uint32_t usr; /**< User defined tags. See rte_distributor_process() */
} hash; /**< hash information */
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index ff47198..dd3b8ba 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -152,11 +152,12 @@ enum grinder_state {
* by scheduler enqueue.
*/
struct rte_sched_port_hierarchy {
- uint32_t queue:2; /**< Queue ID (0 .. 3) */
- uint32_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
- uint32_t pipe:20; /**< Pipe ID */
- uint32_t subport:6; /**< Subport ID */
+ uint16_t queue:2; /**< Queue ID (0 .. 3) */
+ uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
uint32_t color:2; /**< Color */
+ uint16_t unused:10;
+ uint16_t subport; /**< Subport ID */
+ uint32_t pipe; /**< Pipe ID */
};
struct rte_sched_grinder {
@@ -292,8 +293,9 @@ rte_sched_port_check_params(struct rte_sched_port_params *params)
if (params->mtu == 0)
return -5;
- /* n_subports_per_port: non-zero, power of 2 */
+ /* n_subports_per_port: non-zero, limited to 16 bits, power of 2 */
if (params->n_subports_per_port == 0 ||
+ params->n_subports_per_port > 1u << 16 ||
!rte_is_power_of_2(params->n_subports_per_port))
return -6;
@@ -916,6 +918,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
struct rte_sched_port_hierarchy *sched
= (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
+ RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
+
sched->color = (uint32_t) color;
sched->subport = subport;
sched->pipe = pipe;
--
2.1.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 2/2] ethdev: add sanity checks to functions
@ 2015-11-17 15:53 3% ` Stephen Hemminger
2015-11-24 14:56 3% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2015-11-17 15:53 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
On Tue, 17 Nov 2015 12:21:07 +0000
Bruce Richardson <bruce.richardson@intel.com> wrote:
> The functions rte_eth_rx_queue_count and rte_eth_descriptor_done are
> supported by very few PMDs. Therefore, it is best to check for support
> for the functions in the ethdev library, so as to avoid run-time crashes
> at run-time if the application goes to use those APIs. Similarly, the
> port parameter should also be checked for validity.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>
> ---
> lib/librte_ether/rte_ethdev.h | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index a00cd46..028be59 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -2533,16 +2533,16 @@ rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id,
> * @param queue_id
> * The queue id on the specific port.
> * @return
> - * The number of used descriptors in the specific queue.
> + * The number of used descriptors in the specific queue, or:
> + * (-EINVAL) if *port_id* is invalid
> + * (-ENOTSUP) if the device does not support this function
> */
> -static inline uint32_t
> +static inline int
> rte_eth_rx_queue_count(uint8_t port_id, uint16_t queue_id)
> {
> struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> - RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> - RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_count, 0);
> -#endif
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_count, -ENOTSUP);
> return (*dev->dev_ops->rx_queue_count)(dev, queue_id);
> }
>
> @@ -2559,15 +2559,14 @@ rte_eth_rx_queue_count(uint8_t port_id, uint16_t queue_id)
> * - (1) if the specific DD bit is set.
> * - (0) if the specific DD bit is not set.
> * - (-ENODEV) if *port_id* invalid.
> + * - (-ENOTSUP) if the device does not support this function
> */
> static inline int
> rte_eth_rx_descriptor_done(uint8_t port_id, uint16_t queue_id, uint16_t offset)
> {
> struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_descriptor_done, -ENOTSUP);
> -#endif
> return (*dev->dev_ops->rx_descriptor_done)( \
> dev->data->rx_queues[queue_id], offset);
> }
This breaks ABI since older application built with debug will try
and find the shared library entry for the routine.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 2/3] docs: add keep alive sample app guide & release notes
@ 2015-11-18 14:05 3% ` Remy Horton
0 siblings, 0 replies; 200+ results
From: Remy Horton @ 2015-11-18 14:05 UTC (permalink / raw)
To: dev; +Cc: John J Browne
Signed-off-by: Maryam Tahhan <maryam.tahhan@intel.com>
Signed-off-by: John J Browne <john.j.browne@intel.com>
Signed-off-by: Remy Horton <remy.horton@intel.com>
---
doc/api/doxy-api-index.md | 1 +
doc/guides/rel_notes/release_2_2.rst | 3 +
doc/guides/sample_app_ug/index.rst | 1 +
doc/guides/sample_app_ug/keep_alive.rst | 191 ++++++++++++++++++++++++++++++++
4 files changed, 196 insertions(+)
create mode 100644 doc/guides/sample_app_ug/keep_alive.rst
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 72ac3c4..f2c0320 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -146,4 +146,5 @@ There are many libraries, so their headers may be grouped by topics:
[EAL config] (@ref rte_eal.h),
[common] (@ref rte_common.h),
[ABI compat] (@ref rte_compat.h),
+ [keepalive] (@ref rte_keepalive.h),
[version] (@ref rte_version.h)
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 0781ae6..c00ab26 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -102,6 +102,7 @@ New Features
* **Added port hotplug support to xenvirt.**
+* **Added keepalive support to EAL.**
Resolved Issues
---------------
@@ -207,6 +208,8 @@ Libraries
Examples
~~~~~~~~
+* **l2fwd-keepalive: Added keep-alive demonstration.**
+
Other
~~~~~
diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst
index 8ae86c0..1f62ef5 100644
--- a/doc/guides/sample_app_ug/index.rst
+++ b/doc/guides/sample_app_ug/index.rst
@@ -49,6 +49,7 @@ Sample Applications User Guide
ipv4_multicast
ip_reassembly
kernel_nic_interface
+ keep_alive
l2_forward_job_stats
l2_forward_real_virtual
l3_forward
diff --git a/doc/guides/sample_app_ug/keep_alive.rst b/doc/guides/sample_app_ug/keep_alive.rst
new file mode 100644
index 0000000..080811b
--- /dev/null
+++ b/doc/guides/sample_app_ug/keep_alive.rst
@@ -0,0 +1,191 @@
+
+.. BSD LICENSE
+ Copyright(c) 2015 Intel Corporation. All rights reserved.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+
+ * Redistributions of source code must retain the above copyright
+ notice, this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in
+ the documentation and/or other materials provided with the
+ distribution.
+ * Neither the name of Intel Corporation nor the names of its
+ contributors may be used to endorse or promote products derived
+ from this software without specific prior written permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Keep Alive Sample Application
+=============================
+
+The Keep Alive application is a simple example of a
+heartbeat/watchdog for packet processing cores. It demonstrates how
+to detect 'failed' DPDK cores and notify a fault management entity
+of this failure. Its purpose is to ensure the failure of the core
+does not result in a fault that is not detectable by a management
+entity.
+
+
+Overview
+--------
+
+The application demonstrates how to protect against 'silent outages'
+on packet processing cores. A Keep Alive Monitor Agent Core (master)
+monitors the state of packet processing cores (worker cores) by
+dispatching pings at a regular time interval (default is 5ms) and
+monitoring the state of the cores. Cores states are: Alive, MIA, Dead
+or Buried. MIA indicates a missed ping, and Dead indicates two missed
+pings within the specified time interval. When a core is Dead, a
+callback function is invoked to restart the packet processing core;
+A real life application might use this callback function to notify a
+higher level fault management entity of the core failure in order to
+take the appropriate corrective action.
+
+Note: Only the worker cores are monitored. A local (on the host) mechanism
+or agent to supervise the Keep Alive Monitor Agent Core DPDK core is required
+to detect its failure.
+
+Note: This application is based on the L2 forwarding application. As
+such, the initialization and run-time paths are very similar to those
+of the L2 forwarding application.
+
+Compiling the Application
+-------------------------
+
+To compile the application:
+
+#. Go to the sample application directory:
+
+ .. code-block:: console
+
+ export RTE_SDK=/path/to/rte_sdk cd ${RTE_SDK}/examples/keep_alive
+
+#. Set the target (a default target is used if not specified). For example:
+
+ .. code-block:: console
+
+ export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+ See the *DPDK Getting Started Guide* for possible RTE_TARGET values.
+
+#. Build the application:
+
+ .. code-block:: console
+
+ make
+
+Running the Application
+-----------------------
+
+The application has a number of command line options:
+
+.. code-block:: console
+
+ ./build/l2fwd-keepalive [EAL options] \
+ -- -p PORTMASK [-q NQ] [-K PERIOD] [-T PERIOD]
+
+where,
+
+* ``p PORTMASK``: A hexadecimal bitmask of the ports to configure
+
+* ``q NQ``: A number of queues (=ports) per lcore (default is 1)
+
+* ``K PERIOD``: Heartbeat check period in ms(5ms default; 86400 max)
+
+* ``T PERIOD``: statistics will be refreshed each PERIOD seconds (0 to
+ disable, 10 default, 86400 maximum).
+
+To run the application in linuxapp environment with 4 lcores, 16 ports
+8 RX queues per lcore and a ping interval of 10ms, issue the command:
+
+.. code-block:: console
+
+ ./build/l2fwd-keepalive -c f -n 4 -- -q 8 -p ffff -K 10
+
+Refer to the *DPDK Getting Started Guide* for general information on
+running applications and the Environment Abstraction Layer (EAL)
+options.
+
+
+Explanation
+-----------
+
+The following sections provide some explanation of the The
+Keep-Alive/'Liveliness' conceptual scheme. As mentioned in the
+overview section, the initialization and run-time paths are very
+similar to those of the L2 forwarding application (see Chapter 9
+"L2 Forwarding Sample Application (in Real and Virtualized
+Environments)" for more information).
+
+The Keep-Alive/'Liveliness' conceptual scheme:
+
+* A Keep- Alive Agent Runs every N Milliseconds.
+
+* DPDK Cores respond to the keep-alive agent.
+
+* If keep-alive agent detects time-outs, it notifies the
+ fault management entity through a callback function.
+
+The following sections provide some explanation of the code aspects
+that are specific to the Keep Alive sample application.
+
+The heartbeat functionality is initialized with a struct
+rte_heartbeat and the callback function to invoke in the
+case of a timeout.
+
+.. code-block:: c
+
+ rte_global_keepalive_info = rte_keepalive_create(&dead_core, NULL);
+ if (rte_global_hbeat_info == NULL)
+ rte_exit(EXIT_FAILURE, "keepalive_create() failed");
+
+The function that issues the pings hbeat_dispatch_pings()
+is configured to run every check_period milliseconds.
+
+.. code-block:: c
+
+ if (rte_timer_reset(&hb_timer,
+ (check_period * rte_get_timer_hz()) / 1000,
+ PERIODICAL,
+ rte_lcore_id(),
+ &hbeat_dispatch_pings, rte_global_keepalive_info
+ ) != 0 )
+ rte_exit(EXIT_FAILURE, "Keepalive setup failure.\n");
+
+The rest of the initialization and run-time path follows
+the same paths as the the L2 forwarding application. The only
+addition to the main processing loop is the mark alive
+functionality and the example random failures.
+
+.. code-block:: c
+
+ rte_keepalive_mark_alive(&rte_global_hbeat_info);
+ cur_tsc = rte_rdtsc();
+
+ /* Die randomly within 7 secs for demo purposes.. */
+ if (cur_tsc - tsc_initial > tsc_lifetime)
+ break;
+
+The rte_keepalive_mark_alive function simply sets the core state to alive.
+
+.. code-block:: c
+
+ static inline void
+ rte_keepalive_mark_alive(struct rte_heartbeat *keepcfg)
+ {
+ keepcfg->state_flags[rte_lcore_id()] = 1;
+ }
--
1.9.3
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v4] doc: add contributors guide
@ 2015-11-20 12:46 2% ` John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2015-11-20 12:46 UTC (permalink / raw)
To: dev
Add a document to explain the DPDK patch submission and review process.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
---
v4:
* Fixes for mailing list comments.
v3:
* Add recommendation to test build the shared and combined libraries.
v2:
* Fixes for mailing list comments.
* Fix for broken link target.
doc/guides/contributing/documentation.rst | 2 +-
doc/guides/contributing/index.rst | 1 +
doc/guides/contributing/patches.rst | 350 ++++++++++++++++++++++++++++++
3 files changed, 352 insertions(+), 1 deletion(-)
create mode 100644 doc/guides/contributing/patches.rst
diff --git a/doc/guides/contributing/documentation.rst b/doc/guides/contributing/documentation.rst
index 7f5f061..c2d0461 100644
--- a/doc/guides/contributing/documentation.rst
+++ b/doc/guides/contributing/documentation.rst
@@ -1,4 +1,4 @@
-.. doc_guidelines:
+.. _doc_guidelines:
DPDK Documentation Guidelines
=============================
diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
index 561427b..f49ca88 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -9,3 +9,4 @@ Contributor's Guidelines
design
versioning
documentation
+ patches
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
new file mode 100644
index 0000000..50992fd
--- /dev/null
+++ b/doc/guides/contributing/patches.rst
@@ -0,0 +1,350 @@
+.. submitting_patches:
+
+Contributing Code to DPDK
+=========================
+
+This document outlines the guidelines for submitting code to DPDK.
+
+The DPDK development process is modeled (loosely) on the Linux Kernel development model so it is worth reading the
+Linux kernel guide on submitting patches:
+`How to Get Your Change Into the Linux Kernel <http://www.kernel.org/doc/Documentation/SubmittingPatches>`_.
+The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines.
+
+
+The DPDK Development Process
+-----------------------------
+
+The DPDK development process has the following features:
+
+* The code is hosted in a public git repository.
+* There is a mailing list where developers submit patches.
+* There are maintainers for hierarchical components.
+* Patches are reviewed publicly on the mailing list.
+* Successfully reviewed patches are merged to the master branch of the repository.
+
+The mailing list for DPDK development is `dev@dpkg.org <http://dpdk.org/ml/archives/dev/>`_.
+Contributors will need to `register for the mailing list <http://dpdk.org/ml/listinfo/dev>`_ in order to submit patches.
+It is also worth registering for the DPDK `Patchwork <http://dpdk.org/dev/patchwxispork/project/dpdk/list/>`_
+
+The development process requires some familiarity with the ``git`` version control system.
+Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information.
+
+
+Getting the Source Code
+-----------------------
+
+The source code can be cloned using either of the following::
+
+ git clone git://dpdk.org/dpdk
+
+ git clone http://dpdk.org/git/dpdk
+
+
+Make your Changes
+-----------------
+
+Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines and requirements:
+
+* Follow the :ref:`coding_style` guidelines.
+
+* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+
+* New external functions should be added to the local ``version.map`` file.
+ See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
+ New external functions should also be added in alphabetical order.
+
+* Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``.
+ See the :ref:`Release Notes section of the Documentation Guidelines <doc_guidelines>` for details.
+
+* Run ``make install``, ``make examples`` and ``make test`` and build the shared and combined libraries
+ to ensure the changes haven't broken existing code:
+
+ .. code-block:: console
+
+ export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+ make T=$RTE_TARGET install
+ make T=$RTE_TARGET install CONFIG_RTE_BUILD_SHARED_LIB=y \
+ CONFIG_RTE_BUILD_COMBINE_LIBS=y
+ make T=$RTE_TARGET examples
+ make T=$RTE_TARGET test
+
+* Don't break compilation between commits with forward dependencies in a patchset.
+ Each commit should compile on its own to allow for ``git bisect`` and continuous integration testing.
+
+* Add tests to the the ``app/test`` unit test framework where possible.
+
+* Add documentation, if relevant, in the form of Doxygen comments or a User Guide in RST format.
+ See the :ref:`Documentation Guidelines <doc_guidelines>`.
+
+Once the changes have been made you should commit them to your local repo.
+
+For small changes, that do not require specific explanations, it is better to keep things together in the
+same patch.
+Larger changes that require different explanations should be separated into logical patches in a patchset.
+A good way of thinking about whether a patch should be split is to consider whether the change could be
+applied without dependencies as a backport.
+
+As a guide to how patches should be structured run ``git log`` on similar files.
+
+
+Commit Messages: Subject Line
+-----------------------------
+
+The first, summary, line of the git commit message becomes the subject line of the patch email.
+Here are some guidelines for the summary line:
+
+* The summary line must capture the area and the impact of the change.
+
+* The summary line should be around 50 characters.
+
+* The summary line should be lowercase apart from acronyms.
+
+* It should be prefixed with the component name (use git log to check existing components).
+ For example::
+
+ ixgbe: fix offload config option name
+
+ config: increase max queues per port
+
+* Use the imperative of the verb (like instructions to the code base).
+ For example::
+
+ ixgbe: fix compilarion in 32 bit
+
+* Don't add a period/full stop to the subject line or you will end up two in the patch name: ``dpdk_description..patch``.
+
+The actual email subject line should be prefixed by ``[PATCH]`` and the version, if greater than v1,
+for example: ``PATCH v2``.
+The is generally added by ``git send-email`` or ``git format-patch``, see below.
+
+If you are submitting an RFC draft of a feature you can use ``[RFC]`` instead of ``[PATCH]``.
+An RFC patch doesn't have to be complete.
+It is intended as a way of getting early feedback.
+
+
+Commit Messages: Body
+---------------------
+
+Here are some guidelines for the body of a commit message:
+
+* The body of the message should describe the issue being fixed or the feature being added.
+ It is important to provide enough information to allow a reviewer to understand the purpose of the patch.
+
+* When the change is obvious the body can be blank, apart from the signoff.
+
+* The commit message must end with a ``Signed-off-by:`` line which is added using::
+
+ git commit --signoff # or -s
+
+ The purpose of the signoff is explained in the
+ `Developer's Certificate of Origin <http://www.kernel.org/doc/Documentation/SubmittingPatches>`_
+ section of the Linux kernel guidelines.
+
+ .. Note::
+
+ All developers must ensure that they have read and understood the
+ Developer's Certificate of Origin section of the documentation prior
+ to applying the signoff and submitting a patch.
+
+* The signoff must be a real name and not an alias or nickname.
+ More than one signoff is allowed.
+
+* The text of the commit message should be wrapped at 72 characters.
+
+* When fixing a regression, it is a good idea to reference the id of the commit which introduced the bug.
+ You can generate the required text using the following git alias::
+
+ git config alias.fixline "log -1 --abbrev=12 --format='Fixes: %h (\"%s\")'"
+
+ The ``Fixes:`` line can then be added to the commit message::
+
+ doc: fix vhost sample parameter
+
+ Update the docs to reflect removed dev-index.
+
+ Fixes: 17b8320a3e11 ("vhost: remove index parameter")
+
+ Signed-off-by: Alex Smith <alex.smith@example.com>
+
+* When fixing an error or warning it is useful to add the error message and instructions on how to reproduce it.
+
+* Use correct capitalization, punctuation and spelling.
+
+In addition to the ``Signed-off-by:`` name the commit messages can also have one or more of the following:
+
+* ``Reported-by:`` The reporter of the issue.
+* ``Tested-by:`` The tester of the change.
+* ``Reviewed-by:`` The reviewer of the change.
+* ``Suggested-by:`` The person who suggested the change.
+* ``Acked-by:`` When a previous version of the patch was acked and the ack is still relevant.
+
+
+Creating Patches
+----------------
+
+It is possible to send patches directly from git but for new contributors it is recommended to generate the
+patches with ``git format-patch`` and then when everything looks okay, and the patches have been checked, to
+send them with ``git send-email``.
+
+Here are some examples of using ``git format-patch`` to generate patches:
+
+.. code-block:: console
+
+ # Generate a patch from the last commit.
+ git format-patch -1
+
+ # Generate a patch from the last 3 commits.
+ git format-patch -3
+
+ # Generate the patches in a directory.
+ git format-patch -3 -o ~/patch/
+
+ # Add a cover letter to explain a patchset.
+ git format-patch -3 -o ~/patch/ --cover-letter
+
+ # Add a prefix with a version number.
+ git format-patch -3 -o ~/patch/ -v 2
+
+
+
+Cover letters are useful for explaining a patchset and help to generate a logical threading to the patches.
+Smaller notes can be put inline in the patch after the ``---`` separator, for example::
+
+ Subject: [PATCH] fm10k/base: add FM10420 device ids
+
+ Add the device ID for Boulder Rapids and Atwood Channel to enable
+ drivers to support those devices.
+
+ Signed-off-by: Alex Smith <alex.smith@example.com>
+ ---
+
+ ADD NOTES HERE.
+
+ drivers/net/fm10k/base/fm10k_api.c | 6 ++++++
+ drivers/net/fm10k/base/fm10k_type.h | 6 ++++++
+ 2 files changed, 12 insertions(+)
+ ...
+
+Version 2 and later of a patchset should also include a short log of the changes so the reviewer knows what has changed.
+This can be added to the cover letter or the annotations.
+For example::
+
+ v3:
+ * Fixed issued with version.map.
+
+ v2:
+ * Added i40e support.
+ * Renamed ethdev functions from rte_eth_ieee15888_*() to rte_eth_timesync_*()
+ since 802.1AS can be supported through the same interfaces.
+
+
+Checking the Patches
+--------------------
+
+Patches should be checked for formatting and syntax issues using the Linux scripts tool ``checkpatch``.
+
+The ``checkpatch`` utility can be obtained by cloning, and periodically, updating the Linux kernel sources.
+
+The kernel guidelines tested by ``checkpatch`` don't match the DPDK Coding Style guidelines exactly but
+they provide a good indication of conformance.
+Warnings about kernel data types or about split strings can be ignored::
+
+ /path/checkpatch.pl --ignore PREFER_KERNEL_TYPES,SPLIT_STRING -q files*.patch
+
+Ensure that the code compiles with ``gcc`` and ``clang``::
+
+ make T=x86_64-native-linuxapp-gcc install
+ make T=x86_64-native-linuxapp-clang install
+
+Confirm that the changes haven't broken any existing code by running ``make install``, ``make examples`` and
+``make test`` and building the shared and combined libraries:
+
+ .. code-block:: console
+
+ export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+ make T=$RTE_TARGET install
+ make T=$RTE_TARGET install CONFIG_RTE_BUILD_SHARED_LIB=y \
+ CONFIG_RTE_BUILD_COMBINE_LIBS=y
+ make T=$RTE_TARGET examples
+ make T=$RTE_TARGET test
+
+
+Sending Patches
+---------------
+
+Patches should be sent to the mailing list using ``git send-email``.
+You can configure an external SMTP with something like the following::
+
+ [sendemail]
+ smtpuser = name@domain.com
+ smtpserver = smtp.domain.com
+ smtpserverport = 465
+ smtpencryption = ssl
+
+See the `Git send-email <https://git-scm.com/docs/git-send-email>`_ documentation for more details.
+
+The patches should be sent to ``dev@dpdk.org``.
+If the patches are a change to existing files then you should send them TO the maintainer(s) and CC ``dev@dpdk.org``.
+The appropriate maintainer can be found in the ``MAINTAINERS`` file::
+
+ git send-email --to maintainer@some.org --cc dev@dpdk.org 000*.patch
+
+New additions can be sent without a maintainer::
+
+ git send-email --to dev@dpdk.org 000*.patch
+
+You can test the emails by sending it to yourself or with the ``--dry-run`` option.
+
+If the patch is in relation to a previous email thread you can add it to the same thread using the Message ID::
+
+ git send-email --to dev@dpdk.org --in-reply-to <1234-foo@bar.com> 000*.patch
+
+The Message ID can be found in the raw text of emails or at the top of each Patchwork patch,
+`for example <http://dpdk.org/dev/patchwork/patch/7646/>`_.
+Shallow threading (``--thread --no-chain-reply-to``) is preferred for a patch series.
+
+Once submitted your patches will appear on the mailing list and in Patchwork.
+
+Experienced committers may send patches directly with ``git send-email`` without the ``git format-patch`` step.
+The options ``--annotate`` and ``confirm = always`` are recommended for checking patches before sending.
+
+
+The Review Process
+------------------
+
+The more work you put into the previous steps the easier it will be to get a patch accepted.
+
+The general cycle for patch review and acceptance is:
+
+#. Submit the patch.
+
+#. Check the automatic test reports in the coming hours.
+
+#. Wait for review comments. While you are waiting review some other patches.
+
+#. Fix the review comments and submit a ``v n+1`` patchset::
+
+ git format-patch -3 -v 2
+
+#. Update Patchwork to mark your previous patches as "Superseded".
+
+#. If the patch is deemed suitable for merging by the relevant maintainer(s) or other developers they will ``ack``
+ the patch with an email that includes something like::
+
+ Acked-by: Alex Smith <alex.smith@example.com>
+
+ **Note**: When acking patches please remove as much of the text of the patch email as possible.
+ It is generally best to delete everything after the ``Signed-off-by:`` line.
+
+#. Having the patch ``Reviewed-by:`` and/or ``Tested-by:`` will also help the patch to be accepted.
+
+#. If the patch isn't deemed suitable based on being out of scope or conflicting with existing functionality
+ it may receive a ``nack``.
+ In this case you will need to make a more convincing technical argument in favor of your patches.
+
+#. In addition a patch will not be accepted if it doesn't address comments from a previous version with fixes or
+ valid arguments.
+
+#. Acked patches will be merged in the current or next merge window.
--
2.5.0
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v9 1/3] Remove ABI requirement for external library builds.
2015-11-20 15:34 3% ` [dpdk-dev] [PATCH v9 0/3] " Remy Horton
@ 2015-11-20 15:34 4% ` Remy Horton
[not found] ` <2601191342CEEE43887BDE71AB97725836ACAB5A@irsmsx105.ger.corp.intel.com>
2015-11-24 3:05 0% ` [dpdk-dev] [PATCH v9 0/3] User-space ethtool sample application Liu, Yong
1 sibling, 1 reply; 200+ results
From: Remy Horton @ 2015-11-20 15:34 UTC (permalink / raw)
To: dev
Signed-off-by: Andrew G. Harvey <agh@cisco.com>
---
mk/rte.extlib.mk | 2 ++
mk/rte.lib.mk | 6 ++++++
2 files changed, 8 insertions(+)
diff --git a/mk/rte.extlib.mk b/mk/rte.extlib.mk
index ba066bc..4d459e4 100644
--- a/mk/rte.extlib.mk
+++ b/mk/rte.extlib.mk
@@ -31,6 +31,8 @@
MAKEFLAGS += --no-print-directory
+EXTLIB_BUILD := 1
+
# we must create the output dir first and recall the same Makefile
# from this directory
ifeq ($(NOT_FIRST_CALL),)
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index fcc8e20..7262b02 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -40,11 +40,13 @@ VPATH += $(SRCDIR)
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
LIB := $(patsubst %.a,%.so.$(LIBABIVER),$(LIB))
+ifndef EXTLIB_BUILD
ifeq ($(CONFIG_RTE_NEXT_ABI),y)
LIB := $(LIB).1
endif
CPU_LDFLAGS += --version-script=$(SRCDIR)/$(EXPORT_MAP)
endif
+endif
_BUILD = $(LIB)
@@ -174,12 +176,16 @@ $(RTE_OUTPUT)/lib/$(LIB): $(LIB)
@[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib
$(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+ifdef EXTLIB_BUILD
+ $(Q)ln -s -f $< $(basename $@)
+else
ifeq ($(CONFIG_RTE_NEXT_ABI),y)
$(Q)ln -s -f $< $(basename $(basename $@))
else
$(Q)ln -s -f $< $(basename $@)
endif
endif
+endif
#
# Clean all generated files
--
1.9.3
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v9 0/3] User-space ethtool sample application
@ 2015-11-20 15:34 3% ` Remy Horton
2015-11-20 15:34 4% ` [dpdk-dev] [PATCH v9 1/3] Remove ABI requirement for external library builds Remy Horton
2015-11-24 3:05 0% ` [dpdk-dev] [PATCH v9 0/3] User-space ethtool sample application Liu, Yong
0 siblings, 2 replies; 200+ results
From: Remy Horton @ 2015-11-20 15:34 UTC (permalink / raw)
To: dev
Further enhancements to the userspace ethtool implementation that was
submitted in 2.1 and packaged as a self-contained sample application.
Implements an rte_ethtool shim layer based on rte_ethdev API, along
with a command prompt driven demonstration application.
This patchset depends on:
* http://dpdk.org/dev/patchwork/patch/8070/
v9:
* Merged in upstream external lib dependency
* Added sanity check to shim MTU set function
* Added example to example/Makefile
* Rebased to latest master
v8:
* Rebased to latest origin/master
v7:
* Ringparam printouts wrong way round
* Ringparam help message corrections
* Use __rte_unused instead of __attribute__((unused))
* Allow Jumbo-sized MTUs
* Documentation style and spelling changes
v6:
* Fixed hang when run with zero available ports
* Fixed incorrect sanity check preventing EEPROM dumps
* Documentation additions
* Fixed RxMode accepting untagged packets
* Fixed ringparam allocation being too small
v5:
* Documentation changes
v4:
* Fixed assumption that master core always has id zero
* Changed 1:1 core-to-port to 2 core (ethtool & ports) design
* Included the correct documentation..
v3:
* Made use of enums for core state.
* Fixed Makefile issue.
* Fixed incorrect assumption with core ids.
* Changed handling of more ports than cores.
v2:
* Replaced l2fwd base with simpler application.
* Added ringparam functions.
* Added documentation.
Remy Horton (3):
Remove ABI requirement for external library builds.
example: add user-space ethtool sample application
doc: add user-space ethtool sample app guide & release notes
MAINTAINERS | 4 +
doc/guides/rel_notes/release_2_2.rst | 1 +
doc/guides/sample_app_ug/ethtool.rst | 160 +++++++
doc/guides/sample_app_ug/index.rst | 1 +
examples/Makefile | 1 +
examples/ethtool/Makefile | 48 ++
examples/ethtool/ethtool-app/Makefile | 54 +++
examples/ethtool/ethtool-app/ethapp.c | 873 ++++++++++++++++++++++++++++++++++
examples/ethtool/ethtool-app/ethapp.h | 41 ++
examples/ethtool/ethtool-app/main.c | 305 ++++++++++++
examples/ethtool/lib/Makefile | 57 +++
examples/ethtool/lib/rte_ethtool.c | 423 ++++++++++++++++
examples/ethtool/lib/rte_ethtool.h | 410 ++++++++++++++++
mk/rte.extlib.mk | 2 +
mk/rte.lib.mk | 6 +
15 files changed, 2386 insertions(+)
create mode 100644 doc/guides/sample_app_ug/ethtool.rst
create mode 100644 examples/ethtool/Makefile
create mode 100644 examples/ethtool/ethtool-app/Makefile
create mode 100644 examples/ethtool/ethtool-app/ethapp.c
create mode 100644 examples/ethtool/ethtool-app/ethapp.h
create mode 100644 examples/ethtool/ethtool-app/main.c
create mode 100644 examples/ethtool/lib/Makefile
create mode 100644 examples/ethtool/lib/rte_ethtool.c
create mode 100644 examples/ethtool/lib/rte_ethtool.h
--
1.9.3
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size
2015-11-10 17:29 4% ` [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size Mcnamara, John
@ 2015-11-20 16:28 4% ` Olivier MATZ
2015-11-20 16:33 4% ` Bruce Richardson
2015-12-03 16:32 4% ` Mcnamara, John
0 siblings, 2 replies; 200+ results
From: Olivier MATZ @ 2015-11-20 16:28 UTC (permalink / raw)
To: Mcnamara, John, Nelio Laranjeiro, dev
Hi Nélio,
On 11/10/2015 06:29 PM, Mcnamara, John wrote:
>
>
>> -----Original Message-----
>> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
>> Sent: Monday, November 9, 2015 4:48 PM
>> To: dev@dpdk.org
>> Cc: olivier.matz@6wind.com; thomas.monjalon@6wind.com; Mcnamara, John; Lu,
>> Wenzhuo
>> Subject: [PATCH 1/2] doc: announce ABI change for cmdline buffer size
>>
>> Current buffer size are not enough for a few testpmd commands.
>>
>> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
>
While I'm not fundamentally opposed to change the buffer size,
I'm wondering if the impacted commands shouldn't be reworked to
have smaller lines. 256 is already a quite big value for a line:
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
For instance, we could change some commands to use contexts.
Dummy example with reta config:
testpmd> port config 0 rss reta
testpmd-reta-config-0> add hash1 queue1
testpmd-reta-config-0> add hash2 queue2
testpmd-reta-config-0> del hash1 queue1
testpmd-reta-config-0> show
testpmd-reta-config-0> commit
testpmd>
What do you think?
Regards,
Olivier
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v9 1/3] Remove ABI requirement for external library builds.
[not found] ` <2601191342CEEE43887BDE71AB97725836ACAB5A@irsmsx105.ger.corp.intel.com>
@ 2015-11-20 16:32 4% ` Wang, Liang-min
0 siblings, 0 replies; 200+ results
From: Wang, Liang-min @ 2015-11-20 16:32 UTC (permalink / raw)
To: dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Remy Horton
> Sent: Friday, November 20, 2015 3:35 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v9 1/3] Remove ABI requirement for external
> library builds.
>
> Signed-off-by: Andrew G. Harvey <agh@cisco.com>
> ---
> mk/rte.extlib.mk | 2 ++
> mk/rte.lib.mk | 6 ++++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/mk/rte.extlib.mk b/mk/rte.extlib.mk
> index ba066bc..4d459e4 100644
> --- a/mk/rte.extlib.mk
> +++ b/mk/rte.extlib.mk
> @@ -31,6 +31,8 @@
>
> MAKEFLAGS += --no-print-directory
>
> +EXTLIB_BUILD := 1
> +
> # we must create the output dir first and recall the same Makefile
> # from this directory
> ifeq ($(NOT_FIRST_CALL),)
> diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
> index fcc8e20..7262b02 100644
> --- a/mk/rte.lib.mk
> +++ b/mk/rte.lib.mk
> @@ -40,11 +40,13 @@ VPATH += $(SRCDIR)
>
> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> LIB := $(patsubst %.a,%.so.$(LIBABIVER),$(LIB))
> +ifndef EXTLIB_BUILD
> ifeq ($(CONFIG_RTE_NEXT_ABI),y)
> LIB := $(LIB).1
> endif
> CPU_LDFLAGS += --version-script=$(SRCDIR)/$(EXPORT_MAP)
> endif
> +endif
>
>
> _BUILD = $(LIB)
> @@ -174,12 +176,16 @@ $(RTE_OUTPUT)/lib/$(LIB): $(LIB)
> @[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib
> $(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib
> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> +ifdef EXTLIB_BUILD
> + $(Q)ln -s -f $< $(basename $@)
> +else
> ifeq ($(CONFIG_RTE_NEXT_ABI),y)
> $(Q)ln -s -f $< $(basename $(basename $@))
> else
> $(Q)ln -s -f $< $(basename $@)
> endif
> endif
> +endif
>
> #
> # Clean all generated files
> --
> 1.9.3
ACK this patch as it has been reviewed.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size
2015-11-20 16:28 4% ` Olivier MATZ
@ 2015-11-20 16:33 4% ` Bruce Richardson
2015-12-03 16:32 4% ` Mcnamara, John
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2015-11-20 16:33 UTC (permalink / raw)
To: Olivier MATZ; +Cc: dev
On Fri, Nov 20, 2015 at 05:28:43PM +0100, Olivier MATZ wrote:
> Hi Nélio,
>
> On 11/10/2015 06:29 PM, Mcnamara, John wrote:
> >
> >
> >> -----Original Message-----
> >> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> >> Sent: Monday, November 9, 2015 4:48 PM
> >> To: dev@dpdk.org
> >> Cc: olivier.matz@6wind.com; thomas.monjalon@6wind.com; Mcnamara, John; Lu,
> >> Wenzhuo
> >> Subject: [PATCH 1/2] doc: announce ABI change for cmdline buffer size
> >>
> >> Current buffer size are not enough for a few testpmd commands.
> >>
> >> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> >
> > Acked-by: John McNamara <john.mcnamara@intel.com>
> >
>
> While I'm not fundamentally opposed to change the buffer size,
> I'm wondering if the impacted commands shouldn't be reworked to
> have smaller lines. 256 is already a quite big value for a line:
>
> 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
>
> For instance, we could change some commands to use contexts.
> Dummy example with reta config:
>
> testpmd> port config 0 rss reta
> testpmd-reta-config-0> add hash1 queue1
> testpmd-reta-config-0> add hash2 queue2
> testpmd-reta-config-0> del hash1 queue1
> testpmd-reta-config-0> show
> testpmd-reta-config-0> commit
> testpmd>
>
> What do you think?
>
+1
multiple shorter commands are much less error prone than a single long one.
/Bruce
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine
2015-11-03 11:48 0% ` Ferruh Yigit
@ 2015-11-20 19:46 0% ` Eric Kinzie
2015-11-24 14:52 0% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Eric Kinzie @ 2015-11-20 19:46 UTC (permalink / raw)
To: ferruh.yigit, Panu Matilainen, dev, Eric Kinzie
On Tue Nov 03 11:48:57 +0000 2015, Ferruh Yigit wrote:
> On Tue, Nov 03, 2015 at 01:31:45PM +0200, Panu Matilainen wrote:
> > On 11/03/2015 01:02 PM, Ferruh Yigit wrote:
> >> On Tue, Nov 03, 2015 at 08:48:16AM +0200, Panu Matilainen wrote:
> >>> On 11/02/2015 06:42 PM, Eric Kinzie wrote:
> >>>> On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
> >>>>> On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
> >>>>>> 2015-10-19 08:36, Eric Kinzie:
> >>>>>>> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER
> >>>>>>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
> >>>>>>> functions.
> >>>>>> [...]
> >>>>>>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
> >>>>>> [...]
> >>>>>>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
> >>>>>>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \
> >>>>>>> + bond_mode_8023ad_setup_v22);
> >>>>>>
> >>>>>> I'm sorry it doesn't work well when trying to build a combined lib:
> >>>>>>
> >>>>>> ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2
> >>>>>>
> >>>>>> The symbols are OK in the .o file:
> >>>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2
> >>>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0
> >>>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20
> >>>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22
> >>>>>> 0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
> >>>>>>
> >>>>>> I don't understand the problem and I am considering disabling versioning in
> >>>>>> combined library.
> >>>>>>
> >>>>>> Any idea?
> >>>>>>
> >>>>>
> >>>>> The .map additions look incorrect to me:
> >>>>>
> >>>>>> diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
> >>>>>> index 22bd920..7f78717 100644
> >>>>>> --- a/drivers/net/bonding/rte_eth_bond_version.map
> >>>>>> +++ b/drivers/net/bonding/rte_eth_bond_version.map
> >>>>>> @@ -17,6 +17,9 @@ DPDK_2.0 {
> >>>>>> rte_eth_bond_slaves_get;
> >>>>>> rte_eth_bond_xmit_policy_get;
> >>>>>> rte_eth_bond_xmit_policy_set;
> >>>>>> + rte_eth_bond_8023ad_ext_collect;
> >>>>>> + rte_eth_bond_8023ad_ext_distrib;
> >>>>>> + rte_eth_bond_8023ad_ext_slowtx;
> >>>>>
> >>>>> These symbols didn't exist in DPDK 2.0 but are only being added
> >>>>> here. So why are they being added to the 2.0 section?
> >>>>
> >>>> Yes, I think these should probably be moved.
> >>>>
> >>>>
> >>>>>>
> >>>>>> local: *;
> >>>>>> };
> >>>>>> @@ -27,3 +30,10 @@ DPDK_2.1 {
> >>>>>> rte_eth_bond_free;
> >>>>>>
> >>>>>> } DPDK_2.0;
> >>>>>> +
> >>>>>> +DPDK_2.2 {
> >>>>>> + local
> >>>>>> +
> >>>>>> + bond_mode_8023ad_conf_get;
> >>>>>> + bond_mode_8023ad_setup;
> >>>>>> +} DPDK_2.1;
> >>>>>
> >>>>> These are marked local, as in, "not exported" which doesn't seem
> >>>>> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
> >>>>> the symbol export map should look like here:
> >>>>
> >>>>
> >>>> These were not exported to begin with. But after versioning these
> >>>> functions, they are exported unless explicitly declared to be local here.
> >>>>
> >>>
> >>> And this does not ring any warning bells? :)
> >>>
> >>> Sorry, I was not looking at the patch as a whole. You're declaring these
> >>> symbols as exported with the versioning macros, eg
> >>>
> >>> BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
> >>>
> >>> ...and then explicitly telling it to not export them by declaring local, and
> >>> then we wonder why it has trouble finding the symbols.
> >>> The versioning macros wont invent the librte_ prefix for you, you need to
> >>> rename the functions accordingly.
> >>>
> >>> But all this versioning gymnastics is moot anyway because you declare the
> >>> ABI incompatible:
> >>>
> >>> -LIBABIVER := 1
> >>> +LIBABIVER := 2
> >>>
> >>> This changes the library soname, so no binary compiled against the previous
> >>> version can possibly use it anymore. As in, by definition there can be no
> >>> callers of the _v20 variants after this ABI version bump.
> >>>
> >> An observation: even soname is different, just renaming .so file itself works.
> >>
> >> And this can be useful for the case:
> >> libx.so.1 provides functions A, B, C
> >> app1 compiled against libx.so.1, using only function B
> >>
> >> libx.so.1 updated only thefunction A and become libx.so.2
> >> app1 still can run successfully by re-naming lib to libx.so.1 (even soname is libx.so.2)
> >>
> >> But for this usage, user needs to know which function updated and is it safe or not to use this library,
> >> I wonder if there is an automatic way of resolving this dependency.
> >
> > Erm, no. The whole point of changing soname and the physical filename is to
> > tell others it is incompatible with earlier versions. Yes you can rename the
> > file and get lucky (or not), just like you can play Russian roulette.
> > Neither are particularly healthy ideas.
> >
> > Symbol version exists in part to allow libraries to evolve while maintaining
> > compatibility, but it requires careful planning and programming. When public
> > structs change, the structs would have to be versioned too, and from there
> > on it starts getting more and more complicated.
> >
>
> If we strictly want to prevent using old library, whenever LIBABIVER increased, we should update .map as following, right?
>
> FROM: (dpdk2.1)
> ================
> DPDK_2.0 {
> A;
> B;
> C;
> };
>
> DPDK_2.1 {
> D;
> E;
> };
>
> LIBABIVER=1
> ================
>
> TO: (dpdk2.2)
> ================
> DPDK_2.2 {
> A;
> B;
> C;
> D;
> E;
> };
>
> LIBABIVER=2
> ================
>
>
> So this won't work for anybody without luck factor, I think currently we are not doing this.
>
>
> thanks,
> ferruh
>
>
Panu, Ferruh, is there agreement on an acceptable approach to this?
Eric
^ permalink raw reply [relevance 0%]
* [dpdk-dev] difficulty w/ RTE_NEXT_ABI
@ 2015-11-21 8:49 3% Matthew Hall
2015-11-21 10:44 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Matthew Hall @ 2015-11-21 8:49 UTC (permalink / raw)
To: dev
I was trying to rebase my DPDK onto v2.1.0 and I came across some very
confusing code in examples/l3fwd/main.c .
So... this code used the RTE_NEXT_ABI macros on a change which does not appear
to affect the API... on a function that is marked always_inline ???
Maybe I missed something but this seems pointless. An always_inline function
is going to have to be recompiled in any case.
Now I have no clue what would makes sense for my version of the function
either... because RTE_NEXT_ABI is a binary on/off but trying to track a
multi-variate quantity of ABI updates.
For now I guess I have to write it like this inside the RTE_NEXT_ABI:
rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint32_t *dp, uint32_t ptype)
This seems unpleasant and kind of painful. What did I miss here?
Matthew.
static inline __attribute__((always_inline)) void
<<<<<<< 8e29af8a2843b6342dbc72db43ac82c9d29695bf
#ifdef RTE_NEXT_ABI
rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint16_t *dp, uint32_t ptype)
#else
rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint16_t *dp, uint32_t flags)
#endif
=======
rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint32_t *dp, uint32_t flags)
>>>>>>> examples: update examples to use 24 bit extended next hop
{
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] difficulty w/ RTE_NEXT_ABI
2015-11-21 8:49 3% [dpdk-dev] difficulty w/ RTE_NEXT_ABI Matthew Hall
@ 2015-11-21 10:44 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-21 10:44 UTC (permalink / raw)
To: Matthew Hall; +Cc: dev
2015-11-21 03:49, Matthew Hall:
> I was trying to rebase my DPDK onto v2.1.0 and I came across some very
> confusing code in examples/l3fwd/main.c .
>
> So... this code used the RTE_NEXT_ABI macros on a change which does not appear
> to affect the API... on a function that is marked always_inline ???
>
> Maybe I missed something but this seems pointless. An always_inline function
> is going to have to be recompiled in any case.
>
> Now I have no clue what would makes sense for my version of the function
> either... because RTE_NEXT_ABI is a binary on/off but trying to track a
> multi-variate quantity of ABI updates.
>
> For now I guess I have to write it like this inside the RTE_NEXT_ABI:
>
> rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint32_t *dp, uint32_t ptype)
>
> This seems unpleasant and kind of painful. What did I miss here?
>
> Matthew.
>
> static inline __attribute__((always_inline)) void
> <<<<<<< 8e29af8a2843b6342dbc72db43ac82c9d29695bf
> #ifdef RTE_NEXT_ABI
> rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint16_t *dp, uint32_t ptype)
> #else
> rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint16_t *dp, uint32_t flags)
> #endif
The new mbuf provides packet type instead of flags.
So the processing in this function is changed and the variable name is
different to reflect this.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] difficulty w/ RTE_NEXT_ABI
@ 2015-11-22 20:59 3% ` Thomas Monjalon
2015-11-22 23:25 5% ` Matthew Hall
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-22 20:59 UTC (permalink / raw)
To: Matthew Hall; +Cc: dev
2015-11-21 19:25, Matthew Hall:
> On Sat, Nov 21, 2015 at 11:44:20AM +0100, Thomas Monjalon wrote:
> > The new mbuf provides packet type instead of flags.
> > So the processing in this function is changed and the variable name is
> > different to reflect this.
>
> But the data type of the variable is the same, and this is an internal
> always_inline function.
It is an example application using a mbuf feature which changes depending of
CONFIG_RTE_NEXT_ABI. The ABI is in the mbuf library not in the app.
The header of the app function is changed only for the variable name because
the semantic is changed.
> So again I am confused what advantage we got from RTE_NEXT_ABI here, and how
> you have multiple copies of RTE_NEXT_ABI on a single symbol when it is a
> binary variable.
I don't understand what is not clear here.
> This doesn't really answer the bigger question about the reasoning.
Probably because you don't ask clearly your question.
Please check the code and your question again.
Maybe that this reading may help: doc/guides/contributing/versioning.rst
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] difficulty w/ RTE_NEXT_ABI
2015-11-22 20:59 3% ` Thomas Monjalon
@ 2015-11-22 23:25 5% ` Matthew Hall
2015-11-23 0:13 5% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Matthew Hall @ 2015-11-22 23:25 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Sun, Nov 22, 2015 at 09:59:30PM +0100, Thomas Monjalon wrote:
> > So again I am confused what advantage we got from RTE_NEXT_ABI here, and how
> > you have multiple copies of RTE_NEXT_ABI on a single symbol when it is a
> > binary variable.
>
> I don't understand what is not clear here.
OK. Let me restate it.
I was starting from an assumption that the purpose of RTE_NEXT_ABI was to
allow ABI changes.
In most projects I worked on, a renaming of a variable when the data type is
unchanged does not count as an ABI change. So it seems like this is different
from the usual definition.
Secondly, if one is making an ABI change, like I was, to some code which was
already changed once using RTE_NEXT_ABI, which part of the code do you change?
Do you make a third copy different from the first two copies? If you make a
third copy, but RTE_NEXT_ABI is binary (i.e. it has two values, on and off)
then what labeling do you apply to the third copy?
If you don't make a third copy, I am assuming you edit the copy marked with
RTE_NEXT_ABI. But then what happens to a downstream user who wants to have
RTE_NEXT_ABI with the first ABI change, and not your second ABI change?
Can you see what I am trying to ask now?
Matthew.
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] difficulty w/ RTE_NEXT_ABI
2015-11-22 23:25 5% ` Matthew Hall
@ 2015-11-23 0:13 5% ` Thomas Monjalon
2015-11-23 3:53 0% ` Matthew Hall
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-23 0:13 UTC (permalink / raw)
To: Matthew Hall; +Cc: dev
2015-11-22 18:25, Matthew Hall:
> On Sun, Nov 22, 2015 at 09:59:30PM +0100, Thomas Monjalon wrote:
> > > So again I am confused what advantage we got from RTE_NEXT_ABI here, and how
> > > you have multiple copies of RTE_NEXT_ABI on a single symbol when it is a
> > > binary variable.
> >
> > I don't understand what is not clear here.
>
> OK. Let me restate it.
>
> I was starting from an assumption that the purpose of RTE_NEXT_ABI was to
> allow ABI changes.
Yes it is a preview. The next release will have only the new ABI without #ifdef.
> In most projects I worked on, a renaming of a variable when the data type is
> unchanged does not count as an ABI change. So it seems like this is different
> from the usual definition.
No, it is not an ABI change.
As I said previously, the change is in the mbuf ABI.
So in the example app, the 2 ABIs are used with #ifdef.
> Secondly, if one is making an ABI change, like I was, to some code which was
> already changed once using RTE_NEXT_ABI, which part of the code do you change?
If your change is sent upstream, you must rely on the new ABI because the old one
will be removed when your change will be integrated.
If it is a local change, it depends on which ABI you want to use.
> Do you make a third copy different from the first two copies? If you make a
> third copy, but RTE_NEXT_ABI is binary (i.e. it has two values, on and off)
> then what labeling do you apply to the third copy?
>
> If you don't make a third copy, I am assuming you edit the copy marked with
> RTE_NEXT_ABI. But then what happens to a downstream user who wants to have
> RTE_NEXT_ABI with the first ABI change, and not your second ABI change?
In each release, there is only 2 ABIs: current and next.
In 2.2, there is only 1 ABI.
> Can you see what I am trying to ask now?
Yes. Hope my detailed answer is enough.
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] difficulty w/ RTE_NEXT_ABI
2015-11-23 0:13 5% ` Thomas Monjalon
@ 2015-11-23 3:53 0% ` Matthew Hall
0 siblings, 0 replies; 200+ results
From: Matthew Hall @ 2015-11-23 3:53 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Mon, Nov 23, 2015 at 01:13:32AM +0100, Thomas Monjalon wrote:
> If your change is sent upstream, you must rely on the new ABI because the old one
> will be removed when your change will be integrated.
> If it is a local change, it depends on which ABI you want to use.
I submitted separately to Bruce & Co. It is for LPM field expansion.
My question what to do came up in the context of a rebase to master.
> Yes. Hope my detailed answer is enough.
Thanks. It is less confusing now.
Matthew.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf
@ 2015-11-23 12:16 3% ` Declan Doherty
2015-11-23 13:08 0% ` Olivier MATZ
0 siblings, 1 reply; 200+ results
From: Declan Doherty @ 2015-11-23 12:16 UTC (permalink / raw)
To: Ananyev, Konstantin, Olivier MATZ, dev
On 23/11/15 11:52, Ananyev, Konstantin wrote:
> Hi Olivier,
>
>> On 11/20/2015 06:26 PM, Declan Doherty wrote:
>>>> The new files are called rte_mbuf_offload, but from what I understand,
>>>> it is more like a mbuf metadata api. What you call "offload operation"
>>>> is not called because an offload is attached, but because you call
>>>> rte_cryptodev_enqueue_burst() on it.
>>>
>>> Maybe rte_mbuf_offload_metadata would be a better name, if not a bit
>>> more long winded :) The idea of this API set is to give a generic
>>> framework for attaching the the offload operation meta data to a mbuf
>>> which will be retrieved at a later point, when the particular offload
>>> burst function is called. I guess as we only have a single offload
>>> device at the moment the API may look a little over the top!
>>
>> Indeed, not sure rte_mbuf_offload_metadata is better.
>> I'm still not convinced that offload should appear in the name, it
>> is a bit confusing with hardware offloads (ol_flags). Also, it
>> suggests that a work is delegated to another entity, but for instance
>> in this case it is just used as a storage area:
>>
>> ol = rte_pktmbuf_offload_alloc(pool, RTE_PKTMBUF_OL_CRYPTO);
>> rte_crypto_op_attach_session(&ol->op.crypto, session);
>> ol->op.crypto.digest.data = rte_pktmbuf_append(m, digest_len);
>> ol->op.crypto.digest.phys_addr = ...;
>> /* ... */
>> rte_pktmbuf_offload_attach(m, ol);
>> ret = rte_cryptodev_enqueue_burst(dev_id, qp_id, &m, 1);
>>
>> Do you have some other examples in mind that would use this API?
>>
>>>>> +/** Rearms rte_mbuf_offload default parameters */
>>>>> +static inline void
>>>>> +__rte_pktmbuf_offload_reset(struct rte_mbuf_offload *ol,
>>>>> + enum rte_mbuf_ol_op_type type)
>>>>> +{
>>>>> + ol->m = NULL;
>>>>> + ol->type = type;
>>>>> +
>>>>> + switch (type) {
>>>>> + case RTE_PKTMBUF_OL_CRYPTO:
>>>>> + __rte_crypto_op_reset(&ol->op.crypto); break;
>>>>> + default:
>>>>> + break;
>>>>> + }
>>>>> +}
>>>>
>>>> Would it work if several OL are registered?
>>>
>>> I can't see any reason why it wouldn't
>>
>> Sorry, I read it to quickly. I thought it was a
>> rte_pktmbuf_offload_detach() function. By the way there is no
>> such function?
>>
>>
>>>> Also, what is not clear to me is how the offload structure is freed.
>>>> For instance, I think that calling rte_pktmbuf_free(m) on a mbuf
>>>> that has a offload attached would result in a leak.
>>>>
>>>> It would mean that it is not allowed to call any function that free or
>>>> reassemble a mbuf when an offload is attached.
>>>
>>> We just need to walk the chain of offloads calling
>>> rte_pktmbuf_offload_free(), before freeing the mbuf, which will be an
>>> issue with any externally attached meta data. In the case of
>>> reassembling I don't see why we would just move the chain to the head mbuf.
>>
>> Walking the chain of offload + adding the initialization will probably
>> have a little cost that should be evaluated.
>>
>> The freeing is probably not the only problem:
>> - packet duplication: are the offload infos copied? If no, it means that
>> the copy is not exactly a copy
>> - if you chain 2 mbufs that both have offload info attached, how does it
>> behave?
>> - if you prepend a segment to your mbuf, you need to copy the mbuf
>> offload pointer, and also parse the list of offload to update the
>> ol->m pointer of each element.
>>
>>>> It seems that these offload structures are only used to pass crypto
>>>> info to the cryptodev. Would it be a problem to have an API like this?
>>>>
>>>> rx_burst(port, q, mbuf_tab, crypto_tab, n);
>>>>
>>>
>>> I really dislike this option, there's no direct linkage between mbuf and
>>> offload operation.
>>>
>>>> Or even:
>>>>
>>>> rx_burst(port, q, crypto_tab, n);
>>>>
>>>> with each *cryto_tab pointing to a mbuf
>>>>
>>>
>>> I looked at this but it would really hamstring any pipelining
>>> applications which might want to attach multiple offloads to a mbuf at a
>>> point in the pipeline for processing at later steps.
>>
>> As far as I can see, there is already a way to chain several crypto
>> operations in the crypto structure.
>>
>> Another option is to use the mbuf offload API (or the m->userdata
>> pointer which already works for that) only in the application:
>>
>> - the field is completely ignored by the mbuf api and the dpdk driver
>> - it is up to the application to initialize it and free it
>>
>> -> it can only be used when passing mbuf from a part of the app
>> to another, so it perfectly matches the pipeline use case.
>
> I don't think we should start to re-use userdata.
> Userdata was intended for the upper layer app to pass/store it's
> private data associated with mbuf, and we probably should keep it this way.
> While mbuf_offload (or whatever we'll name it) supposed to keep data
> necessary for crypto (and other future type of devices) to operate with mbuf.
>
> All your comments above about that this new field is just ignored by most mbuf
> operations (copy/attach/append/free, etc) are valid.
> By I suppose for now we can just state that for mbuf_offload is not supported by
> all these mbuf ops.
> I understand that current API is probably not perfect and might need to be revised in future.
> Again, as it is completely new feature, I suspect it would be a lot of change requests for it anyway.
> But we need some generic way to pass other (not ethdev) specific information within mbuf
> between user-level and PMDs for non-ethernet devices (and probably between different PMDs too).
>
> Konstantin
>
Just to re-iterate Konstantin's point above. I'm aware that a number of
mbuf operations currently are not supported and are not aware of the
rte_mbuf_offload, but we will be continuing development throughout 2.3
and beyond to address this. Also I hope we will get much more community
feedback and interaction so we can get a more definite feature set for
the library, and by minimizing the features in this release, it will
allow more flexibility on how we can develop this part of handling
offloaded operations and it will limit the ABI issues we will face if it
turns out we need to change this going forwards.
Thanks
Declan
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf
2015-11-23 12:16 3% ` Declan Doherty
@ 2015-11-23 13:08 0% ` Olivier MATZ
2015-11-23 14:17 0% ` Thomas Monjalon
2015-11-23 14:33 3% ` Declan Doherty
0 siblings, 2 replies; 200+ results
From: Olivier MATZ @ 2015-11-23 13:08 UTC (permalink / raw)
To: Declan Doherty, Ananyev, Konstantin, dev
Hi,
On 11/23/2015 01:16 PM, Declan Doherty wrote:
>> I don't think we should start to re-use userdata.
>> Userdata was intended for the upper layer app to pass/store it's
>> private data associated with mbuf, and we probably should keep it this
>> way.
If the crypto API PMD takes both mbuf and crypto instead of just the
mbuf, the mbuf_offload and the userdata wouldn't be very different,
as the metadata would stay inside the application.
So, if it's application private (the dpdk does not know how to handle
it in case of mbuf free, dup, ...), the content of it should be
app-specific.
>> While mbuf_offload (or whatever we'll name it) supposed to keep data
>> necessary for crypto (and other future type of devices) to operate
>> with mbuf.
Any idea of future devices?
>> All your comments above about that this new field is just ignored by
>> most mbuf
>> operations (copy/attach/append/free, etc) are valid.
>> By I suppose for now we can just state that for mbuf_offload is not
>> supported by
>> all these mbuf ops.
So, who is responsible of freeing the mbuf offload metadata?
The crypto pmd ?
It means that as soon as the mbuf offload is added to the mbuf, it is
not possible to call any other dpdk function that would process the
mbuf... if we cannot call anything else before, why not just passing
the crypto argument as a parameter?
Managing offload data would even be more complex in the future if there
are more than one mbuf_offload attached to the mbuf.
>> I understand that current API is probably not perfect and might need
>> to be revised in future.
The problem is that it's not easy to change the dpdk API now.
>> Again, as it is completely new feature, I suspect it would be a lot of
>> change requests for it anyway.
>> But we need some generic way to pass other (not ethdev) specific
>> information within mbuf
>> between user-level and PMDs for non-ethernet devices (and probably
>> between different PMDs too).
If a crypto PMD needs a crypto info, why not adding a crypto argument?
I feel it's clearer from a user point of view.
About PMD to PMD metadata, do you have any use case?
> Just to re-iterate Konstantin's point above. I'm aware that a number of
> mbuf operations currently are not supported and are not aware of the
> rte_mbuf_offload, but we will be continuing development throughout 2.3
> and beyond to address this. Also I hope we will get much more community
> feedback and interaction so we can get a more definite feature set for
> the library, and by minimizing the features in this release, it will
> allow more flexibility on how we can develop this part of handling
> offloaded operations and it will limit the ABI issues we will face if it
> turns out we need to change this going forwards.
I can see the amount of work you've done for making the cryptodev
happen in dpdk. I also recognize that I didn't make comments very early.
If we really want to have this feature in the next release, maybe there
is a way to mark it as experimental, meaning that the API is subject to
change? What do you think?
Thomas, any comment?
Regards,
Olivier
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf
2015-11-23 13:08 0% ` Olivier MATZ
@ 2015-11-23 14:17 0% ` Thomas Monjalon
2015-11-23 14:33 3% ` Declan Doherty
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-11-23 14:17 UTC (permalink / raw)
To: Olivier MATZ; +Cc: dev
2015-11-23 14:08, Olivier MATZ:
> 2015-11-23 12:16, Declan Doherty:
> > 2015-11-23 11:52, Ananyev, Konstantin:
> >> I understand that current API is probably not perfect and might need
> >> to be revised in future.
>
> The problem is that it's not easy to change the dpdk API now.
[...]
> > Just to re-iterate Konstantin's point above. I'm aware that a number of
> > mbuf operations currently are not supported and are not aware of the
> > rte_mbuf_offload, but we will be continuing development throughout 2.3
> > and beyond to address this. Also I hope we will get much more community
> > feedback and interaction so we can get a more definite feature set for
> > the library, and by minimizing the features in this release, it will
> > allow more flexibility on how we can develop this part of handling
> > offloaded operations and it will limit the ABI issues we will face if it
> > turns out we need to change this going forwards.
>
> I can see the amount of work you've done for making the cryptodev
> happen in dpdk. I also recognize that I didn't make comments very early.
>
> If we really want to have this feature in the next release, maybe there
> is a way to mark it as experimental, meaning that the API is subject to
> change? What do you think?
>
> Thomas, any comment?
Yes, it is a totally new work and it probably needs more time to have a
design working well for most of use cases.
As I already discussed with Olivier, I think it should be considered as
experimental. It means we can try it but do not consider it as a stable
API. So the deprecation process would not apply until the experimental
flag is removed.
For the release 2.2, it would be better to remove the crypto dependency
in mbuf. Do you think it is possible?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf
2015-11-23 13:08 0% ` Olivier MATZ
2015-11-23 14:17 0% ` Thomas Monjalon
@ 2015-11-23 14:33 3% ` Declan Doherty
1 sibling, 0 replies; 200+ results
From: Declan Doherty @ 2015-11-23 14:33 UTC (permalink / raw)
To: Olivier MATZ, Ananyev, Konstantin, dev
On 23/11/15 13:08, Olivier MATZ wrote:
> Hi,
>
> On 11/23/2015 01:16 PM, Declan Doherty wrote:
>>> I don't think we should start to re-use userdata.
>>> Userdata was intended for the upper layer app to pass/store it's
>>> private data associated with mbuf, and we probably should keep it this
>>> way.
>
> If the crypto API PMD takes both mbuf and crypto instead of just the
> mbuf, the mbuf_offload and the userdata wouldn't be very different,
> as the metadata would stay inside the application.
>
> So, if it's application private (the dpdk does not know how to handle
> it in case of mbuf free, dup, ...), the content of it should be
> app-specific.
>
>>> While mbuf_offload (or whatever we'll name it) supposed to keep data
>>> necessary for crypto (and other future type of devices) to operate
>>> with mbuf.
>
> Any idea of future devices?
Well the QAT hardware supports compression, so I guess that might be a
likely candidate for future work.
>
>>> All your comments above about that this new field is just ignored by
>>> most mbuf
>>> operations (copy/attach/append/free, etc) are valid.
>>> By I suppose for now we can just state that for mbuf_offload is not
>>> supported by
>>> all these mbuf ops.
>
> So, who is responsible of freeing the mbuf offload metadata?
> The crypto pmd ?
>
> It means that as soon as the mbuf offload is added to the mbuf, it is
> not possible to call any other dpdk function that would process the
> mbuf... if we cannot call anything else before, why not just passing
> the crypto argument as a parameter?
>
> Managing offload data would even be more complex in the future if there
> are more than one mbuf_offload attached to the mbuf.
>
>>> I understand that current API is probably not perfect and might need
>>> to be revised in future.
>
> The problem is that it's not easy to change the dpdk API now.
>
>>> Again, as it is completely new feature, I suspect it would be a lot of
>>> change requests for it anyway.
>>> But we need some generic way to pass other (not ethdev) specific
>>> information within mbuf
>>> between user-level and PMDs for non-ethernet devices (and probably
>>> between different PMDs too).
>
> If a crypto PMD needs a crypto info, why not adding a crypto argument?
> I feel it's clearer from a user point of view.
>
> About PMD to PMD metadata, do you have any use case?
One use case that comes to mind would be the enablement of inline IPsec.
To enable this you would need a mechanism to attach the IPsec metadata,
ESP header offsets etc to an mbuf which the PMD can then use to
correctly complete the tx descriptor.
>
>
>> Just to re-iterate Konstantin's point above. I'm aware that a number of
>> mbuf operations currently are not supported and are not aware of the
>> rte_mbuf_offload, but we will be continuing development throughout 2.3
>> and beyond to address this. Also I hope we will get much more community
>> feedback and interaction so we can get a more definite feature set for
>> the library, and by minimizing the features in this release, it will
>> allow more flexibility on how we can develop this part of handling
>> offloaded operations and it will limit the ABI issues we will face if it
>> turns out we need to change this going forwards.
>
> I can see the amount of work you've done for making the cryptodev
> happen in dpdk. I also recognize that I didn't make comments very early.
>
> If we really want to have this feature in the next release, maybe there
> is a way to mark it as experimental, meaning that the API is subject to
> change? What do you think?
I wouldn't be against this idea. I think a mechanism for marking new
libraries / APIs as experimental for their initial release could be very
useful to allow new features to be introduced with the flexibility to
make further API changes on user feedback without the overhead of ABI
management in the subsequent release.
>
> Thomas, any comment?
>
> Regards,
> Olivier
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v9 0/3] User-space ethtool sample application
2015-11-20 15:34 3% ` [dpdk-dev] [PATCH v9 0/3] " Remy Horton
2015-11-20 15:34 4% ` [dpdk-dev] [PATCH v9 1/3] Remove ABI requirement for external library builds Remy Horton
@ 2015-11-24 3:05 0% ` Liu, Yong
1 sibling, 0 replies; 200+ results
From: Liu, Yong @ 2015-11-24 3:05 UTC (permalink / raw)
To: Horton, Remy, dev
Tested-by: Yong Liu <yong.liu@intel.com>
- Tested Commit: 4522eca1352d8ed7c0823e328e2a68c2ba6459ab
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc version 4.8.3 20140911
- CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
- NIC: Intel Corporation Device 82599ES [8086:10fb]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 9 cases, 9 passed, 0 failed
- Prerequisites command / instruction:
Build userspace ethtool sample
make -C examples/ethtool
- Case: ethtool_dump_driver_info
Description: check userspace sample can dump driver information and port
statistics
Command / instruction:
Start userspace ethtool sample with two ports bound
ethtool -c f -n 4
Wait for the sample start up and shown prompt
EthApp>
Use "drvinfo" command to dump driver information and check it's correct.
EthApp> drvinfo
Port 0 driver: rte_ixgbe_pmd (ver: RTE 2.2.0-rc1)
Port 1 driver: rte_ixgbe_pmd (ver: RTE 2.2.0-rc1)
Change tester port link down and check link status can be detected.
EthApp> link
Port 0: Down
Port 1: Down
Send packets to port0 and port1 and check port statistic correct.
EthApp> Port 0 stats
In: 1 (64 bytes)
Out: 1 (64 bytes)
Err: 0
- Case: ethtool_vlan
Description: check userspace sample can configure port vlan setting
Command / instruction:
Enable port vlan filer in main file
cfg_port.rxmode.hw_vlan_filter=1
Rebuild sample and start userspace ethtool sample with two ports bound
ethtool -c f -n 4
Add random vlan on port and send packet with same vlan
EthApp> vlan 0 add 2997
Check packet normally forwarded and port statistic correct
EthApp> Port 0 stats
In: 1 (64 bytes)
Out: 1 (64 bytes)
Err: 0
Send packet with wrong vlan and check packet not forwarded
EthApp> Port 0 stats
In: 1 (64 bytes)
Out: 1 (64 bytes)
Err: 0
Remove the random vlan on port and send packet with same vlan
EthApp> vlan 0 remove 2997
Check packet not forwarded
EthApp> Port 0 stats
In: 1 (64 bytes)
Out: 1 (64 bytes)
Err: 0
- Case: ethtool_mac_address
Description: check userspace sample can configure port mac address
Command / instruction:
Start userspace ethtool sample with two ports bound
ethtool -c f -n 4
Add random vlan on port and send packet with same vlan
EthApp> vlan 0 add 2997
Changed port mac address and "macaddr" command can dump new mac
EthApp> macaddr 0 00:10:00:00:00:00
EthApp> macaddr 0
Port 0 MAC Address: 00:10:00:00:00:00
Send packet and check forwarded packet source mac changed
- Case: ethtool_port_config
Description: check userspace sample can start/stop port
Command / instruction:
Start userspace ethtool sample with two ports bound
ethtool -c f -n 4
Stop port and check forwarding cannot work
EthApp> stop 0
Restart port and check packet can be normally forwarded
- Case: ethtool_retrieve_eeprom
Description: check userspace sample can retrieve port eerprom file
Command / instruction:
Start userspace ethtool sample with two ports bound
ethtool -c f -n 4
Retrieve port eeprom file and saved for later compare
EthApp> eeprom 0 eeprom_0.bin
Bound port back to default kernel driver and dump eeprom by ethtool
ethtool --eeprom-dump p1p3 raw on > ethtool_eeprom_0.bin
Check userspace ethool and linux ethtool dumped file md5 are the same
md5sum eeprom_0.bin
md5sum ethtool_eeprom_0.bin
- Case: ethtool_retrieve_register
Description: check userspace sample can retrieve port register file
Command / instruction:
Start userspace ethtool sample with two ports bound
ethtool -c f -n 4
Retrieve port register file
EthApp> regs 0 regs_0.bin
User linux ethtool dump this file and check information correct
ethtool -d p1p3 raw off file regs_0.bin
- Case: ethtool_ring_parameter
Description: check userspace sample can configure pending entries of Rx/Tx
ring
Command / instruction:
Start userspace ethtool sample with two ports bound
ethtool -c f -n 4
Use command "ringparam" dump port pending entries
EthApp> ringparam 0
Port 0 ring parameters
Rx Pending: 128 (4096 max)
Tx Pending: 256 (4096 max)
Changed pending entries of Rx/Tx ring to max value
EthApp> ringparam 0 4096 4096
Check that packet can be normally forwarded
EthApp> portstats 0
Port 0 stats
In: 1 (64 bytes)
Out: 1 (64 bytes)
Err: 0
- Case: ethtool_rx_pause
Description: check userspace sample can configure port rx pause setting
Command / instruction:
Start userspace ethtool sample with two ports bound
ethtool -c f -n 4
Enable port 0 handle rx pause frame
EthApp> pause 0 rx
Based on 50% line rate, calculate how many packets hanged per pause frame
Configure transmit number of packets and then one pause frame from test
port
Check forwarded rate just 50% and difference smaller than 0.1%
- Case: ethtool_tx_pause
Description: check userspace sample can configure port tx pause setting
Command / instruction:
After receive burst of packets, sleep a while for slow down
usleep(10);
Rebuild sample and start userspace ethtool sample with two ports bound
ethtool -c f -n 4
Enable port 0 wiht transmit pause frame
EthApp> pause 0 tx
Send packets with line rate from tester port
Enable tester port link control, transmit speed will also dropped
After few seconds stop transmit, check tester port received packets more
than transmitted.
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Remy Horton
> Sent: Friday, November 20, 2015 11:35 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v9 0/3] User-space ethtool sample application
>
> Further enhancements to the userspace ethtool implementation that was
> submitted in 2.1 and packaged as a self-contained sample application.
> Implements an rte_ethtool shim layer based on rte_ethdev API, along
> with a command prompt driven demonstration application.
>
> This patchset depends on:
> * http://dpdk.org/dev/patchwork/patch/8070/
>
> v9:
> * Merged in upstream external lib dependency
> * Added sanity check to shim MTU set function
> * Added example to example/Makefile
> * Rebased to latest master
>
> v8:
> * Rebased to latest origin/master
>
> v7:
> * Ringparam printouts wrong way round
> * Ringparam help message corrections
> * Use __rte_unused instead of __attribute__((unused))
> * Allow Jumbo-sized MTUs
> * Documentation style and spelling changes
>
> v6:
> * Fixed hang when run with zero available ports
> * Fixed incorrect sanity check preventing EEPROM dumps
> * Documentation additions
> * Fixed RxMode accepting untagged packets
> * Fixed ringparam allocation being too small
>
> v5:
> * Documentation changes
>
> v4:
> * Fixed assumption that master core always has id zero
> * Changed 1:1 core-to-port to 2 core (ethtool & ports) design
> * Included the correct documentation..
>
> v3:
> * Made use of enums for core state.
> * Fixed Makefile issue.
> * Fixed incorrect assumption with core ids.
> * Changed handling of more ports than cores.
>
> v2:
> * Replaced l2fwd base with simpler application.
> * Added ringparam functions.
> * Added documentation.
>
> Remy Horton (3):
> Remove ABI requirement for external library builds.
> example: add user-space ethtool sample application
> doc: add user-space ethtool sample app guide & release notes
>
> MAINTAINERS | 4 +
> doc/guides/rel_notes/release_2_2.rst | 1 +
> doc/guides/sample_app_ug/ethtool.rst | 160 +++++++
> doc/guides/sample_app_ug/index.rst | 1 +
> examples/Makefile | 1 +
> examples/ethtool/Makefile | 48 ++
> examples/ethtool/ethtool-app/Makefile | 54 +++
> examples/ethtool/ethtool-app/ethapp.c | 873
> ++++++++++++++++++++++++++++++++++
> examples/ethtool/ethtool-app/ethapp.h | 41 ++
> examples/ethtool/ethtool-app/main.c | 305 ++++++++++++
> examples/ethtool/lib/Makefile | 57 +++
> examples/ethtool/lib/rte_ethtool.c | 423 ++++++++++++++++
> examples/ethtool/lib/rte_ethtool.h | 410 ++++++++++++++++
> mk/rte.extlib.mk | 2 +
> mk/rte.lib.mk | 6 +
> 15 files changed, 2386 insertions(+)
> create mode 100644 doc/guides/sample_app_ug/ethtool.rst
> create mode 100644 examples/ethtool/Makefile
> create mode 100644 examples/ethtool/ethtool-app/Makefile
> create mode 100644 examples/ethtool/ethtool-app/ethapp.c
> create mode 100644 examples/ethtool/ethtool-app/ethapp.h
> create mode 100644 examples/ethtool/ethtool-app/main.c
> create mode 100644 examples/ethtool/lib/Makefile
> create mode 100644 examples/ethtool/lib/rte_ethtool.c
> create mode 100644 examples/ethtool/lib/rte_ethtool.h
>
> --
> 1.9.3
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
@ 2015-11-24 14:31 4% Panu Matilainen
2015-12-01 12:37 4% ` Robie Basak
0 siblings, 2 replies; 200+ results
From: Panu Matilainen @ 2015-11-24 14:31 UTC (permalink / raw)
To: dev
The physically linked-together combined library has been an increasing
source of problems, as was predicted when library and symbol versioning
was introduced. Replace the complex and fragile construction with a
simple linker script which achieves the same without all the problems,
remove the related kludges from eg mlx drivers.
Since creating the linker script is practically zero cost, remove the
config option and just create it always.
Based on a patch by Sergio Gonzales Monroy, linker script approach
initially suggested by Neil Horman.
Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Suggested-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
---
config/common_bsdapp | 5 ---
config/common_linuxapp | 5 ---
drivers/net/Makefile | 1 -
drivers/net/mlx4/Makefile | 6 ---
drivers/net/mlx5/Makefile | 6 ---
lib/Makefile | 1 -
mk/rte.app.mk | 10 -----
mk/rte.combinedlib.mk | 57 ++++++++++++++++++++++++++
mk/rte.lib.mk | 16 --------
mk/rte.sdkbuild.mk | 4 +-
mk/rte.sharelib.mk | 101 ----------------------------------------------
11 files changed, 59 insertions(+), 153 deletions(-)
create mode 100644 mk/rte.combinedlib.mk
delete mode 100644 mk/rte.sharelib.mk
diff --git a/config/common_bsdapp b/config/common_bsdapp
index bdf1fcd..f38cdc0 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -84,11 +84,6 @@ CONFIG_RTE_ARCH_STRICT_ALIGN=n
CONFIG_RTE_BUILD_SHARED_LIB=n
#
-# Combine to one single library
-#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
-
-#
# Use newest code breaking previous ABI
#
CONFIG_RTE_NEXT_ABI=y
diff --git a/config/common_linuxapp b/config/common_linuxapp
index a565153..60f5d92 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -84,11 +84,6 @@ CONFIG_RTE_ARCH_STRICT_ALIGN=n
CONFIG_RTE_BUILD_SHARED_LIB=n
#
-# Combine to one single library
-#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
-
-#
# Use newest code breaking previous ABI
#
CONFIG_RTE_NEXT_ABI=y
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index cddcd57..5d9c585 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -51,5 +51,4 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
-include $(RTE_SDK)/mk/rte.sharelib.mk
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/net/mlx4/Makefile b/drivers/net/mlx4/Makefile
index 23b766d..d2f5692 100644
--- a/drivers/net/mlx4/Makefile
+++ b/drivers/net/mlx4/Makefile
@@ -31,12 +31,6 @@
include $(RTE_SDK)/mk/rte.vars.mk
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS)$(CONFIG_RTE_BUILD_SHARED_LIB),yy)
-all:
- @echo 'MLX4: Not supported in a combined shared library'
- @false
-endif
-
# Library name.
LIB = librte_pmd_mlx4.a
diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index ae568e6..736d205 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -31,12 +31,6 @@
include $(RTE_SDK)/mk/rte.vars.mk
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS)$(CONFIG_RTE_BUILD_SHARED_LIB),yy)
-all:
- @echo 'MLX5: Not supported in a combined shared library'
- @false
-endif
-
# Library name.
LIB = librte_pmd_mlx5.a
diff --git a/lib/Makefile b/lib/Makefile
index 9727b83..a8fe4b2 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -62,5 +62,4 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
endif
-include $(RTE_SDK)/mk/rte.sharelib.mk
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 148653e..2a8fdf7 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -59,10 +59,6 @@ _LDLIBS-y += -L$(RTE_SDK_BIN)/lib
_LDLIBS-y += --whole-archive
-_LDLIBS-$(CONFIG_RTE_BUILD_COMBINE_LIBS) += -l$(RTE_LIBNAME)
-
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
_LDLIBS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += -lrte_distributor
_LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER) += -lrte_reorder
@@ -88,8 +84,6 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrt
_LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost
-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += -lpcap
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += -lsze2
@@ -114,8 +108,6 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += -lz
_LDLIBS-y += --start-group
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
_LDLIBS-$(CONFIG_RTE_LIBRTE_KVARGS) += -lrte_kvargs
_LDLIBS-$(CONFIG_RTE_LIBRTE_MBUF) += -lrte_mbuf
_LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += -lrte_ip_frag
@@ -153,8 +145,6 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += -lrte_pmd_null
endif # ! $(CONFIG_RTE_BUILD_SHARED_LIB)
-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
_LDLIBS-y += $(EXECENV_LDLIBS)
_LDLIBS-y += --end-group
_LDLIBS-y += --no-whole-archive
diff --git a/mk/rte.combinedlib.mk b/mk/rte.combinedlib.mk
new file mode 100644
index 0000000..033287c
--- /dev/null
+++ b/mk/rte.combinedlib.mk
@@ -0,0 +1,57 @@
+# BSD LICENSE
+#
+# Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+#
+# * Redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in
+# the documentation and/or other materials provided with the
+# distribution.
+# * Neither the name of Intel Corporation nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+default: all
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+EXT:=.so
+else
+EXT:=.a
+endif
+
+COMBINEDLIB := lib$(RTE_LIBNAME)$(EXT)
+
+LIBS := $(notdir $(wildcard $(RTE_OUTPUT)/lib/*$(EXT)))
+
+all: FORCE
+ $(Q)echo "GROUP ( $(LIBS) )" > $(RTE_OUTPUT)/lib/$(COMBINEDLIB)
+
+#
+# Clean all generated files
+#
+.PHONY: clean
+clean:
+ $(Q)rm -f $(RTE_OUTPUT)/lib/$(COMBINEDLIB)
+
+.PHONY: FORCE
+FORCE:
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 06a1519..92c9d9e 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -134,14 +134,6 @@ endif
$(depfile_newer)),\
$(O_TO_S_DO))
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
- $(if $(or \
- $(file_missing),\
- $(call cmdline_changed,$(O_TO_C_STR)),\
- $(depfile_missing),\
- $(depfile_newer)),\
- $(O_TO_C_DO))
-endif
else
$(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
@@ -157,14 +149,6 @@ $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
$(depfile_missing),\
$(depfile_newer)),\
$(O_TO_A_DO))
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
- $(if $(or \
- $(file_missing),\
- $(call cmdline_changed,$(O_TO_C_STR)),\
- $(depfile_missing),\
- $(depfile_newer)),\
- $(O_TO_C_DO))
-endif
endif
#
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 38ec7bd..319fe38 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -93,8 +93,8 @@ $(ROOTDIRS-y):
@[ -d $(BUILDDIR)/$@ ] || mkdir -p $(BUILDDIR)/$@
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
- @if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
- $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
+ @if [ $@ = drivers ]; then \
+ $(MAKE) -f $(RTE_SDK)/mk/rte.combinedlib.mk; \
fi
%_clean:
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
deleted file mode 100644
index 7bb7219..0000000
--- a/mk/rte.sharelib.mk
+++ /dev/null
@@ -1,101 +0,0 @@
-# BSD LICENSE
-#
-# Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-# All rights reserved.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions
-# are met:
-#
-# * Redistributions of source code must retain the above copyright
-# notice, this list of conditions and the following disclaimer.
-# * Redistributions in binary form must reproduce the above copyright
-# notice, this list of conditions and the following disclaimer in
-# the documentation and/or other materials provided with the
-# distribution.
-# * Neither the name of Intel Corporation nor the names of its
-# contributors may be used to endorse or promote products derived
-# from this software without specific prior written permission.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-include $(RTE_SDK)/mk/internal/rte.build-pre.mk
-
-# VPATH contains at least SRCDIR
-VPATH += $(SRCDIR)
-
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
-ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
-LIB_ONE := lib$(RTE_LIBNAME).so
-else
-LIB_ONE := lib$(RTE_LIBNAME).a
-endif
-endif
-
-.PHONY:sharelib
-sharelib: $(LIB_ONE) FORCE
-
-OBJS = $(wildcard $(RTE_OUTPUT)/build/lib/*.o)
-
-ifeq ($(LINK_USING_CC),1)
-# Override the definition of LD here, since we're linking with CC
-LD := $(CC) $(CPU_CFLAGS)
-O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \
- -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
-else
-O_TO_S = $(LD) $(CPU_LDFLAGS) \
- -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
-endif
-
-O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight
-O_TO_S_DISP = $(if $(V),"$(O_TO_S_STR)"," LD $(@)")
-O_TO_S_CMD = "cmd_$@ = $(O_TO_S_STR)"
-O_TO_S_DO = @set -e; \
- echo $(O_TO_S_DISP); \
- $(O_TO_S)
-
-O_TO_A = $(AR) crus $(RTE_OUTPUT)/lib/$(LIB_ONE) $(OBJS)
-O_TO_A_STR = $(subst ','\'',$(O_TO_A)) #'# fix syntax highlight
-O_TO_A_DISP = $(if $(V),"$(O_TO_A_STR)"," LD $(@)")
-O_TO_A_CMD = "cmd_$@ = $(O_TO_A_STR)"
-O_TO_A_DO = @set -e; \
- echo $(O_TO_A_DISP); \
- $(O_TO_A)
-#
-# Archive objects to share library
-#
-
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
-ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
-$(LIB_ONE): FORCE
- @[ -d $(dir $@) ] || mkdir -p $(dir $@)
- $(O_TO_S_DO)
-else
-$(LIB_ONE): FORCE
- @[ -d $(dir $@) ] || mkdir -p $(dir $@)
- $(O_TO_A_DO)
-endif
-endif
-
-#
-# Clean all generated files
-#
-.PHONY: clean
-clean: _postclean
-
-.PHONY: doclean
-doclean:
- $(Q)rm -rf $(LIB_ONE)
-
-.PHONY: FORCE
-FORCE:
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine
2015-11-20 19:46 0% ` Eric Kinzie
@ 2015-11-24 14:52 0% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2015-11-24 14:52 UTC (permalink / raw)
To: Eric Kinzie, ferruh.yigit, dev, Eric Kinzie
On 11/20/2015 09:46 PM, Eric Kinzie wrote:
> On Tue Nov 03 11:48:57 +0000 2015, Ferruh Yigit wrote:
>> On Tue, Nov 03, 2015 at 01:31:45PM +0200, Panu Matilainen wrote:
>>> On 11/03/2015 01:02 PM, Ferruh Yigit wrote:
>>>> On Tue, Nov 03, 2015 at 08:48:16AM +0200, Panu Matilainen wrote:
>>>>> On 11/02/2015 06:42 PM, Eric Kinzie wrote:
>>>>>> On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
>>>>>>> On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
>>>>>>>> 2015-10-19 08:36, Eric Kinzie:
>>>>>>>>> Size of struct rte_eth_bond_8023ad_conf changed. Increment LIBABIVER
>>>>>>>>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
>>>>>>>>> functions.
>>>>>>>> [...]
>>>>>>>>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
>>>>>>>> [...]
>>>>>>>>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>>>>>>>>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev *dev, struct rte_eth_bond_8023ad_conf *conf), \
>>>>>>>>> + bond_mode_8023ad_setup_v22);
>>>>>>>>
>>>>>>>> I'm sorry it doesn't work well when trying to build a combined lib:
>>>>>>>>
>>>>>>>> ld: libdpdk.so: version node not found for symbol bond_mode_8023ad_setup@@DPDK_2.2
>>>>>>>>
>>>>>>>> The symbols are OK in the .o file:
>>>>>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup@@DPDK_2.2
>>>>>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup@DPDK_2.0
>>>>>>>> 0000000000002260 g F .text 00000000000000da bond_mode_8023ad_setup_v20
>>>>>>>> 0000000000002340 g F .text 0000000000000171 bond_mode_8023ad_setup_v22
>>>>>>>> 0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
>>>>>>>>
>>>>>>>> I don't understand the problem and I am considering disabling versioning in
>>>>>>>> combined library.
>>>>>>>>
>>>>>>>> Any idea?
>>>>>>>>
>>>>>>>
>>>>>>> The .map additions look incorrect to me:
>>>>>>>
>>>>>>>> diff --git a/drivers/net/bonding/rte_eth_bond_version.map b/drivers/net/bonding/rte_eth_bond_version.map
>>>>>>>> index 22bd920..7f78717 100644
>>>>>>>> --- a/drivers/net/bonding/rte_eth_bond_version.map
>>>>>>>> +++ b/drivers/net/bonding/rte_eth_bond_version.map
>>>>>>>> @@ -17,6 +17,9 @@ DPDK_2.0 {
>>>>>>>> rte_eth_bond_slaves_get;
>>>>>>>> rte_eth_bond_xmit_policy_get;
>>>>>>>> rte_eth_bond_xmit_policy_set;
>>>>>>>> + rte_eth_bond_8023ad_ext_collect;
>>>>>>>> + rte_eth_bond_8023ad_ext_distrib;
>>>>>>>> + rte_eth_bond_8023ad_ext_slowtx;
>>>>>>>
>>>>>>> These symbols didn't exist in DPDK 2.0 but are only being added
>>>>>>> here. So why are they being added to the 2.0 section?
>>>>>>
>>>>>> Yes, I think these should probably be moved.
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> local: *;
>>>>>>>> };
>>>>>>>> @@ -27,3 +30,10 @@ DPDK_2.1 {
>>>>>>>> rte_eth_bond_free;
>>>>>>>>
>>>>>>>> } DPDK_2.0;
>>>>>>>> +
>>>>>>>> +DPDK_2.2 {
>>>>>>>> + local
>>>>>>>> +
>>>>>>>> + bond_mode_8023ad_conf_get;
>>>>>>>> + bond_mode_8023ad_setup;
>>>>>>>> +} DPDK_2.1;
>>>>>>>
>>>>>>> These are marked local, as in, "not exported" which doesn't seem
>>>>>>> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
>>>>>>> the symbol export map should look like here:
>>>>>>
>>>>>>
>>>>>> These were not exported to begin with. But after versioning these
>>>>>> functions, they are exported unless explicitly declared to be local here.
>>>>>>
>>>>>
>>>>> And this does not ring any warning bells? :)
>>>>>
>>>>> Sorry, I was not looking at the patch as a whole. You're declaring these
>>>>> symbols as exported with the versioning macros, eg
>>>>>
>>>>> BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
>>>>>
>>>>> ...and then explicitly telling it to not export them by declaring local, and
>>>>> then we wonder why it has trouble finding the symbols.
>>>>> The versioning macros wont invent the librte_ prefix for you, you need to
>>>>> rename the functions accordingly.
>>>>>
>>>>> But all this versioning gymnastics is moot anyway because you declare the
>>>>> ABI incompatible:
>>>>>
>>>>> -LIBABIVER := 1
>>>>> +LIBABIVER := 2
>>>>>
>>>>> This changes the library soname, so no binary compiled against the previous
>>>>> version can possibly use it anymore. As in, by definition there can be no
>>>>> callers of the _v20 variants after this ABI version bump.
>>>>>
>>>> An observation: even soname is different, just renaming .so file itself works.
>>>>
>>>> And this can be useful for the case:
>>>> libx.so.1 provides functions A, B, C
>>>> app1 compiled against libx.so.1, using only function B
>>>>
>>>> libx.so.1 updated only thefunction A and become libx.so.2
>>>> app1 still can run successfully by re-naming lib to libx.so.1 (even soname is libx.so.2)
>>>>
>>>> But for this usage, user needs to know which function updated and is it safe or not to use this library,
>>>> I wonder if there is an automatic way of resolving this dependency.
>>>
>>> Erm, no. The whole point of changing soname and the physical filename is to
>>> tell others it is incompatible with earlier versions. Yes you can rename the
>>> file and get lucky (or not), just like you can play Russian roulette.
>>> Neither are particularly healthy ideas.
>>>
>>> Symbol version exists in part to allow libraries to evolve while maintaining
>>> compatibility, but it requires careful planning and programming. When public
>>> structs change, the structs would have to be versioned too, and from there
>>> on it starts getting more and more complicated.
>>>
>>
>> If we strictly want to prevent using old library, whenever LIBABIVER increased, we should update .map as following, right?
>>
>> FROM: (dpdk2.1)
>> ================
>> DPDK_2.0 {
>> A;
>> B;
>> C;
>> };
>>
>> DPDK_2.1 {
>> D;
>> E;
>> };
>>
>> LIBABIVER=1
>> ================
>>
>> TO: (dpdk2.2)
>> ================
>> DPDK_2.2 {
>> A;
>> B;
>> C;
>> D;
>> E;
>> };
>>
>> LIBABIVER=2
>> ================
>>
>>
>> So this won't work for anybody without luck factor, I think currently we are not doing this.
>>
>>
>> thanks,
>> ferruh
>>
>>
>
> Panu, Ferruh, is there agreement on an acceptable approach to this?
Define "this" :)
As discussed before in (and around) these:
http://dpdk.org/ml/archives/dev/2015-November/027317.html
http://dpdk.org/ml/archives/dev/2015-November/027321.html
Thomas thinks the struct modification might not even need a LIBABIVER
bump, but that all depends on the details of how the struct is used,
I've no clue about that so I wont comment further on it.
Since the added symbols seem to be intended to be private, the
versioning macro uses and .map changes should be just dropped. Only
exported symbols are to be versioned.
So ultimately the answer is, "yes, but it depends on the details" :)
- Panu -
- Panu -
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 2/2] ethdev: add sanity checks to functions
2015-11-17 15:53 3% ` Stephen Hemminger
@ 2015-11-24 14:56 3% ` Bruce Richardson
2015-11-24 15:29 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2015-11-24 14:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Tue, Nov 17, 2015 at 07:53:09AM -0800, Stephen Hemminger wrote:
> On Tue, 17 Nov 2015 12:21:07 +0000
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
> > The functions rte_eth_rx_queue_count and rte_eth_descriptor_done are
> > supported by very few PMDs. Therefore, it is best to check for support
> > for the functions in the ethdev library, so as to avoid run-time crashes
> > at run-time if the application goes to use those APIs. Similarly, the
> > port parameter should also be checked for validity.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> >
> > ---
> > lib/librte_ether/rte_ethdev.h | 15 +++++++--------
> > 1 file changed, 7 insertions(+), 8 deletions(-)
> >
> > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> > index a00cd46..028be59 100644
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -2533,16 +2533,16 @@ rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id,
> > * @param queue_id
> > * The queue id on the specific port.
> > * @return
> > - * The number of used descriptors in the specific queue.
> > + * The number of used descriptors in the specific queue, or:
> > + * (-EINVAL) if *port_id* is invalid
> > + * (-ENOTSUP) if the device does not support this function
> > */
> > -static inline uint32_t
> > +static inline int
> > rte_eth_rx_queue_count(uint8_t port_id, uint16_t queue_id)
> > {
> > struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > - RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> > - RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_count, 0);
> > -#endif
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
> > + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_count, -ENOTSUP);
> > return (*dev->dev_ops->rx_queue_count)(dev, queue_id);
> > }
> >
> > @@ -2559,15 +2559,14 @@ rte_eth_rx_queue_count(uint8_t port_id, uint16_t queue_id)
> > * - (1) if the specific DD bit is set.
> > * - (0) if the specific DD bit is not set.
> > * - (-ENODEV) if *port_id* invalid.
> > + * - (-ENOTSUP) if the device does not support this function
> > */
> > static inline int
> > rte_eth_rx_descriptor_done(uint8_t port_id, uint16_t queue_id, uint16_t offset)
> > {
> > struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_descriptor_done, -ENOTSUP);
> > -#endif
> > return (*dev->dev_ops->rx_descriptor_done)( \
> > dev->data->rx_queues[queue_id], offset);
> > }
>
> This breaks ABI since older application built with debug will try
> and find the shared library entry for the routine.
Ok, so assuming we care about the ABI for debug builds, is it enough to just
push a patch with a deprecation notice for this for 2.2, or do I need to see about
doing a new patchset with the NEXT_ABI macros included in it? My preference is
obviously for the former.
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 2/2] ethdev: add sanity checks to functions
2015-11-24 14:56 3% ` Bruce Richardson
@ 2015-11-24 15:29 4% ` Thomas Monjalon
2015-11-24 15:45 4% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-24 15:29 UTC (permalink / raw)
To: Bruce Richardson, Stephen Hemminger; +Cc: dev
2015-11-24 14:56, Bruce Richardson:
> On Tue, Nov 17, 2015 at 07:53:09AM -0800, Stephen Hemminger wrote:
> > On Tue, 17 Nov 2015 12:21:07 +0000
> > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > > -static inline uint32_t
> > > +static inline int
Are we talking about this change only?
Or the move in the first patch from .c to .h?
[...]
> > This breaks ABI since older application built with debug will try
> > and find the shared library entry for the routine.
>
> Ok, so assuming we care about the ABI for debug builds,
The return type is not only for debug build?
> is it enough to just push a patch with a deprecation notice for this for 2.2,
The ABI is already broken for ethdev in 2.2.
So the symbol move should not hurt more.
And the API change (return type) should not be a big deal,
but at least an API change notification is required in the release notes.
Other opinion?
> or do I need to see about doing a new patchset with the NEXT_ABI macros
> included in it? My preference is obviously for the former.
No NEXT_ABI is required when ABI is already broken IMHO.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4 2/2] ethdev: add sanity checks to functions
2015-11-24 15:29 4% ` Thomas Monjalon
@ 2015-11-24 15:45 4% ` Bruce Richardson
2015-11-24 15:48 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2015-11-24 15:45 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Tue, Nov 24, 2015 at 04:29:12PM +0100, Thomas Monjalon wrote:
> 2015-11-24 14:56, Bruce Richardson:
> > On Tue, Nov 17, 2015 at 07:53:09AM -0800, Stephen Hemminger wrote:
> > > On Tue, 17 Nov 2015 12:21:07 +0000
> > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > > > -static inline uint32_t
> > > > +static inline int
>
> Are we talking about this change only?
> Or the move in the first patch from .c to .h?
>
The move is the ABI breaker.
> [...]
> > > This breaks ABI since older application built with debug will try
> > > and find the shared library entry for the routine.
> >
> > Ok, so assuming we care about the ABI for debug builds,
>
> The return type is not only for debug build?
>
> > is it enough to just push a patch with a deprecation notice for this for 2.2,
>
> The ABI is already broken for ethdev in 2.2.
> So the symbol move should not hurt more.
> And the API change (return type) should not be a big deal,
> but at least an API change notification is required in the release notes.
> Other opinion?
Ok, it makes sense.
>
> > or do I need to see about doing a new patchset with the NEXT_ABI macros
> > included in it? My preference is obviously for the former.
>
> No NEXT_ABI is required when ABI is already broken IMHO.
If ethdev ABI is already broken, then sure, this additional break for debug
build is no big deal, I think.
I can do a respin of these two patches to include an API note for release notes.
However, I see now that I also need to remove the functions from the map file.
I could do with some help to make sure I do this correctly though. Reading through
the doc on ABI versionning, it looks like I should completely move all existing
functions from the existing release versions and move them to a new 2.2 section,
dropping the four now-inline functions along the way. Is this the correct thing
to do?
/Bruce
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4 2/2] ethdev: add sanity checks to functions
2015-11-24 15:45 4% ` Bruce Richardson
@ 2015-11-24 15:48 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-11-24 15:48 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
2015-11-24 15:45, Bruce Richardson:
> On Tue, Nov 24, 2015 at 04:29:12PM +0100, Thomas Monjalon wrote:
> > 2015-11-24 14:56, Bruce Richardson:
> > > On Tue, Nov 17, 2015 at 07:53:09AM -0800, Stephen Hemminger wrote:
> > > > On Tue, 17 Nov 2015 12:21:07 +0000
> > > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > > > > -static inline uint32_t
> > > > > +static inline int
> >
> > Are we talking about this change only?
> > Or the move in the first patch from .c to .h?
> >
>
> The move is the ABI breaker.
>
> > [...]
> > > > This breaks ABI since older application built with debug will try
> > > > and find the shared library entry for the routine.
> > >
> > > Ok, so assuming we care about the ABI for debug builds,
> >
> > The return type is not only for debug build?
> >
> > > is it enough to just push a patch with a deprecation notice for this for 2.2,
> >
> > The ABI is already broken for ethdev in 2.2.
> > So the symbol move should not hurt more.
> > And the API change (return type) should not be a big deal,
> > but at least an API change notification is required in the release notes.
> > Other opinion?
>
> Ok, it makes sense.
>
> >
> > > or do I need to see about doing a new patchset with the NEXT_ABI macros
> > > included in it? My preference is obviously for the former.
> >
> > No NEXT_ABI is required when ABI is already broken IMHO.
>
> If ethdev ABI is already broken, then sure, this additional break for debug
> build is no big deal, I think.
>
> I can do a respin of these two patches to include an API note for release notes.
> However, I see now that I also need to remove the functions from the map file.
> I could do with some help to make sure I do this correctly though. Reading through
> the doc on ABI versionning, it looks like I should completely move all existing
> functions from the existing release versions and move them to a new 2.2 section,
> dropping the four now-inline functions along the way. Is this the correct thing
> to do?
I think yes.
Removing some symbols means rewriting the symbol map from scratch.
But we never did it yet.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 0/2] ethdev: debug code cleanup
@ 2015-11-24 17:37 3% ` Bruce Richardson
2015-11-24 17:37 4% ` [dpdk-dev] [PATCH v5 1/2] ethdev: remove duplicated debug functions Bruce Richardson
2015-11-24 17:37 4% ` [dpdk-dev] [PATCH v5 2/2] ethdev: add sanity checks to functions Bruce Richardson
1 sibling, 2 replies; 200+ results
From: Bruce Richardson @ 2015-11-24 17:37 UTC (permalink / raw)
To: dev
This patchset performs two cleanups:
1. Four functions in ethdev.c which were enabled for debug only have been
merged into their inlined header-file counterparts. This change required that
a number of macros be renamed and moved to the header file too. The macro changes
are in patches 1 & 2, and the elimination of the separate debug fns are in patch 3.
2. Checks for valid function pointers are added to the API calls for reading
the descriptor ring count, and checking for a valid descriptor. This is because
these functions are not implemented by most drivers, and so it's far safer to
have the check.
NOTE: This patchset now depends upon the cryptodev patchset
---
V5 Changes:
* Remove the 4 debug functions from the map file and, as a result of this, move all
previous functions to the new 2_2 version, sorting them alphabetically.
* Update release notes to cover ABI change
* Update release notes to cover API change for the rx_count() function
V4 Changes:
* Originally this was a 4-patch set, but patches 1 and 2 duplicated changes being
made in the patchset to add crypto device support. Therefore this set has
been reduced to two patches to sit on top of that set.
* As suggested on-list, when adding checks for the function pointers being
valid we can also add in the similarly lightweight checks for the port id
being valid.
V3 Changes:
* Rebased to latest DPDK codebase
* Fixed checkpatch issues in patches 2 and 3.
V2 Changes:
* Rebased to latest DPDK codebase
* Changed type from uint32_t to int for the count function, on the basis of
feedback received.
Bruce Richardson (2):
ethdev: remove duplicated debug functions
ethdev: add sanity checks to functions
doc/guides/rel_notes/release_2_2.rst | 7 ++++
lib/librte_ether/rte_ethdev.c | 64 ---------------------------------
lib/librte_ether/rte_ethdev.h | 62 ++++++++++++++++----------------
lib/librte_ether/rte_ether_version.map | 66 +++++++++++++---------------------
4 files changed, 61 insertions(+), 138 deletions(-)
--
2.5.0
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 1/2] ethdev: remove duplicated debug functions
2015-11-24 17:37 3% ` [dpdk-dev] [PATCH v5 0/2] ethdev: debug code cleanup Bruce Richardson
@ 2015-11-24 17:37 4% ` Bruce Richardson
2015-11-24 17:37 4% ` [dpdk-dev] [PATCH v5 2/2] ethdev: add sanity checks to functions Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2015-11-24 17:37 UTC (permalink / raw)
To: dev
The functions for rx/tx burst, for rx_queue_count and descriptor_done in
the ethdev library all had two copies of the code. One copy in
rte_ethdev.h was inlined for performance, while a second was in
rte_ethdev.c for debugging purposes only. We can eliminate the second
copy of the functions by moving the additional debug checks into the
copies of the functions in the header file. [Any compilation for
debugging at optimization level 0 will not inline the function so the
result should be same as when the function was in the .c file.]
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
doc/guides/rel_notes/release_2_2.rst | 5 +++
lib/librte_ether/Makefile | 2 +-
lib/librte_ether/rte_ethdev.c | 64 ---------------------------------
lib/librte_ether/rte_ethdev.h | 59 +++++++++++++++---------------
lib/librte_ether/rte_ether_version.map | 66 +++++++++++++---------------------
5 files changed, 59 insertions(+), 137 deletions(-)
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 8c77768..d39bf75 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -297,6 +297,11 @@ ABI Changes
* librte_cfgfile: Allow longer names and values by increasing the constants
CFG_NAME_LEN and CFG_VALUE_LEN to 64 and 256 respectively.
+* For debug builds, the functions rte_eth_rx_burst(), rte_eth_tx_burst()
+ rte_eth_rx_descriptor_done() and rte_eth_rx_queue_count() will
+ no longer be separate functions in the DPDK libraries. Instead, they will
+ only be present in the rte_ethdev.h header file.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index 3e81a0e..e810284 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -41,7 +41,7 @@ CFLAGS += $(WERROR_FLAGS)
EXPORT_MAP := rte_ether_version.map
-LIBABIVER := 2
+LIBABIVER := 3
SRCS-y += rte_ethdev.c
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index f82b3a9..3840775 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2451,70 +2451,6 @@ rte_eth_mirror_rule_reset(uint8_t port_id, uint8_t rule_id)
return (*dev->dev_ops->mirror_rule_reset)(dev, rule_id);
}
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
-uint16_t
-rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id,
- struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
-{
- struct rte_eth_dev *dev;
-
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
-
- dev = &rte_eth_devices[port_id];
- RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
- if (queue_id >= dev->data->nb_rx_queues) {
- RTE_PMD_DEBUG_TRACE("Invalid RX queue_id=%d\n", queue_id);
- return 0;
- }
- return (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
- rx_pkts, nb_pkts);
-}
-
-uint16_t
-rte_eth_tx_burst(uint8_t port_id, uint16_t queue_id,
- struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
-{
- struct rte_eth_dev *dev;
-
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
-
- dev = &rte_eth_devices[port_id];
-
- RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_pkt_burst, 0);
- if (queue_id >= dev->data->nb_tx_queues) {
- RTE_PMD_DEBUG_TRACE("Invalid TX queue_id=%d\n", queue_id);
- return 0;
- }
- return (*dev->tx_pkt_burst)(dev->data->tx_queues[queue_id],
- tx_pkts, nb_pkts);
-}
-
-uint32_t
-rte_eth_rx_queue_count(uint8_t port_id, uint16_t queue_id)
-{
- struct rte_eth_dev *dev;
-
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
-
- dev = &rte_eth_devices[port_id];
- RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_count, 0);
- return (*dev->dev_ops->rx_queue_count)(dev, queue_id);
-}
-
-int
-rte_eth_rx_descriptor_done(uint8_t port_id, uint16_t queue_id, uint16_t offset)
-{
- struct rte_eth_dev *dev;
-
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
-
- dev = &rte_eth_devices[port_id];
- RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_descriptor_done, -ENOTSUP);
- return (*dev->dev_ops->rx_descriptor_done)(dev->data->rx_queues[queue_id],
- offset);
-}
-#endif
-
int
rte_eth_dev_callback_register(uint8_t port_id,
enum rte_eth_event_type event,
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index b51b8aa..9fca6ba 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -2492,18 +2492,21 @@ extern int rte_eth_dev_set_vlan_pvid(uint8_t port_id, uint16_t pvid, int on);
* of pointers to *rte_mbuf* structures effectively supplied to the
* *rx_pkts* array.
*/
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
-extern uint16_t rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id,
- struct rte_mbuf **rx_pkts, uint16_t nb_pkts);
-#else
static inline uint16_t
rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id,
struct rte_mbuf **rx_pkts, const uint16_t nb_pkts)
{
- struct rte_eth_dev *dev;
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
- dev = &rte_eth_devices[port_id];
+#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
+ if (queue_id >= dev->data->nb_rx_queues) {
+ RTE_PMD_DEBUG_TRACE("Invalid RX queue_id=%d\n", queue_id);
+ return 0;
+ }
+#endif
int16_t nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
rx_pkts, nb_pkts);
@@ -2521,7 +2524,6 @@ rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id,
return nb_rx;
}
-#endif
/**
* Get the number of used descriptors in a specific queue
@@ -2533,18 +2535,16 @@ rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id,
* @return
* The number of used descriptors in the specific queue.
*/
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
-extern uint32_t rte_eth_rx_queue_count(uint8_t port_id, uint16_t queue_id);
-#else
static inline uint32_t
rte_eth_rx_queue_count(uint8_t port_id, uint16_t queue_id)
{
- struct rte_eth_dev *dev;
-
- dev = &rte_eth_devices[port_id];
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_count, 0);
+#endif
return (*dev->dev_ops->rx_queue_count)(dev, queue_id);
}
-#endif
/**
* Check if the DD bit of the specific RX descriptor in the queue has been set
@@ -2560,21 +2560,17 @@ rte_eth_rx_queue_count(uint8_t port_id, uint16_t queue_id)
* - (0) if the specific DD bit is not set.
* - (-ENODEV) if *port_id* invalid.
*/
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
-extern int rte_eth_rx_descriptor_done(uint8_t port_id,
- uint16_t queue_id,
- uint16_t offset);
-#else
static inline int
rte_eth_rx_descriptor_done(uint8_t port_id, uint16_t queue_id, uint16_t offset)
{
- struct rte_eth_dev *dev;
-
- dev = &rte_eth_devices[port_id];
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_descriptor_done, -ENOTSUP);
+#endif
return (*dev->dev_ops->rx_descriptor_done)( \
dev->data->rx_queues[queue_id], offset);
}
-#endif
/**
* Send a burst of output packets on a transmit queue of an Ethernet device.
@@ -2634,17 +2630,21 @@ rte_eth_rx_descriptor_done(uint8_t port_id, uint16_t queue_id, uint16_t offset)
* the transmit ring. The return value can be less than the value of the
* *tx_pkts* parameter when the transmit ring is full or has been filled up.
*/
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
-extern uint16_t rte_eth_tx_burst(uint8_t port_id, uint16_t queue_id,
- struct rte_mbuf **tx_pkts, uint16_t nb_pkts);
-#else
static inline uint16_t
rte_eth_tx_burst(uint8_t port_id, uint16_t queue_id,
struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
{
- struct rte_eth_dev *dev;
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+
+#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_pkt_burst, 0);
- dev = &rte_eth_devices[port_id];
+ if (queue_id >= dev->data->nb_tx_queues) {
+ RTE_PMD_DEBUG_TRACE("Invalid TX queue_id=%d\n", queue_id);
+ return 0;
+ }
+#endif
#ifdef RTE_ETHDEV_RXTX_CALLBACKS
struct rte_eth_rxtx_callback *cb = dev->pre_tx_burst_cbs[queue_id];
@@ -2660,7 +2660,6 @@ rte_eth_tx_burst(uint8_t port_id, uint16_t queue_id,
return (*dev->tx_pkt_burst)(dev->data->tx_queues[queue_id], tx_pkts, nb_pkts);
}
-#endif
/**
* The eth device event type for interrupt, and maybe others in the future.
diff --git a/lib/librte_ether/rte_ether_version.map b/lib/librte_ether/rte_ether_version.map
index 0c35d53..431fe9c 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -1,4 +1,4 @@
-DPDK_2.0 {
+DPDK_2.2 {
global:
_rte_eth_dev_callback_process;
@@ -7,6 +7,7 @@ DPDK_2.0 {
rte_eth_allmulticast_disable;
rte_eth_allmulticast_enable;
rte_eth_allmulticast_get;
+ rte_eth_copy_pci_info;
rte_eth_dev_allocate;
rte_eth_dev_allocated;
rte_eth_dev_attach;
@@ -24,6 +25,7 @@ DPDK_2.0 {
rte_eth_dev_close;
rte_eth_dev_configure;
rte_eth_dev_count;
+ rte_eth_dev_default_mac_addr_set;
rte_eth_dev_detach;
rte_eth_dev_fdir_add_perfect_filter;
rte_eth_dev_fdir_add_signature_filter;
@@ -37,9 +39,16 @@ DPDK_2.0 {
rte_eth_dev_filter_supported;
rte_eth_dev_flow_ctrl_get;
rte_eth_dev_flow_ctrl_set;
+ rte_eth_dev_get_dcb_info;
+ rte_eth_dev_get_eeprom;
+ rte_eth_dev_get_eeprom_length;
rte_eth_dev_get_mtu;
+ rte_eth_dev_get_reg_info;
+ rte_eth_dev_get_reg_length;
rte_eth_dev_get_vlan_offload;
+ rte_eth_devices;
rte_eth_dev_info_get;
+ rte_eth_dev_is_valid_port;
rte_eth_dev_mac_addr_add;
rte_eth_dev_mac_addr_remove;
rte_eth_dev_priority_flow_ctrl_set;
@@ -48,10 +57,16 @@ DPDK_2.0 {
rte_eth_dev_rss_hash_update;
rte_eth_dev_rss_reta_query;
rte_eth_dev_rss_reta_update;
+ rte_eth_dev_rx_intr_ctl;
+ rte_eth_dev_rx_intr_ctl_q;
+ rte_eth_dev_rx_intr_disable;
+ rte_eth_dev_rx_intr_enable;
rte_eth_dev_rx_queue_start;
rte_eth_dev_rx_queue_stop;
+ rte_eth_dev_set_eeprom;
rte_eth_dev_set_link_down;
rte_eth_dev_set_link_up;
+ rte_eth_dev_set_mc_addr_list;
rte_eth_dev_set_mtu;
rte_eth_dev_set_rx_queue_stats_mapping;
rte_eth_dev_set_tx_queue_stats_mapping;
@@ -74,7 +89,7 @@ DPDK_2.0 {
rte_eth_dev_udp_tunnel_delete;
rte_eth_dev_vlan_filter;
rte_eth_dev_wd_timeout_store;
- rte_eth_devices;
+ rte_eth_dma_zone_reserve;
rte_eth_driver_register;
rte_eth_led_off;
rte_eth_led_on;
@@ -89,55 +104,22 @@ DPDK_2.0 {
rte_eth_promiscuous_get;
rte_eth_remove_rx_callback;
rte_eth_remove_tx_callback;
- rte_eth_rx_burst;
- rte_eth_rx_descriptor_done;
- rte_eth_rx_queue_count;
+ rte_eth_rx_queue_info_get;
rte_eth_rx_queue_setup;
rte_eth_set_queue_rate_limit;
rte_eth_set_vf_rate_limit;
rte_eth_stats;
rte_eth_stats_get;
rte_eth_stats_reset;
- rte_eth_tx_burst;
- rte_eth_tx_queue_setup;
- rte_eth_xstats_get;
- rte_eth_xstats_reset;
-
- local: *;
-};
-
-DPDK_2.1 {
- global:
-
- rte_eth_dev_default_mac_addr_set;
- rte_eth_dev_get_eeprom;
- rte_eth_dev_get_eeprom_length;
- rte_eth_dev_get_reg_info;
- rte_eth_dev_get_reg_length;
- rte_eth_dev_is_valid_port;
- rte_eth_dev_rx_intr_ctl;
- rte_eth_dev_rx_intr_ctl_q;
- rte_eth_dev_rx_intr_disable;
- rte_eth_dev_rx_intr_enable;
- rte_eth_dev_set_eeprom;
- rte_eth_dev_set_mc_addr_list;
+ rte_eth_timesync_adjust_time;
rte_eth_timesync_disable;
rte_eth_timesync_enable;
rte_eth_timesync_read_rx_timestamp;
- rte_eth_timesync_read_tx_timestamp;
-
-} DPDK_2.0;
-
-DPDK_2.2 {
- global:
-
- rte_eth_copy_pci_info;
- rte_eth_dev_get_dcb_info;
- rte_eth_dma_zone_reserve;
- rte_eth_rx_queue_info_get;
- rte_eth_timesync_adjust_time;
rte_eth_timesync_read_time;
+ rte_eth_timesync_read_tx_timestamp;
rte_eth_timesync_write_time;
rte_eth_tx_queue_info_get;
-
-} DPDK_2.1;
+ rte_eth_tx_queue_setup;
+ rte_eth_xstats_get;
+ rte_eth_xstats_reset;
+};
--
2.5.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v5 2/2] ethdev: add sanity checks to functions
2015-11-24 17:37 3% ` [dpdk-dev] [PATCH v5 0/2] ethdev: debug code cleanup Bruce Richardson
2015-11-24 17:37 4% ` [dpdk-dev] [PATCH v5 1/2] ethdev: remove duplicated debug functions Bruce Richardson
@ 2015-11-24 17:37 4% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2015-11-24 17:37 UTC (permalink / raw)
To: dev
The functions rte_eth_rx_queue_count and rte_eth_descriptor_done are
supported by very few PMDs. Therefore, it is best to check for support
for the functions in the ethdev library, so as to avoid run-time crashes
at run-time if the application goes to use those APIs. Similarly, the
port parameter should also be checked for validity.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
doc/guides/rel_notes/release_2_2.rst | 2 ++
lib/librte_ether/rte_ethdev.h | 15 +++++++--------
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index d39bf75..5b2ac63 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -259,6 +259,8 @@ API Changes
* The devargs union field virtual is renamed to virt for C++ compatibility.
+* The rte_eth_rx_queue_count() ethdev API now returns "int" instead of "uint32_t"
+ to allow the use of negative values as error codes on return
ABI Changes
-----------
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 9fca6ba..1ff29e2 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -2533,16 +2533,16 @@ rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id,
* @param queue_id
* The queue id on the specific port.
* @return
- * The number of used descriptors in the specific queue.
+ * The number of used descriptors in the specific queue, or:
+ * (-EINVAL) if *port_id* is invalid
+ * (-ENOTSUP) if the device does not support this function
*/
-static inline uint32_t
+static inline int
rte_eth_rx_queue_count(uint8_t port_id, uint16_t queue_id)
{
struct rte_eth_dev *dev = &rte_eth_devices[port_id];
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
- RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_count, 0);
-#endif
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_count, -ENOTSUP);
return (*dev->dev_ops->rx_queue_count)(dev, queue_id);
}
@@ -2559,15 +2559,14 @@ rte_eth_rx_queue_count(uint8_t port_id, uint16_t queue_id)
* - (1) if the specific DD bit is set.
* - (0) if the specific DD bit is not set.
* - (-ENODEV) if *port_id* invalid.
+ * - (-ENOTSUP) if the device does not support this function
*/
static inline int
rte_eth_rx_descriptor_done(uint8_t port_id, uint16_t queue_id, uint16_t offset)
{
struct rte_eth_dev *dev = &rte_eth_devices[port_id];
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_descriptor_done, -ENOTSUP);
-#endif
return (*dev->dev_ops->rx_descriptor_done)( \
dev->data->rx_queues[queue_id], offset);
}
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 00/10] rte_sched: enhancements and cleanups
2015-11-13 17:58 3% [dpdk-dev] [PATCH v2 " Stephen Hemminger
2015-11-13 17:58 3% ` [dpdk-dev] [PATCH v2 10/10] sched: allow more subports Stephen Hemminger
@ 2015-11-24 23:34 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-11-24 23:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
2015-11-13 09:58, Stephen Hemminger:
> Hierarchal scheduler changes (resend)
>
> Most of these are cleanups for existing code to make it more compatiable
> with coding style, and eliminate #ifdefs.
>
> The only substantive change is to allow more subports per scheduler
> instance. This was submitted for DPDK 2.1 but since it required some
> ABI finesse to change; the real part of this was held off for 2.2.
>
> Stephen Hemminger (10):
> qos: drop deprecated port hierarchy structure
> qos: cleanup comments
> qos: make debugging configurable
> qos: drop debug #ifdef's for credit check
> qos: remove debug conditional code around ENQUEUE
> qos: drop RTE_SCHED_WRR #define
> qos: cleanup defined constants
> qos: allow enabling SSE optimizations in config
> sched: fix coding style
> sched: allow more subports
Applied with deprecation notice removed, thanks.
What about this change announced as deprecation notice?
+* The scheduler statistics structure will change to allow keeping track of
+ RED actions.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] Can't compile DPDK if both CONFIG_RTE_BUILD_COMBINE_LIBS and LIBRTE_PMD_XENVIRT are set to "yes"
@ 2015-11-25 0:26 4% ` Martinx - ジェームズ
2015-11-25 8:44 4% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Martinx - ジェームズ @ 2015-11-25 0:26 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
On 24 November 2015 at 13:53, Panu Matilainen <pmatilai@redhat.com> wrote:
> On 11/24/2015 05:30 PM, Martinx - ジェームズ wrote:
>>
>> On 24 November 2015 at 13:22, Panu Matilainen <pmatilai@redhat.com> wrote:
>>>
>>> On 11/24/2015 04:46 PM, Sergio Gonzalez Monroy wrote:
>>>>
>>>>
>>>> On 24/11/2015 13:57, Panu Matilainen wrote:
>>>>>
>>>>>
>>>>> On 11/23/2015 08:37 PM, Martinx - ジェームズ wrote:
>>>>>>
>>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> My name is Thiago, I'm trying to compile DPDK 2.0, 2.1 and/or 2.2-rc1,
>>>>>> on Ubuntu with Xen support but, it does not build...
>>>>>>
>>>>>> Also, initially, I'm using DPDK sources from Ubuntu APT repository
>>>>>> but, it is also reproducible using upstream DPDK tarball as well,
>>>>>> explained as follows:
>>>>>>
>>>>>> Problem:
>>>>>>
>>>>>> * It is not possible to use the following DPDK options at the same
>>>>>> time:
>>>>>>
>>>>>> CONFIG_RTE_BUILD_COMBINE_LIBS
>>>>>> LIBRTE_PMD_XENVIRT
>>>>>>
>>>>>> Ubuntu DPDK .deb package uses CONFIG_RTE_BUILD_COMBINE_LIBS and,
>>>>>> without it, it can't build its .deb binary package (step: "make -f
>>>>>> debian/rules binary" doesn't work).
>>>>>>
>>>>>> So, if you have the above two options set to "yes", the following
>>>>>> error appear while building DPDK:
>>>>>>
>>>>>> http://pastebin.com/xUsQPxh8
>>>>>>
>>>>> [...]
>>>>>>
>>>>>>
>>>>>> Build error:
>>>>>>
>>>>>> http://pastebin.com/fuUkpF4w
>>>>>>
>>>>>> If you remove "CONFIG_RTE_BUILD_COMBINE_LIBS", then, you can build it
>>>>>> with "LIBRTE_PMD_XENVIRT", and vice-versa. But, without
>>>>>> "...COMBINE_LIBS", Ubuntu .deb package doesn't get builded.
>>>>>>
>>>>>> BTW, the option LIBRTE_XEN_DOM0 is fine when also enabling
>>>>>> COMBINE_LIBS...
>>>>>>
>>>>>> Am I missing something? Is this by design or a DPDK bug?
>>>>>
>>>>>
>>>>>
>>>>> DPDK bug I would say. The combined library has been increasingly in
>>>>> risk of collapsing under its own weight for some time now.
>>>>>
>>>>> A much better way of achieving the same is using a so called linker
>>>>> script which is essentially just an ascii file listing all the
>>>>> individual libraries which the linker handles behind the scenes.
>>>>> FWIW, that's how the combined library is packaged on Fedora and RHEL
>>>>> and consumers like OVS and pktgen never knew the difference.
>>>>>
>>>>> The linker script approach has been suggested before but somehow the
>>>>> threads died without nothing actually happening. I'll revive the patch
>>>>> and post here shortly. Unless Sergio (cc'd) who previously worked on
>>>>> the patches has a newer version cooking silently?
>>>>>
>>>> I haven't worked on it since, so you probably are in a better position
>>>> to continue the work than me.
>>>
>>>
>>>
>>> Ok, I suspected as much but thanks for confirming. I'll continue the work
>>> as
>>> time permits.
>>>
>>> - Panu -
>>>
>>
>> Cool! Thank you guys for this fast reply...
>>
>> Just a curiosity, do you guys think that this will be ready for 2.2?
>> Or maybe just for 2.3?
>>
>> I'm hoping to use this for next Ubuntu release, Xenial on 2016, April
>> (Ubuntu 16.04 LTS).
>>
>> So, I think that there is time, if not too much trouble for you guys
>> (honestly, I don't know how hard is to fix that)... :-)
>
>
> Feel free to try this out: http://dpdk.org/dev/patchwork/patch/9088/
>
> Whether it lands in time for 2.2 I dont know. However there's absolutely no
> need to be held hostage by that patch, you can just disable the combined
> library build option and drop a linker script in its place, created by hand
> or with couple of lines of shell script, eg:
> http://pkgs.fedoraproject.org/cgit/dpdk.git/tree/dpdk.spec#n234
>
> - Panu -
>
Helo Panu,
This is getting interesting... Your patch worked (on top of
dpdk-2.2.0-rc1) but, now, it broke Ubuntu / Debian packaging, because
your patch adds a new file called "mk/rte.combinedlib.mk" but it also,
removes the file "mk/rte.sharelib.mk", which Ubuntu is using to enable
"LIB ABI Version" on DPDK.
I'm talking about the following Ubuntu Patch (very simple and small):
---
tmartins@xenial-1:~/dpdk/ubuntu/dpdk-2.0.0$ cat
debian/patches/ubuntu-combined-shared-lib-abiversion.patch
http://pastebin.com/VhpMF5U1
---
So, with your patch, I can now compile DPDK while using both options
(_COMBINE_LIBS and _XENVIRT) at the same time but, unfortunately,
Ubuntu packaging is now broken...
Yes, I know that you guys have nothing to do with that but, I think
that it would be GREAT if DPDK comes with "Lib ABI Version" by
default...
So, is it possible to, somehow, include "LIBABIVER" on your new
"mk/rte.combinedlib.mk" file?
Then, Ubuntu / Debian will not need to patch DPDK anymore, during
build/packaging process...
I really don't mind if DPDK team (or you Panu) just ignore this
request, I know you guys are very busy, no problem... =)
Nevertheless, I'll also try your suggestion, to use something like this:
http://pkgs.fedoraproject.org/cgit/dpdk.git/tree/dpdk.spec#n234
...to see if it behaves differently, and of course, to see if it
builds the Debian package in the end of the day.
Thanks again!
Thiago
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] Can't compile DPDK if both CONFIG_RTE_BUILD_COMBINE_LIBS and LIBRTE_PMD_XENVIRT are set to "yes"
2015-11-25 0:26 4% ` Martinx - ジェームズ
@ 2015-11-25 8:44 4% ` Panu Matilainen
0 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2015-11-25 8:44 UTC (permalink / raw)
To: Martinx - ジェームズ; +Cc: dev
On 11/25/2015 02:26 AM, Martinx - ジェームズ wrote:
> On 24 November 2015 at 13:53, Panu Matilainen <pmatilai@redhat.com> wrote:
>> On 11/24/2015 05:30 PM, Martinx - ジェームズ wrote:
>>>
>>> On 24 November 2015 at 13:22, Panu Matilainen <pmatilai@redhat.com> wrote:
>>>>
>>>> On 11/24/2015 04:46 PM, Sergio Gonzalez Monroy wrote:
>>>>>
>>>>>
>>>>> On 24/11/2015 13:57, Panu Matilainen wrote:
>>>>>>
>>>>>>
>>>>>> On 11/23/2015 08:37 PM, Martinx - ジェームズ wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hello!
>>>>>>>
>>>>>>> My name is Thiago, I'm trying to compile DPDK 2.0, 2.1 and/or 2.2-rc1,
>>>>>>> on Ubuntu with Xen support but, it does not build...
>>>>>>>
>>>>>>> Also, initially, I'm using DPDK sources from Ubuntu APT repository
>>>>>>> but, it is also reproducible using upstream DPDK tarball as well,
>>>>>>> explained as follows:
>>>>>>>
>>>>>>> Problem:
>>>>>>>
>>>>>>> * It is not possible to use the following DPDK options at the same
>>>>>>> time:
>>>>>>>
>>>>>>> CONFIG_RTE_BUILD_COMBINE_LIBS
>>>>>>> LIBRTE_PMD_XENVIRT
>>>>>>>
>>>>>>> Ubuntu DPDK .deb package uses CONFIG_RTE_BUILD_COMBINE_LIBS and,
>>>>>>> without it, it can't build its .deb binary package (step: "make -f
>>>>>>> debian/rules binary" doesn't work).
>>>>>>>
>>>>>>> So, if you have the above two options set to "yes", the following
>>>>>>> error appear while building DPDK:
>>>>>>>
>>>>>>> http://pastebin.com/xUsQPxh8
>>>>>>>
>>>>>> [...]
>>>>>>>
>>>>>>>
>>>>>>> Build error:
>>>>>>>
>>>>>>> http://pastebin.com/fuUkpF4w
>>>>>>>
>>>>>>> If you remove "CONFIG_RTE_BUILD_COMBINE_LIBS", then, you can build it
>>>>>>> with "LIBRTE_PMD_XENVIRT", and vice-versa. But, without
>>>>>>> "...COMBINE_LIBS", Ubuntu .deb package doesn't get builded.
>>>>>>>
>>>>>>> BTW, the option LIBRTE_XEN_DOM0 is fine when also enabling
>>>>>>> COMBINE_LIBS...
>>>>>>>
>>>>>>> Am I missing something? Is this by design or a DPDK bug?
>>>>>>
>>>>>>
>>>>>>
>>>>>> DPDK bug I would say. The combined library has been increasingly in
>>>>>> risk of collapsing under its own weight for some time now.
>>>>>>
>>>>>> A much better way of achieving the same is using a so called linker
>>>>>> script which is essentially just an ascii file listing all the
>>>>>> individual libraries which the linker handles behind the scenes.
>>>>>> FWIW, that's how the combined library is packaged on Fedora and RHEL
>>>>>> and consumers like OVS and pktgen never knew the difference.
>>>>>>
>>>>>> The linker script approach has been suggested before but somehow the
>>>>>> threads died without nothing actually happening. I'll revive the patch
>>>>>> and post here shortly. Unless Sergio (cc'd) who previously worked on
>>>>>> the patches has a newer version cooking silently?
>>>>>>
>>>>> I haven't worked on it since, so you probably are in a better position
>>>>> to continue the work than me.
>>>>
>>>>
>>>>
>>>> Ok, I suspected as much but thanks for confirming. I'll continue the work
>>>> as
>>>> time permits.
>>>>
>>>> - Panu -
>>>>
>>>
>>> Cool! Thank you guys for this fast reply...
>>>
>>> Just a curiosity, do you guys think that this will be ready for 2.2?
>>> Or maybe just for 2.3?
>>>
>>> I'm hoping to use this for next Ubuntu release, Xenial on 2016, April
>>> (Ubuntu 16.04 LTS).
>>>
>>> So, I think that there is time, if not too much trouble for you guys
>>> (honestly, I don't know how hard is to fix that)... :-)
>>
>>
>> Feel free to try this out: http://dpdk.org/dev/patchwork/patch/9088/
>>
>> Whether it lands in time for 2.2 I dont know. However there's absolutely no
>> need to be held hostage by that patch, you can just disable the combined
>> library build option and drop a linker script in its place, created by hand
>> or with couple of lines of shell script, eg:
>> http://pkgs.fedoraproject.org/cgit/dpdk.git/tree/dpdk.spec#n234
>>
>> - Panu -
>>
>
> Helo Panu,
>
> This is getting interesting... Your patch worked (on top of
> dpdk-2.2.0-rc1) but, now, it broke Ubuntu / Debian packaging, because
> your patch adds a new file called "mk/rte.combinedlib.mk" but it also,
> removes the file "mk/rte.sharelib.mk", which Ubuntu is using to enable
> "LIB ABI Version" on DPDK.
>
> I'm talking about the following Ubuntu Patch (very simple and small):
>
> ---
> tmartins@xenial-1:~/dpdk/ubuntu/dpdk-2.0.0$ cat
> debian/patches/ubuntu-combined-shared-lib-abiversion.patch
>
> http://pastebin.com/VhpMF5U1
> ---
>
> So, with your patch, I can now compile DPDK while using both options
> (_COMBINE_LIBS and _XENVIRT) at the same time but, unfortunately,
> Ubuntu packaging is now broken...
>
> Yes, I know that you guys have nothing to do with that but, I think
> that it would be GREAT if DPDK comes with "Lib ABI Version" by
> default...
>
> So, is it possible to, somehow, include "LIBABIVER" on your new
> "mk/rte.combinedlib.mk" file?
>
> Then, Ubuntu / Debian will not need to patch DPDK anymore, during
> build/packaging process...
The linker script has no ABI version because its not a run-time library,
its only used during building. The ABI versions are carried by the
individual libraries themselves.
- Panu -
> I really don't mind if DPDK team (or you Panu) just ignore this
> request, I know you guys are very busy, no problem... =)
>
> Nevertheless, I'll also try your suggestion, to use something like this:
>
> http://pkgs.fedoraproject.org/cgit/dpdk.git/tree/dpdk.spec#n234
>
> ...to see if it behaves differently, and of course, to see if it
> builds the Debian package in the end of the day.
>
> Thanks again!
> Thiago
>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] cryptodev: mark experimental state
@ 2015-11-25 17:38 5% Thomas Monjalon
2015-11-26 7:39 3% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-25 17:38 UTC (permalink / raw)
To: declan.doherty; +Cc: dev
The crypto API is in an early state.
It requires more discussions and experiments to declare it stable,
as discussed in http://dpdk.org/ml/archives/dev/2015-November/028634.html
A documentation section will be required in the guides.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
MAINTAINERS | 2 +-
config/common_bsdapp | 1 +
config/common_linuxapp | 1 +
doc/guides/contributing/versioning.rst | 1 +
doc/guides/rel_notes/release_2_2.rst | 10 ++++++++++
lib/librte_cryptodev/rte_cryptodev.h | 3 +++
6 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7f3d967..460245b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -219,7 +219,7 @@ M: Thomas Monjalon <thomas.monjalon@6wind.com>
F: lib/librte_ether/
F: scripts/test-null.sh
-Crypto API
+Crypto API - EXPERIMENTAL
M: Declan Doherty <declan.doherty@intel.com>
F: lib/librte_cryptodev/
F: app/test/test_cryptodev*
diff --git a/config/common_bsdapp b/config/common_bsdapp
index 56020b6..3286481 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -310,6 +310,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
#
# Compile generic crypto device library
+# EXPERIMENTAL: API may change without prior notice
#
CONFIG_RTE_LIBRTE_CRYPTODEV=y
CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index eaad8d6..2866986 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -319,6 +319,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
#
# Compile generic crypto device library
+# EXPERIMENTAL: API may change without prior notice
#
CONFIG_RTE_LIBRTE_CRYPTODEV=y
CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 8a739dd..653c7d0 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -13,6 +13,7 @@ General Guidelines
------------------
#. Whenever possible, ABI should be preserved
+#. The libraries marked in experimental state may change without constraint.
#. The addition of symbols is generally not problematic
#. The modification of symbols can generally be managed with versioning
#. The removal of symbols generally is an ABI break and requires bumping of the
diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst
index 8c77768..d0a9955 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -17,6 +17,16 @@ New Features
* **Added keepalive support to EAL and example application.**
+* **Added experimental cryptodev API**
+
+ The cryptographic processing of packet is provided as a preview
+ with two drivers for:
+
+ * Intel QuickAssist devices
+ * Intel AES-NI multi-buffer library
+
+ Due to its experimental state, the API may change without prior notice.
+
* **Added ethdev API to support IEEE1588.**
Added functions to read, write and adjust system time in the NIC.
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 04bade7..aa9f785 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -39,6 +39,9 @@
*
* Defines RTE Crypto Device APIs for the provisioning of cipher and
* authentication operations.
+ *
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
*/
#ifdef __cplusplus
--
2.5.2
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v8 1/9] nfp: basic initialization
@ 2015-11-25 18:47 3% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-11-25 18:47 UTC (permalink / raw)
To: Alejandro.Lucero; +Cc: dev
2015-11-25 16:19, Alejandro.Lucero:
> config/common_linuxapp | 6 +
> doc/guides/rel_notes/release_2_2.rst | 4 +
> drivers/net/Makefile | 1 +
> drivers/net/nfp/Makefile | 54 +++
> drivers/net/nfp/nfp_net.c | 699 ++++++++++++++++++++++++++++++++++
> drivers/net/nfp/nfp_net_ctrl.h | 324 ++++++++++++++++
> drivers/net/nfp/nfp_net_logs.h | 75 ++++
> drivers/net/nfp/nfp_net_pmd.h | 453 ++++++++++++++++++++++
> mk/rte.app.mk | 1 +
It does not compile as a shared library:
Must Specify a librte_pmd_nfp.so..1 ABI version
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 0/7] librte_table: add key_mask parameter to
@ 2015-11-25 22:33 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-11-25 22:33 UTC (permalink / raw)
To: roy.fan.zhang; +Cc: dev
2015-10-28 17:11, roy.fan.zhang@intel.com:
> From: Fan Zhang <roy.fan.zhang@intel.com>
>
> This patchset links to ABI change announced for librte_table.
> The key_mask parameters has been added to the hash table
> parameter structure for 8-byte key and 16-byte key extendible
> bucket and LRU tables.
>
> v2:
> *updated release note
>
> v3:
> *merged release note with source code patch
> *fixed build error: added missing symbol to
> librte_table/rte_table_version.map
>
> v4:
> *modified rte_prefetch offsets to improve hash/lru table
> lookup performance.
>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Please put this line in each commit.
> Fan Zhang (7):
> librte_table: add key_mask parameter to 8- and 16-bytes key hash
> parameters
> librte_table: add 16 byte hash table operations with computed lookup
> app/test: modify app/test_table_combined and app/test_table_tables
> app/test-pipeline: modify pipeline test
> example/ip_pipeline: add parse_hex_string for internal use
> example/ip_pipeline/pipeline: update flow_classification pipeline
> librte_table: performance improvement on rte_prefetch offset
Applied, thanks
^ permalink raw reply [relevance 0%]
* [dpdk-dev] ABI changes in release notes
@ 2015-11-25 23:41 7% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-11-25 23:41 UTC (permalink / raw)
To: dev
Hi all,
I've just noticed that some ABI changes were announced and done but
the corresponding entries in the release notes have not been added.
Please check.
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
2015-11-25 17:38 5% [dpdk-dev] [PATCH] cryptodev: mark experimental state Thomas Monjalon
@ 2015-11-26 7:39 3% ` Panu Matilainen
2015-11-26 8:00 0% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-11-26 7:39 UTC (permalink / raw)
To: Thomas Monjalon, declan.doherty; +Cc: dev
On 11/25/2015 07:38 PM, Thomas Monjalon wrote:
> The crypto API is in an early state.
> It requires more discussions and experiments to declare it stable,
> as discussed in http://dpdk.org/ml/archives/dev/2015-November/028634.html
>
> A documentation section will be required in the guides.
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> ---
[...]
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -310,6 +310,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
>
> #
> # Compile generic crypto device library
> +# EXPERIMENTAL: API may change without prior notice
> #
> CONFIG_RTE_LIBRTE_CRYPTODEV=y
> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index eaad8d6..2866986 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -319,6 +319,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
>
> #
> # Compile generic crypto device library
> +# EXPERIMENTAL: API may change without prior notice
> #
> CONFIG_RTE_LIBRTE_CRYPTODEV=y
> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
[...]
I think an experimental library which declares itself exempt from the
ABI policy should not be compiled by default. That way anybody wanting
to try it out will be forced to notice the experimental status.
More generally / longer term, perhaps there should be a
CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and
defaults to off.
- Panu -
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
2015-11-26 7:39 3% ` Panu Matilainen
@ 2015-11-26 8:00 0% ` Panu Matilainen
2015-11-26 10:08 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-11-26 8:00 UTC (permalink / raw)
To: Thomas Monjalon, declan.doherty; +Cc: dev
On 11/26/2015 09:39 AM, Panu Matilainen wrote:
> On 11/25/2015 07:38 PM, Thomas Monjalon wrote:
>> The crypto API is in an early state.
>> It requires more discussions and experiments to declare it stable,
>> as discussed in http://dpdk.org/ml/archives/dev/2015-November/028634.html
>>
>> A documentation section will be required in the guides.
>>
>> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
>> ---
> [...]
>> --- a/config/common_bsdapp
>> +++ b/config/common_bsdapp
>> @@ -310,6 +310,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
>>
>> #
>> # Compile generic crypto device library
>> +# EXPERIMENTAL: API may change without prior notice
>> #
>> CONFIG_RTE_LIBRTE_CRYPTODEV=y
>> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
>> diff --git a/config/common_linuxapp b/config/common_linuxapp
>> index eaad8d6..2866986 100644
>> --- a/config/common_linuxapp
>> +++ b/config/common_linuxapp
>> @@ -319,6 +319,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
>>
>> #
>> # Compile generic crypto device library
>> +# EXPERIMENTAL: API may change without prior notice
>> #
>> CONFIG_RTE_LIBRTE_CRYPTODEV=y
>> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
> [...]
>
> I think an experimental library which declares itself exempt from the
> ABI policy should not be compiled by default. That way anybody wanting
> to try it out will be forced to notice the experimental status.
>
> More generally / longer term, perhaps there should be a
> CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and
> defaults to off.
On a related note, librte_mbuf_offload cannot be built if
CONFIG_RTE_LIBRTE_CRYPTODEV is disabled. Which seems to suggest its (at
least currently) so tightly couple to cryptodev that perhaps it too
should be marked experimental and default to off.
- Panu -
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
2015-11-26 8:00 0% ` Panu Matilainen
@ 2015-11-26 10:08 0% ` Thomas Monjalon
2015-11-26 13:51 0% ` Doherty, Declan
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-26 10:08 UTC (permalink / raw)
To: Panu Matilainen, declan.doherty; +Cc: dev
2015-11-26 10:00, Panu Matilainen:
> On 11/26/2015 09:39 AM, Panu Matilainen wrote:
> > On 11/25/2015 07:38 PM, Thomas Monjalon wrote:
> >> --- a/config/common_linuxapp
> >> +++ b/config/common_linuxapp
> >> @@ -319,6 +319,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
> >>
> >> #
> >> # Compile generic crypto device library
> >> +# EXPERIMENTAL: API may change without prior notice
> >> #
> >> CONFIG_RTE_LIBRTE_CRYPTODEV=y
> >> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
> > [...]
> >
> > I think an experimental library which declares itself exempt from the
> > ABI policy should not be compiled by default. That way anybody wanting
> > to try it out will be forced to notice the experimental status.
> >
> > More generally / longer term, perhaps there should be a
> > CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and
> > defaults to off.
>
> On a related note, librte_mbuf_offload cannot be built if
> CONFIG_RTE_LIBRTE_CRYPTODEV is disabled. Which seems to suggest its (at
> least currently) so tightly couple to cryptodev that perhaps it too
> should be marked experimental and default to off.
I think you are right.
Declan, what is your opinion?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
2015-11-26 10:08 0% ` Thomas Monjalon
@ 2015-11-26 13:51 0% ` Doherty, Declan
2015-11-27 13:09 0% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Doherty, Declan @ 2015-11-26 13:51 UTC (permalink / raw)
To: Thomas Monjalon, Panu Matilainen; +Cc: dev
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, November 26, 2015 10:09 AM
> To: Panu Matilainen; Doherty, Declan
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
>
> 2015-11-26 10:00, Panu Matilainen:
> > On 11/26/2015 09:39 AM, Panu Matilainen wrote:
> > > On 11/25/2015 07:38 PM, Thomas Monjalon wrote:
> > >> --- a/config/common_linuxapp
> > >> +++ b/config/common_linuxapp
> > >> @@ -319,6 +319,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
> > >>
> > >> #
> > >> # Compile generic crypto device library
> > >> +# EXPERIMENTAL: API may change without prior notice
> > >> #
> > >> CONFIG_RTE_LIBRTE_CRYPTODEV=y
> > >> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
> > > [...]
> > >
> > > I think an experimental library which declares itself exempt from the
> > > ABI policy should not be compiled by default. That way anybody wanting
> > > to try it out will be forced to notice the experimental status.
> > >
> > > More generally / longer term, perhaps there should be a
> > > CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and
> > > defaults to off.
> >
> > On a related note, librte_mbuf_offload cannot be built if
> > CONFIG_RTE_LIBRTE_CRYPTODEV is disabled. Which seems to suggest its (at
> > least currently) so tightly couple to cryptodev that perhaps it too
> > should be marked experimental and default to off.
>
> I think you are right.
> Declan, what is your opinion?
Hey Thomas, yes librte_mbuf_offload should also be set as experimental, it's
probably one of the areas which will most likely change in the future.
On the issue of turning off experimental libraries in the build by default, my
preference would be not to turn them off unless the library has external
dependencies, otherwise the possibility of patches being submitted which
could break an experimental library will be much higher. In my opinion the
fewer build configurations developers have to test against the better.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
2015-11-26 13:51 0% ` Doherty, Declan
@ 2015-11-27 13:09 0% ` Panu Matilainen
2015-11-27 13:30 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-11-27 13:09 UTC (permalink / raw)
To: Doherty, Declan, Thomas Monjalon; +Cc: dev
On 11/26/2015 03:51 PM, Doherty, Declan wrote:
>> -----Original Message-----
>> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
>> Sent: Thursday, November 26, 2015 10:09 AM
>> To: Panu Matilainen; Doherty, Declan
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
>>
>> 2015-11-26 10:00, Panu Matilainen:
>>> On 11/26/2015 09:39 AM, Panu Matilainen wrote:
>>>> On 11/25/2015 07:38 PM, Thomas Monjalon wrote:
>>>>> --- a/config/common_linuxapp
>>>>> +++ b/config/common_linuxapp
>>>>> @@ -319,6 +319,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
>>>>>
>>>>> #
>>>>> # Compile generic crypto device library
>>>>> +# EXPERIMENTAL: API may change without prior notice
>>>>> #
>>>>> CONFIG_RTE_LIBRTE_CRYPTODEV=y
>>>>> CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
>>>> [...]
>>>>
>>>> I think an experimental library which declares itself exempt from the
>>>> ABI policy should not be compiled by default. That way anybody wanting
>>>> to try it out will be forced to notice the experimental status.
>>>>
>>>> More generally / longer term, perhaps there should be a
>>>> CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and
>>>> defaults to off.
>>>
>>> On a related note, librte_mbuf_offload cannot be built if
>>> CONFIG_RTE_LIBRTE_CRYPTODEV is disabled. Which seems to suggest its (at
>>> least currently) so tightly couple to cryptodev that perhaps it too
>>> should be marked experimental and default to off.
>>
>> I think you are right.
>> Declan, what is your opinion?
>
>
> Hey Thomas, yes librte_mbuf_offload should also be set as experimental, it's
> probably one of the areas which will most likely change in the future.
>
> On the issue of turning off experimental libraries in the build by default, my
> preference would be not to turn them off unless the library has external
> dependencies, otherwise the possibility of patches being submitted which
> could break an experimental library will be much higher. In my opinion the
> fewer build configurations developers have to test against the better.
What I'm more worried about is users and developers starting to rely on
it while still in experimental state, a single comment in the header is
really easy to miss.
So I'd like to see *some* mechanism which forces users and developers to
acknowledge the fact that they're dealing with experimental work.
Defaulting to off is one possibility, another one would be wrapping
experimental APIs behind a define which you have to set to be able to
use the API, eg:
#if defined(I_KNOW_THIS_IS_EXPERIMENTAL_AND_MAY_EAT_BABIES)
[...]
#endif
- Panu -
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
2015-11-27 13:09 0% ` Panu Matilainen
@ 2015-11-27 13:30 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-11-27 13:30 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
2015-11-27 15:09, Panu Matilainen:
> On 11/26/2015 03:51 PM, Doherty, Declan wrote:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> >> 2015-11-26 10:00, Panu Matilainen:
> >>> On 11/26/2015 09:39 AM, Panu Matilainen wrote:
> >>>> I think an experimental library which declares itself exempt from the
> >>>> ABI policy should not be compiled by default. That way anybody wanting
> >>>> to try it out will be forced to notice the experimental status.
> >>>>
> >>>> More generally / longer term, perhaps there should be a
> >>>> CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and
> >>>> defaults to off.
> >>>
> >>> On a related note, librte_mbuf_offload cannot be built if
> >>> CONFIG_RTE_LIBRTE_CRYPTODEV is disabled. Which seems to suggest its (at
> >>> least currently) so tightly couple to cryptodev that perhaps it too
> >>> should be marked experimental and default to off.
> >>
> >> I think you are right.
> >> Declan, what is your opinion?
> >
> >
> > Hey Thomas, yes librte_mbuf_offload should also be set as experimental, it's
> > probably one of the areas which will most likely change in the future.
> >
> > On the issue of turning off experimental libraries in the build by default, my
> > preference would be not to turn them off unless the library has external
> > dependencies, otherwise the possibility of patches being submitted which
> > could break an experimental library will be much higher. In my opinion the
> > fewer build configurations developers have to test against the better.
>
> What I'm more worried about is users and developers starting to rely on
> it while still in experimental state, a single comment in the header is
> really easy to miss.
There are some comments in the config, the header file, doxygen and the release notes.
When using a feature, you have to read the header or the doc.
So would it be better advertised by adding a comment in the doxygen section of
some of the mandatory functions or structures?
> So I'd like to see *some* mechanism which forces users and developers to
> acknowledge the fact that they're dealing with experimental work.
> Defaulting to off is one possibility, another one would be wrapping
> experimental APIs behind a define which you have to set to be able to
> use the API, eg:
>
> #if defined(I_KNOW_THIS_IS_EXPERIMENTAL_AND_MAY_EAT_BABIES)
> [...]
> #endif
Are you sure about the babies? ;)
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH 3/3] rte_sched: eliminate floating point in calculating byte clock
@ 2015-11-29 18:46 3% ` Stephen Hemminger
2015-12-02 16:48 0% ` Dumitrescu, Cristian
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2015-11-29 18:46 UTC (permalink / raw)
To: cristian.dumitrescu; +Cc: dev
The old code was doing a floating point divide for each rte_dequeue()
which is very expensive. Change to using fixed point scaled inverse
multiply. To maintain equivalent precision, scaled math is used.
The application ABI is the same.
This improved performance from 5Gbit/sec to 10 Gbit/sec when configured
for 10 Gbit/sec rate.
There was some feedback from Cristian that he wanted a better
solution and was going to give one, but none was provided.
For 2.2 this is a better solution than existing code, if someone
has a better version I would love to see it.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_sched/rte_sched.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 16acd6b..cfae136 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -47,6 +47,7 @@
#include "rte_bitmap.h"
#include "rte_sched_common.h"
#include "rte_approx.h"
+#include "rte_reciprocal.h"
#ifdef __INTEL_COMPILER
#pragma warning(disable:2259) /* conversion may lose significant bits */
@@ -62,6 +63,11 @@
#define RTE_SCHED_PIPE_INVALID UINT32_MAX
#define RTE_SCHED_BMP_POS_INVALID UINT32_MAX
+/* Scaling for cycles_per_byte calculation
+ * Chosen so that minimum rate is 480 bit/sec
+ */
+#define RTE_SCHED_TIME_SHIFT 8
+
struct rte_sched_subport {
/* Token bucket (TB) */
uint64_t tb_time; /* time of last update */
@@ -215,7 +221,7 @@ struct rte_sched_port {
uint64_t time_cpu_cycles; /* Current CPU time measured in CPU cyles */
uint64_t time_cpu_bytes; /* Current CPU time measured in bytes */
uint64_t time; /* Current NIC TX time measured in bytes */
- double cycles_per_byte; /* CPU cycles per byte */
+ struct rte_reciprocal inv_cycles_per_byte; /* CPU cycles per byte */
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -610,7 +616,7 @@ struct rte_sched_port *
rte_sched_port_config(struct rte_sched_port_params *params)
{
struct rte_sched_port *port = NULL;
- uint32_t mem_size, bmp_mem_size, n_queues_per_port, i;
+ uint32_t mem_size, bmp_mem_size, n_queues_per_port, i, cycles_per_byte;
/* Check user parameters. Determine the amount of memory to allocate */
mem_size = rte_sched_port_get_memory_footprint(params);
@@ -661,7 +667,10 @@ rte_sched_port_config(struct rte_sched_port_params *params)
port->time_cpu_cycles = rte_get_tsc_cycles();
port->time_cpu_bytes = 0;
port->time = 0;
- port->cycles_per_byte = ((double) rte_get_tsc_hz()) / ((double) params->rate);
+
+ cycles_per_byte = (rte_get_tsc_hz() << RTE_SCHED_TIME_SHIFT)
+ / params->rate;
+ port->inv_cycles_per_byte = rte_reciprocal_value(cycles_per_byte);
/* Scheduling loop detection */
port->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -2088,11 +2097,15 @@ rte_sched_port_time_resync(struct rte_sched_port *port)
{
uint64_t cycles = rte_get_tsc_cycles();
uint64_t cycles_diff = cycles - port->time_cpu_cycles;
- double bytes_diff = ((double) cycles_diff) / port->cycles_per_byte;
+ uint64_t bytes_diff;
+
+ /* Compute elapsed time in bytes */
+ bytes_diff = rte_reciprocal_divide(cycles_diff << RTE_SCHED_TIME_SHIFT,
+ port->inv_cycles_per_byte);
/* Advance port time */
port->time_cpu_cycles = cycles;
- port->time_cpu_bytes += (uint64_t) bytes_diff;
+ port->time_cpu_bytes += bytes_diff;
if (port->time < port->time_cpu_bytes)
port->time = port->time_cpu_bytes;
--
2.1.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] Query on Filtering Support in DPDK
@ 2015-11-30 13:43 3% ` Thomas Monjalon
2015-12-02 8:05 3% ` Rahul Lakkireddy
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-11-30 13:43 UTC (permalink / raw)
To: Rahul Lakkireddy; +Cc: dev, Felix Marti, Nirranjan Kirubaharan, Kumar Sanghvi
Hi,
2015-11-30 18:19, Rahul Lakkireddy:
> 1. Add a new action 'switch' that will:
> * Allow re-direction to different ports in hardware.
>
> Also, for such a rule, additionally support below:
>
> * Allow source mac/destination mac and vlan header re-writing to be
> done by the hardware.
>
> * Allow re-write of TCP/IP headers to perform NAT in hardware.
>
> 2. Add ability to mask individual fields at a particular layer for each
> filter in flow_director. For example, mask all ip packets coming from
> a particular subnet mask and particular range of l4 ports for each
> filter rule.
>
> We would like to get some suggestions on how to proceed with adding the
> above features.
You need to identify which API must change and what will be the ABI changes.
Then please send a deprecation notice before December 11 in order to be part
of the 2.2 release notes.
If you have some RFC patches to send (at least the API changes), it would be
a good discussion start.
Thanks
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
@ 2015-12-01 12:36 4% ` Robie Basak
2015-12-01 13:30 0% ` Neil Horman
0 siblings, 1 reply; 200+ results
From: Robie Basak @ 2015-12-01 12:36 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
On Tue, Dec 01, 2015 at 02:21:02PM +0200, Panu Matilainen wrote:
> Adding a soname and a semi-arbitrary version does not fix the fundamental
> problems:
>
> Since the library lumps together everything in DPDK, you'd have to bump its
> version whenever any of the individual libraries bumps its version to have
> the version mean anything. DPDK 2.0 and 2.1 are supposedly binary compatible
> but 2.2 certainly is not, and beyond that who knows.
>
> That in turn forces all apps to be rebuild whenever one of the libraries
> changes version, whether those apps use that particular library or not.
If we bundle all the libraries together into one package, then in
distributions we have to rebuild anyway when any of the libraries
changes version since a dependent package can't just depend on any later
version, because we don't know in advance what ABI breaks might occur.
It's also trivial to do rebuilds in a distribution. I'd prefer to see
ABI versioning done right to avoid the pain that might occur there.
Rebuilding dependent packages is on the other hand straightforward.
> The combined library doesn't have symbol versioning, so besides the better
> version compatibility tracking it loses other benefits like limited symbol
> visibility.
The combined library *should* have symbol versioning, which I've brought
up before. This isn't a reason to not have a combined library; it is a
reason to fix the combined library.
Why is limited symbol visibility a benefit in this case?
> Not to mention the extra complexity in makefiles to support it, the
> increasing amount of duct-tape required to hold it together. And still eg
> the MLX pmds declare the configuration not supported at all.
I'd argue that this is because the build system is unnecessarily complex
currently. A library consumer should just be able to #include
<dpdk/foo.h> and link with -ldpdk. It should not have a build system or
custom flags imposed on it by one of the libraries it uses.
Robie
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
2015-11-24 14:31 4% [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script Panu Matilainen
@ 2015-12-01 12:37 4% ` Robie Basak
2015-12-02 11:44 3% ` Neil Horman
1 sibling, 1 reply; 200+ results
From: Robie Basak @ 2015-12-01 12:37 UTC (permalink / raw)
To: Panu Matilainen, dev
Re-sending this unsigned since the ML rejected my signed email.
-1 from Ubuntu without further discussion since it will break us. Please
don't commit this patch yet.
I don't understand why we must have the complexity of so many shared
libraries. From a distribution packaging perspective, all I see is that
this multiplies potential work by twenty times and makes it awkward to
work with without special tooling (which then needs maintaining).
Before I go into details, it would be nice if someone could please
explain why DPDK has to be "special" in needing to do this? I don't
understand why DPDK must be different to every other userspace library
out there. If DPDK has a good need to be different then that's fair
enough. But I feel that if DPDK is deviating from the norm then we need
to frame the discussion from the perspective of "why DPDK must be
different", rather than having me trying to explain why the norm is the
right way to do it.
On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
> That's how Fedora and RHEL are shipping it already and nobody has so much
> as noticed anything strange, much less complained about it. 20 libraries
> is but a drop in the ocean on a average distro.
No, it is 20 times the work from the perspective of DPDK package
maintenance. Let me explain why.
In Debian and Ubuntu, we manage a library transition (an ABI bump in a
library together with all dependencies moving to use the new ABI) by
concurrently packaging both the old and new libraries at once. This
works well with the norm for libraries. We ship one binary package per
soname, with the major version as part of the package name. This allows
a system to have two (or more) ABIs installed simultaneously. For a
library transition, we just package the new version and then that can
land and work concurrently as we then individually update every
dependent (library-consuming) package.
This works because of conventions around sonames, which DPDK breaks
unless we treat it as twenty different libraries which changes our work
from easy to painful.
Usually a library transition is managed by hand by the package
maintainer. It's not taxing because it's straightforward and well
understood. Update and upload the new ABI source package, then find all
reverse dependencies and sort them out, recursively. But if the
maintainer must do it twenty times, then it becomes taxing and prone to
error. And if the reverse dependency tree differs depending on the split
library used by library consumers, then it gets far more complex to
follow.
Admittedly we could tool around this to make it easier, but that's extra
work (both initially and in maintenance) and prone to error (because
we'd only be doing it for DPDK).
Packaging a library is usually virtually a no-op in Debian and Ubuntu
nowadays. Our tooling does it all for us. But packaging DPDK is far from
this currently because of all this added complexity. From my perspective
this is unnecessary and makes no sense. We could do all kinds of things
to work around it (that's what packaging is about) but then we'd have to
maintain that specialness and I don't see why it must be awkward like
this instead of just doing it the same way as every other library.
> The combined library as it is simply is no longer a viable option.
> Besides just being broken (witness the strange hacks people are coming
> up with to work around issues in it) its ugly because it basically gives
> the middle finger to all the effort going into version compatibility,
> and its also big. Few projects will use every library in DPDK, but with
> the combined library they're forced to lug the 800 pound gorilla along
> needlessly.
It's broken because it's broken upstream, and that's what we should fix.
Why is it not viable? How does it give the middle finger to effort going
into version compatibility? Doing it the right way like every other
userspace library is what *gives us* version compatibility because then
distributions can straightforwardly install multiple ABI versions at
once.
Finally, I fail to see any "lug the 800 pound gorilla along" saving. We
(Ubuntu and Fedora) are both shipping all the libraries in one package,
whether split or combined, so they are all being lugged onto disk
anyway. Whether split or combined, there is no saving there. And memory
is hardly saved either because the kernel will just page in and out what
is needed in both cases. So how does this proposed change give us any
saving at all?
If distributions are expected to ship everything lumped together on one
package, then we don't get any benefit of having the library split up.
I did bring this up on this list[1] and my understanding of the outcome
then was that it would be fine for us to use the combined library, and
in time we could better define its ABI. Thus I'm not happy that you're
proposing to change tack on this, both because I'm far from convinced
it's a good idea for the project and wider ecosystem and also because it
creates more work for us.
I understand that in the embedded world you might want to build a subset
of the split libraries, and I'm not suggesting that we take away this
ability if there users who want it (though in that scenario I think
static builds probably make more sense). But in the distribution world,
for binaries we ship, I'd prefer to see things work the standard way
with standard tooling and nothing special going on when there is no need
for it.
Please can you explain why having a combined library is so much of a
problem?
Thanks,
Robie
[1] Message-ID: <20150902134900.GO467@mal.justgohome.co.uk>
Archive: http://dpdk.org/ml/archives/dev/2015-September/023180.html
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
2015-12-01 12:36 4% ` Robie Basak
@ 2015-12-01 13:30 0% ` Neil Horman
0 siblings, 0 replies; 200+ results
From: Neil Horman @ 2015-12-01 13:30 UTC (permalink / raw)
To: Robie Basak; +Cc: dev
On Tue, Dec 01, 2015 at 12:36:15PM +0000, Robie Basak wrote:
> On Tue, Dec 01, 2015 at 02:21:02PM +0200, Panu Matilainen wrote:
> > Adding a soname and a semi-arbitrary version does not fix the fundamental
> > problems:
> >
> > Since the library lumps together everything in DPDK, you'd have to bump its
> > version whenever any of the individual libraries bumps its version to have
> > the version mean anything. DPDK 2.0 and 2.1 are supposedly binary compatible
> > but 2.2 certainly is not, and beyond that who knows.
> >
> > That in turn forces all apps to be rebuild whenever one of the libraries
> > changes version, whether those apps use that particular library or not.
>
> If we bundle all the libraries together into one package, then in
> distributions we have to rebuild anyway when any of the libraries
> changes version since a dependent package can't just depend on any later
> version, because we don't know in advance what ABI breaks might occur.
> It's also trivial to do rebuilds in a distribution. I'd prefer to see
> ABI versioning done right to avoid the pain that might occur there.
> Rebuilding dependent packages is on the other hand straightforward.
>
> > The combined library doesn't have symbol versioning, so besides the better
> > version compatibility tracking it loses other benefits like limited symbol
> > visibility.
>
> The combined library *should* have symbol versioning, which I've brought
> up before. This isn't a reason to not have a combined library; it is a
> reason to fix the combined library.
>
Agreed, but using a linker script as the combined library gets you the proper
symbol versioning.
> Why is limited symbol visibility a benefit in this case?
>
Because it prevents an application from inadvertently using symbols that would
otherwise appear in another library (i.e. if not using the combined library, you
know you've used a symbol in another library because you are then forced to add
that library to the build.
> > Not to mention the extra complexity in makefiles to support it, the
> > increasing amount of duct-tape required to hold it together. And still eg
> > the MLX pmds declare the configuration not supported at all.
>
> I'd argue that this is because the build system is unnecessarily complex
> currently. A library consumer should just be able to #include
> <dpdk/foo.h> and link with -ldpdk. It should not have a build system or
> custom flags imposed on it by one of the libraries it uses.
>
I don't disagree here, but again, modeling libdpdk.so as a linker script gets
you to that point (or 99% of the way there at least).
Neil
> Robie
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
@ 2015-12-01 16:41 4% ` Jerin Jacob
2015-12-02 7:02 3% ` Jianbo Liu
[not found] ` <CAP4Qi3-5ofDU-2-4KsxFzMC1OpTsc5WjmxcFT2Eu_URA0UBzDw@mail.gmail.com>
0 siblings, 2 replies; 200+ results
From: Jerin Jacob @ 2015-12-01 16:41 UTC (permalink / raw)
To: Jianbo Liu; +Cc: dev
On Tue, Dec 01, 2015 at 01:41:15PM -0500, Jianbo Liu wrote:
> Adds ARM NEON support for lpm.
> And enables table/pipeline libraries which depend on lpm.
I already sent the patch on the same yesterday.
We can converge the patches after the discussion.
Please check "[dpdk-dev] [PATCH 0/3] add lpm support for NEON" on ml
>
> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
> ---
> config/defconfig_arm-armv7a-linuxapp-gcc | 3 -
> config/defconfig_arm64-armv8a-linuxapp-gcc | 3 -
> lib/librte_eal/common/include/arch/arm/rte_vect.h | 28 ++++++++++
> lib/librte_lpm/rte_lpm.h | 68 ++++++++++++++++-------
> 4 files changed, 77 insertions(+), 25 deletions(-)
>
> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc
> index cbebd64..efffa1f 100644
> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> @@ -53,9 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n
> CONFIG_RTE_EAL_IGB_UIO=n
>
> # fails to compile on ARM
> -CONFIG_RTE_LIBRTE_LPM=n
> -CONFIG_RTE_LIBRTE_TABLE=n
> -CONFIG_RTE_LIBRTE_PIPELINE=n
> CONFIG_RTE_SCHED_VECTOR=n
>
> # cannot use those on ARM
> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> index 504f3ed..57f7941 100644
> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> @@ -51,7 +51,4 @@ CONFIG_RTE_LIBRTE_IVSHMEM=n
> CONFIG_RTE_LIBRTE_FM10K_PMD=n
> CONFIG_RTE_LIBRTE_I40E_PMD=n
>
> -CONFIG_RTE_LIBRTE_LPM=n
> -CONFIG_RTE_LIBRTE_TABLE=n
> -CONFIG_RTE_LIBRTE_PIPELINE=n
> CONFIG_RTE_SCHED_VECTOR=n
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> index a33c054..7437711 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> @@ -41,6 +41,8 @@ extern "C" {
>
> typedef int32x4_t xmm_t;
>
> +typedef int32x4_t __m128i;
> +
> #define XMM_SIZE (sizeof(xmm_t))
> #define XMM_MASK (XMM_SIZE - 1)
>
> @@ -53,6 +55,32 @@ typedef union rte_xmm {
> double pd[XMM_SIZE / sizeof(double)];
> } __attribute__((aligned(16))) rte_xmm_t;
>
> +static __inline __m128i
> +_mm_set_epi32(int i3, int i2, int i1, int i0)
> +{
> + int32_t r[4] = {i0, i1, i2, i3};
> +
> + return vld1q_s32(r);
> +}
> +
> +static __inline __m128i
> +_mm_loadu_si128(__m128i *p)
> +{
> + return vld1q_s32((int32_t *)p);
> +}
> +
> +static __inline __m128i
> +_mm_set1_epi32(int i)
> +{
> + return vdupq_n_s32(i);
> +}
> +
> +static __inline __m128i
> +_mm_and_si128(__m128i a, __m128i b)
> +{
> + return vandq_s32(a, b);
> +}
> +
IMO, it makes sense to not emulate the SSE intrinsics with NEON
Let's create the rte_vect_* as required. look at the existing patch.
> #ifdef RTE_ARCH_ARM
> /* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */
> static __inline uint8x16_t
> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
> index c299ce2..c76c07d 100644
> --- a/lib/librte_lpm/rte_lpm.h
> +++ b/lib/librte_lpm/rte_lpm.h
> @@ -361,6 +361,47 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
> /* Mask four results. */
> #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff)
>
> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
Separate out arm implementation to the different header file.
Too many ifdef looks odd in the header file and difficult to manage.
> +static inline void
> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t tbl[4])
> +{
> + uint32x4_t i24;
> + uint32_t idx[4];
> +
> + /* get 4 indexes for tbl24[]. */
> + i24 = vshrq_n_u32(vreinterpretq_u32_s32(ip), CHAR_BIT);
> + vst1q_u32(idx, i24);
> +
> + /* extract values from tbl24[] */
> + tbl[0] = *(const uint16_t *)&lpm->tbl24[idx[0]];
> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx[1]];
> + tbl[2] = *(const uint16_t *)&lpm->tbl24[idx[2]];
> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx[3]];
> +}
Nice. There is an improvement in this portion code wrt my patch. This is
a candidate for convergence.
> +#else
> +static inline void
> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, __m128i ip, uint16_t tbl[4])
> +{
> + __m128i i24;
> + uint64_t idx;
> +
> + /* get 4 indexes for tbl24[]. */
> + i24 = _mm_srli_epi32(ip, CHAR_BIT);
> +
> + /* extract values from tbl24[] */
> + idx = _mm_cvtsi128_si64(i24);
> + i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> +
> + tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> +
> + idx = _mm_cvtsi128_si64(i24);
> +
> + tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> +}
> +#endif
> +
> /**
> * Lookup four IP addresses in an LPM table.
> *
> @@ -381,17 +422,19 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
> * if lookup would fail.
> */
> static inline void
> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> +rte_lpm_lookupx4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t hop[4],
> + uint16_t defv)
This would call for change in the change the ABI,
IMO, __m128i can be used to represent 128bit vector to avoid ABI chang
> +#else
separate out arm implementation to the different header file. Too many
ifdef looks odd in the header file.
Could you rebase your patch based on existing patch and send the
improvement portion as separate patch or I can send update patch with
your improvements and with your signoff.
> rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
> uint16_t defv)
> +#endif
> {
> - __m128i i24;
> rte_xmm_t i8;
> uint16_t tbl[4];
> - uint64_t idx, pt;
> -
> - const __m128i mask8 =
> - _mm_set_epi32(UINT8_MAX, UINT8_MAX, UINT8_MAX, UINT8_MAX);
> + uint64_t pt;
>
> + const __m128i mask8 = _mm_set1_epi32(UINT8_MAX);
> /*
> * RTE_LPM_VALID_EXT_ENTRY_BITMASK for 4 LPM entries
> * as one 64-bit value (0x0300030003000300).
> @@ -412,20 +455,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 32 |
> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 48);
>
> - /* get 4 indexes for tbl24[]. */
> - i24 = _mm_srli_epi32(ip, CHAR_BIT);
> -
> - /* extract values from tbl24[] */
> - idx = _mm_cvtsi128_si64(i24);
> - i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> -
> - tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> - tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> -
> - idx = _mm_cvtsi128_si64(i24);
> -
> - tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> - tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> + rte_lpm_tbl24_val4(lpm, ip, tbl);
>
> /* get 4 indexes for tbl8[]. */
> i8.x = _mm_and_si128(ip, mask8);
> --
> 1.8.3.1
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-01 16:41 4% ` Jerin Jacob
@ 2015-12-02 7:02 3% ` Jianbo Liu
[not found] ` <CAP4Qi3-5ofDU-2-4KsxFzMC1OpTsc5WjmxcFT2Eu_URA0UBzDw@mail.gmail.com>
1 sibling, 0 replies; 200+ results
From: Jianbo Liu @ 2015-12-02 7:02 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
On 2 December 2015 at 00:41, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> On Tue, Dec 01, 2015 at 01:41:15PM -0500, Jianbo Liu wrote:
>> Adds ARM NEON support for lpm.
>> And enables table/pipeline libraries which depend on lpm.
>
> I already sent the patch on the same yesterday.
> We can converge the patches after the discussion.
> Please check "[dpdk-dev] [PATCH 0/3] add lpm support for NEON" on ml
>
Yes, I have read your patch. But there are many differences, so I sent
mine for your reviewing :)
>
>>
>> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
>> ---
>> config/defconfig_arm-armv7a-linuxapp-gcc | 3 -
>> config/defconfig_arm64-armv8a-linuxapp-gcc | 3 -
>> lib/librte_eal/common/include/arch/arm/rte_vect.h | 28 ++++++++++
>> lib/librte_lpm/rte_lpm.h | 68 ++++++++++++++++-------
>> 4 files changed, 77 insertions(+), 25 deletions(-)
>>
>> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc
>> index cbebd64..efffa1f 100644
>> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
>> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
>> @@ -53,9 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n
>> CONFIG_RTE_EAL_IGB_UIO=n
>>
>> # fails to compile on ARM
>> -CONFIG_RTE_LIBRTE_LPM=n
>> -CONFIG_RTE_LIBRTE_TABLE=n
>> -CONFIG_RTE_LIBRTE_PIPELINE=n
>> CONFIG_RTE_SCHED_VECTOR=n
>>
>> # cannot use those on ARM
>> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
>> index 504f3ed..57f7941 100644
>> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
>> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
>> @@ -51,7 +51,4 @@ CONFIG_RTE_LIBRTE_IVSHMEM=n
>> CONFIG_RTE_LIBRTE_FM10K_PMD=n
>> CONFIG_RTE_LIBRTE_I40E_PMD=n
>>
>> -CONFIG_RTE_LIBRTE_LPM=n
>> -CONFIG_RTE_LIBRTE_TABLE=n
>> -CONFIG_RTE_LIBRTE_PIPELINE=n
>> CONFIG_RTE_SCHED_VECTOR=n
>> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
>> index a33c054..7437711 100644
>> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
>> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
>> @@ -41,6 +41,8 @@ extern "C" {
>>
>> typedef int32x4_t xmm_t;
>>
>> +typedef int32x4_t __m128i;
>> +
>> #define XMM_SIZE (sizeof(xmm_t))
>> #define XMM_MASK (XMM_SIZE - 1)
>>
>> @@ -53,6 +55,32 @@ typedef union rte_xmm {
>> double pd[XMM_SIZE / sizeof(double)];
>> } __attribute__((aligned(16))) rte_xmm_t;
>>
>> +static __inline __m128i
>> +_mm_set_epi32(int i3, int i2, int i1, int i0)
>> +{
>> + int32_t r[4] = {i0, i1, i2, i3};
>> +
>> + return vld1q_s32(r);
>> +}
>> +
>> +static __inline __m128i
>> +_mm_loadu_si128(__m128i *p)
>> +{
>> + return vld1q_s32((int32_t *)p);
>> +}
>> +
>> +static __inline __m128i
>> +_mm_set1_epi32(int i)
>> +{
>> + return vdupq_n_s32(i);
>> +}
>> +
>> +static __inline __m128i
>> +_mm_and_si128(__m128i a, __m128i b)
>> +{
>> + return vandq_s32(a, b);
>> +}
>> +
>
> IMO, it makes sense to not emulate the SSE intrinsics with NEON
> Let's create the rte_vect_* as required. look at the existing patch.
>
I thought of creating a layer of SIMD over all the platforms before.
But can't you see it make things complicated, considering there are
only few simple intrinsic to implement?
If do so, we also need to explain to others how to use these interfaces.
Besides, this patch did the smallest changes to the original code, and
more likely to be accepted by others.
>
>> #ifdef RTE_ARCH_ARM
>> /* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */
>> static __inline uint8x16_t
>> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
>> index c299ce2..c76c07d 100644
>> --- a/lib/librte_lpm/rte_lpm.h
>> +++ b/lib/librte_lpm/rte_lpm.h
>> @@ -361,6 +361,47 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
>> /* Mask four results. */
>> #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff)
>>
>> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
>
> Separate out arm implementation to the different header file.
> Too many ifdef looks odd in the header file and difficult to manage.
>
But there are many ifdefs already.
And It seems unreasonable to add a new file only for one small function.
>
>> +static inline void
>> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t tbl[4])
>> +{
>> + uint32x4_t i24;
>> + uint32_t idx[4];
>> +
>> + /* get 4 indexes for tbl24[]. */
>> + i24 = vshrq_n_u32(vreinterpretq_u32_s32(ip), CHAR_BIT);
>> + vst1q_u32(idx, i24);
>> +
>> + /* extract values from tbl24[] */
>> + tbl[0] = *(const uint16_t *)&lpm->tbl24[idx[0]];
>> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx[1]];
>> + tbl[2] = *(const uint16_t *)&lpm->tbl24[idx[2]];
>> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx[3]];
>> +}
>
> Nice. There is an improvement in this portion code wrt my patch. This is
> a candidate for convergence.
>
>
>> +#else
>> +static inline void
>> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, __m128i ip, uint16_t tbl[4])
>> +{
>> + __m128i i24;
>> + uint64_t idx;
>> +
>> + /* get 4 indexes for tbl24[]. */
>> + i24 = _mm_srli_epi32(ip, CHAR_BIT);
>> +
>> + /* extract values from tbl24[] */
>> + idx = _mm_cvtsi128_si64(i24);
>> + i24 = _mm_srli_si128(i24, sizeof(uint64_t));
>> +
>> + tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> +
>> + idx = _mm_cvtsi128_si64(i24);
>> +
>> + tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> +}
>> +#endif
>> +
>> /**
>> * Lookup four IP addresses in an LPM table.
>> *
>> @@ -381,17 +422,19 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
>> * if lookup would fail.
>> */
>> static inline void
>> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
>> +rte_lpm_lookupx4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t hop[4],
>> + uint16_t defv)
>
> This would call for change in the change the ABI,
> IMO, __m128i can be used to represent 128bit vector to avoid ABI chang
>
This redefine rte_lpm_lookupx4 is unncessary, I will remove it, so no
ABI change.
And there only one ifdef for ARM platforms left.
>
>> +#else
> separate out arm implementation to the different header file. Too many
> ifdef looks odd in the header file.
>
> Could you rebase your patch based on existing patch and send the
> improvement portion as separate patch or I can send update patch with
> your improvements and with your signoff.
>
>
>> rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
>> uint16_t defv)
>> +#endif
>> {
>> - __m128i i24;
>> rte_xmm_t i8;
>> uint16_t tbl[4];
>> - uint64_t idx, pt;
>> -
>> - const __m128i mask8 =
>> - _mm_set_epi32(UINT8_MAX, UINT8_MAX, UINT8_MAX, UINT8_MAX);
>> + uint64_t pt;
>>
>> + const __m128i mask8 = _mm_set1_epi32(UINT8_MAX);
>> /*
>> * RTE_LPM_VALID_EXT_ENTRY_BITMASK for 4 LPM entries
>> * as one 64-bit value (0x0300030003000300).
>> @@ -412,20 +455,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
>> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 32 |
>> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 48);
>>
>> - /* get 4 indexes for tbl24[]. */
>> - i24 = _mm_srli_epi32(ip, CHAR_BIT);
>> -
>> - /* extract values from tbl24[] */
>> - idx = _mm_cvtsi128_si64(i24);
>> - i24 = _mm_srli_si128(i24, sizeof(uint64_t));
>> -
>> - tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> - tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> -
>> - idx = _mm_cvtsi128_si64(i24);
>> -
>> - tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> - tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> + rte_lpm_tbl24_val4(lpm, ip, tbl);
>>
>> /* get 4 indexes for tbl8[]. */
>> i8.x = _mm_and_si128(ip, mask8);
>> --
>> 1.8.3.1
>>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
[not found] ` <CAP4Qi3-5ofDU-2-4KsxFzMC1OpTsc5WjmxcFT2Eu_URA0UBzDw@mail.gmail.com>
@ 2015-12-02 8:03 0% ` Jerin Jacob
2015-12-02 9:49 0% ` Jianbo Liu
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2015-12-02 8:03 UTC (permalink / raw)
To: Jianbo Liu; +Cc: dev
On Wed, Dec 02, 2015 at 02:54:52PM +0800, Jianbo Liu wrote:
> On 2 December 2015 at 00:41, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > On Tue, Dec 01, 2015 at 01:41:15PM -0500, Jianbo Liu wrote:
> >> Adds ARM NEON support for lpm.
> >> And enables table/pipeline libraries which depend on lpm.
> >
> > I already sent the patch on the same yesterday.
> > We can converge the patches after the discussion.
> > Please check "[dpdk-dev] [PATCH 0/3] add lpm support for NEON" on ml
> >
> Yes, I have read your patch. But there are many differences, so I sent
> mine for your reviewing :)
>
> >
> >>
> >> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
> >> ---
> >> config/defconfig_arm-armv7a-linuxapp-gcc | 3 -
> >> config/defconfig_arm64-armv8a-linuxapp-gcc | 3 -
> >> lib/librte_eal/common/include/arch/arm/rte_vect.h | 28 ++++++++++
> >> lib/librte_lpm/rte_lpm.h | 68 ++++++++++++++++-------
> >> 4 files changed, 77 insertions(+), 25 deletions(-)
> >>
> >> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc
> >> index cbebd64..efffa1f 100644
> >> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> >> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> >> @@ -53,9 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n
> >> CONFIG_RTE_EAL_IGB_UIO=n
> >>
> >> # fails to compile on ARM
> >> -CONFIG_RTE_LIBRTE_LPM=n
> >> -CONFIG_RTE_LIBRTE_TABLE=n
> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
> >> CONFIG_RTE_SCHED_VECTOR=n
> >>
> >> # cannot use those on ARM
> >> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> >> index 504f3ed..57f7941 100644
> >> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> >> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> >> @@ -51,7 +51,4 @@ CONFIG_RTE_LIBRTE_IVSHMEM=n
> >> CONFIG_RTE_LIBRTE_FM10K_PMD=n
> >> CONFIG_RTE_LIBRTE_I40E_PMD=n
> >>
> >> -CONFIG_RTE_LIBRTE_LPM=n
> >> -CONFIG_RTE_LIBRTE_TABLE=n
> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
> >> CONFIG_RTE_SCHED_VECTOR=n
> >> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> >> index a33c054..7437711 100644
> >> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> >> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> >> @@ -41,6 +41,8 @@ extern "C" {
> >>
> >> typedef int32x4_t xmm_t;
> >>
> >> +typedef int32x4_t __m128i;
> >> +
> >> #define XMM_SIZE (sizeof(xmm_t))
> >> #define XMM_MASK (XMM_SIZE - 1)
> >>
> >> @@ -53,6 +55,32 @@ typedef union rte_xmm {
> >> double pd[XMM_SIZE / sizeof(double)];
> >> } __attribute__((aligned(16))) rte_xmm_t;
> >>
> >> +static __inline __m128i
> >> +_mm_set_epi32(int i3, int i2, int i1, int i0)
> >> +{
> >> + int32_t r[4] = {i0, i1, i2, i3};
> >> +
> >> + return vld1q_s32(r);
> >> +}
> >> +
> >> +static __inline __m128i
> >> +_mm_loadu_si128(__m128i *p)
> >> +{
> >> + return vld1q_s32((int32_t *)p);
> >> +}
> >> +
> >> +static __inline __m128i
> >> +_mm_set1_epi32(int i)
> >> +{
> >> + return vdupq_n_s32(i);
> >> +}
> >> +
> >> +static __inline __m128i
> >> +_mm_and_si128(__m128i a, __m128i b)
> >> +{
> >> + return vandq_s32(a, b);
> >> +}
> >> +
IMO, it's not always good to emulate GCC defined intrinsics of
other architecture. What if a legacy DPDK application has such mappings
then BOOM, multiple definition, which one is correct? which one
to comment it out? Integration pain starts for DPDK library consumer:-(
> >
> > IMO, it makes sense to not emulate the SSE intrinsics with NEON
> > Let's create the rte_vect_* as required. look at the existing patch.
> >
> I thought of creating a layer of SIMD over all the platforms before.
> But can't you see it make things complicated, considering there are
> only few simple intrinsic to implement?
Not true, There were, a lot of SSE intrinsics needs be to emulated for ACL NEON
implementation if I were to take this approach and emulation comes with
the cost.
So my take is,
lets the each architecture implementation for specific SIMD version of DPDK
API in the library should have the freedom to implement the API in
NATIVE.
And let's create only rte_vect_* abstraction only for using
that API/library. Which boils down to have very minimal rte_vect_*
abstraction to load, store, set not beyond that.
This makes clear "contract" between DPDK library and the applications.
and make easy for remaning new architecture porting effort in DPDK.
Imagine how your proposed function will look like if new architecture
wants to implement "optimized" version of rte_lpm_lookupx4
> If do so, we also need to explain to others how to use these interfaces.
> Besides, this patch did the smallest changes to the original code, and
> more likely to be accepted by others.
other patch makes no changes to IA version of rte_lpm_lookupx4.I thought
that make reviewer easy to review the changes in architecture
perspective.
>
> >
> >> #ifdef RTE_ARCH_ARM
> >> /* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */
> >> static __inline uint8x16_t
> >> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
> >> index c299ce2..c76c07d 100644
> >> --- a/lib/librte_lpm/rte_lpm.h
> >> +++ b/lib/librte_lpm/rte_lpm.h
> >> @@ -361,6 +361,47 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
> >> /* Mask four results. */
> >> #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff)
> >>
> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> >
> > Separate out arm implementation to the different header file.
> > Too many ifdef looks odd in the header file and difficult to manage.
> >
> But there are many ifdefs already.
> And It seems unreasonable to add a new file only for one small function.
>
small or big, its matter of each architecture to have
the freedom for the optimized version for the implementation.
What if other architecture demands to write this function in assembly
or restructure it for performance improvement?
> >
> >> +static inline void
> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t tbl[4])
> >> +{
> >> + uint32x4_t i24;
> >> + uint32_t idx[4];
> >> +
> >> + /* get 4 indexes for tbl24[]. */
> >> + i24 = vshrq_n_u32(vreinterpretq_u32_s32(ip), CHAR_BIT);
> >> + vst1q_u32(idx, i24);
> >> +
> >> + /* extract values from tbl24[] */
> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[idx[0]];
> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx[1]];
> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[idx[2]];
> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx[3]];
> >> +}
> >
> > Nice. There is an improvement in this portion code wrt my patch. This is
> > a candidate for convergence.
> >
> >
> >> +#else
> >> +static inline void
> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, __m128i ip, uint16_t tbl[4])
> >> +{
> >> + __m128i i24;
> >> + uint64_t idx;
> >> +
> >> + /* get 4 indexes for tbl24[]. */
> >> + i24 = _mm_srli_epi32(ip, CHAR_BIT);
> >> +
> >> + /* extract values from tbl24[] */
> >> + idx = _mm_cvtsi128_si64(i24);
> >> + i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> >> +
> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> +
> >> + idx = _mm_cvtsi128_si64(i24);
> >> +
> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> +}
> >> +#endif
> >> +
> >> /**
> >> * Lookup four IP addresses in an LPM table.
> >> *
> >> @@ -381,17 +422,19 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
> >> * if lookup would fail.
> >> */
> >> static inline void
> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> >> +rte_lpm_lookupx4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t hop[4],
> >> + uint16_t defv)
> >
> > This would call for change in the change the ABI,
> > IMO, __m128i can be used to represent 128bit vector to avoid ABI chang
> >
> This redefine rte_lpm_lookupx4 is unncessary, I will remove it, so no
> ABI change.
> And there only one ifdef for ARM platforms left.
>
> >
> >> +#else
> > separate out arm implementation to the different header file. Too many
> > ifdef looks odd in the header file.
> >
> > Could you rebase your patch based on existing patch and send the
> > improvement portion as separate patch or I can send update patch with
> > your improvements and with your signoff.
> >
> >
> >> rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
> >> uint16_t defv)
> >> +#endif
> >> {
> >> - __m128i i24;
> >> rte_xmm_t i8;
> >> uint16_t tbl[4];
> >> - uint64_t idx, pt;
> >> -
> >> - const __m128i mask8 =
> >> - _mm_set_epi32(UINT8_MAX, UINT8_MAX, UINT8_MAX, UINT8_MAX);
> >> + uint64_t pt;
> >>
> >> + const __m128i mask8 = _mm_set1_epi32(UINT8_MAX);
> >> /*
> >> * RTE_LPM_VALID_EXT_ENTRY_BITMASK for 4 LPM entries
> >> * as one 64-bit value (0x0300030003000300).
> >> @@ -412,20 +455,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 32 |
> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 48);
> >>
> >> - /* get 4 indexes for tbl24[]. */
> >> - i24 = _mm_srli_epi32(ip, CHAR_BIT);
> >> -
> >> - /* extract values from tbl24[] */
> >> - idx = _mm_cvtsi128_si64(i24);
> >> - i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> >> -
> >> - tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> - tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> -
> >> - idx = _mm_cvtsi128_si64(i24);
> >> -
> >> - tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> - tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> + rte_lpm_tbl24_val4(lpm, ip, tbl);
> >>
> >> /* get 4 indexes for tbl8[]. */
> >> i8.x = _mm_and_si128(ip, mask8);
> >> --
> >> 1.8.3.1
> >>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] Query on Filtering Support in DPDK
2015-11-30 13:43 3% ` Thomas Monjalon
@ 2015-12-02 8:05 3% ` Rahul Lakkireddy
0 siblings, 0 replies; 200+ results
From: Rahul Lakkireddy @ 2015-12-02 8:05 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Felix Marti, Nirranjan Kirubaharan, Kumar A S
Hi Thomas,
On Monday, November 11/30/15, 2015 at 05:43:18 -0800, Thomas Monjalon wrote:
> Hi,
>
> 2015-11-30 18:19, Rahul Lakkireddy:
> > 1. Add a new action 'switch' that will:
> > * Allow re-direction to different ports in hardware.
> >
> > Also, for such a rule, additionally support below:
> >
> > * Allow source mac/destination mac and vlan header re-writing to be
> > done by the hardware.
> >
> > * Allow re-write of TCP/IP headers to perform NAT in hardware.
> >
> > 2. Add ability to mask individual fields at a particular layer for each
> > filter in flow_director. For example, mask all ip packets coming from
> > a particular subnet mask and particular range of l4 ports for each
> > filter rule.
> >
> > We would like to get some suggestions on how to proceed with adding the
> > above features.
>
> You need to identify which API must change and what will be the ABI changes.
> Then please send a deprecation notice before December 11 in order to be part
> of the 2.2 release notes.
I am currently identifying the various API changes to support this and
also the ABI changes if any.
>
> If you have some RFC patches to send (at least the API changes), it would be
> a good discussion start.
I will try to post some RFC patches in 3-4 days time to get more
inputs/reviews on the approach.
Thanks,
Rahul.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 8:03 0% ` Jerin Jacob
@ 2015-12-02 9:49 0% ` Jianbo Liu
2015-12-02 10:39 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Jianbo Liu @ 2015-12-02 9:49 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
On 2 December 2015 at 16:03, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> On Wed, Dec 02, 2015 at 02:54:52PM +0800, Jianbo Liu wrote:
>> On 2 December 2015 at 00:41, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
>> > On Tue, Dec 01, 2015 at 01:41:15PM -0500, Jianbo Liu wrote:
>> >> Adds ARM NEON support for lpm.
>> >> And enables table/pipeline libraries which depend on lpm.
>> >
>> > I already sent the patch on the same yesterday.
>> > We can converge the patches after the discussion.
>> > Please check "[dpdk-dev] [PATCH 0/3] add lpm support for NEON" on ml
>> >
>> Yes, I have read your patch. But there are many differences, so I sent
>> mine for your reviewing :)
>>
>> >
>> >>
>> >> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
>> >> ---
>> >> config/defconfig_arm-armv7a-linuxapp-gcc | 3 -
>> >> config/defconfig_arm64-armv8a-linuxapp-gcc | 3 -
>> >> lib/librte_eal/common/include/arch/arm/rte_vect.h | 28 ++++++++++
>> >> lib/librte_lpm/rte_lpm.h | 68 ++++++++++++++++-------
>> >> 4 files changed, 77 insertions(+), 25 deletions(-)
>> >>
>> >> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc
>> >> index cbebd64..efffa1f 100644
>> >> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
>> >> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
>> >> @@ -53,9 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n
>> >> CONFIG_RTE_EAL_IGB_UIO=n
>> >>
>> >> # fails to compile on ARM
>> >> -CONFIG_RTE_LIBRTE_LPM=n
>> >> -CONFIG_RTE_LIBRTE_TABLE=n
>> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
>> >> CONFIG_RTE_SCHED_VECTOR=n
>> >>
>> >> # cannot use those on ARM
>> >> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
>> >> index 504f3ed..57f7941 100644
>> >> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
>> >> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
>> >> @@ -51,7 +51,4 @@ CONFIG_RTE_LIBRTE_IVSHMEM=n
>> >> CONFIG_RTE_LIBRTE_FM10K_PMD=n
>> >> CONFIG_RTE_LIBRTE_I40E_PMD=n
>> >>
>> >> -CONFIG_RTE_LIBRTE_LPM=n
>> >> -CONFIG_RTE_LIBRTE_TABLE=n
>> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
>> >> CONFIG_RTE_SCHED_VECTOR=n
>> >> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
>> >> index a33c054..7437711 100644
>> >> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
>> >> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
>> >> @@ -41,6 +41,8 @@ extern "C" {
>> >>
>> >> typedef int32x4_t xmm_t;
>> >>
>> >> +typedef int32x4_t __m128i;
>> >> +
>> >> #define XMM_SIZE (sizeof(xmm_t))
>> >> #define XMM_MASK (XMM_SIZE - 1)
>> >>
>> >> @@ -53,6 +55,32 @@ typedef union rte_xmm {
>> >> double pd[XMM_SIZE / sizeof(double)];
>> >> } __attribute__((aligned(16))) rte_xmm_t;
>> >>
>> >> +static __inline __m128i
>> >> +_mm_set_epi32(int i3, int i2, int i1, int i0)
>> >> +{
>> >> + int32_t r[4] = {i0, i1, i2, i3};
>> >> +
>> >> + return vld1q_s32(r);
>> >> +}
>> >> +
>> >> +static __inline __m128i
>> >> +_mm_loadu_si128(__m128i *p)
>> >> +{
>> >> + return vld1q_s32((int32_t *)p);
>> >> +}
>> >> +
>> >> +static __inline __m128i
>> >> +_mm_set1_epi32(int i)
>> >> +{
>> >> + return vdupq_n_s32(i);
>> >> +}
>> >> +
>> >> +static __inline __m128i
>> >> +_mm_and_si128(__m128i a, __m128i b)
>> >> +{
>> >> + return vandq_s32(a, b);
>> >> +}
>> >> +
>
> IMO, it's not always good to emulate GCC defined intrinsics of
> other architecture. What if a legacy DPDK application has such mappings
> then BOOM, multiple definition, which one is correct? which one
> to comment it out? Integration pain starts for DPDK library consumer:-(
>
They can include rte_vect.h in build/include directly, which is linked correctly
to the one for that ARCH, so there is no need to worry about.
>> >
>> > IMO, it makes sense to not emulate the SSE intrinsics with NEON
>> > Let's create the rte_vect_* as required. look at the existing patch.
>> >
>> I thought of creating a layer of SIMD over all the platforms before.
>> But can't you see it make things complicated, considering there are
>> only few simple intrinsic to implement?
>
> Not true, There were, a lot of SSE intrinsics needs be to emulated for ACL NEON
> implementation if I were to take this approach and emulation comes with
> the cost.
>
No, I will not re-implement all the intrinsic like that .
I only do with the simple intrinsic, such as load/store, as you said below.
> So my take is,
> lets the each architecture implementation for specific SIMD version of DPDK
> API in the library should have the freedom to implement the API in
> NATIVE.
>
> And let's create only rte_vect_* abstraction only for using
> that API/library. Which boils down to have very minimal rte_vect_*
> abstraction to load, store, set not beyond that.
>
> This makes clear "contract" between DPDK library and the applications.
> and make easy for remaning new architecture porting effort in DPDK.
>
Agree.
But I reuse existing intrinsic names, and you recreate new ones.
And I try to do as few changes as possible, and try to avoid any
mistaken which may cause code un-compiled.
I think it's design level question, we need to hear what others talk about it.
> Imagine how your proposed function will look like if new architecture
> wants to implement "optimized" version of rte_lpm_lookupx4
>
There is no optimization for this (simple) rte_lpm_lookupx4, otherwise
you have done that in your patch.
If there is for other new platform, defintely they should do like
yours, as you did for NEON ACL.
>
>> If do so, we also need to explain to others how to use these interfaces.
>> Besides, this patch did the smallest changes to the original code, and
>> more likely to be accepted by others.
>
> other patch makes no changes to IA version of rte_lpm_lookupx4.I thought
> that make reviewer easy to review the changes in architecture
> perspective.
>
As I know, they don't enable LPM for PPC, and ARM is the first one to
touch this issue.
>>
>> >
>> >> #ifdef RTE_ARCH_ARM
>> >> /* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */
>> >> static __inline uint8x16_t
>> >> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
>> >> index c299ce2..c76c07d 100644
>> >> --- a/lib/librte_lpm/rte_lpm.h
>> >> +++ b/lib/librte_lpm/rte_lpm.h
>> >> @@ -361,6 +361,47 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
>> >> /* Mask four results. */
>> >> #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff)
>> >>
>> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
>> >
>> > Separate out arm implementation to the different header file.
>> > Too many ifdef looks odd in the header file and difficult to manage.
>> >
>> But there are many ifdefs already.
>> And It seems unreasonable to add a new file only for one small function.
>>
>
> small or big, its matter of each architecture to have
> the freedom for the optimized version for the implementation.
>
> What if other architecture demands to write this function in assembly
> or restructure it for performance improvement?
>
If there is such demands, should do like that.
But I don't see any restructure in your patch, and you still follow
the logic as x86, is it worth adding a new file?
>
>> >
>> >> +static inline void
>> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t tbl[4])
>> >> +{
>> >> + uint32x4_t i24;
>> >> + uint32_t idx[4];
>> >> +
>> >> + /* get 4 indexes for tbl24[]. */
>> >> + i24 = vshrq_n_u32(vreinterpretq_u32_s32(ip), CHAR_BIT);
>> >> + vst1q_u32(idx, i24);
>> >> +
>> >> + /* extract values from tbl24[] */
>> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[idx[0]];
>> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx[1]];
>> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[idx[2]];
>> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx[3]];
>> >> +}
>> >
>> > Nice. There is an improvement in this portion code wrt my patch. This is
>> > a candidate for convergence.
>> >
>> >
>> >> +#else
>> >> +static inline void
>> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, __m128i ip, uint16_t tbl[4])
>> >> +{
>> >> + __m128i i24;
>> >> + uint64_t idx;
>> >> +
>> >> + /* get 4 indexes for tbl24[]. */
>> >> + i24 = _mm_srli_epi32(ip, CHAR_BIT);
>> >> +
>> >> + /* extract values from tbl24[] */
>> >> + idx = _mm_cvtsi128_si64(i24);
>> >> + i24 = _mm_srli_si128(i24, sizeof(uint64_t));
>> >> +
>> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> >> +
>> >> + idx = _mm_cvtsi128_si64(i24);
>> >> +
>> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> >> +}
>> >> +#endif
>> >> +
>> >> /**
>> >> * Lookup four IP addresses in an LPM table.
>> >> *
>> >> @@ -381,17 +422,19 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
>> >> * if lookup would fail.
>> >> */
>> >> static inline void
>> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
>> >> +rte_lpm_lookupx4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t hop[4],
>> >> + uint16_t defv)
>> >
>> > This would call for change in the change the ABI,
>> > IMO, __m128i can be used to represent 128bit vector to avoid ABI chang
>> >
>> This redefine rte_lpm_lookupx4 is unncessary, I will remove it, so no
>> ABI change.
>> And there only one ifdef for ARM platforms left.
>>
>> >
>> >> +#else
>> > separate out arm implementation to the different header file. Too many
>> > ifdef looks odd in the header file.
>> >
>> > Could you rebase your patch based on existing patch and send the
>> > improvement portion as separate patch or I can send update patch with
>> > your improvements and with your signoff.
>> >
>> >
>> >> rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
>> >> uint16_t defv)
>> >> +#endif
>> >> {
>> >> - __m128i i24;
>> >> rte_xmm_t i8;
>> >> uint16_t tbl[4];
>> >> - uint64_t idx, pt;
>> >> -
>> >> - const __m128i mask8 =
>> >> - _mm_set_epi32(UINT8_MAX, UINT8_MAX, UINT8_MAX, UINT8_MAX);
>> >> + uint64_t pt;
>> >>
>> >> + const __m128i mask8 = _mm_set1_epi32(UINT8_MAX);
>> >> /*
>> >> * RTE_LPM_VALID_EXT_ENTRY_BITMASK for 4 LPM entries
>> >> * as one 64-bit value (0x0300030003000300).
>> >> @@ -412,20 +455,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
>> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 32 |
>> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 48);
>> >>
>> >> - /* get 4 indexes for tbl24[]. */
>> >> - i24 = _mm_srli_epi32(ip, CHAR_BIT);
>> >> -
>> >> - /* extract values from tbl24[] */
>> >> - idx = _mm_cvtsi128_si64(i24);
>> >> - i24 = _mm_srli_si128(i24, sizeof(uint64_t));
>> >> -
>> >> - tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> >> - tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> >> -
>> >> - idx = _mm_cvtsi128_si64(i24);
>> >> -
>> >> - tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> >> - tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> >> + rte_lpm_tbl24_val4(lpm, ip, tbl);
>> >>
>> >> /* get 4 indexes for tbl8[]. */
>> >> i8.x = _mm_and_si128(ip, mask8);
>> >> --
>> >> 1.8.3.1
>> >>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 9:49 0% ` Jianbo Liu
@ 2015-12-02 10:39 0% ` Jerin Jacob
2015-12-02 13:13 0% ` Jianbo Liu
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2015-12-02 10:39 UTC (permalink / raw)
To: Jianbo Liu; +Cc: dev
On Wed, Dec 02, 2015 at 05:49:41PM +0800, Jianbo Liu wrote:
> On 2 December 2015 at 16:03, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > On Wed, Dec 02, 2015 at 02:54:52PM +0800, Jianbo Liu wrote:
> >> On 2 December 2015 at 00:41, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> >> > On Tue, Dec 01, 2015 at 01:41:15PM -0500, Jianbo Liu wrote:
> >> >> Adds ARM NEON support for lpm.
> >> >> And enables table/pipeline libraries which depend on lpm.
> >> >
> >> > I already sent the patch on the same yesterday.
> >> > We can converge the patches after the discussion.
> >> > Please check "[dpdk-dev] [PATCH 0/3] add lpm support for NEON" on ml
> >> >
> >> Yes, I have read your patch. But there are many differences, so I sent
> >> mine for your reviewing :)
> >>
> >> >
> >> >>
> >> >> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
> >> >> ---
> >> >> config/defconfig_arm-armv7a-linuxapp-gcc | 3 -
> >> >> config/defconfig_arm64-armv8a-linuxapp-gcc | 3 -
> >> >> lib/librte_eal/common/include/arch/arm/rte_vect.h | 28 ++++++++++
> >> >> lib/librte_lpm/rte_lpm.h | 68 ++++++++++++++++-------
> >> >> 4 files changed, 77 insertions(+), 25 deletions(-)
> >> >>
> >> >> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc
> >> >> index cbebd64..efffa1f 100644
> >> >> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> >> >> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> >> >> @@ -53,9 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n
> >> >> CONFIG_RTE_EAL_IGB_UIO=n
> >> >>
> >> >> # fails to compile on ARM
> >> >> -CONFIG_RTE_LIBRTE_LPM=n
> >> >> -CONFIG_RTE_LIBRTE_TABLE=n
> >> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
> >> >> CONFIG_RTE_SCHED_VECTOR=n
> >> >>
> >> >> # cannot use those on ARM
> >> >> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> >> >> index 504f3ed..57f7941 100644
> >> >> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> >> >> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> >> >> @@ -51,7 +51,4 @@ CONFIG_RTE_LIBRTE_IVSHMEM=n
> >> >> CONFIG_RTE_LIBRTE_FM10K_PMD=n
> >> >> CONFIG_RTE_LIBRTE_I40E_PMD=n
> >> >>
> >> >> -CONFIG_RTE_LIBRTE_LPM=n
> >> >> -CONFIG_RTE_LIBRTE_TABLE=n
> >> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
> >> >> CONFIG_RTE_SCHED_VECTOR=n
> >> >> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> >> >> index a33c054..7437711 100644
> >> >> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> >> >> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> >> >> @@ -41,6 +41,8 @@ extern "C" {
> >> >>
> >> >> typedef int32x4_t xmm_t;
> >> >>
> >> >> +typedef int32x4_t __m128i;
> >> >> +
> >> >> #define XMM_SIZE (sizeof(xmm_t))
> >> >> #define XMM_MASK (XMM_SIZE - 1)
> >> >>
> >> >> @@ -53,6 +55,32 @@ typedef union rte_xmm {
> >> >> double pd[XMM_SIZE / sizeof(double)];
> >> >> } __attribute__((aligned(16))) rte_xmm_t;
> >> >>
> >> >> +static __inline __m128i
> >> >> +_mm_set_epi32(int i3, int i2, int i1, int i0)
> >> >> +{
> >> >> + int32_t r[4] = {i0, i1, i2, i3};
> >> >> +
> >> >> + return vld1q_s32(r);
> >> >> +}
> >> >> +
> >> >> +static __inline __m128i
> >> >> +_mm_loadu_si128(__m128i *p)
> >> >> +{
> >> >> + return vld1q_s32((int32_t *)p);
> >> >> +}
> >> >> +
> >> >> +static __inline __m128i
> >> >> +_mm_set1_epi32(int i)
> >> >> +{
> >> >> + return vdupq_n_s32(i);
> >> >> +}
> >> >> +
> >> >> +static __inline __m128i
> >> >> +_mm_and_si128(__m128i a, __m128i b)
> >> >> +{
> >> >> + return vandq_s32(a, b);
> >> >> +}
> >> >> +
> >
> > IMO, it's not always good to emulate GCC defined intrinsics of
> > other architecture. What if a legacy DPDK application has such mappings
> > then BOOM, multiple definition, which one is correct? which one
> > to comment it out? Integration pain starts for DPDK library consumer:-(
> >
> They can include rte_vect.h in build/include directly, which is linked correctly
> to the one for that ARCH, so there is no need to worry about.
I think you missed the point,I was trying to say that
legacy DPDK application and third party stacks uses SSE2NEON kind of
libraries
for quick integration, for example, something like this
https://github.com/jratcliff63367/sse2neon/blob/master/SSE2NEON.h
AND they include "rte_lpm.h"(it internally includes rte_vect.h)
that lead to multiple definition and its not good.
>
>
> >> >
> >> > IMO, it makes sense to not emulate the SSE intrinsics with NEON
> >> > Let's create the rte_vect_* as required. look at the existing patch.
> >> >
> >> I thought of creating a layer of SIMD over all the platforms before.
> >> But can't you see it make things complicated, considering there are
> >> only few simple intrinsic to implement?
> >
> > Not true, There were, a lot of SSE intrinsics needs be to emulated for ACL NEON
> > implementation if I were to take this approach and emulation comes with
> > the cost.
> >
> No, I will not re-implement all the intrinsic like that .
> I only do with the simple intrinsic, such as load/store, as you said below.
but you forced to add _mm_and_si128 also to the list and emulated
_mm_and_si128 intrinsic. Am just saying no emulation.
>
> > So my take is,
> > lets the each architecture implementation for specific SIMD version of DPDK
> > API in the library should have the freedom to implement the API in
> > NATIVE.
> >
> > And let's create only rte_vect_* abstraction only for using
> > that API/library. Which boils down to have very minimal rte_vect_*
> > abstraction to load, store, set not beyond that.
> >
> > This makes clear "contract" between DPDK library and the applications.
> > and make easy for remaning new architecture porting effort in DPDK.
> >
> Agree.
> But I reuse existing intrinsic names, and you recreate new ones.
> And I try to do as few changes as possible, and try to avoid any
> mistaken which may cause code un-compiled.
Its trival to verify. Just compile it
> I think it's design level question, we need to hear what others talk about it.
>
> > Imagine how your proposed function will look like if new architecture
> > wants to implement "optimized" version of rte_lpm_lookupx4
> >
> There is no optimization for this (simple) rte_lpm_lookupx4, otherwise
> you have done that in your patch.
> If there is for other new platform, defintely they should do like
> yours, as you did for NEON ACL.
>
> >
> >> If do so, we also need to explain to others how to use these interfaces.
> >> Besides, this patch did the smallest changes to the original code, and
> >> more likely to be accepted by others.
> >
> > other patch makes no changes to IA version of rte_lpm_lookupx4.I thought
> > that make reviewer easy to review the changes in architecture
> > perspective.
> >
> As I know, they don't enable LPM for PPC, and ARM is the first one to
> touch this issue.
>
> >>
> >> >
> >> >> #ifdef RTE_ARCH_ARM
> >> >> /* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */
> >> >> static __inline uint8x16_t
> >> >> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
> >> >> index c299ce2..c76c07d 100644
> >> >> --- a/lib/librte_lpm/rte_lpm.h
> >> >> +++ b/lib/librte_lpm/rte_lpm.h
> >> >> @@ -361,6 +361,47 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
> >> >> /* Mask four results. */
> >> >> #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff)
> >> >>
> >> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> >> >
> >> > Separate out arm implementation to the different header file.
> >> > Too many ifdef looks odd in the header file and difficult to manage.
> >> >
> >> But there are many ifdefs already.
> >> And It seems unreasonable to add a new file only for one small function.
> >>
> >
> > small or big, its matter of each architecture to have
> > the freedom for the optimized version for the implementation.
> >
> > What if other architecture demands to write this function in assembly
> > or restructure it for performance improvement?
> >
> If there is such demands, should do like that.
> But I don't see any restructure in your patch, and you still follow
> the logic as x86, is it worth adding a new file?
SIMD Logic on getting 4 indexes for tbl24[] is different.
/* get 4 indexes for tbl24[]. */
i24 = _mm_srli_epi32(ip, CHAR_BIT);
/* extract values from tbl24[] */
idx = _mm_cvtsi128_si64(i24);
i24 = _mm_srli_si128(i24, sizeof(uint64_t));
tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
idx = _mm_cvtsi128_si64(i24);
tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
VS
/* extract values from tbl24[] */
idx = vgetq_lane_u64((uint64x2_t)i24, 0);
tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
idx = vgetq_lane_u64((uint64x2_t)i24, 1);
tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>
> >
> >> >
> >> >> +static inline void
> >> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t tbl[4])
> >> >> +{
> >> >> + uint32x4_t i24;
> >> >> + uint32_t idx[4];
> >> >> +
> >> >> + /* get 4 indexes for tbl24[]. */
> >> >> + i24 = vshrq_n_u32(vreinterpretq_u32_s32(ip), CHAR_BIT);
> >> >> + vst1q_u32(idx, i24);
> >> >> +
> >> >> + /* extract values from tbl24[] */
> >> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[idx[0]];
> >> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx[1]];
> >> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[idx[2]];
> >> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx[3]];
> >> >> +}
> >> >
> >> > Nice. There is an improvement in this portion code wrt my patch. This is
> >> > a candidate for convergence.
> >> >
> >> >
> >> >> +#else
> >> >> +static inline void
> >> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, __m128i ip, uint16_t tbl[4])
> >> >> +{
> >> >> + __m128i i24;
> >> >> + uint64_t idx;
> >> >> +
> >> >> + /* get 4 indexes for tbl24[]. */
> >> >> + i24 = _mm_srli_epi32(ip, CHAR_BIT);
> >> >> +
> >> >> + /* extract values from tbl24[] */
> >> >> + idx = _mm_cvtsi128_si64(i24);
> >> >> + i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> >> >> +
> >> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> >> +
> >> >> + idx = _mm_cvtsi128_si64(i24);
> >> >> +
> >> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> >> +}
> >> >> +#endif
> >> >> +
> >> >> /**
> >> >> * Lookup four IP addresses in an LPM table.
> >> >> *
> >> >> @@ -381,17 +422,19 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
> >> >> * if lookup would fail.
> >> >> */
> >> >> static inline void
> >> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> >> >> +rte_lpm_lookupx4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t hop[4],
> >> >> + uint16_t defv)
> >> >
> >> > This would call for change in the change the ABI,
> >> > IMO, __m128i can be used to represent 128bit vector to avoid ABI chang
> >> >
> >> This redefine rte_lpm_lookupx4 is unncessary, I will remove it, so no
> >> ABI change.
> >> And there only one ifdef for ARM platforms left.
> >>
> >> >
> >> >> +#else
> >> > separate out arm implementation to the different header file. Too many
> >> > ifdef looks odd in the header file.
> >> >
> >> > Could you rebase your patch based on existing patch and send the
> >> > improvement portion as separate patch or I can send update patch with
> >> > your improvements and with your signoff.
> >> >
> >> >
> >> >> rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
> >> >> uint16_t defv)
> >> >> +#endif
> >> >> {
> >> >> - __m128i i24;
> >> >> rte_xmm_t i8;
> >> >> uint16_t tbl[4];
> >> >> - uint64_t idx, pt;
> >> >> -
> >> >> - const __m128i mask8 =
> >> >> - _mm_set_epi32(UINT8_MAX, UINT8_MAX, UINT8_MAX, UINT8_MAX);
> >> >> + uint64_t pt;
> >> >>
> >> >> + const __m128i mask8 = _mm_set1_epi32(UINT8_MAX);
> >> >> /*
> >> >> * RTE_LPM_VALID_EXT_ENTRY_BITMASK for 4 LPM entries
> >> >> * as one 64-bit value (0x0300030003000300).
> >> >> @@ -412,20 +455,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
> >> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 32 |
> >> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 48);
> >> >>
> >> >> - /* get 4 indexes for tbl24[]. */
> >> >> - i24 = _mm_srli_epi32(ip, CHAR_BIT);
> >> >> -
> >> >> - /* extract values from tbl24[] */
> >> >> - idx = _mm_cvtsi128_si64(i24);
> >> >> - i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> >> >> -
> >> >> - tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> >> - tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> >> -
> >> >> - idx = _mm_cvtsi128_si64(i24);
> >> >> -
> >> >> - tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> >> - tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> >> + rte_lpm_tbl24_val4(lpm, ip, tbl);
> >> >>
> >> >> /* get 4 indexes for tbl8[]. */
> >> >> i8.x = _mm_and_si128(ip, mask8);
> >> >> --
> >> >> 1.8.3.1
> >> >>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
2015-12-01 12:37 4% ` Robie Basak
@ 2015-12-02 11:44 3% ` Neil Horman
2015-12-03 1:31 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Neil Horman @ 2015-12-02 11:44 UTC (permalink / raw)
To: Robie Basak; +Cc: dev
On Tue, Dec 01, 2015 at 12:37:37PM +0000, Robie Basak wrote:
> Re-sending this unsigned since the ML rejected my signed email.
>
> -1 from Ubuntu without further discussion since it will break us. Please
> don't commit this patch yet.
>
> I don't understand why we must have the complexity of so many shared
> libraries. From a distribution packaging perspective, all I see is that
> this multiplies potential work by twenty times and makes it awkward to
> work with without special tooling (which then needs maintaining).
>
Theres nothing "complex" about the simple fact that a project builds lots of
libraries. Its extreemely common. Any graphic window manager has exactly the
same situation, as do any number of tools that have multiple hardware backends
impelmented in user space (v4l, sane, iptables, to name just a few).
> Before I go into details, it would be nice if someone could please
> explain why DPDK has to be "special" in needing to do this? I don't
Its not special, see above. Not saying the build environment cant be improved,
but the fact that there are multiple libraries is pretty straightforward.
> understand why DPDK must be different to every other userspace library
> out there. If DPDK has a good need to be different then that's fair
> enough. But I feel that if DPDK is deviating from the norm then we need
> to frame the discussion from the perspective of "why DPDK must be
> different", rather than having me trying to explain why the norm is the
> right way to do it.
>
> On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
> > That's how Fedora and RHEL are shipping it already and nobody has so much
> > as noticed anything strange, much less complained about it. 20 libraries
> > is but a drop in the ocean on a average distro.
>
> No, it is 20 times the work from the perspective of DPDK package
> maintenance. Let me explain why.
>
> In Debian and Ubuntu, we manage a library transition (an ABI bump in a
> library together with all dependencies moving to use the new ABI) by
> concurrently packaging both the old and new libraries at once. This
> works well with the norm for libraries. We ship one binary package per
> soname, with the major version as part of the package name. This allows
> a system to have two (or more) ABIs installed simultaneously. For a
> library transition, we just package the new version and then that can
> land and work concurrently as we then individually update every
> dependent (library-consuming) package.
So thats, a distribution choice, not an upstream problem. And it seems like a
problem you should have already solved (note the examples above). If you feel
like you need to package multiple ABI versions in the same library, you can,
just update the LIBABIVER of all the libraries, instead of the ones that truly
change, so that each library is guaranteed a newer so version, to make the
library file name unique. Yes you have to make a small change from upstream,
but thats part of the work that distribution maintainers do.
> This works because of conventions around sonames, which DPDK breaks
> unless we treat it as twenty different libraries which changes our work
> from easy to painful.
>
> Usually a library transition is managed by hand by the package
> maintainer. It's not taxing because it's straightforward and well
> understood. Update and upload the new ABI source package, then find all
> reverse dependencies and sort them out, recursively. But if the
> maintainer must do it twenty times, then it becomes taxing and prone to
> error. And if the reverse dependency tree differs depending on the split
> library used by library consumers, then it gets far more complex to
> follow.
>
> Admittedly we could tool around this to make it easier, but that's extra
> work (both initially and in maintenance) and prone to error (because
> we'd only be doing it for DPDK).
>
You must already have a solution to this, I can't imagine you package all the
libraries for kde or gnome (or even pam) separately)
> Packaging a library is usually virtually a no-op in Debian and Ubuntu
> nowadays. Our tooling does it all for us. But packaging DPDK is far from
> this currently because of all this added complexity. From my perspective
> this is unnecessary and makes no sense. We could do all kinds of things
> to work around it (that's what packaging is about) but then we'd have to
> maintain that specialness and I don't see why it must be awkward like
> this instead of just doing it the same way as every other library.
>
> > The combined library as it is simply is no longer a viable option.
> > Besides just being broken (witness the strange hacks people are coming
> > up with to work around issues in it) its ugly because it basically gives
> > the middle finger to all the effort going into version compatibility,
> > and its also big. Few projects will use every library in DPDK, but with
> > the combined library they're forced to lug the 800 pound gorilla along
> > needlessly.
>
> It's broken because it's broken upstream, and that's what we should fix.
> Why is it not viable? How does it give the middle finger to effort going
> into version compatibility?
Because each individual library has a version script that gets applied during
link to version symbols properly. Those scripts dont get applied when building
the combined library.
> Doing it the right way like every other
> userspace library is what *gives us* version compatibility because then
> distributions can straightforwardly install multiple ABI versions at
> once.
Again, Not at all uncommon. You're packaging methodology is the issue here,
not the fact that there are multiple libraries.
> Finally, I fail to see any "lug the 800 pound gorilla along" saving. We
> (Ubuntu and Fedora) are both shipping all the libraries in one package,
> whether split or combined, so they are all being lugged onto disk
> anyway. Whether split or combined, there is no saving there. And memory
> is hardly saved either because the kernel will just page in and out what
> is needed in both cases. So how does this proposed change give us any
> saving at all?
>
Not true, initalization constructors for PMD's at the very least mean that every
pmd will get paged in weather you want it or not using the combined library.
Individual libraries let you dynamically load them (via dlopen). I think the
same is true of several other facets of dpdk.
Neil
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 10:39 0% ` Jerin Jacob
@ 2015-12-02 13:13 0% ` Jianbo Liu
2015-12-02 14:34 3% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Jianbo Liu @ 2015-12-02 13:13 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> On Wed, Dec 02, 2015 at 05:49:41PM +0800, Jianbo Liu wrote:
>> On 2 December 2015 at 16:03, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
>> > On Wed, Dec 02, 2015 at 02:54:52PM +0800, Jianbo Liu wrote:
>> >> On 2 December 2015 at 00:41, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
>> >> > On Tue, Dec 01, 2015 at 01:41:15PM -0500, Jianbo Liu wrote:
>> >> >> Adds ARM NEON support for lpm.
>> >> >> And enables table/pipeline libraries which depend on lpm.
>> >> >
>> >> > I already sent the patch on the same yesterday.
>> >> > We can converge the patches after the discussion.
>> >> > Please check "[dpdk-dev] [PATCH 0/3] add lpm support for NEON" on ml
>> >> >
>> >> Yes, I have read your patch. But there are many differences, so I sent
>> >> mine for your reviewing :)
>> >>
>> >> >
>> >> >>
>> >> >> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
>> >> >> ---
>> >> >> config/defconfig_arm-armv7a-linuxapp-gcc | 3 -
>> >> >> config/defconfig_arm64-armv8a-linuxapp-gcc | 3 -
>> >> >> lib/librte_eal/common/include/arch/arm/rte_vect.h | 28 ++++++++++
>> >> >> lib/librte_lpm/rte_lpm.h | 68 ++++++++++++++++-------
>> >> >> 4 files changed, 77 insertions(+), 25 deletions(-)
>> >> >>
>> >> >> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc
>> >> >> index cbebd64..efffa1f 100644
>> >> >> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
>> >> >> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
>> >> >> @@ -53,9 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n
>> >> >> CONFIG_RTE_EAL_IGB_UIO=n
>> >> >>
>> >> >> # fails to compile on ARM
>> >> >> -CONFIG_RTE_LIBRTE_LPM=n
>> >> >> -CONFIG_RTE_LIBRTE_TABLE=n
>> >> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
>> >> >> CONFIG_RTE_SCHED_VECTOR=n
>> >> >>
>> >> >> # cannot use those on ARM
>> >> >> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
>> >> >> index 504f3ed..57f7941 100644
>> >> >> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
>> >> >> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
>> >> >> @@ -51,7 +51,4 @@ CONFIG_RTE_LIBRTE_IVSHMEM=n
>> >> >> CONFIG_RTE_LIBRTE_FM10K_PMD=n
>> >> >> CONFIG_RTE_LIBRTE_I40E_PMD=n
>> >> >>
>> >> >> -CONFIG_RTE_LIBRTE_LPM=n
>> >> >> -CONFIG_RTE_LIBRTE_TABLE=n
>> >> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
>> >> >> CONFIG_RTE_SCHED_VECTOR=n
>> >> >> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
>> >> >> index a33c054..7437711 100644
>> >> >> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
>> >> >> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
>> >> >> @@ -41,6 +41,8 @@ extern "C" {
>> >> >>
>> >> >> typedef int32x4_t xmm_t;
>> >> >>
>> >> >> +typedef int32x4_t __m128i;
>> >> >> +
>> >> >> #define XMM_SIZE (sizeof(xmm_t))
>> >> >> #define XMM_MASK (XMM_SIZE - 1)
>> >> >>
>> >> >> @@ -53,6 +55,32 @@ typedef union rte_xmm {
>> >> >> double pd[XMM_SIZE / sizeof(double)];
>> >> >> } __attribute__((aligned(16))) rte_xmm_t;
>> >> >>
>> >> >> +static __inline __m128i
>> >> >> +_mm_set_epi32(int i3, int i2, int i1, int i0)
>> >> >> +{
>> >> >> + int32_t r[4] = {i0, i1, i2, i3};
>> >> >> +
>> >> >> + return vld1q_s32(r);
>> >> >> +}
>> >> >> +
>> >> >> +static __inline __m128i
>> >> >> +_mm_loadu_si128(__m128i *p)
>> >> >> +{
>> >> >> + return vld1q_s32((int32_t *)p);
>> >> >> +}
>> >> >> +
>> >> >> +static __inline __m128i
>> >> >> +_mm_set1_epi32(int i)
>> >> >> +{
>> >> >> + return vdupq_n_s32(i);
>> >> >> +}
>> >> >> +
>> >> >> +static __inline __m128i
>> >> >> +_mm_and_si128(__m128i a, __m128i b)
>> >> >> +{
>> >> >> + return vandq_s32(a, b);
>> >> >> +}
>> >> >> +
>> >
>> > IMO, it's not always good to emulate GCC defined intrinsics of
>> > other architecture. What if a legacy DPDK application has such mappings
>> > then BOOM, multiple definition, which one is correct? which one
>> > to comment it out? Integration pain starts for DPDK library consumer:-(
>> >
>> They can include rte_vect.h in build/include directly, which is linked correctly
>> to the one for that ARCH, so there is no need to worry about.
>
> I think you missed the point,I was trying to say that
> legacy DPDK application and third party stacks uses SSE2NEON kind of
> libraries
> for quick integration, for example, something like this
> https://github.com/jratcliff63367/sse2neon/blob/master/SSE2NEON.h
>
> AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> that lead to multiple definition and its not good.
>
But you will have similar issue since "typedef int32x4_t __m128i"
appears in both your patch and this header file.
>>
>>
>> >> >
>> >> > IMO, it makes sense to not emulate the SSE intrinsics with NEON
>> >> > Let's create the rte_vect_* as required. look at the existing patch.
>> >> >
>> >> I thought of creating a layer of SIMD over all the platforms before.
>> >> But can't you see it make things complicated, considering there are
>> >> only few simple intrinsic to implement?
>> >
>> > Not true, There were, a lot of SSE intrinsics needs be to emulated for ACL NEON
>> > implementation if I were to take this approach and emulation comes with
>> > the cost.
>> >
>> No, I will not re-implement all the intrinsic like that .
>> I only do with the simple intrinsic, such as load/store, as you said below.
>
> but you forced to add _mm_and_si128 also to the list and emulated
> _mm_and_si128 intrinsic. Am just saying no emulation.
>
I means simple intrinsic, not load/store only.
Depends on how you define emulation. Actually, these simple intrisinic
could be only one NEON instruction, and will not bring cost.
>
>>
>> > So my take is,
>> > lets the each architecture implementation for specific SIMD version of DPDK
>> > API in the library should have the freedom to implement the API in
>> > NATIVE.
>> >
>> > And let's create only rte_vect_* abstraction only for using
>> > that API/library. Which boils down to have very minimal rte_vect_*
>> > abstraction to load, store, set not beyond that.
>> >
>> > This makes clear "contract" between DPDK library and the applications.
>> > and make easy for remaning new architecture porting effort in DPDK.
>> >
>> Agree.
>> But I reuse existing intrinsic names, and you recreate new ones.
>> And I try to do as few changes as possible, and try to avoid any
>> mistaken which may cause code un-compiled.
>
> Its trival to verify. Just compile it
>
>> I think it's design level question, we need to hear what others talk about it.
>>
>> > Imagine how your proposed function will look like if new architecture
>> > wants to implement "optimized" version of rte_lpm_lookupx4
>> >
>> There is no optimization for this (simple) rte_lpm_lookupx4, otherwise
>> you have done that in your patch.
>> If there is for other new platform, defintely they should do like
>> yours, as you did for NEON ACL.
>>
>> >
>> >> If do so, we also need to explain to others how to use these interfaces.
>> >> Besides, this patch did the smallest changes to the original code, and
>> >> more likely to be accepted by others.
>> >
>> > other patch makes no changes to IA version of rte_lpm_lookupx4.I thought
>> > that make reviewer easy to review the changes in architecture
>> > perspective.
>> >
>> As I know, they don't enable LPM for PPC, and ARM is the first one to
>> touch this issue.
>>
>> >>
>> >> >
>> >> >> #ifdef RTE_ARCH_ARM
>> >> >> /* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */
>> >> >> static __inline uint8x16_t
>> >> >> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
>> >> >> index c299ce2..c76c07d 100644
>> >> >> --- a/lib/librte_lpm/rte_lpm.h
>> >> >> +++ b/lib/librte_lpm/rte_lpm.h
>> >> >> @@ -361,6 +361,47 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
>> >> >> /* Mask four results. */
>> >> >> #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff)
>> >> >>
>> >> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
>> >> >
>> >> > Separate out arm implementation to the different header file.
>> >> > Too many ifdef looks odd in the header file and difficult to manage.
>> >> >
>> >> But there are many ifdefs already.
>> >> And It seems unreasonable to add a new file only for one small function.
>> >>
>> >
>> > small or big, its matter of each architecture to have
>> > the freedom for the optimized version for the implementation.
>> >
>> > What if other architecture demands to write this function in assembly
>> > or restructure it for performance improvement?
>> >
>> If there is such demands, should do like that.
>> But I don't see any restructure in your patch, and you still follow
>> the logic as x86, is it worth adding a new file?
>
> SIMD Logic on getting 4 indexes for tbl24[] is different.
>
> /* get 4 indexes for tbl24[]. */
> i24 = _mm_srli_epi32(ip, CHAR_BIT);
>
> /* extract values from tbl24[] */
> idx = _mm_cvtsi128_si64(i24);
> i24 = _mm_srli_si128(i24, sizeof(uint64_t));
>
> tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>
> idx = _mm_cvtsi128_si64(i24);
>
> tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>
> VS
>
> /* extract values from tbl24[] */
> idx = vgetq_lane_u64((uint64x2_t)i24, 0);
>
> tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>
> idx = vgetq_lane_u64((uint64x2_t)i24, 1);
>
> tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>
It's only the optimazation of part of code in that function. I did the
similar in my patch.
But, looking from the whole, this function is not restructured, and
the logic is the same as x86.
>>
>> >
>> >> >
>> >> >> +static inline void
>> >> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t tbl[4])
>> >> >> +{
>> >> >> + uint32x4_t i24;
>> >> >> + uint32_t idx[4];
>> >> >> +
>> >> >> + /* get 4 indexes for tbl24[]. */
>> >> >> + i24 = vshrq_n_u32(vreinterpretq_u32_s32(ip), CHAR_BIT);
>> >> >> + vst1q_u32(idx, i24);
>> >> >> +
>> >> >> + /* extract values from tbl24[] */
>> >> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[idx[0]];
>> >> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx[1]];
>> >> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[idx[2]];
>> >> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx[3]];
>> >> >> +}
>> >> >
>> >> > Nice. There is an improvement in this portion code wrt my patch. This is
>> >> > a candidate for convergence.
>> >> >
>> >> >
>> >> >> +#else
>> >> >> +static inline void
>> >> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, __m128i ip, uint16_t tbl[4])
>> >> >> +{
>> >> >> + __m128i i24;
>> >> >> + uint64_t idx;
>> >> >> +
>> >> >> + /* get 4 indexes for tbl24[]. */
>> >> >> + i24 = _mm_srli_epi32(ip, CHAR_BIT);
>> >> >> +
>> >> >> + /* extract values from tbl24[] */
>> >> >> + idx = _mm_cvtsi128_si64(i24);
>> >> >> + i24 = _mm_srli_si128(i24, sizeof(uint64_t));
>> >> >> +
>> >> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> >> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> >> >> +
>> >> >> + idx = _mm_cvtsi128_si64(i24);
>> >> >> +
>> >> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> >> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> >> >> +}
>> >> >> +#endif
>> >> >> +
>> >> >> /**
>> >> >> * Lookup four IP addresses in an LPM table.
>> >> >> *
>> >> >> @@ -381,17 +422,19 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
>> >> >> * if lookup would fail.
>> >> >> */
>> >> >> static inline void
>> >> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
>> >> >> +rte_lpm_lookupx4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t hop[4],
>> >> >> + uint16_t defv)
>> >> >
>> >> > This would call for change in the change the ABI,
>> >> > IMO, __m128i can be used to represent 128bit vector to avoid ABI chang
>> >> >
>> >> This redefine rte_lpm_lookupx4 is unncessary, I will remove it, so no
>> >> ABI change.
>> >> And there only one ifdef for ARM platforms left.
>> >>
>> >> >
>> >> >> +#else
>> >> > separate out arm implementation to the different header file. Too many
>> >> > ifdef looks odd in the header file.
>> >> >
>> >> > Could you rebase your patch based on existing patch and send the
>> >> > improvement portion as separate patch or I can send update patch with
>> >> > your improvements and with your signoff.
>> >> >
>> >> >
>> >> >> rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
>> >> >> uint16_t defv)
>> >> >> +#endif
>> >> >> {
>> >> >> - __m128i i24;
>> >> >> rte_xmm_t i8;
>> >> >> uint16_t tbl[4];
>> >> >> - uint64_t idx, pt;
>> >> >> -
>> >> >> - const __m128i mask8 =
>> >> >> - _mm_set_epi32(UINT8_MAX, UINT8_MAX, UINT8_MAX, UINT8_MAX);
>> >> >> + uint64_t pt;
>> >> >>
>> >> >> + const __m128i mask8 = _mm_set1_epi32(UINT8_MAX);
>> >> >> /*
>> >> >> * RTE_LPM_VALID_EXT_ENTRY_BITMASK for 4 LPM entries
>> >> >> * as one 64-bit value (0x0300030003000300).
>> >> >> @@ -412,20 +455,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
>> >> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 32 |
>> >> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 48);
>> >> >>
>> >> >> - /* get 4 indexes for tbl24[]. */
>> >> >> - i24 = _mm_srli_epi32(ip, CHAR_BIT);
>> >> >> -
>> >> >> - /* extract values from tbl24[] */
>> >> >> - idx = _mm_cvtsi128_si64(i24);
>> >> >> - i24 = _mm_srli_si128(i24, sizeof(uint64_t));
>> >> >> -
>> >> >> - tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> >> >> - tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> >> >> -
>> >> >> - idx = _mm_cvtsi128_si64(i24);
>> >> >> -
>> >> >> - tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
>> >> >> - tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
>> >> >> + rte_lpm_tbl24_val4(lpm, ip, tbl);
>> >> >>
>> >> >> /* get 4 indexes for tbl8[]. */
>> >> >> i8.x = _mm_and_si128(ip, mask8);
>> >> >> --
>> >> >> 1.8.3.1
>> >> >>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/3] eal: introduce rte_vect_* abstractions
@ 2015-12-02 13:43 3% ` Jan Viktorin
2015-12-02 14:51 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Jan Viktorin @ 2015-12-02 13:43 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
On Mon, 30 Nov 2015 22:54:11 +0530
Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> introduce rte_vect_* abstractions to remove SSE/AVX specific
> code in the common code(i.e the test applications)
>
> The patch does not provide any functional change for IA, the goal is to
Does IA mean Intel Architecture?
> have infrastructure to reuse the common vector-based test code across
> all the architectures.
>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> lib/librte_eal/common/include/arch/arm/rte_vect.h | 17 ++++++++++++++++-
> lib/librte_eal/common/include/arch/x86/rte_vect.h | 8 ++++++++
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> index 21cdb4d..d300951 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> @@ -33,13 +33,14 @@
> #ifndef _RTE_VECT_ARM_H_
> #define _RTE_VECT_ARM_H_
>
> -#include "arm_neon.h"
> +#include <arm_neon.h>
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> typedef int32x4_t xmm_t;
> +typedef int32x4_t __m128i;
As Jianbo pointed out recently, the __m128i type should be refactored in
a general rte_vect API too. If we do something like
#if SSE
typedef __m128i rte_128i;
#elif NEON
typedef int32x4_y rte_128i;
#endif
does it make somebody angry? I am afraid that it will influence a lot of
code. However, from the ABI point of view, it is OK, isn't it?
>
> #define XMM_SIZE (sizeof(xmm_t))
> #define XMM_MASK (XMM_SIZE - 1)
> @@ -53,6 +54,20 @@ typedef union rte_xmm {
> double pd[XMM_SIZE / sizeof(double)];
> } __attribute__((aligned(16))) rte_xmm_t;
>
> +/* rte_vect_* abstraction implementation using NEON */
> +
> +/* loads the __m128i value from address p(does not need to be 16-byte aligned)*/
> +#define rte_vect_loadu_sil128(p) vld1q_s32((const int32_t *)p)
> +
> +/* sets the 4 signed 32-bit integer values and returns the __m128i variable */
> +static inline __m128i __attribute__((always_inline))
> +rte_vect_set_epi32(int i3, int i2, int i1, int i0)
> +{
> + int32_t data[4] = {i0, i1, i2, i3};
> +
> + return vld1q_s32(data);
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_eal/common/include/arch/x86/rte_vect.h b/lib/librte_eal/common/include/arch/x86/rte_vect.h
> index b698797..91c6523 100644
> --- a/lib/librte_eal/common/include/arch/x86/rte_vect.h
> +++ b/lib/librte_eal/common/include/arch/x86/rte_vect.h
> @@ -125,6 +125,14 @@ typedef union rte_ymm {
> })
> #endif /* (defined(__ICC) && __ICC < 1210) */
>
> +/* rte_vect_* abstraction implementation using SSE */
> +
> +/* loads the __m128i value from address p(does not need to be 16-byte aligned)*/
> +#define rte_vect_loadu_sil128(p) _mm_loadu_si128(p)
> +
> +/* sets the 4 signed 32-bit integer values and returns the __m128i variable */
> +#define rte_vect_set_epi32(i3, i2, i1, i0) _mm_set_epi32(i3, i2, i1, i0)
> +
> #ifdef __cplusplus
> }
> #endif
I like this approach. It is a question whether to inherit names from
SSE. However, why to reinvent the wheel...
We probably need other people to give their ideas about such
generalization of the API.
I think, there should be an autotest of the rte_vect API. Is it
possible to create one?
Regards
Jan
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
@ 2015-12-02 13:53 4% ` Panu Matilainen
2015-12-02 14:31 5% ` Yuanhan Liu
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-02 13:53 UTC (permalink / raw)
To: Yuanhan Liu, dev; +Cc: Victor Kaplansky, Michael S. Tsirkin
On 12/02/2015 05:43 AM, Yuanhan Liu wrote:
> VHOST_USER_SET_LOG_BASE request is used to tell the backend (dpdk
> vhost-user) where we should log dirty pages, and how big the log
> buffer is.
>
> This request introduces a new payload:
>
> typedef struct VhostUserLog {
> uint64_t mmap_size;
> uint64_t mmap_offset;
> } VhostUserLog;
>
> Also, a fd is delivered from QEMU by ancillary data.
>
> With those info given, an area of memory is mmaped, assigned
> to dev->log_base, for logging dirty pages.
>
> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> ---
> lib/librte_vhost/rte_virtio_net.h | 2 ++
> lib/librte_vhost/vhost_user/vhost-net-user.c | 7 ++++-
> lib/librte_vhost/vhost_user/vhost-net-user.h | 6 ++++
> lib/librte_vhost/vhost_user/virtio-net-user.c | 44 +++++++++++++++++++++++++++
> lib/librte_vhost/vhost_user/virtio-net-user.h | 1 +
> 5 files changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
> index 5687452..416dac2 100644
> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -127,6 +127,8 @@ struct virtio_net {
> #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
> char ifname[IF_NAME_SZ]; /**< Name of the tap device or socket path. */
> uint32_t virt_qp_nb; /**< number of queue pair we have allocated */
> + uint64_t log_size; /**< Size of log area */
> + uint8_t *log_base; /**< Where dirty pages are logged */
> void *priv; /**< private context */
> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
> } __rte_cache_aligned;
This (and other changes in patch 2 breaks the librte_vhost ABI again, so
you'd need to at least add a deprecation note to 2.2 to be able to do it
in 2.3 at all according to the ABI policy.
Perhaps a better option would be adding some padding to the structs now
for 2.2 since the vhost ABI is broken there anyway. That would at least
give a chance to keep it compatible from 2.2 to 2.3.
- Panu -
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 13:53 4% ` Panu Matilainen
@ 2015-12-02 14:31 5% ` Yuanhan Liu
2015-12-02 14:48 4% ` Panu Matilainen
2015-12-02 16:38 4% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Yuanhan Liu @ 2015-12-02 14:31 UTC (permalink / raw)
To: Panu Matilainen, Thomas Monjalon
Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On Wed, Dec 02, 2015 at 03:53:45PM +0200, Panu Matilainen wrote:
> On 12/02/2015 05:43 AM, Yuanhan Liu wrote:
> >VHOST_USER_SET_LOG_BASE request is used to tell the backend (dpdk
> >vhost-user) where we should log dirty pages, and how big the log
> >buffer is.
> >
> >This request introduces a new payload:
> >
> > typedef struct VhostUserLog {
> > uint64_t mmap_size;
> > uint64_t mmap_offset;
> > } VhostUserLog;
> >
> >Also, a fd is delivered from QEMU by ancillary data.
> >
> >With those info given, an area of memory is mmaped, assigned
> >to dev->log_base, for logging dirty pages.
> >
> >Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> >---
> > lib/librte_vhost/rte_virtio_net.h | 2 ++
> > lib/librte_vhost/vhost_user/vhost-net-user.c | 7 ++++-
> > lib/librte_vhost/vhost_user/vhost-net-user.h | 6 ++++
> > lib/librte_vhost/vhost_user/virtio-net-user.c | 44 +++++++++++++++++++++++++++
> > lib/librte_vhost/vhost_user/virtio-net-user.h | 1 +
> > 5 files changed, 59 insertions(+), 1 deletion(-)
> >
> >diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
> >index 5687452..416dac2 100644
> >--- a/lib/librte_vhost/rte_virtio_net.h
> >+++ b/lib/librte_vhost/rte_virtio_net.h
> >@@ -127,6 +127,8 @@ struct virtio_net {
> > #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
> > char ifname[IF_NAME_SZ]; /**< Name of the tap device or socket path. */
> > uint32_t virt_qp_nb; /**< number of queue pair we have allocated */
> >+ uint64_t log_size; /**< Size of log area */
> >+ uint8_t *log_base; /**< Where dirty pages are logged */
> > void *priv; /**< private context */
> > struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
> > } __rte_cache_aligned;
>
> This (and other changes in patch 2 breaks the librte_vhost ABI
> again, so you'd need to at least add a deprecation note to 2.2 to be
> able to do it in 2.3 at all according to the ABI policy.
I was thinking that adding a new field (instead of renaming it or
removing it) isn't an ABI break. So, I was wrong?
>
> Perhaps a better option would be adding some padding to the structs
> now for 2.2 since the vhost ABI is broken there anyway. That would
> at least give a chance to keep it compatible from 2.2 to 2.3.
It will not be compatible, unless we add exact same fields (not
something like uint8_t pad[xx]). Otherwise, the pad field renaming
is also an ABI break, right?
Thomas, should I write an ABI deprecation note? Can I make it for
v2.2 release If I make one tomorrow? (Sorry that I'm not awared
of that it would be an ABI break).
--yliu
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 13:13 0% ` Jianbo Liu
@ 2015-12-02 14:34 3% ` Jerin Jacob
2015-12-02 16:40 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2015-12-02 14:34 UTC (permalink / raw)
To: Jianbo Liu; +Cc: dev
On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > On Wed, Dec 02, 2015 at 05:49:41PM +0800, Jianbo Liu wrote:
> >> On 2 December 2015 at 16:03, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> >> > On Wed, Dec 02, 2015 at 02:54:52PM +0800, Jianbo Liu wrote:
> >> >> On 2 December 2015 at 00:41, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> >> >> > On Tue, Dec 01, 2015 at 01:41:15PM -0500, Jianbo Liu wrote:
> >> >> >> Adds ARM NEON support for lpm.
> >> >> >> And enables table/pipeline libraries which depend on lpm.
> >> >> >
> >> >> > I already sent the patch on the same yesterday.
> >> >> > We can converge the patches after the discussion.
> >> >> > Please check "[dpdk-dev] [PATCH 0/3] add lpm support for NEON" on ml
> >> >> >
> >> >> Yes, I have read your patch. But there are many differences, so I sent
> >> >> mine for your reviewing :)
> >> >>
> >> >> >
> >> >> >>
> >> >> >> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
> >> >> >> ---
> >> >> >> config/defconfig_arm-armv7a-linuxapp-gcc | 3 -
> >> >> >> config/defconfig_arm64-armv8a-linuxapp-gcc | 3 -
> >> >> >> lib/librte_eal/common/include/arch/arm/rte_vect.h | 28 ++++++++++
> >> >> >> lib/librte_lpm/rte_lpm.h | 68 ++++++++++++++++-------
> >> >> >> 4 files changed, 77 insertions(+), 25 deletions(-)
> >> >> >>
> >> >> >> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc
> >> >> >> index cbebd64..efffa1f 100644
> >> >> >> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> >> >> >> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> >> >> >> @@ -53,9 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n
> >> >> >> CONFIG_RTE_EAL_IGB_UIO=n
> >> >> >>
> >> >> >> # fails to compile on ARM
> >> >> >> -CONFIG_RTE_LIBRTE_LPM=n
> >> >> >> -CONFIG_RTE_LIBRTE_TABLE=n
> >> >> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
> >> >> >> CONFIG_RTE_SCHED_VECTOR=n
> >> >> >>
> >> >> >> # cannot use those on ARM
> >> >> >> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> >> >> >> index 504f3ed..57f7941 100644
> >> >> >> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> >> >> >> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> >> >> >> @@ -51,7 +51,4 @@ CONFIG_RTE_LIBRTE_IVSHMEM=n
> >> >> >> CONFIG_RTE_LIBRTE_FM10K_PMD=n
> >> >> >> CONFIG_RTE_LIBRTE_I40E_PMD=n
> >> >> >>
> >> >> >> -CONFIG_RTE_LIBRTE_LPM=n
> >> >> >> -CONFIG_RTE_LIBRTE_TABLE=n
> >> >> >> -CONFIG_RTE_LIBRTE_PIPELINE=n
> >> >> >> CONFIG_RTE_SCHED_VECTOR=n
> >> >> >> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> >> >> >> index a33c054..7437711 100644
> >> >> >> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> >> >> >> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> >> >> >> @@ -41,6 +41,8 @@ extern "C" {
> >> >> >>
> >> >> >> typedef int32x4_t xmm_t;
> >> >> >>
> >> >> >> +typedef int32x4_t __m128i;
> >> >> >> +
> >> >> >> #define XMM_SIZE (sizeof(xmm_t))
> >> >> >> #define XMM_MASK (XMM_SIZE - 1)
> >> >> >>
> >> >> >> @@ -53,6 +55,32 @@ typedef union rte_xmm {
> >> >> >> double pd[XMM_SIZE / sizeof(double)];
> >> >> >> } __attribute__((aligned(16))) rte_xmm_t;
> >> >> >>
> >> >> >> +static __inline __m128i
> >> >> >> +_mm_set_epi32(int i3, int i2, int i1, int i0)
> >> >> >> +{
> >> >> >> + int32_t r[4] = {i0, i1, i2, i3};
> >> >> >> +
> >> >> >> + return vld1q_s32(r);
> >> >> >> +}
> >> >> >> +
> >> >> >> +static __inline __m128i
> >> >> >> +_mm_loadu_si128(__m128i *p)
> >> >> >> +{
> >> >> >> + return vld1q_s32((int32_t *)p);
> >> >> >> +}
> >> >> >> +
> >> >> >> +static __inline __m128i
> >> >> >> +_mm_set1_epi32(int i)
> >> >> >> +{
> >> >> >> + return vdupq_n_s32(i);
> >> >> >> +}
> >> >> >> +
> >> >> >> +static __inline __m128i
> >> >> >> +_mm_and_si128(__m128i a, __m128i b)
> >> >> >> +{
> >> >> >> + return vandq_s32(a, b);
> >> >> >> +}
> >> >> >> +
> >> >
> >> > IMO, it's not always good to emulate GCC defined intrinsics of
> >> > other architecture. What if a legacy DPDK application has such mappings
> >> > then BOOM, multiple definition, which one is correct? which one
> >> > to comment it out? Integration pain starts for DPDK library consumer:-(
> >> >
> >> They can include rte_vect.h in build/include directly, which is linked correctly
> >> to the one for that ARCH, so there is no need to worry about.
> >
> > I think you missed the point,I was trying to say that
> > legacy DPDK application and third party stacks uses SSE2NEON kind of
> > libraries
> > for quick integration, for example, something like this
> > https://github.com/jratcliff63367/sse2neon/blob/master/SSE2NEON.h
> >
> > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > that lead to multiple definition and its not good.
> >
> But you will have similar issue since "typedef int32x4_t __m128i"
> appears in both your patch and this header file.
I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
is fine(unlike inline function).
my intention to keep __m128i "as is" because changing the __m128i to rte_???
something would break the ABI.
>
> >>
> >>
> >> >> >
> >> >> > IMO, it makes sense to not emulate the SSE intrinsics with NEON
> >> >> > Let's create the rte_vect_* as required. look at the existing patch.
> >> >> >
> >> >> I thought of creating a layer of SIMD over all the platforms before.
> >> >> But can't you see it make things complicated, considering there are
> >> >> only few simple intrinsic to implement?
> >> >
> >> > Not true, There were, a lot of SSE intrinsics needs be to emulated for ACL NEON
> >> > implementation if I were to take this approach and emulation comes with
> >> > the cost.
> >> >
> >> No, I will not re-implement all the intrinsic like that .
> >> I only do with the simple intrinsic, such as load/store, as you said below.
> >
> > but you forced to add _mm_and_si128 also to the list and emulated
> > _mm_and_si128 intrinsic. Am just saying no emulation.
> >
> I means simple intrinsic, not load/store only.
> Depends on how you define emulation. Actually, these simple intrisinic
> could be only one NEON instruction, and will not bring cost.
>
> >
> >>
> >> > So my take is,
> >> > lets the each architecture implementation for specific SIMD version of DPDK
> >> > API in the library should have the freedom to implement the API in
> >> > NATIVE.
> >> >
> >> > And let's create only rte_vect_* abstraction only for using
> >> > that API/library. Which boils down to have very minimal rte_vect_*
> >> > abstraction to load, store, set not beyond that.
> >> >
> >> > This makes clear "contract" between DPDK library and the applications.
> >> > and make easy for remaning new architecture porting effort in DPDK.
> >> >
> >> Agree.
> >> But I reuse existing intrinsic names, and you recreate new ones.
> >> And I try to do as few changes as possible, and try to avoid any
> >> mistaken which may cause code un-compiled.
> >
> > Its trival to verify. Just compile it
> >
> >> I think it's design level question, we need to hear what others talk about it.
> >>
> >> > Imagine how your proposed function will look like if new architecture
> >> > wants to implement "optimized" version of rte_lpm_lookupx4
> >> >
> >> There is no optimization for this (simple) rte_lpm_lookupx4, otherwise
> >> you have done that in your patch.
> >> If there is for other new platform, defintely they should do like
> >> yours, as you did for NEON ACL.
> >>
> >> >
> >> >> If do so, we also need to explain to others how to use these interfaces.
> >> >> Besides, this patch did the smallest changes to the original code, and
> >> >> more likely to be accepted by others.
> >> >
> >> > other patch makes no changes to IA version of rte_lpm_lookupx4.I thought
> >> > that make reviewer easy to review the changes in architecture
> >> > perspective.
> >> >
> >> As I know, they don't enable LPM for PPC, and ARM is the first one to
> >> touch this issue.
> >>
> >> >>
> >> >> >
> >> >> >> #ifdef RTE_ARCH_ARM
> >> >> >> /* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */
> >> >> >> static __inline uint8x16_t
> >> >> >> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
> >> >> >> index c299ce2..c76c07d 100644
> >> >> >> --- a/lib/librte_lpm/rte_lpm.h
> >> >> >> +++ b/lib/librte_lpm/rte_lpm.h
> >> >> >> @@ -361,6 +361,47 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
> >> >> >> /* Mask four results. */
> >> >> >> #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff)
> >> >> >>
> >> >> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> >> >> >
> >> >> > Separate out arm implementation to the different header file.
> >> >> > Too many ifdef looks odd in the header file and difficult to manage.
> >> >> >
> >> >> But there are many ifdefs already.
> >> >> And It seems unreasonable to add a new file only for one small function.
> >> >>
> >> >
> >> > small or big, its matter of each architecture to have
> >> > the freedom for the optimized version for the implementation.
> >> >
> >> > What if other architecture demands to write this function in assembly
> >> > or restructure it for performance improvement?
> >> >
> >> If there is such demands, should do like that.
> >> But I don't see any restructure in your patch, and you still follow
> >> the logic as x86, is it worth adding a new file?
> >
> > SIMD Logic on getting 4 indexes for tbl24[] is different.
> >
> > /* get 4 indexes for tbl24[]. */
> > i24 = _mm_srli_epi32(ip, CHAR_BIT);
> >
> > /* extract values from tbl24[] */
> > idx = _mm_cvtsi128_si64(i24);
> > i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> >
> > tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> > tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >
> > idx = _mm_cvtsi128_si64(i24);
> >
> > tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> > tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >
> > VS
> >
> > /* extract values from tbl24[] */
> > idx = vgetq_lane_u64((uint64x2_t)i24, 0);
> >
> > tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> > tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >
> > idx = vgetq_lane_u64((uint64x2_t)i24, 1);
> >
> > tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> > tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >
> It's only the optimazation of part of code in that function. I did the
> similar in my patch.
> But, looking from the whole, this function is not restructured, and
> the logic is the same as x86.
>
> >>
> >> >
> >> >> >
> >> >> >> +static inline void
> >> >> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t tbl[4])
> >> >> >> +{
> >> >> >> + uint32x4_t i24;
> >> >> >> + uint32_t idx[4];
> >> >> >> +
> >> >> >> + /* get 4 indexes for tbl24[]. */
> >> >> >> + i24 = vshrq_n_u32(vreinterpretq_u32_s32(ip), CHAR_BIT);
> >> >> >> + vst1q_u32(idx, i24);
> >> >> >> +
> >> >> >> + /* extract values from tbl24[] */
> >> >> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[idx[0]];
> >> >> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx[1]];
> >> >> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[idx[2]];
> >> >> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx[3]];
> >> >> >> +}
> >> >> >
> >> >> > Nice. There is an improvement in this portion code wrt my patch. This is
> >> >> > a candidate for convergence.
> >> >> >
> >> >> >
> >> >> >> +#else
> >> >> >> +static inline void
> >> >> >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, __m128i ip, uint16_t tbl[4])
> >> >> >> +{
> >> >> >> + __m128i i24;
> >> >> >> + uint64_t idx;
> >> >> >> +
> >> >> >> + /* get 4 indexes for tbl24[]. */
> >> >> >> + i24 = _mm_srli_epi32(ip, CHAR_BIT);
> >> >> >> +
> >> >> >> + /* extract values from tbl24[] */
> >> >> >> + idx = _mm_cvtsi128_si64(i24);
> >> >> >> + i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> >> >> >> +
> >> >> >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> >> >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> >> >> +
> >> >> >> + idx = _mm_cvtsi128_si64(i24);
> >> >> >> +
> >> >> >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> >> >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> >> >> +}
> >> >> >> +#endif
> >> >> >> +
> >> >> >> /**
> >> >> >> * Lookup four IP addresses in an LPM table.
> >> >> >> *
> >> >> >> @@ -381,17 +422,19 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips,
> >> >> >> * if lookup would fail.
> >> >> >> */
> >> >> >> static inline void
> >> >> >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> >> >> >> +rte_lpm_lookupx4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t hop[4],
> >> >> >> + uint16_t defv)
> >> >> >
> >> >> > This would call for change in the change the ABI,
> >> >> > IMO, __m128i can be used to represent 128bit vector to avoid ABI chang
> >> >> >
> >> >> This redefine rte_lpm_lookupx4 is unncessary, I will remove it, so no
> >> >> ABI change.
> >> >> And there only one ifdef for ARM platforms left.
> >> >>
> >> >> >
> >> >> >> +#else
> >> >> > separate out arm implementation to the different header file. Too many
> >> >> > ifdef looks odd in the header file.
> >> >> >
> >> >> > Could you rebase your patch based on existing patch and send the
> >> >> > improvement portion as separate patch or I can send update patch with
> >> >> > your improvements and with your signoff.
> >> >> >
> >> >> >
> >> >> >> rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
> >> >> >> uint16_t defv)
> >> >> >> +#endif
> >> >> >> {
> >> >> >> - __m128i i24;
> >> >> >> rte_xmm_t i8;
> >> >> >> uint16_t tbl[4];
> >> >> >> - uint64_t idx, pt;
> >> >> >> -
> >> >> >> - const __m128i mask8 =
> >> >> >> - _mm_set_epi32(UINT8_MAX, UINT8_MAX, UINT8_MAX, UINT8_MAX);
> >> >> >> + uint64_t pt;
> >> >> >>
> >> >> >> + const __m128i mask8 = _mm_set1_epi32(UINT8_MAX);
> >> >> >> /*
> >> >> >> * RTE_LPM_VALID_EXT_ENTRY_BITMASK for 4 LPM entries
> >> >> >> * as one 64-bit value (0x0300030003000300).
> >> >> >> @@ -412,20 +455,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
> >> >> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 32 |
> >> >> >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 48);
> >> >> >>
> >> >> >> - /* get 4 indexes for tbl24[]. */
> >> >> >> - i24 = _mm_srli_epi32(ip, CHAR_BIT);
> >> >> >> -
> >> >> >> - /* extract values from tbl24[] */
> >> >> >> - idx = _mm_cvtsi128_si64(i24);
> >> >> >> - i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> >> >> >> -
> >> >> >> - tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> >> >> - tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> >> >> -
> >> >> >> - idx = _mm_cvtsi128_si64(i24);
> >> >> >> -
> >> >> >> - tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
> >> >> >> - tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
> >> >> >> + rte_lpm_tbl24_val4(lpm, ip, tbl);
> >> >> >>
> >> >> >> /* get 4 indexes for tbl8[]. */
> >> >> >> i8.x = _mm_and_si128(ip, mask8);
> >> >> >> --
> >> >> >> 1.8.3.1
> >> >> >>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 14:31 5% ` Yuanhan Liu
@ 2015-12-02 14:48 4% ` Panu Matilainen
2015-12-02 15:09 0% ` Yuanhan Liu
2015-12-02 16:38 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-02 14:48 UTC (permalink / raw)
To: Yuanhan Liu, Thomas Monjalon; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On 12/02/2015 04:31 PM, Yuanhan Liu wrote:
> On Wed, Dec 02, 2015 at 03:53:45PM +0200, Panu Matilainen wrote:
>> On 12/02/2015 05:43 AM, Yuanhan Liu wrote:
>>> VHOST_USER_SET_LOG_BASE request is used to tell the backend (dpdk
>>> vhost-user) where we should log dirty pages, and how big the log
>>> buffer is.
>>>
>>> This request introduces a new payload:
>>>
>>> typedef struct VhostUserLog {
>>> uint64_t mmap_size;
>>> uint64_t mmap_offset;
>>> } VhostUserLog;
>>>
>>> Also, a fd is delivered from QEMU by ancillary data.
>>>
>>> With those info given, an area of memory is mmaped, assigned
>>> to dev->log_base, for logging dirty pages.
>>>
>>> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
>>> ---
>>> lib/librte_vhost/rte_virtio_net.h | 2 ++
>>> lib/librte_vhost/vhost_user/vhost-net-user.c | 7 ++++-
>>> lib/librte_vhost/vhost_user/vhost-net-user.h | 6 ++++
>>> lib/librte_vhost/vhost_user/virtio-net-user.c | 44 +++++++++++++++++++++++++++
>>> lib/librte_vhost/vhost_user/virtio-net-user.h | 1 +
>>> 5 files changed, 59 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
>>> index 5687452..416dac2 100644
>>> --- a/lib/librte_vhost/rte_virtio_net.h
>>> +++ b/lib/librte_vhost/rte_virtio_net.h
>>> @@ -127,6 +127,8 @@ struct virtio_net {
>>> #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
>>> char ifname[IF_NAME_SZ]; /**< Name of the tap device or socket path. */
>>> uint32_t virt_qp_nb; /**< number of queue pair we have allocated */
>>> + uint64_t log_size; /**< Size of log area */
>>> + uint8_t *log_base; /**< Where dirty pages are logged */
>>> void *priv; /**< private context */
>>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
>>> } __rte_cache_aligned;
>>
>> This (and other changes in patch 2 breaks the librte_vhost ABI
>> again, so you'd need to at least add a deprecation note to 2.2 to be
>> able to do it in 2.3 at all according to the ABI policy.
>
> I was thinking that adding a new field (instead of renaming it or
> removing it) isn't an ABI break. So, I was wrong?
Adding or removing a field in the middle of a public struct is always an
ABI break. Adding to the end often is too, but not always.
Renaming a field is an API break but not an ABI break - the compiler
cares but the cpu does not.
>>
>> Perhaps a better option would be adding some padding to the structs
>> now for 2.2 since the vhost ABI is broken there anyway. That would
>> at least give a chance to keep it compatible from 2.2 to 2.3.
>
> It will not be compatible, unless we add exact same fields (not
> something like uint8_t pad[xx]). Otherwise, the pad field renaming
> is also an ABI break, right?
There's no ABI (or API) break in changing reserved unused fields to
something else, as long as care is taken with sizes and alignment. In
any case padding is best added to the end of a struct to minimize risks
and keep things simple.
- Panu -
>
> Thomas, should I write an ABI deprecation note? Can I make it for
> v2.2 release If I make one tomorrow? (Sorry that I'm not awared
> of that it would be an ABI break).
>
> --yliu
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/3] eal: introduce rte_vect_* abstractions
2015-12-02 13:43 3% ` Jan Viktorin
@ 2015-12-02 14:51 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2015-12-02 14:51 UTC (permalink / raw)
To: Jan Viktorin; +Cc: dev
On Wed, Dec 02, 2015 at 02:43:34PM +0100, Jan Viktorin wrote:
> On Mon, 30 Nov 2015 22:54:11 +0530
> Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
>
> > introduce rte_vect_* abstractions to remove SSE/AVX specific
> > code in the common code(i.e the test applications)
> >
> > The patch does not provide any functional change for IA, the goal is to
>
> Does IA mean Intel Architecture?
Yes.
>
> > have infrastructure to reuse the common vector-based test code across
> > all the architectures.
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> > lib/librte_eal/common/include/arch/arm/rte_vect.h | 17 ++++++++++++++++-
> > lib/librte_eal/common/include/arch/x86/rte_vect.h | 8 ++++++++
> > 2 files changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> > index 21cdb4d..d300951 100644
> > --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> > +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> > @@ -33,13 +33,14 @@
> > #ifndef _RTE_VECT_ARM_H_
> > #define _RTE_VECT_ARM_H_
> >
> > -#include "arm_neon.h"
> > +#include <arm_neon.h>
> >
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> >
> > typedef int32x4_t xmm_t;
> > +typedef int32x4_t __m128i;
>
> As Jianbo pointed out recently, the __m128i type should be refactored in
> a general rte_vect API too. If we do something like
>
> #if SSE
> typedef __m128i rte_128i;
> #elif NEON
> typedef int32x4_y rte_128i;
> #endif
>
> does it make somebody angry? I am afraid that it will influence a lot of
> code. However, from the ABI point of view, it is OK, isn't it?
>
> >
> > #define XMM_SIZE (sizeof(xmm_t))
> > #define XMM_MASK (XMM_SIZE - 1)
> > @@ -53,6 +54,20 @@ typedef union rte_xmm {
> > double pd[XMM_SIZE / sizeof(double)];
> > } __attribute__((aligned(16))) rte_xmm_t;
> >
> > +/* rte_vect_* abstraction implementation using NEON */
> > +
> > +/* loads the __m128i value from address p(does not need to be 16-byte aligned)*/
> > +#define rte_vect_loadu_sil128(p) vld1q_s32((const int32_t *)p)
> > +
> > +/* sets the 4 signed 32-bit integer values and returns the __m128i variable */
> > +static inline __m128i __attribute__((always_inline))
> > +rte_vect_set_epi32(int i3, int i2, int i1, int i0)
> > +{
> > + int32_t data[4] = {i0, i1, i2, i3};
> > +
> > + return vld1q_s32(data);
> > +}
> > +
> > #ifdef __cplusplus
> > }
> > #endif
> > diff --git a/lib/librte_eal/common/include/arch/x86/rte_vect.h b/lib/librte_eal/common/include/arch/x86/rte_vect.h
> > index b698797..91c6523 100644
> > --- a/lib/librte_eal/common/include/arch/x86/rte_vect.h
> > +++ b/lib/librte_eal/common/include/arch/x86/rte_vect.h
> > @@ -125,6 +125,14 @@ typedef union rte_ymm {
> > })
> > #endif /* (defined(__ICC) && __ICC < 1210) */
> >
> > +/* rte_vect_* abstraction implementation using SSE */
> > +
> > +/* loads the __m128i value from address p(does not need to be 16-byte aligned)*/
> > +#define rte_vect_loadu_sil128(p) _mm_loadu_si128(p)
> > +
> > +/* sets the 4 signed 32-bit integer values and returns the __m128i variable */
> > +#define rte_vect_set_epi32(i3, i2, i1, i0) _mm_set_epi32(i3, i2, i1, i0)
> > +
> > #ifdef __cplusplus
> > }
> > #endif
>
> I like this approach. It is a question whether to inherit names from
> SSE. However, why to reinvent the wheel...
>
> We probably need other people to give their ideas about such
> generalization of the API.
Yes, I would like get the feedback from other people.
ret_vect_* abstraction only for the common code (i.e test code) which
typically used to call the SIMD DPDK API's across the architecture.
>
> I think, there should be an autotest of the rte_vect API. Is it
> possible to create one?
Yes
>
> Regards
> Jan
>
> --
> Jan Viktorin E-mail: Viktorin@RehiveTech.com
> System Architect Web: www.RehiveTech.com
> RehiveTech
> Brno, Czech Republic
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 14:48 4% ` Panu Matilainen
@ 2015-12-02 15:09 0% ` Yuanhan Liu
2015-12-02 16:58 0% ` Panu Matilainen
0 siblings, 1 reply; 200+ results
From: Yuanhan Liu @ 2015-12-02 15:09 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On Wed, Dec 02, 2015 at 04:48:14PM +0200, Panu Matilainen wrote:
...
> >>>diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
> >>>index 5687452..416dac2 100644
> >>>--- a/lib/librte_vhost/rte_virtio_net.h
> >>>+++ b/lib/librte_vhost/rte_virtio_net.h
> >>>@@ -127,6 +127,8 @@ struct virtio_net {
> >>> #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
> >>> char ifname[IF_NAME_SZ]; /**< Name of the tap device or socket path. */
> >>> uint32_t virt_qp_nb; /**< number of queue pair we have allocated */
> >>>+ uint64_t log_size; /**< Size of log area */
> >>>+ uint8_t *log_base; /**< Where dirty pages are logged */
> >>> void *priv; /**< private context */
> >>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
> >>> } __rte_cache_aligned;
> >>
> >>This (and other changes in patch 2 breaks the librte_vhost ABI
> >>again, so you'd need to at least add a deprecation note to 2.2 to be
> >>able to do it in 2.3 at all according to the ABI policy.
> >
> >I was thinking that adding a new field (instead of renaming it or
> >removing it) isn't an ABI break. So, I was wrong?
>
> Adding or removing a field in the middle of a public struct is
> always an ABI break. Adding to the end often is too, but not always.
> Renaming a field is an API break but not an ABI break - the compiler
> cares but the cpu does not.
Good to know. Thanks.
>
> >>
> >>Perhaps a better option would be adding some padding to the structs
> >>now for 2.2 since the vhost ABI is broken there anyway. That would
> >>at least give a chance to keep it compatible from 2.2 to 2.3.
> >
> >It will not be compatible, unless we add exact same fields (not
> >something like uint8_t pad[xx]). Otherwise, the pad field renaming
> >is also an ABI break, right?
>
> There's no ABI (or API) break in changing reserved unused fields to
> something else, as long as care is taken with sizes and alignment.
as long as we don't reference the reserved unused fields?
> In any case padding is best added to the end of a struct to minimize
> risks and keep things simple.
The thing is that isn't it a bit aweful to (always) add pads to
the end of a struct, especially when you don't know how many
need to be padded?
--yliu
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 14:31 5% ` Yuanhan Liu
2015-12-02 14:48 4% ` Panu Matilainen
@ 2015-12-02 16:38 4% ` Thomas Monjalon
2015-12-03 1:49 0% ` Yuanhan Liu
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-02 16:38 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
2015-12-02 22:31, Yuanhan Liu:
> Thomas, should I write an ABI deprecation note? Can I make it for
> v2.2 release If I make one tomorrow? (Sorry that I'm not awared
> of that it would be an ABI break).
As Panu suggested, it would be better to reserve some room now
in 2.2 which already breaks vhost ABI.
Maybe we have a chance to keep the same vhost ABI in 2.3.
The 2.2 release will probably be closed in less than 2 weeks.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 14:34 3% ` Jerin Jacob
@ 2015-12-02 16:40 0% ` Thomas Monjalon
2015-12-02 16:53 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-02 16:40 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
2015-12-02 20:04, Jerin Jacob:
> On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > that lead to multiple definition and its not good.
> > >
> > But you will have similar issue since "typedef int32x4_t __m128i"
> > appears in both your patch and this header file.
>
> I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> is fine(unlike inline function).
>
> my intention to keep __m128i "as is" because changing the __m128i to rte_???
> something would break the ABI.
Isn't it already broken in 2.2?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/3] rte_sched: eliminate floating point in calculating byte clock
2015-11-29 18:46 3% ` [dpdk-dev] [PATCH 3/3] rte_sched: eliminate floating point in calculating byte clock Stephen Hemminger
@ 2015-12-02 16:48 0% ` Dumitrescu, Cristian
2015-12-02 22:08 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Dumitrescu, Cristian @ 2015-12-02 16:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Sunday, November 29, 2015 8:47 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>
> Subject: [PATCH 3/3] rte_sched: eliminate floating point in calculating byte
> clock
>
> The old code was doing a floating point divide for each rte_dequeue()
> which is very expensive. Change to using fixed point scaled inverse
> multiply. To maintain equivalent precision, scaled math is used.
> The application ABI is the same.
>
> This improved performance from 5Gbit/sec to 10 Gbit/sec when configured
> for 10 Gbit/sec rate.
>
> There was some feedback from Cristian that he wanted a better
> solution and was going to give one, but none was provided.
> For 2.2 this is a better solution than existing code, if someone
> has a better version I would love to see it.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> lib/librte_sched/rte_sched.c | 23 ++++++++++++++++++-----
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> index 16acd6b..cfae136 100644
> --- a/lib/librte_sched/rte_sched.c
> +++ b/lib/librte_sched/rte_sched.c
> @@ -47,6 +47,7 @@
> #include "rte_bitmap.h"
> #include "rte_sched_common.h"
> #include "rte_approx.h"
> +#include "rte_reciprocal.h"
>
> #ifdef __INTEL_COMPILER
> #pragma warning(disable:2259) /* conversion may lose significant bits */
> @@ -62,6 +63,11 @@
> #define RTE_SCHED_PIPE_INVALID UINT32_MAX
> #define RTE_SCHED_BMP_POS_INVALID UINT32_MAX
>
> +/* Scaling for cycles_per_byte calculation
> + * Chosen so that minimum rate is 480 bit/sec
> + */
> +#define RTE_SCHED_TIME_SHIFT 8
Stephen, can you please elaborate why we need to shift the dividend at all and why the shift value was picked as 8? Is 8 a hard constraint? How does this affect the scheduling precision/accuracy?
> +
> struct rte_sched_subport {
> /* Token bucket (TB) */
> uint64_t tb_time; /* time of last update */
> @@ -215,7 +221,7 @@ struct rte_sched_port {
> uint64_t time_cpu_cycles; /* Current CPU time measured in CPU
> cyles */
> uint64_t time_cpu_bytes; /* Current CPU time measured in bytes
> */
> uint64_t time; /* Current NIC TX time measured in bytes */
> - double cycles_per_byte; /* CPU cycles per byte */
> + struct rte_reciprocal inv_cycles_per_byte; /* CPU cycles per byte */
>
> /* Scheduling loop detection */
> uint32_t pipe_loop;
> @@ -610,7 +616,7 @@ struct rte_sched_port *
> rte_sched_port_config(struct rte_sched_port_params *params)
> {
> struct rte_sched_port *port = NULL;
> - uint32_t mem_size, bmp_mem_size, n_queues_per_port, i;
> + uint32_t mem_size, bmp_mem_size, n_queues_per_port, i,
> cycles_per_byte;
>
> /* Check user parameters. Determine the amount of memory to
> allocate */
> mem_size = rte_sched_port_get_memory_footprint(params);
> @@ -661,7 +667,10 @@ rte_sched_port_config(struct
> rte_sched_port_params *params)
> port->time_cpu_cycles = rte_get_tsc_cycles();
> port->time_cpu_bytes = 0;
> port->time = 0;
> - port->cycles_per_byte = ((double) rte_get_tsc_hz()) / ((double)
> params->rate);
> +
> + cycles_per_byte = (rte_get_tsc_hz() << RTE_SCHED_TIME_SHIFT)
> + / params->rate;
> + port->inv_cycles_per_byte = rte_reciprocal_value(cycles_per_byte);
>
> /* Scheduling loop detection */
> port->pipe_loop = RTE_SCHED_PIPE_INVALID;
> @@ -2088,11 +2097,15 @@ rte_sched_port_time_resync(struct
> rte_sched_port *port)
> {
> uint64_t cycles = rte_get_tsc_cycles();
> uint64_t cycles_diff = cycles - port->time_cpu_cycles;
> - double bytes_diff = ((double) cycles_diff) / port->cycles_per_byte;
> + uint64_t bytes_diff;
> +
> + /* Compute elapsed time in bytes */
> + bytes_diff = rte_reciprocal_divide(cycles_diff <<
> RTE_SCHED_TIME_SHIFT,
> + port->inv_cycles_per_byte);
>
> /* Advance port time */
> port->time_cpu_cycles = cycles;
> - port->time_cpu_bytes += (uint64_t) bytes_diff;
> + port->time_cpu_bytes += bytes_diff;
> if (port->time < port->time_cpu_bytes)
> port->time = port->time_cpu_bytes;
>
> --
> 2.1.4
Can you provide some insight into how you tested this code and the test vectors you used?
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
@ 2015-12-02 16:50 36% Panu Matilainen
2015-12-02 18:23 4% ` Neil Horman
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Panu Matilainen @ 2015-12-02 16:50 UTC (permalink / raw)
To: dev
In addition to git tags, support validating abi between any legal
gitrevisions(7) syntaxes, such as "validate-abi.sh . -1 <target>"
"validate-abi.sh master mybrach <target>" etc in addition to
validating between tags. Makes it easier to run the validator
for in-development work.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
---
scripts/validate-abi.sh | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
index 4476433..0e3ccd7 100755
--- a/scripts/validate-abi.sh
+++ b/scripts/validate-abi.sh
@@ -43,16 +43,15 @@ log() {
}
validate_tags() {
- git tag -l | grep -q "$TAG1"
- if [ $? -ne 0 ]
+
+ if [ -z "$HASH1" ]
then
- echo "$TAG1 is invalid"
+ echo "invalid revision: $TAG1"
return
fi
- git tag -l | grep -q "$TAG2"
- if [ $? -ne 0 ]
+ if [ -z "$HASH2" ]
then
- echo "$TAG2 is invalid"
+ echo "invalid revision: $TAG2"
return
fi
}
@@ -112,6 +111,9 @@ then
cleanup_and_exit 1
fi
+HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null)
+HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null)
+
# Make sure our tags exist
res=$(validate_tags)
if [ -n "$res" ]
@@ -120,6 +122,10 @@ then
cleanup_and_exit 1
fi
+# Make hashes available in output for non-local reference
+TAG1="$TAG1 ($HASH1)"
+TAG2="$TAG2 ($HASH2)"
+
ABICHECK=`which abi-compliance-checker 2>/dev/null`
if [ $? -ne 0 ]
then
@@ -152,7 +158,7 @@ cd $(dirname $0)/..
log "INFO" "Checking out version $TAG1 of the dpdk"
# Move to the old version of the tree
-git checkout $TAG1
+git checkout $HASH1
# Make sure we configure SHARED libraries
# Also turn off IGB and KNI as those require kernel headers to build
@@ -185,7 +191,7 @@ cd $TARGET/lib
log "INFO" "COLLECTING ABI INFORMATION FOR $TAG1"
for i in `ls *.so`
do
- $ABIDUMP $i -o $ABI_DIR/$i-ABI-0.dump -lver $TAG1
+ $ABIDUMP $i -o $ABI_DIR/$i-ABI-0.dump -lver $HASH1
done
cd ../..
@@ -194,7 +200,7 @@ git clean -f -d
git reset --hard
# Move to the new version of the tree
log "INFO" "Checking out version $TAG2 of the dpdk"
-git checkout $TAG2
+git checkout $HASH2
# Make sure we configure SHARED libraries
# Also turn off IGB and KNI as those require kernel headers to build
@@ -220,7 +226,7 @@ cd $TARGET/lib
log "INFO" "COLLECTING ABI INFORMATION FOR $TAG2"
for i in `ls *.so`
do
- $ABIDUMP $i -o $ABI_DIR/$i-ABI-1.dump -lver $TAG2
+ $ABIDUMP $i -o $ABI_DIR/$i-ABI-1.dump -lver $HASH2
done
cd ../..
--
2.5.0
^ permalink raw reply [relevance 36%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 16:40 0% ` Thomas Monjalon
@ 2015-12-02 16:53 0% ` Jerin Jacob
2015-12-02 16:57 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2015-12-02 16:53 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> 2015-12-02 20:04, Jerin Jacob:
> > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > that lead to multiple definition and its not good.
> > > >
> > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > appears in both your patch and this header file.
> >
> > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > is fine(unlike inline function).
> >
> > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > something would break the ABI.
>
> Isn't it already broken in 2.2?
Does it mean, You would like to have rte_128i(or similar) kind of
abstraction to represent 128bit SIMD variable in DPDK?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 15:09 0% ` Yuanhan Liu
@ 2015-12-02 16:58 0% ` Panu Matilainen
2015-12-02 17:24 3% ` Michael S. Tsirkin
0 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-02 16:58 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On 12/02/2015 05:09 PM, Yuanhan Liu wrote:
> On Wed, Dec 02, 2015 at 04:48:14PM +0200, Panu Matilainen wrote:
> ...
>>>>> diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
>>>>> index 5687452..416dac2 100644
>>>>> --- a/lib/librte_vhost/rte_virtio_net.h
>>>>> +++ b/lib/librte_vhost/rte_virtio_net.h
>>>>> @@ -127,6 +127,8 @@ struct virtio_net {
>>>>> #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
>>>>> char ifname[IF_NAME_SZ]; /**< Name of the tap device or socket path. */
>>>>> uint32_t virt_qp_nb; /**< number of queue pair we have allocated */
>>>>> + uint64_t log_size; /**< Size of log area */
>>>>> + uint8_t *log_base; /**< Where dirty pages are logged */
>>>>> void *priv; /**< private context */
>>>>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
>>>>> } __rte_cache_aligned;
>>>>
>>>> This (and other changes in patch 2 breaks the librte_vhost ABI
>>>> again, so you'd need to at least add a deprecation note to 2.2 to be
>>>> able to do it in 2.3 at all according to the ABI policy.
>>>
>>> I was thinking that adding a new field (instead of renaming it or
>>> removing it) isn't an ABI break. So, I was wrong?
>>
>> Adding or removing a field in the middle of a public struct is
>> always an ABI break. Adding to the end often is too, but not always.
>> Renaming a field is an API break but not an ABI break - the compiler
>> cares but the cpu does not.
>
> Good to know. Thanks.
>
>>
>>>>
>>>> Perhaps a better option would be adding some padding to the structs
>>>> now for 2.2 since the vhost ABI is broken there anyway. That would
>>>> at least give a chance to keep it compatible from 2.2 to 2.3.
>>>
>>> It will not be compatible, unless we add exact same fields (not
>>> something like uint8_t pad[xx]). Otherwise, the pad field renaming
>>> is also an ABI break, right?
>>
>> There's no ABI (or API) break in changing reserved unused fields to
>> something else, as long as care is taken with sizes and alignment.
>
> as long as we don't reference the reserved unused fields?
That would be the definition of an unused field I think :)
Call it "reserved" if you want, it doesn't really matter as long as its
clear its something you shouldn't be using.
>
>> In any case padding is best added to the end of a struct to minimize
>> risks and keep things simple.
>
> The thing is that isn't it a bit aweful to (always) add pads to
> the end of a struct, especially when you don't know how many
> need to be padded?
Then you pad for what you think you need, plus a bit extra, and maybe
some more for others who might want to extend it. What is a reasonable
amount needs deciding case by case - if a struct is alloced in the
millions then be (very) conservative, but if there are one or 50 such
structs within an app lifetime then who cares if its bit larger?
And yeah padding may be annoying, but that's pretty much the only option
in a project where most of the structs are out in the open.
- Panu -
>
> --yliu
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 16:53 0% ` Jerin Jacob
@ 2015-12-02 16:57 3% ` Thomas Monjalon
2015-12-02 17:38 0% ` Jerin Jacob
2015-12-03 9:33 0% ` Jerin Jacob
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2015-12-02 16:57 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
2015-12-02 22:23, Jerin Jacob:
> On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > 2015-12-02 20:04, Jerin Jacob:
> > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > that lead to multiple definition and its not good.
> > > > >
> > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > appears in both your patch and this header file.
> > >
> > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > is fine(unlike inline function).
> > >
> > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > something would break the ABI.
> >
> > Isn't it already broken in 2.2?
>
> Does it mean, You would like to have rte_128i(or similar) kind of
> abstraction to represent 128bit SIMD variable in DPDK?
If you are convinced that it is the best way to write a generic code, yes.
I think the most important question is to know what is the best solution
for performance and maintainability. The API/ABI questions will be considered
after.
Thanks for your involvement guys.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 16:58 0% ` Panu Matilainen
@ 2015-12-02 17:24 3% ` Michael S. Tsirkin
0 siblings, 0 replies; 200+ results
From: Michael S. Tsirkin @ 2015-12-02 17:24 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev, Victor Kaplansky
On Wed, Dec 02, 2015 at 06:58:03PM +0200, Panu Matilainen wrote:
> On 12/02/2015 05:09 PM, Yuanhan Liu wrote:
> >On Wed, Dec 02, 2015 at 04:48:14PM +0200, Panu Matilainen wrote:
> >...
> >>>>>diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
> >>>>>index 5687452..416dac2 100644
> >>>>>--- a/lib/librte_vhost/rte_virtio_net.h
> >>>>>+++ b/lib/librte_vhost/rte_virtio_net.h
> >>>>>@@ -127,6 +127,8 @@ struct virtio_net {
> >>>>> #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
> >>>>> char ifname[IF_NAME_SZ]; /**< Name of the tap device or socket path. */
> >>>>> uint32_t virt_qp_nb; /**< number of queue pair we have allocated */
> >>>>>+ uint64_t log_size; /**< Size of log area */
> >>>>>+ uint8_t *log_base; /**< Where dirty pages are logged */
> >>>>> void *priv; /**< private context */
> >>>>> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
> >>>>> } __rte_cache_aligned;
> >>>>
> >>>>This (and other changes in patch 2 breaks the librte_vhost ABI
> >>>>again, so you'd need to at least add a deprecation note to 2.2 to be
> >>>>able to do it in 2.3 at all according to the ABI policy.
> >>>
> >>>I was thinking that adding a new field (instead of renaming it or
> >>>removing it) isn't an ABI break. So, I was wrong?
> >>
> >>Adding or removing a field in the middle of a public struct is
> >>always an ABI break. Adding to the end often is too, but not always.
> >>Renaming a field is an API break but not an ABI break - the compiler
> >>cares but the cpu does not.
> >
> >Good to know. Thanks.
> >
> >>
> >>>>
> >>>>Perhaps a better option would be adding some padding to the structs
> >>>>now for 2.2 since the vhost ABI is broken there anyway. That would
> >>>>at least give a chance to keep it compatible from 2.2 to 2.3.
> >>>
> >>>It will not be compatible, unless we add exact same fields (not
> >>>something like uint8_t pad[xx]). Otherwise, the pad field renaming
> >>>is also an ABI break, right?
> >>
> >>There's no ABI (or API) break in changing reserved unused fields to
> >>something else, as long as care is taken with sizes and alignment.
> >
> >as long as we don't reference the reserved unused fields?
>
> That would be the definition of an unused field I think :)
> Call it "reserved" if you want, it doesn't really matter as long as its
> clear its something you shouldn't be using.
>
> >
> >>In any case padding is best added to the end of a struct to minimize
> >>risks and keep things simple.
> >
> >The thing is that isn't it a bit aweful to (always) add pads to
> >the end of a struct, especially when you don't know how many
> >need to be padded?
>
> Then you pad for what you think you need, plus a bit extra, and maybe some
> more for others who might want to extend it. What is a reasonable amount
> needs deciding case by case - if a struct is alloced in the millions then be
> (very) conservative, but if there are one or 50 such structs within an app
> lifetime then who cares if its bit larger?
>
> And yeah padding may be annoying, but that's pretty much the only option in
> a project where most of the structs are out in the open.
>
> - Panu -
Functions versioning is another option.
For a sufficiently widely used struct, it's a lot of work, padding
is easier. But it might be better than breaking ABI
if e.g. you didn't pad enough.
> >
> > --yliu
> >
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 16:57 3% ` Thomas Monjalon
@ 2015-12-02 17:38 0% ` Jerin Jacob
2015-12-03 9:33 0% ` Jerin Jacob
1 sibling, 0 replies; 200+ results
From: Jerin Jacob @ 2015-12-02 17:38 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Wed, Dec 02, 2015 at 05:57:10PM +0100, Thomas Monjalon wrote:
> 2015-12-02 22:23, Jerin Jacob:
> > On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > > 2015-12-02 20:04, Jerin Jacob:
> > > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > > that lead to multiple definition and its not good.
> > > > > >
> > > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > > appears in both your patch and this header file.
> > > >
> > > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > > is fine(unlike inline function).
> > > >
> > > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > > something would break the ABI.
> > >
> > > Isn't it already broken in 2.2?
> >
> > Does it mean, You would like to have rte_128i(or similar) kind of
> > abstraction to represent 128bit SIMD variable in DPDK?
>
> If you are convinced that it is the best way to write a generic code, yes.
> I think the most important question is to know what is the best solution
> for performance and maintainability. The API/ABI questions will be considered
IMO, a true portable platform-independent library may need rte_128i kind
of abstracttion to represent a 128bit SIMD variable. I can send an RFC
patch to see the changes required across the DPDK.
> after.
>
> Thanks for your involvement guys.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-02 16:50 36% [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range Panu Matilainen
@ 2015-12-02 18:23 4% ` Neil Horman
2015-12-03 12:14 29% ` Mcnamara, John
2015-12-03 14:05 36% ` [dpdk-dev] [PATCH v2] " Panu Matilainen
2 siblings, 0 replies; 200+ results
From: Neil Horman @ 2015-12-02 18:23 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
On Wed, Dec 02, 2015 at 06:50:47PM +0200, Panu Matilainen wrote:
> In addition to git tags, support validating abi between any legal
> gitrevisions(7) syntaxes, such as "validate-abi.sh . -1 <target>"
> "validate-abi.sh master mybrach <target>" etc in addition to
> validating between tags. Makes it easier to run the validator
> for in-development work.
>
> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 3/3] rte_sched: eliminate floating point in calculating byte clock
2015-12-02 16:48 0% ` Dumitrescu, Cristian
@ 2015-12-02 22:08 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2015-12-02 22:08 UTC (permalink / raw)
To: Dumitrescu, Cristian; +Cc: dev
On Wed, 2 Dec 2015 16:48:17 +0000
"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com> wrote:
>
>
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Sunday, November 29, 2015 8:47 PM
> > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> > Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>
> > Subject: [PATCH 3/3] rte_sched: eliminate floating point in calculating byte
> > clock
> >
> > The old code was doing a floating point divide for each rte_dequeue()
> > which is very expensive. Change to using fixed point scaled inverse
> > multiply. To maintain equivalent precision, scaled math is used.
> > The application ABI is the same.
> >
> > This improved performance from 5Gbit/sec to 10 Gbit/sec when configured
> > for 10 Gbit/sec rate.
> >
> > There was some feedback from Cristian that he wanted a better
> > solution and was going to give one, but none was provided.
> > For 2.2 this is a better solution than existing code, if someone
> > has a better version I would love to see it.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
> > lib/librte_sched/rte_sched.c | 23 ++++++++++++++++++-----
> > 1 file changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> > index 16acd6b..cfae136 100644
> > --- a/lib/librte_sched/rte_sched.c
> > +++ b/lib/librte_sched/rte_sched.c
> > @@ -47,6 +47,7 @@
> > #include "rte_bitmap.h"
> > #include "rte_sched_common.h"
> > #include "rte_approx.h"
> > +#include "rte_reciprocal.h"
> >
> > #ifdef __INTEL_COMPILER
> > #pragma warning(disable:2259) /* conversion may lose significant bits */
> > @@ -62,6 +63,11 @@
> > #define RTE_SCHED_PIPE_INVALID UINT32_MAX
> > #define RTE_SCHED_BMP_POS_INVALID UINT32_MAX
> >
> > +/* Scaling for cycles_per_byte calculation
> > + * Chosen so that minimum rate is 480 bit/sec
> > + */
> > +#define RTE_SCHED_TIME_SHIFT 8
>
> Stephen, can you please elaborate why we need to shift the dividend at all and why the shift value was picked as 8? Is 8 a hard constraint? How does this affect the scheduling precision/accuracy?
The shift value is a tradeoff for scaled math. The bigger the shift
the finer the resolution, but at the risk of overflow in the cycles_per_byte.
The value was chosen as a tradeoff based on current CPU clock rate (TSC)
and minimum rate.
> > +
> > struct rte_sched_subport {
> > /* Token bucket (TB) */
> > uint64_t tb_time; /* time of last update */
> > @@ -215,7 +221,7 @@ struct rte_sched_port {
> > uint64_t time_cpu_cycles; /* Current CPU time measured in CPU
> > cyles */
> > uint64_t time_cpu_bytes; /* Current CPU time measured in bytes
> > */
> > uint64_t time; /* Current NIC TX time measured in bytes */
> > - double cycles_per_byte; /* CPU cycles per byte */
> > + struct rte_reciprocal inv_cycles_per_byte; /* CPU cycles per byte */
> >
> > /* Scheduling loop detection */
> > uint32_t pipe_loop;
> > @@ -610,7 +616,7 @@ struct rte_sched_port *
> > rte_sched_port_config(struct rte_sched_port_params *params)
> > {
> > struct rte_sched_port *port = NULL;
> > - uint32_t mem_size, bmp_mem_size, n_queues_per_port, i;
> > + uint32_t mem_size, bmp_mem_size, n_queues_per_port, i,
> > cycles_per_byte;
> >
> > /* Check user parameters. Determine the amount of memory to
> > allocate */
> > mem_size = rte_sched_port_get_memory_footprint(params);
> > @@ -661,7 +667,10 @@ rte_sched_port_config(struct
> > rte_sched_port_params *params)
> > port->time_cpu_cycles = rte_get_tsc_cycles();
> > port->time_cpu_bytes = 0;
> > port->time = 0;
> > - port->cycles_per_byte = ((double) rte_get_tsc_hz()) / ((double)
> > params->rate);
> > +
> > + cycles_per_byte = (rte_get_tsc_hz() << RTE_SCHED_TIME_SHIFT)
> > + / params->rate;
> > + port->inv_cycles_per_byte = rte_reciprocal_value(cycles_per_byte);
> >
> > /* Scheduling loop detection */
> > port->pipe_loop = RTE_SCHED_PIPE_INVALID;
> > @@ -2088,11 +2097,15 @@ rte_sched_port_time_resync(struct
> > rte_sched_port *port)
> > {
> > uint64_t cycles = rte_get_tsc_cycles();
> > uint64_t cycles_diff = cycles - port->time_cpu_cycles;
> > - double bytes_diff = ((double) cycles_diff) / port->cycles_per_byte;
> > + uint64_t bytes_diff;
> > +
> > + /* Compute elapsed time in bytes */
> > + bytes_diff = rte_reciprocal_divide(cycles_diff <<
> > RTE_SCHED_TIME_SHIFT,
> > + port->inv_cycles_per_byte);
> >
> > /* Advance port time */
> > port->time_cpu_cycles = cycles;
> > - port->time_cpu_bytes += (uint64_t) bytes_diff;
> > + port->time_cpu_bytes += bytes_diff;
> > if (port->time < port->time_cpu_bytes)
> > port->time = port->time_cpu_bytes;
> >
> > --
> > 2.1.4
>
> Can you provide some insight into how you tested this code and the test vectors you used?
We tested with 10 gbit link and range of rates from 10k bit up to 10 gbit.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
@ 2015-12-03 1:22 4% Ferruh Yigit
2015-12-03 1:36 4% ` Thomas Monjalon
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Ferruh Yigit @ 2015-12-03 1:22 UTC (permalink / raw)
To: dev
Fixes following error (observed when versioning macros used):
LD libdpdk.so
/usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
for symbol <function>@DPDK_x.y
Also resulting combined library contains symbol version information:
$ readelf -a build/lib/libdpdk.so | grep rte_eal_ | grep @ | head
<...> GLOBAL DEFAULT 12 rte_eal_alarm_set@@DPDK_2.0
<...> GLOBAL DEFAULT 12 rte_eal_pci_write_config@@DPDK_2.1
<...> GLOBAL DEFAULT 12 rte_eal_remote_launch@@DPDK_2.0
...
Versioning fixed by merging all version scripts into one automatically and
feeding it to final library.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
drivers/net/Makefile | 3 +++
lib/Makefile | 3 +++
mk/rte.sdkbuild.mk | 2 +-
mk/rte.sharelib.mk | 3 +++
scripts/merge_maps.sh | 29 +++++++++++++++++++++++++++++
5 files changed, 39 insertions(+), 1 deletion(-)
create mode 100755 scripts/merge_maps.sh
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index cddcd57..d3c865b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -51,5 +51,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
+ifeq ($(COMBINED_BUILD),1)
include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/lib/Makefile b/lib/Makefile
index ef172ea..d0f7fb8 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -64,5 +64,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
endif
+ifeq ($(COMBINED_BUILD),1)
include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 38ec7bd..d4e3abf 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -94,7 +94,7 @@ $(ROOTDIRS-y):
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
@if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
- $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
+ COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
fi
%_clean:
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
index 7bb7219..76ead09 100644
--- a/mk/rte.sharelib.mk
+++ b/mk/rte.sharelib.mk
@@ -40,6 +40,8 @@ LIB_ONE := lib$(RTE_LIBNAME).so
else
LIB_ONE := lib$(RTE_LIBNAME).a
endif
+COMBINED_MAP=$(BUILDDIR)/lib/libdpdk.map
+CPU_LDFLAGS += --version-script=$(COMBINED_MAP)
endif
.PHONY:sharelib
@@ -79,6 +81,7 @@ ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
$(LIB_ONE): FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
+ @$(SRCDIR)/scripts/merge_maps.sh > $(COMBINED_MAP)
$(O_TO_S_DO)
else
$(LIB_ONE): FORCE
diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
new file mode 100755
index 0000000..bc40dc8
--- /dev/null
+++ b/scripts/merge_maps.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
+SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
+
+first=0
+prev_sym="none"
+
+for s in $SYMBOLS; do
+ echo "$s {"
+ echo " global:"
+ echo ""
+ for f in $FILES; do
+ sed -n "/$s {/,/}/p" $f | sed '/^$/d' | grep -v global | grep -v local | sed '1d' | sed '$d'
+ done | sort -u
+ echo ""
+ if [ $first -eq 0 ]; then
+ first=1;
+ echo " local: *;";
+ fi
+ if [ "$prev_sym" == "none" ]; then
+ echo "};";
+ prev_sym=$s;
+ else
+ echo "} $prev_sym;";
+ prev_sym=$s;
+ fi
+ echo ""
+done
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
2015-12-02 11:44 3% ` Neil Horman
@ 2015-12-03 1:31 0% ` Ferruh Yigit
2015-12-03 8:11 3% ` Christian Ehrhardt
2015-12-03 14:59 0% ` Neil Horman
0 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2015-12-03 1:31 UTC (permalink / raw)
To: Neil Horman; +Cc: dev
On Wed, Dec 02, 2015 at 06:44:19AM -0500, Neil Horman wrote:
> On Tue, Dec 01, 2015 at 12:37:37PM +0000, Robie Basak wrote:
> > Re-sending this unsigned since the ML rejected my signed email.
> >
> > -1 from Ubuntu without further discussion since it will break us. Please
> > don't commit this patch yet.
> >
> > I don't understand why we must have the complexity of so many shared
> > libraries. From a distribution packaging perspective, all I see is that
> > this multiplies potential work by twenty times and makes it awkward to
> > work with without special tooling (which then needs maintaining).
> >
> Theres nothing "complex" about the simple fact that a project builds lots of
> libraries. Its extreemely common. Any graphic window manager has exactly the
> same situation, as do any number of tools that have multiple hardware backends
> impelmented in user space (v4l, sane, iptables, to name just a few).
>
> > Before I go into details, it would be nice if someone could please
> > explain why DPDK has to be "special" in needing to do this? I don't
> Its not special, see above. Not saying the build environment cant be improved,
> but the fact that there are multiple libraries is pretty straightforward.
>
> > understand why DPDK must be different to every other userspace library
> > out there. If DPDK has a good need to be different then that's fair
> > enough. But I feel that if DPDK is deviating from the norm then we need
> > to frame the discussion from the perspective of "why DPDK must be
> > different", rather than having me trying to explain why the norm is the
> > right way to do it.
> >
> > On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
> > > That's how Fedora and RHEL are shipping it already and nobody has so much
> > > as noticed anything strange, much less complained about it. 20 libraries
> > > is but a drop in the ocean on a average distro.
> >
> > No, it is 20 times the work from the perspective of DPDK package
> > maintenance. Let me explain why.
> >
> > In Debian and Ubuntu, we manage a library transition (an ABI bump in a
> > library together with all dependencies moving to use the new ABI) by
> > concurrently packaging both the old and new libraries at once. This
> > works well with the norm for libraries. We ship one binary package per
> > soname, with the major version as part of the package name. This allows
> > a system to have two (or more) ABIs installed simultaneously. For a
> > library transition, we just package the new version and then that can
> > land and work concurrently as we then individually update every
> > dependent (library-consuming) package.
> So thats, a distribution choice, not an upstream problem. And it seems like a
> problem you should have already solved (note the examples above). If you feel
> like you need to package multiple ABI versions in the same library, you can,
> just update the LIBABIVER of all the libraries, instead of the ones that truly
> change, so that each library is guaranteed a newer so version, to make the
> library file name unique. Yes you have to make a small change from upstream,
> but thats part of the work that distribution maintainers do.
>
>
> > This works because of conventions around sonames, which DPDK breaks
> > unless we treat it as twenty different libraries which changes our work
> > from easy to painful.
> >
> > Usually a library transition is managed by hand by the package
> > maintainer. It's not taxing because it's straightforward and well
> > understood. Update and upload the new ABI source package, then find all
> > reverse dependencies and sort them out, recursively. But if the
> > maintainer must do it twenty times, then it becomes taxing and prone to
> > error. And if the reverse dependency tree differs depending on the split
> > library used by library consumers, then it gets far more complex to
> > follow.
> >
> > Admittedly we could tool around this to make it easier, but that's extra
> > work (both initially and in maintenance) and prone to error (because
> > we'd only be doing it for DPDK).
> >
> You must already have a solution to this, I can't imagine you package all the
> libraries for kde or gnome (or even pam) separately)
>
> > Packaging a library is usually virtually a no-op in Debian and Ubuntu
> > nowadays. Our tooling does it all for us. But packaging DPDK is far from
> > this currently because of all this added complexity. From my perspective
> > this is unnecessary and makes no sense. We could do all kinds of things
> > to work around it (that's what packaging is about) but then we'd have to
> > maintain that specialness and I don't see why it must be awkward like
> > this instead of just doing it the same way as every other library.
> >
> > > The combined library as it is simply is no longer a viable option.
> > > Besides just being broken (witness the strange hacks people are coming
> > > up with to work around issues in it) its ugly because it basically gives
> > > the middle finger to all the effort going into version compatibility,
> > > and its also big. Few projects will use every library in DPDK, but with
> > > the combined library they're forced to lug the 800 pound gorilla along
> > > needlessly.
> >
> > It's broken because it's broken upstream, and that's what we should fix.
> > Why is it not viable? How does it give the middle finger to effort going
> > into version compatibility?
> Because each individual library has a version script that gets applied during
> link to version symbols properly. Those scripts dont get applied when building
> the combined library.
>
>
> > Doing it the right way like every other
> > userspace library is what *gives us* version compatibility because then
> > distributions can straightforwardly install multiple ABI versions at
> > once.
> Again, Not at all uncommon. You're packaging methodology is the issue here,
> not the fact that there are multiple libraries.
>
> > Finally, I fail to see any "lug the 800 pound gorilla along" saving. We
> > (Ubuntu and Fedora) are both shipping all the libraries in one package,
> > whether split or combined, so they are all being lugged onto disk
> > anyway. Whether split or combined, there is no saving there. And memory
> > is hardly saved either because the kernel will just page in and out what
> > is needed in both cases. So how does this proposed change give us any
> > saving at all?
> >
> Not true, initalization constructors for PMD's at the very least mean that every
> pmd will get paged in weather you want it or not using the combined library.
> Individual libraries let you dynamically load them (via dlopen). I think the
> same is true of several other facets of dpdk.
>
> Neil
>
I just sent a patch that fixes versioning in combined library, can you please check it: http://dpdk.org/dev/patchwork/patch/9259/
Thanks,
ferruh
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 1:22 4% [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library Ferruh Yigit
@ 2015-12-03 1:36 4% ` Thomas Monjalon
2015-12-03 1:59 4% ` Ferruh Yigit
2015-12-03 8:18 4% ` [dpdk-dev] [PATCH v2] " Christian Ehrhardt
2015-12-03 12:49 7% ` Panu Matilainen
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-03 1:36 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
Hi Ferruh,
Thanks for working on it.
2015-12-03 01:22, Ferruh Yigit:
> +ifeq ($(COMBINED_BUILD),1)
> include $(RTE_SDK)/mk/rte.sharelib.mk
> +endif
[...]
> @if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
> - $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
> + COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
What is it fixing?
The badly named sharelib is for combined build only.
[...]
> +FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
The build dir is not always "build/"
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] eal: don't crash if one pci device fails
@ 2015-12-03 1:38 3% Stephen Hemminger
2015-12-03 10:02 0% ` Bruce Richardson
2015-12-03 10:08 0% ` David Marchand
0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2015-12-03 1:38 UTC (permalink / raw)
To: dev
If there is a failure to setup one pci device, there maybe other
devices that can be initialized. Don't call rte_exit which
is a forced crash, pass the error back to the
application to decide what it wants to do.
Might be good idea to return a positive value for the
number of devices found, but that would break ABI.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/common/eal_common_pci.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_pci.c b/lib/librte_eal/common/eal_common_pci.c
index dcfe947..594ef9c 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -391,12 +391,13 @@ rte_eal_pci_probe(void)
struct rte_pci_device *dev = NULL;
struct rte_devargs *devargs;
int probe_all = 0;
- int ret = 0;
+ int failed = 0;
if (rte_eal_devargs_type_count(RTE_DEVTYPE_WHITELISTED_PCI) == 0)
probe_all = 1;
TAILQ_FOREACH(dev, &pci_device_list, next) {
+ int ret = 0;
/* set devargs in PCI structure */
devargs = pci_devargs_lookup(dev);
@@ -409,13 +410,17 @@ rte_eal_pci_probe(void)
else if (devargs != NULL &&
devargs->type == RTE_DEVTYPE_WHITELISTED_PCI)
ret = pci_probe_all_drivers(dev);
- if (ret < 0)
- rte_exit(EXIT_FAILURE, "Requested device " PCI_PRI_FMT
- " cannot be used\n", dev->addr.domain, dev->addr.bus,
- dev->addr.devid, dev->addr.function);
+
+ if (ret < 0) {
+ RTE_LOG(ERR, EAL,
+ "Requested device " PCI_PRI_FMT " cannot be used\n",
+ dev->addr.domain, dev->addr.bus,
+ dev->addr.devid, dev->addr.function);
+ failed = ret;
+ }
}
- return 0;
+ return failed;
}
/* dump one device */
--
2.1.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-02 16:38 4% ` Thomas Monjalon
@ 2015-12-03 1:49 0% ` Yuanhan Liu
0 siblings, 0 replies; 200+ results
From: Yuanhan Liu @ 2015-12-03 1:49 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Victor Kaplansky, Michael S. Tsirkin
On Wed, Dec 02, 2015 at 05:38:10PM +0100, Thomas Monjalon wrote:
> 2015-12-02 22:31, Yuanhan Liu:
> > Thomas, should I write an ABI deprecation note? Can I make it for
> > v2.2 release If I make one tomorrow? (Sorry that I'm not awared
> > of that it would be an ABI break).
>
> As Panu suggested, it would be better to reserve some room now
> in 2.2 which already breaks vhost ABI.
> Maybe we have a chance to keep the same vhost ABI in 2.3.
Got it. I will cook up one now.
--yliu
>
> The 2.2 release will probably be closed in less than 2 weeks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 1:36 4% ` Thomas Monjalon
@ 2015-12-03 1:59 4% ` Ferruh Yigit
2015-12-03 2:15 4% ` [dpdk-dev] [PATCH v3] " Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-12-03 1:59 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Thu, Dec 03, 2015 at 02:36:53AM +0100, Thomas Monjalon wrote:
> Hi Ferruh,
>
> Thanks for working on it.
>
> 2015-12-03 01:22, Ferruh Yigit:
> > +ifeq ($(COMBINED_BUILD),1)
> > include $(RTE_SDK)/mk/rte.sharelib.mk
> > +endif
> [...]
> > @if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
> > - $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
> > + COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
>
> What is it fixing?
> The badly named sharelib is for combined build only.
lib/Makefile and drivers/net/Makefile includes sharelib.mk _always_, this flag is to include sharelib.mk only when we are compiling combined library.
Previously this inclusion was not problem because there was not common variable, now we start using common CPU_LDFLAGS variable and sharedlib.mk shouldn't included when not compiling for combined lib.
>
> [...]
> > +FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
>
> The build dir is not always "build/"
>
Thanks, I will fix this and send a new patch, I assume I can rely on "*_version.map" naming convention.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v3] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 1:59 4% ` Ferruh Yigit
@ 2015-12-03 2:15 4% ` Ferruh Yigit
2015-12-03 2:22 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-12-03 2:15 UTC (permalink / raw)
To: dev
Fixes following error (observed when versioning macros used):
LD libdpdk.so
/usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
for symbol <function>@DPDK_x.y
Also resulting combined library contains symbol version information:
$ readelf -a build/lib/libdpdk.so | grep rte_eal_ | grep @ | head
<...> GLOBAL DEFAULT 12 rte_eal_alarm_set@@DPDK_2.0
<...> GLOBAL DEFAULT 12 rte_eal_pci_write_config@@DPDK_2.1
<...> GLOBAL DEFAULT 12 rte_eal_remote_launch@@DPDK_2.0
...
Versioning fixed by merging all version scripts into one automatically and
feeding it to final library.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
drivers/net/Makefile | 3 +++
lib/Makefile | 3 +++
mk/rte.sdkbuild.mk | 2 +-
mk/rte.sharelib.mk | 3 +++
scripts/merge_maps.sh | 29 +++++++++++++++++++++++++++++
5 files changed, 39 insertions(+), 1 deletion(-)
create mode 100755 scripts/merge_maps.sh
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index cddcd57..d3c865b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -51,5 +51,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
+ifeq ($(COMBINED_BUILD),1)
include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/lib/Makefile b/lib/Makefile
index ef172ea..d0f7fb8 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -64,5 +64,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
endif
+ifeq ($(COMBINED_BUILD),1)
include $(RTE_SDK)/mk/rte.sharelib.mk
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 38ec7bd..d4e3abf 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -94,7 +94,7 @@ $(ROOTDIRS-y):
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
@if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
- $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
+ COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
fi
%_clean:
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
index 7bb7219..76ead09 100644
--- a/mk/rte.sharelib.mk
+++ b/mk/rte.sharelib.mk
@@ -40,6 +40,8 @@ LIB_ONE := lib$(RTE_LIBNAME).so
else
LIB_ONE := lib$(RTE_LIBNAME).a
endif
+COMBINED_MAP=$(BUILDDIR)/lib/libdpdk.map
+CPU_LDFLAGS += --version-script=$(COMBINED_MAP)
endif
.PHONY:sharelib
@@ -79,6 +81,7 @@ ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
$(LIB_ONE): FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
+ @$(SRCDIR)/scripts/merge_maps.sh > $(COMBINED_MAP)
$(O_TO_S_DO)
else
$(LIB_ONE): FORCE
diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
new file mode 100755
index 0000000..4ace975
--- /dev/null
+++ b/scripts/merge_maps.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+FILES=$(find $RTE_SDK -name "*_version.map")
+SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
+
+first=0
+prev_sym="none"
+
+for s in $SYMBOLS; do
+ echo "$s {"
+ echo " global:"
+ echo ""
+ for f in $FILES; do
+ sed -n "/$s {/,/}/p" $f | sed '/^$/d' | grep -v global | grep -v local | sed '1d' | sed '$d'
+ done | sort -u
+ echo ""
+ if [ $first -eq 0 ]; then
+ first=1;
+ echo " local: *;";
+ fi
+ if [ "$prev_sym" == "none" ]; then
+ echo "};";
+ prev_sym=$s;
+ else
+ echo "} $prev_sym;";
+ prev_sym=$s;
+ fi
+ echo ""
+done
--
2.5.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] vhost: reserve some spaces for virtio_net and vhost_virtqueue struct
@ 2015-12-03 2:27 3% Yuanhan Liu
0 siblings, 0 replies; 200+ results
From: Yuanhan Liu @ 2015-12-03 2:27 UTC (permalink / raw)
To: dev; +Cc: Michael S. Tsirkin, Victor Kaplansky
So that we will not break ABI in future extension by adding few more
fields.
Struct vhost_virtqueue is reserved with 16 qwords (the later vhost-live
migration support would at least consume 3 of them), and struct virtio_net
is reserved with a bit more, 64 qwords, as there is only one instance for
a virtio nic instance.
Note that both reservation are not placed at the end of the struct, but
instead before the last field, since both the last field at the two struct
take a lot spaces. Putting the reservation after it would divide those
reserved fields to another cacheline. (we might need fix them in future, btw)
CC: Panu Matilainen <pmatilai@redhat.com>
CC: Thomas Monjalon <thomas.monjalon@6wind.com>
CC: Michael S. Tsirkin <mst@redhat.com>
CC: Victor Kaplansky <vkaplans@redhat.com>
Suggested-by: Panu Matilainen <pmatilai@redhat.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
---
Is the reservation a bit too large? :)
---
lib/librte_vhost/rte_virtio_net.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_vhost/rte_virtio_net.h b/lib/librte_vhost/rte_virtio_net.h
index 5687452..10dcb90 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -90,6 +90,7 @@ struct vhost_virtqueue {
int callfd; /**< Used to notify the guest (trigger interrupt). */
int kickfd; /**< Currently unused as polling mode is enabled. */
int enabled;
+ uint64_t reserved[16]; /**< Reserve some spaces for future extension. */
struct buf_vector buf_vec[BUF_VECTOR_MAX]; /**< for scatter RX. */
} __rte_cache_aligned;
@@ -128,6 +129,7 @@ struct virtio_net {
char ifname[IF_NAME_SZ]; /**< Name of the tap device or socket path. */
uint32_t virt_qp_nb; /**< number of queue pair we have allocated */
void *priv; /**< private context */
+ uint64_t reserved[64]; /**< Reserve some spaces for future extension. */
struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; /**< Contains all virtqueue information. */
} __rte_cache_aligned;
--
1.9.0
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 2:15 4% ` [dpdk-dev] [PATCH v3] " Ferruh Yigit
@ 2015-12-03 2:22 4% ` Thomas Monjalon
2015-12-03 11:24 4% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-03 2:22 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
2015-12-03 02:15, Ferruh Yigit:
> +ifeq ($(COMBINED_BUILD),1)
> include $(RTE_SDK)/mk/rte.sharelib.mk
> +endif
I still don't understand what was the issue with this include but it
seems not related to versioning.
Please condider a separate patch with a detailed explanation of the bug.
[...]
> +FILES=$(find $RTE_SDK -name "*_version.map")
No, we can have several build directories in RTE_SDK.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
2015-12-03 1:31 0% ` Ferruh Yigit
@ 2015-12-03 8:11 3% ` Christian Ehrhardt
2015-12-03 14:59 0% ` Neil Horman
1 sibling, 0 replies; 200+ results
From: Christian Ehrhardt @ 2015-12-03 8:11 UTC (permalink / raw)
To: Neil Horman, Robie Basak, dev
Hi Ferruh,
while not tackling the "soname for combined lib" which I felt to be
the center of all this discussion.
I like that with your patch the symbols in the combined lib are no
more anonymous, but versioned according to the maps the DPDK sub
libraries are maintaining anyway.
Some more technical feedback on your post.
I wonder if we would find a similar solution for the overall soname version.
Unfortunately all naive approaches that came to my mind so far
(summing up LIBABIVER, biggest of LIBABIVER, ...) all have all too
obvious faults.
And I didn't have time for a complex one yet.
I feel that - in favor of non-perfect, but simple solution - it might
be easier to carry one global LIBABIVER for the combined lib that is
increased on each DPDK release IF (very likely) one of the ABIs was
changed in the Release.
Something like a LIBABISUBVER could be increased on any release that
did change, but not break the old ABI.
Well, likely still too naive - I need more time to really get into all
that - like to better understand all the benefits and drawbacks of the
linker script approach.
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
On Thu, Dec 3, 2015 at 2:31 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> On Wed, Dec 02, 2015 at 06:44:19AM -0500, Neil Horman wrote:
>> On Tue, Dec 01, 2015 at 12:37:37PM +0000, Robie Basak wrote:
>> > Re-sending this unsigned since the ML rejected my signed email.
>> >
>> > -1 from Ubuntu without further discussion since it will break us. Please
>> > don't commit this patch yet.
>> >
>> > I don't understand why we must have the complexity of so many shared
>> > libraries. From a distribution packaging perspective, all I see is that
>> > this multiplies potential work by twenty times and makes it awkward to
>> > work with without special tooling (which then needs maintaining).
>> >
>> Theres nothing "complex" about the simple fact that a project builds lots of
>> libraries. Its extreemely common. Any graphic window manager has exactly the
>> same situation, as do any number of tools that have multiple hardware backends
>> impelmented in user space (v4l, sane, iptables, to name just a few).
>>
>> > Before I go into details, it would be nice if someone could please
>> > explain why DPDK has to be "special" in needing to do this? I don't
>> Its not special, see above. Not saying the build environment cant be improved,
>> but the fact that there are multiple libraries is pretty straightforward.
>>
>> > understand why DPDK must be different to every other userspace library
>> > out there. If DPDK has a good need to be different then that's fair
>> > enough. But I feel that if DPDK is deviating from the norm then we need
>> > to frame the discussion from the perspective of "why DPDK must be
>> > different", rather than having me trying to explain why the norm is the
>> > right way to do it.
>> >
>> > On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
>> > > That's how Fedora and RHEL are shipping it already and nobody has so much
>> > > as noticed anything strange, much less complained about it. 20 libraries
>> > > is but a drop in the ocean on a average distro.
>> >
>> > No, it is 20 times the work from the perspective of DPDK package
>> > maintenance. Let me explain why.
>> >
>> > In Debian and Ubuntu, we manage a library transition (an ABI bump in a
>> > library together with all dependencies moving to use the new ABI) by
>> > concurrently packaging both the old and new libraries at once. This
>> > works well with the norm for libraries. We ship one binary package per
>> > soname, with the major version as part of the package name. This allows
>> > a system to have two (or more) ABIs installed simultaneously. For a
>> > library transition, we just package the new version and then that can
>> > land and work concurrently as we then individually update every
>> > dependent (library-consuming) package.
>> So thats, a distribution choice, not an upstream problem. And it seems like a
>> problem you should have already solved (note the examples above). If you feel
>> like you need to package multiple ABI versions in the same library, you can,
>> just update the LIBABIVER of all the libraries, instead of the ones that truly
>> change, so that each library is guaranteed a newer so version, to make the
>> library file name unique. Yes you have to make a small change from upstream,
>> but thats part of the work that distribution maintainers do.
>>
>>
>> > This works because of conventions around sonames, which DPDK breaks
>> > unless we treat it as twenty different libraries which changes our work
>> > from easy to painful.
>> >
>> > Usually a library transition is managed by hand by the package
>> > maintainer. It's not taxing because it's straightforward and well
>> > understood. Update and upload the new ABI source package, then find all
>> > reverse dependencies and sort them out, recursively. But if the
>> > maintainer must do it twenty times, then it becomes taxing and prone to
>> > error. And if the reverse dependency tree differs depending on the split
>> > library used by library consumers, then it gets far more complex to
>> > follow.
>> >
>> > Admittedly we could tool around this to make it easier, but that's extra
>> > work (both initially and in maintenance) and prone to error (because
>> > we'd only be doing it for DPDK).
>> >
>> You must already have a solution to this, I can't imagine you package all the
>> libraries for kde or gnome (or even pam) separately)
>>
>> > Packaging a library is usually virtually a no-op in Debian and Ubuntu
>> > nowadays. Our tooling does it all for us. But packaging DPDK is far from
>> > this currently because of all this added complexity. From my perspective
>> > this is unnecessary and makes no sense. We could do all kinds of things
>> > to work around it (that's what packaging is about) but then we'd have to
>> > maintain that specialness and I don't see why it must be awkward like
>> > this instead of just doing it the same way as every other library.
>> >
>> > > The combined library as it is simply is no longer a viable option.
>> > > Besides just being broken (witness the strange hacks people are coming
>> > > up with to work around issues in it) its ugly because it basically gives
>> > > the middle finger to all the effort going into version compatibility,
>> > > and its also big. Few projects will use every library in DPDK, but with
>> > > the combined library they're forced to lug the 800 pound gorilla along
>> > > needlessly.
>> >
>> > It's broken because it's broken upstream, and that's what we should fix.
>> > Why is it not viable? How does it give the middle finger to effort going
>> > into version compatibility?
>> Because each individual library has a version script that gets applied during
>> link to version symbols properly. Those scripts dont get applied when building
>> the combined library.
>>
>>
>> > Doing it the right way like every other
>> > userspace library is what *gives us* version compatibility because then
>> > distributions can straightforwardly install multiple ABI versions at
>> > once.
>> Again, Not at all uncommon. You're packaging methodology is the issue here,
>> not the fact that there are multiple libraries.
>>
>> > Finally, I fail to see any "lug the 800 pound gorilla along" saving. We
>> > (Ubuntu and Fedora) are both shipping all the libraries in one package,
>> > whether split or combined, so they are all being lugged onto disk
>> > anyway. Whether split or combined, there is no saving there. And memory
>> > is hardly saved either because the kernel will just page in and out what
>> > is needed in both cases. So how does this proposed change give us any
>> > saving at all?
>> >
>> Not true, initalization constructors for PMD's at the very least mean that every
>> pmd will get paged in weather you want it or not using the combined library.
>> Individual libraries let you dynamically load them (via dlopen). I think the
>> same is true of several other facets of dpdk.
>>
>> Neil
>>
> I just sent a patch that fixes versioning in combined library, can you please check it: http://dpdk.org/dev/patchwork/patch/9259/
>
> Thanks,
> ferruh
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 1:22 4% [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library Ferruh Yigit
2015-12-03 1:36 4% ` Thomas Monjalon
@ 2015-12-03 8:18 4% ` Christian Ehrhardt
2015-12-03 11:18 4% ` Ferruh Yigit
2015-12-03 12:49 7% ` Panu Matilainen
2 siblings, 1 reply; 200+ results
From: Christian Ehrhardt @ 2015-12-03 8:18 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
Hi Ferruh,
some minor bash improvements that could be made in the next revision:
On Thu, Dec 3, 2015 at 2:22 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
> new file mode 100755
> index 0000000..bc40dc8
> --- /dev/null
> +++ b/scripts/merge_maps.sh
> @@ -0,0 +1,29 @@
> +#!/bin/sh
> +
> +FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
> +SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
Guarding $RTE_SDK and $FILES with "" will help avoid some potential
issues due to words splitting.
[...]
> + sed -n "/$s {/,/}/p" $f | sed '/^$/d' | grep -v global | grep -v local | sed '1d' | sed '$d'
As above with $f
[...]
> + if [ "$prev_sym" == "none" ]; then
Should be only one = as == is non standard and could fail in some environments.
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-02 16:57 3% ` Thomas Monjalon
2015-12-02 17:38 0% ` Jerin Jacob
@ 2015-12-03 9:33 0% ` Jerin Jacob
2015-12-03 11:02 3% ` Ananyev, Konstantin
1 sibling, 1 reply; 200+ results
From: Jerin Jacob @ 2015-12-03 9:33 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Wed, Dec 02, 2015 at 05:57:10PM +0100, Thomas Monjalon wrote:
> 2015-12-02 22:23, Jerin Jacob:
> > On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > > 2015-12-02 20:04, Jerin Jacob:
> > > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > > that lead to multiple definition and its not good.
> > > > > >
> > > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > > appears in both your patch and this header file.
> > > >
> > > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > > is fine(unlike inline function).
> > > >
> > > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > > something would break the ABI.
> > >
> > > Isn't it already broken in 2.2?
> >
> > Does it mean, You would like to have rte_128i(or similar) kind of
> > abstraction to represent 128bit SIMD variable in DPDK?
>
> If you are convinced that it is the best way to write a generic code, yes.
I grep-ed through DPDK API list to see the dependency with SIMD in API
definition.I see only rte_lpm_lookupx4 API has SIMD dependency in API
definition.
I believe that's the root cause of the problem. IMO, The
better way to fix this would be to remove __m128i from API and have more
general representation to remove the architecture dependency from API
something like this,
rte_lpm_lookupx4(const struct rte_lpm *lpm, uint32_t *ip, uint16_t
hop[4], uint16_t defv)
instead of
rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t
hop[4], uint16_t defv)
Now I am not sure why this API was created like this, from l3fwd.c
example, it looks to accommodate the IPV4 byte swap[1]. If it's true,
maybe we can have eal byte swap abstraction for optimized byte swap on
memory for 4 IP address in one shot
or
Have rte_lpm_lookupx4 take an argument for byte swap or not ?
or
something similar?
Thoughts ?
[1]
const __m128i bswap_mask = _mm_set_epi8(12, 13, 14, 15, 8, 9, 10, 11,
4, 5, 6, 7, 0, 1, 2, 3);
/* Byte swap 4 IPV4 addresses. */
dip = _mm_shuffle_epi8(dip, bswap_mask);
Jerin
> I think the most important question is to know what is the best solution
> for performance and maintainability. The API/ABI questions will be considered
> after.
>
> Thanks for your involvement guys.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: don't crash if one pci device fails
2015-12-03 1:38 3% [dpdk-dev] [PATCH] eal: don't crash if one pci device fails Stephen Hemminger
@ 2015-12-03 10:02 0% ` Bruce Richardson
2015-12-03 10:08 0% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2015-12-03 10:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Wed, Dec 02, 2015 at 05:38:40PM -0800, Stephen Hemminger wrote:
> If there is a failure to setup one pci device, there maybe other
> devices that can be initialized. Don't call rte_exit which
> is a forced crash, pass the error back to the
> application to decide what it wants to do.
>
> Might be good idea to return a positive value for the
> number of devices found, but that would break ABI.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The return value from this function gets passed back to rte_eal_init() where
it will still cause an application to terminate. Therefore, I think the
commit message is a little misleading.
Otherwise all looks ok to me. Will help weed out multiple device failures on
a single pass too.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: don't crash if one pci device fails
2015-12-03 1:38 3% [dpdk-dev] [PATCH] eal: don't crash if one pci device fails Stephen Hemminger
2015-12-03 10:02 0% ` Bruce Richardson
@ 2015-12-03 10:08 0% ` David Marchand
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2015-12-03 10:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Thu, Dec 3, 2015 at 2:38 AM, Stephen Hemminger <
stephen@networkplumber.org> wrote:
> If there is a failure to setup one pci device, there maybe other
> devices that can be initialized. Don't call rte_exit which
> is a forced crash, pass the error back to the
> application to decide what it wants to do.
>
> Might be good idea to return a positive value for the
> number of devices found, but that would break ABI.
>
I don't see how this return code will help the application do something
after this.
You don't know which device probe failed with just this.
rte_eal_pci_probe() returning a != 0 value will trigger a rte_panic in
rte_eal_init() anyway.
So I suppose you want to use rte_eal_pci_probe out of rte_eal_init.
In such a case, why don't you use rte_eal_pci_probe_one ?
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-03 9:33 0% ` Jerin Jacob
@ 2015-12-03 11:02 3% ` Ananyev, Konstantin
2015-12-03 12:17 3% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2015-12-03 11:02 UTC (permalink / raw)
To: Jerin Jacob, Thomas Monjalon; +Cc: dev
Hi Jerin,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> Sent: Thursday, December 03, 2015 9:34 AM
> To: Thomas Monjalon
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
>
> On Wed, Dec 02, 2015 at 05:57:10PM +0100, Thomas Monjalon wrote:
> > 2015-12-02 22:23, Jerin Jacob:
> > > On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > > > 2015-12-02 20:04, Jerin Jacob:
> > > > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > > > that lead to multiple definition and its not good.
> > > > > > >
> > > > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > > > appears in both your patch and this header file.
> > > > >
> > > > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > > > is fine(unlike inline function).
> > > > >
> > > > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > > > something would break the ABI.
> > > >
> > > > Isn't it already broken in 2.2?
> > >
> > > Does it mean, You would like to have rte_128i(or similar) kind of
> > > abstraction to represent 128bit SIMD variable in DPDK?
> >
> > If you are convinced that it is the best way to write a generic code, yes.
>
> I grep-ed through DPDK API list to see the dependency with SIMD in API
> definition.I see only rte_lpm_lookupx4 API has SIMD dependency in API
> definition.
>
> I believe that's the root cause of the problem. IMO, The
> better way to fix this would be to remove __m128i from API and have more
> general representation to remove the architecture dependency from API
>
> something like this,
>
> rte_lpm_lookupx4(const struct rte_lpm *lpm, uint32_t *ip, uint16_t
> hop[4], uint16_t defv)
>
> instead of
>
> rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t
> hop[4], uint16_t defv)
The idea for that function was that rte_lpm_lookupx4() accepts 4 IPv4 addresses that are:
1. already in 128bit register
2. 'prepared' - byte swap is already done for them if needed.
About ways to fix __m128i dependency: as I can see x86 and arm DPDK code
already has xmm_t typedef:
$ find lib -type f | xargs grep xmm_t | grep typedef
lib/librte_eal/common/include/arch/x86/rte_vect.h:typedef __m128i xmm_t;
lib/librte_eal/common/include/arch/arm/rte_vect.h:typedef int32x4_t xmm_t;
Why not to change rte_lpm_lookupx4() to accept xmm_t as input parameter.
As I understand it would solve the problem, and wouldn't introduce any API/ABI breakage, right?
Konstantin
>
> Now I am not sure why this API was created like this, from l3fwd.c
> example, it looks to accommodate the IPV4 byte swap[1]. If it's true,
> maybe we can have eal byte swap abstraction for optimized byte swap on
> memory for 4 IP address in one shot
>
> or
>
> Have rte_lpm_lookupx4 take an argument for byte swap or not ?
>
> or
>
> something similar?
>
> Thoughts ?
>
> [1]
> const __m128i bswap_mask = _mm_set_epi8(12, 13, 14, 15, 8, 9, 10, 11,
> 4, 5, 6, 7, 0, 1, 2, 3);
> /* Byte swap 4 IPV4 addresses. */
> dip = _mm_shuffle_epi8(dip, bswap_mask);
>
> Jerin
>
> > I think the most important question is to know what is the best solution
> > for performance and maintainability. The API/ABI questions will be considered
> > after.
> >
> > Thanks for your involvement guys.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 8:18 4% ` [dpdk-dev] [PATCH v2] " Christian Ehrhardt
@ 2015-12-03 11:18 4% ` Ferruh Yigit
2015-12-03 14:01 4% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2015-12-03 11:18 UTC (permalink / raw)
To: Christian Ehrhardt; +Cc: dev
On Thu, Dec 03, 2015 at 09:18:49AM +0100, Christian Ehrhardt wrote:
> Hi Ferruh,
> some minor bash improvements that could be made in the next revision:
>
> On Thu, Dec 3, 2015 at 2:22 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> > diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
> > new file mode 100755
> > index 0000000..bc40dc8
> > --- /dev/null
> > +++ b/scripts/merge_maps.sh
> > @@ -0,0 +1,29 @@
> > +#!/bin/sh
> > +
> > +FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
> > +SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
>
> Guarding $RTE_SDK and $FILES with "" will help avoid some potential
> issues due to words splitting.
>
> [...]
> > + sed -n "/$s {/,/}/p" $f | sed '/^$/d' | grep -v global | grep -v local | sed '1d' | sed '$d'
>
> As above with $f
>
> [...]
> > + if [ "$prev_sym" == "none" ]; then
>
> Should be only one = as == is non standard and could fail in some environments.
>
Thank you Christian, I will update accordingly.
Regards,
ferruh
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 2:22 4% ` Thomas Monjalon
@ 2015-12-03 11:24 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2015-12-03 11:24 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
On Thu, Dec 03, 2015 at 03:22:39AM +0100, Thomas Monjalon wrote:
> 2015-12-03 02:15, Ferruh Yigit:
> > +ifeq ($(COMBINED_BUILD),1)
> > include $(RTE_SDK)/mk/rte.sharelib.mk
> > +endif
>
> I still don't understand what was the issue with this include but it
> seems not related to versioning.
> Please condider a separate patch with a detailed explanation of the bug.
>
Indeed this is related to the using versioning macros VERSION_SYMBOL, BIND_DEFAULT_SYMBOL
But let me try to fix this in different way
> [...]
> > +FILES=$(find $RTE_SDK -name "*_version.map")
>
> No, we can have several build directories in RTE_SDK.
>
"grep -v" was to remove build output .map files, not searching for _version.map, so it should be OK
but let me narrow search path to lib and drivers folders to be safe
Thanks,
ferruh
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-02 16:50 36% [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range Panu Matilainen
2015-12-02 18:23 4% ` Neil Horman
@ 2015-12-03 12:14 29% ` Mcnamara, John
2015-12-03 13:28 4% ` Thomas Monjalon
2015-12-03 13:39 7% ` Panu Matilainen
2015-12-03 14:05 36% ` [dpdk-dev] [PATCH v2] " Panu Matilainen
2 siblings, 2 replies; 200+ results
From: Mcnamara, John @ 2015-12-03 12:14 UTC (permalink / raw)
To: Panu Matilainen, dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
> Sent: Wednesday, December 2, 2015 4:51 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] scripts: support any legal git revisions as
> abi validation range
>
> In addition to git tags, support validating abi between any legal
> gitrevisions(7) syntaxes, such as "validate-abi.sh . -1 <target>"
> "validate-abi.sh master mybrach <target>" etc in addition to validating
> between tags. Makes it easier to run the validator for in-development
> work.
Hi Panu,
+1 for this.
You might also change the ABI validation section of the docs to go along
with this. Something like the patch below. If not I'll submit it
afterwards.
Also, if someone has some bandwidth it would be good to add an option
to pass -j with an optional number to "make" in the script.
John
$ git diff
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 653c7d0..5ce5f9d 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -465,19 +465,23 @@ utilities which can be installed via a package manager. For example::
sudo yum install abi-compliance-checker
sudo yum install abi-dumper
+ sudo yum install greadelf
The syntax of the ``validate-abi.sh`` utility is::
- ./scripts/validate-abi.sh <TAG1> <TAG2> <TARGET>
+ ./scripts/validate-abi.sh <REV1> <REV2> <TARGET>
-Where ``TAG1`` and ``TAG2`` are valid git tags on the local repo and target is
-the usual DPDK compilation target.
+Where ``REV1`` and ``REV2`` are valid `gitrevisions(7)
+<https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html>`_ on the
+local repo and ``TARGET`` is the usual DPDK compilation target.
-For example to test the current committed HEAD against a previous release tag
-we could add a temporary tag and run the utility as follows::
+For example::
- git tag MY_TEMP_TAG
- ./scripts/validate-abi.sh v2.0.0 MY_TEMP_TAG x86_64-native-linuxapp-gcc
+ # Check between the previous and latest commits:
+ ./scripts/validate-abi.sh HEAD~1 HEAD x86_64-native-linuxapp-gcc
+
+ # Check between two tags:
+ ./scripts/validate-abi.sh v2.1.0 v2.2.0 x86_64-native-linuxapp-gcc
After the validation script completes (it can take a while since it need to
compile both tags) it will create compatibility reports in the
^ permalink raw reply [relevance 29%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-03 11:02 3% ` Ananyev, Konstantin
@ 2015-12-03 12:17 3% ` Jerin Jacob
2015-12-03 12:42 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2015-12-03 12:17 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
On Thu, Dec 03, 2015 at 11:02:07AM +0000, Ananyev, Konstantin wrote:
Hi Konstantin,
> Hi Jerin,
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > Sent: Thursday, December 03, 2015 9:34 AM
> > To: Thomas Monjalon
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
> >
> > On Wed, Dec 02, 2015 at 05:57:10PM +0100, Thomas Monjalon wrote:
> > > 2015-12-02 22:23, Jerin Jacob:
> > > > On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > > > > 2015-12-02 20:04, Jerin Jacob:
> > > > > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > > > > that lead to multiple definition and its not good.
> > > > > > > >
> > > > > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > > > > appears in both your patch and this header file.
> > > > > >
> > > > > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > > > > is fine(unlike inline function).
> > > > > >
> > > > > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > > > > something would break the ABI.
> > > > >
> > > > > Isn't it already broken in 2.2?
> > > >
> > > > Does it mean, You would like to have rte_128i(or similar) kind of
> > > > abstraction to represent 128bit SIMD variable in DPDK?
> > >
> > > If you are convinced that it is the best way to write a generic code, yes.
> >
> > I grep-ed through DPDK API list to see the dependency with SIMD in API
> > definition.I see only rte_lpm_lookupx4 API has SIMD dependency in API
> > definition.
> >
> > I believe that's the root cause of the problem. IMO, The
> > better way to fix this would be to remove __m128i from API and have more
> > general representation to remove the architecture dependency from API
> >
> > something like this,
> >
> > rte_lpm_lookupx4(const struct rte_lpm *lpm, uint32_t *ip, uint16_t
> > hop[4], uint16_t defv)
> >
> > instead of
> >
> > rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t
> > hop[4], uint16_t defv)
>
> The idea for that function was that rte_lpm_lookupx4() accepts 4 IPv4 addresses that are:
> 1. already in 128bit register
> 2. 'prepared' - byte swap is already done for them if needed.
>
> About ways to fix __m128i dependency: as I can see x86 and arm DPDK code
> already has xmm_t typedef:
>
> $ find lib -type f | xargs grep xmm_t | grep typedef
> lib/librte_eal/common/include/arch/x86/rte_vect.h:typedef __m128i xmm_t;
> lib/librte_eal/common/include/arch/arm/rte_vect.h:typedef int32x4_t xmm_t;
>
> Why not to change rte_lpm_lookupx4() to accept xmm_t as input parameter.
> As I understand it would solve the problem, and wouldn't introduce any API/ABI breakage, right?
Yes, If we have API/ABI breakage concerns.
IMO, Now this would call for some kind of rte_vect_* abstraction load,
store, set kind of SIMD operation on xmm_t in common test code to
aviod #ifdef's in app/test/test_lpm.c
I guess we may not need those abstractions in
lib/librte_eal/common/include/arch/ directory.
keeping in app/test/xmmt_ops.h should be enough, right?
>
> Konstantin
>
> >
> > Now I am not sure why this API was created like this, from l3fwd.c
> > example, it looks to accommodate the IPV4 byte swap[1]. If it's true,
> > maybe we can have eal byte swap abstraction for optimized byte swap on
> > memory for 4 IP address in one shot
> >
> > or
> >
> > Have rte_lpm_lookupx4 take an argument for byte swap or not ?
> >
> > or
> >
> > something similar?
> >
> > Thoughts ?
> >
> > [1]
> > const __m128i bswap_mask = _mm_set_epi8(12, 13, 14, 15, 8, 9, 10, 11,
> > 4, 5, 6, 7, 0, 1, 2, 3);
> > /* Byte swap 4 IPV4 addresses. */
> > dip = _mm_shuffle_epi8(dip, bswap_mask);
> >
> > Jerin
> >
> > > I think the most important question is to know what is the best solution
> > > for performance and maintainability. The API/ABI questions will be considered
> > > after.
> > >
> > > Thanks for your involvement guys.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-03 12:17 3% ` Jerin Jacob
@ 2015-12-03 12:42 0% ` Ananyev, Konstantin
2015-12-03 13:20 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2015-12-03 12:42 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Thursday, December 03, 2015 12:17 PM
> To: Ananyev, Konstantin
> Cc: Thomas Monjalon; dev@dpdk.org; viktorin@rehivetech.com
> Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
>
> On Thu, Dec 03, 2015 at 11:02:07AM +0000, Ananyev, Konstantin wrote:
>
> Hi Konstantin,
>
> > Hi Jerin,
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > Sent: Thursday, December 03, 2015 9:34 AM
> > > To: Thomas Monjalon
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
> > >
> > > On Wed, Dec 02, 2015 at 05:57:10PM +0100, Thomas Monjalon wrote:
> > > > 2015-12-02 22:23, Jerin Jacob:
> > > > > On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > > > > > 2015-12-02 20:04, Jerin Jacob:
> > > > > > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > > > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > > > > > that lead to multiple definition and its not good.
> > > > > > > > >
> > > > > > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > > > > > appears in both your patch and this header file.
> > > > > > >
> > > > > > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > > > > > is fine(unlike inline function).
> > > > > > >
> > > > > > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > > > > > something would break the ABI.
> > > > > >
> > > > > > Isn't it already broken in 2.2?
> > > > >
> > > > > Does it mean, You would like to have rte_128i(or similar) kind of
> > > > > abstraction to represent 128bit SIMD variable in DPDK?
> > > >
> > > > If you are convinced that it is the best way to write a generic code, yes.
> > >
> > > I grep-ed through DPDK API list to see the dependency with SIMD in API
> > > definition.I see only rte_lpm_lookupx4 API has SIMD dependency in API
> > > definition.
> > >
> > > I believe that's the root cause of the problem. IMO, The
> > > better way to fix this would be to remove __m128i from API and have more
> > > general representation to remove the architecture dependency from API
> > >
> > > something like this,
> > >
> > > rte_lpm_lookupx4(const struct rte_lpm *lpm, uint32_t *ip, uint16_t
> > > hop[4], uint16_t defv)
> > >
> > > instead of
> > >
> > > rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t
> > > hop[4], uint16_t defv)
> >
> > The idea for that function was that rte_lpm_lookupx4() accepts 4 IPv4 addresses that are:
> > 1. already in 128bit register
> > 2. 'prepared' - byte swap is already done for them if needed.
> >
> > About ways to fix __m128i dependency: as I can see x86 and arm DPDK code
> > already has xmm_t typedef:
> >
> > $ find lib -type f | xargs grep xmm_t | grep typedef
> > lib/librte_eal/common/include/arch/x86/rte_vect.h:typedef __m128i xmm_t;
> > lib/librte_eal/common/include/arch/arm/rte_vect.h:typedef int32x4_t xmm_t;
> >
> > Why not to change rte_lpm_lookupx4() to accept xmm_t as input parameter.
> > As I understand it would solve the problem, and wouldn't introduce any API/ABI breakage, right?
>
> Yes, If we have API/ABI breakage concerns.
>
> IMO, Now this would call for some kind of rte_vect_* abstraction load,
> store, set kind of SIMD operation on xmm_t in common test code to
> aviod #ifdef's in app/test/test_lpm.c
Yes, seems so.
>
> I guess we may not need those abstractions in
> lib/librte_eal/common/include/arch/ directory.
> keeping in app/test/xmmt_ops.h should be enough, right?
That sounds ok to me.
At least for now.
For future the more generic question - do we like to have some
generic layer abstraction for similar vector instrincts across different archs?
>From one side it might help people writing/using vector implementation of some stuff,
from other side - there would be extra hassle creating/supporting it.
Konstantin
>
>
> >
> > Konstantin
> >
> > >
> > > Now I am not sure why this API was created like this, from l3fwd.c
> > > example, it looks to accommodate the IPV4 byte swap[1]. If it's true,
> > > maybe we can have eal byte swap abstraction for optimized byte swap on
> > > memory for 4 IP address in one shot
> > >
> > > or
> > >
> > > Have rte_lpm_lookupx4 take an argument for byte swap or not ?
> > >
> > > or
> > >
> > > something similar?
> > >
> > > Thoughts ?
> > >
> > > [1]
> > > const __m128i bswap_mask = _mm_set_epi8(12, 13, 14, 15, 8, 9, 10, 11,
> > > 4, 5, 6, 7, 0, 1, 2, 3);
> > > /* Byte swap 4 IPV4 addresses. */
> > > dip = _mm_shuffle_epi8(dip, bswap_mask);
> > >
> > > Jerin
> > >
> > > > I think the most important question is to know what is the best solution
> > > > for performance and maintainability. The API/ABI questions will be considered
> > > > after.
> > > >
> > > > Thanks for your involvement guys.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 1:22 4% [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library Ferruh Yigit
2015-12-03 1:36 4% ` Thomas Monjalon
2015-12-03 8:18 4% ` [dpdk-dev] [PATCH v2] " Christian Ehrhardt
@ 2015-12-03 12:49 7% ` Panu Matilainen
2015-12-03 13:51 4% ` [dpdk-dev] [PATCH v4] " Ferruh Yigit
2 siblings, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-03 12:49 UTC (permalink / raw)
To: Ferruh Yigit, dev
On 12/03/2015 03:22 AM, Ferruh Yigit wrote:
> Fixes following error (observed when versioning macros used):
> LD libdpdk.so
> /usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
> for symbol <function>@DPDK_x.y
>
> Also resulting combined library contains symbol version information:
> $ readelf -a build/lib/libdpdk.so | grep rte_eal_ | grep @ | head
> <...> GLOBAL DEFAULT 12 rte_eal_alarm_set@@DPDK_2.0
> <...> GLOBAL DEFAULT 12 rte_eal_pci_write_config@@DPDK_2.1
> <...> GLOBAL DEFAULT 12 rte_eal_remote_launch@@DPDK_2.0
> ...
>
> Versioning fixed by merging all version scripts into one automatically and
> feeding it to final library.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---
> drivers/net/Makefile | 3 +++
> lib/Makefile | 3 +++
> mk/rte.sdkbuild.mk | 2 +-
> mk/rte.sharelib.mk | 3 +++
> scripts/merge_maps.sh | 29 +++++++++++++++++++++++++++++
> 5 files changed, 39 insertions(+), 1 deletion(-)
> create mode 100755 scripts/merge_maps.sh
>
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index cddcd57..d3c865b 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -51,5 +51,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
> DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
> DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
>
> +ifeq ($(COMBINED_BUILD),1)
> include $(RTE_SDK)/mk/rte.sharelib.mk
> +endif
> +
> include $(RTE_SDK)/mk/rte.subdir.mk
> diff --git a/lib/Makefile b/lib/Makefile
> index ef172ea..d0f7fb8 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -64,5 +64,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
> DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
> endif
>
> +ifeq ($(COMBINED_BUILD),1)
> include $(RTE_SDK)/mk/rte.sharelib.mk
> +endif
> +
> include $(RTE_SDK)/mk/rte.subdir.mk
> diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
> index 38ec7bd..d4e3abf 100644
> --- a/mk/rte.sdkbuild.mk
> +++ b/mk/rte.sdkbuild.mk
> @@ -94,7 +94,7 @@ $(ROOTDIRS-y):
> @echo "== Build $@"
> $(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
> @if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
> - $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
> + COMBINED_BUILD=1 $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
> fi
>
> %_clean:
> diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
> index 7bb7219..76ead09 100644
> --- a/mk/rte.sharelib.mk
> +++ b/mk/rte.sharelib.mk
> @@ -40,6 +40,8 @@ LIB_ONE := lib$(RTE_LIBNAME).so
> else
> LIB_ONE := lib$(RTE_LIBNAME).a
> endif
> +COMBINED_MAP=$(BUILDDIR)/lib/libdpdk.map
> +CPU_LDFLAGS += --version-script=$(COMBINED_MAP)
> endif
>
> .PHONY:sharelib
> @@ -79,6 +81,7 @@ ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> $(LIB_ONE): FORCE
> @[ -d $(dir $@) ] || mkdir -p $(dir $@)
> + @$(SRCDIR)/scripts/merge_maps.sh > $(COMBINED_MAP)
> $(O_TO_S_DO)
> else
> $(LIB_ONE): FORCE
> diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
> new file mode 100755
> index 0000000..bc40dc8
> --- /dev/null
> +++ b/scripts/merge_maps.sh
> @@ -0,0 +1,29 @@
> +#!/bin/sh
> +
> +FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
> +SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
> +
> +first=0
> +prev_sym="none"
> +
> +for s in $SYMBOLS; do
> + echo "$s {"
> + echo " global:"
> + echo ""
> + for f in $FILES; do
> + sed -n "/$s {/,/}/p" $f | sed '/^$/d' | grep -v global | grep -v local | sed '1d' | sed '$d'
> + done | sort -u
> + echo ""
> + if [ $first -eq 0 ]; then
> + first=1;
> + echo " local: *;";
> + fi
> + if [ "$prev_sym" == "none" ]; then
> + echo "};";
> + prev_sym=$s;
> + else
> + echo "} $prev_sym;";
> + prev_sym=$s;
> + fi
> + echo ""
> +done
>
I'd still rather see the combined library replaced with a linker script,
but as long as it is there then +1 for this: with symbol versioning in
place, applications linked to it more likely refuse to start than
randomly crash when ABI changes, internal symbols are hidden etc. And
doesn't require manual updating of two maps since its all scripted.
- Panu -
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
2015-12-03 12:42 0% ` Ananyev, Konstantin
@ 2015-12-03 13:20 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2015-12-03 13:20 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
On Thu, Dec 03, 2015 at 12:42:13PM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Thursday, December 03, 2015 12:17 PM
> > To: Ananyev, Konstantin
> > Cc: Thomas Monjalon; dev@dpdk.org; viktorin@rehivetech.com
> > Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
> >
> > On Thu, Dec 03, 2015 at 11:02:07AM +0000, Ananyev, Konstantin wrote:
> >
> > Hi Konstantin,
> >
> > > Hi Jerin,
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > > Sent: Thursday, December 03, 2015 9:34 AM
> > > > To: Thomas Monjalon
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
> > > >
> > > > On Wed, Dec 02, 2015 at 05:57:10PM +0100, Thomas Monjalon wrote:
> > > > > 2015-12-02 22:23, Jerin Jacob:
> > > > > > On Wed, Dec 02, 2015 at 05:40:13PM +0100, Thomas Monjalon wrote:
> > > > > > > 2015-12-02 20:04, Jerin Jacob:
> > > > > > > > On Wed, Dec 02, 2015 at 09:13:51PM +0800, Jianbo Liu wrote:
> > > > > > > > > On 2 December 2015 at 18:39, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > > > > > > > > > AND they include "rte_lpm.h"(it internally includes rte_vect.h)
> > > > > > > > > > that lead to multiple definition and its not good.
> > > > > > > > > >
> > > > > > > > > But you will have similar issue since "typedef int32x4_t __m128i"
> > > > > > > > > appears in both your patch and this header file.
> > > > > > > >
> > > > > > > > I just tested it, it won't break, back to back "typedef int32x4_t __m128i"
> > > > > > > > is fine(unlike inline function).
> > > > > > > >
> > > > > > > > my intention to keep __m128i "as is" because changing the __m128i to rte_???
> > > > > > > > something would break the ABI.
> > > > > > >
> > > > > > > Isn't it already broken in 2.2?
> > > > > >
> > > > > > Does it mean, You would like to have rte_128i(or similar) kind of
> > > > > > abstraction to represent 128bit SIMD variable in DPDK?
> > > > >
> > > > > If you are convinced that it is the best way to write a generic code, yes.
> > > >
> > > > I grep-ed through DPDK API list to see the dependency with SIMD in API
> > > > definition.I see only rte_lpm_lookupx4 API has SIMD dependency in API
> > > > definition.
> > > >
> > > > I believe that's the root cause of the problem. IMO, The
> > > > better way to fix this would be to remove __m128i from API and have more
> > > > general representation to remove the architecture dependency from API
> > > >
> > > > something like this,
> > > >
> > > > rte_lpm_lookupx4(const struct rte_lpm *lpm, uint32_t *ip, uint16_t
> > > > hop[4], uint16_t defv)
> > > >
> > > > instead of
> > > >
> > > > rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t
> > > > hop[4], uint16_t defv)
> > >
> > > The idea for that function was that rte_lpm_lookupx4() accepts 4 IPv4 addresses that are:
> > > 1. already in 128bit register
> > > 2. 'prepared' - byte swap is already done for them if needed.
> > >
> > > About ways to fix __m128i dependency: as I can see x86 and arm DPDK code
> > > already has xmm_t typedef:
> > >
> > > $ find lib -type f | xargs grep xmm_t | grep typedef
> > > lib/librte_eal/common/include/arch/x86/rte_vect.h:typedef __m128i xmm_t;
> > > lib/librte_eal/common/include/arch/arm/rte_vect.h:typedef int32x4_t xmm_t;
> > >
> > > Why not to change rte_lpm_lookupx4() to accept xmm_t as input parameter.
> > > As I understand it would solve the problem, and wouldn't introduce any API/ABI breakage, right?
> >
> > Yes, If we have API/ABI breakage concerns.
> >
> > IMO, Now this would call for some kind of rte_vect_* abstraction load,
> > store, set kind of SIMD operation on xmm_t in common test code to
> > aviod #ifdef's in app/test/test_lpm.c
>
> Yes, seems so.
>
> >
> > I guess we may not need those abstractions in
> > lib/librte_eal/common/include/arch/ directory.
> > keeping in app/test/xmmt_ops.h should be enough, right?
>
> That sounds ok to me.
> At least for now.
> For future the more generic question - do we like to have some
> generic layer abstraction for similar vector instrincts across different archs?
> From one side it might help people writing/using vector implementation of some stuff,
> from other side - there would be extra hassle creating/supporting it.
There are few such libaries avilable on web. example:
NEON -> SSE
https://software.intel.com/sites/default/files/managed/cf/f6/NEONvsSSE.h
SSE -> NEON
https://github.com/jratcliff63367/sse2neon/blob/master/SSE2NEON.h
but coming up with common abstraction will be difficult as it's not
one to one mapped all the time and performance criteria to choose
the instruction on given architecture to realize a certain logic etc
Jerin
>
> Konstantin
>
> >
> >
> > >
> > > Konstantin
> > >
> > > >
> > > > Now I am not sure why this API was created like this, from l3fwd.c
> > > > example, it looks to accommodate the IPV4 byte swap[1]. If it's true,
> > > > maybe we can have eal byte swap abstraction for optimized byte swap on
> > > > memory for 4 IP address in one shot
> > > >
> > > > or
> > > >
> > > > Have rte_lpm_lookupx4 take an argument for byte swap or not ?
> > > >
> > > > or
> > > >
> > > > something similar?
> > > >
> > > > Thoughts ?
> > > >
> > > > [1]
> > > > const __m128i bswap_mask = _mm_set_epi8(12, 13, 14, 15, 8, 9, 10, 11,
> > > > 4, 5, 6, 7, 0, 1, 2, 3);
> > > > /* Byte swap 4 IPV4 addresses. */
> > > > dip = _mm_shuffle_epi8(dip, bswap_mask);
> > > >
> > > > Jerin
> > > >
> > > > > I think the most important question is to know what is the best solution
> > > > > for performance and maintainability. The API/ABI questions will be considered
> > > > > after.
> > > > >
> > > > > Thanks for your involvement guys.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-03 12:14 29% ` Mcnamara, John
@ 2015-12-03 13:28 4% ` Thomas Monjalon
2015-12-03 13:44 4% ` Panu Matilainen
2015-12-03 13:39 7% ` Panu Matilainen
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-03 13:28 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev
2015-12-03 12:14, Mcnamara, John:
> Also, if someone has some bandwidth it would be good to add an option
> to pass -j with an optional number to "make" in the script.
We can use -j without any number:
"make will not limit the number of jobs that can run simultaneously".
It is a not so bad default.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-03 12:14 29% ` Mcnamara, John
2015-12-03 13:28 4% ` Thomas Monjalon
@ 2015-12-03 13:39 7% ` Panu Matilainen
2015-12-03 13:41 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Panu Matilainen @ 2015-12-03 13:39 UTC (permalink / raw)
To: Mcnamara, John, dev
On 12/03/2015 02:14 PM, Mcnamara, John wrote:
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
>> Sent: Wednesday, December 2, 2015 4:51 PM
>> To: dev@dpdk.org
>> Subject: [dpdk-dev] [PATCH] scripts: support any legal git revisions as
>> abi validation range
>>
>> In addition to git tags, support validating abi between any legal
>> gitrevisions(7) syntaxes, such as "validate-abi.sh . -1 <target>"
>> "validate-abi.sh master mybrach <target>" etc in addition to validating
>> between tags. Makes it easier to run the validator for in-development
>> work.
>
> Hi Panu,
>
> +1 for this.
>
> You might also change the ABI validation section of the docs to go along
> with this. Something like the patch below. If not I'll submit it
> afterwards.
Good points, including changing the usage message to REV instead of TAG.
I'll send an improved version based on this, thanks.
>
> Also, if someone has some bandwidth it would be good to add an option
> to pass -j with an optional number to "make" in the script.
Can do, although I'm still waiting fo my previous, semi-related
validate-abi patches from September to be applied...
- Panu -
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-03 13:39 7% ` Panu Matilainen
@ 2015-12-03 13:41 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-03 13:41 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
2015-12-03 15:39, Panu Matilainen:
> > Also, if someone has some bandwidth it would be good to add an option
> > to pass -j with an optional number to "make" in the script.
>
> Can do, although I'm still waiting fo my previous, semi-related
> validate-abi patches from September to be applied...
Oh yes, sorry. I will apply it shortly.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-03 13:28 4% ` Thomas Monjalon
@ 2015-12-03 13:44 4% ` Panu Matilainen
2015-12-03 13:49 4% ` Richardson, Bruce
2015-12-03 15:46 4% ` Mcnamara, John
0 siblings, 2 replies; 200+ results
From: Panu Matilainen @ 2015-12-03 13:44 UTC (permalink / raw)
To: Thomas Monjalon, Mcnamara, John; +Cc: dev
On 12/03/2015 03:28 PM, Thomas Monjalon wrote:
> 2015-12-03 12:14, Mcnamara, John:
>> Also, if someone has some bandwidth it would be good to add an option
>> to pass -j with an optional number to "make" in the script.
>
> We can use -j without any number:
> "make will not limit the number of jobs that can run simultaneously".
> It is a not so bad default.
>
Hmm, my memory associates an unlimited -j to make with sudden death by
fork-bomb. But that was a long time ago and on a different codebase (the
kernel maybe), with DPDK on current hardware it doesn't seem that bad at
all.
OTOH we can also simply ask the system for a reasonable value, eg
$ /usr/bin/getconf _NPROCESSORS_ONLN
- Panu -
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-03 13:44 4% ` Panu Matilainen
@ 2015-12-03 13:49 4% ` Richardson, Bruce
2015-12-03 15:46 4% ` Mcnamara, John
1 sibling, 0 replies; 200+ results
From: Richardson, Bruce @ 2015-12-03 13:49 UTC (permalink / raw)
To: Panu Matilainen, Thomas Monjalon, Mcnamara, John; +Cc: dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
> Sent: Thursday, December 3, 2015 1:44 PM
> To: Thomas Monjalon <thomas.monjalon@6wind.com>; Mcnamara, John
> <john.mcnamara@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions
> as abi validation range
>
> On 12/03/2015 03:28 PM, Thomas Monjalon wrote:
> > 2015-12-03 12:14, Mcnamara, John:
> >> Also, if someone has some bandwidth it would be good to add an option
> >> to pass -j with an optional number to "make" in the script.
> >
> > We can use -j without any number:
> > "make will not limit the number of jobs that can run simultaneously".
> > It is a not so bad default.
> >
>
> Hmm, my memory associates an unlimited -j to make with sudden death by
> fork-bomb. But that was a long time ago and on a different codebase (the
> kernel maybe), with DPDK on current hardware it doesn't seem that bad at
> all.
>
> OTOH we can also simply ask the system for a reasonable value, eg $
> /usr/bin/getconf _NPROCESSORS_ONLN
>
> - Panu -
+1 to this.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v4] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 12:49 7% ` Panu Matilainen
@ 2015-12-03 13:51 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2015-12-03 13:51 UTC (permalink / raw)
To: dev
Fixes following error (observed when versioning macros used):
LD libdpdk.so
/usr/bin/ld: /root/dpdk/build/lib/libdpdk.so: version node not found
for symbol <function>@DPDK_x.y
Also resulting combined library contains symbol version information:
$ readelf -a build/lib/libdpdk.so | grep rte_eal_ | grep @ | head
<...> GLOBAL DEFAULT 12 rte_eal_alarm_set@@DPDK_2.0
<...> GLOBAL DEFAULT 12 rte_eal_pci_write_config@@DPDK_2.1
<...> GLOBAL DEFAULT 12 rte_eal_remote_launch@@DPDK_2.0
...
Versioning fixed by merging all version scripts into one automatically and
feeding it to final library.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
mk/rte.sharelib.mk | 6 +++++-
scripts/merge_maps.sh | 29 +++++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 1 deletion(-)
create mode 100755 scripts/merge_maps.sh
diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk
index 7bb7219..6029b71 100644
--- a/mk/rte.sharelib.mk
+++ b/mk/rte.sharelib.mk
@@ -40,6 +40,8 @@ LIB_ONE := lib$(RTE_LIBNAME).so
else
LIB_ONE := lib$(RTE_LIBNAME).a
endif
+COMBINED_MAP=$(BUILDDIR)/lib/libdpdk.map
+COMBINED_LDFLAGS += --version-script=$(COMBINED_MAP)
endif
.PHONY:sharelib
@@ -51,9 +53,10 @@ ifeq ($(LINK_USING_CC),1)
# Override the definition of LD here, since we're linking with CC
LD := $(CC) $(CPU_CFLAGS)
O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \
+ $(call linkerprefix,$(COMBINED_LDFLAGS)) \
-shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
else
-O_TO_S = $(LD) $(CPU_LDFLAGS) \
+O_TO_S = $(LD) $(CPU_LDFLAGS) $(COMBINED_LDFLAGS) \
-shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
endif
@@ -79,6 +82,7 @@ ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
$(LIB_ONE): FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
+ @$(SRCDIR)/scripts/merge_maps.sh > $(COMBINED_MAP)
$(O_TO_S_DO)
else
$(LIB_ONE): FORCE
diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
new file mode 100755
index 0000000..edc88de
--- /dev/null
+++ b/scripts/merge_maps.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+FILES=$(find "$RTE_SDK"/lib "$RTE_SDK"/drivers -name "*_version.map")
+SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
+
+first=0
+prev_sym="none"
+
+for s in $SYMBOLS; do
+ echo "$s {"
+ echo " global:"
+ echo ""
+ for f in $FILES; do
+ sed -n "/$s {/,/}/p" "$f" | sed '/^$/d' | grep -v global | grep -v local | sed -e '1d' -e '$d'
+ done | sort -u
+ echo ""
+ if [ $first -eq 0 ]; then
+ first=1;
+ echo " local: *;";
+ fi
+ if [ "$prev_sym" = "none" ]; then
+ echo "};";
+ prev_sym=$s;
+ else
+ echo "} $prev_sym;";
+ prev_sym=$s;
+ fi
+ echo ""
+done
--
2.5.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library
2015-12-03 11:18 4% ` Ferruh Yigit
@ 2015-12-03 14:01 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2015-12-03 14:01 UTC (permalink / raw)
To: Christian Ehrhardt, dev
On Thu, Dec 03, 2015 at 11:18:27AM +0000, Ferruh Yigit wrote:
> On Thu, Dec 03, 2015 at 09:18:49AM +0100, Christian Ehrhardt wrote:
> > Hi Ferruh,
> > some minor bash improvements that could be made in the next revision:
> >
> > On Thu, Dec 3, 2015 at 2:22 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> > > diff --git a/scripts/merge_maps.sh b/scripts/merge_maps.sh
> > > new file mode 100755
> > > index 0000000..bc40dc8
> > > --- /dev/null
> > > +++ b/scripts/merge_maps.sh
> > > @@ -0,0 +1,29 @@
> > > +#!/bin/sh
> > > +
> > > +FILES=$(find $RTE_SDK -name "*.map" | grep -v build)
> > > +SYMBOLS=$(grep -h "{" $FILES | sort -u | sed 's/{//')
> >
> > Guarding $RTE_SDK and $FILES with "" will help avoid some potential
> > issues due to words splitting.
I quoted them (not $FILES which grep requires multiple params), but that will not actually help with folder names contains spaces, for that case script is broken.
I fixed script using IFS and a few tricks but made script unnecessarly complex, so I revert back and leaving as it is unless required explicitly.
And I suspect if folder name has spaces this script won't be only thing broken.
Thanks,
ferruh
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2] scripts: support any legal git revisions as abi validation range
2015-12-02 16:50 36% [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range Panu Matilainen
2015-12-02 18:23 4% ` Neil Horman
2015-12-03 12:14 29% ` Mcnamara, John
@ 2015-12-03 14:05 36% ` Panu Matilainen
2 siblings, 0 replies; 200+ results
From: Panu Matilainen @ 2015-12-03 14:05 UTC (permalink / raw)
To: dev
In addition to git tags, support validating abi between any legal
gitrevisions(7) syntaxes, such as "validate-abi.sh -1 . <target>"
"validate-abi.sh master mybranch <target>" etc in addition to
validating between tags. Makes it easier to run the validator
for in-development work.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
v2 changes:
- update usage and error messages to match new behavior
- update documentation too (as suggested by John McNamara)
doc/guides/contributing/versioning.rst | 20 ++++++++++++-------
scripts/validate-abi.sh | 36 ++++++++++++++++++++--------------
2 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 653c7d0..015ebb7 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -468,16 +468,22 @@ utilities which can be installed via a package manager. For example::
The syntax of the ``validate-abi.sh`` utility is::
- ./scripts/validate-abi.sh <TAG1> <TAG2> <TARGET>
+ ./scripts/validate-abi.sh <REV1> <REV2> <TARGET>
-Where ``TAG1`` and ``TAG2`` are valid git tags on the local repo and target is
-the usual DPDK compilation target.
+Where ``REV1`` and ``REV2`` are valid gitrevisions(7)
+https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
+on the local repo and target is the usual DPDK compilation target.
-For example to test the current committed HEAD against a previous release tag
-we could add a temporary tag and run the utility as follows::
+For example:
- git tag MY_TEMP_TAG
- ./scripts/validate-abi.sh v2.0.0 MY_TEMP_TAG x86_64-native-linuxapp-gcc
+ # Check between the previous and latest commit:
+ ./scripts/validate-abi.sh HEAD~1 HEAD x86_64-native-linuxapp-gcc
+
+ # Check between two tags:
+ ./scripts/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linuxapp-gcc
+
+ # Check between git master and local topic-branch "vhost-hacking":
+ ./scripts/validate-abi.sh master vhost-hacking x86_64-native-linuxapp-gcc
After the validation script completes (it can take a while since it need to
compile both tags) it will create compatibility reports in the
diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
index 4476433..e49c425 100755
--- a/scripts/validate-abi.sh
+++ b/scripts/validate-abi.sh
@@ -33,7 +33,7 @@ TARGET=$3
ABI_DIR=`mktemp -d -p /tmp ABI.XXXXXX`
usage() {
- echo "$0 <TAG1> <TAG2> <TARGET>"
+ echo "$0 <REV1> <REV2> <TARGET>"
}
log() {
@@ -43,16 +43,15 @@ log() {
}
validate_tags() {
- git tag -l | grep -q "$TAG1"
- if [ $? -ne 0 ]
+
+ if [ -z "$HASH1" ]
then
- echo "$TAG1 is invalid"
+ echo "invalid revision: $TAG1"
return
fi
- git tag -l | grep -q "$TAG2"
- if [ $? -ne 0 ]
+ if [ -z "$HASH2" ]
then
- echo "$TAG2 is invalid"
+ echo "invalid revision: $TAG2"
return
fi
}
@@ -60,12 +59,12 @@ validate_tags() {
validate_args() {
if [ -z "$TAG1" ]
then
- echo "Must Specify TAG1"
+ echo "Must Specify REV1"
return
fi
if [ -z "$TAG2" ]
then
- echo "Must Specify TAG2"
+ echo "Must Specify REV2"
return
fi
if [ -z "$TARGET" ]
@@ -112,6 +111,9 @@ then
cleanup_and_exit 1
fi
+HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null)
+HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null)
+
# Make sure our tags exist
res=$(validate_tags)
if [ -n "$res" ]
@@ -120,6 +122,10 @@ then
cleanup_and_exit 1
fi
+# Make hashes available in output for non-local reference
+TAG1="$TAG1 ($HASH1)"
+TAG2="$TAG2 ($HASH2)"
+
ABICHECK=`which abi-compliance-checker 2>/dev/null`
if [ $? -ne 0 ]
then
@@ -135,8 +141,8 @@ then
fi
log "INFO" "We're going to check and make sure that applications built"
-log "INFO" "against DPDK DSOs from tag $TAG1 will still run when executed"
-log "INFO" "against DPDK DSOs built from tag $TAG2."
+log "INFO" "against DPDK DSOs from version $TAG1 will still run when executed"
+log "INFO" "against DPDK DSOs built from version $TAG2."
log "INFO" ""
# Check to make sure we have a clean tree
@@ -152,7 +158,7 @@ cd $(dirname $0)/..
log "INFO" "Checking out version $TAG1 of the dpdk"
# Move to the old version of the tree
-git checkout $TAG1
+git checkout $HASH1
# Make sure we configure SHARED libraries
# Also turn off IGB and KNI as those require kernel headers to build
@@ -185,7 +191,7 @@ cd $TARGET/lib
log "INFO" "COLLECTING ABI INFORMATION FOR $TAG1"
for i in `ls *.so`
do
- $ABIDUMP $i -o $ABI_DIR/$i-ABI-0.dump -lver $TAG1
+ $ABIDUMP $i -o $ABI_DIR/$i-ABI-0.dump -lver $HASH1
done
cd ../..
@@ -194,7 +200,7 @@ git clean -f -d
git reset --hard
# Move to the new version of the tree
log "INFO" "Checking out version $TAG2 of the dpdk"
-git checkout $TAG2
+git checkout $HASH2
# Make sure we configure SHARED libraries
# Also turn off IGB and KNI as those require kernel headers to build
@@ -220,7 +226,7 @@ cd $TARGET/lib
log "INFO" "COLLECTING ABI INFORMATION FOR $TAG2"
for i in `ls *.so`
do
- $ABIDUMP $i -o $ABI_DIR/$i-ABI-1.dump -lver $TAG2
+ $ABIDUMP $i -o $ABI_DIR/$i-ABI-1.dump -lver $HASH2
done
cd ../..
--
2.5.0
^ permalink raw reply [relevance 36%]
* Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
2015-12-03 1:31 0% ` Ferruh Yigit
2015-12-03 8:11 3% ` Christian Ehrhardt
@ 2015-12-03 14:59 0% ` Neil Horman
1 sibling, 0 replies; 200+ results
From: Neil Horman @ 2015-12-03 14:59 UTC (permalink / raw)
To: Robie Basak, dev
On Thu, Dec 03, 2015 at 01:31:33AM +0000, Ferruh Yigit wrote:
> On Wed, Dec 02, 2015 at 06:44:19AM -0500, Neil Horman wrote:
> > On Tue, Dec 01, 2015 at 12:37:37PM +0000, Robie Basak wrote:
> > > Re-sending this unsigned since the ML rejected my signed email.
> > >
> > > -1 from Ubuntu without further discussion since it will break us. Please
> > > don't commit this patch yet.
> > >
> > > I don't understand why we must have the complexity of so many shared
> > > libraries. From a distribution packaging perspective, all I see is that
> > > this multiplies potential work by twenty times and makes it awkward to
> > > work with without special tooling (which then needs maintaining).
> > >
> > Theres nothing "complex" about the simple fact that a project builds lots of
> > libraries. Its extreemely common. Any graphic window manager has exactly the
> > same situation, as do any number of tools that have multiple hardware backends
> > impelmented in user space (v4l, sane, iptables, to name just a few).
> >
> > > Before I go into details, it would be nice if someone could please
> > > explain why DPDK has to be "special" in needing to do this? I don't
> > Its not special, see above. Not saying the build environment cant be improved,
> > but the fact that there are multiple libraries is pretty straightforward.
> >
> > > understand why DPDK must be different to every other userspace library
> > > out there. If DPDK has a good need to be different then that's fair
> > > enough. But I feel that if DPDK is deviating from the norm then we need
> > > to frame the discussion from the perspective of "why DPDK must be
> > > different", rather than having me trying to explain why the norm is the
> > > right way to do it.
> > >
> > > On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
> > > > That's how Fedora and RHEL are shipping it already and nobody has so much
> > > > as noticed anything strange, much less complained about it. 20 libraries
> > > > is but a drop in the ocean on a average distro.
> > >
> > > No, it is 20 times the work from the perspective of DPDK package
> > > maintenance. Let me explain why.
> > >
> > > In Debian and Ubuntu, we manage a library transition (an ABI bump in a
> > > library together with all dependencies moving to use the new ABI) by
> > > concurrently packaging both the old and new libraries at once. This
> > > works well with the norm for libraries. We ship one binary package per
> > > soname, with the major version as part of the package name. This allows
> > > a system to have two (or more) ABIs installed simultaneously. For a
> > > library transition, we just package the new version and then that can
> > > land and work concurrently as we then individually update every
> > > dependent (library-consuming) package.
> > So thats, a distribution choice, not an upstream problem. And it seems like a
> > problem you should have already solved (note the examples above). If you feel
> > like you need to package multiple ABI versions in the same library, you can,
> > just update the LIBABIVER of all the libraries, instead of the ones that truly
> > change, so that each library is guaranteed a newer so version, to make the
> > library file name unique. Yes you have to make a small change from upstream,
> > but thats part of the work that distribution maintainers do.
> >
> >
> > > This works because of conventions around sonames, which DPDK breaks
> > > unless we treat it as twenty different libraries which changes our work
> > > from easy to painful.
> > >
> > > Usually a library transition is managed by hand by the package
> > > maintainer. It's not taxing because it's straightforward and well
> > > understood. Update and upload the new ABI source package, then find all
> > > reverse dependencies and sort them out, recursively. But if the
> > > maintainer must do it twenty times, then it becomes taxing and prone to
> > > error. And if the reverse dependency tree differs depending on the split
> > > library used by library consumers, then it gets far more complex to
> > > follow.
> > >
> > > Admittedly we could tool around this to make it easier, but that's extra
> > > work (both initially and in maintenance) and prone to error (because
> > > we'd only be doing it for DPDK).
> > >
> > You must already have a solution to this, I can't imagine you package all the
> > libraries for kde or gnome (or even pam) separately)
> >
> > > Packaging a library is usually virtually a no-op in Debian and Ubuntu
> > > nowadays. Our tooling does it all for us. But packaging DPDK is far from
> > > this currently because of all this added complexity. From my perspective
> > > this is unnecessary and makes no sense. We could do all kinds of things
> > > to work around it (that's what packaging is about) but then we'd have to
> > > maintain that specialness and I don't see why it must be awkward like
> > > this instead of just doing it the same way as every other library.
> > >
> > > > The combined library as it is simply is no longer a viable option.
> > > > Besides just being broken (witness the strange hacks people are coming
> > > > up with to work around issues in it) its ugly because it basically gives
> > > > the middle finger to all the effort going into version compatibility,
> > > > and its also big. Few projects will use every library in DPDK, but with
> > > > the combined library they're forced to lug the 800 pound gorilla along
> > > > needlessly.
> > >
> > > It's broken because it's broken upstream, and that's what we should fix.
> > > Why is it not viable? How does it give the middle finger to effort going
> > > into version compatibility?
> > Because each individual library has a version script that gets applied during
> > link to version symbols properly. Those scripts dont get applied when building
> > the combined library.
> >
> >
> > > Doing it the right way like every other
> > > userspace library is what *gives us* version compatibility because then
> > > distributions can straightforwardly install multiple ABI versions at
> > > once.
> > Again, Not at all uncommon. You're packaging methodology is the issue here,
> > not the fact that there are multiple libraries.
> >
> > > Finally, I fail to see any "lug the 800 pound gorilla along" saving. We
> > > (Ubuntu and Fedora) are both shipping all the libraries in one package,
> > > whether split or combined, so they are all being lugged onto disk
> > > anyway. Whether split or combined, there is no saving there. And memory
> > > is hardly saved either because the kernel will just page in and out what
> > > is needed in both cases. So how does this proposed change give us any
> > > saving at all?
> > >
> > Not true, initalization constructors for PMD's at the very least mean that every
> > pmd will get paged in weather you want it or not using the combined library.
> > Individual libraries let you dynamically load them (via dlopen). I think the
> > same is true of several other facets of dpdk.
> >
> > Neil
> >
> I just sent a patch that fixes versioning in combined library, can you please check it: http://dpdk.org/dev/patchwork/patch/9259/
>
> Thanks,
> ferruh
>
>
I've seen the patch, and I appreciate the effort, but it really seems to me like
more of the same. That is to say, its a good effort but it really creates
additional ifrastructure to allow a single library to be built, but the fact of
the matter is, a single library isn't needed. The build system is setup to
crate multiple libraries, and a linker scripts allows for the combined library
functionality, without adding additional clutter to the Makefiles. The argument
that its more work to support multiple libraries in some distributions simply
doesn't ring true with me, because that must be a problem which is already
solved for other popular projects which are architected in a simmilar fashion.
Regards
Neil
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range
2015-12-03 13:44 4% ` Panu Matilainen
2015-12-03 13:49 4% ` Richardson, Bruce
@ 2015-12-03 15:46 4% ` Mcnamara, John
1 sibling, 0 replies; 200+ results
From: Mcnamara, John @ 2015-12-03 15:46 UTC (permalink / raw)
To: Panu Matilainen, Thomas Monjalon; +Cc: dev
> -----Original Message-----
> From: Panu Matilainen [mailto:pmatilai@redhat.com]
> Sent: Thursday, December 3, 2015 1:44 PM
> To: Thomas Monjalon; Mcnamara, John
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] scripts: support any legal git revisions
> as abi validation range
>
> On 12/03/2015 03:28 PM, Thomas Monjalon wrote:
> > 2015-12-03 12:14, Mcnamara, John:
> >> Also, if someone has some bandwidth it would be good to add an option
> >> to pass -j with an optional number to "make" in the script.
> >
> > We can use -j without any number:
> > "make will not limit the number of jobs that can run simultaneously".
> > It is a not so bad default.
> >
>
> Hmm, my memory associates an unlimited -j to make with sudden death by
> fork-bomb. But that was a long time ago and on a different codebase (the
> kernel maybe), with DPDK on current hardware it doesn't seem that bad at
> all.
>
> OTOH we can also simply ask the system for a reasonable value, eg $
> /usr/bin/getconf _NPROCESSORS_ONLN
Hi,
To be clear, it would be nice to be able to pass "-j" or "-j n" like you can do to directly to 'make'.
For a compile heavy codebase (no DPDK) "-j" can, as you say, choke your system but that would be up to the user to specify, or not.
John.
--
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size
2015-11-20 16:28 4% ` Olivier MATZ
2015-11-20 16:33 4% ` Bruce Richardson
@ 2015-12-03 16:32 4% ` Mcnamara, John
1 sibling, 0 replies; 200+ results
From: Mcnamara, John @ 2015-12-03 16:32 UTC (permalink / raw)
To: Olivier MATZ, Nelio Laranjeiro, dev
> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Friday, November 20, 2015 4:29 PM
> To: Mcnamara, John; Nelio Laranjeiro; dev@dpdk.org
> Cc: thomas.monjalon@6wind.com; Lu, Wenzhuo
> Subject: Re: [PATCH 1/2] doc: announce ABI change for cmdline buffer size
>
> Hi Nélio,
>
> On 11/10/2015 06:29 PM, Mcnamara, John wrote:
> >
> >
> >> -----Original Message-----
> >> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> >> Sent: Monday, November 9, 2015 4:48 PM
> >> To: dev@dpdk.org
> >> Cc: olivier.matz@6wind.com; thomas.monjalon@6wind.com; Mcnamara,
> >> John; Lu, Wenzhuo
> >> Subject: [PATCH 1/2] doc: announce ABI change for cmdline buffer size
> >>
> >> Current buffer size are not enough for a few testpmd commands.
> >>
> >> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> >
> > Acked-by: John McNamara <john.mcnamara@intel.com>
> >
>
> While I'm not fundamentally opposed to change the buffer size, I'm
> wondering if the impacted commands shouldn't be reworked to have smaller
> lines. 256 is already a quite big value for a line:
>
> 01234567890123456789012345678901234567890123456789012345678901234567890123
> 45678901234567890123456789012345678901234567890123456789012345678901234567
> 89012345678901234567890123456789012345678901234567890123456789012345678901
> 2345678901234567890123456789012345
>
> For instance, we could change some commands to use contexts.
> Dummy example with reta config:
>
> testpmd> port config 0 rss reta
> testpmd-reta-config-0> add hash1 queue1
> testpmd-reta-config-0> add hash2 queue2
> testpmd-reta-config-0> del hash1 queue1
> testpmd-reta-config-0> show
> testpmd-reta-config-0> commit
> testpmd>
>
> What do you think?
Hi,
I think it is a good idea but my concern is that it won't get done unless someone commits to doing it.
And if they do it will be a non-trivial change since the commandline/runtime parsing in testpmd is a little crufty and it isn't set up to do this kind of sub-command parsing.
Also, we will still have to maintain backward compatibility (for users and testers) with the existing single line versions of the commands.
So, I'd like to make sure that this change isn't blocked on the assumption that it will be fixed with a more elegant solution if that solution is unlikely to happen.
However, I do think that we should avoid bolting on every increasing options to existing testpmd commands and should instead create new commands where it makes sense.
John.
--
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 0/3 v2] Minor abi-validator improvements
2015-11-11 7:07 4% ` Panu Matilainen
@ 2015-12-03 19:38 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-03 19:38 UTC (permalink / raw)
To: Panu Matilainen; +Cc: dev
2015-09-24 06:23, Neil Horman:
> On Thu, Sep 24, 2015 at 10:50:56AM +0300, Panu Matilainen wrote:
> > For giggles, tried running abi-validator between 2.0 and 2.1 on
> > my Fedora 22 laptop, didn't work due to various build failures.
> > With this patch series the following now succeeds:
> >
> > EXTRA_CFLAGS="-Wno-error" scripts/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linuxapp-gcc
> >
> > Panu Matilainen (3):
> > scripts: permit passing extra compiler & linker flags to ABI validator
> > scripts: move two identical config fixups into a function
> > scripts: teach ABI validator about CONFIG_RTE_KNI_KMOD
> >
> > scripts/validate-abi.sh | 28 ++++++++++++++--------------
> > 1 file changed, 14 insertions(+), 14 deletions(-)
> >
>
> series
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] virtio: fix link state regression
@ 2015-12-04 2:08 3% Stephen Hemminger
2015-12-04 3:29 0% ` Yuanhan Liu
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2015-12-04 2:08 UTC (permalink / raw)
To: huawei.xie, yuanhan.liu, bernard.iremonger; +Cc: dev
Support for link state interrupt was broken on virtio by
commit bda66c418c85 ("ethdev: add device fields from PCI layer")
This is caused because the actual value of drv_flags is not set
until after the resource_init has figured out whether it is using
UIO or direct I/O instructions.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
There maybe other drivers with the same problem. It would have
been better to move the structure elements (and break ABI) rather
than assume it safe to copy them. Better to fail compiling.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] virtio: fix link state regression
2015-12-04 2:08 3% [dpdk-dev] [PATCH] virtio: fix link state regression Stephen Hemminger
@ 2015-12-04 3:29 0% ` Yuanhan Liu
2015-12-04 15:25 0% ` Iremonger, Bernard
0 siblings, 1 reply; 200+ results
From: Yuanhan Liu @ 2015-12-04 3:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Thu, Dec 03, 2015 at 06:08:24PM -0800, Stephen Hemminger wrote:
> Support for link state interrupt was broken on virtio by
>
> commit bda66c418c85 ("ethdev: add device fields from PCI layer")
>
> This is caused because the actual value of drv_flags is not set
> until after the resource_init has figured out whether it is using
> UIO or direct I/O instructions.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> There maybe other drivers with the same problem. It would have
> been better to move the structure elements (and break ABI) rather
> than assume it safe to copy them. Better to fail compiling.
I see no patch content.
--yliu
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] virtio: fix link state regression
2015-12-04 3:29 0% ` Yuanhan Liu
@ 2015-12-04 15:25 0% ` Iremonger, Bernard
2015-12-04 15:27 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Iremonger, Bernard @ 2015-12-04 15:25 UTC (permalink / raw)
To: Yuanhan Liu, Stephen Hemminger; +Cc: dev
Hi Stephen, Yuanhan,
> -----Original Message-----
> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> Sent: Friday, December 4, 2015 3:30 AM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Xie, Huawei <huawei.xie@intel.com>; Iremonger, Bernard
> <bernard.iremonger@intel.com>; dev@dpdk.org
> Subject: Re: [PATCH] virtio: fix link state regression
>
> On Thu, Dec 03, 2015 at 06:08:24PM -0800, Stephen Hemminger wrote:
> > Support for link state interrupt was broken on virtio by
> >
> > commit bda66c418c85 ("ethdev: add device fields from PCI layer")
> >
> > This is caused because the actual value of drv_flags is not set until
> > after the resource_init has figured out whether it is using UIO or
> > direct I/O instructions.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
> > There maybe other drivers with the same problem. It would have been
> > better to move the structure elements (and break ABI) rather than
> > assume it safe to copy them. Better to fail compiling.
>
> I see no patch content.
>
> --yliu
I have submitted a patch for this issue.
http://dpdk.org/dev/patchwork/patch/9345/
I have checked the other drivers, I found an issue with the bonding PMD.
I have submitted a patch for this.
http://dpdk.org/dev/patchwork/patch/9342/
The remaining drivers look fine to me.
Regards,
Bernard.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] virtio: fix link state regression
2015-12-04 15:25 0% ` Iremonger, Bernard
@ 2015-12-04 15:27 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2015-12-04 15:27 UTC (permalink / raw)
To: Iremonger, Bernard; +Cc: dev
2015-12-04 15:25, Iremonger, Bernard:
> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> > On Thu, Dec 03, 2015 at 06:08:24PM -0800, Stephen Hemminger wrote:
> > > Support for link state interrupt was broken on virtio by
> > >
> > > commit bda66c418c85 ("ethdev: add device fields from PCI layer")
> > >
> > > This is caused because the actual value of drv_flags is not set until
> > > after the resource_init has figured out whether it is using UIO or
> > > direct I/O instructions.
> > >
> > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > ---
> > > There maybe other drivers with the same problem. It would have been
> > > better to move the structure elements (and break ABI) rather than
> > > assume it safe to copy them. Better to fail compiling.
> >
> > I see no patch content.
> >
> > --yliu
>
> I have submitted a patch for this issue.
>
> http://dpdk.org/dev/patchwork/patch/9345/
>
> I have checked the other drivers, I found an issue with the bonding PMD.
> I have submitted a patch for this.
>
> http://dpdk.org/dev/patchwork/patch/9342/
>
> The remaining drivers look fine to me.
Thank you Bernard for the quick response.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH resend] virtio: fix link state regression
@ 2015-12-04 15:59 3% Stephen Hemminger
2015-12-04 16:18 0% ` Iremonger, Bernard
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2015-12-04 15:59 UTC (permalink / raw)
To: huawei.xie, yuanhan.liu, bernard.iremonger; +Cc: dev
Support for link state interrupt was broken on virtio by
commit bda66c418c85 ("ethdev: add device fields from PCI layer")
This is caused because the actual value of drv_flags is not set
until after the resource_init has figured out whether it is using
UIO or direct I/O instructions.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
There maybe other drivers with the same problem. It would have
been better to move the structure elements (and break ABI) rather
than assume it safe to copy them.
drivers/net/virtio/virtio_ethdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 74c00ee..8e12804 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1289,11 +1289,11 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
pci_dev = eth_dev->pci_dev;
- rte_eth_copy_pci_info(eth_dev, pci_dev);
-
if (virtio_resource_init(pci_dev) < 0)
return -1;
+ rte_eth_copy_pci_info(eth_dev, pci_dev);
+
hw->use_msix = virtio_has_msix(&pci_dev->addr);
hw->io_base = (uint32_t)(uintptr_t)pci_dev->mem_resource[0].addr;
--
2.1.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH resend] virtio: fix link state regression
2015-12-04 15:59 3% [dpdk-dev] [PATCH resend] " Stephen Hemminger
@ 2015-12-04 16:18 0% ` Iremonger, Bernard
0 siblings, 0 replies; 200+ results
From: Iremonger, Bernard @ 2015-12-04 16:18 UTC (permalink / raw)
To: Stephen Hemminger, Xie, Huawei, yuanhan.liu; +Cc: dev
Hi Stephen,
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, December 4, 2015 3:59 PM
> To: Xie, Huawei <huawei.xie@intel.com>; yuanhan.liu@linux.intel.com;
> Iremonger, Bernard <bernard.iremonger@intel.com>
> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>
> Subject: [PATCH resend] virtio: fix link state regression
>
> Support for link state interrupt was broken on virtio by
>
> commit bda66c418c85 ("ethdev: add device fields from PCI layer")
>
> This is caused because the actual value of drv_flags is not set until after the
> resource_init has figured out whether it is using UIO or direct I/O
> instructions.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> ---
>
> There maybe other drivers with the same problem. It would have been
> better to move the structure elements (and break ABI) rather than assume it
> safe to copy them.
>
> drivers/net/virtio/virtio_ethdev.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index 74c00ee..8e12804 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1289,11 +1289,11 @@ eth_virtio_dev_init(struct rte_eth_dev
> *eth_dev)
>
> pci_dev = eth_dev->pci_dev;
>
> - rte_eth_copy_pci_info(eth_dev, pci_dev);
> -
> if (virtio_resource_init(pci_dev) < 0)
> return -1;
>
> + rte_eth_copy_pci_info(eth_dev, pci_dev);
> +
> hw->use_msix = virtio_has_msix(&pci_dev->addr);
> hw->io_base = (uint32_t)(uintptr_t)pci_dev-
> >mem_resource[0].addr;
>
> --
> 2.1.4
I think the call to rte_eth_copy_pci_info() needs to be a bit later.
After the following code:
/* If host does not support status then disable LSC */
if (!vtpci_with_feature(hw, VIRTIO_NET_F_STATUS))
pci_dev->driver->drv_flags &= ~RTE_PCI_DRV_INTR_LSC;
I have submitted a patch for this earlier today
http://dpdk.org/dev/patchwork/patch/9345/
Regards,
Bernard.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
@ 2015-12-05 19:47 3% ` Stephen Hemminger
2015-12-05 21:21 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2015-12-05 19:47 UTC (permalink / raw)
To: Glynn, Michael J; +Cc: dev, Betts, Ian
On Sat, 5 Dec 2015 17:53:04 +0000
"Glynn, Michael J" <michael.j.glynn@intel.com> wrote:
>
>
> -----Original Message-----
> From: Betts, Ian
> Sent: Saturday, December 5, 2015 12:07 PM
> To: Thomas Monjalon; Stephen Hemminger
> Cc: dev@dpdk.org; O'Driscoll, Tim; Richardson, Bruce; Glynn, Michael J
> Subject: RE: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
>
>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, December 4, 2015 6:34 PM
> To: Stephen Hemminger
> Cc: dev@dpdk.org; Betts, Ian
> Subject: Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
>
> > Intel may have some milestone to get it into DPDK 2.2 but really this
> > seems too late...
>
> >>>Yes, sure it is too late to have enough discussions in 2.2 timeframe
> >Just to understand what we mean by too late...
> >The original RFC was issued on 2nd September.
> >Thus there have been some three months available for discussion, and for people to raise any questions or concerns.
> >The first patch was available on 30th September, and a number of subsequent patch versions have been issued, meaning the code has been available for review for two month
> >As mentioned in the reply to Stephen, there has been no adverse feedback during this period.
> >/Ian
>
> Hi Thomas/Stephen
>
> I agree with Ian, how much time is expected for a discussion to happen?
>
> As Ian stated, the feature was stated in our 2.2 planned feature list, we created a RFC over 3 months ago, and there's been code available for review for over 2 months now! (not to mention several version updates, docs, etc.).
> Given this, I believe that there has been ample time for the community to review and provide feedback rather than waiting until the eve of RC3 and then requesting more time.
>
> In addition, by making it a sample application first people can test it, see if it's useful, and further enhance it. Based on usefulness and feedback, we can then decide whether to make it a DPDK library in a future release, make it a separate library somewhere else, or do nothing further on it
>
> For these reasons, I believe it should be merged into RC3
Since it is an example and well documented that is fine.
Is there an explicit statement that ABI is not binding for examples?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
2015-12-05 19:47 3% ` Stephen Hemminger
@ 2015-12-05 21:21 0% ` Thomas Monjalon
2015-12-06 6:17 0% ` Betts, Ian
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2015-12-05 21:21 UTC (permalink / raw)
To: Stephen Hemminger, Glynn, Michael J, Betts, Ian; +Cc: dev
> > > Intel may have some milestone to get it into DPDK 2.2 but really this
> > > seems too late...
> >
> > >>>Yes, sure it is too late to have enough discussions in 2.2 timeframe
> > >Just to understand what we mean by too late...
> > >The original RFC was issued on 2nd September.
> > >Thus there have been some three months available for discussion, and for people to raise any questions or concerns.
> > >The first patch was available on 30th September, and a number of subsequent patch versions have been issued, meaning the code has been available for review for two month
> > >As mentioned in the reply to Stephen, there has been no adverse feedback during this period.
> > >/Ian
> >
> > Hi Thomas/Stephen
> >
> > I agree with Ian, how much time is expected for a discussion to happen?
> >
> > As Ian stated, the feature was stated in our 2.2 planned feature list, we created a RFC over 3 months ago, and there's been code available for review for over 2 months now! (not to mention several version updates, docs, etc.).
> > Given this, I believe that there has been ample time for the community to review and provide feedback rather than waiting until the eve of RC3 and then requesting more time.
> >
> > In addition, by making it a sample application first people can test it, see if it's useful, and further enhance it. Based on usefulness and feedback, we can then decide whether to make it a DPDK library in a future release, make it a separate library somewhere else, or do nothing further on it
> >
> > For these reasons, I believe it should be merged into RC3
I am not against this idea.
I just say that we have no time anymore for discussions.
There was no review probably because it is "just" an example.
Given that the code is huge, it would be better to have some good feedback
for its integration. But it does not hurt to integrate anyway.
The only problem is the maintenance overload. When we change something in
a library, every examples must be updated to keep them working.
That's why we must avoid keeping some useless examples.
So this one must be discussed during the 2.3 cycle and will see if we
keep it, shrink it, revert it or move to a library.
> Since it is an example and well documented that is fine.
> Is there an explicit statement that ABI is not binding for examples?
What do you mean by "binding"?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
2015-12-05 21:21 0% ` Thomas Monjalon
@ 2015-12-06 6:17 0% ` Betts, Ian
0 siblings, 0 replies; 200+ results
From: Betts, Ian @ 2015-12-06 6:17 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger, Glynn, Michael J; +Cc: dev
-----Original Message-----
From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
Sent: Saturday, December 5, 2015 9:21 PM
To: Stephen Hemminger; Glynn, Michael J; Betts, Ian
Cc: dev@dpdk.org; O'Driscoll, Tim; Richardson, Bruce
Subject: Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
> > > Intel may have some milestone to get it into DPDK 2.2 but really
> > > this seems too late...
> >
> > >>>Yes, sure it is too late to have enough discussions in 2.2
> > >>>timeframe
> > >Just to understand what we mean by too late...
> > >The original RFC was issued on 2nd September.
> > >Thus there have been some three months available for discussion, and for people to raise any questions or concerns.
> > >The first patch was available on 30th September, and a number of
> > >subsequent patch versions have been issued, meaning the code has been available for review for two month As mentioned in the reply to Stephen, there has been no adverse feedback during this period.
> > >/Ian
> >
> > Hi Thomas/Stephen
> >
> > I agree with Ian, how much time is expected for a discussion to happen?
> >
> > As Ian stated, the feature was stated in our 2.2 planned feature list, we created a RFC over 3 months ago, and there's been code available for review for over 2 months now! (not to mention several version updates, docs, etc.).
> > Given this, I believe that there has been ample time for the community to review and provide feedback rather than waiting until the eve of RC3 and then requesting more time.
> >
> > In addition, by making it a sample application first people can test
> > it, see if it's useful, and further enhance it. Based on usefulness
> > and feedback, we can then decide whether to make it a DPDK library
> > in a future release, make it a separate library somewhere else, or
> > do nothing further on it
> >
> > For these reasons, I believe it should be merged into RC3
I am not against this idea.
I just say that we have no time anymore for discussions.
There was no review probably because it is "just" an example.
Given that the code is huge, it would be better to have some good feedback for its integration. But it does not hurt to integrate anyway.
The only problem is the maintenance overload. When we change something in a library, every examples must be updated to keep them working.
That's why we must avoid keeping some useless examples.
So this one must be discussed during the 2.3 cycle and will see if we keep it, shrink it, revert it or move to a library.
> Since it is an example and well documented that is fine.
> Is there an explicit statement that ABI is not binding for examples?
>What do you mean by "binding"?
I think these are fair comments.
I do take the point about maintenance overhead, there is no value in dragging along
something that is not being used. After making it available and allowing time for
users to explore we can gauge the answer best.
Feedback should inform the direction, and whilst we do continue pathfinding activity internally,
in fact we had not planned any updates during the 2.3 cycle, precisely to allow time
to understand if/how the community would like to see it evolve.
So personally I see 2.4 as an appropriate target to implement whatever we decide.
^ permalink raw reply [relevance 0%]
Results 1201-1400 of ~18000 next (newer) | prev (older) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2015-09-20 14:51 [dpdk-dev] [PATCH 0/2] i40e: enlarge the number of supported queues Helin Zhang
2015-10-22 7:28 ` [dpdk-dev] [PATCH v2 0/2] i40e: Enlarge " Helin Zhang
2015-10-22 7:28 ` [dpdk-dev] [PATCH v2 2/2] " Helin Zhang
2015-11-03 1:16 3% ` Thomas Monjalon
2015-11-03 2:49 0% ` Zhang, Helin
2015-11-03 15:40 ` [dpdk-dev] [PATCH v3 0/2] " Helin Zhang
2015-11-03 15:40 9% ` [dpdk-dev] [PATCH v3 2/2] " Helin Zhang
2015-09-22 3:45 [dpdk-dev] [PATCH 0/4] extend flow director to support VF filtering in i40e driver Jingjing Wu
2015-10-28 8:41 ` [dpdk-dev] [PATCH v2 " Jingjing Wu
2015-10-30 7:42 0% ` Zhang, Helin
2015-10-31 16:24 ` [dpdk-dev] [PATCH v3 0/3] " Jingjing Wu
2015-10-31 16:24 17% ` [dpdk-dev] [PATCH v3 1/3] ethdev: extend struct to support flow director in VFs Jingjing Wu
2015-11-04 3:29 ` [dpdk-dev] [PATCH v4 0/3] extend flow drector to support VF filtering in i40e driver Jingjing Wu
2015-11-04 3:29 17% ` [dpdk-dev] [PATCH v4 1/3] ethdev: extend struct to support flow director in VFs Jingjing Wu
2015-09-24 7:34 [dpdk-dev] [PATCH 0/3] Minor abi-validator improvements Panu Matilainen
2015-09-24 7:50 ` [dpdk-dev] [PATCH 0/3 v2] " Panu Matilainen
2015-09-24 10:23 ` Neil Horman
2015-11-11 7:07 4% ` Panu Matilainen
2015-11-11 10:16 4% ` Thomas Monjalon
2015-11-11 10:24 4% ` Panu Matilainen
2015-12-03 19:38 4% ` Thomas Monjalon
2015-10-02 15:20 [dpdk-dev] [PATCH 0/3] add sample ptp slave application Daniel Mrzyglod
2015-10-30 9:43 ` [dpdk-dev] [PATCH v2 0/6] " Daniel Mrzyglod
2015-10-30 9:43 4% ` [dpdk-dev] [PATCH v2 1/6] ethdev: add additional ieee1588 support functions Daniel Mrzyglod
2015-11-03 16:38 ` [dpdk-dev] [PATCH v3 0/7] add sample ptp slave application Daniel Mrzyglod
2015-11-03 16:38 4% ` [dpdk-dev] [PATCH v3 1/7] ethdev: add additional ieee1588 support functions Daniel Mrzyglod
2015-11-04 10:06 ` [dpdk-dev] [PATCH v4 0/7] add sample ptp slave application Daniel Mrzyglod
2015-11-04 10:06 4% ` [dpdk-dev] [PATCH v4 1/7] ethdev: add additional ieee1588 support functions Daniel Mrzyglod
2015-11-05 14:05 ` [dpdk-dev] [PATCH v5 0/7] add sample ptp slave application Daniel Mrzyglod
2015-11-05 14:06 4% ` [dpdk-dev] [PATCH v5 1/7] ethdev: add additional ieee1588 support functions Daniel Mrzyglod
2015-10-05 17:57 [dpdk-dev] [PATCH 0/3] Add RETA configuration to mlx5 Adrien Mazarguil
2015-10-30 18:58 3% ` [dpdk-dev] [PATCH v2 " Adrien Mazarguil
2015-10-15 16:51 [dpdk-dev] [PATCH] add a dpdk contributors guide John McNamara
2015-11-20 12:46 2% ` [dpdk-dev] [PATCH v4] doc: add " John McNamara
2015-10-19 15:36 [dpdk-dev] [PATCH v6 0/4] bonding corrections and additions Eric Kinzie
2015-10-19 15:36 ` [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine Eric Kinzie
2015-11-01 18:17 ` Thomas Monjalon
2015-11-01 23:17 4% ` [dpdk-dev] [PATCH] mk: fix ABI versioning compile error for combined shared library Ferruh Yigit
2015-11-01 23:24 4% ` Thomas Monjalon
2015-11-02 0:05 4% ` Ferruh Yigit
2015-11-02 7:10 4% ` Thomas Monjalon
2015-11-02 10:20 4% ` Ferruh Yigit
2015-11-02 15:23 4% ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
2015-11-02 16:26 4% ` Thomas Monjalon
2015-11-02 19:18 4% ` Ferruh Yigit
2015-11-03 7:06 4% ` Panu Matilainen
2015-11-03 9:20 8% ` Ferruh Yigit
2015-11-03 10:41 4% ` Panu Matilainen
2015-11-03 11:33 4% ` Ferruh Yigit
2015-11-03 11:43 4% ` Panu Matilainen
2015-11-06 13:58 7% ` [dpdk-dev] [PATCH] " Ferruh Yigit
2015-11-06 13:58 4% ` Ferruh Yigit
2015-11-02 10:23 3% ` [dpdk-dev] [PATCH v6 3/4] bond mode 4: allow external state machine Panu Matilainen
2015-11-02 16:42 0% ` Eric Kinzie
2015-11-03 6:48 4% ` Panu Matilainen
2015-11-03 8:16 0% ` Thomas Monjalon
2015-11-03 8:30 0% ` Panu Matilainen
2015-11-03 9:38 0% ` Thomas Monjalon
2015-11-03 17:12 0% ` Eric Kinzie
2015-11-03 11:02 0% ` Ferruh Yigit
2015-11-03 11:31 0% ` Panu Matilainen
2015-11-03 11:48 0% ` Ferruh Yigit
2015-11-20 19:46 0% ` Eric Kinzie
2015-11-24 14:52 0% ` Panu Matilainen
2015-10-20 2:41 [dpdk-dev] [PATCH] doc: Add missing new line before code block Tetsuya Mukawa
2015-10-28 9:33 ` Mcnamara, John
2015-11-05 2:11 0% ` Tetsuya Mukawa
2015-10-28 17:11 [dpdk-dev] [PATCH v4 0/7] librte_table: add key_mask parameter to roy.fan.zhang
2015-11-25 22:33 0% ` Thomas Monjalon
2015-10-29 4:09 [dpdk-dev] [PATCH v5 0/2] i40e: RSS/FD granularity configuration Helin Zhang
2015-10-29 6:02 ` [dpdk-dev] [PATCH v6 0/3] " Helin Zhang
2015-10-29 6:02 ` [dpdk-dev] [PATCH v6 1/3] " Helin Zhang
2015-10-29 9:38 ` Bruce Richardson
2015-10-30 1:58 4% ` Zhang, Helin
2015-10-30 3:11 3% ` [dpdk-dev] [PATCH v7 0/2] " Helin Zhang
2015-10-30 3:11 4% ` [dpdk-dev] [PATCH v7 1/2] " Helin Zhang
2015-10-30 13:46 4% ` Thomas Monjalon
2015-11-02 2:11 4% ` Zhang, Helin
2015-11-02 7:27 3% ` Thomas Monjalon
2015-11-02 7:59 0% ` Zhang, Helin
2015-11-02 8:23 3% ` Thomas Monjalon
2015-10-30 7:59 0% ` [dpdk-dev] [PATCH v7 0/2] " Wu, Jingjing
2015-11-02 14:32 4% ` [dpdk-dev] [PATCH v8 " Helin Zhang
2015-11-02 14:32 5% ` [dpdk-dev] [PATCH v8 1/2] " Helin Zhang
2015-11-03 16:07 4% ` [dpdk-dev] [PATCH v9 0/2] " Helin Zhang
2015-11-03 16:07 5% ` [dpdk-dev] [PATCH v9 1/2] " Helin Zhang
2015-10-29 8:53 [dpdk-dev] [PATCH v2 00/10] enable DCB feature on Intel XL710/X710 NIC Jingjing Wu
2015-10-31 15:57 ` [dpdk-dev] [PATCH v3 0/9] " Jingjing Wu
2015-10-31 15:57 4% ` [dpdk-dev] [PATCH v3 1/9] ethdev: rename dcb_queue to dcb_tc in dcb config struct Jingjing Wu
2015-10-29 18:27 [dpdk-dev] [PATCH 0/5] ARMv8 additions to ARMv7 support Thomas Monjalon
2015-10-30 0:25 ` [dpdk-dev] [PATCH v5 00/15] Support ARMv7 architecture Jan Viktorin
2015-10-30 0:25 3% ` [dpdk-dev] [PATCH v5 14/15] mk: Introduce " Jan Viktorin
2015-10-30 12:00 4% [dpdk-dev] lpm patches Bruce Richardson
2015-10-30 17:59 0% ` Matthew Hall
2015-10-30 19:34 0% ` Vladimir Medvedkin
2015-10-30 21:55 0% ` Bruce Richardson
2015-11-02 3:58 [dpdk-dev] [PATCH v2 1/2] vhost: Add callback and private data for vhost PMD Tetsuya Mukawa
2015-11-09 5:16 ` [dpdk-dev] [PATCH v3 0/2] Add VHOST PMD Tetsuya Mukawa
2015-11-09 5:17 ` [dpdk-dev] [PATCH v3 1/2] vhost: Add callback and private data for vhost PMD Tetsuya Mukawa
2015-11-09 18:16 3% ` Aaron Conole
2015-11-10 3:13 0% ` Tetsuya Mukawa
2015-11-10 7:16 3% ` Panu Matilainen
2015-11-10 9:48 3% ` Tetsuya Mukawa
2015-11-10 10:05 3% ` Panu Matilainen
2015-11-10 10:15 0% ` Tetsuya Mukawa
2015-11-02 23:47 [dpdk-dev] [PATCH v6 00/15] Support ARMv7 architecture Jan Viktorin
2015-11-02 23:47 3% ` [dpdk-dev] [PATCH v6 14/15] mk: Introduce " Jan Viktorin
2015-11-03 12:00 [dpdk-dev] [PATCH v3 0/4] ethdev: minor cleanup Bruce Richardson
2015-11-17 12:21 ` [dpdk-dev] [PATCH v4 0/2] ethdev: debug code cleanup Bruce Richardson
2015-11-17 12:21 ` [dpdk-dev] [PATCH v4 2/2] ethdev: add sanity checks to functions Bruce Richardson
2015-11-17 15:53 3% ` Stephen Hemminger
2015-11-24 14:56 3% ` Bruce Richardson
2015-11-24 15:29 4% ` Thomas Monjalon
2015-11-24 15:45 4% ` Bruce Richardson
2015-11-24 15:48 0% ` Thomas Monjalon
2015-11-24 17:37 3% ` [dpdk-dev] [PATCH v5 0/2] ethdev: debug code cleanup Bruce Richardson
2015-11-24 17:37 4% ` [dpdk-dev] [PATCH v5 1/2] ethdev: remove duplicated debug functions Bruce Richardson
2015-11-24 17:37 4% ` [dpdk-dev] [PATCH v5 2/2] ethdev: add sanity checks to functions Bruce Richardson
2015-11-05 9:58 [dpdk-dev] [PATCH] cmdline: increase commandline buffer size to 512 John McNamara
2015-11-05 16:50 3% ` Nélio Laranjeiro
2015-11-09 11:45 4% ` Mcnamara, John
2015-11-09 15:54 0% ` Nélio Laranjeiro
[not found] <1446658952-101192-1-git-send-email-huawei.xie@intel.com>
2015-11-05 10:21 ` [dpdk-dev] [RFC PATCH] vhost: remove lockless enqueue to virt ring Xie, Huawei
2015-11-06 1:42 ` Tetsuya Mukawa
2015-11-06 5:33 3% ` Xie, Huawei
2015-11-06 10:24 [dpdk-dev] [PATCH] reserve 'make install' for future use Bruce Richardson
2015-11-06 10:24 2% ` [dpdk-dev] [PATCH] mk: rename 'make install' to 'make sdk' Bruce Richardson
2015-11-09 16:48 9% [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size Nelio Laranjeiro
2015-11-09 16:48 9% ` [dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA configuration Nelio Laranjeiro
2015-11-10 17:29 4% ` [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size Mcnamara, John
2015-11-20 16:28 4% ` Olivier MATZ
2015-11-20 16:33 4% ` Bruce Richardson
2015-12-03 16:32 4% ` Mcnamara, John
2015-11-10 3:11 11% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow Jingjing Wu
2015-11-12 3:10 4% ` Lu, Wenzhuo
2015-11-12 3:23 4% ` Zhang, Helin
2015-11-12 10:09 4% ` Chilikin, Andrey
2015-11-10 3:49 11% [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_filter_conf Jingjing Wu
2015-11-12 3:11 4% ` Lu, Wenzhuo
2015-11-12 3:23 4% ` Zhang, Helin
2015-11-10 17:32 [dpdk-dev] [PATCH v6 00/10] Crypto API and device framework Declan Doherty
2015-11-13 18:58 ` [dpdk-dev] [PATCH v7 " Declan Doherty
2015-11-13 18:58 ` [dpdk-dev] [PATCH v7 06/10] mbuf_offload: library to support attaching offloads to a mbuf Declan Doherty
2015-11-20 15:27 ` Olivier MATZ
2015-11-20 17:26 ` Declan Doherty
2015-11-23 9:10 ` Olivier MATZ
2015-11-23 11:52 ` Ananyev, Konstantin
2015-11-23 12:16 3% ` Declan Doherty
2015-11-23 13:08 0% ` Olivier MATZ
2015-11-23 14:17 0% ` Thomas Monjalon
2015-11-23 14:33 3% ` Declan Doherty
2015-11-13 17:54 3% [dpdk-dev] [PATCH 00/10] rte_sched: enhancements and cleanups Stephen Hemminger
2015-11-13 17:58 3% [dpdk-dev] [PATCH v2 " Stephen Hemminger
2015-11-13 17:58 3% ` [dpdk-dev] [PATCH v2 10/10] sched: allow more subports Stephen Hemminger
2015-11-24 23:34 0% ` [dpdk-dev] [PATCH v2 00/10] rte_sched: enhancements and cleanups Thomas Monjalon
2015-11-16 13:42 [dpdk-dev] [PATCH v8 0/2] User-space ethtool sample application Remy Horton
2015-11-20 15:34 3% ` [dpdk-dev] [PATCH v9 0/3] " Remy Horton
2015-11-20 15:34 4% ` [dpdk-dev] [PATCH v9 1/3] Remove ABI requirement for external library builds Remy Horton
[not found] ` <2601191342CEEE43887BDE71AB97725836ACAB5A@irsmsx105.ger.corp.intel.com>
2015-11-20 16:32 4% ` Wang, Liang-min
2015-11-24 3:05 0% ` [dpdk-dev] [PATCH v9 0/3] User-space ethtool sample application Liu, Yong
2015-11-18 14:05 [dpdk-dev] [PATCH v5 0/3] Keepalive monitoring & reporting Remy Horton
2015-11-18 14:05 3% ` [dpdk-dev] [PATCH v5 2/3] docs: add keep alive sample app guide & release notes Remy Horton
2015-11-21 8:49 3% [dpdk-dev] difficulty w/ RTE_NEXT_ABI Matthew Hall
2015-11-21 10:44 0% ` Thomas Monjalon
2015-11-22 0:25 ` Matthew Hall
2015-11-22 20:59 3% ` Thomas Monjalon
2015-11-22 23:25 5% ` Matthew Hall
2015-11-23 0:13 5% ` Thomas Monjalon
2015-11-23 3:53 0% ` Matthew Hall
2015-11-23 18:37 [dpdk-dev] Can't compile DPDK if both CONFIG_RTE_BUILD_COMBINE_LIBS and LIBRTE_PMD_XENVIRT are set to "yes" Martinx - ジェームズ
2015-11-24 13:57 ` Panu Matilainen
2015-11-24 14:46 ` Sergio Gonzalez Monroy
2015-11-24 15:22 ` Panu Matilainen
2015-11-24 15:30 ` Martinx - ジェームズ
2015-11-24 15:53 ` Panu Matilainen
2015-11-25 0:26 4% ` Martinx - ジェームズ
2015-11-25 8:44 4% ` Panu Matilainen
2015-11-24 14:31 4% [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script Panu Matilainen
2015-11-24 22:46 ` Stephen Hemminger
2015-11-25 8:38 ` Panu Matilainen
2015-11-25 16:08 ` Stephen Hemminger
2015-11-30 15:03 ` Neil Horman
2015-11-30 16:41 ` Stephen Hemminger
2015-12-01 12:21 ` Panu Matilainen
2015-12-01 12:36 4% ` Robie Basak
2015-12-01 13:30 0% ` Neil Horman
2015-12-01 12:37 4% ` Robie Basak
2015-12-02 11:44 3% ` Neil Horman
2015-12-03 1:31 0% ` Ferruh Yigit
2015-12-03 8:11 3% ` Christian Ehrhardt
2015-12-03 14:59 0% ` Neil Horman
2015-11-25 16:19 [dpdk-dev] [PATCH v8 0/9] support for netronome nfp-6xxx card Alejandro.Lucero
2015-11-25 16:19 ` [dpdk-dev] [PATCH v8 1/9] nfp: basic initialization Alejandro.Lucero
2015-11-25 18:47 3% ` Thomas Monjalon
2015-11-25 17:38 5% [dpdk-dev] [PATCH] cryptodev: mark experimental state Thomas Monjalon
2015-11-26 7:39 3% ` Panu Matilainen
2015-11-26 8:00 0% ` Panu Matilainen
2015-11-26 10:08 0% ` Thomas Monjalon
2015-11-26 13:51 0% ` Doherty, Declan
2015-11-27 13:09 0% ` Panu Matilainen
2015-11-27 13:30 0% ` Thomas Monjalon
2015-11-25 23:41 7% [dpdk-dev] ABI changes in release notes Thomas Monjalon
2015-11-29 18:46 [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 Stephen Hemminger
2015-11-29 18:46 3% ` [dpdk-dev] [PATCH 3/3] rte_sched: eliminate floating point in calculating byte clock Stephen Hemminger
2015-12-02 16:48 0% ` Dumitrescu, Cristian
2015-12-02 22:08 0% ` Stephen Hemminger
2015-11-30 12:49 [dpdk-dev] Query on Filtering Support in DPDK Rahul Lakkireddy
2015-11-30 13:43 3% ` Thomas Monjalon
2015-12-02 8:05 3% ` Rahul Lakkireddy
2015-11-30 17:24 [dpdk-dev] [PATCH 0/3] add lpm support for NEON Jerin Jacob
2015-11-30 17:24 ` [dpdk-dev] [PATCH 1/3] eal: introduce rte_vect_* abstractions Jerin Jacob
2015-12-02 13:43 3% ` Jan Viktorin
2015-12-02 14:51 0% ` Jerin Jacob
2015-12-01 18:41 [dpdk-dev] [PATCH 0/4] support acl/lpm/table/pipeline libs for armv7 and armv8 Jianbo Liu
2015-12-01 18:41 ` [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs Jianbo Liu
2015-12-01 16:41 4% ` Jerin Jacob
2015-12-02 7:02 3% ` Jianbo Liu
[not found] ` <CAP4Qi3-5ofDU-2-4KsxFzMC1OpTsc5WjmxcFT2Eu_URA0UBzDw@mail.gmail.com>
2015-12-02 8:03 0% ` Jerin Jacob
2015-12-02 9:49 0% ` Jianbo Liu
2015-12-02 10:39 0% ` Jerin Jacob
2015-12-02 13:13 0% ` Jianbo Liu
2015-12-02 14:34 3% ` Jerin Jacob
2015-12-02 16:40 0% ` Thomas Monjalon
2015-12-02 16:53 0% ` Jerin Jacob
2015-12-02 16:57 3% ` Thomas Monjalon
2015-12-02 17:38 0% ` Jerin Jacob
2015-12-03 9:33 0% ` Jerin Jacob
2015-12-03 11:02 3% ` Ananyev, Konstantin
2015-12-03 12:17 3% ` Jerin Jacob
2015-12-03 12:42 0% ` Ananyev, Konstantin
2015-12-03 13:20 0% ` Jerin Jacob
2015-12-02 3:43 [dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support Yuanhan Liu
2015-12-02 3:43 ` [dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request Yuanhan Liu
2015-12-02 13:53 4% ` Panu Matilainen
2015-12-02 14:31 5% ` Yuanhan Liu
2015-12-02 14:48 4% ` Panu Matilainen
2015-12-02 15:09 0% ` Yuanhan Liu
2015-12-02 16:58 0% ` Panu Matilainen
2015-12-02 17:24 3% ` Michael S. Tsirkin
2015-12-02 16:38 4% ` Thomas Monjalon
2015-12-03 1:49 0% ` Yuanhan Liu
2015-12-02 16:50 36% [dpdk-dev] [PATCH] scripts: support any legal git revisions as abi validation range Panu Matilainen
2015-12-02 18:23 4% ` Neil Horman
2015-12-03 12:14 29% ` Mcnamara, John
2015-12-03 13:28 4% ` Thomas Monjalon
2015-12-03 13:44 4% ` Panu Matilainen
2015-12-03 13:49 4% ` Richardson, Bruce
2015-12-03 15:46 4% ` Mcnamara, John
2015-12-03 13:39 7% ` Panu Matilainen
2015-12-03 13:41 4% ` Thomas Monjalon
2015-12-03 14:05 36% ` [dpdk-dev] [PATCH v2] " Panu Matilainen
2015-12-03 1:22 4% [dpdk-dev] [PATCH v2] mk: fix compile error and ABI versioning for combined shared library Ferruh Yigit
2015-12-03 1:36 4% ` Thomas Monjalon
2015-12-03 1:59 4% ` Ferruh Yigit
2015-12-03 2:15 4% ` [dpdk-dev] [PATCH v3] " Ferruh Yigit
2015-12-03 2:22 4% ` Thomas Monjalon
2015-12-03 11:24 4% ` Ferruh Yigit
2015-12-03 8:18 4% ` [dpdk-dev] [PATCH v2] " Christian Ehrhardt
2015-12-03 11:18 4% ` Ferruh Yigit
2015-12-03 14:01 4% ` Ferruh Yigit
2015-12-03 12:49 7% ` Panu Matilainen
2015-12-03 13:51 4% ` [dpdk-dev] [PATCH v4] " Ferruh Yigit
2015-12-03 1:38 3% [dpdk-dev] [PATCH] eal: don't crash if one pci device fails Stephen Hemminger
2015-12-03 10:02 0% ` Bruce Richardson
2015-12-03 10:08 0% ` David Marchand
2015-12-03 2:27 3% [dpdk-dev] [PATCH] vhost: reserve some spaces for virtio_net and vhost_virtqueue struct Yuanhan Liu
2015-12-03 16:21 [dpdk-dev] [PATCH v7 2/4] examples: add lthread subsystem for performance-thread Ian Betts
2015-12-04 10:34 ` [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread Ian Betts
2015-12-04 18:03 ` Stephen Hemminger
2015-12-04 18:33 ` Thomas Monjalon
2015-12-05 12:06 ` Betts, Ian
2015-12-05 17:53 ` Glynn, Michael J
2015-12-05 19:47 3% ` Stephen Hemminger
2015-12-05 21:21 0% ` Thomas Monjalon
2015-12-06 6:17 0% ` Betts, Ian
2015-12-04 2:08 3% [dpdk-dev] [PATCH] virtio: fix link state regression Stephen Hemminger
2015-12-04 3:29 0% ` Yuanhan Liu
2015-12-04 15:25 0% ` Iremonger, Bernard
2015-12-04 15:27 0% ` Thomas Monjalon
2015-12-04 15:59 3% [dpdk-dev] [PATCH resend] " Stephen Hemminger
2015-12-04 16:18 0% ` Iremonger, Bernard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).