[dpdk-dev] [PATCH v1 0/3] TAP RSS eBPF cover letter
The patches of TAP RSS eBPF follow the RFC on this issue https://dpdk.org/dev/patchwork/patch/31781/ Pascal Mazon (1): net/tap: add BPF sections for TAP device This commit introduces BPF program (tap_bpf_program.c) with different sections which should be loaded to the kernel in BPF architecture format. BPF code compilation is not part of dpdk compilation. This commit also adds a skeleton for the RAP RSS implementation Ophir Munk (2): net/tap: add eBPF instructions == This commit adds eBPF machine instructions as part of dkdk compilation in the format of C arrays. This approach is currently under review with regard to: - licensing - Ability to update a BPF program and download new machine code net/tap: add eBPF classifiers map and actions = This commit builds and sends netlink messages to the kernel that include BPF classifiers and actions. When using BPF system call to load code to the kernel a license name must be specified. The license name is currently set to "Dual BSD/GPL". Please note licensing in general is under review and is not adderessed in this patch. doc/guides/prog_guide/rte_flow_tap.rst | 962 ++ drivers/net/tap/Makefile |7 +- drivers/net/tap/rte_eth_tap.h |9 +- drivers/net/tap/tap_bpf_insns.c| 5460 drivers/net/tap/tap_bpf_program.c | 321 ++ drivers/net/tap/tap_bpf_shared.h | 56 + drivers/net/tap/tap_flow.c | 613 +++- 7 files changed, 7323 insertions(+), 105 deletions(-) create mode 100644 doc/guides/prog_guide/rte_flow_tap.rst create mode 100644 drivers/net/tap/tap_bpf_insns.c create mode 100644 drivers/net/tap/tap_bpf_program.c create mode 100644 drivers/net/tap/tap_bpf_shared.h -- 2.7.4
[dpdk-dev] [PATCH v1 3/3] net/tap: add eBPF classifiers map and actions
Add TC BPF classifier for each TAP queue. Based on this classifier packets
marked with RSS queues will be directed to the matched queue using
TC "skbedit" action. This step is done once at startup
Add RSS BPF map entry for each new RSS rule. The BPF map entry includes
the RSS queues
Add TC BPF actions for each new RSS rule
- Calculate RSS hash based on L2 src, L2 dest, L3 src, L3 dst and L4 src.
- Write the selected RSS queue into skb control block based on the RSS hash
(i.e. marking the packet) and set the next step as reclassify.
Signed-off-by: Ophir Munk
---
drivers/net/tap/rte_eth_tap.h | 2 +
drivers/net/tap/tap_bpf_insns.c | 55 --
drivers/net/tap/tap_bpf_program.c | 14 +-
drivers/net/tap/tap_bpf_shared.h | 18 +-
drivers/net/tap/tap_flow.c| 402 +++---
5 files changed, 404 insertions(+), 87 deletions(-)
diff --git a/drivers/net/tap/rte_eth_tap.h b/drivers/net/tap/rte_eth_tap.h
index 01ac153..c185473 100644
--- a/drivers/net/tap/rte_eth_tap.h
+++ b/drivers/net/tap/rte_eth_tap.h
@@ -94,6 +94,8 @@ struct pmd_internals {
int flower_vlan_support; /* 1 if kernel supports, else 0 */
int rss_enabled; /* 1 if RSS is enabled, else 0 */
/* implicit rules set when RSS is enabled */
+ int map_fd; /* BPF RSS map fd */
+ int bpf_fd[RTE_PMD_TAP_MAX_QUEUES];/* List of bpf fds per queue */
LIST_HEAD(tap_rss_flows, rte_flow) rss_flows;
LIST_HEAD(tap_flows, rte_flow) flows;/* rte_flow rules */
/* implicit rte_flow rules set when a remote device is active */
diff --git a/drivers/net/tap/tap_bpf_insns.c b/drivers/net/tap/tap_bpf_insns.c
index 951d037..707dce8 100644
--- a/drivers/net/tap/tap_bpf_insns.c
+++ b/drivers/net/tap/tap_bpf_insns.c
@@ -134,7 +134,7 @@ int bpf_load_cls_q_insns(__u32 queue_idx)
return bpf_load(BPF_PROG_TYPE_SCHED_ACT,
(struct bpf_insn *)cls_q_insns,
CLS_Q_INSNS_CNT,
- "GPL", 0);
+ "Dual BSD/GPL", 0);
}
/*
@@ -174,7 +174,7 @@ int bpf_load_tailing_insns(void)
return bpf_load(BPF_PROG_TYPE_SCHED_ACT,
(struct bpf_insn *)tailing_insns,
TAILING_INSNS_CNT,
- "GPL", 0);
+ "Dual BSD/GPL", 0);
}
/*
@@ -220,7 +220,7 @@ int bpf_load_hash_appending_insns(void)
return bpf_load(BPF_PROG_TYPE_SCHED_ACT,
(struct bpf_insn *)hash_appending_insns,
HASH_APPENDING_INSNS_CNT,
- "GPL", 0);
+ "Dual BSD/GPL", 0);
}
/*
@@ -290,14 +290,14 @@ static struct bpf_insn queue_setting_insns[] = {
* @return
* -1 if the BPF program couldn't be loaded. An fd (int) otherwise.
*/
-int bpf_load_queue_setting_insns(__u32 queue_idx)
+int bpf_load_queue_setting_insns(__u32 key_idx)
{
- queue_setting_insns[1].imm = queue_idx;
+ queue_setting_insns[1].imm = key_idx;
return bpf_load(BPF_PROG_TYPE_SCHED_ACT,
(struct bpf_insn *)queue_setting_insns,
QUEUE_SETTING_INSNS_CNT,
- "GPL", 0);
+ "Dual BSD/GPL", 0);
}
/*
@@ -918,7 +918,7 @@ int bpf_load_l2_src_hash_insns(__u32 key_idx)
return bpf_load(BPF_PROG_TYPE_SCHED_ACT,
(struct bpf_insn *)l2_src_hash_insns,
L2_SRC_HASH_INSNS_CNT,
- "GPL", 0);
+ "Dual BSD/GPL", 0);
}
/*
@@ -1525,7 +1525,7 @@ int bpf_load_l2_dst_hash_insns(__u32 key_idx)
return bpf_load(BPF_PROG_TYPE_SCHED_ACT,
(struct bpf_insn *)l2_dst_hash_insns,
L2_DST_HASH_INSNS_CNT,
- "GPL", 0);
+ "Dual BSD/GPL", 0);
}
/*
@@ -3285,7 +3285,7 @@ int bpf_load_l3_dst_hash_insns(__u32 key_idx)
return bpf_load(BPF_PROG_TYPE_SCHED_ACT,
(struct bpf_insn *)l3_dst_hash_insns,
L3_DST_HASH_INSNS_CNT,
- "GPL", 0);
+ "Dual BSD/GPL", 0);
}
/*
@@ -5034,7 +5034,7 @@ int bpf_load_l3_src_hash_insns(__u32 key_idx)
return bpf_load(BPF_PROG_TYPE_SCHED_ACT,
(struct bpf_insn *)l3_src_hash_insns,
L3_SRC_HASH_INSNS_CNT,
- "GPL", 0);
+ "Dual BSD/GPL", 0);
}
/*
@@ -5376,7 +5376,7 @@ int bpf_load_l4_src_hash_insns(__u32 key_idx)
return bpf_load(BPF_PROG_TYPE_SCHED_ACT,
(struct bpf_insn *)l4_src_hash_insns,
L4_SRC_HASH_INSNS_CNT,
- "GPL", 0);
+ "Dual BSD/GPL", 0);
}
#ifndef __NR_bpf
@@ -5425,3 +5425,36 @@ int bpf_load(enum bpf_prog_type type,
return sys_bpf(BPF_PROG_LOAD, &attr, sizeof(attr));
}
+
+
+int bpf_map_create(enum bpf_map_type map_type,
+ unsigned int key_size,
+ unsigned int value_size,
+ unsigned int max_entries)
+{
+ union bpf_attr attr;
+
+ bzero(&attr, sizeof(a
[dpdk-dev] [PATCH v1 1/3] net/tap: add BPF sections for TAP device
From: Pascal Mazon The DPDK traffic classifier is the rte_flow API and the tap PMD must support it including RSS queue mapping. An example usage for this requirement is failsafe transparent switching from a PCI device to TAP device while keep redirecting packets to the same RSS queues on both devices. This commit uses eBPF classification and actions in order to support TAP RSS. eBPF requires Linux version 3.19. eBPF is effective only when running with an appropriate kernel version. In case kernel headers do not include eBPF definitions a warning will be issued during compilation time and TAP RSS will not be supported. Signed-off-by: Ophir Munk --- doc/guides/prog_guide/rte_flow_tap.rst | 962 + drivers/net/tap/Makefile | 6 +- drivers/net/tap/rte_eth_tap.h | 7 +- drivers/net/tap/tap_flow.c | 336 4 files changed, 1207 insertions(+), 104 deletions(-) create mode 100644 doc/guides/prog_guide/rte_flow_tap.rst diff --git a/doc/guides/prog_guide/rte_flow_tap.rst b/doc/guides/prog_guide/rte_flow_tap.rst new file mode 100644 index 000..04ddda6 --- /dev/null +++ b/doc/guides/prog_guide/rte_flow_tap.rst @@ -0,0 +1,962 @@ += +Flow API support in TAP PMD, using TC += + +.. contents:: +.. sectnum:: + +.. footer:: + + v0.8 - page ###Page### + +.. raw:: pdf + + PageBreak + +Rationale += + +For this project, the tap PMD has to receive selected traffic from a different +netdevice (refer to *VM migration with Microsoft Hyper-V and Mellanox +ConnectX-3* document) and only cover the same set of rules as supported by the +mlx4 PMD. + +The DPDK traffic classifier is the rte_flow API, and the tap PMD must therefore +implement it. For that, TC was chosen for several reasons: + +- it happens very early in the kernel stack for ingress (faster than netfilter). +- it supports dropping packets given a specific flow. +- it supports redirecting packets to a different netdevice. +- it has a "flower" classifier type that meets mostly the pattern items in + rte_flow. +- it can be configured through a netlink socket, without an external tool. + +Modes of operation +== + +There should be two modes of operation for the tap PMD regarding rte_flow: +*local* and *remote*. Only one mode can be in use at a time for a specific tap +interface. + +The *local* mode would be the default one, if no specific parameter is specified +in the command line. To start the application with tap in *remote* mode, set the +``remote`` tap parameter to the interface you want to redirect packets from, +e.g.:: + + testpmd -n 4 -c 0xf -m 1024 --vdev=net_tap,iface=tap0,remote=eth3 -- \ + -i --burst=64 --coremask=0x2 + +*Local* mode + + +In *local* mode, flow rules would be applied as-is, on the tap netdevice itself +(e.g.: ``tap0``). + +The typical use-case is having a linux program (e.g. a webserver) communicating +with the DPDK app through the tap netdevice:: + + +-+ + |DPDK application | + +-+ + | ^ + | rte_flow rte_flow | + v egress ingress | + +-+ + |Tap PMD | + +-+ + | ^ + | TC TC | + v ingress egress | + +-+ +-+ + | |<-| | + | Tap netdevice (tap0) | | Linux app (webserver) | + | |->| | + +-+ +-+ + +.. raw:: pdf + + PageBreak + +*Remote* mode +- + +In *remote* mode, flow rules would be applied on the tap netdevice (e.g.: +``tap0``), and use a similar match to redirect specific packets from another +netdevice (e.g.: ``eth3``, a NetVSC netdevice in our project scenario):: + + +-+ + |DPDK application | + +-+ + | ^ + | rte_flow rte_flow | + v egress ingress | + +-+ + |Tap PMD | + +-+ + | ^ + | TC TC | + v ingress egress | + +-+ +-+ + | |<--redirection---\ | + | Tap netdevice (tap0) | | | | + | |->|-\ eth3 | | + +-+ +--||-+ + | TC TC ^ + | egress ingress | +
Re: [dpdk-dev] [PATCH] arch/arm: optimization for memcpy on AArch64
Hi Jerin,
> -Original Message-
> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> Sent: Friday, December 15, 2017 12:06
> To: Herbert Guan
> Cc: Jianbo Liu ; dev@dpdk.org
> Subject: Re: [PATCH] arch/arm: optimization for memcpy on AArch64
>
> -Original Message-
> > Date: Sun, 3 Dec 2017 12:37:30 +
> > From: Herbert Guan
> > To: Jerin Jacob
> > CC: Jianbo Liu , "dev@dpdk.org"
> > Subject: RE: [PATCH] arch/arm: optimization for memcpy on AArch64
> >
> > Jerin,
>
> Hi Herbert,
>
> >
> > Thanks a lot for your review and comments. Please find my comments
> below inline.
> >
> > Best regards,
> > Herbert
> >
> > > -Original Message-
> > > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> > > Sent: Wednesday, November 29, 2017 20:32
> > > To: Herbert Guan
> > > Cc: Jianbo Liu ; dev@dpdk.org
> > > Subject: Re: [PATCH] arch/arm: optimization for memcpy on AArch64
> > >
> > > -Original Message-
> > > > Date: Mon, 27 Nov 2017 15:49:45 +0800
> > > > From: Herbert Guan
> > > > To: jerin.ja...@caviumnetworks.com, jianbo@arm.com,
> dev@dpdk.org
> > > > CC: Herbert Guan
> > > > Subject: [PATCH] arch/arm: optimization for memcpy on AArch64
> > > > X-Mailer: git-send-email 1.8.3.1
> > > > +
> > > > +/**
> > > > + * Beginning of customization section
> > > > +**/
> > > > +#define ALIGNMENT_MASK 0x0F
> > > > +#ifndef RTE_ARCH_ARM64_MEMCPY_STRICT_ALIGN
> > > > +// Only src unalignment will be treaed as unaligned copy
> > >
> > > C++ style comments. It may generate check patch errors.
> >
> > I'll change it to use C style comment in the version 2.
> >
> > >
> > > > +#define IS_UNALIGNED_COPY(dst, src) ((uintptr_t)(dst) &
> > > > +ALIGNMENT_MASK) #else // Both dst and src unalignment will be
> treated
> > > > +as unaligned copy #define IS_UNALIGNED_COPY(dst, src) \
> > > > +(((uintptr_t)(dst) | (uintptr_t)(src)) & ALIGNMENT_MASK)
> > > #endif
> > > > +
> > > > +
> > > > +// If copy size is larger than threshold, memcpy() will be used.
> > > > +// Run "memcpy_perf_autotest" to determine the proper threshold.
> > > > +#define ALIGNED_THRESHOLD ((size_t)(0x))
> > > > +#define UNALIGNED_THRESHOLD ((size_t)(0x))
> > >
> > > Do you see any case where this threshold is useful.
> >
> > Yes, on some platforms, and/or with some glibc version, the glibc memcpy
> has better performance in larger size (e.g., >512, >4096...). So developers
> should run unit test to find the best threshold. The default value of
> 0x
> should be modified with evaluated values.
>
> OK
>
> >
> > >
> > > > +
> > > > +static inline void *__attribute__ ((__always_inline__))i
>
> use __rte_always_inline
Applied in V3 patch.
>
> > > > +rte_memcpy(void *restrict dst, const void *restrict src, size_t n)
> > > > +{
> > > > +if (n < 16) {
> > > > +rte_memcpy_lt16((uint8_t *)dst, (const uint8_t *)src, n);
> > > > +return dst;
> > > > +}
> > > > +if (n < 64) {
> > > > +rte_memcpy_ge16_lt64((uint8_t *)dst, (const uint8_t *)src,
> > > n);
> > > > +return dst;
> > > > +}
> > >
> > > Unfortunately we have 128B cache arm64 implementation too. Could you
> > > please take care that based on RTE_CACHE_LINE_SIZE
> > >
> >
> > Here the value of '64' is not the cache line size. But for the reason that
> prefetch itself will cost some cycles, it's not worthwhile to do prefetch for
> small size (e.g. < 64 bytes) copy. Per my test, prefetching for small size
> copy
> will actually lower the performance.
>
> But
> I think, '64' is a function of cache size. ie. Any reason why we haven't used
> rte_memcpy_ge16_lt128()/rte_memcpy_ge128 pair instead of
> rte_memcpy_ge16_lt64//rte_memcpy_ge64 pair?
> I think, if you can add one more conditional compilation to choose between
> rte_memcpy_ge16_lt128()/rte_memcpy_ge128 vs
> rte_memcpy_ge16_lt64//rte_memcpy_ge64,
> will address the all arm64 variants supported in current DPDK.
>
The logic for 128B cache is implemented as you've suggested, and has been added
in V3 patch.
> >
> > In the other hand, I can only find one 128B cache line aarch64 machine here.
> And it do exist some specific optimization for this machine. Not sure if
> it'll be
> beneficial for other 128B cache machines or not. I prefer not to put it in
> this
> patch but in a later standalone specific patch for 128B cache machines.
> >
> > > > +__builtin_prefetch(src, 0, 0); // rte_prefetch_non_temporal(src);
> > > > +__builtin_prefetch(dst, 1, 0); // * unchanged *
>
> # Why only once __builtin_prefetch used? Why not invoke in
> rte_memcpy_ge64 loop
> # Does it make sense to prefetch src + 64/128 * n
Prefetch is only necessary once at the beginning. CPU will do auto incremental
prefetch when the continuous memory access starts. It's not necessary to do
prefetch in the loop. In fact doing it in loop will actually break CPU's HW
prefetch and degrade the performance.
IMPORTANT NOTICE: The co
Re: [dpdk-dev] [PATCH] net/virtio: fix Rx and Tx handler selection for arm32
On Thu, Dec 14, 2017 at 03:32:13PM +0100, Olivier Matz wrote:
> From: Samuel Gauthier
>
> On arm32, we were always selecting the simple handler, but it is only
> available if neon is present.
>
> This is due to a typo in the name of the config option.
> CONFIG_RTE_ARCH_ARM is for Makefiles. One should use RTE_ARCH_ARM.
>
> Fixes: 2d7c37194ee4 ("net/virtio: add NEON based Rx handler")
> Cc: sta...@dpdk.org
Hi Olivier,
My comment isn't really related to this patch, but related
to the commit it fixes and some related commits from you.
The commit (2d7c37194ee4) specified by the fixline doesn't
really cause the problem described in the commit log:
"On arm32, we were always selecting the simple handler, ..."
Actually, it will cause the simple handler won't be chosen
on arm32. Below is the relevant part (use_simple_rxtx won't
get a chance to be updated to 1 on arm32):
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 0e369bd12..9ab441bc3 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -488,6 +488,9 @@ virtio_update_rxtx_handler(struct rte_eth_dev *dev,
#if defined RTE_ARCH_X86
if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SSE3))
use_simple_rxtx = 1;
+#elif defined RTE_ARCH_ARM64 || defined CONFIG_RTE_ARCH_ARM
+ if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON))
+ use_simple_rxtx = 1;
#endif
/* Use simple rx/tx func if single segment and no offloads */
if (use_simple_rxtx &&
It's the below commits (together with the above commit)
caused the simple handler will always be chosen on arm32:
4819eae8d94b ("net/virtio: rationalize setting of Rx/Tx handlers")
0964936308cd ("net/virtio: keep Rx handler whatever the Tx queue config")
For the above two commits, I think they have some other
problems. From my understanding, vector Rx function of
virtio PMD doesn't really follow the virtio spec. It
assumes the desc idx in the used ring will be written by
the backend in an expected order (i.e. the same order in
avail ring). So it even doesn't read the id field from
the used_elem to get the desc idx (but actually it should,
unless we change the virtio spec). It seems that simple
Tx function also has similar problem.
So IMO, we shouldn't choose the simple functions on all
platforms unless users enable them explicitly as we can't
guarantee they will work with all backends. So maybe the
problems can be fixed further? Any thoughts?
Best regards,
Tiwei Bie
>
> Signed-off-by: Samuel Gauthier
> ---
> drivers/net/virtio/virtio_ethdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index e0328f61d..c0ba83b06 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1784,7 +1784,7 @@ virtio_dev_configure(struct rte_eth_dev *dev)
> hw->use_simple_rx = 1;
> hw->use_simple_tx = 1;
>
> -#if defined RTE_ARCH_ARM64 || defined CONFIG_RTE_ARCH_ARM
> +#if defined RTE_ARCH_ARM64 || defined RTE_ARCH_ARM
> if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON)) {
> hw->use_simple_rx = 0;
> hw->use_simple_tx = 0;
> --
> 2.11.0
>
[dpdk-dev] [PATCH v3] arch/arm: optimization for memcpy on AArch64
This patch provides an option to do rte_memcpy() using 'restrict'
qualifier, which can induce GCC to do optimizations by using more
efficient instructions, providing some performance gain over memcpy()
on some AArch64 platforms/enviroments.
The memory copy performance differs between different AArch64
platforms. And a more recent glibc (e.g. 2.23 or later)
can provide a better memcpy() performance compared to old glibc
versions. It's always suggested to use a more recent glibc if
possible, from which the entire system can get benefit. If for some
reason an old glibc has to be used, this patch is provided for an
alternative.
This implementation can improve memory copy on some AArch64
platforms, when an old glibc (e.g. 2.19, 2.17...) is being used.
It is disabled by default and needs "RTE_ARCH_ARM64_MEMCPY"
defined to activate. It's not always proving better performance
than memcpy() so users need to run DPDK unit test
"memcpy_perf_autotest" and customize parameters in "customization
section" in rte_memcpy_64.h for best performance.
Compiler version will also impact the rte_memcpy() performance.
It's observed on some platforms and with the same code, GCC 7.2.0
compiled binary can provide better performance than GCC 4.8.5. It's
suggested to use GCC 5.4.0 or later.
Signed-off-by: Herbert Guan
---
config/common_armv8a_linuxapp | 6 +
.../common/include/arch/arm/rte_memcpy_64.h| 292 +
2 files changed, 298 insertions(+)
diff --git a/config/common_armv8a_linuxapp b/config/common_armv8a_linuxapp
index 6732d1e..8f0cbed 100644
--- a/config/common_armv8a_linuxapp
+++ b/config/common_armv8a_linuxapp
@@ -44,6 +44,12 @@ CONFIG_RTE_FORCE_INTRINSICS=y
# to address minimum DMA alignment across all arm64 implementations.
CONFIG_RTE_CACHE_LINE_SIZE=128
+# Accelarate rte_memcpy. Be sure to run unit test to determine the
+# best threshold in code. Refer to notes in source file
+# (lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h) for more
+# info.
+CONFIG_RTE_ARCH_ARM64_MEMCPY=n
+
CONFIG_RTE_LIBRTE_FM10K_PMD=n
CONFIG_RTE_LIBRTE_SFC_EFX_PMD=n
CONFIG_RTE_LIBRTE_AVP_PMD=n
diff --git a/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h
b/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h
index b80d8ba..1ea275d 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h
@@ -42,6 +42,296 @@
#include "generic/rte_memcpy.h"
+#ifdef RTE_ARCH_ARM64_MEMCPY
+#include
+#include
+
+/*
+ * The memory copy performance differs on different AArch64
micro-architectures.
+ * And the most recent glibc (e.g. 2.23 or later) can provide a better memcpy()
+ * performance compared to old glibc versions. It's always suggested to use a
+ * more recent glibc if possible, from which the entire system can get benefit.
+ *
+ * This implementation improves memory copy on some aarch64
micro-architectures,
+ * when an old glibc (e.g. 2.19, 2.17...) is being used. It is disabled by
+ * default and needs "RTE_ARCH_ARM64_MEMCPY" defined to activate. It's not
+ * always providing better performance than memcpy() so users need to run unit
+ * test "memcpy_perf_autotest" and customize parameters in customization
section
+ * below for best performance.
+ *
+ * Compiler version will also impact the rte_memcpy() performance. It's
observed
+ * on some platforms and with the same code, GCC 7.2.0 compiled binaries can
+ * provide better performance than GCC 4.8.5 compiled binaries.
+ */
+
+/**
+ * Beginning of customization section
+ **/
+#define ALIGNMENT_MASK 0x0F
+#ifndef RTE_ARCH_ARM64_MEMCPY_STRICT_ALIGN
+/* Only src unalignment will be treaed as unaligned copy */
+#define IS_UNALIGNED_COPY(dst, src) ((uintptr_t)(dst) & ALIGNMENT_MASK)
+#else
+/* Both dst and src unalignment will be treated as unaligned copy */
+#define IS_UNALIGNED_COPY(dst, src) \
+ (((uintptr_t)(dst) | (uintptr_t)(src)) & ALIGNMENT_MASK)
+#endif
+
+
+/*
+ * If copy size is larger than threshold, memcpy() will be used.
+ * Run "memcpy_perf_autotest" to determine the proper threshold.
+ */
+#define ALIGNED_THRESHOLD ((size_t)(0x))
+#define UNALIGNED_THRESHOLD ((size_t)(0x))
+
+/**
+ * End of customization section
+ **/
+#ifdef RTE_TOOLCHAIN_GCC
+#if (GCC_VERSION < 50400)
+#warning "The GCC version is quite old, which may result in sub-optimal \
+performance of the compiled code. It is suggested that at least GCC 5.4.0 \
+be used."
+#endif
+#endif
+
+static __rte_always_inline void
+rte_mov16(uint8_t *restrict dst, const uint8_t *restrict src)
+{
+ __uint128_t *restrict dst128 = (__uint128_t *restrict)dst;
+ const __uint128_t *restrict src128 = (const __uint128_t *restrict)src;
+ *dst128 = *src128;
+}
+
+static __rte_always_inline void
+rte_mov
Re: [dpdk-dev] [PATCH] net/i40e: i40e support mac loopback
Hi Yanglong
It seems your patch cannot be applied on my system. Please do a check on your
patch.
In addition, please make sure your local git repo was cloned from the right
sub-tree.
e.g. 'git clone http://dpdk.org/git/next/dpdk-next-net-intel'
Hi maintainers
I need your comments, ACK or NACK. Thanks!
Regards,
Helin
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yanglong Wu
> Sent: Monday, November 20, 2017 12:06 PM
> To: dev@dpdk.org
> Cc: Wu, Yanglong
> Subject: [dpdk-dev] [PATCH] net/i40e: i40e support mac loopback
>
> According to loopback mode, setup loopback link or not.
> If loopback link is setted, packets will be sent to rx_q from tx_q
> directly.Loopback mode can be used to support testing task.
>
> Signed-off-by: Yanglong Wu
> ---
> drivers/net/i40e/base/i40e_adminq_cmd.h | 1 +
> drivers/net/i40e/i40e_ethdev.c | 12 +++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h
> b/drivers/net/i40e/base/i40e_adminq_cmd.h
> index c36da2a32..8171f877b 100644
> --- a/drivers/net/i40e/base/i40e_adminq_cmd.h
> +++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
> @@ -2128,6 +2128,7 @@
> I40E_CHECK_CMD_LENGTH(i40e_aqc_an_advt_reg);
> /* Set Loopback mode (0x0618) */
> struct i40e_aqc_set_lb_mode {
> __le16 lb_mode;
> +#define I40E_AQ_LB_MODE_NONE 0x0
> #define I40E_AQ_LB_PHY_LOCAL 0x01
> #define I40E_AQ_LB_PHY_REMOTE0x02
> #define I40E_AQ_LB_MAC_LOCAL 0x04
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index f40c463aa..2e6aa9d0d 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -2048,6 +2048,17 @@ i40e_dev_start(struct rte_eth_dev *dev)
> }
> }
>
> + /* Enable mac loopback mode */
> + if (hw->mac.type == I40E_MAC_XL710 &&
> + (dev->data->dev_conf.lpbk_mode == I40E_AQ_LB_MODE_NONE ||
> + dev->data->dev_conf.lpbk_mode ==
> I40E_AQ_LB_PHY_LOCAL)) {
> + ret = i40e_aq_set_lb_modes(hw,
> +dev->data->dev_conf.lpbk_mode,
> NULL);
> + if (ret != I40E_SUCCESS) {
> + PMD_DRV_LOG(INFO, "fail to set loopback link");
> + goto err_up;
> + }
> + }
> +
> /* Apply link configure */
> if (dev->data->dev_conf.link_speeds & ~(ETH_LINK_SPEED_100M |
> ETH_LINK_SPEED_1G | ETH_LINK_SPEED_10G
> |
> --
> 2.11.0
Re: [dpdk-dev] [PATCH] arch/arm: optimization for memcpy on AArch64
-Original Message- > Date: Mon, 18 Dec 2017 02:51:19 + > From: Herbert Guan > To: Jerin Jacob > CC: Jianbo Liu , "dev@dpdk.org" > Subject: RE: [PATCH] arch/arm: optimization for memcpy on AArch64 > > Hi Jerin, Hi Herbert, > > > > > > Here the value of '64' is not the cache line size. But for the reason > > > that > > prefetch itself will cost some cycles, it's not worthwhile to do prefetch > > for > > small size (e.g. < 64 bytes) copy. Per my test, prefetching for small size > > copy > > will actually lower the performance. > > > > But > > I think, '64' is a function of cache size. ie. Any reason why we haven't > > used > > rte_memcpy_ge16_lt128()/rte_memcpy_ge128 pair instead of > > rte_memcpy_ge16_lt64//rte_memcpy_ge64 pair? > > I think, if you can add one more conditional compilation to choose between > > rte_memcpy_ge16_lt128()/rte_memcpy_ge128 vs > > rte_memcpy_ge16_lt64//rte_memcpy_ge64, > > will address the all arm64 variants supported in current DPDK. > > > > The logic for 128B cache is implemented as you've suggested, and has been > added in V3 patch. > > > > > > > In the other hand, I can only find one 128B cache line aarch64 machine > > > here. > > And it do exist some specific optimization for this machine. Not sure if > > it'll be > > beneficial for other 128B cache machines or not. I prefer not to put it in > > this > > patch but in a later standalone specific patch for 128B cache machines. > > > > > > > > +__builtin_prefetch(src, 0, 0); // rte_prefetch_non_temporal(src); > > > > > +__builtin_prefetch(dst, 1, 0); // * unchanged * > > > > # Why only once __builtin_prefetch used? Why not invoke in > > rte_memcpy_ge64 loop > > # Does it make sense to prefetch src + 64/128 * n > > Prefetch is only necessary once at the beginning. CPU will do auto > incremental prefetch when the continuous memory access starts. It's not > necessary to do prefetch in the loop. In fact doing it in loop will actually > break CPU's HW prefetch and degrade the performance. Yes. But, aarch64 specification does not mandate that all implementation should have HW prefetch mechanism(ie. it is IMPLEMENTATION DEFINED). I think, You have provided a good start for memcpy implementation and we can fine tune it _latter_ based different micro architecture. Your v3 looks good. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. Please remove such notice from public mailing list.
Re: [dpdk-dev] [PATCH 1/2] mempool: notify mempool area after mempool alloc
On Friday 15 December 2017 09:30 PM, Pavan Nikhilesh wrote: > Mempool creation needs to be completed first before notifying mempool to > register the mempool area. > > Signed-off-by: Pavan Nikhilesh > --- LGTM. Acked-by: Santosh Shukla
Re: [dpdk-dev] [PATCH 2/2] mempool/octeontx: clean up memory area registration
On Friday 15 December 2017 09:30 PM, Pavan Nikhilesh wrote: > Clean up dependency between alloc and memory area registration, this > removes the need for SLIST data structure and octeontx_pool_list. > > Signed-off-by: Pavan Nikhilesh > --- nits: s/clean up dependency/ clean up the dependency. Acked-by: Santosh Shukla
[dpdk-dev] [PATCH] net/i40e: fix FDIR input set conflict
The first FDIR rule for some PCTYPE will configure input set and
create flow, the following flows must use the same input set,
otherwise will cause input set conflict and fail to create flow.
But if creating the first rule after flow flush, input set should
be re-configured.
Fixes: 42044b69c67d ("net/i40e: support input set selection for FDIR")
c: sta...@dpdk.org
Signed-off-by: Beilei Xing
---
drivers/net/i40e/i40e_flow.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c
index 7e4936e..a9e7a0d 100644
--- a/drivers/net/i40e/i40e_flow.c
+++ b/drivers/net/i40e/i40e_flow.c
@@ -4406,6 +4406,7 @@ i40e_flow_flush_fdir_filter(struct i40e_pf *pf)
struct rte_eth_dev *dev = pf->adapter->eth_dev;
struct i40e_fdir_info *fdir_info = &pf->fdir;
struct i40e_fdir_filter *fdir_filter;
+ enum i40e_filter_pctype pctype;
struct rte_flow *flow;
void *temp;
int ret;
@@ -4427,6 +4428,10 @@ i40e_flow_flush_fdir_filter(struct i40e_pf *pf)
rte_free(flow);
}
}
+
+ for (pctype = I40E_FILTER_PCTYPE_NONF_IPV4_UDP;
+pctype <= I40E_FILTER_PCTYPE_L2_PAYLOAD; pctype++)
+ pf->fdir.inset_flag[pctype] = 0;
}
return ret;
--
2.5.5
Re: [dpdk-dev] [PATCH] net/i40e: i40e support mac loopback
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yanglong Wu
> Sent: Monday, November 20, 2017 12:06 PM
> To: dev@dpdk.org
> Cc: Wu, Yanglong
> Subject: [dpdk-dev] [PATCH] net/i40e: i40e support mac loopback
"i40e" in the title can be omitted.
>
> According to loopback mode, setup loopback link or not.
> If loopback link is setted, packets will be sent to rx_q from tx_q
> directly.Loopback mode can be used to support testing task.
>
> Signed-off-by: Yanglong Wu
> ---
> drivers/net/i40e/base/i40e_adminq_cmd.h | 1 +
> drivers/net/i40e/i40e_ethdev.c | 12 +++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h
> b/drivers/net/i40e/base/i40e_adminq_cmd.h
> index c36da2a32..8171f877b 100644
> --- a/drivers/net/i40e/base/i40e_adminq_cmd.h
> +++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
> @@ -2128,6 +2128,7 @@
> I40E_CHECK_CMD_LENGTH(i40e_aqc_an_advt_reg);
> /* Set Loopback mode (0x0618) */
> struct i40e_aqc_set_lb_mode {
> __le16 lb_mode;
> +#define I40E_AQ_LB_MODE_NONE 0x0
Don't define it in base code, can move it to i40e PMD.
> #define I40E_AQ_LB_PHY_LOCAL 0x01
> #define I40E_AQ_LB_PHY_REMOTE0x02
> #define I40E_AQ_LB_MAC_LOCAL 0x04
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index f40c463aa..2e6aa9d0d 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -2048,6 +2048,17 @@ i40e_dev_start(struct rte_eth_dev *dev)
> }
> }
>
> + /* Enable mac loopback mode */
> + if (hw->mac.type == I40E_MAC_XL710 &&
Only I40E_MAC_XL710 supports loopback mode?
> + (dev->data->dev_conf.lpbk_mode == I40E_AQ_LB_MODE_NONE
> ||
> + dev->data->dev_conf.lpbk_mode ==
> I40E_AQ_LB_PHY_LOCAL)) {
> + ret = i40e_aq_set_lb_modes(hw,
> +dev->data->dev_conf.lpbk_mode,
> NULL);
> + if (ret != I40E_SUCCESS) {
> + PMD_DRV_LOG(INFO, "fail to set loopback link");
Better to use 'ERR' to replace 'INFO'.
> + goto err_up;
> + }
> + }
> +
> /* Apply link configure */
> if (dev->data->dev_conf.link_speeds & ~(ETH_LINK_SPEED_100M |
> ETH_LINK_SPEED_1G |
> ETH_LINK_SPEED_10G |
> --
> 2.11.0
[dpdk-dev] [PATCH] kni: fix pci_enable_msix_range error handling
pci_enable_msix_range's return value has a different meaning than what
was previously returned by pci_enable_msix.
"It returns a negative errno if an error occurs. If it succeeds, it
returns the actual number of interrupts allocated and indicates the
successful configuration of MSI-X capability structure with new
allocated MSI-X interrupts."
The following commit introduced pci_enable_msix_range:
dpdk: 9fb3cd2c ("kni: fix ethtool build with kernel 4.11")
http://dpdk.org/dev/patchwork/patch/24076/
Signed-off-by: Andy Roulin
---
lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
index e0f427a..32ef3b9 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
@@ -1043,14 +1043,16 @@ static void igb_set_interrupt_capability(struct
igb_adapter *adapter, bool msix)
#ifdef HAVE_PCI_ENABLE_MSIX
err = pci_enable_msix(pdev,
adapter->msix_entries, numvecs);
+ if (err == 0)
+ break;
#else
err = pci_enable_msix_range(pdev,
adapter->msix_entries,
numvecs,
numvecs);
-#endif
- if (err == 0)
+ if (err < 0)
break;
+#endif
}
/* MSI-X failed, so fall through and try MSI */
dev_warn(pci_dev_to_dev(pdev), "Failed to initialize MSI-X
interrupts. "
--
2.1.4
Re: [dpdk-dev] [PATCH] net/virtio-user: specify MAC address for tap port
Hi Ning,
On Thu, Dec 14, 2017 at 07:38:14PM +0800, Ning Li wrote:
> When use virtio_user as exception path, we need to specify a MAC
> address for the tap port.
Is this a fix? Did you meet any issue? If so, please describe
the issue and add a fixline.
>
> Signed-off-by: Ning Li
> ---
> drivers/net/virtio/virtio_user/vhost_kernel.c | 3 ++-
> drivers/net/virtio/virtio_user/vhost_kernel_tap.c | 8
> drivers/net/virtio/virtio_user/vhost_kernel_tap.h | 12 +++-
> 3 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_user/vhost_kernel.c
> b/drivers/net/virtio/virtio_user/vhost_kernel.c
> index 68d28b1..dd24b6b 100644
> --- a/drivers/net/virtio/virtio_user/vhost_kernel.c
> +++ b/drivers/net/virtio/virtio_user/vhost_kernel.c
> @@ -380,7 +380,8 @@ struct vhost_memory_kernel {
> else
> hdr_size = sizeof(struct virtio_net_hdr);
>
> - tapfd = vhost_kernel_open_tap(&dev->ifname, hdr_size, req_mq);
> + tapfd = vhost_kernel_open_tap(&dev->ifname, hdr_size, req_mq,
> + (char *)dev->mac_addr);
> if (tapfd < 0) {
> PMD_DRV_LOG(ERR, "fail to open tap for vhost kernel");
> return -1;
> diff --git a/drivers/net/virtio/virtio_user/vhost_kernel_tap.c
> b/drivers/net/virtio/virtio_user/vhost_kernel_tap.c
> index 689a5cf..756fde2 100644
> --- a/drivers/net/virtio/virtio_user/vhost_kernel_tap.c
> +++ b/drivers/net/virtio/virtio_user/vhost_kernel_tap.c
> @@ -123,6 +123,14 @@
You forgot to add the mac param for vhost_kernel_open_tap().
The patch isn't buildable on my machine.
> PMD_DRV_LOG(ERR, "TUNSETOFFLOAD ioctl() failed: %s",
> strerror(errno));
>
> + memset(&ifr, 0, sizeof(ifr));
> + ifr.ifr_hwaddr.sa_family = ARPHRD_ETHER;
ARPHRD_ETHER? Please explain.
> + memcpy(ifr.ifr_hwaddr.sa_data, mac, ETH_ALEN);
You can use ETHER_ADDR_LEN.
There is no need to define ETH_ALEN.
> + if (ioctl(tapfd, SIOCSIFHWADDR, (void *)&ifr) == -1) {
> + PMD_DRV_LOG(ERR, "SIOCSIFHWADDR failed: %s", strerror(errno));
> + goto error;
> + }
> +
> if (!(*p_ifname))
> *p_ifname = strdup(ifr.ifr_name);
>
> diff --git a/drivers/net/virtio/virtio_user/vhost_kernel_tap.h
> b/drivers/net/virtio/virtio_user/vhost_kernel_tap.h
> index eae340c..f59b1ac 100644
> --- a/drivers/net/virtio/virtio_user/vhost_kernel_tap.h
> +++ b/drivers/net/virtio/virtio_user/vhost_kernel_tap.h
> @@ -64,4 +64,14 @@
> /* Constants */
> #define PATH_NET_TUN "/dev/net/tun"
>
> -int vhost_kernel_open_tap(char **p_ifname, int hdr_size, int req_mq);
> +/* Socket configuration controls. */
> +#define SIOCSIFHWADDR 0x8924 /* set hardware address */
There is no need to define this.
> +
> +/* ARP protocol HARDWARE identifiers. */
> +#define ARPHRD_ETHER1 /* Ethernet */
> +
> +/* Length of Ethernet address. */
> +#define ETH_ALEN 6
> +
There is no need to define this.
Thanks,
Tiwei
> +int vhost_kernel_open_tap(char **p_ifname, int hdr_size, int req_mq,
> + const char *mac);
> --
> 1.8.3.1
>
>
Re: [dpdk-dev] [RFC] eventdev: add crypto adapter API header
-Original Message-
> Date: Thu, 14 Dec 2017 18:52:02 +
> From: "Eads, Gage"
> To: Jerin Jacob
> CC: "Gujjar, Abhinandan S" , "dev@dpdk.org"
> , "Vangati, Narender" , "Rao,
> Nikhil" , "hemant.agra...@nxp.com"
> , "Doherty, Declan" ,
> "nidadavolu.mur...@cavium.com" ,
> "nithin.dabilpu...@cavium.com" ,
> "narayanaprasad.athr...@cavium.com"
> Subject: RE: [RFC] eventdev: add crypto adapter API header
>
>
>
> > -Original Message-
> > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> > Sent: Wednesday, December 13, 2017 8:49 PM
> > To: Eads, Gage
> > Cc: Gujjar, Abhinandan S ; dev@dpdk.org;
> > Vangati, Narender ; Rao, Nikhil
> > ; hemant.agra...@nxp.com; Doherty, Declan
> > ; nidadavolu.mur...@cavium.com;
> > nithin.dabilpu...@cavium.com; narayanaprasad.athr...@cavium.com
> > Subject: Re: [RFC] eventdev: add crypto adapter API header
> >
> > -Original Message-
> > > Date: Wed, 13 Dec 2017 23:35:48 +
> > > From: "Eads, Gage"
> > > To: Jerin Jacob , "Gujjar, Abhinandan S"
> > >
> > > CC: "dev@dpdk.org" , "Vangati, Narender"
> > > , "Rao, Nikhil" ,
> > > "hemant.agra...@nxp.com" , "Doherty, Declan"
> > > , "nidadavolu.mur...@cavium.com"
> > > , "nithin.dabilpu...@cavium.com"
> > > , "narayanaprasad.athr...@cavium.com"
> > >
> > > Subject: RE: [RFC] eventdev: add crypto adapter API header
> > >
> > > Hey Jerin,
> >
> > Hey Gage,
> >
> > >
> > >
> > >
> > > > > +
> > > > > + /**
> > > > > + * @warning
> > > > > + * @b EXPERIMENTAL: this enum may change without prior notice
> > > > > + *
> > > > > + * Crypto event adapter type
> > > > > + */
> > > > > +enum rte_event_crypto_adapter_type {
> > > > > + RTE_EVENT_CRYPTO_ADAPTER_RX_ONLY = 1,
> > > > > + /**< Start only Rx part of crypto adapter.
> > > > > + * Packets dequeued from cryptodev are new to eventdev and
> > > > > + * events will be treated as RTE_EVENT_OP_NEW */
> > > > > + RTE_EVENT_CRYPTO_ADAPTER_RX_TX,
> > > > > + /**< Start both Rx & Tx part of crypto adapter.
> > > > > + * Packet's event context will be retained and
> > > > > + * event will be treated as RTE_EVENT_OP_FORWARD */ };
> > > >
> > > > How about leveraging ev.op based schematics as mentioned above?
> > >
> > > That could work, but perhaps the ev.op should be configured once up
> > > front, as
> > I see it being a function of the application architecture. A couple possible
> > designs, for example:
> > > - Worker enqueues into cryptodev, adapter polls for response: the adapter
> > port would always use OP_NEW here.
> > > - Worker sends a crypto request event to the adapter, which gives the
> > > request to the cryptodev and polls for response: the adapter port
> > > would always use OP_FWD here. (This ties in with my implicit release
> > > patch (http://dpdk.org/ml/archives/dev/2017-December/083535.html))
> > > - Etc.
> >
> > Yes. Semantically both approaches will work. I was trying to avoid extra
> > clutter(enum rte_event_crypto_adapter_type) in adapter API.
> > I don't see any problem in moving ev.op to adapter configuration time if it
> > helps
> > the SW driver.
> >
> > IMO, We can change RTE_EVENT_CRYPTO_ADAPTER_RX_ONLY and
> > RTE_EVENT_CRYPTO_ADAPTER_RX_TX to more appropriate name, something
> > like,
> > RTE_EVENT_CRYPTO_ADAPTER_TYPE_OP_NEW/RTE_EVENT_CRYPTO_ADAPTE
> > R_TYPE_OP_FWD
> > or something like that.
> >
>
> I agree that the two naming schemes are equivalent, but since this option
> would control the adapter's behavior (Rx only vs. Rx + Tx), (IMO) I think
> Abhinandan's original names do a better job of conveying what effect these
> two options have on the adapter, compared to the op type names.
The only concern with Rx/Tx terminology was, It is mostly used in the ethdev
domain.
In crypto domain, typically, we use enqueue/dequeue.
The only difference between two modes is if adapter enqueue the events with
RTE_EVENT_OP_NEW vs RTE_EVENT_OP_FORWARD then (IMO) we can change
something related to that name to avoid adding a new terminology.
BTW, Based on the earlier discussion, if we need to add opaque eventdev metadata
to cryptodev then it may change ABI.If so, I think, we need to announce
ABI change notice for cryptodev and plan cryptodev adapter for v18.05.
[dpdk-dev] [PATCH v6 0/2] add inline protocol support
The series adds inline protocol support in DPDK. First patch introduces changes in lib to enable applications to save a (void *) pointer as "userdata" in security session. For inline processed packets, applications would use the metadata field in the mbuf (rte_mbuf.udata64) to retrieve the userdata registered for the security session which processed the packet. The metadata would be device specific. This is primarily required for inline protocol processed ingress packets. For such packets, the packet may not have enough information to identify the security parameters with which the packet was processed. Application can register what it needs to identify the required parameter. The userdata will be set while creating the security session. Second patch adds support for inline protocol in ipsec-secgw application Anoob Joseph (2): lib/security: add support for get userdata examples/ipsec-secgw: add support for inline protocol doc/guides/prog_guide/rte_security.rst | 22 - examples/ipsec-secgw/esp.c | 6 +- examples/ipsec-secgw/ipsec-secgw.c | 42 +- examples/ipsec-secgw/ipsec.c | 121 ++- lib/librte_security/rte_security.c | 12 +++ lib/librte_security/rte_security.h | 20 + lib/librte_security/rte_security_driver.h| 18 lib/librte_security/rte_security_version.map | 1 + 8 files changed, 219 insertions(+), 23 deletions(-) -- 2.7.4
[dpdk-dev] [PATCH v6 1/2] lib/security: add support for get userdata
In case of inline protocol processed ingress traffic, the packet may not
have enough information to determine the security parameters with which
the packet was processed. In such cases, application could get metadata
from the packet which could be used to identify the security parameters
with which the packet was processed.
Application could register "userdata" with the security session, and
this could be retrieved from the metadata of inline processed packets.
The metadata returned by "rte_security_get_pkt_metadata()" will be
device specific. Also the driver is expected to return the application
registered "userdata" as is, without any modifications.
Signed-off-by: Anoob Joseph
---
v6:
* The file *_version.map needs APIs to be in alphabetical order. Fixed this
for the new API added.
v5:
* No change
v4:
* Documented the usage of rte_mbuf.udata64 field by security library
* Removed (rte_security_get_pkt_metadata() API as the udata64 field itself
will have device-specific metadata, and could be directly used
v3:
* Replaced 64 bit metadata in conf with (void *)userdata
* The API(rte_security_get_pkt_metadata) would return void * instead of
uint64_t
v2:
* Replaced get_session and get_cookie APIs with get_pkt_metadata API
doc/guides/prog_guide/rte_security.rst | 22 +-
lib/librte_security/rte_security.c | 12
lib/librte_security/rte_security.h | 20
lib/librte_security/rte_security_driver.h| 18 ++
lib/librte_security/rte_security_version.map | 1 +
5 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/rte_security.rst
b/doc/guides/prog_guide/rte_security.rst
index 71be036..6768ebe 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -148,7 +148,9 @@ packet. e.g. in the case of IPSec, the IPSec tunnel headers
(if any),
ESP/AH headers will be removed from the packet and the received packet
will contains the decrypted packet only. The driver Rx path checks the
descriptors and based on the crypto status sets additional flags in
-``rte_mbuf.ol_flags`` field.
+``rte_mbuf.ol_flags`` field. The driver would also set device-specific
+metadata in ``rte_mbuf.udata64`` field. This will allow the application
+to identify the security processing done on the packet.
.. note::
@@ -421,6 +423,22 @@ For Inline Crypto and Inline protocol offload, device
specific defined metadata
updated in the mbuf using ``rte_security_set_pkt_metadata()`` if
``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set.
+For inline protocol offloaded ingress traffic, the application can register a
+pointer, ``userdata`` , in the security session. When the packet is received,
+``rte_security_get_userdata()`` would return the userdata registered for the
+security session which processed the packet.
+
+.. note::
+
+In case of inline processed packets, ``rte_mbuf.udata64`` field would be
+used by the driver to relay information on the security processing
+associated with the packet. In ingress, the driver would set this in Rx
+path while in egress, ``rte_security_set_pkt_metadata()`` would perform a
+similar operation. The application is expected not to modify the field
+when it has relevant info. For ingress, this device-specific 64 bit value
+is required to derive other information (like userdata), required for
+identifying the security processing done on the packet.
+
Security session configuration
~~
@@ -440,6 +458,8 @@ Security Session configuration structure is defined as
``rte_security_session_co
/**< Configuration parameters for security session */
struct rte_crypto_sym_xform *crypto_xform;
/**< Security Session Crypto Transformations */
+void *userdata;
+/**< Application specific userdata to be saved with session */
};
The configuration structure reuses the ``rte_crypto_sym_xform`` struct for
crypto related
diff --git a/lib/librte_security/rte_security.c
b/lib/librte_security/rte_security.c
index 1227fca..5805051 100644
--- a/lib/librte_security/rte_security.c
+++ b/lib/librte_security/rte_security.c
@@ -108,6 +108,18 @@ rte_security_set_pkt_metadata(struct rte_security_ctx
*instance,
sess, m, params);
}
+void *
+rte_security_get_userdata(struct rte_security_ctx *instance, uint64_t md)
+{
+ void *userdata = NULL;
+
+ RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_userdata, NULL);
+ if (instance->ops->get_userdata(instance->device, md, &userdata))
+ return NULL;
+
+ return userdata;
+}
+
const struct rte_security_capability *
rte_security_capabilities_get(struct rte_security_ctx *instance)
{
diff --git a/lib/librte_security/rte_security.h
b/lib/librte_security/rte_security.h
index 653929b..a34cbba 100644
--- a/lib/librte_security/rte_security.h
+++ b/l
[dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol
Adding support for inline protocol processing
In ingress side, application will receive regular IP packets, without
any IPsec related info. Application will do a selector check (SP-SA
check) by making use of the metadata from the packet. The
device-specific metadata in mbuf would aid in determing the security
session which processed the packet.
In egress side, the plain packet would be submitted to the driver. The
packet will have optional metadata, which could be used to identify the
security session associated with the packet.
Signed-off-by: Anoob Joseph
---
v6:
* No change
v5:
* Fixed checkpatch reported warnings
v4:
* Directly using rte_mbuf.udata64 as the metadata from the packet
* Removed usage of rte_security_get_pkt_metadata API
v3:
* Using (void *)userdata instead of 64 bit metadata in conf
* Changes parallel to the change in API
v2:
* Using get_pkt_metadata API instead of get_session & get_cookie APIs
examples/ipsec-secgw/esp.c | 6 +-
examples/ipsec-secgw/ipsec-secgw.c | 42 -
examples/ipsec-secgw/ipsec.c | 121 +++--
3 files changed, 147 insertions(+), 22 deletions(-)
diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
index c3efe52..561f873 100644
--- a/examples/ipsec-secgw/esp.c
+++ b/examples/ipsec-secgw/esp.c
@@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa *sa,
RTE_ASSERT(sa != NULL);
RTE_ASSERT(cop != NULL);
- if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+ if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+ (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
@@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
RTE_ASSERT(m != NULL);
RTE_ASSERT(sa != NULL);
- if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+ if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+ (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
m->ol_flags |= PKT_TX_SEC_OFFLOAD;
} else {
RTE_ASSERT(cop != NULL);
diff --git a/examples/ipsec-secgw/ipsec-secgw.c
b/examples/ipsec-secgw/ipsec-secgw.c
index c98454a..8254056 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -265,6 +265,40 @@ prepare_one_packet(struct rte_mbuf *pkt, struct
ipsec_traffic *t)
RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
rte_pktmbuf_free(pkt);
}
+
+ /* Check if the packet has been processed inline. For inline protocol
+* processed packets, the metadata in the mbuf can be used to identify
+* the security processing done on the packet. The metadata will be
+* used to retrieve the application registered userdata associated
+* with the security session.
+*/
+
+ if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
+ struct ipsec_sa *sa;
+ struct ipsec_mbuf_metadata *priv;
+ struct rte_security_ctx *ctx = (struct rte_security_ctx *)
+ rte_eth_dev_get_sec_ctx(
+ pkt->port);
+
+ /* Retrieve the userdata registered. Here, the userdata
+* registered is the SA pointer.
+*/
+
+ sa = (struct ipsec_sa *)
+ rte_security_get_userdata(ctx, pkt->udata64);
+
+ if (sa == NULL) {
+ /* userdata could not be retrieved */
+ return;
+ }
+
+ /* Save SA as priv member in mbuf. This will be used in the
+* IPsec selector(SP-SA) check.
+*/
+
+ priv = get_priv(pkt);
+ priv->sa = sa;
+ }
}
static inline void
@@ -401,11 +435,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa,
struct traffic_type *ip,
ip->pkts[j++] = m;
continue;
}
- if (res & DISCARD || i < lim) {
+ if (res & DISCARD) {
rte_pktmbuf_free(m);
continue;
}
+
/* Only check SPI match for processed IPSec packets */
+ if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
+ rte_pktmbuf_free(m);
+ continue;
+ }
+
sa_idx = ip->res[i] & PROTECT_MASK;
if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
rte_pktmbuf_free(m);
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 70ed227..bd68
Re: [dpdk-dev] [PATCH v6 1/2] lib/security: add support for get userdata
On 12/18/2017 12:45 PM, Anoob Joseph wrote: In case of inline protocol processed ingress traffic, the packet may not have enough information to determine the security parameters with which the packet was processed. In such cases, application could get metadata from the packet which could be used to identify the security parameters with which the packet was processed. Application could register "userdata" with the security session, and this could be retrieved from the metadata of inline processed packets. The metadata returned by "rte_security_get_pkt_metadata()" will be device specific. Also the driver is expected to return the application registered "userdata" as is, without any modifications. Signed-off-by: Anoob Joseph --- v6: * The file *_version.map needs APIs to be in alphabetical order. Fixed this for the new API added. v5: * No change v4: * Documented the usage of rte_mbuf.udata64 field by security library * Removed (rte_security_get_pkt_metadata() API as the udata64 field itself will have device-specific metadata, and could be directly used v3: * Replaced 64 bit metadata in conf with (void *)userdata * The API(rte_security_get_pkt_metadata) would return void * instead of uint64_t v2: * Replaced get_session and get_cookie APIs with get_pkt_metadata API doc/guides/prog_guide/rte_security.rst | 22 +- lib/librte_security/rte_security.c | 12 lib/librte_security/rte_security.h | 20 lib/librte_security/rte_security_driver.h| 18 ++ lib/librte_security/rte_security_version.map | 1 + 5 files changed, 72 insertions(+), 1 deletion(-) library Patch Acked-by: Akhil Goyal
Re: [dpdk-dev] [PATCH v3] arch/arm: optimization for memcpy on AArch64
-Original Message- > Date: Mon, 18 Dec 2017 10:54:24 +0800 > From: Herbert Guan > To: dev@dpdk.org, jerin.ja...@caviumnetworks.com > CC: Herbert Guan > Subject: [PATCH v3] arch/arm: optimization for memcpy on AArch64 > X-Mailer: git-send-email 1.8.3.1 > > Signed-off-by: Herbert Guan > --- > config/common_armv8a_linuxapp | 6 + > .../common/include/arch/arm/rte_memcpy_64.h| 292 > + > 2 files changed, 298 insertions(+) > > diff --git a/config/common_armv8a_linuxapp b/config/common_armv8a_linuxapp > index 6732d1e..8f0cbed 100644 > --- a/config/common_armv8a_linuxapp > +++ b/config/common_armv8a_linuxapp > @@ -44,6 +44,12 @@ CONFIG_RTE_FORCE_INTRINSICS=y > # to address minimum DMA alignment across all arm64 implementations. > CONFIG_RTE_CACHE_LINE_SIZE=128 > > +# Accelarate rte_memcpy. Be sure to run unit test to determine the Additional space before "Be". Rather than just mentioning the unit test, mention the absolute test case name(memcpy_perf_autotest) > +# best threshold in code. Refer to notes in source file Additional space before "Refer" > +# (lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h) for more > +# info. > +CONFIG_RTE_ARCH_ARM64_MEMCPY=n > + > CONFIG_RTE_LIBRTE_FM10K_PMD=n > CONFIG_RTE_LIBRTE_SFC_EFX_PMD=n > CONFIG_RTE_LIBRTE_AVP_PMD=n > diff --git a/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h > b/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h > index b80d8ba..1ea275d 100644 > --- a/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h > +++ b/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h > @@ -42,6 +42,296 @@ > > #include "generic/rte_memcpy.h" > > +#ifdef RTE_ARCH_ARM64_MEMCPY See the comment below at "(GCC_VERSION < 50400)" check > +#include > +#include > + > +/* > + * The memory copy performance differs on different AArch64 > micro-architectures. > + * And the most recent glibc (e.g. 2.23 or later) can provide a better > memcpy() > + * performance compared to old glibc versions. It's always suggested to use a > + * more recent glibc if possible, from which the entire system can get > benefit. > + * > + * This implementation improves memory copy on some aarch64 > micro-architectures, > + * when an old glibc (e.g. 2.19, 2.17...) is being used. It is disabled by > + * default and needs "RTE_ARCH_ARM64_MEMCPY" defined to activate. It's not > + * always providing better performance than memcpy() so users need to run > unit > + * test "memcpy_perf_autotest" and customize parameters in customization > section > + * below for best performance. > + * > + * Compiler version will also impact the rte_memcpy() performance. It's > observed > + * on some platforms and with the same code, GCC 7.2.0 compiled binaries can > + * provide better performance than GCC 4.8.5 compiled binaries. > + */ > + > +/** > + * Beginning of customization section > + **/ > +#define ALIGNMENT_MASK 0x0F This symbol will be included in public rte_memcpy.h version for arm64 DPDK build. Please use RTE_ prefix to avoid multi definition.(RTE_ARCH_ARM64_ALIGN_MASK ? or any shorter name) > +#ifndef RTE_ARCH_ARM64_MEMCPY_STRICT_ALIGN > +/* Only src unalignment will be treaed as unaligned copy */ > +#define IS_UNALIGNED_COPY(dst, src) ((uintptr_t)(dst) & ALIGNMENT_MASK) > +#else > +/* Both dst and src unalignment will be treated as unaligned copy */ > +#define IS_UNALIGNED_COPY(dst, src) \ > + (((uintptr_t)(dst) | (uintptr_t)(src)) & ALIGNMENT_MASK) > +#endif > + > + > +/* > + * If copy size is larger than threshold, memcpy() will be used. > + * Run "memcpy_perf_autotest" to determine the proper threshold. > + */ > +#define ALIGNED_THRESHOLD ((size_t)(0x)) > +#define UNALIGNED_THRESHOLD ((size_t)(0x)) Same as above comment. > + > +/** > + * End of customization section > + **/ > +#ifdef RTE_TOOLCHAIN_GCC > +#if (GCC_VERSION < 50400) > +#warning "The GCC version is quite old, which may result in sub-optimal \ > +performance of the compiled code. It is suggested that at least GCC 5.4.0 \ > +be used." Even though it is warning, based on where this file get included it will generate error(see below) How about, selecting optimized memcpy when RTE_ARCH_ARM64_MEMCPY && if (GCC_VERSION >= 50400) ? CC eal_common_options.o In file included from /home/jerin/dpdk.org/build/include/rte_memcpy.h:37:0,from /home/jerin/dpdk.org/lib/librte_eal/common/eal_common_options.c:53: /home/jerin/dpdk.org/build/include/rte_memcpy_64.h:93:2: error: #warning "The GCC version is quite old, which may result in sub-optimal performance of the compiled code. It is suggested that at least GCC 5.4.0 be used." [-Werror=cpp] ^^ #warning "The GCC version is quite
Re: [dpdk-dev] [PATCH v2 2/5] lpm: fix compilation on ARM BE
On 12/13/2017 6:52 PM, Bruce Richardson wrote:
On Wed, Dec 13, 2017 at 06:22:55PM +0530, Hemant Agrawal wrote:
Compiling on ARM BE using Linaro toolchain caused following
error/warnings.
rte_lpm.c: In function ‘add_depth_big_v20’:
rte_lpm.c:911:4: error: braces around scalar initializer [-Werror]
{ .group_idx = (uint8_t)tbl8_group_index, },
^
rte_lpm.c:911:4: note: (near initialization for
‘new_tbl24_entry.depth’)
rte_lpm.c:911:6:error: field name not in record or union initializer
{ .group_idx = (uint8_t)tbl8_group_index, },
^
rte_lpm.c:911:6: note: (near initialization for
‘new_tbl24_entry.depth’)
rte_lpm.c:914:13: error: initialized field overwritten
[-Werror=override-init]
.depth = 0,
Fixes: dc81ebbacaeb ("lpm: extend IPv4 next hop field")
Cc: Michal Kobylinski
Cc: sta...@dpdk.org
Signed-off-by: Jun Yang
Signed-off-by: Hemant Agrawal
Acked-by: Bruce Richardson
---
v2: added endianess check in the assignments
lib/librte_lpm/rte_lpm.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index e1f1fad..a47c04f 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -912,10 +912,17 @@ add_depth_big_v20(struct rte_lpm_v20 *lpm, uint32_t
ip_masked, uint8_t depth,
*/
struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
{ .group_idx = (uint8_t)tbl8_group_index, },
.valid = VALID,
.valid_group = 1,
.depth = 0,
+#else
+ .depth = 0,
+ .valid_group = 1,
+ .valid = VALID,
+ { .group_idx = (uint8_t)tbl8_group_index, },
+#endif
};
I'm not I'd agree with this as a "better" fix. Were the issues with the
previous version of just removing the braces. All the ifdefs are rather
ugly.
Ok. I will revert.
[dpdk-dev] [PATCH v3 2/5] lpm: fix compilation on ARM BE
Compiling on ARM BE using Linaro toolchain caused following
error/warnings.
rte_lpm.c: In function ‘add_depth_big_v20’:
rte_lpm.c:911:4: error: braces around scalar initializer [-Werror]
{ .group_idx = (uint8_t)tbl8_group_index, },
^
rte_lpm.c:911:4: note: (near initialization for
‘new_tbl24_entry.depth’)
rte_lpm.c:911:6:error: field name not in record or union initializer
{ .group_idx = (uint8_t)tbl8_group_index, },
^
rte_lpm.c:911:6: note: (near initialization for
‘new_tbl24_entry.depth’)
rte_lpm.c:914:13: error: initialized field overwritten
[-Werror=override-init]
.depth = 0,
Fixes: dc81ebbacaeb ("lpm: extend IPv4 next hop field")
Cc: Michal Kobylinski
Cc: sta...@dpdk.org
Signed-off-by: Hemant Agrawal
Acked-by: Bruce Richardson
---
v3: reverting ifdef
v2: adding ifdef
lib/librte_lpm/rte_lpm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index e1f1fad..dda74a9 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -912,7 +912,7 @@ add_depth_big_v20(struct rte_lpm_v20 *lpm, uint32_t
ip_masked, uint8_t depth,
*/
struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- { .group_idx = (uint8_t)tbl8_group_index, },
+ .group_idx = (uint8_t)tbl8_group_index,
.valid = VALID,
.valid_group = 1,
.depth = 0,
@@ -958,7 +958,7 @@ add_depth_big_v20(struct rte_lpm_v20 *lpm, uint32_t
ip_masked, uint8_t depth,
*/
struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- { .group_idx = (uint8_t)tbl8_group_index, },
+ .group_idx = (uint8_t)tbl8_group_index,
.valid = VALID,
.valid_group = 1,
.depth = 0,
@@ -1365,7 +1365,7 @@ delete_depth_small_v20(struct rte_lpm_v20 *lpm, uint32_t
ip_masked,
*/
struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- {.next_hop = lpm->rules_tbl[sub_rule_index].next_hop,},
+ .next_hop = lpm->rules_tbl[sub_rule_index].next_hop,
.valid = VALID,
.valid_group = 0,
.depth = sub_rule_depth,
@@ -1668,7 +1668,7 @@ delete_depth_big_v20(struct rte_lpm_v20 *lpm, uint32_t
ip_masked,
} else if (tbl8_recycle_index > -1) {
/* Update tbl24 entry. */
struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
- { .next_hop = lpm->tbl8[tbl8_recycle_index].next_hop, },
+ .next_hop = lpm->tbl8[tbl8_recycle_index].next_hop,
.valid = VALID,
.valid_group = 0,
.depth = lpm->tbl8[tbl8_recycle_index].depth,
--
2.7.4
[dpdk-dev] [PATCH v3 1/5] pmdinfogen: fix cross compilation for ARM BE
Cross compiling DPDK for BE mode on ARM results into errors
"PMDINFO portal/dpaa2_hw_dpio.o.pmd.c No drivers registered"
The original code assumes the sh_size to be 32 bit, while it can
be Elf32_Word or Elf64_Xword based on 32bit or 64 bit systems.
This patches replaces the sh_size conversion routines to use ADDR_SIZE
Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen utility")
Cc: Neil Horman
Cc: sta...@dpdk.org
Signed-off-by: Jun Yang
Signed-off-by: Hemant Agrawal
Acked-by: Bruce Richardson
Acked-by: Neil Horman
---
buildtools/pmdinfogen/pmdinfogen.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/buildtools/pmdinfogen/pmdinfogen.c
b/buildtools/pmdinfogen/pmdinfogen.c
index 96ccbf3..b07dbcf 100644
--- a/buildtools/pmdinfogen/pmdinfogen.c
+++ b/buildtools/pmdinfogen/pmdinfogen.c
@@ -158,7 +158,8 @@ static int parse_elf(struct elf_info *info, const char
*filename)
* There are more than 64k sections,
* read count from .sh_size.
*/
- info->num_sections = TO_NATIVE(endian, 32, sechdrs[0].sh_size);
+ info->num_sections =
+ TO_NATIVE(endian, ADDR_SIZE, sechdrs[0].sh_size);
} else {
info->num_sections = hdr->e_shnum;
}
@@ -181,7 +182,7 @@ static int parse_elf(struct elf_info *info, const char
*filename)
sechdrs[i].sh_offset=
TO_NATIVE(endian, ADDR_SIZE, sechdrs[i].sh_offset);
sechdrs[i].sh_size =
- TO_NATIVE(endian, 32, sechdrs[i].sh_size);
+ TO_NATIVE(endian, ADDR_SIZE, sechdrs[i].sh_size);
sechdrs[i].sh_link =
TO_NATIVE(endian, 32, sechdrs[i].sh_link);
sechdrs[i].sh_info =
--
2.7.4
[dpdk-dev] [PATCH v3 3/5] bus/dpaa: fix compilation on ARM BE
Fix the following compilation error when compiling
with ARM BE compiler.
drivers/bus/dpaa/include/fsl_qman.h:1997:25:
error: statement with no effect [-Werror=unused-value]
#define hw_sg_to_cpu(x) (x)
Fixes: c47ff048b99a ("bus/dpaa: add QMAN driver core routines")
Cc: sta...@dpdk.org
Signed-off-by: Hemant Agrawal
---
drivers/bus/dpaa/include/fsl_qman.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/dpaa/include/fsl_qman.h
b/drivers/bus/dpaa/include/fsl_qman.h
index eedfd7e..72556dc 100644
--- a/drivers/bus/dpaa/include/fsl_qman.h
+++ b/drivers/bus/dpaa/include/fsl_qman.h
@@ -1993,8 +1993,8 @@ static inline int qman_poll_fq_for_init(struct qman_fq
*fq)
}
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
-#define cpu_to_hw_sg(x) (x)
-#define hw_sg_to_cpu(x) (x)
+#define cpu_to_hw_sg(x)
+#define hw_sg_to_cpu(x)
#else
#define cpu_to_hw_sg(x) __cpu_to_hw_sg(x)
#define hw_sg_to_cpu(x) __hw_sg_to_cpu(x)
--
2.7.4
[dpdk-dev] [PATCH v3 5/5] net/ixgbe: fix compilation on ARM BE
fixes the following compilation error on compiling with ARM BE compiler
ixgbe_common.c: In function ‘ixgbe_host_interface_command’:
ixgbe_common.c:4610:22: error: passing argument 1 of
‘__builtin_bswap32’ makes integer from pointer without a cast
[-Werror=int-conversion]
IXGBE_LE32_TO_CPUS(&buffer[bi]);
^
Fixes: aa4fc14d2cee ("ixgbe: update base driver")
Cc: sta...@dpdk.org
Signed-off-by: Hemant Agrawal
Acked-by: Bruce Richardson
---
drivers/net/ixgbe/base/ixgbe_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/base/ixgbe_common.c
b/drivers/net/ixgbe/base/ixgbe_common.c
index 7f85713..5e6ad95 100644
--- a/drivers/net/ixgbe/base/ixgbe_common.c
+++ b/drivers/net/ixgbe/base/ixgbe_common.c
@@ -4607,7 +4607,7 @@ s32 ixgbe_host_interface_command(struct ixgbe_hw *hw, u32
*buffer,
/* first pull in the header so we know the buffer length */
for (bi = 0; bi < dword_len; bi++) {
buffer[bi] = IXGBE_READ_REG_ARRAY(hw, IXGBE_FLEX_MNG, bi);
- IXGBE_LE32_TO_CPUS(&buffer[bi]);
+ IXGBE_LE32_TO_CPUS((uintptr_t)&buffer[bi]);
}
/* If there is any thing in data position pull it in */
@@ -4627,7 +4627,7 @@ s32 ixgbe_host_interface_command(struct ixgbe_hw *hw, u32
*buffer,
/* Pull in the rest of the buffer (bi is where we left off) */
for (; bi <= dword_len; bi++) {
buffer[bi] = IXGBE_READ_REG_ARRAY(hw, IXGBE_FLEX_MNG, bi);
- IXGBE_LE32_TO_CPUS(&buffer[bi]);
+ IXGBE_LE32_TO_CPUS((uintptr_t)&buffer[bi]);
}
rel_out:
--
2.7.4
[dpdk-dev] [PATCH v3 4/5] net/i40e: fix compilation on ARM BE
This patch fixes the following error observed when
compiling with ARM BE compiler.
i40e_ethdev.c: In function ‘i40e_dev_tunnel_filter_set’:
i40e_ethdev.c:6988:5: error: lvalue required as unary ‘&’ operand
&rte_cpu_to_le_32(ipv4_addr),
Fixes: edc845bd53ec ("app/testpmd: fix build on FreeBSD")
Cc: Marvin Liu
Cc: sta...@dpdk.org
Signed-off-by: Hemant Agrawal
Acked-by: Beilei Xing
---
drivers/net/i40e/i40e_ethdev.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 811cc9f..a92933c 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -6951,7 +6951,7 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
uint8_t add)
{
uint16_t ip_type;
- uint32_t ipv4_addr;
+ uint32_t ipv4_addr, ipv4_addr_le;
uint8_t i, tun_type = 0;
/* internal varialbe to convert ipv6 byte order */
uint32_t convert_ipv6[4];
@@ -6984,8 +6984,9 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
if (tunnel_filter->ip_type == RTE_TUNNEL_IPTYPE_IPV4) {
ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV4;
ipv4_addr = rte_be_to_cpu_32(tunnel_filter->ip_addr.ipv4_addr);
+ ipv4_addr_le = rte_cpu_to_le_32(ipv4_addr);
rte_memcpy(&pfilter->element.ipaddr.v4.data,
- &rte_cpu_to_le_32(ipv4_addr),
+ &ipv4_addr_le,
sizeof(pfilter->element.ipaddr.v4.data));
} else {
ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV6;
@@ -7302,7 +7303,7 @@ i40e_dev_consistent_tunnel_filter_set(struct i40e_pf *pf,
uint8_t add)
{
uint16_t ip_type;
- uint32_t ipv4_addr;
+ uint32_t ipv4_addr, ipv4_addr_le;
uint8_t i, tun_type = 0;
/* internal variable to convert ipv6 byte order */
uint32_t convert_ipv6[4];
@@ -7338,8 +7339,9 @@ i40e_dev_consistent_tunnel_filter_set(struct i40e_pf *pf,
if (tunnel_filter->ip_type == I40E_TUNNEL_IPTYPE_IPV4) {
ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV4;
ipv4_addr = rte_be_to_cpu_32(tunnel_filter->ip_addr.ipv4_addr);
+ ipv4_addr_le = rte_cpu_to_le_32(ipv4_addr);
rte_memcpy(&pfilter->element.ipaddr.v4.data,
- &rte_cpu_to_le_32(ipv4_addr),
+ &ipv4_addr_le,
sizeof(pfilter->element.ipaddr.v4.data));
} else {
ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV6;
--
2.7.4
