[dpdk-stable] patch 'mk: fix quoting for ARM mtune argument' has been queued to LTS release 16.11.2

[dpdk-stable] patch 'mk: fix quoting for ARM mtune argument' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 16d69788647ad9406d8ce2e0c9c42414993406f5 Mon Sep 17 00:00:00 2001
From: Pascal Mazon <pascal.mazon@6wind.com>
Date: Mon, 10 Apr 2017 14:18:51 +0200
Subject: [PATCH] mk: fix quoting for ARM mtune argument
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

[ upstream commit be1d4e8564d34312f624781678c884a61e35f3b8 ]

The mtune argument needs an unquoted argument, otherwise the compiler
complains:

  arm-buildroot-linux-gnueabi-gcc.br_real: error:
    unrecognized argument in option ‘-mtune="cortex-a9"’

Fixes: 02a8686263de ("mk: introduce ARMv7 architecture")
Fixes: 4a7e4626975a ("mk: introduce NXP dpaa2 architecture based on armv8-a")

Reported-by: Jan Viktorin <viktorin@rehivetech.com>
Signed-off-by: Pascal Mazon <pascal.mazon@6wind.com>
Tested-by: Jan Viktorin <viktorin@rehivetech.com>
---
 mk/machine/armv7a/rte.vars.mk | 2 +-
 mk/machine/dpaa2/rte.vars.mk  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/mk/machine/armv7a/rte.vars.mk b/mk/machine/armv7a/rte.vars.mk
index 36fa3de..41c4c40 100644
--- a/mk/machine/armv7a/rte.vars.mk
+++ b/mk/machine/armv7a/rte.vars.mk
@@ -57,7 +57,7 @@
 MACHINE_CFLAGS += -march=armv7-a
 
 ifdef CONFIG_RTE_ARCH_ARM_TUNE
-MACHINE_CFLAGS += -mtune=$(CONFIG_RTE_ARCH_ARM_TUNE)
+MACHINE_CFLAGS += -mtune=$(CONFIG_RTE_ARCH_ARM_TUNE:"%"=%)
 endif
 
 MACHINE_CFLAGS += -mfpu=neon
diff --git a/mk/machine/dpaa2/rte.vars.mk b/mk/machine/dpaa2/rte.vars.mk
index 8541633..61ada89 100644
--- a/mk/machine/dpaa2/rte.vars.mk
+++ b/mk/machine/dpaa2/rte.vars.mk
@@ -56,5 +56,5 @@
 MACHINE_CFLAGS += -march=armv8-a
 
 ifdef CONFIG_RTE_ARCH_ARM_TUNE
-MACHINE_CFLAGS += -mcpu=$(CONFIG_RTE_ARCH_ARM_TUNE)
+MACHINE_CFLAGS += -mcpu=$(CONFIG_RTE_ARCH_ARM_TUNE:"%"=%)
 endif
-- 
1.9.0

[dpdk-stable] patch 'net/cxgbe: fix possible null pointer dereference' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 3e10f568be1d33ffecbb29e9c4584dc6cc20f10e Mon Sep 17 00:00:00 2001
From: Henry Cai <caihe@huawei.com>
Date: Tue, 28 Mar 2017 15:32:20 +0800
Subject: [PATCH] net/cxgbe: fix possible null pointer dereference

[ upstream commit 4a8f7cdd2281c7d904eae5b5ee92e4214e945e51 ]

Check return value of malloc.

Fixes: 3bd122eef2cc ("cxgbe/base: add hardware API for Chelsio T5 series adapters")

Signed-off-by: Henry Cai <caihe@huawei.com>
Acked-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
---
 drivers/net/cxgbe/base/t4_hw.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/cxgbe/base/t4_hw.c b/drivers/net/cxgbe/base/t4_hw.c
index c089b06..9dca8da 100644
--- a/drivers/net/cxgbe/base/t4_hw.c
+++ b/drivers/net/cxgbe/base/t4_hw.c
@@ -359,6 +359,9 @@ int t4_wr_mbox_meat_timeout(struct adapter *adap, int mbox,
 	struct mbox_entry entry;
 	u32 pcie_fw = 0;
 
+	if (!temp)
+		return -ENOMEM;
+
 	if ((size & 15) || size > MBOX_LEN) {
 		free(temp);
 		return -EINVAL;
-- 
1.9.0

[dpdk-stable] patch 'net/i40e: fix allocation check' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 35bccc41273a770afbda009fa195b3da0c4af265 Mon Sep 17 00:00:00 2001
From: Henry Cai <caihe@huawei.com>
Date: Wed, 5 Apr 2017 21:19:53 +0800
Subject: [PATCH] net/i40e: fix allocation check

[ upstream commit 1cbeaa0eadbbc228a78e930ffdaa603eff4ff2ec ]

function i40evf_add_del_all_mac_addr without check return
value of rte_zmalloc

Fixes: 97ac72aa71a9 ("i40e: support setting VF MAC address")

Signed-off-by: Henry Cai <caihe@huawei.com>
Acked-by: Helin Zhang <helin.zhang@intel.com>
---
 drivers/net/i40e/i40e_ethdev_vf.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
index 640d316..9618dd5 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1997,6 +1997,10 @@ i40evf_add_del_all_mac_addr(struct rte_eth_dev *dev, bool add)
 		}
 
 		list = rte_zmalloc("i40evf_del_mac_buffer", len, 0);
+		if (!list) {
+			PMD_DRV_LOG(ERR, "fail to allocate memory");
+			return;
+		}
 
 		for (i = begin; i < next_begin; i++) {
 			addr = &dev->data->mac_addrs[i];
-- 
1.9.0

[dpdk-stable] patch 'net/i40e: fix VF link speed' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 4f34cefcf0a4ee72ae68f130f43bec239929ed2f Mon Sep 17 00:00:00 2001
From: Qi Zhang <qi.z.zhang@intel.com>
Date: Sun, 9 Apr 2017 14:05:05 -0400
Subject: [PATCH] net/i40e: fix VF link speed

[ upstream commit e5d85d36d2a0910d13dfdf98394ccc3c27f6b61c ]

When PF notify link speed to VF, encode of link speed need to
be converted from ETH_SPEED_XXX to I40E_LINK_SPEED_XXX.

Fixes: bb6722fb5c0e ("net/i40e: fix VF bonded device link down")

Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
---
 drivers/net/i40e/i40e_pf.c | 29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
index 97b8ecc..b36d901 100644
--- a/drivers/net/i40e/i40e_pf.c
+++ b/drivers/net/i40e/i40e_pf.c
@@ -907,8 +907,33 @@ i40e_notify_vf_link_status(struct rte_eth_dev *dev, struct i40e_pf_vf *vf)
 	event.event = I40E_VIRTCHNL_EVENT_LINK_CHANGE;
 	event.event_data.link_event.link_status =
 		dev->data->dev_link.link_status;
-	event.event_data.link_event.link_speed =
-		(enum i40e_aq_link_speed)dev->data->dev_link.link_speed;
+
+	/* need to convert the ETH_SPEED_xxx into I40E_LINK_SPEED_xxx */
+	switch (dev->data->dev_link.link_speed) {
+	case ETH_SPEED_NUM_100M:
+		event.event_data.link_event.link_speed = I40E_LINK_SPEED_100MB;
+		break;
+	case ETH_SPEED_NUM_1G:
+		event.event_data.link_event.link_speed = I40E_LINK_SPEED_1GB;
+		break;
+	case ETH_SPEED_NUM_10G:
+		event.event_data.link_event.link_speed = I40E_LINK_SPEED_10GB;
+		break;
+	case ETH_SPEED_NUM_20G:
+		event.event_data.link_event.link_speed = I40E_LINK_SPEED_20GB;
+		break;
+	case ETH_SPEED_NUM_25G:
+		event.event_data.link_event.link_speed = I40E_LINK_SPEED_25GB;
+		break;
+	case ETH_SPEED_NUM_40G:
+		event.event_data.link_event.link_speed = I40E_LINK_SPEED_40GB;
+		break;
+	default:
+		event.event_data.link_event.link_speed =
+			I40E_LINK_SPEED_UNKNOWN;
+		break;
+	}
+
 	i40e_pf_host_send_msg_to_vf(vf, I40E_VIRTCHNL_OP_EVENT,
 		I40E_SUCCESS, (uint8_t *)&event, sizeof(event));
 }
-- 
1.9.0

[dpdk-stable] patch 'net/i40e: add missing 25G link speed' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 603f75e6ca1592bf6cb642f940e9a1be80f2b533 Mon Sep 17 00:00:00 2001
From: Qi Zhang <qi.z.zhang@intel.com>
Date: Sun, 9 Apr 2017 14:05:06 -0400
Subject: [PATCH] net/i40e: add missing 25G link speed

[ upstream commit 8a4764f8b7f986b9e30b91f6f56606b82605c00e ]

Add missing 25G link speed decode in i40evf_dev_link_update.

Fixes: 75d133dd3296 ("net/i40e: enable 25G device")

Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
---
 drivers/net/i40e/i40e_ethdev_vf.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
index 9618dd5..efd4fac 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2146,6 +2146,9 @@ i40evf_dev_link_update(struct rte_eth_dev *dev,
 	case I40E_LINK_SPEED_20GB:
 		new_link.link_speed = ETH_SPEED_NUM_20G;
 		break;
+	case I40E_LINK_SPEED_25GB:
+		new_link.link_speed = ETH_SPEED_NUM_25G;
+		break;
 	case I40E_LINK_SPEED_40GB:
 		new_link.link_speed = ETH_SPEED_NUM_40G;
 		break;
-- 
1.9.0

[dpdk-stable] patch 'net/i40e: fix hash input set on X722' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From f9b96ab6b4a9fc9e10b012642baddd6444c30e43 Mon Sep 17 00:00:00 2001
From: Jeff Guo <jia.guo@intel.com>
Date: Thu, 6 Apr 2017 10:35:26 +0800
Subject: [PATCH] net/i40e: fix hash input set on X722
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

[ upstream commit e711f8a8cdbfc621c97d303c6871c66265c60bc9 ]

There are some new PCTYPEs on X722, but they have not been announced
on the RTE lib, so if it can not set corresponding hash input set for
these packet type, the hash function won’t work.

So we need to handle them base on the translation of the new
PCTYPE and the original PCTYPE.

Fixes: b6a0ec418274 ("i40e: use AQ for Rx control register read/write")

Signed-off-by: Jeff Guo <jia.guo@intel.com>
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
---
 drivers/net/i40e/i40e_ethdev.c | 39 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 5c7647a..2a23a49 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -7052,7 +7052,44 @@ i40e_set_hash_filter_global_config(struct i40e_hw *hw,
 		pctype = i40e_flowtype_to_pctype(i);
 		reg = (g_cfg->sym_hash_enable_mask[0] & (1UL << i)) ?
 				I40E_GLQF_HSYM_SYMH_ENA_MASK : 0;
-		i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(pctype), reg);
+		if (hw->mac.type == I40E_MAC_X722) {
+			if (pctype == I40E_FILTER_PCTYPE_NONF_IPV4_UDP) {
+				i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(
+				  I40E_FILTER_PCTYPE_NONF_IPV4_UDP), reg);
+				i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(
+				  I40E_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP),
+				  reg);
+				i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(
+				  I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV4_UDP),
+				  reg);
+			} else if (pctype == I40E_FILTER_PCTYPE_NONF_IPV4_TCP) {
+				i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(
+				  I40E_FILTER_PCTYPE_NONF_IPV4_TCP), reg);
+				i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(
+				  I40E_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK),
+				  reg);
+			} else if (pctype == I40E_FILTER_PCTYPE_NONF_IPV6_UDP) {
+				i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(
+				  I40E_FILTER_PCTYPE_NONF_IPV6_UDP), reg);
+				i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(
+				  I40E_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP),
+				  reg);
+				i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(
+				  I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV6_UDP),
+				  reg);
+			} else if (pctype == I40E_FILTER_PCTYPE_NONF_IPV6_TCP) {
+				i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(
+				  I40E_FILTER_PCTYPE_NONF_IPV6_TCP), reg);
+				i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(
+				  I40E_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK),
+				  reg);
+			} else {
+				i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(pctype),
+				  reg);
+			}
+		} else {
+			i40e_write_rx_ctl(hw, I40E_GLQF_HSYM(pctype), reg);
+		}
 	}
 
 	reg = i40e_read_rx_ctl(hw, I40E_GLQF_CTL);
-- 
1.9.0

[dpdk-stable] patch 'net/thunderx: fix stats access out of bounds' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 8168d29597f2048b0fe9594e85d45b561b8cb3ce Mon Sep 17 00:00:00 2001
From: Marcin Wilk <marcin.wilk@caviumnetworks.com>
Date: Tue, 11 Apr 2017 14:35:13 +0200
Subject: [PATCH] net/thunderx: fix stats access out of bounds

[ upstream commit 695cd416ce6c02d7a20108765573936998b2dbf0 ]

Trying to assign more queues to stats struct break only from one loop
when the maximum size is reached. Outside loop iteration is continued.
This leads to access an array out of bounds.

Fixes: 21e3fb0050b9 ("net/thunderx: add final bits for secondary queue support")

Signed-off-by: Marcin Wilk <marcin.wilk@caviumnetworks.com>
Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
 drivers/net/thunderx/nicvf_ethdev.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
index aea445b..2da5af0 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -244,7 +244,7 @@ nicvf_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
 
 	/* Reading per RX ring stats */
 	for (qidx = rx_start; qidx <= rx_end; qidx++) {
-		if (qidx == RTE_ETHDEV_QUEUE_STAT_CNTRS)
+		if (qidx >= RTE_ETHDEV_QUEUE_STAT_CNTRS)
 			break;
 
 		nicvf_hw_get_rx_qstats(nic, &rx_qstats, qidx);
@@ -257,7 +257,7 @@ nicvf_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
 
 	/* Reading per TX ring stats */
 	for (qidx = tx_start; qidx <= tx_end; qidx++) {
-		if (qidx == RTE_ETHDEV_QUEUE_STAT_CNTRS)
+		if (qidx >= RTE_ETHDEV_QUEUE_STAT_CNTRS)
 			break;
 
 		nicvf_hw_get_tx_qstats(nic, &tx_qstats, qidx);
@@ -276,7 +276,7 @@ nicvf_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
 
 		/* Reading per RX ring stats */
 		for (qidx = rx_start; qidx <= rx_end; qidx++) {
-			if (qidx == RTE_ETHDEV_QUEUE_STAT_CNTRS)
+			if (qidx >= RTE_ETHDEV_QUEUE_STAT_CNTRS)
 				break;
 
 			nicvf_hw_get_rx_qstats(snic, &rx_qstats,
@@ -289,7 +289,7 @@ nicvf_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
 		nicvf_tx_range(dev, snic, &tx_start, &tx_end);
 		/* Reading per TX ring stats */
 		for (qidx = tx_start; qidx <= tx_end; qidx++) {
-			if (qidx == RTE_ETHDEV_QUEUE_STAT_CNTRS)
+			if (qidx >= RTE_ETHDEV_QUEUE_STAT_CNTRS)
 				break;
 
 			nicvf_hw_get_tx_qstats(snic, &tx_qstats,
-- 
1.9.0

[dpdk-stable] patch 'net/ena: cleanup if refilling of Rx descriptors fails' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 32c782c5926d9c922e04346906198674c74f8cbc Mon Sep 17 00:00:00 2001
From: Michal Krawczyk <mk@semihalf.com>
Date: Mon, 10 Apr 2017 16:28:10 +0200
Subject: [PATCH] net/ena: cleanup if refilling of Rx descriptors fails

[ upstream commit 2732e07ad1e54c648c8ca5bc6965af5bf607ba10 ]

If wrong number of descriptors for refilling was passed to the Rx
repopulate function, there was memory leak which caused memory pool to
run out of resources in longer go.

In case of fail when refilling Rx descriptors, all additional mbufs
have to be released.

Fixes: 1173fca25af9 ("ena: add polling-mode driver")

Signed-off-by: Michal Krawczyk <mk@semihalf.com>
Reviewed-by: Jakub Palider <jpalider@gmail.com>
Acked-by: Jan Medala <jan.medala@outlook.com>
---
 drivers/net/ena/ena_ethdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index c1fd7bb..a62db65 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -1160,6 +1160,8 @@ static int ena_populate_rx_queue(struct ena_ring *rxq, unsigned int count)
 		rc = ena_com_add_single_rx_desc(rxq->ena_com_io_sq,
 						&ebuf, next_to_use_masked);
 		if (unlikely(rc)) {
+			rte_mempool_put_bulk(rxq->mb_pool, (void **)(&mbuf),
+					     count - i);
 			RTE_LOG(WARNING, PMD, "failed adding rx desc\n");
 			break;
 		}
-- 
1.9.0

[dpdk-stable] patch 'net/bonding: allow configuring jumbo frames without slaves' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 07468ca98937b4efa1491e263eda7d5c167192c1 Mon Sep 17 00:00:00 2001
From: Ilya Maximets <i.maximets@samsung.com>
Date: Fri, 7 Apr 2017 18:07:12 +0300
Subject: [PATCH] net/bonding: allow configuring jumbo frames without slaves

[ upstream commit c32c2c06bc82b3977b7d16d50a5d7cdcfc7b7e76 ]

Currently, 'rte_eth_dev_configure' fails on attempt to setup
max_rx_pkt_len > 2048 if no slaves was added to bonded device.

For example:

	rte_eth_dev_attach("eth_bond0,slave=05:00.0,mode=l34", &id)
	conf.rxmode.jumbo_frame = 1;
	conf.rxmode.max_rx_pkt_len = 9000;
	rte_eth_dev_configure(id, 1, 1, &conf)

Result:
	EAL: Initializing pmd_bond for eth_bond0
	EAL: Create bonded device eth_bond0 on port 4 in mode 2 on socket 0.
	rte_eth_dev_configure: ethdev port_id=4 \
		max_rx_pkt_len 9018 > max valid value 2048

It's expected that slaves will be added to bonded device inside
'rte_eth_dev_configure' and proper 'max_rx_pktlen' configured
for all of them.

Failure happens because of hardcoded low value of 'max_rx_pktlen'.
Increasing of this value to ETHER_MAX_JUMBO_FRAME_LEN will allow
above scenario (attach + configure).

It is important because it is the way OVS wants to work with
all DPDK devices (including virtual).
Changing the default hardcoded value makes no harm because
all the slaves' related code uses only 'candidate_max_rx_pktlen'
variable.

Fixes: 6cfc6a4f0d61 ("net/bonding: inherit maximum Rx packet length")

Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Reviewed-by: Eric Kinzie <ehkinzie@gmail.com>
Acked-by: Declan Doherty <declan.doherty@intel.com>
---
 drivers/net/bonding/rte_eth_bond_pmd.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c b/drivers/net/bonding/rte_eth_bond_pmd.c
index a80b6fa..08ef181 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -1668,8 +1668,9 @@ bond_ethdev_info(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 
 	dev_info->max_mac_addrs = 1;
 
-	dev_info->max_rx_pktlen = internals->candidate_max_rx_pktlen ?
-				  internals->candidate_max_rx_pktlen : 2048;
+	dev_info->max_rx_pktlen = internals->candidate_max_rx_pktlen
+				  ? internals->candidate_max_rx_pktlen
+				  : ETHER_MAX_JUMBO_FRAME_LEN;
 
 	dev_info->max_rx_queues = (uint16_t)128;
 	dev_info->max_tx_queues = (uint16_t)512;
-- 
1.9.0

[dpdk-stable] patch 'net/mlx4: fix Rx after mbuf alloc failure' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From dbe0a318476b3d12e6a24abd2d3c9879a2ad4fd3 Mon Sep 17 00:00:00 2001
From: Charles Myers <charles.myers@spirent.com>
Date: Thu, 13 Apr 2017 12:15:24 -1000
Subject: [PATCH] net/mlx4: fix Rx after mbuf alloc failure

[ upstream commit 1193edaa828725bead4d54fa7c1214f105d203c4 ]

Fixes issue where mlx4 driver stops receiving packets when mbuf
allocation fails in mlx4_rx_burst().

This issue appears to be caused because the code doesn't recycle the
existing mbuf to the sges array when mbuf allocation fails as is done
in the code right above it which handles (wc.status != IBV_WC_SUCCESS).

Copying the code from the above case fixes the issue.

Fixes: acac55f16412 ("mlx4: use MOFED 3.0 fast verbs interface for Rx operations")

Signed-off-by: Charles Myers <charles.myers@spirent.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
---
 drivers/net/mlx4/mlx4.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 695efe3..83f9143 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -3340,6 +3340,8 @@ mlx4_rx_burst(void *dpdk_rxq, struct rte_mbuf **pkts, uint16_t pkts_n)
 			/* Increase out of memory counters. */
 			++rxq->stats.rx_nombuf;
 			++rxq->priv->dev->data->rx_mbuf_alloc_failed;
+			/* Add SGE to array for repost. */
+			sges[i] = elt->sge;
 			goto repost;
 		}
 
-- 
1.9.0

[dpdk-stable] patch 'net/i40e: ensure vector mode is not used with QinQ' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 11618f606bd65c4664f66c71723bd90b5289c23d Mon Sep 17 00:00:00 2001
From: Bernard Iremonger <bernard.iremonger@intel.com>
Date: Thu, 13 Apr 2017 10:53:05 +0100
Subject: [PATCH] net/i40e: ensure vector mode is not used with QinQ

[ upstream commit b6e2e78f5dbece33b64e742331ae949b7ead5373 ]

In rx vector mode, QinQ is not supported.
When hw_vlan_extend is set for QinQ ensure that
rx vector mode is not selected.

Fixes: 8e109464c022 ("i40e: allow vector Rx and Tx usage")

Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
 drivers/net/i40e/i40e_rxtx_vec_common.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/i40e/i40e_rxtx_vec_common.h b/drivers/net/i40e/i40e_rxtx_vec_common.h
index 990520f..23b4e35 100644
--- a/drivers/net/i40e/i40e_rxtx_vec_common.h
+++ b/drivers/net/i40e/i40e_rxtx_vec_common.h
@@ -243,6 +243,10 @@ i40e_rx_vec_dev_conf_condition_check_default(struct rte_eth_dev *dev)
 	if (rxmode->header_split == 1)
 		return -1;
 
+	/* no QinQ support */
+	if (rxmode->hw_vlan_extend == 1)
+		return -1;
+
 	return 0;
 #else
 	RTE_SET_USED(dev);
-- 
1.9.0

[dpdk-stable] patch 'vhost: fix use after free' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 69923f658e0289429a8d1ea18c523c3289c6e5e7 Mon Sep 17 00:00:00 2001
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Date: Mon, 17 Apr 2017 15:27:04 +0800
Subject: [PATCH] vhost: fix use after free

[ upstream commit 7bd841b2691a428ac70f965a6ee352728da9c0f3 ]

A "return" is missing on error, which could lead to a "use after free"
issue (about var "conn").

Coverity issue: 143476
Fixes: 65388b43f592 ("vhost: fix fd leaks for vhost-user server mode")

Reported-by: John McNamara <john.mcnamara@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
 lib/librte_vhost/socket.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_vhost/socket.c b/lib/librte_vhost/socket.c
index 2afde98..84e0595 100644
--- a/lib/librte_vhost/socket.c
+++ b/lib/librte_vhost/socket.c
@@ -228,6 +228,7 @@ vhost_user_add_connection(int fd, struct vhost_user_socket *vsocket)
 		RTE_LOG(ERR, VHOST_CONFIG,
 			"failed to add fd %d into vhost server fdset\n",
 			fd);
+		return;
 	}
 
 	pthread_mutex_lock(&vsocket->conn_mutex);
-- 
1.9.0

[dpdk-stable] patch 'net/virtio-user: fix address on 32-bit system' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 3de9e0f31b9de9184a508b2fe694f13b6f668ee8 Mon Sep 17 00:00:00 2001
From: Jianfeng Tan <jianfeng.tan@intel.com>
Date: Wed, 19 Apr 2017 02:30:33 +0000
Subject: [PATCH] net/virtio-user: fix address on 32-bit system

[ upstream commit 260aae9ad9621e3e758f1443abb8fcbc25ece07c ]

virtio-user cannot work on 32-bit system as higher 32-bit of the
addr field (64-bit) in the desc is filled with non-zero value
which should not happen for a 32-bit system.

In case of virtio-user, we use buf_addr of mbuf to fill the
virtqueue desc addr. This is a regression bug. For 32-bit system,
the first 4 bytes of mbuf is buf_addr, with following 8 bytes for
buf_phyaddr. With below wrong definition, both buf_addr and lower
4 bytes buf_phyaddr are obtained to fill the virtqueue desc.
  #define VIRTIO_MBUF_ADDR(mb, vq) \
	(*(uint64_t *)((uintptr_t)(mb) + (vq)->offset))

Fixes: 25f80d108780 ("net/virtio: fix packet corruption")

Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
---
 drivers/net/virtio/virtqueue.h | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index b1070e0..569c251 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -71,8 +71,14 @@ struct rte_mbuf;
 /**
  * Return the physical address (or virtual address in case of
  * virtio-user) of mbuf data buffer.
+ *
+ * The address is firstly casted to the word size (sizeof(uintptr_t))
+ * before casting it to uint64_t. This is to make it work with different
+ * combination of word size (64 bit and 32 bit) and virtio device
+ * (virtio-pci and virtio-user).
  */
-#define VIRTIO_MBUF_ADDR(mb, vq) (*(uint64_t *)((uintptr_t)(mb) + (vq)->offset))
+#define VIRTIO_MBUF_ADDR(mb, vq) \
+	((uint64_t)(*(uintptr_t *)((uintptr_t)(mb) + (vq)->offset)))
 #else
 #define VIRTIO_MBUF_ADDR(mb, vq) ((mb)->buf_physaddr)
 #endif
-- 
1.9.0

[dpdk-stable] patch 'vhost: fix dequeue zero copy' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 0b107b3d6023fb690a7dbd3e500a87807cfa9060 Mon Sep 17 00:00:00 2001
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Date: Wed, 19 Apr 2017 13:26:01 +0800
Subject: [PATCH] vhost: fix dequeue zero copy

[ upstream commit 84ad6e44915a797cbab81c3042c600955ca75408 ]

For zero copy mode, we need pin the mbuf to not let the underlaying PMD
driver (or the app) free the mbuf. Currently, only the heading mbuf is
pinned. However, the mbuf free function would try to free all mbufs
in the mbuf chain (-1 to the refcnt). This may lead the head mbuf being
still pinned, while the other subsequent mbufs are actually freed. Which
is wrong.

It becomes more fatal after the mbuf refactor, more specificly, after
the commit 8f094a9ac5d7 ("mbuf: set mbuf fields while in pool"). The
refcnt resets to 1 after the last real reference. OTOH, it leads to a
situtation that we never know one mbuf is actually freed or not. This
would result the mbuf __just__ after the heading mbuf being freed twice:
it's firstly freed (and put back to mempool) when the underlaying PMD
finishes the DMA.  Later, it will then be freed again when vhost unpins
it. Meaning, one mbuf may be returned to the mempool twice, while in
turn, being allocated twice later. Something uncertain may happen then.
For example, the VM2VM case becomes broken.

Fixes: b0a985d1f340 ("vhost: add dequeue zero copy")

Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
---
 lib/librte_vhost/virtio_net.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index d0a3b11..ea027f1 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -905,6 +905,8 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct vring_desc *descs,
 					"allocate memory for mbuf.\n");
 				return -1;
 			}
+			if (unlikely(dev->dequeue_zero_copy))
+				rte_mbuf_refcnt_update(cur, 1);
 
 			prev->next = cur;
 			prev->data_len = mbuf_offset;
-- 
1.9.0

[dpdk-stable] patch 'crypto/qat: fix AES-GCM authentication length' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From cba5d8157e2907a438ca8115cc92b056fb701356 Mon Sep 17 00:00:00 2001
From: Arek Kusztal <arkadiuszx.kusztal@intel.com>
Date: Thu, 13 Apr 2017 10:29:03 +0100
Subject: [PATCH] crypto/qat: fix AES-GCM authentication length

[ upstream commit 46c96a9fc9e774b4abcd8a7ee75dd19f55a42e1c ]

This commit fixes AES-GCM length of authentication input data,
cipher length is used instead

Fixes: 1703e94ac5ce ("qat: add driver for QuickAssist devices")

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
Acked-by: Deepak Kumar Jain <deepak.k.jain@intel.com>
---
 drivers/crypto/qat/qat_crypto.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
index a4119fc..9ba8b60 100644
--- a/drivers/crypto/qat/qat_crypto.c
+++ b/drivers/crypto/qat/qat_crypto.c
@@ -1062,6 +1062,12 @@ qat_write_hw_desc_entry(struct rte_crypto_op *op, uint8_t *out_msg)
 				}
 			}
 
+		} else if (ctx->qat_hash_alg ==
+					ICP_QAT_HW_AUTH_ALGO_GALOIS_128 ||
+				ctx->qat_hash_alg ==
+					ICP_QAT_HW_AUTH_ALGO_GALOIS_64) {
+			auth_ofs = op->sym->cipher.data.offset;
+			auth_len = op->sym->cipher.data.length;
 		} else {
 			auth_ofs = op->sym->auth.data.offset;
 			auth_len = op->sym->auth.data.length;
-- 
1.9.0

[dpdk-stable] patch 'crypto/qat: fix IV zero physical address' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 5d652f09f7ef3221b69454b1b2f1709d08ce1879 Mon Sep 17 00:00:00 2001
From: Arek Kusztal <arkadiuszx.kusztal@intel.com>
Date: Fri, 14 Apr 2017 09:08:42 +0100
Subject: [PATCH] crypto/qat: fix IV zero physical address

[ upstream commit 4ca12b236cf7a354889d894151b3623732b3b58f ]

This commit fixes zero physical address when IV not set

Fixes: 1703e94ac5ce ("qat: add driver for QuickAssist devices")

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
Acked-by: Deepak Kumar Jain <deepak.k.jain@intel.com>
---
 drivers/crypto/qat/qat_crypto.c | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
index 9ba8b60..abffa90 100644
--- a/drivers/crypto/qat/qat_crypto.c
+++ b/drivers/crypto/qat/qat_crypto.c
@@ -1021,17 +1021,24 @@ qat_write_hw_desc_entry(struct rte_crypto_op *op, uint8_t *out_msg)
 		}
 
 		/* copy IV into request if it fits */
-		if (op->sym->cipher.iv.length && (op->sym->cipher.iv.length <=
-				sizeof(cipher_param->u.cipher_IV_array))) {
-			rte_memcpy(cipher_param->u.cipher_IV_array,
-					op->sym->cipher.iv.data,
-					op->sym->cipher.iv.length);
-		} else {
-			ICP_QAT_FW_LA_CIPH_IV_FLD_FLAG_SET(
-					qat_req->comn_hdr.serv_specif_flags,
-					ICP_QAT_FW_CIPH_IV_64BIT_PTR);
-			cipher_param->u.s.cipher_IV_ptr =
-					op->sym->cipher.iv.phys_addr;
+		/*
+		 * If IV length is zero do not copy anything but still
+		 * use request descriptor embedded IV
+		 *
+		 */
+		if (op->sym->cipher.iv.length) {
+			if (op->sym->cipher.iv.length <=
+					sizeof(cipher_param->u.cipher_IV_array)) {
+				rte_memcpy(cipher_param->u.cipher_IV_array,
+						op->sym->cipher.iv.data,
+						op->sym->cipher.iv.length);
+			} else {
+				ICP_QAT_FW_LA_CIPH_IV_FLD_FLAG_SET(
+						qat_req->comn_hdr.serv_specif_flags,
+						ICP_QAT_FW_CIPH_IV_64BIT_PTR);
+				cipher_param->u.s.cipher_IV_ptr =
+						op->sym->cipher.iv.phys_addr;
+			}
 		}
 		min_ofs = cipher_ofs;
 	}
-- 
1.9.0

[dpdk-stable] patch 'examples/l2fwd-crypto: fix AEAD tests when AAD is zero' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From e3282f5a3afdc92f62c1fae60e5d563f2336f79a Mon Sep 17 00:00:00 2001
From: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Date: Mon, 17 Apr 2017 13:23:37 +0100
Subject: [PATCH] examples/l2fwd-crypto: fix AEAD tests when AAD is zero

[ upstream commit 18f421f65bb8dcfa77919c48edeb54c867ce89c8 ]

For AEAD algorithms, additional authenticated data (AAD)
can be passed, but it is optional, so its size can be zero.
However, it is required to set this length to zero in the crypto
operation to avoid undefined behaviour.

Fixes: 617a7949c98a ("examples/l2fwd-crypto: parse AAD parameter")

Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
 examples/l2fwd-crypto/main.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index bc88be5..5f8f04f 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -499,6 +499,10 @@ l2fwd_simple_crypto_enqueue(struct rte_mbuf *m,
 			op->sym->auth.aad.data = cparams->aad.data;
 			op->sym->auth.aad.phys_addr = cparams->aad.phys_addr;
 			op->sym->auth.aad.length = cparams->aad.length;
+		} else {
+			op->sym->auth.aad.data = NULL;
+			op->sym->auth.aad.phys_addr = 0;
+			op->sym->auth.aad.length = 0;
 		}
 	}
 
@@ -699,7 +703,8 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)
 					generate_random_key(port_cparams[i].aad.data,
 						port_cparams[i].aad.length);
 
-			}
+			} else
+				port_cparams[i].aad.length = 0;
 
 			if (options->auth_xform.auth.op == RTE_CRYPTO_AUTH_OP_VERIFY)
 				port_cparams[i].hash_verify = 1;
-- 
1.9.0

[dpdk-stable] patch 'examples/l2fwd-crypto: fix padding calculation' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 7ec092c6207d00e26cc7bfc26bde97c9aee5d336 Mon Sep 17 00:00:00 2001
From: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Date: Wed, 19 Apr 2017 15:37:54 +0100
Subject: [PATCH] examples/l2fwd-crypto: fix padding calculation

[ upstream commit c64457cb11f0df25813983b10c47d80058b9a8ba ]

For padding calculation, it is necessary to know if algorithm
is a block cipher or stream cipher algorithm, and know the
block size for the algorithm.

In the application, this block size should be only the
cipher block size, but if authentication was used too,
it was being overwritten by the authentication block size,
which is not needed.

Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")

Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
---
 examples/l2fwd-crypto/main.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 5f8f04f..77a5fe1 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -1698,7 +1698,6 @@ initialize_cryptodevs(struct l2fwd_crypto_options *options, unsigned nb_ports,
 				continue;
 			}
 
-			options->block_size = cap->sym.auth.block_size;
 			/*
 			 * Check if length of provided AAD is supported
 			 * by the algorithm chosen.
-- 
1.9.0

[dpdk-stable] patch 'kni: fix possible memory leak' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From 9875d5f69835a951d17c1b9166880efaca7062d1 Mon Sep 17 00:00:00 2001
From: Ferruh Yigit <ferruh.yigit@intel.com>
Date: Tue, 18 Apr 2017 15:21:44 +0100
Subject: [PATCH] kni: fix possible memory leak

[ upstream commit 8eba5ebd181141f71115d01bf65fd2e9ad549210 ]

alloc_q and rx_q fifos holds physical address of the mbufs, and not able
to free those mbufs explicitly.

But kernel thread reads from rx_q and puts used mbufs into free_q (with
their virtual addresses.) And kernel thread stopped when application
close the /dev/kni file on exit. So rx_q has time to be consumed by
kernel thread but leak is technically possible.

Another fifo, alloc_q has physical addresses too, but all those coming
from same mempool provided by application, when application quit, all
mempool already returned back, so this leak can be ignored.

Added check and wait logic for rx_q to be sure kernel consumed the fifo,
an error message printed after some ammount of wait, and an explicit
mempool free added for alloc_q.

Fixes: 8451269e6d7b ("kni: remove continuous memory restriction")

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
 lib/librte_kni/rte_kni.c      | 20 ++++++++++++++------
 lib/librte_kni/rte_kni_fifo.h |  9 +++++++++
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index a80cefd..52fcd4b 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -452,16 +452,16 @@ kni_free_fifo(struct rte_kni_fifo *fifo)
 }
 
 static void
-kni_free_fifo_phy(struct rte_kni_fifo *fifo)
+kni_free_fifo_phy(struct rte_mempool *pktmbuf_pool, struct rte_kni_fifo *fifo)
 {
 	void *mbuf_phys;
 	int ret;
 
+	rte_mempool_free(pktmbuf_pool);
+
+	/* All mbufs alredy freed with rte_mempoll_free, just free the fifo */
 	do {
 		ret = kni_fifo_get(fifo, &mbuf_phys, 1);
-		/*
-		 * TODO: free mbufs
-		 */
 	} while (ret);
 }
 
@@ -470,6 +470,7 @@ rte_kni_release(struct rte_kni *kni)
 {
 	struct rte_kni_device_info dev_info;
 	uint32_t slot_id;
+	uint32_t retry = 5;
 
 	if (!kni || !kni->in_use)
 		return -1;
@@ -481,9 +482,16 @@ rte_kni_release(struct rte_kni *kni)
 	}
 
 	/* mbufs in all fifo should be released, except request/response */
+
+	/* wait until all rxq packets processed by kernel */
+	while (kni_fifo_count(kni->rx_q) && retry--)
+		usleep(1000);
+
+	if (kni_fifo_count(kni->rx_q))
+		RTE_LOG(ERR, KNI, "Fail to free all Rx-q items\n");
+
+	kni_free_fifo_phy(kni->pktmbuf_pool, kni->alloc_q);
 	kni_free_fifo(kni->tx_q);
-	kni_free_fifo_phy(kni->rx_q);
-	kni_free_fifo_phy(kni->alloc_q);
 	kni_free_fifo(kni->free_q);
 
 	slot_id = kni->slot_id;
diff --git a/lib/librte_kni/rte_kni_fifo.h b/lib/librte_kni/rte_kni_fifo.h
index 8cb8587..c7cd5c2 100644
--- a/lib/librte_kni/rte_kni_fifo.h
+++ b/lib/librte_kni/rte_kni_fifo.h
@@ -91,3 +91,12 @@ kni_fifo_get(struct rte_kni_fifo *fifo, void **data, unsigned num)
 	fifo->read = new_read;
 	return i;
 }
+
+/**
+ * Get the num of elements in the fifo
+ */
+static inline uint32_t
+kni_fifo_count(struct rte_kni_fifo *fifo)
+{
+	return (fifo->len + fifo->write - fifo->read) & (fifo->len - 1);
+}
-- 
1.9.0

[dpdk-stable] patch 'test/mempool: free mempool on exit' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From af86d9f27365c4ee5e23ed6bb3cd4b66d7559419 Mon Sep 17 00:00:00 2001
From: Shreyansh Jain <shreyansh.jain@nxp.com>
Date: Wed, 5 Apr 2017 15:05:33 +0530
Subject: [PATCH] test/mempool: free mempool on exit

[ upstream commit 98aabe1b701f3f58153aef029d483e2d8b9ca7b6 ]

mempool autotest was not freeing the mempools.

Fixes: 8ef772ae ("app/test: rework mempool test")

Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
Reviewed-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
---
 app/test/test_mempool.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index b9880b3..715b250 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -509,6 +509,7 @@ walk_cb(struct rte_mempool *mp, void *userdata __rte_unused)
 static int
 test_mempool(void)
 {
+	int ret = -1;
 	struct rte_mempool *mp_cache = NULL;
 	struct rte_mempool *mp_nocache = NULL;
 	struct rte_mempool *mp_stack = NULL;
@@ -607,13 +608,13 @@ test_mempool(void)
 
 	rte_mempool_list_dump(stdout);
 
-	return 0;
+	ret = 0;
 
 err:
 	rte_mempool_free(mp_nocache);
 	rte_mempool_free(mp_cache);
 	rte_mempool_free(mp_stack);
-	return -1;
+	return ret;
 }
 
 REGISTER_TEST_COMMAND(mempool_autotest, test_mempool);
-- 
1.9.0

[dpdk-stable] patch 'net/virtio: fix queue notify' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From a9a174ce6216a87f9383aa78e8293d29dc50dca5 Mon Sep 17 00:00:00 2001
From: Xiao Wang <xiao.w.wang@intel.com>
Date: Tue, 11 Apr 2017 03:44:28 -0700
Subject: [PATCH] net/virtio: fix queue notify

[ backported from upstream commit 518208f3a1d370dc0873bf08d407a9aa9add4aec ]

According to spec, we should write virtqueue index into the notify
address, rather than 1. Besides, some HW backend may rely on the data
written to identify which queue need to serve.

Fixes: 6ba1f63b5ab0 ("virtio: support specification 1.0")

Signed-off-by: Xiao Wang <xiao.w.wang@intel.com>
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
---
 drivers/net/virtio/virtio_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index 8d5355c..f49a123 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -517,7 +517,7 @@ modern_del_queue(struct virtio_hw *hw, struct virtqueue *vq)
 static void
 modern_notify_queue(struct virtio_hw *hw __rte_unused, struct virtqueue *vq)
 {
-	io_write16(1, vq->notify_addr);
+	io_write16(vq->vq_queue_index, vq->notify_addr);
 }
 
 const struct virtio_pci_ops modern_ops = {
-- 
1.9.0

[dpdk-stable] patch 'net/virtio: fix link status always being up' has been queued to LTS release 16.11.2

[Yuanhan Liu]

Hi,

FYI, your patch has been queued to LTS release 16.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable
yet. It will be pushed if I get no objections before 04/26/17.
So please shout if anyone has objections.

Thanks.

	--yliu

---
>From def1983375f9f81222a972957ee5e5e014389808 Mon Sep 17 00:00:00 2001
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Date: Fri, 14 Apr 2017 14:36:45 +0800
Subject: [PATCH] net/virtio: fix link status always being up

[ backported from upstream commit aa9f060617653bac99f41dedfd518b7034374139 ]

The virtio port link status will always be UP, even the port is stopped:

    testpmd> port stop 0
    Stopping ports...
    Checking link statuses...
    Port 0 Link Up - speed 10000 Mbps - full-duplex
    Done

The link status is queried by link_update callback when LSC is disabled.
Which in turn queries the "status" field.  However, the "status" is
read-only. I couldn't think of some proper ways to change the status
without doing device reset.

Instead of doing (the heavy) reset at stop, this patch introduced a flag,
which is set to 1 and 0 on start and stop, respectively. When it's set to
0, the link status is set to DOWN unconditionally.

Fixes: a85786dc816f ("virtio: fix states handling during initialization")

Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
---
 drivers/net/virtio/virtio_ethdev.c | 7 ++++++-
 drivers/net/virtio/virtio_pci.h    | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index ff3f781..d2256f7 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1581,6 +1581,7 @@ virtio_dev_start(struct rte_eth_dev *dev)
 		txvq = dev->data->tx_queues[i];
 		VIRTQUEUE_DUMP(txvq->vq);
 	}
+	hw->started = 1;
 
 	return 0;
 }
@@ -1636,6 +1637,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)
 static void
 virtio_dev_stop(struct rte_eth_dev *dev)
 {
+	struct virtio_hw *hw = dev->data->dev_private;
 	struct rte_eth_link link;
 
 	PMD_INIT_LOG(DEBUG, "stop");
@@ -1643,6 +1645,7 @@ virtio_dev_stop(struct rte_eth_dev *dev)
 	if (dev->data->dev_conf.intr_conf.lsc)
 		rte_intr_disable(&dev->pci_dev->intr_handle);
 
+	hw->started = 0;
 	memset(&link, 0, sizeof(link));
 	virtio_dev_atomic_write_link_status(dev, &link);
 }
@@ -1659,7 +1662,9 @@ virtio_dev_link_update(struct rte_eth_dev *dev, __rte_unused int wait_to_complet
 	link.link_duplex = ETH_LINK_FULL_DUPLEX;
 	link.link_speed  = SPEED_10G;
 
-	if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS)) {
+	if (hw->started == 0) {
+		link.link_status = ETH_LINK_DOWN;
+	} else if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS)) {
 		PMD_INIT_LOG(DEBUG, "Get link status from hw");
 		vtpci_read_dev_config(hw,
 				offsetof(struct virtio_net_config, status),
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index d83a685..40f7e42 100644
--- a/drivers/net/virtio/virtio_pci.h
+++ b/drivers/net/virtio/virtio_pci.h
@@ -249,6 +249,7 @@ struct virtio_hw {
 	uint64_t    req_guest_features;
 	uint64_t    guest_features;
 	uint32_t    max_queue_pairs;
+	uint16_t    started;
 	uint16_t    vtnet_hdr_size;
 	uint8_t	    vlan_strip;
 	uint8_t	    use_msix;
-- 
1.9.0