Re: [dpdk-dev] [PATCH v6] devtools: add tags and cscope index file generation support
29/04/2017 12:51, Jerin Jacob: > This script generates cscope, gtags, and tags index files based on > EAL environment(architecture and OS(linux/bsd)). > > Selection of the architecture and OS environment is based on dpdk > configuration target(T=).If EAL environment(T=) is not specified, > the script generates tag files based on available source code. > > Usage: make tags|cscope|gtags|etags [T=config] > > example usage: > make cscope > make tags T=x86_64-native-linuxapp-gcc > make gtags T=arm64-armv8a-linuxapp-gcc > > Signed-off-by: Jerin Jacob > Reviewed-by: Yuanhan Liu > Reviewed-by: Ferruh Yigit > --- > v6: > - Addressed all the review comments from Thomas > http://dpdk.org/ml/archives/dev/2017-April/064964.html Reviewed-by: Thomas Monjalon Applied, thanks
Re: [dpdk-dev] [PATCH v6] devtools: add tags and cscope index file generation support
30/04/2017 12:45, Thomas Monjalon: > 29/04/2017 12:51, Jerin Jacob: > > This script generates cscope, gtags, and tags index files based on > > EAL environment(architecture and OS(linux/bsd)). > > > > Selection of the architecture and OS environment is based on dpdk > > configuration target(T=).If EAL environment(T=) is not specified, > > the script generates tag files based on available source code. > > > > Usage: make tags|cscope|gtags|etags [T=config] > > > > example usage: > > make cscope > > make tags T=x86_64-native-linuxapp-gcc > > make gtags T=arm64-armv8a-linuxapp-gcc > > > > Signed-off-by: Jerin Jacob > > Reviewed-by: Yuanhan Liu > > Reviewed-by: Ferruh Yigit > > --- > > v6: > > - Addressed all the review comments from Thomas > > http://dpdk.org/ml/archives/dev/2017-April/064964.html > > Reviewed-by: Thomas Monjalon > > Applied, thanks PS: I've just moved the "cd" line at the beginning of the script in order to be able to do: devtools % ./build-tags.sh -h
Re: [dpdk-dev] [PATCH] usertools: fix device binding when using with kernel tools
26/04/2017 15:52, Guduri Prathyusha:
> The following sequence of operation gives error in binding devices
> 1) Bind a device using dpdk-devbind.py
> 2) Unbind the device using kernel tools(/sys/bus/pci/device/driver/unbind)
> 3) Bind the device using kernel tools(/sys/bus/pci/driver/new_id and
> /sys/bus/pci/driver/bind)
>
> The bind failure was due to cached driver name in 'driver_override'.
> Fix it by writing 'null' to driver_override just after binding a
> device so that any method of binding/unbinding can be used.
>
> Fixes: 2fc350293570 ("usertools: use optimized driver override scheme to
> bind")
>
> Reported-by: Tu LijuanX A
> Signed-off-by: Guduri Prathyusha
Applied, thanks
[dpdk-dev] [PATCH 0/3] fix memory overflow for 32 bit vPMD
The return mbuf points of RX path is possible be modified out of bound with 32 bit vPMD. The patch set fix for related drivers. Qi Zhang (3): net/i40e: fix memory overflow for 32 bit vPMD net/ixgbe: fix memory overflow for 32 bit vPMD net/fm10k: fix memory overflow for 32 bit vPMD drivers/net/fm10k/fm10k_rxtx_vec.c | 16 drivers/net/i40e/i40e_rxtx_vec_sse.c | 16 drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 16 3 files changed, 36 insertions(+), 12 deletions(-) -- 2.7.4
[dpdk-dev] [PATCH 1/3] net/i40e: fix memory overflow for 32 bit vPMD
Return mbuf points of _recv_raw_pkts_vec are modified out of bound.
Fixes: 8e109464c022 ("i40e: allow vector Rx and Tx usage")
Cc: sta...@dpdk.org
Signed-off-by: Qi Zhang
---
drivers/net/i40e/i40e_rxtx_vec_sse.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx_vec_sse.c
b/drivers/net/i40e/i40e_rxtx_vec_sse.c
index 8bc3399..3b4a352 100644
--- a/drivers/net/i40e/i40e_rxtx_vec_sse.c
+++ b/drivers/net/i40e/i40e_rxtx_vec_sse.c
@@ -316,20 +316,26 @@ _recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
__m128i descs[RTE_I40E_DESCS_PER_LOOP];
__m128i pkt_mb1, pkt_mb2, pkt_mb3, pkt_mb4;
__m128i zero, staterr, sterr_tmp1, sterr_tmp2;
- __m128i mbp1, mbp2; /* two mbuf pointer in one XMM reg. */
+ /* 2 64 bit or 4 32 bit mbuf pointers in one XMM reg. */
+ __m128i mbp1;
+#if defined(RTE_ARCH_X86_64)
+ __m128i mbp2;
+#endif
- /* B.1 load 1 mbuf point */
+ /* B.1 load 2 (64 bit) or 4 (32 bit) mbuf points */
mbp1 = _mm_loadu_si128((__m128i *)&sw_ring[pos]);
/* Read desc statuses backwards to avoid race condition */
/* A.1 load 4 pkts desc */
descs[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));
rte_compiler_barrier();
- /* B.2 copy 2 mbuf point into rx_pkts */
+ /* B.2 copy 2 64 bit or 4 32 bit mbuf point into rx_pkts */
_mm_storeu_si128((__m128i *)&rx_pkts[pos], mbp1);
- /* B.1 load 1 mbuf point */
+#if defined(RTE_ARCH_X86_64)
+ /* B.1 load 2 64 bit mbuf points */
mbp2 = _mm_loadu_si128((__m128i *)&sw_ring[pos+2]);
+#endif
descs[2] = _mm_loadu_si128((__m128i *)(rxdp + 2));
rte_compiler_barrier();
@@ -338,8 +344,10 @@ _recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
rte_compiler_barrier();
descs[0] = _mm_loadu_si128((__m128i *)(rxdp));
+#if defined(RTE_ARCH_X86_64)
/* B.2 copy 2 mbuf point into rx_pkts */
_mm_storeu_si128((__m128i *)&rx_pkts[pos+2], mbp2);
+#endif
if (split_packet) {
rte_mbuf_prefetch_part2(rx_pkts[pos]);
--
2.7.4
[dpdk-dev] [PATCH 2/3] net/ixgbe: fix memory overflow for 32 bit vPMD
Return mbuf points of _recv_raw_pkts_vec are modified out of bound.
Fixes: c95584dc2b18 ("ixgbe: new vectorized functions for Rx/Tx")
Cc: sta...@dpdk.org
Signed-off-by: Qi Zhang
---
drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
index 795ee33..a7bc199 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
@@ -337,9 +337,13 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
__m128i descs[RTE_IXGBE_DESCS_PER_LOOP];
__m128i pkt_mb1, pkt_mb2, pkt_mb3, pkt_mb4;
__m128i zero, staterr, sterr_tmp1, sterr_tmp2;
- __m128i mbp1, mbp2; /* two mbuf pointer in one XMM reg. */
+ /* 2 64 bit or 4 32 bit mbuf pointers in one XMM reg. */
+ __m128i mbp1;
+#if defined(RTE_ARCH_X86_64)
+ __m128i mbp2;
+#endif
- /* B.1 load 1 mbuf point */
+ /* B.1 load 2 (64 bit) or 4 (32 bit) mbuf points */
mbp1 = _mm_loadu_si128((__m128i *)&sw_ring[pos]);
/* Read desc statuses backwards to avoid race condition */
@@ -347,11 +351,13 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
descs[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));
rte_compiler_barrier();
- /* B.2 copy 2 mbuf point into rx_pkts */
+ /* B.2 copy 2 64 bit or 4 32 bit mbuf point into rx_pkts */
_mm_storeu_si128((__m128i *)&rx_pkts[pos], mbp1);
- /* B.1 load 1 mbuf point */
+#if defined(RTE_ARCH_X86_64)
+ /* B.1 load 2 64 bit mbuf points */
mbp2 = _mm_loadu_si128((__m128i *)&sw_ring[pos+2]);
+#endif
descs[2] = _mm_loadu_si128((__m128i *)(rxdp + 2));
rte_compiler_barrier();
@@ -360,8 +366,10 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
rte_compiler_barrier();
descs[0] = _mm_loadu_si128((__m128i *)(rxdp));
+#if defined(RTE_ARCH_X86_64)
/* B.2 copy 2 mbuf point into rx_pkts */
_mm_storeu_si128((__m128i *)&rx_pkts[pos+2], mbp2);
+#endif
if (split_packet) {
rte_mbuf_prefetch_part2(rx_pkts[pos]);
--
2.7.4
[dpdk-dev] [PATCH 3/3] net/fm10k: fix memory overflow for 32 bit vPMD
Return mbuf points of _recv_raw_pkts_vec are modified out of bound.
Fixes: a6ce64a97520 ("fm10k: introduce vector driver")
Cc: sta...@dpdk.org
Signed-off-by: Qi Zhang
---
drivers/net/fm10k/fm10k_rxtx_vec.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c
b/drivers/net/fm10k/fm10k_rxtx_vec.c
index 89cd958..c762b43 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -467,9 +467,13 @@ fm10k_recv_raw_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
__m128i descs0[RTE_FM10K_DESCS_PER_LOOP];
__m128i pkt_mb1, pkt_mb2, pkt_mb3, pkt_mb4;
__m128i zero, staterr, sterr_tmp1, sterr_tmp2;
- __m128i mbp1, mbp2; /* two mbuf pointer in one XMM reg. */
+ __m128i mbp1;
+ /* 2 64 bit or 4 32 bit mbuf pointers in one XMM reg. */
+#if defined(RTE_ARCH_X86_64)
+ __m128i mbp2;
+#endif
- /* B.1 load 1 mbuf point */
+ /* B.1 load 2 (64 bit) or 4 (32 bit) mbuf points */
mbp1 = _mm_loadu_si128((__m128i *)&mbufp[pos]);
/* Read desc statuses backwards to avoid race condition */
@@ -477,11 +481,13 @@ fm10k_recv_raw_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
descs0[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));
rte_compiler_barrier();
- /* B.2 copy 2 mbuf point into rx_pkts */
+ /* B.2 copy 2 64 bit or 4 32 bit mbuf point into rx_pkts */
_mm_storeu_si128((__m128i *)&rx_pkts[pos], mbp1);
- /* B.1 load 1 mbuf point */
+#if defined(RTE_ARCH_X86_64)
+ /* B.1 load 2 64 bit mbuf poitns */
mbp2 = _mm_loadu_si128((__m128i *)&mbufp[pos+2]);
+#endif
descs0[2] = _mm_loadu_si128((__m128i *)(rxdp + 2));
rte_compiler_barrier();
@@ -490,8 +496,10 @@ fm10k_recv_raw_pkts_vec(void *rx_queue, struct rte_mbuf
**rx_pkts,
rte_compiler_barrier();
descs0[0] = _mm_loadu_si128((__m128i *)(rxdp));
+#if defined(RTE_ARCH_X86_64)
/* B.2 copy 2 mbuf point into rx_pkts */
_mm_storeu_si128((__m128i *)&rx_pkts[pos+2], mbp2);
+#endif
/* avoid compiler reorder optimization */
rte_compiler_barrier();
--
2.7.4
Re: [dpdk-dev] [PATCH v2] usertools: add status-dev argument to devbind
27/04/2017 19:55, Ferruh Yigit: > Script displays status for all device types and output is much > longer than it used to be. This makes harder to read script output. > > This patch adds new --status-dev argument to the script to select > a device group to display status. > > Supported device groups: > net > crypto > event > mempool > > Sample usage: > ./usertools/dpdk-devbind.py --status-dev mempool > > Signed-off-by: Ferruh Yigit Applied, thanks
Re: [dpdk-dev] [PATCH] usertools: fix cpu_layout script for multithreads of more than 2
28/04/2017 14:25, Andriy Berestovskyy: > Works fine on ThunderX and does not brake Intel either. > > Reviewed-by: Andriy Berestovskyy > Tested-by: Andriy Berestovskyy > > Andriy > > On 28.04.2017 13:58, Thomas Monjalon wrote: > > Andriy, please would you like to review this patch? > > > > 28/04/2017 12:34, Gowrishankar: > >> From: Gowrishankar Muthukrishnan > >> > >> Current usertools/cpu_layout.py is broken to handle multithreads of count > >> more > >> than 2 as in IBM powerpc P8 servers. Below patch addressed this issue. > >> Also, > >> added minor exception catch on failing to open unavailable sys file in > >> case of > >> multithread=off configuration in server. > >> > >> Patch has been verified not to break existing topology configurations > >> and also not changing anything in current output. > >> > >> Signed-off-by: Gowrishankar Muthukrishnan > >> Applied, thanks
[dpdk-dev] [PATCH] usertools: fix CPU layout with python 3
These differences in Python 3 were causing errors:
- xrange is replaced by range
- dict values are a view (instead of list)
- has_key is removed
Fixes: deb87e6777c0 ("usertools: use sysfs for CPU layout")
Fixes: 63985c5f104e ("usertools: fix CPU layout for more than 2 threads")
Signed-off-by: Thomas Monjalon
---
usertools/cpu_layout.py | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/usertools/cpu_layout.py b/usertools/cpu_layout.py
index 99152a2ec..74da928df 100755
--- a/usertools/cpu_layout.py
+++ b/usertools/cpu_layout.py
@@ -35,6 +35,10 @@
#
from __future__ import print_function
import sys
+try:
+xrange # Python 2
+except NameError:
+xrange = range # Python 3
sockets = []
cores = []
@@ -72,7 +76,7 @@
print("")
max_processor_len = len(str(len(cores) * len(sockets) * 2 - 1))
-max_thread_count = len(core_map.values()[0])
+max_thread_count = len(core_map)
max_core_map_len = (max_processor_len * max_thread_count) \
+ len(", ") * (max_thread_count - 1) \
+ len('[]') + len('Socket ')
@@ -92,7 +96,7 @@
for c in cores:
output = "Core %s" % str(c).ljust(max_core_id_len)
for s in sockets:
-if core_map.has_key((s,c)):
+if (s,c) in core_map:
output += " " + str(core_map[(s, c)]).ljust(max_core_map_len)
else:
output += " " * (max_core_map_len + 1)
--
2.12.2
Re: [dpdk-dev] [PATCH v2 01/13] EAL: count nr_overcommit_hugepages as available
13/12/2016 02:28, Michał Mirosław: > Signed-off-by: Michał Mirosław > --- > lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 43 > ++--- > 1 file changed, 32 insertions(+), 11 deletions(-) There is neither explanation nor comments for this patch. Michal, please check with Sergio (mem maintainer) what can be done.
Re: [dpdk-dev] [PATCH 03/13] rte_ether: set PKT_RX_VLAN_STRIPPED in rte_vlan_strip()
09/02/2017 16:56, Olivier MATZ:
> Hi,
>
> On Mon, 30 Jan 2017 10:54:08 +0100, Thomas Monjalon
> wrote:
> > It is fixing the introduction of the new flag PKT_RX_VLAN_STRIPPED.
> >
> > Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
> >
> > This patch is applying the flag to the software emulation case
> > (currently only for virtio).
> > So the comment of this flag should be changed:
> >
> > /**
> > * A vlan has been stripped by the hardware and its tci is saved in
> > * mbuf->vlan_tci. This can only happen if vlan stripping is enabled
> > * in the RX configuration of the PMD.
> > */
> > #define PKT_RX_VLAN_STRIPPED (1ULL <<
> > 6)
> >
> >
> > > Signed-off-by: Michał Mirosław
> > [...]
> > > --- a/lib/librte_net/rte_ether.h
> > > +++ b/lib/librte_net/rte_ether.h
> > > @@ -357,7 +357,7 @@ static inline int rte_vlan_strip(struct
> > > rte_mbuf *m) return -1;
> > >
> > > struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
> > > - m->ol_flags |= PKT_RX_VLAN_PKT;
> > > + m->ol_flags |= PKT_RX_VLAN_PKT | PKT_RX_VLAN_STRIPPED;
> > > m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
> > >
> > > /* Copy ether header over rather than moving whole packet
> > > */
> >
> > I think this flag should also be removed in the function
> > rte_vlan_insert().
>
> Agree with Thomas, I think rte_vlan_insert() should be updated too.
>
> But I don't think the comment of the mbuf flag should be changed:
> "stripped by the hardware" is a bit ambiguous for virtual drivers, but
> we can understand that for virtual drivers the same work is done in
> software.
No more comment?
Olivier, the author is not replying.
I think we should have updated the patch ourself.
How risky it is for 17.05?
Should it wait for 17.08?
Re: [dpdk-dev] [PATCH] app/testpmd: refine xstats show
08/02/2017 17:30, Thomas Monjalon: > 2017-01-18 09:07, Tan, Jianfeng: > > > > How about "nz" for non-zero? > > > > > > I would prefer the full name. If you want nonzero, that's ok for me, but > > > there > > > is > > > no need to make it shorter and not readable enough (I wouldn't know what > > > nz is). > > > > Make sense. Will send out patch soon. > > Any news? Why this patch is forgotten?
Re: [dpdk-dev] [PATCH] vfio: set IOMMU type for the container once
28/04/2017 15:24, Burakov, Anatoly:
> > From: Andrew Rybchenko [mailto:arybche...@solarflare.com]
> > Sent: Tuesday, April 4, 2017 5:06 PM
> > To: dev@dpdk.org
> > Cc: Burakov, Anatoly ; Alejandro Lucero
> >
> > Subject: [PATCH] vfio: set IOMMU type for the container once
> >
> > If more than one used PCI device belongs to one IOMMU group, it is still one
> > IOMMU group and the container IOMMU type should be set only once.
> >
> > Fixes: 94c0776b1bad ("vfio: support hotplug")
> >
> > Signed-off-by: Andrew Rybchenko
>
> Acked-by: Anatoly Burakov
Applied, thanks
Re: [dpdk-dev] [PATCH] vfio: fix device unplug when several devices per vfio group
28/04/2017 15:25, Burakov, Anatoly:
> From: Alejandro Lucero [mailto:alejandro.luc...@netronome.com]
> > VFIO allows a secure way of assigning devices to user space and those
> > devices which can not be isolated from other ones are set in same VFIO
> > group. Releasing or unplugging a device should be aware of remaining
> > devices is the same group for avoiding to close such a group.
> >
> > Fixes: 94c0776b1bad ("vfio: support hotplug")
> >
> > Signed-off-by: Alejandro Lucero
>
> I have tested this on my setup on an old kernel with multiple
> attach/detaches, and it works (whereas it fails without this patch).
>
> Acked-by: Anatoly Burakov
Applied, thanks
Re: [dpdk-dev] [PATCH dpdk v2] vfio/ppc64/spapr: Use correct structures for add/remove windows
26/04/2017 10:15, Burakov, Anatoly: > > > > If Linux UAPI headers in the system do not have > > VFIO_SPAPR_TCE_v2_IOMMU defined, DPDK define necessary structures > > itself. However the existing definitions are different from ones pushed to > > the mainline kernel. > > > > This copies structures passed via VFIO_IOMMU_SPAPR_TCE_CREATE and > > VFIO_IOMMU_SPAPR_TCE_REMOVE ioctls. > > > > No change in behaviour is expected if installed linux UAPI headers have > > knowledge of VFIO_SPAPR_TCE_v2_IOMMU. > > > > Signed-off-by: Alexey Kardashevskiy > > That was quite an oversight on my part!.. > > Acked-by: Anatoly Burakov Applied, thanks
Re: [dpdk-dev] [PATCH v2] mbuf: fix 64bit address alignment in 32-bit builds
28/04/2017 15:10, Bruce Richardson:
> On i686 builds, the uin64_t type is 64-bits in size but is aligned to
> 32-bits only. This causes mbuf fields for rearm_data to not be 16-byte
> aligned on 32-bit builds, which causes errors with some vector PMDs which
> expect the rearm data to be aligned as on 64-bit.
>
> Given that we cannot use the extra space in the data structures anyway, as
> it's already used on 64-bit builds, we can just force alignment of the
> physical address in the mbuf to 8-bytes in all cases. This has no effect on
> 64-bit systems, but fixes the updated PMDs on 32-bit.
>
> Fixes: f4356d7ca168 ("net/i40e: eliminate mbuf write on rearm")
> Fixes: f160666a1073 ("net/ixgbe: eliminate mbuf write on rearm")
>
> Signed-off-by: Bruce Richardson
> ---
> v2: change alignment fix from being for all phys_addr_t vars to just
> the one in the mbuf structure. This is a lower risk fix. Additional
> patches promised to put in build-checks for alignment in vpmds will
> be sent separately.
Applied, thanks
Re: [dpdk-dev] [PATCH] mk: use extra cflags when linking apps with the compiler
25/04/2017 18:10, Gage Eads: > From: John Jacques > > When using the compiler to link applications, include EXTRA_CFLAGS. This > is needed, for example, when cross-compiling, to pass --sysroot. > GCC cross-compilers built with Yocto don't use the --with-sysroot option, > making it necessary to pass --sysroot command-line option. > > Signed-off-by: John Jacques > Signed-off-by: Gage Eads Applied, thanks
Re: [dpdk-dev] [PATCH] mk: fix external builds with relative output dir
26/04/2017 23:01, Jan Blunck: > In case the output directory (O=) is undefined or a relative directory lets > turn it into an absolute path before passing it on. Otherwise the output > directory is created relative to the subdir, e.g. pktgen/app/build/... and > pktgen/lib/lua/src/build/... > > Signed-off-by: Jan Blunck Applied, thanks
Re: [dpdk-dev] 答复: [PATCH] config: support 16 sockets server
19/04/2017 11:49, Ananyev, Konstantin: > > > > > We has already test on 16 node server, everything is fine, without any > > issue. > > > > Testcase as follows: > > I. with dpdk args -c 0xf, test pass > > II. with 32 forward-lcores, each node with 2 lcores(total 16 nodes), test > > pass > > III. with forward lcore id greater than 128, test pass > > IV. with forward and master lcore on node 15, test pass > > > > That's really great to hear, but why default config have to be updated? > Most people don't run dpdk on such powerful boxes, so for them > increasing these config values would be just waste of space. > Why not create your own config instead? I agree. The default config should not set the maximum values for the biggest machines. Rejected
Re: [dpdk-dev] [PATCH] config: set cache line as 128B in the generic arm64 config
28/04/2017 04:14, Jianbo Liu: > On 27 April 2017 at 00:29, Jerin Jacob wrote: > > armv8 implementations may have 64B or 128B cache line. > > Setting to the maximum available cache line size in generic config to > > address minimum DMA alignment across all arm64 implementations. > > > > Increasing the cacheline size has no negative impact to cache invalidation > > on systems with a smaller cache line. > > > > The need for the minimum DMA alignment has impact on functional aspects > > of the platform so default config should cater the functional aspects. > > > > There is an impact on memory usage with this scheme, but that's not too > > important for the single image arm64 distribution use case. > > > > The arm64 linux kernel followed the similar approach for single > > arm64 image use case. > > http://lxr.free-electrons.com/source/arch/arm64/include/asm/cache.h > > > > Signed-off-by: Jerin Jacob > > Acked-by: Jianbo Liu Applied, thanks
Re: [dpdk-dev] [PATCH v2] config: make AVX and AVX512 configurable
28/04/2017 04:08, Yang, Zhiyong: > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Zhihong Wang > > > > Making AVX and AVX512 configurable is useful for performance and power > > testing. > > > > The similar kernel patch at https://patchwork.kernel.org/patch/9618883/. > > > > AVX512 support like in rte_memcpy has been in DPDK since 16.04, but it's > > still > > unproven in rich use cases in hardware. Therefore it's marked as > > experimental > > for now, will enable it after enough field test and possible optimization. > > > > Signed-off-by: Zhihong Wang > > Reviewed-by: Zhiyong Yang Applied, thanks
Re: [dpdk-dev] [PATCH v3 00/14] Fixes for exported headers
26/04/2017 14:07, Adrien Mazarguil: > This series addresses the remaining issues seen by check-includes.sh in > exported headers. Most of them may cause compilation errors in user > applications: > > - Dependencies on missing includes. > - Non-standard C/C++ constructs usage without associated safeties. > - Missing C++ awareness blocks. > > It also addresses the incomplete implementation of E-Tag and NVGRE flow API > pattern items. Applied, thanks
Re: [dpdk-dev] [dpdk-stable] [PATCH] lib/librte_cmdline: fix CLI parsing issue
28/04/2017 11:13, Olivier Matz:
> Hi Wenzhuo,
>
> On Fri, 28 Apr 2017 08:38:21 +, "Lu, Wenzhuo"
> wrote:
> > Hi Oilvier,
> > As we discussed before, I send this patch. Would you like to take a look at
> > it? Better fix it before release 17.05, thanks.
> >
> >
> > > When parsing a CLI, all the CLI instances are checked one by one. Even if
> > > an
> > > instance already matches the CLI, the parsing will not stop for ambiguous
> > > check.
> > > The problem is that the following check may change the parsing result of
> > > the
> > > previous one even if the following instance doesn't match.
> > >
> > > Use a temporary validate for the parsing result when trying to match an
> > > instance and only store the result when it matches, so the previous result
> > > has no chance to be changed.
> > >
> > > Fixes: af75078fece3 ("first public release")
> > > CC: sta...@dpdk.org
> > >
> > > Signed-off-by: Wenzhuo Lu
>
> Sorry for the delay,
>
> Acked-by: Olivier Matz
Applied, thanks
Re: [dpdk-dev] [PATCH] doc: correct the hugepage limitation of 32 bit
> > The hugepage memory limitation of 32 bit application is "1GB size" but not > > "1GB per page size". > > > > Signed-off-by: Qi Zhang > > Thanks for the correction. > > Acked-by: John McNamara Applied, thanks
Re: [dpdk-dev] [PATCH v2 4/4] devtools: add git log checks for rmv
25/04/2017 12:18, Gaetan Rivet: > Signed-off-by: Gaetan Rivet > --- > devtools/check-git-log.sh | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/devtools/check-git-log.sh b/devtools/check-git-log.sh > index 8449d4f..f081ff5 100755 > --- a/devtools/check-git-log.sh > +++ b/devtools/check-git-log.sh > @@ -132,6 +132,7 @@ bad=$(echo "$headlines" | grep -E --color=always \ > -e ':.*\' \ > -e ':.*\' \ > -e ':.*\' \ > + -e ':.*\' \ > -e ':.*\' \ > -e ':.*\' \ > -e ':.*\<[Vv]lan\>' \ rmv is not an acronym. I think there is no need to enforce uppercases.
Re: [dpdk-dev] [PATCH v2 1/4] doc: fix missing backquotes
26/04/2017 16:58, Mcnamara, John:
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Gaetan Rivet
> > Sent: Tuesday, April 25, 2017 11:18 AM
> > To: dev@dpdk.org
> > Cc: Yigit, Ferruh
> > Subject: [dpdk-dev] [PATCH v2 1/4] doc: fix missing backquotes
> >
> > Fixes: ea85e7d711b6 ("ethdev: retrieve xstats by ID")
> >
> > Signed-off-by: Gaetan Rivet
>
> Thanks. Could you also make the V1 patches as "superseded" in patchwork.
>
> Acked-by: John McNamara
Series applied, except patch 4/4 which is superfluous.
Re: [dpdk-dev] [PATCH v5 0/3] MAC address fail to be added shouldn't be stored
30/04/2017 06:11, Wei Dai: > Current ethdev always stores MAC address even it fails to be added. > Other function may regard the failed MAC address valid and lead to > some errors. So There is a need to check if the addr is added > successfully or not and discard it if it fails. > > In 3rd patch, add a command "add_more_mac_addr port_id base_mac_addr count" > to add more than one MAC address one time. > This command can simplify the test for the first patch. > Normally a MAC address may fails to be added only after many MAC > addresses have been added. > Without this command, a tester may only trigger failed MAC address > by running many times of testpmd command 'mac_addr add' . > > For v4 patch set, have got acknowledgement from > Nelio Laranjeiro for mlx changes > Yuanhan Liu for virtio changes You have not taken the ack from Konstantin, and you have again forgot --in-reply-to, so review is hard. Checkpatch reports: ERROR:EXECUTE_PERMISSIONS: do not set execute permissions for source files Please make a perfect v6.
Re: [dpdk-dev] [PATCH] usertools: fix CPU layout with python 3
On Sunday 30 April 2017 07:41 PM, Thomas Monjalon wrote:
These differences in Python 3 were causing errors:
- xrange is replaced by range
- dict values are a view (instead of list)
- has_key is removed
Thanks Thomas.
Please include minor correction in your patch as below.
Fixes: deb87e6777c0 ("usertools: use sysfs for CPU layout")
Fixes: 63985c5f104e ("usertools: fix CPU layout for more than 2 threads")
Signed-off-by: Thomas Monjalon
---
usertools/cpu_layout.py | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/usertools/cpu_layout.py b/usertools/cpu_layout.py
index 99152a2ec..74da928df 100755
--- a/usertools/cpu_layout.py
+++ b/usertools/cpu_layout.py
@@ -35,6 +35,10 @@
#
from __future__ import print_function
import sys
+try:
+xrange # Python 2
+except NameError:
+xrange = range # Python 3
sockets = []
cores = []
@@ -72,7 +76,7 @@
print("")
max_processor_len = len(str(len(cores) * len(sockets) * 2 - 1))
-max_thread_count = len(core_map.values()[0])
+max_thread_count = len(core_map)
We need to retain thread count calculated from any of core_map values
(index 0 as in patch),
hence keeping ljust() in output same as w/o this change. So,
max_thread_count = len(list(core_map.values())[0])
Above list() ensures return values are in list always irrespective of
python 2x / 3x.
Regards,
Gowrishankar
max_core_map_len = (max_processor_len * max_thread_count) \
+ len(", ") * (max_thread_count - 1) \
+ len('[]') + len('Socket ')
@@ -92,7 +96,7 @@
for c in cores:
output = "Core %s" % str(c).ljust(max_core_id_len)
for s in sockets:
-if core_map.has_key((s,c)):
+if (s,c) in core_map:
output += " " + str(core_map[(s, c)]).ljust(max_core_map_len)
else:
output += " " * (max_core_map_len + 1)
[dpdk-dev] [PATCH] net/thunderx: add compile-time checks
The thunderx PMD is sensitive to the layout of the mbuf on the RX path. Add in some compile-time checks to make sure the mbuf layout assumptions are valid, and to provide hints to anyone changing the mbuf where things may need to be updated. Signed-off-by: Jerin Jacob --- - As previously discussed*, add some compile time checks to the pmds to help sanity-check their dependencies on the mbuf layout. * http://dpdk.org/ml/archives/dev/2017-April/064988.html - Targeted for v17.08 --- drivers/net/thunderx/nicvf_ethdev.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c index e4910c9b3..ddcfabaf7 100644 --- a/drivers/net/thunderx/nicvf_ethdev.c +++ b/drivers/net/thunderx/nicvf_ethdev.c @@ -1239,6 +1239,13 @@ nicvf_rxq_mbuf_setup(struct nicvf_rxq *rxq) struct rte_mbuf mb_def; RTE_BUILD_BUG_ON(sizeof(union mbuf_initializer) != 8); + RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, data_off) % 8 != 0); + RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, refcnt) - + offsetof(struct rte_mbuf, data_off) != 2); + RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, nb_segs) - + offsetof(struct rte_mbuf, data_off) != 4); + RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, port) - + offsetof(struct rte_mbuf, data_off) != 6); mb_def.nb_segs = 1; mb_def.data_off = RTE_PKTMBUF_HEADROOM; mb_def.port = rxq->port_id; -- 2.12.2
[dpdk-dev] [PATCH] doc: announce ABI change on ethdev
This is an ABI change notice for DPDK 17.08 in librte_ether about changes in rte_eth_txmode structure. Currently Tx offloads are enabled by default, and can be disabled using ETH_TXQ_FLAGS_NO* flags. This behaviour is not consistent with the Rx side where the Rx offloads are disabled by default and enabled according to bit field in rte_eth_rxmode structure. The proposal is to disable the Tx offloads by default, and provide a way for the application to enable them in rte_eth_txmode structure. Besides of making the Tx configuration API more consistent for applications, PMDs will be able to provide a better out of the box performance. Finally, as part of the work, the ETH_TXQ_FLAGS_NO* will be superseded as well. Signed-off-by: Shahaf Shuler --- looks like this patch has arrived to everyone besides dev@dpdk.org resending it again. sorry for the noise. --- doc/guides/rel_notes/deprecation.rst | 8 1 file changed, 8 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index a3e7c720c..0920b4766 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -81,3 +81,11 @@ Deprecation Notices - ``rte_crpytodev_scheduler_mode_get``, replaced by ``rte_cryptodev_scheduler_mode_get`` - ``rte_crpytodev_scheduler_mode_set``, replaced by ``rte_cryptodev_scheduler_mode_set`` + +* ethdev: in 17.08 ABI changes are planned: + Tx offloads will no longer be enabled by default. + Instead, the ``rte_eth_txmode`` structure will be extended with bit field to enable + each Tx offload. + Besides of making the Rx/Tx configuration API more consistent for the + application, PMDs will be able to provide a better out of the box performance. + as part of the work, ``ETH_TXQ_FLAGS_NO*`` will be superseded as well. -- 2.12.0
