[dpdk-dev] [PATCH v4 1/2] config: use defconfig_arm64-armv8a-linuxapp-gcc as base for arm64 targets
Reviewed-by: Jianbo Liu On 1 December 2015 at 01:20, Jerin Jacob wrote: > let each armv8 machine targets capture only the differences > between the common defconfig_arm64-armv8a-linuxapp-gcc > > Suggested-by: Thomas Monjalon > Signed-off-by: Jerin Jacob > --- > config/defconfig_arm64-thunderx-linuxapp-gcc | 22 +- > config/defconfig_arm64-xgene1-linuxapp-gcc | 24 +--- > 2 files changed, 2 insertions(+), 44 deletions(-) > > diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc b/config/defconfig_arm64-thunderx-linuxapp-gcc > index 6b2048b..fe5e987 100644 > --- a/config/defconfig_arm64-thunderx-linuxapp-gcc > +++ b/config/defconfig_arm64-thunderx-linuxapp-gcc > @@ -29,28 +29,8 @@ > # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > # > > -#include "common_linuxapp" > +#include "defconfig_arm64-armv8a-linuxapp-gcc" > > CONFIG_RTE_MACHINE="thunderx" > > -CONFIG_RTE_ARCH="arm64" > -CONFIG_RTE_ARCH_ARM64=y > -CONFIG_RTE_ARCH_64=y > -CONFIG_RTE_ARCH_ARM_NEON=y > - > -CONFIG_RTE_FORCE_INTRINSICS=y > - > -CONFIG_RTE_TOOLCHAIN="gcc" > -CONFIG_RTE_TOOLCHAIN_GCC=y > - > CONFIG_RTE_CACHE_LINE_SIZE=128 > - > -CONFIG_RTE_IXGBE_INC_VECTOR=n > -CONFIG_RTE_LIBRTE_VIRTIO_PMD=n > -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 > diff --git a/config/defconfig_arm64-xgene1-linuxapp-gcc b/config/defconfig_arm64-xgene1-linuxapp-gcc > index d75f8f0..f096166 100644 > --- a/config/defconfig_arm64-xgene1-linuxapp-gcc > +++ b/config/defconfig_arm64-xgene1-linuxapp-gcc > @@ -29,28 +29,6 @@ > # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > # > > -#include "common_linuxapp" > +#include "defconfig_arm64-armv8a-linuxapp-gcc" > > CONFIG_RTE_MACHINE="xgene1" > - > -CONFIG_RTE_ARCH="arm64" > -CONFIG_RTE_ARCH_ARM64=y > -CONFIG_RTE_ARCH_64=y > -CONFIG_RTE_ARCH_ARM_NEON=y > - > -CONFIG_RTE_FORCE_INTRINSICS=y > - > -CONFIG_RTE_TOOLCHAIN="gcc" > -CONFIG_RTE_TOOLCHAIN_GCC=y > - > -CONFIG_RTE_CACHE_LINE_SIZE=64 > - > -CONFIG_RTE_IXGBE_INC_VECTOR=n > -CONFIG_RTE_LIBRTE_VIRTIO_PMD=n > -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 > -- > 2.1.0 >
[dpdk-dev] DPDK OVS on Ubuntu 14.04
Dear All, We are trying to install DPDK OVS on top of the openstack juno in Ubuntu 14.04 single server. We are referring following steps for executing the same. https://software.intel.com/en-us/blogs/2015/06/09/building-vhost-user-for-ovs-today-using-dpdk-200 During execution we are getting some issues with ovs-vswitchd service as its getting hang during starting. _ nfv-dpdk at nfv-dpdk:~$ tail -f /var/log/openvswitch/ovs-vswitchd.log 2015-11-24T10:54:34.036Z|6|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connecting... 2015-11-24T10:54:34.036Z|7|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connected 2015-11-24T10:54:34.064Z|8|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.4.90 2015-11-24T11:03:42.957Z|2|vlog|INFO|opened log file /var/log/openvswitch/ov s-vswitchd.log 2015-11-24T11:03:42.958Z|3|ovs_numa|INFO|Discovered 24 CPU cores on NUMA nod e 0 2015-11-24T11:03:42.958Z|4|ovs_numa|INFO|Discovered 24 CPU cores on NUMA nod e 1 2015-11-24T11:03:42.958Z|5|ovs_numa|INFO|Discovered 2 NUMA nodes and 48 CPU cores 2015-11-24T11:03:42.958Z|6|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connecting... 2015-11-24T11:03:42.958Z|7|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connected 2015-11-24T11:03:42.961Z|8|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.4.90 _ Also, attaching output(Hugepage.txt) of ? ./ovs-vswitchd --dpdk -c 0x0FF8 -n 4 --socket-mem 1024,0 -- --log-file=/var/log/openvswitch/ovs-vswitchd.log --pidfile=/var/run/oppenvswitch/ovs-vswitchd.pid? - We tried seting up echo 0 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages, but couldn?t succeeded. Can anyone please help us in getting the things if we are missing any and causing ovs-vswitchd to stuck while starting? Also, when we create vm in openstack with DPDK OVS, dpdkvhost-user type interfaces are getting created automatically. If this interfaces are getting mapped with regular br-int bridge rather than DPDK bridge br0 then is this mean that we have successfully enabled DPDK with netdev datapath? We really appreciate for all the advice if you have. Thanks, Abhijeet Thanks & Regards Abhijeet Karve =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -- next part -- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 108749 bytes Desc: not available URL: <http://dpdk.org/ml/archives/dev/attachments/20151201/1321e9df/attachment-0001.png> -- next part -- An embedded and charset-unspecified text was scrubbed... Name: Hugepage issue.txt URL: <http://dpdk.org/ml/archives/dev/attachments/20151201/1321e9df/attachment-0001.txt>
[dpdk-dev] running dpdk 2.1 on openstak causes CPU soft lockup
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nissim Nisimov > Sent: lundi 23 novembre 2015 20:44 > To: dev at dpdk.org > Subject: [dpdk-dev] running dpdk 2.1 on openstak causes CPU soft lockup > > Hi, > > I am running DPDK 2.1.0 based app on OpenStack KVM guest. OS of guest is > Ubuntu LTS 14.04 3.13 kernel. > virtio. > > After upgrade to dpdk 2.1 (previous version was dpdk 1.8 and it worked fine) > we are seeing the following issue: > > [960.004535] BUG: soft lockup - CPU#3 stuck for 23s! [ip:8419] > > The message will be printed in an endless loop and the system won't > recover. > > Is it a known issue in dpdk 2.1? any patch I can apply in order to overcome > this? > > > Thx > Nissim Do you have virtIO interfaces in your guest, with at least one (usually the first one, used for cloud-init) used by the kernel? If so, even if they are in use by the kernel, DPDK virtIO driver will attach to them (without detaching the kernel), leading to either kernel crash or infinite loops. Until DPDK 1.8.0 included, you had to explicitly bind the virtIO interfaces, via igb_uio. But since DPDK 2.x, all non-blacklisted interfaces are bound. Franck This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Ce message et toutes ses pi?ces jointes (ci-apr?s le "message")sont confidentiels et ?tablis ? l'intention exclusive de ses destinataires. Si vous avez re?u ce message par erreur, merci d?en informer imm?diatement son ?metteur par courrier ?lectronique et d?effacer ce message de votre syst?me. Dans cette hypoth?se, vous n??tes pas autoris? ? utiliser, copier ce message et/ou en divulguer le contenu ? un tiers. Tout message ?lectronique est susceptible d'alt?ration. Qosmos et ses filiales d?clinent toute responsabilit? au titre de ce message s'il a ?t? alt?r?, d?form? ou falsifi?.
[dpdk-dev] running dpdk 2.1 on openstak causes CPU soft lockup
Yup this is exactly our issue. We blacked list the specific interface and its working again. Thx Nissim -Original Message- From: Franck BAUDIN [mailto:franck.bau...@qosmos.com] Sent: Tuesday, December 01, 2015 2:20 PM To: Nissim Nisimov; dev at dpdk.org Subject: RE: running dpdk 2.1 on openstak causes CPU soft lockup > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nissim Nisimov > Sent: lundi 23 novembre 2015 20:44 > To: dev at dpdk.org > Subject: [dpdk-dev] running dpdk 2.1 on openstak causes CPU soft > lockup > > Hi, > > I am running DPDK 2.1.0 based app on OpenStack KVM guest. OS of guest > is Ubuntu LTS 14.04 3.13 kernel. > virtio. > > After upgrade to dpdk 2.1 (previous version was dpdk 1.8 and it worked > fine) we are seeing the following issue: > > [960.004535] BUG: soft lockup - CPU#3 stuck for 23s! [ip:8419] > > The message will be printed in an endless loop and the system won't > recover. > > Is it a known issue in dpdk 2.1? any patch I can apply in order to > overcome this? > > > Thx > Nissim Do you have virtIO interfaces in your guest, with at least one (usually the first one, used for cloud-init) used by the kernel? If so, even if they are in use by the kernel, DPDK virtIO driver will attach to them (without detaching the kernel), leading to either kernel crash or infinite loops. Until DPDK 1.8.0 included, you had to explicitly bind the virtIO interfaces, via igb_uio. But since DPDK 2.x, all non-blacklisted interfaces are bound. Franck This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Ce message et toutes ses pi?ces jointes (ci-apr?s le "message")sont confidentiels et ?tablis ? l'intention exclusive de ses destinataires. Si vous avez re?u ce message par erreur, merci d?en informer imm?diatement son ?metteur par courrier ?lectronique et d?effacer ce message de votre syst?me. Dans cette hypoth?se, vous n??tes pas autoris? ? utiliser, copier ce message et/ou en divulguer le contenu ? un tiers. Tout message ?lectronique est susceptible d'alt?ration. Qosmos et ses filiales d?clinent toute responsabilit? au titre de ce message s'il a ?t? alt?r?, d?form? ou falsifi?.
[dpdk-dev] 2.3 Roadmap
On Mon, Nov 30, 2015 at 05:16:55PM -0800, Stephen Hemminger wrote: > On Mon, 30 Nov 2015 22:53:50 + > Kyle Larose wrote: > > > Hi Tim, > > > > On Mon, Nov 30, 2015 at 3:50 PM, O'Driscoll, Tim > intel.com> wrote: > > > > > Tcpdump Support: Support for tcpdump will be added to DPDK. This will > > > improve usability and debugging of DPDK applications. > > > > I'm curious about the proposed tcpdump support. Is there a concrete plan > > for this, or is that still being looked into? Sandvine is interested in > > contributing to this effort. Anything we can do to help? > > > > Thanks, > > > > Kyle > > We discussed an Ovscon doing a simple example of how to have a thread use > named pipe > support (already in tcpdump and wireshark). More complex solutions require > changes to > libpcap and application interaction. Our current thinking is to use kni to mirror packets into the kernel itself, so that all standard linux capture tools can then be used. /Bruce
[dpdk-dev] [PATCH] ixgbe: fix tx_bytes statistic with link down
This patch fixes tx byte statistics when transmitting packets
with link down.
Previously, the counter would decrement 4 bytes for each packet that
was transmitted with link down, causing the uint64 to wrap around.
Fixes: c03fcee9abbd ("ixgbe: remove CRC size from byte counters")
Reported-by: Michael Qiu
Signed-off-by: Harry van Haaren
---
drivers/net/ixgbe/ixgbe_ethdev.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 808ac69..1b6cd8e 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2341,7 +2341,6 @@ ixgbe_read_stats_registers(struct ixgbe_hw *hw,
{
uint32_t bprc, lxon, lxoff, total;
uint32_t delta_gprc = 0;
- uint32_t delta_gptc = 0;
unsigned i;
/* Workaround for RX byte count not including CRC bytes when CRC
+ * strip is enabled. CRC bytes are removed from counters when crc_strip
@@ -2388,7 +2387,6 @@ ixgbe_read_stats_registers(struct ixgbe_hw *hw,
uint32_t delta_qprdc = IXGBE_READ_REG(hw, IXGBE_QPRDC(i));
delta_gprc += delta_qprc;
- delta_gptc += delta_qptc;
hw_stats->qprc[i] += delta_qprc;
hw_stats->qptc[i] += delta_qptc;
@@ -2444,6 +2442,8 @@ ixgbe_read_stats_registers(struct ixgbe_hw *hw,
if (crc_strip == 0)
hw_stats->gorc -= delta_gprc * ETHER_CRC_LEN;
+ uint64_t delta_gptc = IXGBE_READ_REG(hw, IXGBE_GPTC);
+ hw_stats->gptc += delta_gptc;
hw_stats->gotc -= delta_gptc * ETHER_CRC_LEN;
hw_stats->tor -= (hw_stats->tpr - old_tpr) * ETHER_CRC_LEN;
@@ -2470,7 +2470,6 @@ ixgbe_read_stats_registers(struct ixgbe_hw *hw,
hw_stats->lxofftxc += lxoff;
total = lxon + lxoff;
- hw_stats->gptc += IXGBE_READ_REG(hw, IXGBE_GPTC);
hw_stats->mptc += IXGBE_READ_REG(hw, IXGBE_MPTC);
hw_stats->ptc64 += IXGBE_READ_REG(hw, IXGBE_PTC64);
hw_stats->gptc -= total;
--
1.9.1
[dpdk-dev] [PATCH 0/4] support acl/lpm/table/pipeline libs for armv7 and armv8
Hi, I'm from Linaro.org, and will work on DPDK to make it better runing on different ARM Platforms. This patchset includes a small fix in rte_cycle_32.h, and enables acl/lpm/table/pipeline libs for armv7 and armv8. Please apply it after [PATCH v4 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm. Thanks! Jianbo Jianbo Liu (4): eal/arm: use RTE_ARM_EAL_RDTSC_USE_PMU in rte_cycle_32.h eal/acl: enable acl for armv7-a eal/arm: Enable lpm/table/pipeline libs maintainers: claim resposibility for ARMv7 and ARMv8 MAINTAINERS| 2 + config/defconfig_arm-armv7a-linuxapp-gcc | 4 -- config/defconfig_arm64-armv8a-linuxapp-gcc | 3 - lib/librte_acl/Makefile| 2 +- lib/librte_acl/rte_acl.c | 2 +- .../common/include/arch/arm/rte_cycles_32.h| 2 +- lib/librte_eal/common/include/arch/arm/rte_vect.h | 51 lib/librte_lpm/rte_lpm.h | 68 -- 8 files changed, 105 insertions(+), 29 deletions(-) -- 1.8.3.1
[dpdk-dev] [PATCH 1/4] eal/arm: use RTE_ARM_EAL_RDTSC_USE_PMU in rte_cycle_32.h
CONFIG_* from config files can not be used in code.
Signed-off-by: Jianbo Liu
---
lib/librte_eal/common/include/arch/arm/rte_cycles_32.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h
b/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h
index 6c6098e..9c1be71 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h
@@ -54,7 +54,7 @@ extern "C" {
* @return
* The time base for this lcore.
*/
-#ifndef CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU
+#ifndef RTE_ARM_EAL_RDTSC_USE_PMU
/**
* This call is easily portable to any ARM architecture, however,
--
1.8.3.1
[dpdk-dev] [PATCH 2/4] eal/acl: enable acl for armv7-a
Implement vqtbl1q_u8 intrinsic function, which is not support in armv7-a.
Signed-off-by: Jianbo Liu
---
config/defconfig_arm-armv7a-linuxapp-gcc | 1 -
lib/librte_acl/Makefile | 2 +-
lib/librte_acl/rte_acl.c | 2 +-
lib/librte_eal/common/include/arch/arm/rte_vect.h | 23 +++
4 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc
b/config/defconfig_arm-armv7a-linuxapp-gcc
index 9924ff9..cbebd64 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -53,7 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n
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
diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
index 897237d..2e394c9 100644
--- a/lib/librte_acl/Makefile
+++ b/lib/librte_acl/Makefile
@@ -49,7 +49,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_bld.c
SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_gen.c
SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_scalar.c
-ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
+ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),)
SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_neon.c
CFLAGS_acl_run_neon.o += -flax-vector-conversions -Wno-maybe-uninitialized
else
diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
index e2fdebd..339aace 100644
--- a/lib/librte_acl/rte_acl.c
+++ b/lib/librte_acl/rte_acl.c
@@ -114,7 +114,7 @@ rte_acl_init(void)
{
enum rte_acl_classify_alg alg = RTE_ACL_CLASSIFY_DEFAULT;
-#ifdef RTE_ARCH_ARM64
+#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
alg = RTE_ACL_CLASSIFY_NEON;
#else
#ifdef CC_AVX2_SUPPORT
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..a33c054 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
@@ -53,6 +53,29 @@ typedef union rte_xmm {
double pd[XMM_SIZE / sizeof(double)];
} __attribute__((aligned(16))) rte_xmm_t;
+#ifdef RTE_ARCH_ARM
+/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */
+static __inline uint8x16_t
+vqtbl1q_u8(uint8x16_t a, uint8x16_t b)
+{
+ uint8_t i, pos;
+ rte_xmm_t rte_a, rte_b, rte_ret;
+
+ vst1q_u8(rte_a.u8, a);
+ vst1q_u8(rte_b.u8, b);
+
+ for (i = 0; i < 16; i++) {
+ pos = rte_b.u8[i];
+ if (pos < 16)
+ rte_ret.u8[i] = rte_a.u8[pos];
+ else
+ rte_ret.u8[i] = 0;
+ }
+
+ return vld1q_u8(rte_ret.u8);
+}
+#endif
+
#ifdef __cplusplus
}
#endif
--
1.8.3.1
[dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
Adds ARM NEON support for lpm.
And enables table/pipeline libraries which depend on lpm.
Signed-off-by: Jianbo Liu
---
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;
+
#defineXMM_SIZE(sizeof(xmm_t))
#defineXMM_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);
+}
+
#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)
+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]];
+}
+#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)
+#else
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).
[dpdk-dev] [PATCH 4/4] maintainers: claim resposibility for ARMv7 and ARMv8
Signed-off-by: Jianbo Liu --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4478862..f859985 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -124,10 +124,12 @@ F: doc/guides/sample_app_ug/multi_process.rst ARM v7 M: Jan Viktorin +M: Jianbo Liu F: lib/librte_eal/common/include/arch/arm/ ARM v8 M: Jerin Jacob +M: Jianbo Liu F: lib/librte_eal/common/include/arch/arm/*_64.h F: lib/librte_acl/acl_run_neon.* -- 1.8.3.1
[dpdk-dev] [PATCH] ixgbe: fix tx_bytes statistic with link down
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Harry van Haaren
> Sent: Tuesday, December 01, 2015 10:26 AM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] ixgbe: fix tx_bytes statistic with link down
>
> This patch fixes tx byte statistics when transmitting packets
> with link down.
>
> Previously, the counter would decrement 4 bytes for each packet that
> was transmitted with link down, causing the uint64 to wrap around.
>
> Fixes: c03fcee9abbd ("ixgbe: remove CRC size from byte counters")
>
> Reported-by: Michael Qiu
> Signed-off-by: Harry van Haaren
Acked-by: Pablo de Lara
[dpdk-dev] [ovs-dev] OVS with DPDK Meetup notes
> -Original Message- > From: Flavio Leitner [mailto:fbl at sysclose.org] > Sent: Monday, November 30, 2015 11:51 PM > To: Traynor, Kevin > Cc: dev at openvswitch.org; users at dpdk.org > Subject: Re: [ovs-dev] OVS with DPDK Meetup notes > > On Thu, Nov 26, 2015 at 05:56:08PM +, Traynor, Kevin wrote: > > Hi All, > > > > Just wanted to post some summary notes on the recent OVS with DPDK Meetup > we > > had after the OVS conference. Thanks to everyone for the often lively > discussion. > > I've collated and condensed Maryam's notes (Thank you Maryam) with my own. > > Corrections and additions are welcome. > > Thanks for having organized the event and for the good notes. > > > > Usability > > == > > * Single binary for OVS/OVS with DPDK and static vs. dynamic linking > > - Discussion around deployment and what the best model is. > > - Flavio has posted a mail on this > >http://openvswitch.org/pipermail/dev/2015-November/062599.html > > Let us know if you find a performance difference between static vs > dynamic linking. We might be able to accommodate both options in > the same spec, but it seems we should go with shared linking only > to keep it simple for now. > Yes, will do. I seem to recall from when we looked at this on a previous project it was a few hundred kpps but it was a long time ago, so I'm not certain how many. > > > Features > > > > * Multiqueue vhost-user > > - Looks really promising - will help us scale out performance to the VM. > > I see that vhost PMD is moving and if it gets accepted, it would > be a nice clean up for OVS. Do you know if there is someone working > on this already? I agree, it should simplify the code a lot. Ciara reviewed it and did a quick integration to see if the api would work. The patch was churning quite a bit, so we decided to hold off doing any more work with it for the time being. > > > * dpdkr/ivshmem > > - Still useful. Check/Update documentation to ensure limitations are > clear. > > Yeah, same thing here. > > Thanks, > fbl
[dpdk-dev] [PATCH v7 11/11] doc: Add information about new installation rules
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mario Carrillo > Sent: Tuesday, December 1, 2015 12:53 AM > To: dev at dpdk.org > Cc: Venegas Munoz, Jos C > Subject: [dpdk-dev] [PATCH v7 11/11] doc: Add information about new > installation rules > > Information about variables and rules behaviour is added to documentation. Hi, Thanks for the documentation. Some comments below. > diff --git a/doc/build-sdk-quick.txt b/doc/build-sdk-quick.txt index > bf18b48..66f0d0e 100644 > --- a/doc/build-sdk-quick.txt > +++ b/doc/build-sdk-quick.txt > @@ -5,10 +5,21 @@ Build commands > all same as build (default rule) > buildbuild in a configured directory > cleanremove files but keep configuration > - install build many targets (wildcard allowed) and install > in DESTDIR > + install if T is defined, build a target and install in > DESTDIR > + else call install-fhs target The convention in this file is to use tabs rather than spaces for the first level indentation. Copy that style at the above and following lines. > uninstallremove all installed targets > examples build examples for given targets (T=) > examples_clean clean examples for given targets (T=) > +Install commands > + install if T is defined, build a target and install in > DESTDIR > + else call install-fhs target Same as above, 1 tab instead of spaces at the start of the line, spaces after that for alignment. > + install-headers install headers files > + install-bin install app files a dpdk tools > + install-lib install libraries > + install-doc install documentation > + install-mod install modules > + install-sdk install headers, makefiles, scripts,examples, tools > and config files Typo. Needs space after comma. > + install-fhs install libraries, modules, app files, nic bind files > and documentation Maybe "tools" instead of " nic bind files". Also, for me, "fhs" isn't clear as an option. Maybe "install-all" instead. > diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst > b/doc/guides/freebsd_gsg/build_dpdk.rst > index 8eff599..72826d0 100644 > --- a/doc/guides/freebsd_gsg/build_dpdk.rst > +++ b/doc/guides/freebsd_gsg/build_dpdk.rst > @@ -136,6 +136,46 @@ The DPDK is composed of several directories: > > * config, tools, scripts, mk: Framework-related makefiles, scripts and > configuration > > + > +Build and install DPDK using a file hierarchy > +- > + > +Following the next steps is possible configure, build and install > +specific files according to a file hierarchy and a group of variables. Probably better as something like: It is possible to configure, build and install specific groups of DPDK files into a a file hierarchy using the following install commands and variables: > + > +.. code-block:: console > + > + make config T= > + make > + make > + > ++--+- > ---+ > +| install target | Description > | > ++==+=== > ++=+ > +|install |if T is not defined will call install-fhs install > | In general tables should be avoided in the docs. See the Tables section of the DPDK Documentation guidelines: http://dpdk.org/doc/guides/contributing/documentation.html#tables A bullet list would be clear here. Something like: Where the install options are: * ``install`` If ``T`` is not defined make will call ``install-fhs``. * ``install-headers`` Install headers files into ``includedir`` which is defined as ``$(prefix)/include/dpdk``. * ``install-bin`` Install app files and dpdk tools into ``bindir`` which is defined as ``$(exec_prefix)/bin``. * ``install-lib`` Install libraries into ``libdir`` which is defined as ``$(exec_prefix)/lib``. * ``install-doc`` Install documentation into ``docdir`` which is defined as ``$(datarootdir)/doc/dpdk``. * ``install-mod`` Install modules into ``kerneldir``. If ``RTE_EXEC_ENV`` is ``linuxapp`` then ``kerneldir`` is ``/lib/modules/$(uname -r)/extra/drivers/dpdk`` otherwise ``/boot/modules``. * ``install-sdk`` Install headers, makefiles, scripts,examples and config files into ``sdkdir`` which is defined as ``$(datarootdir)/dpdk``. * ``install-fhs`` Install libraries, modules, app files, tools and documentation. > +prefix=/usr/local, exec_prefix=$(prefix) and > +datarootdir=$(prefix)/share by default however prefix, exec_prefix, > datarootdir and all path variables can be overridden furthermore all > targets can use DESTDIR variable. This could be reformatted more clearly like the following: The follo
[dpdk-dev] [PATCH v4 2/2] doc: correct Rings-based PMD section in the NIC Drivers guides
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bernard Iremonger
> Sent: Saturday, November 28, 2015 11:02 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4 2/2] doc: correct Rings-based PMD section in
> the NIC Drivers guides
>
> Correct the sample code in the pcap_ring.rst file to match the latest
> rte_eth_ring.c code.
>
> The parameters to the rte_eth_from_rings() function have changed since the
> documentation was written.
> The API change occurred before DPDK 1.8 when the rst files were added.
> The original documentation on which the pcap_ring.rst file was based was
> not correct.
>
> Fixes: fc1f2750a3ec("doc: programmers guide")
>
> Signed-off-by: Bernard Iremonger
> Acked-by: Bruce Richardson
Acked-by: John McNamara
[dpdk-dev] 2.3 Roadmap
Hello DPDK list, I've been so far just roughly reading messages, as I've been working on my company's product based on DPDK1.6 for some time and haven't yet much catched up to newer releases, but as I implemented packet capture for my product just in a way as commented here, (using KNI), > Our current thinking is to use kni to mirror packets into the kernel itself, > so that all standard linux capture tools can then be used. > > /Bruce I felt like giving commets from my humble experiences,,, - In our case, KNI is always enabeld for each DPDK port, as it seemed handy that packet rx/tx stat and up/down status can be checked by ifconfig as well. Also, iface MIB become available as well via /sys/devices/pci.../net. As far as we checked it, it seemed that just creating KNI itself didn't much affect Dplane performance. (Just when we update statistics, there is a bit of overhead.) - I inserted rte_kni_tx_burst() call to packet RX path (after rte_eth_rx_burst) and TX path (after rte_eth_tx_burst, based on an assumption that just sent out pkt is not yet freed, it will be freed when the tx descriptor is overwritten by some time later tx packet.). The call to rte_kni_tx_burst() is enabled/disabled by some external capture enable/disable command. I copy the packet beforehand and pass the copied one to rte_kni_tx_burst(). In TX path, we might not need to copy if we just increment the packet refcnt by 1, but haven't yet tried such hack much. The packets sent to rte_kni_tx_burst() can then be captured by normal libpcap tools like tcpdump on the correspondent KNI. The performance loss when the capture was enabled was roughly 20-30%. (Perhaps it might change based on many factors.) By the way, in this way, we can enable tx-only or rx-only capture. - Some considerations, - Someone might not like capture on/off check everytime on normal fast path tx/rx route. I too, so created fastpath send routine and slowpath send routine, and switched the function pointer when the capture is enabled/disabled. But not sure if it was worth for the effort. - In this approach, everyone needs to create their own capture enable/disable command in their implementation, and it could be a bit bothering. I myself am not sure if it's possible, but if as in normal tcpdump, an invocation of tcpdump to a KNI interfce could be somehow notified to the correspondent DPDK port user application, and then the call to rte_kni_tx_burst() could be automatically enabled/disabled, that's cool. Thanks, Yoshinobu Inoue From: Bruce Richardson Subject: Re: [dpdk-dev] 2.3 Roadmap Date: Tue, 1 Dec 2015 10:03:33 + > On Mon, Nov 30, 2015 at 05:16:55PM -0800, Stephen Hemminger wrote: >> On Mon, 30 Nov 2015 22:53:50 + >> Kyle Larose wrote: >> >> > Hi Tim, >> > >> > On Mon, Nov 30, 2015 at 3:50 PM, O'Driscoll, Tim > > intel.com> wrote: >> > >> > > Tcpdump Support: Support for tcpdump will be added to DPDK. This will >> > > improve usability and debugging of DPDK applications. >> > >> > I'm curious about the proposed tcpdump support. Is there a concrete plan >> > for this, or is that still being looked into? Sandvine is interested in >> > contributing to this effort. Anything we can do to help? >> > >> > Thanks, >> > >> > Kyle >> >> We discussed an Ovscon doing a simple example of how to have a thread use >> named pipe >> support (already in tcpdump and wireshark). More complex solutions require >> changes to >> libpcap and application interaction. > > Our current thinking is to use kni to mirror packets into the kernel itself, > so that all standard linux capture tools can then be used. > > /Bruce >
[dpdk-dev] 2.3 Roadmap
> -Original Message- > From: Hobywan Kenoby [mailto:hobywank at hotmail.com] > Sent: Monday, November 30, 2015 10:30 PM > To: O'Driscoll, Tim; dev at dpdk.org > Subject: Re: 2.3 Roadmap > > > Hi, > > CAT And CDP technologies look very intriguing Could you elaborate a > little on those? We're working on a white paper which should be available soon. In the meantime, there's more information on these technologies at: https://www-ssl.intel.com/content/www/us/en/communications/cache-monitoring-cache-allocation-technologies.html https://01.org/packet-processing/cache-monitoring-technology-memory-bandwidth-monitoring-cache-allocation-technology-code-and-data Tim > > -HK > > From: dev on behalf of O'Driscoll, Tim > > Sent: Monday, November 30, 2015 9:50:58 PM > To: dev at dpdk.org > Subject: [dpdk-dev] 2.3 Roadmap > > As we're nearing the completion of the 2.2 release, I'd like to start a > discussion on plans for 2.3. To kick this off, below are the features > that we're hoping to submit for this release. > > If others are prepared to contribute their plans, then we could build a > complete view of the release which Thomas can maintain on the dpdk.org > roadmap page, and make sure we're not duplicating work. > > > IPsec Sample Application: A sample application will be created which > will show how DPDK and the new cryptodev API can be used to implement > IPsec. Use of the cryptodev API will allow either hardware or software > encryption to be used. IKE will not be implemented so the SA/SP DBs will > be statically configured. > > Cryptodev Support for SNOW 3G: The cryptodev API, and the hardware and > software crypto PMDs that it supports, will be enhanced to support the > SNOW 3G cipher. > > External Mempool Manager: SoCs and some software applications that use > DPDK have their own memory allocation capabilities. This feature will > allow DPDK to work with an external mempool manager. > > Packet Framework (Edge Router Use Case): > - Further performance tuning for the vPE use case. > - Support for load balancing within a pipeline. > - Support for CPU utilization measurements within a pipeline. > - Improvements for the functional pipelines, tables and ports. > > Ethdev Enhancements: Merge parts of the Packet Framework ports library > into ethdev so they can be used without the Packet Framework. The > initial focus is to add support for buffered TX to ethdev. > > Live Migration: The main infrastructure to support live migration of VMs > was implemented over the last few DPDK releases via the Link Bonding and > PCI Hot Plug features. This feature will involve further investigation, > prototyping and enhancements to improve live migration support in DPDK. > > Tcpdump Support: Support for tcpdump will be added to DPDK. This will > improve usability and debugging of DPDK applications. > > Increase Next Hops for LPM (IPv4): The number of next hops for IPv4 LPM > is currently limited to 256. This will be extended to allow a greater > number of next hops. > > Fm10k Enhancements: FTAG based forwarding, and performance tuning > > Support Intel Resource Director Technology: A library will be added to > DPDK to support the following Intel CPU technologies: > - CAT - Cache Allocation Technology (LLC aka L3) > - CDP - Code Data Prioritization (extension of CAT) > - CMT - Cache Monitoring Technology (LLC) > - MBM - Memory Bandwidth Monitoring, to local and remote RAM > These technologies are currently available via cgroups and perf, but > this feature will provide closer integration with DPDK and a sample > application showing how they can be used. > > I40e Enhancements: > - Flow Director input set Alignment > - Ethertype configuration for QinQ support > - Flow Director Support for Tunnels (QinQ, GRE/NVGRE, VXLAN) > - Flow Director Support for IP Proto and IP TOS > - VEB switching > - Floating VEB > - IPGRE Support > - Set VF MAC address > - Rework PCIe extended tag enabling by using DPDK interfaces > > Virtio/Vhost Enhancements: > - Virtio 1.0 support > - Vhost software TSO > - Vhost/virtio performance tuning > > Container Enhancements: > - Virtio for containers > - Hugetlbfs mount point size > - Cgroup resource awareness > - Enable short-lived DPDK applications > > Generic Tunneling API: > - Implement virtual flow device framework > - Implement generic virtual device management APIs, including the > following callback functions: > - flow_ethdev_start/stop/configure/close/info_get > - ethdev_rx/tx_queue_setup/release > - flow_ethdev_tunnel_configure/setup/destroy > - flow_ethdev_tunnel_pkt_decap/encap > - Implement flow device PMD drive APIs > - rte_eth_flow_dev_create/remove/ others > - Integrate VXLAN protocol (including VXLAN decap/encap optimization) > into this framework only on i40e. > > > Tim
[dpdk-dev] 2.3 Roadmap
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Dave Neary > Sent: Monday, November 30, 2015 10:19 PM > To: O'Driscoll, Tim; dev at dpdk.org > Subject: Re: [dpdk-dev] 2.3 Roadmap > > Hi Tim, > > Just curious about one item on the list: > > On 11/30/2015 03:50 PM, O'Driscoll, Tim wrote: > > IPsec Sample Application: A sample application will be created which > will show how DPDK and the new cryptodev API can be used to implement > IPsec. Use of the cryptodev API will allow either hardware or software > encryption to be used. IKE will not be implemented so the SA/SP DBs will > be statically configured. > > Do you anticipate this application living in the dpdk repo, or in a > separate tree? Good question. As a sample application showing how DPDK can be used to implement IPsec, I believe it belongs within the DPDK repo. When we have an Architecture Board in place, I think one of the first tasks for the board should be to clarify the scope of DPDK. Venky agreed at the Userspace event to draft an initial statement on this. If the outcome of that is that the IPsec sample app doesn't belong within DPDK, then we can put it into a separate tree. Tim > > Thanks, > Dave. > > -- > Dave Neary - NFV/SDN Community Strategy > Open Source and Standards, Red Hat - http://community.redhat.com > Ph: +1-978-399-2182 / Cell: +1-978-799-3338
[dpdk-dev] 2.3 Roadmap
On Tue, Dec 01, 2015 at 08:26:39PM +0900, Yoshinobu Inoue wrote: > Hello DPDK list, > > I've been so far just roughly reading messages, as I've been working on my > company's product based on DPDK1.6 for some time and haven't yet much > catched up to newer releases, > but as I implemented packet capture for my product just in a way as commented > here, (using KNI), > > > Our current thinking is to use kni to mirror packets into the kernel itself, > > so that all standard linux capture tools can then be used. > > > > /Bruce > > I felt like giving commets from my humble experiences,,, > > - In our case, KNI is always enabeld for each DPDK port, >as it seemed handy that packet rx/tx stat and up/down status can be checked >by ifconfig as well. >Also, iface MIB become available as well via /sys/devices/pci.../net. > >As far as we checked it, it seemed that just creating KNI itself didn't > much >affect Dplane performance. >(Just when we update statistics, there is a bit of overhead.) > > - I inserted rte_kni_tx_burst() call to >packet RX path (after rte_eth_rx_burst) and TX path (after > rte_eth_tx_burst, >based on an assumption that just sent out pkt is not yet freed, it will be >freed when the tx descriptor is overwritten by some time later tx packet.). > >The call to rte_kni_tx_burst() is enabled/disabled by some external capture >enable/disable command. > >I copy the packet beforehand and pass the copied one to rte_kni_tx_burst(). >In TX path, we might not need to copy if we just increment the packet > refcnt >by 1, but haven't yet tried such hack much. > >The packets sent to rte_kni_tx_burst() can then be captured by normal > libpcap >tools like tcpdump on the correspondent KNI. > >The performance loss when the capture was enabled was roughly 20-30%. >(Perhaps it might change based on many factors.) > >By the way, in this way, we can enable tx-only or rx-only capture. > > > - Some considerations, > >- Someone might not like capture on/off check everytime on normal fast > path > tx/rx route. > I too, so created fastpath send routine and slowpath send routine, > and switched the function pointer when the capture is enabled/disabled. > But not sure if it was worth for the effort. > >- In this approach, everyone needs to create their own capture > enable/disable > command in their implementation, and it could be a bit bothering. > > I myself am not sure if it's possible, but if as in normal tcpdump, > an invocation of tcpdump to a KNI interfce could be somehow notified to > the correspondent DPDK port user application, and then the call to > rte_kni_tx_burst() could be automatically enabled/disabled, that's cool. > > > Thanks, > Yoshinobu Inoue > Hi, that is indeed very similar to what we are thinking ourselves. Is there any of what you have already done that you could contribute publically to save us duplicating some of your effort? [The one big difference, is that we are not thinking of enabling kni permanently for each port, as the ethtool support is only present for a couple of NIC types, and solving that is a separate issue.:-)] /Bruce
[dpdk-dev] [PATCH v9 3/3] doc: add user-space ethtool sample app guide
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, Konstantin > Sent: Friday, November 20, 2015 5:16 PM > To: Horton, Remy; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v9 3/3] doc: add user-space ethtool sample > app guide > > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Remy Horton > > Sent: Friday, November 20, 2015 3:35 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] [PATCH v9 3/3] doc: add user-space ethtool sample > app guide > > > > Signed-off-by: Remy Horton > > --- > > Acked-by: Konstantin Ananyev Acked-by: John McNamara
[dpdk-dev] [PATCH v7 11/11] doc: Add information about new installation rules
> -Original Message- > From: Mcnamara, John > Sent: Tuesday, December 1, 2015 11:12 AM > To: 'Mario Carrillo'; dev at dpdk.org > Cc: Venegas Munoz, Jos C > Subject: RE: [dpdk-dev] [PATCH v7 11/11] doc: Add information about new > installation rules > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mario Carrillo > > Sent: Tuesday, December 1, 2015 12:53 AM > > To: dev at dpdk.org > > Cc: Venegas Munoz, Jos C > > Subject: [dpdk-dev] [PATCH v7 11/11] doc: Add information about new > > installation rules > > > > Information about variables and rules behaviour is added to > documentation. > > Hi, > > Thanks for the documentation. Some comments below. Hi, You also need to mark the v6 versions as Superseded: http://dpdk.org/dev/patchwork/project/dpdk/list/?submitter=Mario+Carrillo John. --
[dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
On 11/30/2015 06:41 PM, Stephen Hemminger wrote: > On Mon, 30 Nov 2015 10:03:43 -0500 > Neil Horman wrote: > >> On Wed, Nov 25, 2015 at 08:08:37AM -0800, Stephen Hemminger wrote: >>> On Wed, 25 Nov 2015 10:38:48 +0200 >>> Panu Matilainen wrote: >>> On 11/25/2015 12:46 AM, Stephen Hemminger wrote: > On Tue, 24 Nov 2015 16:31:17 +0200 > Panu Matilainen wrote: > >> 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 > intel.com> >> Suggested-by: Neil Horman >> Signed-off-by: Panu Matilainen > > But it now means distros have to ship 20 libraries which seems like > a step back. 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. But more to the point, distros will prefer 50 working libraries over one that doesn't. 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. - Panu - >>> >>> Fixing the combined library took less than an hour for us. >> How did you fix the versioning issue? >> >> Neil > > This is what I did. > Also decided to keep shared library version == major DPDK version > to avoid confusion. > > > mk: fix when building combined shared library > > The DPDK mk file does not set shared object name or version > information as required by Debian. > > Signed-off-by: Stephen Hemminger > > --- a/mk/rte.sharelib.mk > +++ b/mk/rte.sharelib.mk > @@ -51,10 +51,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)) \ > - -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) > + -shared $(OBJS) -Wl,-soname,$(LIB_ONE).$(RTE_LIBVERS) -o > $(RTE_OUTPUT)/lib/$(LIB_ONE) > else > O_TO_S = $(LD) $(CPU_LDFLAGS) \ > - -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) > + -shared $(OBJS) -soname $(LIB_ONE).$(RTE_LIBVERS) -o > $(RTE_OUTPUT)/lib/$(LIB_ONE) > endif > > O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight > --- a/mk/rte.vars.mk > +++ b/mk/rte.vars.mk > @@ -74,8 +74,10 @@ ifneq ($(BUILDING_RTE_SDK),) > endif > > RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) > +RTE_LIBVERS := $(CONFIG_RTE_LIBVERS:"%"=%) > ifeq ($(RTE_LIBNAME),) > RTE_LIBNAME := intel_dpdk > +RTE_LIBVERS := 2 > endif > > # RTE_TARGET is deducted from config when we are building the SDK. > 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. The combined library doesn't have symbol versioning, so besides the better version compatibility tracking it loses other benefits like limited symbol visibility. 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. - Panu -
[dpdk-dev] [PATCH v2] ip_pipeline: add check on nic's rxq and txq
This patch checks that rx queue and tx queue of each
link specified in ip pipeline configuration file are
used.
*v2
- fix checkpatch warnings
Signed-off-by: Jasvinder Singh
Acked-by: Cristian Dumitrescu
---
examples/ip_pipeline/config_check.c | 4
1 file changed, 4 insertions(+)
diff --git a/examples/ip_pipeline/config_check.c
b/examples/ip_pipeline/config_check.c
index 8052bc4..1ff5763 100644
--- a/examples/ip_pipeline/config_check.c
+++ b/examples/ip_pipeline/config_check.c
@@ -98,6 +98,8 @@ check_links(struct app_params *app)
n_rxq = app_link_get_n_rxq(app, link);
+ APP_CHECK((n_rxq), "%s does not have any RXQ\n", link->name);
+
APP_CHECK((n_rxq == rxq_max + 1),
"%s RXQs are not contiguous (B)\n", link->name);
@@ -115,6 +117,8 @@ check_links(struct app_params *app)
/* Check that link RXQs are contiguous */
n_txq = app_link_get_n_txq(app, link);
+ APP_CHECK((n_txq), "%s does not have any TXQ\n", link->name);
+
for (i = 0; i < n_txq; i++) {
char name[APP_PARAM_NAME_SIZE];
int pos;
--
2.5.0
[dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
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 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
[dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
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
[dpdk-dev] [PATCH 1/4] eal/arm: use RTE_ARM_EAL_RDTSC_USE_PMU in rte_cycle_32.h
Hello Jianbo,
thank you for this fix. I had the feeling this works the same like in the Linux
Kernel where the CONFIG_ prefix is be used. My bad. I recommend to make
this patch separate. I can't see any relation to the rest of the series.
Regards
Jan
On Tue, 1 Dec 2015 13:41:13 -0500
Jianbo Liu wrote:
> CONFIG_* from config files can not be used in code.
>
> Signed-off-by: Jianbo Liu
> ---
> lib/librte_eal/common/include/arch/arm/rte_cycles_32.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h
> b/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h
> index 6c6098e..9c1be71 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h
> @@ -54,7 +54,7 @@ extern "C" {
> * @return
> * The time base for this lcore.
> */
> -#ifndef CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU
> +#ifndef RTE_ARM_EAL_RDTSC_USE_PMU
>
> /**
> * This call is easily portable to any ARM architecture, however,
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH 1/4] eal/arm: use RTE_ARM_EAL_RDTSC_USE_PMU in rte_cycle_32.h
On Tue, 1 Dec 2015 13:41:13 -0500 Jianbo Liu wrote: > CONFIG_* from config files can not be used in code. > > Signed-off-by: Jianbo Liu > --- Acked-by: Jan Viktorin -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH 0/4] support acl/lpm/table/pipeline libs for armv7 and armv8
On Tue, 1 Dec 2015 13:41:12 -0500 Jianbo Liu wrote: > Hi, > I'm from Linaro.org, and will work on DPDK to make it better > runing on different ARM Platforms. > > This patchset includes a small fix in rte_cycle_32.h, > and enables acl/lpm/table/pipeline libs for armv7 and armv8. > Please apply it after [PATCH v4 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm. Would it avoid some merge conflicts or is there some other dependency? Jan > > Thanks! > Jianbo > > > Jianbo Liu (4): > eal/arm: use RTE_ARM_EAL_RDTSC_USE_PMU in rte_cycle_32.h > eal/acl: enable acl for armv7-a > eal/arm: Enable lpm/table/pipeline libs > maintainers: claim resposibility for ARMv7 and ARMv8 > > MAINTAINERS| 2 + > config/defconfig_arm-armv7a-linuxapp-gcc | 4 -- > config/defconfig_arm64-armv8a-linuxapp-gcc | 3 - > lib/librte_acl/Makefile| 2 +- > lib/librte_acl/rte_acl.c | 2 +- > .../common/include/arch/arm/rte_cycles_32.h| 2 +- > lib/librte_eal/common/include/arch/arm/rte_vect.h | 51 > lib/librte_lpm/rte_lpm.h | 68 > -- > 8 files changed, 105 insertions(+), 29 deletions(-) > -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH 0/4] support acl/lpm/table/pipeline libs for armv7 and armv8
On Tue, Dec 01, 2015 at 01:47:23PM +0100, Jan Viktorin wrote: > On Tue, 1 Dec 2015 13:41:12 -0500 > Jianbo Liu wrote: > > > Hi, > > I'm from Linaro.org, and will work on DPDK to make it better > > runing on different ARM Platforms. > > > > This patchset includes a small fix in rte_cycle_32.h, > > and enables acl/lpm/table/pipeline libs for armv7 and armv8. > > Please apply it after [PATCH v4 0/2] disable CONFIG_RTE_SCHED_VECTOR for > > arm. > > Would it avoid some merge conflicts or is there some other dependency? > There is no conflicts, but please apply Jerin's patch first since this patchset is based on that. > Jan > > > > > Thanks! > > Jianbo > > > > > > Jianbo Liu (4): > > eal/arm: use RTE_ARM_EAL_RDTSC_USE_PMU in rte_cycle_32.h > > eal/acl: enable acl for armv7-a > > eal/arm: Enable lpm/table/pipeline libs > > maintainers: claim resposibility for ARMv7 and ARMv8 > > > > MAINTAINERS| 2 + > > config/defconfig_arm-armv7a-linuxapp-gcc | 4 -- > > config/defconfig_arm64-armv8a-linuxapp-gcc | 3 - > > lib/librte_acl/Makefile| 2 +- > > lib/librte_acl/rte_acl.c | 2 +- > > .../common/include/arch/arm/rte_cycles_32.h| 2 +- > > lib/librte_eal/common/include/arch/arm/rte_vect.h | 51 > > lib/librte_lpm/rte_lpm.h | 68 > > -- > > 8 files changed, 105 insertions(+), 29 deletions(-) > > > > > > -- >Jan Viktorin E-mail: Viktorin at RehiveTech.com >System Architect Web:www.RehiveTech.com >RehiveTech >Brno, Czech Republic
[dpdk-dev] 2.3 Roadmap
On Mon, Nov 30, 2015 at 08:50:58PM +, O'Driscoll, Tim wrote: > Increase Next Hops for LPM (IPv4): The number of next hops for IPv4 LPM is > currently limited to 256. This will be extended to allow a greater number of > next hops. In other threads, we previously proposed doing increased LPM4 *and* LPM6. Having incompatible support between both is a huge headache for me. And I already contributed patches to fix the issue in both versions. Thanks, Matthew
[dpdk-dev] 2.3 Roadmap
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall > Sent: Tuesday, December 1, 2015 1:00 PM > To: O'Driscoll, Tim > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] 2.3 Roadmap > > On Mon, Nov 30, 2015 at 08:50:58PM +, O'Driscoll, Tim wrote: > > Increase Next Hops for LPM (IPv4): The number of next hops for IPv4 > LPM is > > currently limited to 256. This will be extended to allow a greater > number of > > next hops. > > In other threads, we previously proposed doing increased LPM4 *and* > LPM6. > > Having incompatible support between both is a huge headache for me. > > And I already contributed patches to fix the issue in both versions. True. The goal is to merge the best of the various patches that were submitted on this. This could involve changes to IPv6 as well as IPv4. Tim > > Thanks, > Matthew
[dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
On Mon, Nov 30, 2015 at 08:41:02AM -0800, Stephen Hemminger wrote: > On Mon, 30 Nov 2015 10:03:43 -0500 > Neil Horman wrote: > > > On Wed, Nov 25, 2015 at 08:08:37AM -0800, Stephen Hemminger wrote: > > > On Wed, 25 Nov 2015 10:38:48 +0200 > > > Panu Matilainen wrote: > > > > > > > On 11/25/2015 12:46 AM, Stephen Hemminger wrote: > > > > > On Tue, 24 Nov 2015 16:31:17 +0200 > > > > > Panu Matilainen wrote: > > > > > > > > > >> 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 > > > >> intel.com> > > > > >> Suggested-by: Neil Horman > > > > >> Signed-off-by: Panu Matilainen > > > > > > > > > > But it now means distros have to ship 20 libraries which seems like > > > > > a step back. > > > > > > > > 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. But more to > > > > the point, distros will prefer 50 working libraries over one that > > > > doesn't. > > > > > > > > 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. > > > > > > > > - Panu - > > > > > > > > > > Fixing the combined library took less than an hour for us. > > How did you fix the versioning issue? > > > > Neil > > This is what I did. > Also decided to keep shared library version == major DPDK version > to avoid confusion. > Ok, thats the library versioning, which is great, but I was more concerned about the symbol versioning - i.e. the collection of version linker scripts that get applied when you build individual libraries, but completely ignored when you build the combined library Neil > > mk: fix when building combined shared library > > The DPDK mk file does not set shared object name or version > information as required by Debian. > > Signed-off-by: Stephen Hemminger > > --- a/mk/rte.sharelib.mk > +++ b/mk/rte.sharelib.mk > @@ -51,10 +51,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)) \ > - -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) > + -shared $(OBJS) -Wl,-soname,$(LIB_ONE).$(RTE_LIBVERS) -o > $(RTE_OUTPUT)/lib/$(LIB_ONE) > else > O_TO_S = $(LD) $(CPU_LDFLAGS) \ > - -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) > + -shared $(OBJS) -soname $(LIB_ONE).$(RTE_LIBVERS) -o > $(RTE_OUTPUT)/lib/$(LIB_ONE) > endif > > O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight > --- a/mk/rte.vars.mk > +++ b/mk/rte.vars.mk > @@ -74,8 +74,10 @@ ifneq ($(BUILDING_RTE_SDK),) > endif > > RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) > +RTE_LIBVERS := $(CONFIG_RTE_LIBVERS:"%"=%) > ifeq ($(RTE_LIBNAME),) > RTE_LIBNAME := intel_dpdk > +RTE_LIBVERS := 2 > endif > > # RTE_TARGET is deducted from config when we are building the SDK. >
[dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
On Tue, Dec 01, 2015 at 12:36:15PM +, 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 > 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 >
[dpdk-dev] [PATCH v7 11/11] doc: Add information about new installation rules
Hi John, Thank you so much for your comments about documentation patches, I have taken note for the next version :) Thanks. Mario. From: Mcnamara, John Sent: Tuesday, December 01, 2015 4:08 AM To: Arevalo, Mario Alfredo C; dev at dpdk.org Cc: Venegas Munoz, Jos C Subject: RE: [dpdk-dev] [PATCH v7 11/11] doc: Add information about new installation rules > -Original Message- > From: Mcnamara, John > Sent: Tuesday, December 1, 2015 11:12 AM > To: 'Mario Carrillo'; dev at dpdk.org > Cc: Venegas Munoz, Jos C > Subject: RE: [dpdk-dev] [PATCH v7 11/11] doc: Add information about new > installation rules > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mario Carrillo > > Sent: Tuesday, December 1, 2015 12:53 AM > > To: dev at dpdk.org > > Cc: Venegas Munoz, Jos C > > Subject: [dpdk-dev] [PATCH v7 11/11] doc: Add information about new > > installation rules > > > > Information about variables and rules behaviour is added to > documentation. > > Hi, > > Thanks for the documentation. Some comments below. Hi, You also need to mark the v6 versions as Superseded: http://dpdk.org/dev/patchwork/project/dpdk/list/?submitter=Mario+Carrillo John. --
[dpdk-dev] 2.3 Roadmap
On Tue, Dec 01, 2015 at 11:58:16AM +, Bruce Richardson wrote: > Hi, > > that is indeed very similar to what we are thinking ourselves. Is there any of > what you have already done that you could contribute publically to save us > duplicating some of your effort? [The one big difference, is that we are not > thinking of enabling kni permanently for each port, as the ethtool support is > only present for a couple of NIC types, and solving that is a separate > issue.:-)] > > /Bruce Personally I was looking at something a bit different because I wanted an ability to support lightning fast BPF expressions for security purposes, not just debugging captures. I got hold of a copy of the bpfjit implementation, with some tweaks to support compiling on Linux and BSD in userspace mode, from Alexander Nasonov who made it for the BSD kernel, as a result of participating here. I am planning to use this to do the captures so you don't incur the headache or performance issues with rte_kni. I am curious how I might be able to link it up w/ the standard libpcap based tools to get an end-to-end solution with minimal loss. Matthew.
[dpdk-dev] 2.3 Roadmap
On Tue, Dec 01, 2015 at 01:16:47PM +, O'Driscoll, Tim wrote: > True. The goal is to merge the best of the various patches that were > submitted on this. This could involve changes to IPv6 as well as IPv4. > > > Tim If it's possible to fix IPv6 as well this would be good for me. Offering a large nexthop space on all protocols is very good for BGP / core routing and security inspection applications. Using this feature, I will be able to detect interactions with bad subnets and IPs at tremendous speed compared to competing solutions. Matthew.
[dpdk-dev] 2.3 Roadmap
On Tue, Dec 01, 2015 at 08:44:57AM -0500, Matthew Hall wrote: > On Tue, Dec 01, 2015 at 01:16:47PM +, O'Driscoll, Tim wrote: > > True. The goal is to merge the best of the various patches that were > > submitted on this. This could involve changes to IPv6 as well as IPv4. > > > > > > Tim > > If it's possible to fix IPv6 as well this would be good for me. Offering a > large nexthop space on all protocols is very good for BGP / core routing and > security inspection applications. Using this feature, I will be able to > detect > interactions with bad subnets and IPs at tremendous speed compared to > competing solutions. > > Matthew. Hi Matthew, Couple of follow-up questions on this: * do you need the exact same number of bits in both implementations? If we support 21 bits of data in IPv6 and 24 in IPv4 is that an issue compared to supporting 21 bits just in both for compatibility. * related to this - how much data are you looking to store in the tables? Thanks, /Bruce
[dpdk-dev] [PATCH] mk: bump minimum march in default machine
While playing with building 2.2-rc2 I found that our usual way didn't work anymore. We usually configured "make config T=x86_64-native-linuxapp-gcc" but then set CONFIG_RTE_MACHINE="default" to get something like the "lowest acceptable build" but with that wide CPU copatibility. I found that with DPDK 2.2 this fails with issues like: In file included from /usr/lib/gcc/x86_64-linux-gnu/5/include/immintrin.h:37:0, from dpdk-2.2.0-rc2/lib/librte_sched/rte_sched.c:56: dpdk-2.2.0-rc2/lib/librte_sched/rte_sched.c: In function ?grinder_pipe_exists?: /usr/lib/gcc/x86_64-linux-gnu/5/include/smmintrin.h:67:1: error: inlining failed in call to always_inline ?_mm_testz_si128?: target specific option mismatch _mm_testz_si128 (__m128i __M, __m128i __V) ^ This is a hard need on newer SSE4.x features which are not given with march=core2. So if nehalem (the next march level which has SSE4.x) is the new minimum let us set this in the default machine config. Signed-off-by: Christian Ehrhardt --- [diffstat] rte.vars.mk |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) [diff] diff --git a/mk/machine/default/rte.vars.mk b/mk/machine/default/rte.vars.mk index 53c6af6..170d880 100644 --- a/mk/machine/default/rte.vars.mk +++ b/mk/machine/default/rte.vars.mk @@ -55,4 +55,4 @@ # CPU_LDFLAGS = # CPU_ASFLAGS = -MACHINE_CFLAGS += -march=core2 +MACHINE_CFLAGS += -march=nehalem
[dpdk-dev] 2.3 Roadmap
On 12/01/2015 12:03 PM, Bruce Richardson wrote: > On Mon, Nov 30, 2015 at 05:16:55PM -0800, Stephen Hemminger wrote: >> On Mon, 30 Nov 2015 22:53:50 + >> Kyle Larose wrote: >> >>> Hi Tim, >>> >>> On Mon, Nov 30, 2015 at 3:50 PM, O'Driscoll, Tim >> intel.com> wrote: >>> Tcpdump Support: Support for tcpdump will be added to DPDK. This will improve usability and debugging of DPDK applications. >>> >>> I'm curious about the proposed tcpdump support. Is there a concrete plan >>> for this, or is that still being looked into? Sandvine is interested in >>> contributing to this effort. Anything we can do to help? >>> >>> Thanks, >>> >>> Kyle >> >> We discussed an Ovscon doing a simple example of how to have a thread use >> named pipe >> support (already in tcpdump and wireshark). More complex solutions require >> changes to >> libpcap and application interaction. > > Our current thinking is to use kni to mirror packets into the kernel itself, > so that all standard linux capture tools can then be used. The problem with that (unless I'm missing something here) is that KNI requires using out-of-tree kernel modules which makes it pretty much a non-option for distros. - Panu -
[dpdk-dev] [PATCH] mk: bump minimum march in default machine
On 12/01/2015 04:26 PM, Christian Ehrhardt wrote: > While playing with building 2.2-rc2 I found that our usual way didn't work > anymore. > We usually configured "make config T=x86_64-native-linuxapp-gcc" but then > set CONFIG_RTE_MACHINE="default" to get something like the "lowest acceptable > build" but with that wide CPU copatibility. > > I found that with DPDK 2.2 this fails with issues like: > In file included from > /usr/lib/gcc/x86_64-linux-gnu/5/include/immintrin.h:37:0, > from dpdk-2.2.0-rc2/lib/librte_sched/rte_sched.c:56: > dpdk-2.2.0-rc2/lib/librte_sched/rte_sched.c: In function > ?grinder_pipe_exists?: > /usr/lib/gcc/x86_64-linux-gnu/5/include/smmintrin.h:67:1: error: inlining > failed in call to always_inline ?_mm_testz_si128?: target specific option > mismatch > _mm_testz_si128 (__m128i __M, __m128i __V) > ^ > This is a hard need on newer SSE4.x features which are not given with > march=core2. > > So if nehalem (the next march level which has SSE4.x) is the new minimum let > us > set this in the default machine config. > > Signed-off-by: Christian Ehrhardt > --- > > [diffstat] > rte.vars.mk |2 +- >1 file changed, 1 insertion(+), 1 deletion(-) > > [diff] > diff --git a/mk/machine/default/rte.vars.mk b/mk/machine/default/rte.vars.mk > index 53c6af6..170d880 100644 > --- a/mk/machine/default/rte.vars.mk > +++ b/mk/machine/default/rte.vars.mk > @@ -55,4 +55,4 @@ > # CPU_LDFLAGS = > # CPU_ASFLAGS = > > -MACHINE_CFLAGS += -march=core2 > +MACHINE_CFLAGS += -march=nehalem > You can just disable CONFIG_RTE_SCHED_VECTOR instead. Also see http://dpdk.org/ml/archives/dev/2015-November/029067.html - Panu -
[dpdk-dev] [PATCH 2/4] eal/acl: enable acl for armv7-a
On Tue, Dec 01, 2015 at 01:41:14PM -0500, Jianbo Liu wrote:
> Implement vqtbl1q_u8 intrinsic function, which is not support in armv7-a.
>
> Signed-off-by: Jianbo Liu
> ---
> config/defconfig_arm-armv7a-linuxapp-gcc | 1 -
> lib/librte_acl/Makefile | 2 +-
> lib/librte_acl/rte_acl.c | 2 +-
> lib/librte_eal/common/include/arch/arm/rte_vect.h | 23
> +++
> 4 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc
> b/config/defconfig_arm-armv7a-linuxapp-gcc
> index 9924ff9..cbebd64 100644
> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> @@ -53,7 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n
> 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
> diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
> index 897237d..2e394c9 100644
> --- a/lib/librte_acl/Makefile
> +++ b/lib/librte_acl/Makefile
> @@ -49,7 +49,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_bld.c
> SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_gen.c
> SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_scalar.c
>
> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
> +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),)
> SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_neon.c
> CFLAGS_acl_run_neon.o += -flax-vector-conversions -Wno-maybe-uninitialized
> else
> diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> index e2fdebd..339aace 100644
> --- a/lib/librte_acl/rte_acl.c
> +++ b/lib/librte_acl/rte_acl.c
> @@ -114,7 +114,7 @@ rte_acl_init(void)
> {
> enum rte_acl_classify_alg alg = RTE_ACL_CLASSIFY_DEFAULT;
>
> -#ifdef RTE_ARCH_ARM64
> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> alg = RTE_ACL_CLASSIFY_NEON;
I believe SIMD is optional in armv7. If true, select alg as
RTE_ACL_CLASSIFY_NEON only when cpufeature NEON enabled.
> #else
> #ifdef CC_AVX2_SUPPORT
> 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..a33c054 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> @@ -53,6 +53,29 @@ typedef union rte_xmm {
> double pd[XMM_SIZE / sizeof(double)];
> } __attribute__((aligned(16))) rte_xmm_t;
>
> +#ifdef RTE_ARCH_ARM
> +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */
> +static __inline uint8x16_t
> +vqtbl1q_u8(uint8x16_t a, uint8x16_t b)
> +{
> + uint8_t i, pos;
> + rte_xmm_t rte_a, rte_b, rte_ret;
> +
> + vst1q_u8(rte_a.u8, a);
> + vst1q_u8(rte_b.u8, b);
> +
> + for (i = 0; i < 16; i++) {
> + pos = rte_b.u8[i];
> + if (pos < 16)
> + rte_ret.u8[i] = rte_a.u8[pos];
> + else
> + rte_ret.u8[i] = 0;
> + }
> +
> + return vld1q_u8(rte_ret.u8);
> +}
> +#endif
> +
> #ifdef __cplusplus
> }
> #endif
> --
> 1.8.3.1
>
[dpdk-dev] 2.3 Roadmap
On Tue, Dec 1, 2015 at 8:42 AM, Matthew Hall wrote: > I am planning to use this to do the captures so you don't incur the headache > or performance issues with rte_kni. > > I am curious how I might be able to link it up w/ the standard libpcap based > tools to get an end-to-end solution with minimal loss Earlier Stephen mentioned using the named pipe behaviour of tcpdump. Is there an opportunity to take what you have mentioned here and marry it to the named pipe output to get the perf you need? Personally I have written a tool which sends packets out of a ring pmd in my main application. The associated rings are polled by another application which dumps to the packets to a pcap file. This has fairly good performance, though my implementation is quite crude. My point here is that sending to a named pipe may not be a bad idea. I don't know how the perf would compare, but it can't be that bad, can it? :P Things might get tricky thought if we need multiple queues to handle the rate of traffic being captured. Not sure how tcpdump would like that. I've also considered using cuse to expose a cdev that tcpdump could read from, but I'm not sure that tcpdump has that ability yet. > > Matthew. Thanks, Kyle
[dpdk-dev] DPDK OVS on Ubuntu 14.04
May need to setup huge pages on kernel boot line (this is example, you may need to adjust): The huge page configuration can be added to the default configuration file /etc/default/grub by adding to the GRUB_CMDLINE_LINUX and the grub configuration file regenerated to get an updated configuration file for Linux boot. # vim /etc/default/grub// edit file . . . GRUB_CMDLINE_LINUX_DEFAULT="... default_hugepagesz=1GB hugepagesz=1GB hugepages=4 hugepagesize=2m hugepages=2048 ..." . . . This example sets up huge pages for both 1 GB pages for 4 GB of 1 GB hugepage memory and 2 MB pages for 4 GB of 2 MB hugepage memory. After boot the number of 1 GB pages cannot be changed, but the number of 2 MB pages can be changed. After editing configuration file /etc/default/grub , the new grub.cfg boot file needs to be regenerated: # update-grub And reboot. After reboot memory managers need to be setup: If /dev/hugepages does not exist:# mkdir /dev/hugepages # mount -t hugetlbfs nodev /dev/hugepages # mkdir /dev/hugepages_2mb # mount -t hugetlbfs nodev /dev/hugepages_2mb -o pagesize=2MB Mike -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Abhijeet Karve Sent: Monday, November 30, 2015 10:14 PM To: dev at dpdk.org Cc: bhavya.addep at gmail.com Subject: [dpdk-dev] DPDK OVS on Ubuntu 14.04 Dear All, We are trying to install DPDK OVS on top of the openstack juno in Ubuntu 14.04 single server. We are referring following steps for executing the same. https://software.intel.com/en-us/blogs/2015/06/09/building-vhost-user-for-ovs-today-using-dpdk-200 During execution we are getting some issues with ovs-vswitchd service as its getting hang during starting. _ nfv-dpdk at nfv-dpdk:~$ tail -f /var/log/openvswitch/ovs-vswitchd.log 2015-11-24T10:54:34.036Z|6|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connecting... 2015-11-24T10:54:34.036Z|7|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connected 2015-11-24T10:54:34.064Z|8|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.4.90 2015-11-24T11:03:42.957Z|2|vlog|INFO|opened log file /var/log/openvswitch/ov s-vswitchd.log 2015-11-24T11:03:42.958Z|3|ovs_numa|INFO|Discovered 24 CPU cores on NUMA nod e 0 2015-11-24T11:03:42.958Z|4|ovs_numa|INFO|Discovered 24 CPU cores on NUMA nod e 1 2015-11-24T11:03:42.958Z|5|ovs_numa|INFO|Discovered 2 NUMA nodes and 48 CPU cores 2015-11-24T11:03:42.958Z|6|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connecting... 2015-11-24T11:03:42.958Z|7|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connected 2015-11-24T11:03:42.961Z|8|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.4.90 _ Also, attaching output(Hugepage.txt) of ? ./ovs-vswitchd --dpdk -c 0x0FF8 -n 4 --socket-mem 1024,0 -- --log-file=/var/log/openvswitch/ovs-vswitchd.log --pidfile=/var/run/oppenvswitch/ovs-vswitchd.pid? - We tried seting up echo 0 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages, but couldn?t succeeded. Can anyone please help us in getting the things if we are missing any and causing ovs-vswitchd to stuck while starting? Also, when we create vm in openstack with DPDK OVS, dpdkvhost-user type interfaces are getting created automatically. If this interfaces are getting mapped with regular br-int bridge rather than DPDK bridge br0 then is this mean that we have successfully enabled DPDK with netdev datapath? We really appreciate for all the advice if you have. Thanks, Abhijeet Thanks & Regards Abhijeet Karve =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
[dpdk-dev] [PATCH 2/4] eal/acl: enable acl for armv7-a
On Tue, 1 Dec 2015 20:13:49 +0530 Jerin Jacob wrote: > > enum rte_acl_classify_alg alg = RTE_ACL_CLASSIFY_DEFAULT; > > > > -#ifdef RTE_ARCH_ARM64 > > +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64) > > alg = RTE_ACL_CLASSIFY_NEON; > > I believe SIMD is optional in armv7. If true, select alg as > RTE_ACL_CLASSIFY_NEON only when cpufeature NEON enabled. Yes. Or, probably, we can be happy with #if defined(__ARM_NEON_FP) ... #endif as it is currently done in rte_memcpy_32.h. Regards Jan
[dpdk-dev] 2.3 Roadmap
On 01/12/2015 15:27, Panu Matilainen wrote: > The problem with that (unless I'm missing something here) is that KNI > requires using out-of-tree kernel modules which makes it pretty much a > non-option for distros. It works fine with some distros. I do not think it should be an argument.
[dpdk-dev] 2.3 Roadmap
On 12/01/2015 04:48 PM, Vincent JARDIN wrote: > On 01/12/2015 15:27, Panu Matilainen wrote: >> The problem with that (unless I'm missing something here) is that KNI >> requires using out-of-tree kernel modules which makes it pretty much a >> non-option for distros. > > It works fine with some distros. I do not think it should be an argument. Its not a question of *working*, its that out-of-tree kernel modules are considered unsupportable by the kernel people. So relying on KNI would make the otherwise important and desireable tcpdump feature non-existent on at least Fedora and RHEL where such modules are practically outright banned by distro policies. - Panu -
[dpdk-dev] [PATCH] mk: bump minimum march in default machine
Hi, thanks! I didn't have the insight of it being "lightly tested and doesn't provide really significant performance improvement". But probably we then should go for the suggestion of the referred mail of "it should probably be disabled by default on all platforms". I'll submit a patch for that then in a few minutes. Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Tue, Dec 1, 2015 at 3:32 PM, Panu Matilainen wrote: > On 12/01/2015 04:26 PM, Christian Ehrhardt wrote: >> >> While playing with building 2.2-rc2 I found that our usual way didn't work >> anymore. >> We usually configured "make config T=x86_64-native-linuxapp-gcc" but then >> set CONFIG_RTE_MACHINE="default" to get something like the "lowest >> acceptable >> build" but with that wide CPU copatibility. >> >> I found that with DPDK 2.2 this fails with issues like: >> In file included from >> /usr/lib/gcc/x86_64-linux-gnu/5/include/immintrin.h:37:0, >> from dpdk-2.2.0-rc2/lib/librte_sched/rte_sched.c:56: >> dpdk-2.2.0-rc2/lib/librte_sched/rte_sched.c: In function >> ?grinder_pipe_exists?: >> /usr/lib/gcc/x86_64-linux-gnu/5/include/smmintrin.h:67:1: error: inlining >> failed in call to always_inline ?_mm_testz_si128?: target specific option >> mismatch >> _mm_testz_si128 (__m128i __M, __m128i __V) >> ^ >> This is a hard need on newer SSE4.x features which are not given with >> march=core2. >> >> So if nehalem (the next march level which has SSE4.x) is the new minimum >> let us >> set this in the default machine config. >> >> Signed-off-by: Christian Ehrhardt >> --- >> >> [diffstat] >> rte.vars.mk |2 +- >>1 file changed, 1 insertion(+), 1 deletion(-) >> >> [diff] >> diff --git a/mk/machine/default/rte.vars.mk >> b/mk/machine/default/rte.vars.mk >> index 53c6af6..170d880 100644 >> --- a/mk/machine/default/rte.vars.mk >> +++ b/mk/machine/default/rte.vars.mk >> @@ -55,4 +55,4 @@ >> # CPU_LDFLAGS = >> # CPU_ASFLAGS = >> >> -MACHINE_CFLAGS += -march=core2 >> +MACHINE_CFLAGS += -march=nehalem >> > > You can just disable CONFIG_RTE_SCHED_VECTOR instead. Also see > http://dpdk.org/ml/archives/dev/2015-November/029067.html > > - Panu -
[dpdk-dev] [PATCH] mk: disable SCHED_VECTOR in the default config
As it causes issues when building with RTE_MACHINE=default due to SSE4.x requirements and in other discussions was so far rated "lightly tested and doesn't provide really significant performance improvement" let us disable that in the default config. (=> http://dpdk.org/ml/archives/dev/2015-November/029067.html) Signed-off-by: Christian Ehrhardt --- [diffstat] common_bsdapp |2 +- common_linuxapp |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) [diff] --- a/config/common_bsdapp +++ b/config/common_bsdapp @@ -440,7 +440,7 @@ CONFIG_RTE_SCHED_COLLECT_STATS=n CONFIG_RTE_SCHED_SUBPORT_TC_OV=n CONFIG_RTE_SCHED_PORT_N_GRINDERS=8 -CONFIG_RTE_SCHED_VECTOR=y +CONFIG_RTE_SCHED_VECTOR=n # # Compile the distributor library --- a/config/common_linuxapp +++ b/config/common_linuxapp @@ -451,7 +451,7 @@ CONFIG_RTE_SCHED_COLLECT_STATS=n CONFIG_RTE_SCHED_SUBPORT_TC_OV=n CONFIG_RTE_SCHED_PORT_N_GRINDERS=8 -CONFIG_RTE_SCHED_VECTOR=y +CONFIG_RTE_SCHED_VECTOR=n # # Compile the distributor library
[dpdk-dev] 2.3 Roadmap
On Tue, Dec 1, 2015 at 3:58 PM, Panu Matilainen wrote: > On 12/01/2015 04:48 PM, Vincent JARDIN wrote: >> >> On 01/12/2015 15:27, Panu Matilainen wrote: >>> >>> The problem with that (unless I'm missing something here) is that KNI >>> requires using out-of-tree kernel modules which makes it pretty much a >>> non-option for distros. >> >> >> It works fine with some distros. I do not think it should be an argument. > > > Its not a question of *working*, its that out-of-tree kernel modules are > considered unsupportable by the kernel people. So relying on KNI would make > the otherwise important and desirable tcpdump feature non-existent on at > least Fedora and RHEL where such modules are practically outright banned by > distro policies. > > - Panu - +1 to that argument from an Ubuntu Point-of-View Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
[dpdk-dev] 2.3 Roadmap
On Tue, Dec 01, 2015 at 04:58:08PM +0200, Panu Matilainen wrote: > On 12/01/2015 04:48 PM, Vincent JARDIN wrote: > >On 01/12/2015 15:27, Panu Matilainen wrote: > >>The problem with that (unless I'm missing something here) is that KNI > >>requires using out-of-tree kernel modules which makes it pretty much a > >>non-option for distros. > > > >It works fine with some distros. I do not think it should be an argument. > > Its not a question of *working*, its that out-of-tree kernel modules are > considered unsupportable by the kernel people. So relying on KNI would make > the otherwise important and desireable tcpdump feature non-existent on at > least Fedora and RHEL where such modules are practically outright banned by > distro policies. > > - Panu - Yes, KNI is a bit of a problem right now in that way. How about a solution which is just based around the idea of setting up a generic port mirroring callback? Hopefully in the future we can get KNI exposed as a PMD, and we already have a ring PMD, and could possibly do a generic file/fifo PMD. Between the 3, we could then have multiple options for intercepting traffic going in/out of an app. The callback would just have to copy the traffic to the selected interface before returning it to the app as normal? /Bruce
[dpdk-dev] [PATCH] mk: disable SCHED_VECTOR in the default config
On Tue, 1 Dec 2015 16:13:23 +0100 Christian Ehrhardt wrote: > As it causes issues when building with RTE_MACHINE=default due to SSE4.x > requirements and in other discussions was so far rated "lightly tested and > doesn't provide really significant performance improvement" let us disable > that in the default config. > (=> http://dpdk.org/ml/archives/dev/2015-November/029067.html) > > Signed-off-by: Christian Ehrhardt Acked-by: Stephen Hemminger
[dpdk-dev] 2.3 Roadmap
Bruce Richardson writes: > On Tue, Dec 01, 2015 at 04:58:08PM +0200, Panu Matilainen wrote: >> On 12/01/2015 04:48 PM, Vincent JARDIN wrote: >> >On 01/12/2015 15:27, Panu Matilainen wrote: >> >>The problem with that (unless I'm missing something here) is that KNI >> >>requires using out-of-tree kernel modules which makes it pretty much a >> >>non-option for distros. >> > >> >It works fine with some distros. I do not think it should be an argument. >> >> Its not a question of *working*, its that out-of-tree kernel modules are >> considered unsupportable by the kernel people. So relying on KNI would make >> the otherwise important and desireable tcpdump feature non-existent on at >> least Fedora and RHEL where such modules are practically outright banned by >> distro policies. >> >> - Panu - > > Yes, KNI is a bit of a problem right now in that way. > > How about a solution which is just based around the idea of setting up a > generic > port mirroring callback? Hopefully in the future we can get KNI > exposed as a PMD, > and we already have a ring PMD, and could possibly do a generic file/fifo PMD. > Between the 3, we could then have multiple options for intercepting traffic > going in/out of an app. The callback would just have to copy the traffic to > the > selected interface before returning it to the app as normal? > > /Bruce I'm actually working on a patch series that uses a TAP device (it's currently been only minorly tested) called back from the port input. The benefit is no dependancy on kernel modules (just TUN/TAP support). I don't have a way of signaling sampling, so right now, it's just drinking from the firehose. Nothing I'm ready to put out publicly (because it's ugly - just a PoC), but it allows a few things: 1) on demand on/off using standard linux tools (ifconfig/ip to set tap device up/down) 2) Can work with any tool which reads off of standard linux interfaces (tcpdump/wireshark work out of the box, but you could plug in any pcap or non-pcap tool) 3) Doesn't require changes to the application (no command line switches during startup, etc.) As I said, I'm not ready to put it out there publicly, because I haven't had a chance to check the performance, and it's definitely not following any kind of DPDK-like coding style. Just wanted to throw this out as food for thought - if you think this approach is worthwhile I can try to prioritize it, at least to get an RFC series out. -Aaron
[dpdk-dev] 2.3 Roadmap
> -Original Message- > From: Aaron Conole [mailto:aconole at redhat.com] > Sent: Tuesday, December 1, 2015 3:31 PM > To: Richardson, Bruce > Cc: Panu Matilainen ; dev at dpdk.org > Subject: Re: [dpdk-dev] 2.3 Roadmap > > Bruce Richardson writes: > > On Tue, Dec 01, 2015 at 04:58:08PM +0200, Panu Matilainen wrote: > >> On 12/01/2015 04:48 PM, Vincent JARDIN wrote: > >> >On 01/12/2015 15:27, Panu Matilainen wrote: > >> >>The problem with that (unless I'm missing something here) is that > >> >>KNI requires using out-of-tree kernel modules which makes it pretty > >> >>much a non-option for distros. > >> > > >> >It works fine with some distros. I do not think it should be an > argument. > >> > >> Its not a question of *working*, its that out-of-tree kernel modules > >> are considered unsupportable by the kernel people. So relying on KNI > >> would make the otherwise important and desireable tcpdump feature > >> non-existent on at least Fedora and RHEL where such modules are > >> practically outright banned by distro policies. > >> > >>- Panu - > > > > Yes, KNI is a bit of a problem right now in that way. > > > > How about a solution which is just based around the idea of setting up > > a generic port mirroring callback? Hopefully in the future we can get > > KNI exposed as a PMD, and we already have a ring PMD, and could > > possibly do a generic file/fifo PMD. > > Between the 3, we could then have multiple options for intercepting > > traffic going in/out of an app. The callback would just have to copy > > the traffic to the selected interface before returning it to the app as > normal? > > > > /Bruce > > I'm actually working on a patch series that uses a TAP device (it's > currently been only minorly tested) called back from the port input. The > benefit is no dependancy on kernel modules (just TUN/TAP support). I don't > have a way of signaling sampling, so right now, it's just drinking from > the firehose. Nothing I'm ready to put out publicly (because it's ugly - > just a PoC), but it allows a few things: > > 1) on demand on/off using standard linux tools (ifconfig/ip to set tap >device up/down) > 2) Can work with any tool which reads off of standard linux interfaces >(tcpdump/wireshark work out of the box, but you could plug in any >pcap or non-pcap tool) > 3) Doesn't require changes to the application (no command line switches >during startup, etc.) > > As I said, I'm not ready to put it out there publicly, because I haven't > had a chance to check the performance, and it's definitely not following > any kind of DPDK-like coding style. Just wanted to throw this out as food > for thought - if you think this approach is worthwhile I can try to > prioritize it, at least to get an RFC series out. > > -Aaron Once I had a generic file-handling PMD written, I was then considering extending it to work with TUN/TAP too. :-) I think a TAP PMD would be useful for the downstream distros who can't package KNI as it is right now. /Bruce
[dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
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
> ---
> 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 tabl
[dpdk-dev] [PATCH 4/4] maintainers: claim resposibility for ARMv7 and ARMv8
On Tue, Dec 01, 2015 at 01:41:16PM -0500, Jianbo Liu wrote: > Signed-off-by: Jianbo Liu > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4478862..f859985 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -124,10 +124,12 @@ F: doc/guides/sample_app_ug/multi_process.rst > > ARM v7 > M: Jan Viktorin > +M: Jianbo Liu > F: lib/librte_eal/common/include/arch/arm/ > > ARM v8 > M: Jerin Jacob > +M: Jianbo Liu +1 > F: lib/librte_eal/common/include/arch/arm/*_64.h > F: lib/librte_acl/acl_run_neon.* > > -- > 1.8.3.1 >
[dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
On Tue, 1 Dec 2015 22:11:42 +0530 Jerin Jacob 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 I've missed that too. Did you CC me? Jan -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] Unable to configure ethdev in secondary process using ring PMD
On 11/30/2015 07:53 PM, Richardson, Bruce wrote: > > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alexey Bogdanenko >> Sent: Monday, November 30, 2015 4:17 PM >> To: dev at dpdk.org >> Subject: [dpdk-dev] Unable to configure ethdev in secondary process using >> ring PMD >> >> Hello, >> >> I would like to setup communication between two existing DPDK applications >> and run them on the same host. >> >> "Connecting their ports" in some way in order not to rewrite the >> applications would be very desirable. Specifically, I would like one >> process to send packets and the second process to receive the packets >> using rte_eth_tx_burst() and rte_eth_rx_burst() respectively. >> >> The most straightforward way to accomplish this seems to be by using ring >> based PMD API as described in the documentation [1] and email [2]. >> To adapt the example from the documentation to multi-process scenario, I >> call rte_ring_create() and rte_eth_from_rings() in the primary process, >> rte_ring_lookup() and rte_eth_from_rings() in the secondary process. >> After that each process calls rte_eth_dev_configure(). >> >> Unfortunately, the function returns -1001 in the secondary process, which >> is explained in debug log: >> >> PMD: rte_eth_dev_configure: Cannot run in secondary processes >> >> Is it possible to connect the applications as described above? Any advice >> would be appreciated. >> >> References: >> >> 1. Network Interface Controller Drivers. Chapter 8. >> Libpcap and Ring Based Poll Mode Drivers. >> >> 2. DPDK ML. Fri Dec 6 07:22:06 CET 2013. How to know corresponding device >> from port number. Tetsuya.Mukawa >> >> Thanks, >> >> Alexey Bogdanenko > > Hi Alexey, > > The ring PMDs returned from eth_from_rings should be all ready to be used > without having to explicitly configure it or set up the queues. > > /Bruce > Thanks for the quick reply, I updated dpdk from v2.1.0 to a more recent version (near v2.2.0-rc2), removed calls to rte_eth_dev_configure(), rte_eth_rx_queue_setup(). It solved the problem. Your advice was very helpful. However, I encountered a rather minor but similar issue, which is that rte_eth_dev_start() returns -1001 in the secondary processes. The message I get is: rte_eth_dev_start: Cannot run in secondary processes Now, I could avoid calling the function altogether, however in this case rte_eth_link_get_nowait() reports that the link status is down which is a bit inconvenient. Did I miss anything or is it just a limitation of ring PMD? Alexey Bogdanenko
[dpdk-dev] Unable to configure ethdev in secondary process using ring PMD
On Tue, Dec 01, 2015 at 08:30:15PM +0300, Alexey Bogdanenko wrote: > On 11/30/2015 07:53 PM, Richardson, Bruce wrote: > > > > > >>-Original Message- > >>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alexey Bogdanenko > >>Sent: Monday, November 30, 2015 4:17 PM > >>To: dev at dpdk.org > >>Subject: [dpdk-dev] Unable to configure ethdev in secondary process using > >>ring PMD > >> > >>Hello, > >> > >>I would like to setup communication between two existing DPDK applications > >>and run them on the same host. > >> > >>"Connecting their ports" in some way in order not to rewrite the > >>applications would be very desirable. Specifically, I would like one > >>process to send packets and the second process to receive the packets > >>using rte_eth_tx_burst() and rte_eth_rx_burst() respectively. > >> > >>The most straightforward way to accomplish this seems to be by using ring > >>based PMD API as described in the documentation [1] and email [2]. > >>To adapt the example from the documentation to multi-process scenario, I > >>call rte_ring_create() and rte_eth_from_rings() in the primary process, > >>rte_ring_lookup() and rte_eth_from_rings() in the secondary process. > >>After that each process calls rte_eth_dev_configure(). > >> > >>Unfortunately, the function returns -1001 in the secondary process, which > >>is explained in debug log: > >> > >>PMD: rte_eth_dev_configure: Cannot run in secondary processes > >> > >>Is it possible to connect the applications as described above? Any advice > >>would be appreciated. > >> > >>References: > >> > >>1. Network Interface Controller Drivers. Chapter 8. > >>Libpcap and Ring Based Poll Mode Drivers. > >> > >>2. DPDK ML. Fri Dec 6 07:22:06 CET 2013. How to know corresponding device > >>from port number. Tetsuya.Mukawa > >> > >>Thanks, > >> > >>Alexey Bogdanenko > > > >Hi Alexey, > > > >The ring PMDs returned from eth_from_rings should be all ready to be used > >without having to explicitly configure it or set up the queues. > > > >/Bruce > > > > Thanks for the quick reply, > > I updated dpdk from v2.1.0 to a more recent version (near v2.2.0-rc2), > removed calls to rte_eth_dev_configure(), rte_eth_rx_queue_setup(). It > solved the problem. > > Your advice was very helpful. > > However, I encountered a rather minor but similar issue, which is that > rte_eth_dev_start() returns -1001 in the secondary processes. The message I > get is: > > rte_eth_dev_start: Cannot run in secondary processes > > Now, I could avoid calling the function altogether, however in this case > rte_eth_link_get_nowait() reports that the link status is down which is a > bit inconvenient. > > Did I miss anything or is it just a limitation of ring PMD? > > Alexey Bogdanenko Sounds like a limitation that shouldn't be there. Possibly a bug. /Bruce
[dpdk-dev] [PATCH v7 00/11] Add installation rules for dpdk files.
Hi Mario, Thanks for your work. There are some interesting ideas :) I'm going to send a patchset to establish the same kind of rules keeping the old install behaviour and allowing a standard one with the same name (install). The result would be closed to what pkg/dpdk.spec provides. Your review would be appreciated.
[dpdk-dev] 2.3 Roadmap
On Tue, Dec 01, 2015 at 09:45:56AM -0500, Kyle Larose wrote: > Earlier Stephen mentioned using the named pipe behaviour of tcpdump. > Is there an opportunity to take what you have mentioned here and marry > it to the named pipe output to get the perf you need? I am wondering about the same thing. But I didn't want to limit the scope of solutions too much so I didn't specifically enumerate this possibility. Matthew.
[dpdk-dev] 2.3 Roadmap
On Tue, Dec 01, 2015 at 10:31:02AM -0500, Aaron Conole wrote: > The benefit is no dependancy on kernel modules (just TUN/TAP support). I > don't have a way of signaling sampling, so right now, it's just drinking > from the firehose. This is actually quite a good idea. Many years ago I coded up a simple connector between DPDK and TAP devices for use with some legacy applications that did not support DPDK. I could definitely connect the output of user-space bpfjit to a TAP device quite easily. I am somewhat less clear on how to connect tcpdump or other standard libpcap based entities up, so that one could change the capture filters or other settings from outside the DPDK application. I am hoping some of the network API experts can comment on this since I'm just a security specialist. How are you letting people configure the capture filter in this scenario? Matthew.
[dpdk-dev] [PATCH v7 00/11] Add installation rules for dpdk files.
Hi Thomas, Thank you for your answer, John Mcnamara gave feedback about documentation in this version (7) and I'm going to send a version number 8 with new changes about documentation, it would be amazing if you could take a look it :) thank you for your attention. Mario. From: Thomas Monjalon [thomas.monja...@6wind.com] Sent: Tuesday, December 01, 2015 11:17 AM To: Arevalo, Mario Alfredo C Cc: dev at dpdk.org; olivier.matz at 6wind.com; miguel.bernal.marin at linux.intel.com; Venegas Munoz, Jos C; Richardson, Bruce; david.marchand at 6wind.com Subject: Re: [PATCH v7 00/11] Add installation rules for dpdk files. Hi Mario, Thanks for your work. There are some interesting ideas :) I'm going to send a patchset to establish the same kind of rules keeping the old install behaviour and allowing a standard one with the same name (install). The result would be closed to what pkg/dpdk.spec provides. Your review would be appreciated.
[dpdk-dev] [PATCH v8 00/11] Add installation rules for dpdk files.
DPDK package lacks of a mechanism to install libraries, headers applications, kernel modules and sdk files to a file system tree. This patch set allows to install files based on the next proposal: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html v8: When "make install" is invoked if "T" variable is defined, the installation process will have the current behaviour, else "install-fhs" rule will be called. Using rules support is possible to do the next steps: make config T= make make Modify the makefile target to specify the files that will be installed using a rule: * make install-bin (install app files)(dafault path bindir=$(exec_prefix)/bin). * make install-headers (install headers)(dafault path includedir=$(prefix)/include/dpdk). * make install-lib (install libraries)(dafault path libdir=$(exec_prefix)/lib). * make install-doc (install documentation)(dafault path docdir=$(datarootdir)/doc/dpdk). * make install-mod (install modules)(dafault path if RTE_EXEC_ENV=linuxapp then kerneldir=/lib/modules/$(uname -r)/extra/drivers/dpdk else kerneldir=/boot/modules). * make install-sdk (install headers, makefiles, scripts,examples and config files) (default path sdkdir=$(datadir)/share/dpdk). * make install-fhs (install libraries, modules, app files, tools and documentation). * make install (if T is defined current behaviour, else it will call install-fhs rule). The following defaults apply: prefix=/usr/local exec_prefix=$(prefix) datarootdir=$(prefix)/share All path variables can be overridden and all targets can use the "DESTDIR" variable. Furthermore this information is added to documentation. v7: When "make install" is invoked if "T" variable is defined, the installation process will have the current behaviour, else "install-fhs" rule will be called. Using rules support is possible to do the next steps: make config T= make make Modify the makefile target to specify the files that will be installed using a rule: * make install-bin (install app files)(dafault path bindir=$(exec_prefix)/bin). * make install-headers (install headers)(dafault path includedir=$(prefix)/include/dpdk). * make install-lib (install libraries)(dafault path libdir=$(exec_prefix)/lib). * make install-doc (install documentation)(dafault path docdir=$(datarootdir)/doc/dpdk). * make install-mod (install modules)(dafault path if RTE_EXEC_ENV=linuxapp then kerneldir=/lib/modules/$(uname -r)/extra/drivers/dpdk else kerneldir=/boot/modules). * make install-sdk (install headers, makefiles, scripts,examples and config files) (default path sdkdir=$(datadir)/share/dpdk). * make install-fhs (install libraries, modules, app files, nic bind files (tools) and documentation). * make install (if T is defined current behaviour, else it will call install-fhs rule). where prefix=/usr/local, exec_prefix=$(prefix), datarootdir=$(prefix)/share, and datadir=$(datarootdir)/dpdk by default. Also you can use the DESTDIR var. All directory variables mentioned above can be overridden (bindir, libdir, includedir, docidr, kerneldir, prefix, exec_prefix and data). Furthermore this information is added to documentation. v6: When "make install" is invoked if "T" variable is defined, the installation process will have the current behaviour, else "install-fhs" rule will be called. Using rules support is possible to do the next steps: make config T= make make Modify the makefile target to specify the files that will be installed using a rule: * make install-bin (install app files)(dafault path BIN_DIR=$(RTE_PREFIX)/bin). * make install-headers (install headers)(dafault path INCLUDE_DIR=$(RTE_PREFIX)/include/dpdk). * make install-lib (install libraries)(dafault path LIB_DIR=$(RTE_PREFIX)/lib). * make install-doc (install documentation)(dafault path DOC_DIR=$(RTE_PREFIX)/share/doc/dpdk). * make install-mod (install modules)(dafault path if RTE_EXEC_ENV=linuxapp then KMOD_DIR=/lib/modules/$(uname -r)/extra/drivers/dpdk else KMOD_DIR=/boot/modules). * make install-sdk (install headers, makefiles, scripts,examples, tools and config files) (default path DATA_DIR=$(RTE_PREFIX)/share/dpdk). * make install-fhs (install libraries, modules, app files, nic bind files and documentation). * make install (if T is defined current behaviour, else it will call install-fhs rule ) where RTE_PREFIX=/usr/local by default. Also you can use the DESTDIR var. All directory variables mentioned above can be overridden (BIN_DIR, LIB_DIR, INCLUDE_DIR, DOC_DIR, KMOD_DIR, RTE_PREFIX and DATA_DIR). Furthermore this information is added to documentation. v5: When "make install" is invoked if "T" variable is defined, the installation process will have the current behaviour, else "install-fhs" rule will be called. Using rules support is possible to do the next steps: make config T= make
[dpdk-dev] [PATCH v8 01/11] mk: Add rule for installing headers
Add hierarchy-file support to the DPDK headers,
when invoking "make install-headers" headers will
be installed in: $(DESTDIR)/$(includedir)
where includedir=$(prefix)/include/dpdk and prefix=/usr/local by
default, you can override "prefix" and "includedir" vars.
This hierarchy is based on:
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
and variables are based on:
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
https://www.gnu.org/prep/standards/html_node/DESTDIR.html
Signed-off-by: Mario Carrillo
---
mk/rte.sdkinstall.mk | 22 +-
mk/rte.sdkroot.mk| 4 ++--
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index 86c98a5..a4a01cf 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -41,6 +41,11 @@ endif
# x86_64-native-*-gcc
ifndef T
T=*
+ifneq (,$(wildcard $(RTE_OUTPUT)/.config))
+prefix ?= /usr/local
+includedir ?= $(prefix)/include/dpdk
+HSLINKS := $(shell find $(RTE_OUTPUT)/include/ -name *.h)
+endif
endif
#
@@ -72,7 +77,22 @@ install: $(INSTALL_TARGETS)
echo "Using local configuration"; \
fi
$(Q)$(MAKE) all O=$(BUILD_DIR)/$*
-
+#
+# install headers in /usr/local/include/dpdk by default
+# "prefix" and "includedir" vars can be overridden.
+#
+.PHONY: install-headers
+install-headers:
+ @echo == Installing headers;
+ @if [ ! -z "${HSLINKS}" ]; then \
+ for HSLINK in ${HSLINKS}; do \
+ HEADER=$$(readlink -f $$HSLINK); \
+ HEADER_DIR=$$(dirname $$HSLINK | sed 's/.*include\/*//'); \
+ [ -d $(DESTDIR)/$(includedir)/$$HEADER_DIR ] || mkdir -p
$(DESTDIR)/$(includedir)/$$HEADER_DIR; \
+ cp -rf $$HEADER ${DESTDIR}/${includedir}/$$HEADER_DIR; \
+ echo installing: $$HEADER; \
+ done \
+ fi
#
# uninstall: remove all built sdk
#
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index e8423b0..8477a2b 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -97,8 +97,8 @@ test fast_test ring_test mempool_test perf_test coverage:
testall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@
-.PHONY: install uninstall
-install uninstall:
+.PHONY: install install-headers uninstall
+install install-headers uninstall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
.PHONY: doc help
--
2.6.3
[dpdk-dev] [PATCH v8 02/11] mk: Add rule for installing app files
Add hierarchy-file support to the DPDK app files,
nic bind file and cpu layout file
when invoking "make install-bin" app files will
be installed in: $(DESTDIR)/$(bindir)
where bindir=$(exec_prefix)/usr/local/bin
prefix=/usr/local
and exec_prefix=$(prefix) by default,
you can override prefix, exec_prefix and bindir vars.
This hierarchy is based on:
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
and variables are based on:
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
https://www.gnu.org/prep/standards/html_node/DESTDIR.html
Signed-off-by: Mario Carrillo
---
mk/rte.sdkinstall.mk | 19 +++
mk/rte.sdkroot.mk| 4 ++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index a4a01cf..93de06b 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -43,8 +43,13 @@ ifndef T
T=*
ifneq (,$(wildcard $(RTE_OUTPUT)/.config))
prefix ?= /usr/local
+exec_prefix ?= $(prefix)
includedir ?= $(prefix)/include/dpdk
+bindir ?= $(exec_prefix)/bin
HSLINKS := $(shell find $(RTE_OUTPUT)/include/ -name *.h)
+BINARY_FILES := $(patsubst %.map,,$(wildcard $(RTE_OUTPUT)/app/*))
+NIC_FILES := $(wildcard $(RTE_SDK)/tools/*.py)
+BINARY_FILES += $(NIC_FILES)
endif
endif
@@ -94,6 +99,20 @@ install-headers:
done \
fi
#
+# install app files in /usr/local/bin by default
+# "prefix" and "bindir" can be overridden.
+#
+.PHONY: install-bin
+install-bin:
+ @echo == Installing app files;
+ @if [ ! -z "${BINARY_FILES}" ]; then \
+ [ -d $(DESTDIR)/$(bindir) ] || mkdir -p $(DESTDIR)/$(bindir); \
+ for BIN_FILE in ${BINARY_FILES}; do \
+ cp -rf $$BIN_FILE ${DESTDIR}/${bindir}; \
+ echo installing: $$BIN_FILE; \
+ done \
+ fi
+#
# uninstall: remove all built sdk
#
UNINSTALL_TARGETS := $(addsuffix _uninstall,\
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index 8477a2b..24eaa60 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -97,8 +97,8 @@ test fast_test ring_test mempool_test perf_test coverage:
testall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@
-.PHONY: install install-headers uninstall
-install install-headers uninstall:
+.PHONY: install install-headers install-bin uninstall
+install install-headers install-bin uninstall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
.PHONY: doc help
--
2.6.3
[dpdk-dev] [PATCH v8 03/11] mk: Add rule for installing libraries
Add hierarchy-file support to the DPDK libraries,
when invoking "make install-lib" libraries will
be installed in: $(DESTDIR)/$(libdir)
where libdir=$(exec_prefix)/usr/lib
prefix=/usr/local
and exec_prefix=$(prefix) by default,
you can override prefix, exec_prefix and libdir vars.
This hierarchy is based on:
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
and variables are based on:
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
https://www.gnu.org/prep/standards/html_node/DESTDIR.html
Signed-off-by: Mario Carrillo
---
mk/rte.sdkinstall.mk | 16
mk/rte.sdkroot.mk| 4 ++--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index 93de06b..ff99afe 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -46,9 +46,11 @@ prefix ?= /usr/local
exec_prefix ?= $(prefix)
includedir ?= $(prefix)/include/dpdk
bindir ?= $(exec_prefix)/bin
+libdir ?= $(exec_prefix)/lib
HSLINKS := $(shell find $(RTE_OUTPUT)/include/ -name *.h)
BINARY_FILES := $(patsubst %.map,,$(wildcard $(RTE_OUTPUT)/app/*))
NIC_FILES := $(wildcard $(RTE_SDK)/tools/*.py)
+LIBS := $(wildcard $(RTE_OUTPUT)/lib/*)
BINARY_FILES += $(NIC_FILES)
endif
endif
@@ -113,6 +115,20 @@ install-bin:
done \
fi
#
+# install libs in /usr/local/lib by default
+# "prefix" and "libdir" can be overridden.
+#
+.PHONY: install-lib
+install-lib:
+ @echo == Installing libraries
+ @if [ ! -z "${LIBS}" ]; then \
+ [ -d $(DESTDIR)/$(libdir) ] || mkdir -p $(DESTDIR)/$(libdir); \
+ for LIB in ${LIBS}; do \
+ cp -rf $$LIB ${DESTDIR}/${libdir}; \
+ echo installing: $$LIB; \
+ done \
+ fi
+#
# uninstall: remove all built sdk
#
UNINSTALL_TARGETS := $(addsuffix _uninstall,\
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index 24eaa60..7a72c9b 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -97,8 +97,8 @@ test fast_test ring_test mempool_test perf_test coverage:
testall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@
-.PHONY: install install-headers install-bin uninstall
-install install-headers install-bin uninstall:
+.PHONY: install install-headers install-bin install-lib uninstall
+install install-headers install-bin install-lib uninstall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
.PHONY: doc help
--
2.6.3
[dpdk-dev] [PATCH v8 04/11] mk: Add rule for installing modules
Add hierarchy-file support to the DPDK modules,
when invoking "make install-mod" modules will be
installed in: $(DESTDIR)/$(kerneldir)
if RTE_EXEC_ENV=linuxapp then
kerneldir=/lib/modules/$(uname -r)/extra/drivers/dpdk
else kerneldir=/boot/modules
by default, you can override "kerneldir" var.
This hierarchy is based on:
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
Signed-off-by: Mario Carrillo
---
mk/rte.sdkinstall.mk | 24
mk/rte.sdkroot.mk| 4 ++--
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index ff99afe..1502399 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -51,7 +51,15 @@ HSLINKS := $(shell find $(RTE_OUTPUT)/include/ -name *.h)
BINARY_FILES := $(patsubst %.map,,$(wildcard $(RTE_OUTPUT)/app/*))
NIC_FILES := $(wildcard $(RTE_SDK)/tools/*.py)
LIBS := $(wildcard $(RTE_OUTPUT)/lib/*)
+MODULES := $(wildcard $(RTE_OUTPUT)/kmod/*)
BINARY_FILES += $(NIC_FILES)
+include $(RTE_OUTPUT)/.config
+RTE_EXEC_ENV := $(CONFIG_RTE_EXEC_ENV:"%"=%)
+ifeq ($(RTE_EXEC_ENV),linuxapp)
+kerneldir ?= /lib/modules/$(shell uname -r)/extra/drivers/dpdk
+else
+kerneldir ?= /boot/modules
+endif
endif
endif
@@ -129,6 +137,22 @@ install-lib:
done \
fi
#
+# if RTE_EXEC_ENV=linuxapp modules install in:
+# /lib/modules/$(uname -r)/extra/drivers/dpdk
+# else /boot/modules/ by default
+# "kerneldir" var can be overridden.
+#
+.PHONY: install-mod
+install-mod:
+ @echo == Installing modules
+ @if [ ! -z "${MODULES}" ]; then \
+ [ -d $(DESTDIR)/$(kerneldir) ] || mkdir -p $(DESTDIR)/$(kerneldir); \
+ for MOD in ${MODULES}; do \
+ cp -rf $$MOD ${DESTDIR}/${kerneldir}; \
+ echo installing: $$MOD; \
+ done \
+ fi
+#
# uninstall: remove all built sdk
#
UNINSTALL_TARGETS := $(addsuffix _uninstall,\
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index 7a72c9b..e652218 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -97,8 +97,8 @@ test fast_test ring_test mempool_test perf_test coverage:
testall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@
-.PHONY: install install-headers install-bin install-lib uninstall
-install install-headers install-bin install-lib uninstall:
+.PHONY: install install-headers install-bin install-lib install-mod uninstall
+install install-headers install-bin install-lib install-mod uninstall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
.PHONY: doc help
--
2.6.3
[dpdk-dev] [PATCH v8 05/11] mk: Add rule for installing documentation
Add hierarchy-file support to the DPDK documentation,
when invoking "make install-doc" documentation files will
be installed in: $(DESTDIR)/$(docdir) where
docdir=$(datarootdir)/doc/dpdk
datarootdir=$(prefix)/share
prefix=/usr/local by default, you can override "prefix",
"datarootdir" and "docdir" vars.
This hierarchy is based on:
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
and variables are based on:
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
https://www.gnu.org/prep/standards/html_node/DESTDIR.html
Signed-off-by: Mario Carrillo
---
mk/rte.sdkinstall.mk | 17 +
mk/rte.sdkroot.mk| 5 +++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index 1502399..c062489 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -47,11 +47,14 @@ exec_prefix ?= $(prefix)
includedir ?= $(prefix)/include/dpdk
bindir ?= $(exec_prefix)/bin
libdir ?= $(exec_prefix)/lib
+datarootdir ?= $(prefix)/share
+docdir ?= $(datarootdir)/doc/dpdk
HSLINKS := $(shell find $(RTE_OUTPUT)/include/ -name *.h)
BINARY_FILES := $(patsubst %.map,,$(wildcard $(RTE_OUTPUT)/app/*))
NIC_FILES := $(wildcard $(RTE_SDK)/tools/*.py)
LIBS := $(wildcard $(RTE_OUTPUT)/lib/*)
MODULES := $(wildcard $(RTE_OUTPUT)/kmod/*)
+DOCS := $(wildcard $(RTE_SDK)/doc/*)
BINARY_FILES += $(NIC_FILES)
include $(RTE_OUTPUT)/.config
RTE_EXEC_ENV := $(CONFIG_RTE_EXEC_ENV:"%"=%)
@@ -153,6 +156,20 @@ install-mod:
done \
fi
#
+# install documentation in /usr/local/share/doc/dpdk
+# by default, "docdir", "prefix" and "datarootdir" vars can be overriden.
+#
+.PHONY: install-doc
+install-doc:
+ @echo == Installing documentation
+ @if [ ! -z "${DOCS}" ]; then \
+ [ -d $(DESTDIR)/$(docdir) ] || mkdir -p $(DESTDIR)/$(docdir); \
+ for DOC in ${DOCS}; do \
+ cp -rf $$DOC ${DESTDIR}/${docdir}; \
+ echo installing: $$DOC; \
+ done \
+ fi
+#
# uninstall: remove all built sdk
#
UNINSTALL_TARGETS := $(addsuffix _uninstall,\
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index e652218..f56341d 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -97,8 +97,9 @@ test fast_test ring_test mempool_test perf_test coverage:
testall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@
-.PHONY: install install-headers install-bin install-lib install-mod uninstall
-install install-headers install-bin install-lib install-mod uninstall:
+.PHONY: install install-headers install-bin install-lib install-mod \
+install-doc uninstall
+install install-headers install-bin install-lib install-mod install-doc
uninstall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
.PHONY: doc help
--
2.6.3
[dpdk-dev] [PATCH v8 06/11] mk: Add rule for installing sdk files
Add hierarchy-file support to the DPDK makefiles, scripts, examples, tools, config files and headers, when invoking "make install-sdk" makefiles, scripts, examples and config files will be installed in: $(DESTDIR)/$(sdkdir) and headers will be installed in: $(DESTDIR)/$(includedir) where sdkdir=$(datadir) datadir=$(datarootdir)/dpdk datarootdir=$(prefix)/share includedir=$(prefix)/include/dpdk prefix=/usr/local by default, you can override "prefix", "sdkdir", "datadir", "datarootdir" and "includedir" vars. This hierarchy is based on: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html and variables are based on: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html https://www.gnu.org/prep/standards/html_node/DESTDIR.html Signed-off-by: Mario Carrillo --- mk/rte.sdkinstall.mk | 19 +++ mk/rte.sdkroot.mk| 5 +++-- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk index c062489..09950fa 100644 --- a/mk/rte.sdkinstall.mk +++ b/mk/rte.sdkinstall.mk @@ -49,6 +49,8 @@ bindir ?= $(exec_prefix)/bin libdir ?= $(exec_prefix)/lib datarootdir ?= $(prefix)/share docdir ?= $(datarootdir)/doc/dpdk +datadir ?= $(datarootdir)/dpdk +sdkdir ?= $(datadir) HSLINKS := $(shell find $(RTE_OUTPUT)/include/ -name *.h) BINARY_FILES := $(patsubst %.map,,$(wildcard $(RTE_OUTPUT)/app/*)) NIC_FILES := $(wildcard $(RTE_SDK)/tools/*.py) @@ -170,6 +172,23 @@ install-doc: done \ fi # +# install sdk files in /usr/local/share/dpdk by default +# where prefix and "sdkdir", "datadir" and "prefix" var can be overridden. +# +.PHONY: install-sdk +install-sdk: install-headers + @echo == Installing sdk files + @[ -d $(DESTDIR)/$(sdkdir) ] || mkdir -p $(DESTDIR)/$(sdkdir); \ + cp -rf $(RTE_SDK)/mk $(DESTDIR)/$(sdkdir); \ + echo installing: $(RTE_SDK)/mk; \ + cp -rf $(RTE_SDK)/scripts $(DESTDIR)/$(sdkdir); \ + echo installing: $(RTE_SDK)/scripts; \ + cp -rf $(RTE_SDK)/examples $(DESTDIR)/$(sdkdir); \ + echo installing: $(RTE_SDK)/examples; + @[ -d $(DESTDIR)/$(sdkdir)/config ] || mkdir -p $(DESTDIR)/$(sdkdir)/config; \ + cp -f $(RTE_SDK)/build/.config $(DESTDIR)/$(sdkdir)/config; \ + echo installing: $(RTE_OUTPUT)/.config +# # uninstall: remove all built sdk # UNINSTALL_TARGETS := $(addsuffix _uninstall,\ diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk index f56341d..6fac88a 100644 --- a/mk/rte.sdkroot.mk +++ b/mk/rte.sdkroot.mk @@ -98,8 +98,9 @@ testall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@ .PHONY: install install-headers install-bin install-lib install-mod \ -install-doc uninstall -install install-headers install-bin install-lib install-mod install-doc uninstall: +install-doc install-sdk uninstall +install install-headers install-bin install-lib install-mod install-doc \ +install-sdk uninstall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@ .PHONY: doc help -- 2.6.3
[dpdk-dev] [PATCH v8 07/11] mk: Add rule for installing runtime files
Add hierarchy-file support to the DPDK libraries, modules, binary files, nic bind file, cpu layout file (tools) and documentation, when invoking "make install-fhs" (filesystem hierarchy standard) runtime files will be by default installed in: $(DESTDIR)/$(bindir) where bindir=$(exec_prefix)/bin (binary files) $(DESTDIR)/$(docdir) where docdir=$(datarootdir)/doc/dpdk (documentation) $(DESTDIR)/$(libdir) where libdir=$(exec_prefix)/lib (libraries) $(DESTDIR)/$(kerneldir) (modules) if RTE_EXEC_ENV=linuxapp then kerneldir=/lib/modules/$(uname -r)/extra/drivers/dpdk else kerneldir=/boot/modules exec_prefix=$(prefix) datarootdir=$(prefix)/share and prefix=/usr/local All directory variables mentioned above can be overridden. This hierarchy is based on: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html and variables are based on: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html https://www.gnu.org/prep/standards/html_node/DESTDIR.html Signed-off-by: Mario Carrillo --- mk/rte.sdkinstall.mk | 9 + mk/rte.sdkroot.mk| 4 ++-- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk index 09950fa..d1ff160 100644 --- a/mk/rte.sdkinstall.mk +++ b/mk/rte.sdkinstall.mk @@ -189,6 +189,15 @@ install-sdk: install-headers cp -f $(RTE_SDK)/build/.config $(DESTDIR)/$(sdkdir)/config; \ echo installing: $(RTE_OUTPUT)/.config # +# install runtime files +# +.PHONY: install-fhs +install-fhs: install-lib install-bin install-doc install-mod + @echo == Installing runtime files + @[ -d $(DESTDIR)/$(datadir) ] || mkdir -p $(DESTDIR)/$(datadir); \ + cp -rf $(RTE_SDK)/tools $(DESTDIR)/$(datadir); \ + echo installing: $(RTE_SDK)/tools +# # uninstall: remove all built sdk # UNINSTALL_TARGETS := $(addsuffix _uninstall,\ diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk index 6fac88a..dd5f399 100644 --- a/mk/rte.sdkroot.mk +++ b/mk/rte.sdkroot.mk @@ -98,9 +98,9 @@ testall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@ .PHONY: install install-headers install-bin install-lib install-mod \ -install-doc install-sdk uninstall +install-doc install-sdk install-fhs uninstall install install-headers install-bin install-lib install-mod install-doc \ -install-sdk uninstall: +install-sdk install-fhs uninstall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@ .PHONY: doc help -- 2.6.3
[dpdk-dev] [PATCH v8 08/11] app: Change name to test binary
This is order to test could be installed in a file herarchy and do not make a colision with test command from coreutils package. Signed-off-by: Mario Carrillo --- app/test/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/test/Makefile b/app/test/Makefile index ec33e1a..184f91b 100644 --- a/app/test/Makefile +++ b/app/test/Makefile @@ -36,7 +36,7 @@ ifeq ($(CONFIG_RTE_APP_TEST),y) # # library name # -APP = test +APP = test-dpdk # # all sources are stored in SRCS-y -- 2.6.3
[dpdk-dev] [PATCH v8 09/11] mk: Rename install rule as mbuild rule
"install" rule with the current dpdk behaviour change its name by mbuild. Signed-off-by: Mario Carrillo --- mk/rte.sdkinstall.mk | 8 mk/rte.sdkroot.mk| 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk index d1ff160..df16f5c 100644 --- a/mk/rte.sdkinstall.mk +++ b/mk/rte.sdkinstall.mk @@ -73,13 +73,13 @@ endif # INSTALL_CONFIGS := $(patsubst $(RTE_SRCDIR)/config/defconfig_%,%,\ $(wildcard $(RTE_SRCDIR)/config/defconfig_$(T))) -INSTALL_TARGETS := $(addsuffix _install,\ +INSTALL_TARGETS := $(addsuffix _mbuild,\ $(filter-out %~,$(INSTALL_CONFIGS))) -.PHONY: install -install: $(INSTALL_TARGETS) +.PHONY: mbuild +mbuild: $(INSTALL_TARGETS) -%_install: +%_mbuild: @echo == Installing $* $(Q)if [ ! -f $(BUILD_DIR)/$*/.config ]; then \ $(MAKE) config T=$* O=$(BUILD_DIR)/$*; \ diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk index dd5f399..1b619b7 100644 --- a/mk/rte.sdkroot.mk +++ b/mk/rte.sdkroot.mk @@ -97,9 +97,9 @@ test fast_test ring_test mempool_test perf_test coverage: testall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@ -.PHONY: install install-headers install-bin install-lib install-mod \ +.PHONY: mbuild install-headers install-bin install-lib install-mod \ install-doc install-sdk install-fhs uninstall -install install-headers install-bin install-lib install-mod install-doc \ +mbuild install-headers install-bin install-lib install-mod install-doc \ install-sdk install-fhs uninstall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@ -- 2.6.3
[dpdk-dev] [PATCH v8 10/11] mk: Add new install rule
If "T" variable is defined, the installation process will have the current behaviour, else install rule will be called. Signed-off-by: Mario Carrillo --- mk/rte.sdkinstall.mk | 12 +++- mk/rte.sdkroot.mk| 4 ++-- 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk index df16f5c..5195442 100644 --- a/mk/rte.sdkinstall.mk +++ b/mk/rte.sdkinstall.mk @@ -40,7 +40,6 @@ endif # target name or a name containing jokers "*". Example: # x86_64-native-*-gcc ifndef T -T=* ifneq (,$(wildcard $(RTE_OUTPUT)/.config)) prefix ?= /usr/local exec_prefix ?= $(prefix) @@ -198,6 +197,17 @@ install-fhs: install-lib install-bin install-doc install-mod cp -rf $(RTE_SDK)/tools $(DESTDIR)/$(datadir); \ echo installing: $(RTE_SDK)/tools # +# if "T" var is defined, mbuild rule will be called, else +# install-fhs rule will be called. +# +.PHONY: install +install: +ifdef T +install: mbuild +else +install: install-fhs +endif +# # uninstall: remove all built sdk # UNINSTALL_TARGETS := $(addsuffix _uninstall,\ diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk index 1b619b7..2f8f64a 100644 --- a/mk/rte.sdkroot.mk +++ b/mk/rte.sdkroot.mk @@ -97,9 +97,9 @@ test fast_test ring_test mempool_test perf_test coverage: testall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@ -.PHONY: mbuild install-headers install-bin install-lib install-mod \ +.PHONY: mbuild install install-headers install-bin install-lib install-mod \ install-doc install-sdk install-fhs uninstall -mbuild install-headers install-bin install-lib install-mod install-doc \ +mbuild install install-headers install-bin install-lib install-mod install-doc \ install-sdk install-fhs uninstall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@ -- 2.6.3
[dpdk-dev] [PATCH v8 11/11] doc: Add information about new installation rules
Information about variables and rules behaviour is added to documentation. Signed-off-by: Mario Carrillo --- doc/build-sdk-quick.txt | 23 - doc/guides/freebsd_gsg/build_dpdk.rst | 62 +++ doc/guides/linux_gsg/build_dpdk.rst | 62 +++ 3 files changed, 146 insertions(+), 1 deletion(-) diff --git a/doc/build-sdk-quick.txt b/doc/build-sdk-quick.txt index bf18b48..89ddcac 100644 --- a/doc/build-sdk-quick.txt +++ b/doc/build-sdk-quick.txt @@ -5,10 +5,19 @@ Build commands all same as build (default rule) buildbuild in a configured directory cleanremove files but keep configuration - install build many targets (wildcard allowed) and install in DESTDIR + install if T is defined, build a target and install in DESTDIR else call install-fhs target uninstallremove all installed targets examples build examples for given targets (T=) examples_clean clean examples for given targets (T=) +Install commands + install if T is defined, build a target and install in DESTDIR else call install-fhs target + install-headers install headers files + install-bin install app files a dpdk tools + install-lib install libraries + install-doc install documentation + install-mod install modules + install-sdk install headers, makefiles, scripts, examples, tools and config files + install-fhs install libraries, modules, app files, tools and documentation Build variables EXTRA_CPPFLAGS preprocessor options EXTRA_CFLAGS compiler options @@ -23,3 +32,15 @@ Build variables T target template (install default: *) - used with config or install format: templates in config/defconfig_* +Install variables + prefix /usr/local by default it can be overridden + exec_prefix $(prefix) + bindir $(exec_prefix)/bin by default it can be overridden + includedir $(prefix)/include by default it can be overridden + libdir $(exec_prefix)/lib by default it can be overridden + docdir $(datarootdir)/share/doc/dpdk by default it can be overridden + sdkdir $(datadir) + datadir $(datarootdir)/dpdk + datarootdir $(prefix)/share + kerneldir /lib/modules/$(uname -r)/extra/drivers/dpdk is for linux and + /boot/modules for BSD by default, they can be overridden diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst b/doc/guides/freebsd_gsg/build_dpdk.rst index 8eff599..e5162fc 100644 --- a/doc/guides/freebsd_gsg/build_dpdk.rst +++ b/doc/guides/freebsd_gsg/build_dpdk.rst @@ -136,6 +136,68 @@ The DPDK is composed of several directories: * config, tools, scripts, mk: Framework-related makefiles, scripts and configuration + +Build and install DPDK using a file hierarchy +- + +It is possible to configure, build and install specific groups of DPDK files +into a file hierarchy using the following install commands and variables: + +.. code-block:: console + + make config T= + make + make + +* ``install`` + + If ``T`` is not defined make will call ``install-fhs``. + +* ``install-headers`` + + Install headers files into ``includedir`` which is defined as + ``$(prefix)/include/dpdk``. + +* ``install-bin`` + + Install app files and dpdk tools into ``bindir`` which is defined as + ``$(exec_prefix)/bin``. + +* ``install-lib`` + + Install libraries into ``libdir`` which is defined as + ``$(exec_prefix)/lib``. + +* ``install-doc`` + + Install documentation into ``docdir`` which is defined as + ``$(datarootdir)/doc/dpdk``. + +* ``install-mod`` + + Install modules into ``kerneldir``. If ``RTE_EXEC_ENV`` is ``linuxapp`` then + ``kerneldir`` is ``/lib/modules/$(uname -r)/extra/drivers/dpdk`` otherwise + ``/boot/modules``. + +* ``install-sdk`` + + Install headers, makefiles, scripts, examples and config files into + ``sdkdir`` which is defined as ``$(datarootdir)/dpdk``. + +* ``install-fhs`` + + Install libraries, modules, app files, tools and documentation. + +The following defaults apply:: + + prefix=/usr/local + exec_prefix=$(prefix) + datarootdir=$(prefix)/share + +All path variables can be overridden and all targets can use the ``DESTDIR`` +variable. + + Installation of the DPDK Target Environments diff --git a/doc/guides/linux_gsg/build_dpdk.rst b/doc/guides/linux_gsg/build_dpdk.rst index 2680e66..7f3ab9d 100644 --- a/doc/guides/linux_gsg/build_dpdk.rst +++ b/doc/guides/linux_gsg/build_dpdk.rst @@ -152,6 +152,68 @@ The user may also make modifications to the compile-time DPDK configuration by e In a
[dpdk-dev] 2.3 Roadmap
On Tue, Dec 01, 2015 at 01:57:39PM +, Bruce Richardson wrote: > Hi Matthew, > > Couple of follow-up questions on this: > * do you need the exact same number of bits in both implementations? If we > support > 21 bits of data in IPv6 and 24 in IPv4 is that an issue compared to supporting > 21 bits just in both for compatibility. > * related to this - how much data are you looking to store in the tables? > > Thanks, > /Bruce Let me provide some more detailed high level examples of some security use cases so we could consider what makes sense. 1) Spamhaus provides a list of approximately 800 CIDR blocks which are so bad that they recommend null-routing them as widely as possible: https://www.spamhaus.org/drop/ https://www.spamhaus.org/drop/drop.txt https://www.spamhaus.org/drop/edrop.txt In the old implementation I couldn't even fit all of those, and doing something like this seems to be a must-have feature for security. 2) Team Cymru provides lists of Bogons for IPv4 and IPv6. In IPv4, there are 3600 bogon CIDR blocks because many things are in-use. But the IPv6 table has 65000 CIDR blocks, because it is larger, newer, and more sparse. http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt http://www.team-cymru.org/Services/Bogons/fullbogons-ipv6.txt Being able to monitor these would be another must-have for security and is quite popular for core routing from what I have heard. 3) At any given time, through various methods, I am aware of around 350,000 to 2.5 million recent bad IP addresses. Technically single entries could be matched using rte_hash. But it is quite common in the security world, to look at the number of bad IPs in a class C, and then flag the entire subnet as suspect if more than a few bad IPs are present there. Some support for some level of this is a must-have for security and firewall use cases. 4) Of course, it goes without saying that fitting the contents of the entire Internet BGP prefix list for IPv4 and IPv6 is a must-have for core routing although less needed for security. I am not an expert in this. Some very basic statistics I located with a quick search suggest one needs about 600,000 prefixes (presumably for IPv4). It would help if some router experts could clarify it and help me know what the story is for IPv6. http://www.cidr-report.org/as2.0/#General_Status 5) Considering all of the above, it seems like 22 or 23 unsigned lookup bits are required (4194304 or 8388608 entries) if you want comprehensive bad IP detection. And probably 21 unsigned bits for basic security support. But that would not necessarily leave a whole lot of headroom depending on the details. Matthew.
[dpdk-dev] [PATCH] bnx2x: tx_start_bd->vlan_or_ethertype is le16
> >Anyone to review please? > >2015-11-03 12:26, Chas Williams: >> Signed-off-by: Chas Williams <3chas3 at gmail.com> >> --- >> drivers/net/bnx2x/bnx2x.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c >> index fed7a06..76444eb 100644 >> --- a/drivers/net/bnx2x/bnx2x.c >> +++ b/drivers/net/bnx2x/bnx2x.c >> @@ -2169,7 +2169,8 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, >>struct rte_mbuf **m_head, int m_p >> struct ether_hdr *eh >> = rte_pktmbuf_mtod(m0, struct ether_hdr *); >> >> -tx_start_bd->vlan_or_ethertype = eh->ether_type; >> +tx_start_bd->vlan_or_ethertype >> += >> rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type)); >> } >> } > > Acked-by: Harish Patil Minor question - any specific reason to use rte_be_to_cpu_16() on ether_type alone before converting from native order to le16? Thanks, Harish This message and any attached documents contain information from the sending company or its parent company(s), subsidiaries, divisions or branch offices that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
[dpdk-dev] [PATCH] bnx2x: tx_start_bd->vlan_or_ethertype is le16
On Tue, 1 Dec 2015 21:53:59 + Harish Patil wrote: > > > >Anyone to review please? > > > >2015-11-03 12:26, Chas Williams: > >> Signed-off-by: Chas Williams <3chas3 at gmail.com> > >> --- > >> drivers/net/bnx2x/bnx2x.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c > >> index fed7a06..76444eb 100644 > >> --- a/drivers/net/bnx2x/bnx2x.c > >> +++ b/drivers/net/bnx2x/bnx2x.c > >> @@ -2169,7 +2169,8 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, > >>struct rte_mbuf **m_head, int m_p > >> struct ether_hdr *eh > >> = rte_pktmbuf_mtod(m0, struct ether_hdr > >> *); > >> > >> -tx_start_bd->vlan_or_ethertype = > >> eh->ether_type; > >> +tx_start_bd->vlan_or_ethertype > >> += > >> rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type)); > >> } > >> } > > > > > > Acked-by: Harish Patil > > > Minor question - any specific reason to use rte_be_to_cpu_16() on > ether_type alone before converting from native order to le16? ether_type is in network byte order (big endian) and hardware wants little endian. On x86 the second step is a nop.
[dpdk-dev] [PATCH] bnx2x: tx_start_bd->vlan_or_ethertype is le16
> >On Tue, 1 Dec 2015 21:53:59 + >Harish Patil wrote: > >> > >> >Anyone to review please? >> > >> >2015-11-03 12:26, Chas Williams: >> >> Signed-off-by: Chas Williams <3chas3 at gmail.com> >> >> --- >> >> drivers/net/bnx2x/bnx2x.c | 3 ++- >> >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c >> >> index fed7a06..76444eb 100644 >> >> --- a/drivers/net/bnx2x/bnx2x.c >> >> +++ b/drivers/net/bnx2x/bnx2x.c >> >> @@ -2169,7 +2169,8 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, >> >>struct rte_mbuf **m_head, int m_p >> >> struct ether_hdr *eh >> >> = rte_pktmbuf_mtod(m0, struct >>ether_hdr *); >> >> >> >> -tx_start_bd->vlan_or_ethertype = >>eh->ether_type; >> >> +tx_start_bd->vlan_or_ethertype >> >> += >>rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type)); >> >> } >> >> } >> > >> > >> >> Acked-by: Harish Patil >> >> >> Minor question - any specific reason to use rte_be_to_cpu_16() on >> ether_type alone before converting from native order to le16? > >ether_type is in network byte order (big endian) >and hardware wants little endian. On x86 the second step is a nop. > Thanks. Yes the question was for second step, second step would be a no-op on x86 - thanks for clarifying. This message and any attached documents contain information from the sending company or its parent company(s), subsidiaries, divisions or branch offices that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
[dpdk-dev] [PATCH] bnx2x: tx_start_bd->vlan_or_ethertype is le16
On Wed, 2015-12-02 at 00:34 +0100, Thomas Monjalon wrote: > 2015-12-01 14:37, Stephen Hemminger: > > Harish Patil wrote: > > > >2015-11-03 12:26, Chas Williams: > > > >> --- a/drivers/net/bnx2x/bnx2x.c > > > >> +++ b/drivers/net/bnx2x/bnx2x.c > > > >> -tx_start_bd->vlan_or_ethertype = > > > >> eh->ether_type; > > > >> +tx_start_bd->vlan_or_ethertype > > > >> += > > > >> rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type)); > > > > > > Minor question - any specific reason to use rte_be_to_cpu_16() on > > > ether_type alone before converting from native order to le16? > > > > ether_type is in network byte order (big endian) > > and hardware wants little endian. On x86 the second step is a nop. > > Doesn't it deserve a macro rte_ntole16()? > It may be in lib/librte_eal/common/include/generic/rte_byteorder.h. I looked I didn't see anything. This value, according to the linux driver, wants to be little endian regardless of the host endian.
[dpdk-dev] 2.3 Roadmap
On Wed, Dec 02, 2015 at 01:38:07AM +, Wiles, Keith wrote: > In Pktgen I used tap interface to wireshark and that worked very nicely the > only problem is it was slow :-( > > Having a tap PMD would be nice to be able to remove that code from Pktgen. All these approaches we discussed so far have a serious architectural issue. The entire point of BPF / libpcap was to prevent crossing unnecessary system boundaries with an arbitrarily, unsustainably large volume of unfiltered packets which will be tossed out anyways thereafter as they are irrelevant to a particular debugging objective. In the past it was the kernel -> user boundary. In our case it is the Data Plane -> Management Plane boundary. If we don't use something similar to libpcap offline mode (which I am using presently in my code) or preferably the user-space bpfjit (which I am working up to using eventually), it's going to be more or less impossible for this to work properly and not blow stuff up with anything close to wirespeed traffic going through the links being monitored. Especially with 10, 40, 100, ad nauseam, gigabit links. With the classic BPF / libpcap, it's absolutely possible to get it to work, without causing a big performance problem, or causing a huge packet dump meltdown, or any other issues in the process. We need to find a way to achieve the same objective in our new environment as well. One possible option, if some kernel guys could assist with figuring out the trick, would be if we could capture the BPF ioctl / syscall / whatever it secretly does on the TAP or KNI interface, when it passes the capture filter to the kernel, and steal the filter for use in pcap offline or userspace bpfjit inside of DPDK. Then supply only the packets meeting the filter back onto said interface. Matthew.
[dpdk-dev] [PATCH 0/3] replace bzero with memset
The DPDK is mostly consistent about using the POSIX standard memset instead of bzero; but there seem to be some leftover BSD hold outs. Stephen Hemminger (3): test-pmd: use memset not bzero xen-virt: use memset not bzero qat: use memset instead of bzero app/test-pmd/testpmd.c| 4 ++-- drivers/net/xenvirt/rte_eth_xenvirt.c | 3 ++- examples/dpdk_qat/crypto.c| 8 3 files changed, 8 insertions(+), 7 deletions(-) -- 2.1.4
[dpdk-dev] [PATCH 1/3] test-pmd: use memset not bzero
The standard for DPDK is to use memset() not bzero which
is a leftover BSD-ism.
Signed-off-by: Stephen Hemminger
---
app/test-pmd/testpmd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 093952f..98ae46d 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1512,7 +1512,7 @@ attach_port(char *identifier)
nb_ports = rte_eth_dev_count();
/* set_default_fwd_ports_config(); */
- bzero(fwd_ports_ids, sizeof(fwd_ports_ids));
+ memset(fwd_ports_ids, 0, sizeof(fwd_ports_ids));
i = 0;
FOREACH_PORT(j, ports) {
fwd_ports_ids[i] = j;
@@ -1547,7 +1547,7 @@ detach_port(uint8_t port_id)
nb_ports = rte_eth_dev_count();
/* set_default_fwd_ports_config(); */
- bzero(fwd_ports_ids, sizeof(fwd_ports_ids));
+ memset(fwd_ports_ids, 0, sizeof(fwd_ports_ids));
i = 0;
FOREACH_PORT(pi, ports) {
fwd_ports_ids[i] = pi;
--
2.1.4
[dpdk-dev] [PATCH 2/3] xen-virt: use memset not bzero
Signed-off-by: Stephen Hemminger --- drivers/net/xenvirt/rte_eth_xenvirt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/xenvirt/rte_eth_xenvirt.c b/drivers/net/xenvirt/rte_eth_xenvirt.c index e83c08c..3353bcb 100644 --- a/drivers/net/xenvirt/rte_eth_xenvirt.c +++ b/drivers/net/xenvirt/rte_eth_xenvirt.c @@ -640,7 +640,8 @@ eth_dev_xenvirt_create(const char *name, const char *params, struct pmd_internals *internals = NULL; struct rte_eth_dev *eth_dev = NULL; struct xenvirt_dict dict; - bzero(&dict, sizeof(struct xenvirt_dict)); + + memset(&dict, 0, sizeof(struct xenvirt_dict)); RTE_LOG(INFO, PMD, "Creating virtio rings backed ethdev on numa socket %u\n", numa_node); -- 2.1.4
[dpdk-dev] [PATCH 3/3] qat: use memset instead of bzero
Signed-off-by: Stephen Hemminger
---
examples/dpdk_qat/crypto.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/examples/dpdk_qat/crypto.c b/examples/dpdk_qat/crypto.c
index c03ea78..8954bf8 100644
--- a/examples/dpdk_qat/crypto.c
+++ b/examples/dpdk_qat/crypto.c
@@ -307,7 +307,7 @@ getCoreAffinity(Cpa32U *coreAffinity, const
CpaInstanceHandle instanceHandle)
Cpa16U i = 0;
CpaStatus status = CPA_STATUS_SUCCESS;
- bzero(&info, sizeof(CpaInstanceInfo2));
+ memset(&info, 0, sizeof(CpaInstanceInfo2));
status = cpaCyInstanceGetInfo2(instanceHandle, &info);
if (CPA_STATUS_SUCCESS != status) {
@@ -380,7 +380,7 @@ initCySymSession(const int pkt_cipher_alg,
CpaBoolean isCrypto = CPA_TRUE, isHmac = CPA_TRUE;
CpaCySymSessionSetupData sessionSetupData;
- bzero(&sessionSetupData, sizeof(CpaCySymSessionSetupData));
+ memset(&sessionSetupData, 0, sizeof(CpaCySymSessionSetupData));
/* Assumption: key length is set to each algorithm's max length */
switch (pkt_cipher_alg) {
@@ -781,7 +781,7 @@ crypto_encrypt(struct rte_mbuf *rte_buff, enum cipher_alg
c, enum hash_alg h)
lcore_id = rte_lcore_id();
- bzero(opData, sizeof(CpaCySymDpOpData));
+ memset(opData, 0, sizeof(CpaCySymDpOpData));
opData->srcBuffer = opData->dstBuffer =
PACKET_DATA_START_PHYS(rte_buff);
opData->srcBufferLen = opData->dstBufferLen = rte_buff->data_len;
@@ -856,7 +856,7 @@ crypto_decrypt(struct rte_mbuf *rte_buff, enum cipher_alg
c, enum hash_alg h)
lcore_id = rte_lcore_id();
- bzero(opData, sizeof(CpaCySymDpOpData));
+ memset(opData, 0, sizeof(CpaCySymDpOpData));
opData->dstBuffer = opData->srcBuffer =
PACKET_DATA_START_PHYS(rte_buff);
opData->dstBufferLen = opData->srcBufferLen = rte_buff->data_len;
--
2.1.4
[dpdk-dev] [PATCH 0/2] fix missing dependencies
Fix some issues found when doing parallel builds Stephen Hemminger (2): cmdline_test: add missing dependencies bonding: add depencency on cmdline library app/cmdline_test/Makefile| 3 +++ drivers/net/bonding/Makefile | 1 + 2 files changed, 4 insertions(+) -- 2.1.4
[dpdk-dev] [PATCH 1/2] cmdline_test: add missing dependencies
The cmdline test is missing a necessary dependency on other components. This caused a build failure when doing parallel builds. Signed-off-by: Stephen Hemminger --- app/cmdline_test/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/app/cmdline_test/Makefile b/app/cmdline_test/Makefile index e9eafd2..c6169f5 100644 --- a/app/cmdline_test/Makefile +++ b/app/cmdline_test/Makefile @@ -47,6 +47,9 @@ SRCS-y += commands.c CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +# this application needs libraries first +DEPDIRS-y += lib drivers + include $(RTE_SDK)/mk/rte.app.mk endif -- 2.1.4
[dpdk-dev] [PATCH 2/2] bonding: add depencency on cmdline library
Parallel build of bonding driver can fail because of missing dependency. Signed-off-by: Stephen Hemminger --- drivers/net/bonding/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/bonding/Makefile b/drivers/net/bonding/Makefile index dee0875..10c794c 100644 --- a/drivers/net/bonding/Makefile +++ b/drivers/net/bonding/Makefile @@ -63,5 +63,6 @@ DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_mbuf DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_ether DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_eal DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_kvargs +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_cmdline include $(RTE_SDK)/mk/rte.lib.mk -- 2.1.4
[dpdk-dev] [PATCH] add README
This project is missing a proper README which is used in other projects and some git visualization services. Only a starting point, please feel free to edit. To keep the file short and current, I avoided putting any specific information about features and versions. Signed-off-by: Stephen Hemminger --- README | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 README diff --git a/README b/README new file mode 100644 index 000..29ba0e0 --- /dev/null +++ b/README @@ -0,0 +1,11 @@ +DPDK is a set of libraries and drivers for fast packet processing. +It supports many processor architectures and both FreeBSD and Linux. + +The DPDK uses the Open Source BSD license for the core libraries and +drivers. The kernel components are GPLv2 licensed. + +Please check the doc directory for release notes, +API documentation, and sample application information. + +For questions and usage discussions, subscribe to: users at dpdk.org +Report bugs and issues to the development mailing list: dev at dpdk.org -- 2.1.4
