[dpdk-dev] [PATCH v1] doc: update release notes for mlx driver
Signed-off-by: Raslan Darawsheh --- doc/guides/rel_notes/release_17_11.rst | 146 + 1 file changed, 146 insertions(+) diff --git a/doc/guides/rel_notes/release_17_11.rst b/doc/guides/rel_notes/release_17_11.rst index c7d8826..37ff3ba 100644 --- a/doc/guides/rel_notes/release_17_11.rst +++ b/doc/guides/rel_notes/release_17_11.rst @@ -624,3 +624,149 @@ Tested Platforms This section is a comment. do not overwrite or remove it. Also, make sure to start the actual text at the margin. = + +* Intel(R) platforms with Mellanox(R) NICs combinations + + * Platform details: + + * Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz + * Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz + * Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz + * Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz + * Intel(R) Xeon(R) CPU E5-2640 @ 2.50GHz + * Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz + + * OS: + + * Red Hat Enterprise Linux Server release 7.3 (Maipo) + * Red Hat Enterprise Linux Server release 7.2 (Maipo) + * Ubuntu 16.10 + * Ubuntu 16.04 + * Ubuntu 14.04 + + * MLNX_OFED: 4.2-1.0.0.0 + + * NICs: + + * Mellanox(R) ConnectX(R)-3 Pro 40G MCX354A-FCC_Ax (2x40G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1007 + * Firmware version: 2.42.5000 + + * Mellanox(R) ConnectX(R)-4 10G MCX4111A-XCAT (1x10G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.21.1000 + + * Mellanox(R) ConnectX(R)-4 10G MCX4121A-XCAT (2x10G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.21.1000 + + * Mellanox(R) ConnectX(R)-4 25G MCX4111A-ACAT (1x25G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.21.1000 + + * Mellanox(R) ConnectX(R)-4 25G MCX4121A-ACAT (2x25G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.21.1000 + + * Mellanox(R) ConnectX(R)-4 40G MCX4131A-BCAT/MCX413A-BCAT (1x40G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.21.1000 + + * Mellanox(R) ConnectX(R)-4 40G MCX415A-BCAT (1x40G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1013 + * Firmware version: 12.21.1000 + + * Mellanox(R) ConnectX(R)-4 50G MCX4131A-GCAT/MCX413A-GCAT (1x50G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.21.1000 + + * Mellanox(R) ConnectX(R)-4 50G MCX414A-BCAT (2x50G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.21.1000 + + * Mellanox(R) ConnectX(R)-4 50G MCX415A-GCAT/MCX416A-BCAT/MCX416A-GCAT + (2x50G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1013 + * Firmware version: 12.21.1000 + + * Mellanox(R) ConnectX(R)-4 50G MCX415A-CCAT (1x100G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1013 + * Firmware version: 12.21.1000 + + * Mellanox(R) ConnectX(R)-4 100G MCX416A-CCAT (2x100G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1013 + * Firmware version: 12.21.1000 + + * Mellanox(R) ConnectX(R)-4 Lx 10G MCX4121A-XCAT (2x10G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1015 + * Firmware version: 14.21.1000 + + * Mellanox(R) ConnectX(R)-4 Lx 25G MCX4121A-ACAT (2x25G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1015 + * Firmware version: 14.21.1000 + + * Mellanox(R) ConnectX(R)-5 100G MCX556A-ECAT (2x100G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1017 + * Firmware version: 16.21.1000 + + * Mellanox(R) ConnectX-5 Ex EN 100G MCX516A-CDAT (2x100G) + + * Host interface: PCI Express 4.0 x16 + * Device ID: 15b3:1019 + * Firmware version: 16.21.1000 + +* ARM platforms with Mellanox(R) NICs combinations + + * Platform details: + +* Qualcomm ARM 1.1 2500MHz + + * OS: + + * Ubuntu 16.04 + + * MLNX_OFED: 4.2-1.0.0.0 + + * NICs: + + * Mellanox(R) ConnectX(R)-4 Lx 25G MCX4121A-ACAT (2x25G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1015 + * Firmware version: 14.21.1000 + + * Mellanox(R) ConnectX(R)-5 100G MCX556A-ECAT (2x100G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1017 + * Firmware version: 16.21.1000 -- 2.7.4
[dpdk-dev] [PATCH v1] net/mlx4: store RSS hash result in mbufs
Add RSS hash result from CQE to mbuf,
Also, set PKT_RX_RSS_HASH in the ol_flags.
Signed-off-by: Raslan Darawsheh
---
drivers/net/mlx4/mlx4_rxtx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mlx4/mlx4_rxtx.c b/drivers/net/mlx4/mlx4_rxtx.c
index 2bfa8b1..5bc9874 100644
--- a/drivers/net/mlx4/mlx4_rxtx.c
+++ b/drivers/net/mlx4/mlx4_rxtx.c
@@ -964,7 +964,8 @@ mlx4_rx_burst(void *dpdk_rxq, struct rte_mbuf **pkts,
uint16_t pkts_n)
/* Update packet information. */
pkt->packet_type =
rxq_cq_to_pkt_type(cqe, rxq->l2tun_offload);
- pkt->ol_flags = 0;
+ pkt->ol_flags = PKT_RX_RSS_HASH;
+ pkt->hash.rss = cqe->immed_rss_invalid;
pkt->pkt_len = len;
if (rxq->csum | rxq->csum_l2tun) {
uint32_t flags =
--
2.7.4
Re: [dpdk-dev] [dpdk-stable] [PATCH v6] ring: guarantee load/load order in enqueue and dequeue
10/11/2017 04:30, Jia He:
> We watched a rte panic of mbuf_autotest in our qualcomm arm64 server
> (Amberwing).
>
> Root cause:
> In __rte_ring_move_cons_head()
> ...
> do {
> /* Restore n as it may change every loop */
> n = max;
>
> *old_head = r->cons.head;//1st load
> const uint32_t prod_tail = r->prod.tail; //2nd load
>
> In weak memory order architectures(powerpc,arm), the 2nd load might be
> reodered before the 1st load, that makes *entries is bigger than we wanted.
> This nasty reording messed enque/deque up.
>
> cpu1(producer) cpu2(consumer) cpu3(consumer)
> load r->prod.tail
> in enqueue:
> load r->cons.tail
> load r->prod.head
>
> store r->prod.tail
>
> load r->cons.head
> load r->prod.tail
> ...
> store r->cons.{head,tail}
> load r->cons.head
>
> Then, r->cons.head will be bigger than prod_tail, then make *entries very
> big and the consumer will go forward incorrectly.
>
> After this patch, the old cons.head will be recaculated after failure of
> rte_atomic32_cmpset
>
> There is no such issue on X86, because X86 is strong memory order model.
> But rte_smp_rmb() doesn't have impact on runtime performance on X86, so
> keep the same code without architectures specific concerns.
>
> Signed-off-by: Jia He
> Signed-off-by: jie2@hxt-semitech.com
> Signed-off-by: bing.z...@hxt-semitech.com
> Acked-by: Jerin Jacob
> Acked-by: Jianbo Liu
> Cc: sta...@dpdk.org
Applied, thanks
Re: [dpdk-dev] [PATCH] net/virtio: init MTU in case no control channel
07/11/2017 04:44, Yuanhan Liu: > On Wed, Oct 25, 2017 at 08:09:06PM -0700, wangzhike wrote: > > The max_mtu is kept as zero in case no CRTL channel, which leads > > to failure when calling virtio_mtu_set(). > > > > Signed-off-by: wangzhike > > Acked-by: Yuanhan Liu Sorry, it cannot be applied without the real name of the author.
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/virtio: fix memory leak
01/11/2017 16:33, Yuanhan Liu:
> On Fri, Oct 27, 2017 at 11:54:09AM +0800, Pengzhen Liu wrote:
> > In function eth_virtio_dev_init(), dynamic memory stored
> > in "eth_dev->data->mac_addrs" variable and it is not freed
> > when function return,
> > this is a possible memory leak.
> >
> > Fixes: 8ced1542f7a3 ("net/virtio: eth_dev->data->mac_addrs is not freed")
> > Cc: sta...@dpdk.org
> > Signed-off-by: Pengzhen Liu
>
> Acked-by: Yuanhan Liu
Applied, thanks
Re: [dpdk-dev] [PATCH] testpmd: add nanosleep in main loop
> -Original Message- > From: Marcelo Tosatti [mailto:mtosa...@redhat.com] > Sent: Saturday, November 11, 2017 3:50 AM > To: Ananyev, Konstantin > Cc: Adrien Mazarguil ; dev@dpdk.org; Luiz > Capitulino ; Daniel Bristot de Oliveira > > Subject: Re: [dpdk-dev] [PATCH] testpmd: add nanosleep in main loop > > On Fri, Nov 10, 2017 at 10:14:23AM +, Ananyev, Konstantin wrote: > > > > > > > -Original Message- > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Adrien Mazarguil > > > Sent: Friday, November 10, 2017 9:12 AM > > > To: Marcelo Tosatti > > > Cc: dev@dpdk.org; Luiz Capitulino ; Daniel > > > Bristot de Oliveira > > > Subject: Re: [dpdk-dev] [PATCH] testpmd: add nanosleep in main loop > > > > > > Hi Marcelo, > > > > > > On Fri, Nov 10, 2017 at 04:02:10AM -0200, Marcelo Tosatti wrote: > > > > > > > > This patch allows a configurable pair of values to be set, which > > > > controls > > > > the frequency and length of a nanosleep call performed at test-pmd's > > > > iofwd main loop. > > > > > > > > The problem is the following: it is necessary to execute code > > > > on isolated CPUs which is not part of the packet forwarding load. > > > > > > > > For example: > > > > > > > > "echo val > /sys/kernel/debug/tracing/buffer_size_kb" > > > > > > > > hangs the process, because the DPDK thread has higher > > > > priority than the workqueue thread which executes the flush from > > > > CPU local tracebuffer to CPU global trace buffer [the workitem > > > > in case]. > > > > > > > > There are more serious issues than the trace-cmd bug, such as XFS > > > > workitems failing to execute causing filesystem corruption. > > > > > > > > To workaround this problem, until a proper kernel > > > > solution is developed, allow DPDK to nanosleep > > > > (hopefully with a small enough frequency and interval > > > > so that the performance is within acceptable levels). > > > > > > I understand the need to do something about it, however the nanosleep() > > > approach seems questionable to me. > > > > > > Testpmd's forwarding modes (particularly I/O) are used for benchmarking > > > purposes by many and are therefore sensitive to change. This code path is > > > currently free from system calls for that reason and nanosleep() is an > > > expensive one by definition. Even if optional or called at a low > > > frequency, > > > the presence of this new code has an impact. > > > > > > Since testpmd is a development tool not supposed to run in a production > > > environment, is there really a need for it to be patched to work around a > > > (temporary) Linux kernel bug? > > > > > > If so, why is I/O the only forwarding mode impacted? > > > > > > If it's used in a production environment and such a fix can't wait, have > > > other workarounds been considered: > > > > > > - Replacing testpmd in I/O mode with a physical cable or switch? > > > > > > - Using proper options on the kernel command line as described in [1], > > > such > > > as isolcpus, rcu_nocbs, nohz_full? > > > > > > [1] doc/guides/howto/pvp_reference_benchmark.rst > > > > > > Agree with Adrian here - the patch doesn't fix the problem in any case, > > It does fix the problem as the original message describes the testing. If the user will run testpmd with different fwd mode (macfwd, csum, txonly, etc.) - he would hit exactly the same problem. If the user would run any other of DPDK sample applications (l2fwd, l3fwd, etc.) - he would hit the same problem again. If some of DPDK customers have a busy loop inside their production system - they would hit that problem too. As I understand - that problem is even not DPDK related - any application that uses busy loop inside can be affected. Correct? So I think the patch doesn't fix the problem, all it does - helps to avoid particular manifestation of it. BTW, if it is a generic kernel problem - I suppose there should be some record in kernel bugzilla to track it, right? If so, could you probably provide some reference to it? >From other side - testpmd is not a production app - as the name implies it is a tool to test PMDs functionality and performance. Specially iofwd is sort of synthetic benchmark that allows to measure highest possible PMD performance. That's why I think many people (and me too) would prefer to keep it intact and free from any system calls. If you are that desperate to provide some workaround sepcially for testpmd - my suggestion would be to introduce new fwd mode here that would call nanosleep() periodically, while keeping original iofwd mode intact. > > > while introducing an unnecessary slowdown in testpmd iofwd mode. > > It is not unnecessary: it is a mandatory slowdown for any approach > which fixes the problem, whether it's in DPDK or not. dpdk runs on other OSes too (freebsd). For non-linux users it definetly looks like an unnecessary one. > > > Please think up some other approach. > > Konstantin > > What characteristics are you looking for in "some other
Re: [dpdk-dev] [PATCH v1] doc: update release notes for mlx driver
12/11/2017 15:27, Raslan Darawsheh: > Signed-off-by: Raslan Darawsheh Applied, thanks
Re: [dpdk-dev] [PATCH] bus/pci: fix bsd doxygen file description
12/11/2017 08:56, Jerin Jacob:
> Fixes: 764bf26873b9 ("add FreeBSD support")
>
> Signed-off-by: Jerin Jacob
Applied, thanks
Re: [dpdk-dev] [PATCH] lib/librte_eal: Fix typos
10/11/2017 09:24, Pavel Shirshov: > Signed-off-by: Pavel Shirshov Merged with a lot of other typo fixes, thanks Have you used a tool to find these typos?
Re: [dpdk-dev] [PATCH] usertools/dpdk-devbind.py: Fix a typo
10/11/2017 09:21, Pavel Shirshov: > Signed-off-by: Pavel Shirshov Applied, thanks
Re: [dpdk-dev] [PATCH] doc: fix an error in DPDK programmers's guide (EAL)
> > Fix an error in DPDK programmer's guide (EAL section): it should be > > rte_thread_get_affinity() instead of rte_pthread_get_affinity(). > > > > Signed-off-by: Rami Rosen > > Acked-by: John McNamara Applied, thanks
Re: [dpdk-dev] [PATCH] doc: fix a typo in ip pipeline app guide
> > This patch fixes a trivial typo in ip pipeline app guide. > > > > Signed-off-by: Rami Rosen > > Acked-by: John McNamara Applied, thanks
Re: [dpdk-dev] DPDK memory error check and offline bad pages
Anyone has any idea on this? Can’t believe DPDK doesn’t support such an important feature. This is going to be a show stopper for real production system. -Jianjian On 11/7/17, 1:13 PM, "Jianjian Huo" wrote: Hi dpdk developers, I have a question regarding how DPDK memory module treats memory errors. In Linux kernel, it has mechanism (mcelog and EDAC) to monitor the memory controller and report correctable/uncorrectable memory errors. Using some configurations, if memory errors exceed threshold, system can offline bad memory pages and avoid applications to access/crash. Do we have similar mechanism in DPDK? Thanks, Jianjian
[dpdk-dev] [dpdk-announce] release candidate 17.11-rc4
A new DPDK release candidate is ready for testing: http://dpdk.org/browse/dpdk/tag/?id=v17.11-rc4 The release notes should be closed now: http://dpdk.org/doc/guides/rel_notes/release_17_11.html There are few tricky fixes in this last release candidate which need to be tested before the announcing the release. Please test carefully, thank you.
Re: [dpdk-dev] DPDK memory error check and offline bad pages
Hi Jianjian, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jianjian Huo > Sent: Wednesday, November 8, 2017 5:13 AM > To: dev@dpdk.org > Subject: [dpdk-dev] DPDK memory error check and offline bad pages > > Hi dpdk developers, > > I have a question regarding how DPDK memory module treats memory > errors. You mean hardware error which cannot be fixed by ECC? > > In Linux kernel, it has mechanism (mcelog and EDAC) to monitor the memory > controller and report correctable/uncorrectable memory errors. Using some > configurations, if memory errors exceed threshold, system can offline bad > memory pages and avoid applications to access/crash. DPDK app is just one of applications. Are there any framework to notify such error to applications? To notify is the first thing, to recover is another thing which takes more effort. > Do we have similar mechanism in DPDK? No, as far as I know. Thanks, Jianfeng > > Thanks, > Jianjian >
