* [dpdk-stable] [PATCH 01/31] net/bnxt: fix clear port stats
[not found] <20180619213058.12273-1-ajit.khaparde@broadcom.com>
@ 2018-06-19 21:30 ` Ajit Khaparde
2018-06-19 21:30 ` [dpdk-stable] [PATCH 05/31] net/bnxt: fix dev close operation Ajit Khaparde
` (5 subsequent siblings)
6 siblings, 0 replies; 11+ messages in thread
From: Ajit Khaparde @ 2018-06-19 21:30 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, stable
PORT_CLR_STATS is not allowed for VFs, NPAR, MultiHost functions
or when SR-IOV is enabled.
Don't send the HWRM command in such cases.
Fixes: bfb9c2260be2 ("net/bnxt: support xstats get/reset")
Cc: stable@dpdk.org
Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
---
drivers/net/bnxt/bnxt.h | 4 ++++
drivers/net/bnxt/bnxt_hwrm.c | 5 ++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index afaaf8c41..35c3073dd 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -98,6 +98,7 @@ struct bnxt_child_vf_info {
struct bnxt_pf_info {
#define BNXT_FIRST_PF_FID 1
#define BNXT_MAX_VFS(bp) (bp->pf.max_vfs)
+#define BNXT_TOTAL_VFS(bp) (bp->pf.total_vfs)
#define BNXT_FIRST_VF_FID 128
#define BNXT_PF_RINGS_USED(bp) bnxt_get_num_queues(bp)
#define BNXT_PF_RINGS_AVAIL(bp) (bp->pf.max_cp_rings - BNXT_PF_RINGS_USED(bp))
@@ -105,6 +106,9 @@ struct bnxt_pf_info {
uint16_t first_vf_id;
uint16_t active_vfs;
uint16_t max_vfs;
+ uint16_t total_vfs; /* Total VFs possible.
+ * Not necessarily enabled.
+ */
uint32_t func_cfg_flags;
void *vf_req_buf;
rte_iova_t vf_req_buf_dma_addr;
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index d6fdc1b88..f441d4610 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -506,6 +506,7 @@ static int __bnxt_hwrm_func_qcaps(struct bnxt *bp)
if (BNXT_PF(bp)) {
bp->pf.port_id = resp->port_id;
bp->pf.first_vf_id = rte_le_to_cpu_16(resp->first_vf_id);
+ bp->pf.total_vfs = rte_le_to_cpu_16(resp->max_vfs);
new_max_vfs = bp->pdev->max_vfs;
if (new_max_vfs != bp->pf.max_vfs) {
if (bp->pf.vf_info)
@@ -3151,7 +3152,9 @@ int bnxt_hwrm_port_clr_stats(struct bnxt *bp)
struct bnxt_pf_info *pf = &bp->pf;
int rc;
- if (!(bp->flags & BNXT_FLAG_PORT_STATS))
+ /* Not allowed on NS2 device, NPAR, MultiHost, VF */
+ if (!(bp->flags & BNXT_FLAG_PORT_STATS) || BNXT_VF(bp) ||
+ BNXT_NPAR(bp) || BNXT_MH(bp) || BNXT_TOTAL_VFS(bp))
return 0;
HWRM_PREP(req, PORT_CLR_STATS);
--
2.15.1 (Apple Git-101)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [dpdk-stable] [PATCH 05/31] net/bnxt: fix dev close operation
[not found] <20180619213058.12273-1-ajit.khaparde@broadcom.com>
2018-06-19 21:30 ` [dpdk-stable] [PATCH 01/31] net/bnxt: fix clear port stats Ajit Khaparde
@ 2018-06-19 21:30 ` Ajit Khaparde
2018-06-26 15:28 ` Ferruh Yigit
2018-06-19 21:30 ` [dpdk-stable] [PATCH 07/31] net/bnxt: fix HW Tx checksum offload check Ajit Khaparde
` (4 subsequent siblings)
6 siblings, 1 reply; 11+ messages in thread
From: Ajit Khaparde @ 2018-06-19 21:30 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, stable
We are not cleaning up all the memory and also not unregistering
the driver during device close operation. This patch fixes the issue.
Fixes: 893074951314 (net/bnxt: free memory in close operation)
Cc: stable@dpdk.org
Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
---
drivers/net/bnxt/bnxt_ethdev.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 33560db0d..b3826360c 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -152,6 +152,7 @@ static const struct rte_pci_id bnxt_pci_id_map[] = {
static int bnxt_vlan_offload_set_op(struct rte_eth_dev *dev, int mask);
static void bnxt_print_link_info(struct rte_eth_dev *eth_dev);
static int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev, uint16_t new_mtu);
+static int bnxt_dev_uninit(struct rte_eth_dev *eth_dev);
/***********************/
@@ -668,6 +669,8 @@ static void bnxt_dev_close_op(struct rte_eth_dev *eth_dev)
rte_free(bp->grp_info);
bp->grp_info = NULL;
}
+
+ bnxt_dev_uninit(eth_dev);
}
static void bnxt_mac_addr_remove_op(struct rte_eth_dev *eth_dev,
@@ -3116,7 +3119,6 @@ static int bnxt_init_board(struct rte_eth_dev *eth_dev)
return rc;
}
-static int bnxt_dev_uninit(struct rte_eth_dev *eth_dev);
#define ALLOW_FUNC(x) \
{ \
@@ -3408,13 +3410,15 @@ bnxt_dev_init(struct rte_eth_dev *eth_dev)
}
static int
-bnxt_dev_uninit(struct rte_eth_dev *eth_dev) {
+bnxt_dev_uninit(struct rte_eth_dev *eth_dev)
+{
struct bnxt *bp = eth_dev->data->dev_private;
int rc;
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return -EPERM;
+ PMD_DRV_LOG(INFO, "Calling Device uninit\n");
bnxt_disable_int(bp);
bnxt_free_int(bp);
bnxt_free_mem(bp);
@@ -3428,8 +3432,17 @@ bnxt_dev_uninit(struct rte_eth_dev *eth_dev) {
}
rc = bnxt_hwrm_func_driver_unregister(bp, 0);
bnxt_free_hwrm_resources(bp);
- rte_memzone_free((const struct rte_memzone *)bp->tx_mem_zone);
- rte_memzone_free((const struct rte_memzone *)bp->rx_mem_zone);
+
+ if (bp->tx_mem_zone) {
+ rte_memzone_free((const struct rte_memzone *)bp->tx_mem_zone);
+ bp->tx_mem_zone = NULL;
+ }
+
+ if (bp->rx_mem_zone) {
+ rte_memzone_free((const struct rte_memzone *)bp->rx_mem_zone);
+ bp->rx_mem_zone = NULL;
+ }
+
if (bp->dev_stopped == 0)
bnxt_dev_close_op(eth_dev);
if (bp->pf.vf_info)
@@ -3456,7 +3469,7 @@ static int bnxt_pci_remove(struct rte_pci_device *pci_dev)
static struct rte_pci_driver bnxt_rte_pmd = {
.id_table = bnxt_pci_id_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING |
- RTE_PCI_DRV_INTR_LSC,
+ RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_INTR_RMV,
.probe = bnxt_pci_probe,
.remove = bnxt_pci_remove,
};
--
2.15.1 (Apple Git-101)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [dpdk-stable] [PATCH 07/31] net/bnxt: fix HW Tx checksum offload check
[not found] <20180619213058.12273-1-ajit.khaparde@broadcom.com>
2018-06-19 21:30 ` [dpdk-stable] [PATCH 01/31] net/bnxt: fix clear port stats Ajit Khaparde
2018-06-19 21:30 ` [dpdk-stable] [PATCH 05/31] net/bnxt: fix dev close operation Ajit Khaparde
@ 2018-06-19 21:30 ` Ajit Khaparde
2018-06-19 21:30 ` [dpdk-stable] [PATCH 25/31] net/bnxt: fix Tx with multiple mbuf Ajit Khaparde
` (3 subsequent siblings)
6 siblings, 0 replies; 11+ messages in thread
From: Ajit Khaparde @ 2018-06-19 21:30 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, stable, Xiaoxin Peng
Add more checks for checksum calculation offload.
Also check for tunnel frames and select the proper
buffer descriptor size.
Fixes: 6eb3cc2294fd ("net/bnxt: add initial Tx code")
Cc: stable@dpdk.org
Signed-off-by: Xiaoxin Peng <xiaoxin.peng@broadcom.com>
Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Reviewed-by: Jason He <jason.he@broadcom.com>
Reviewed-by: Qingmin Liu <qingmin.liu@broadcom.com>
---
drivers/net/bnxt/bnxt_txr.c | 51 ++++++++++++++++++++++++++++++++++++++++++---
drivers/net/bnxt/bnxt_txr.h | 10 +++++++++
2 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_txr.c b/drivers/net/bnxt/bnxt_txr.c
index 0fdf0fd08..68645b2f7 100644
--- a/drivers/net/bnxt/bnxt_txr.c
+++ b/drivers/net/bnxt/bnxt_txr.c
@@ -135,7 +135,9 @@ static uint16_t bnxt_start_xmit(struct rte_mbuf *tx_pkt,
if (tx_pkt->ol_flags & (PKT_TX_TCP_SEG | PKT_TX_TCP_CKSUM |
PKT_TX_UDP_CKSUM | PKT_TX_IP_CKSUM |
- PKT_TX_VLAN_PKT | PKT_TX_OUTER_IP_CKSUM))
+ PKT_TX_VLAN_PKT | PKT_TX_OUTER_IP_CKSUM |
+ PKT_TX_TUNNEL_GRE | PKT_TX_TUNNEL_VXLAN |
+ PKT_TX_TUNNEL_GENEVE))
long_bd = true;
tx_buf = &txr->tx_buf_ring[txr->tx_prod];
@@ -203,16 +205,46 @@ static uint16_t bnxt_start_xmit(struct rte_mbuf *tx_pkt,
/* Outer IP, Inner IP, Inner TCP/UDP CSO */
txbd1->lflags |= TX_BD_FLG_TIP_IP_TCP_UDP_CHKSUM;
txbd1->mss = 0;
+ } else if ((tx_pkt->ol_flags & PKT_TX_OIP_IIP_TCP_CKSUM) ==
+ PKT_TX_OIP_IIP_TCP_CKSUM) {
+ /* Outer IP, Inner IP, Inner TCP/UDP CSO */
+ txbd1->lflags |= TX_BD_FLG_TIP_IP_TCP_UDP_CHKSUM;
+ txbd1->mss = 0;
+ } else if ((tx_pkt->ol_flags & PKT_TX_OIP_IIP_UDP_CKSUM) ==
+ PKT_TX_OIP_IIP_UDP_CKSUM) {
+ /* Outer IP, Inner IP, Inner TCP/UDP CSO */
+ txbd1->lflags |= TX_BD_FLG_TIP_IP_TCP_UDP_CHKSUM;
+ txbd1->mss = 0;
} else if ((tx_pkt->ol_flags & PKT_TX_IIP_TCP_UDP_CKSUM) ==
PKT_TX_IIP_TCP_UDP_CKSUM) {
/* (Inner) IP, (Inner) TCP/UDP CSO */
txbd1->lflags |= TX_BD_FLG_IP_TCP_UDP_CHKSUM;
txbd1->mss = 0;
+ } else if ((tx_pkt->ol_flags & PKT_TX_IIP_UDP_CKSUM) ==
+ PKT_TX_IIP_UDP_CKSUM) {
+ /* (Inner) IP, (Inner) TCP/UDP CSO */
+ txbd1->lflags |= TX_BD_FLG_IP_TCP_UDP_CHKSUM;
+ txbd1->mss = 0;
+ } else if ((tx_pkt->ol_flags & PKT_TX_IIP_TCP_CKSUM) ==
+ PKT_TX_IIP_TCP_CKSUM) {
+ /* (Inner) IP, (Inner) TCP/UDP CSO */
+ txbd1->lflags |= TX_BD_FLG_IP_TCP_UDP_CHKSUM;
+ txbd1->mss = 0;
} else if ((tx_pkt->ol_flags & PKT_TX_OIP_TCP_UDP_CKSUM) ==
PKT_TX_OIP_TCP_UDP_CKSUM) {
/* Outer IP, (Inner) TCP/UDP CSO */
txbd1->lflags |= TX_BD_FLG_TIP_TCP_UDP_CHKSUM;
txbd1->mss = 0;
+ } else if ((tx_pkt->ol_flags & PKT_TX_OIP_UDP_CKSUM) ==
+ PKT_TX_OIP_UDP_CKSUM) {
+ /* Outer IP, (Inner) TCP/UDP CSO */
+ txbd1->lflags |= TX_BD_FLG_TIP_TCP_UDP_CHKSUM;
+ txbd1->mss = 0;
+ } else if ((tx_pkt->ol_flags & PKT_TX_OIP_TCP_CKSUM) ==
+ PKT_TX_OIP_TCP_CKSUM) {
+ /* Outer IP, (Inner) TCP/UDP CSO */
+ txbd1->lflags |= TX_BD_FLG_TIP_TCP_UDP_CHKSUM;
+ txbd1->mss = 0;
} else if ((tx_pkt->ol_flags & PKT_TX_OIP_IIP_CKSUM) ==
PKT_TX_OIP_IIP_CKSUM) {
/* Outer IP, Inner IP CSO */
@@ -223,11 +255,23 @@ static uint16_t bnxt_start_xmit(struct rte_mbuf *tx_pkt,
/* TCP/UDP CSO */
txbd1->lflags |= TX_BD_LONG_LFLAGS_TCP_UDP_CHKSUM;
txbd1->mss = 0;
- } else if (tx_pkt->ol_flags & PKT_TX_IP_CKSUM) {
+ } else if ((tx_pkt->ol_flags & PKT_TX_TCP_CKSUM) ==
+ PKT_TX_TCP_CKSUM) {
+ /* TCP/UDP CSO */
+ txbd1->lflags |= TX_BD_LONG_LFLAGS_TCP_UDP_CHKSUM;
+ txbd1->mss = 0;
+ } else if ((tx_pkt->ol_flags & PKT_TX_UDP_CKSUM) ==
+ PKT_TX_UDP_CKSUM) {
+ /* TCP/UDP CSO */
+ txbd1->lflags |= TX_BD_LONG_LFLAGS_TCP_UDP_CHKSUM;
+ txbd1->mss = 0;
+ } else if ((tx_pkt->ol_flags & PKT_TX_IP_CKSUM) ==
+ PKT_TX_IP_CKSUM) {
/* IP CSO */
txbd1->lflags |= TX_BD_LONG_LFLAGS_IP_CHKSUM;
txbd1->mss = 0;
- } else if (tx_pkt->ol_flags & PKT_TX_OUTER_IP_CKSUM) {
+ } else if ((tx_pkt->ol_flags & PKT_TX_OUTER_IP_CKSUM) ==
+ PKT_TX_OUTER_IP_CKSUM) {
/* IP CSO */
txbd1->lflags |= TX_BD_LONG_LFLAGS_T_IP_CHKSUM;
txbd1->mss = 0;
@@ -251,6 +295,7 @@ static uint16_t bnxt_start_xmit(struct rte_mbuf *tx_pkt,
}
txbd->flags_type |= TX_BD_LONG_FLAGS_PACKET_END;
+ txbd1->lflags = rte_cpu_to_le_32(txbd1->lflags);
txr->tx_prod = RING_NEXT(txr->tx_ring_struct, txr->tx_prod);
diff --git a/drivers/net/bnxt/bnxt_txr.h b/drivers/net/bnxt/bnxt_txr.h
index 15c7e5a09..7f3c7cdb0 100644
--- a/drivers/net/bnxt/bnxt_txr.h
+++ b/drivers/net/bnxt/bnxt_txr.h
@@ -45,10 +45,20 @@ int bnxt_tx_queue_stop(struct rte_eth_dev *dev, uint16_t tx_queue_id);
#define PKT_TX_OIP_IIP_TCP_UDP_CKSUM (PKT_TX_TCP_CKSUM | PKT_TX_UDP_CKSUM | \
PKT_TX_IP_CKSUM | PKT_TX_OUTER_IP_CKSUM)
+#define PKT_TX_OIP_IIP_UDP_CKSUM (PKT_TX_UDP_CKSUM | \
+ PKT_TX_IP_CKSUM | PKT_TX_OUTER_IP_CKSUM)
+#define PKT_TX_OIP_IIP_TCP_CKSUM (PKT_TX_TCP_CKSUM | \
+ PKT_TX_IP_CKSUM | PKT_TX_OUTER_IP_CKSUM)
#define PKT_TX_IIP_TCP_UDP_CKSUM (PKT_TX_TCP_CKSUM | PKT_TX_UDP_CKSUM | \
PKT_TX_IP_CKSUM)
+#define PKT_TX_IIP_TCP_CKSUM (PKT_TX_TCP_CKSUM | PKT_TX_IP_CKSUM)
+#define PKT_TX_IIP_UDP_CKSUM (PKT_TX_UDP_CKSUM | PKT_TX_IP_CKSUM)
#define PKT_TX_OIP_TCP_UDP_CKSUM (PKT_TX_TCP_CKSUM | PKT_TX_UDP_CKSUM | \
PKT_TX_OUTER_IP_CKSUM)
+#define PKT_TX_OIP_UDP_CKSUM (PKT_TX_UDP_CKSUM | \
+ PKT_TX_OUTER_IP_CKSUM)
+#define PKT_TX_OIP_TCP_CKSUM (PKT_TX_TCP_CKSUM | \
+ PKT_TX_OUTER_IP_CKSUM)
#define PKT_TX_OIP_IIP_CKSUM (PKT_TX_IP_CKSUM | \
PKT_TX_OUTER_IP_CKSUM)
#define PKT_TX_TCP_UDP_CKSUM (PKT_TX_TCP_CKSUM | PKT_TX_UDP_CKSUM)
--
2.15.1 (Apple Git-101)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [dpdk-stable] [PATCH 25/31] net/bnxt: fix Tx with multiple mbuf
[not found] <20180619213058.12273-1-ajit.khaparde@broadcom.com>
` (2 preceding siblings ...)
2018-06-19 21:30 ` [dpdk-stable] [PATCH 07/31] net/bnxt: fix HW Tx checksum offload check Ajit Khaparde
@ 2018-06-19 21:30 ` Ajit Khaparde
2018-06-19 21:30 ` [dpdk-stable] [PATCH 28/31] net/bnxt: fix set MTU Ajit Khaparde
` (2 subsequent siblings)
6 siblings, 0 replies; 11+ messages in thread
From: Ajit Khaparde @ 2018-06-19 21:30 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, Xiaoxin Peng, stable
From: Xiaoxin Peng <xiaoxin.peng@broadcom.com>
When using multi-mbuf to xmit large packets, we need to use total
packet lengths (sum of all segments) to set txbd->flags_type.
Packets will not be sent when using tx_pkt->data_len(The first
segment of packets).
Fixes: 6eb3cc2294fd ("net/bnxt: add initial Tx code")
Cc: stable@dpdk.org
Signed-off-by: Xiaoxin Peng <xiaoxin.peng@broadcom.com>
Reviewed-by: Herry Chen <herry.chen@broadcom.com>
Reviewed-by: Jason He <jason.he@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Ajit Kumar Khaparde <ajit.khaparde@broadcom.com>
---
drivers/net/bnxt/bnxt_txr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_txr.c b/drivers/net/bnxt/bnxt_txr.c
index f8fd22156..23c8e6660 100644
--- a/drivers/net/bnxt/bnxt_txr.c
+++ b/drivers/net/bnxt/bnxt_txr.c
@@ -160,10 +160,10 @@ static uint16_t bnxt_start_xmit(struct rte_mbuf *tx_pkt,
*cmpl_next = false;
}
txbd->len = tx_pkt->data_len;
- if (txbd->len >= 2014)
+ if (tx_pkt->pkt_len >= 2014)
txbd->flags_type |= TX_BD_LONG_FLAGS_LHINT_GTE2K;
else
- txbd->flags_type |= lhint_arr[txbd->len >> 9];
+ txbd->flags_type |= lhint_arr[tx_pkt->pkt_len >> 9];
txbd->address = rte_cpu_to_le_32(rte_mbuf_data_iova(tx_buf->mbuf));
if (long_bd) {
--
2.15.1 (Apple Git-101)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [dpdk-stable] [PATCH 28/31] net/bnxt: fix set MTU
[not found] <20180619213058.12273-1-ajit.khaparde@broadcom.com>
` (3 preceding siblings ...)
2018-06-19 21:30 ` [dpdk-stable] [PATCH 25/31] net/bnxt: fix Tx with multiple mbuf Ajit Khaparde
@ 2018-06-19 21:30 ` Ajit Khaparde
2018-06-26 15:30 ` Ferruh Yigit
2018-06-19 21:30 ` [dpdk-stable] [PATCH 29/31] net/bnxt: fix incorrect IO address handling in Tx Ajit Khaparde
2018-06-19 21:30 ` [dpdk-stable] [PATCH 31/31] net/bnxt: fix to move a flow to a different queue Ajit Khaparde
6 siblings, 1 reply; 11+ messages in thread
From: Ajit Khaparde @ 2018-06-19 21:30 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, stable
There is no need to update hardware configuration if new MTU is
not greater than the max data the mbuf can accommodate.
Fixes: daef48efe5e5 ("net/bnxt: support set MTU")
Cc: stable@dpdk.org
Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
---
drivers/net/bnxt/bnxt_ethdev.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 9cfa43778..1145bc195 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1597,6 +1597,7 @@ static int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev, uint16_t new_mtu)
for (i = 0; i < bp->nr_vnics; i++) {
struct bnxt_vnic_info *vnic = &bp->vnic_info[i];
+ uint16_t size = 0;
vnic->mru = bp->eth_dev->data->mtu + ETHER_HDR_LEN +
ETHER_CRC_LEN + VLAN_TAG_SIZE * 2;
@@ -1604,9 +1605,14 @@ static int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev, uint16_t new_mtu)
if (rc)
break;
- rc = bnxt_hwrm_vnic_plcmode_cfg(bp, vnic);
- if (rc)
- return rc;
+ size = rte_pktmbuf_data_room_size(bp->rx_queues[0]->mb_pool);
+ size -= RTE_PKTMBUF_HEADROOM;
+
+ if (size < new_mtu) {
+ rc = bnxt_hwrm_vnic_plcmode_cfg(bp, vnic);
+ if (rc)
+ return rc;
+ }
}
return rc;
--
2.15.1 (Apple Git-101)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [dpdk-stable] [PATCH 29/31] net/bnxt: fix incorrect IO address handling in Tx
[not found] <20180619213058.12273-1-ajit.khaparde@broadcom.com>
` (4 preceding siblings ...)
2018-06-19 21:30 ` [dpdk-stable] [PATCH 28/31] net/bnxt: fix set MTU Ajit Khaparde
@ 2018-06-19 21:30 ` Ajit Khaparde
2018-06-19 21:30 ` [dpdk-stable] [PATCH 31/31] net/bnxt: fix to move a flow to a different queue Ajit Khaparde
6 siblings, 0 replies; 11+ messages in thread
From: Ajit Khaparde @ 2018-06-19 21:30 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, stable
rte_mbuf_data_iova returns a 64-bit address. But we are incorrectly
using only 32-bits of that. Use rte_cpu_to_le_64 instead of
rte_cpu_to_le_32
Fixes: 6eb3cc2294fd ("net/bnxt: add initial Tx code")
Cc: stable@dpdk.org
Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
---
drivers/net/bnxt/bnxt_txr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_txr.c b/drivers/net/bnxt/bnxt_txr.c
index 23c8e6660..4e684f208 100644
--- a/drivers/net/bnxt/bnxt_txr.c
+++ b/drivers/net/bnxt/bnxt_txr.c
@@ -164,7 +164,7 @@ static uint16_t bnxt_start_xmit(struct rte_mbuf *tx_pkt,
txbd->flags_type |= TX_BD_LONG_FLAGS_LHINT_GTE2K;
else
txbd->flags_type |= lhint_arr[tx_pkt->pkt_len >> 9];
- txbd->address = rte_cpu_to_le_32(rte_mbuf_data_iova(tx_buf->mbuf));
+ txbd->address = rte_cpu_to_le_64(rte_mbuf_data_iova(tx_buf->mbuf));
if (long_bd) {
txbd->flags_type |= TX_BD_LONG_TYPE_TX_BD_LONG;
@@ -287,7 +287,7 @@ static uint16_t bnxt_start_xmit(struct rte_mbuf *tx_pkt,
tx_buf = &txr->tx_buf_ring[txr->tx_prod];
txbd = &txr->tx_desc_ring[txr->tx_prod];
- txbd->address = rte_cpu_to_le_32(rte_mbuf_data_iova(m_seg));
+ txbd->address = rte_cpu_to_le_64(rte_mbuf_data_iova(m_seg));
txbd->flags_type |= TX_BD_SHORT_TYPE_TX_BD_SHORT;
txbd->len = m_seg->data_len;
--
2.15.1 (Apple Git-101)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [dpdk-stable] [PATCH 31/31] net/bnxt: fix to move a flow to a different queue
[not found] <20180619213058.12273-1-ajit.khaparde@broadcom.com>
` (5 preceding siblings ...)
2018-06-19 21:30 ` [dpdk-stable] [PATCH 29/31] net/bnxt: fix incorrect IO address handling in Tx Ajit Khaparde
@ 2018-06-19 21:30 ` Ajit Khaparde
6 siblings, 0 replies; 11+ messages in thread
From: Ajit Khaparde @ 2018-06-19 21:30 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, Somnath Kotur, stable
From: Somnath Kotur <somnath.kotur@broadcom.com>
While moving a flow to a different destination queue,
the l2_filter_id being passed to the FW command was incorrect.
Fix it by re-using the matching filter's l2_filter_id since
that is supposed to be the same in this case.
Fixes: 5ef3b79fdfe6 ("net/bnxt: support flow filter ops")
Cc: stable@dpdk.org
Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com>
Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
---
drivers/net/bnxt/bnxt_flow.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bnxt/bnxt_flow.c b/drivers/net/bnxt/bnxt_flow.c
index a491e9dbf..ac7656741 100644
--- a/drivers/net/bnxt/bnxt_flow.c
+++ b/drivers/net/bnxt/bnxt_flow.c
@@ -968,9 +968,13 @@ bnxt_match_filter(struct bnxt *bp, struct bnxt_filter_info *nf)
sizeof(nf->dst_ipaddr_mask))) {
if (mf->dst_id == nf->dst_id)
return -EEXIST;
- /* Same Flow, Different queue
+ /*
+ * Same Flow, Different queue
* Clear the old ntuple filter
+ * Reuse the matching L2 filter
+ * ID for the new filter
*/
+ nf->fw_l2_filter_id = mf->fw_l2_filter_id;
if (nf->filter_type == HWRM_CFA_EM_FILTER)
bnxt_hwrm_clear_em_filter(bp, mf);
if (nf->filter_type == HWRM_CFA_NTUPLE_FILTER)
--
2.15.1 (Apple Git-101)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-stable] [PATCH 05/31] net/bnxt: fix dev close operation
2018-06-19 21:30 ` [dpdk-stable] [PATCH 05/31] net/bnxt: fix dev close operation Ajit Khaparde
@ 2018-06-26 15:28 ` Ferruh Yigit
2018-06-28 20:16 ` Ajit Khaparde
0 siblings, 1 reply; 11+ messages in thread
From: Ferruh Yigit @ 2018-06-26 15:28 UTC (permalink / raw)
To: Ajit Khaparde, dev; +Cc: stable
On 6/19/2018 10:30 PM, Ajit Khaparde wrote:
> We are not cleaning up all the memory and also not unregistering
> the driver during device close operation. This patch fixes the issue.
>
> Fixes: 893074951314 (net/bnxt: free memory in close operation)
> Cc: stable@dpdk.org
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
<...>
> @@ -3408,13 +3410,15 @@ bnxt_dev_init(struct rte_eth_dev *eth_dev)
> }
>
> static int
> -bnxt_dev_uninit(struct rte_eth_dev *eth_dev) {
> +bnxt_dev_uninit(struct rte_eth_dev *eth_dev)
> +{
> struct bnxt *bp = eth_dev->data->dev_private;
> int rc;
>
> if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> return -EPERM;
>
> + PMD_DRV_LOG(INFO, "Calling Device uninit\n");
This looks like can be a debug message, what do you think?
<...>
> @@ -3456,7 +3469,7 @@ static int bnxt_pci_remove(struct rte_pci_device *pci_dev)
> static struct rte_pci_driver bnxt_rte_pmd = {
> .id_table = bnxt_pci_id_map,
> .drv_flags = RTE_PCI_DRV_NEED_MAPPING |
> - RTE_PCI_DRV_INTR_LSC,
> + RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_INTR_RMV,
Is Remove interrupts really supported? I can't find the related code in the driver.
You need to call _rte_eth_dev_callback_process() for RTE_ETH_EVENT_INTR_RMV
where you handle the interrupt.
And announce the feature "Removal event" in bnxt.ini
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-stable] [PATCH 28/31] net/bnxt: fix set MTU
2018-06-19 21:30 ` [dpdk-stable] [PATCH 28/31] net/bnxt: fix set MTU Ajit Khaparde
@ 2018-06-26 15:30 ` Ferruh Yigit
2018-06-28 20:13 ` Ajit Khaparde
0 siblings, 1 reply; 11+ messages in thread
From: Ferruh Yigit @ 2018-06-26 15:30 UTC (permalink / raw)
To: Ajit Khaparde, dev; +Cc: stable
On 6/19/2018 10:30 PM, Ajit Khaparde wrote:
> There is no need to update hardware configuration if new MTU is
> not greater than the max data the mbuf can accommodate.
If app sets a smaller MTU won't it expect that HW will drop received packets
bigger than provided size? Will this logic work if HW is not updated?
>
> Fixes: daef48efe5e5 ("net/bnxt: support set MTU")
> Cc: stable@dpdk.org
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> ---
> drivers/net/bnxt/bnxt_ethdev.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
> index 9cfa43778..1145bc195 100644
> --- a/drivers/net/bnxt/bnxt_ethdev.c
> +++ b/drivers/net/bnxt/bnxt_ethdev.c
> @@ -1597,6 +1597,7 @@ static int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev, uint16_t new_mtu)
>
> for (i = 0; i < bp->nr_vnics; i++) {
> struct bnxt_vnic_info *vnic = &bp->vnic_info[i];
> + uint16_t size = 0;
>
> vnic->mru = bp->eth_dev->data->mtu + ETHER_HDR_LEN +
> ETHER_CRC_LEN + VLAN_TAG_SIZE * 2;
> @@ -1604,9 +1605,14 @@ static int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev, uint16_t new_mtu)
> if (rc)
> break;
>
> - rc = bnxt_hwrm_vnic_plcmode_cfg(bp, vnic);
> - if (rc)
> - return rc;
> + size = rte_pktmbuf_data_room_size(bp->rx_queues[0]->mb_pool);
> + size -= RTE_PKTMBUF_HEADROOM;
> +
> + if (size < new_mtu) {
> + rc = bnxt_hwrm_vnic_plcmode_cfg(bp, vnic);
> + if (rc)
> + return rc;
> + }
> }
>
> return rc;
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-stable] [PATCH 28/31] net/bnxt: fix set MTU
2018-06-26 15:30 ` Ferruh Yigit
@ 2018-06-28 20:13 ` Ajit Khaparde
0 siblings, 0 replies; 11+ messages in thread
From: Ajit Khaparde @ 2018-06-28 20:13 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, dpdk stable
On Tue, Jun 26, 2018 at 8:30 AM, Ferruh Yigit <ferruh.yigit@intel.com>
wrote:
> On 6/19/2018 10:30 PM, Ajit Khaparde wrote:
> > There is no need to update hardware configuration if new MTU is
> > not greater than the max data the mbuf can accommodate.
>
> If app sets a smaller MTU won't it expect that HW will drop received
> packets
> bigger than provided size? Will this logic work if HW is not updated?
>
Actually, the commit message needs rephrased.
The behavior you mentioned will not be impacted.
The hardware will honor the MTU configured.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-stable] [PATCH 05/31] net/bnxt: fix dev close operation
2018-06-26 15:28 ` Ferruh Yigit
@ 2018-06-28 20:16 ` Ajit Khaparde
0 siblings, 0 replies; 11+ messages in thread
From: Ajit Khaparde @ 2018-06-28 20:16 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, dpdk stable
>
> > + PMD_DRV_LOG(INFO, "Calling Device uninit\n");
>
> This looks like can be a debug message, what do you think?
>
Yes. Changed it to debug.
>
> <...>
>
> > @@ -3456,7 +3469,7 @@ static int bnxt_pci_remove(struct rte_pci_device
> *pci_dev)
> > static struct rte_pci_driver bnxt_rte_pmd = {
> > .id_table = bnxt_pci_id_map,
> > .drv_flags = RTE_PCI_DRV_NEED_MAPPING |
> > - RTE_PCI_DRV_INTR_LSC,
> > + RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_INTR_RMV,
>
> Is Remove interrupts really supported? I can't find the related code in
> the driver.
>
That was some left over code. I cleaned it up.
Thanks
>
> You need to call _rte_eth_dev_callback_process() for
> RTE_ETH_EVENT_INTR_RMV
> where you handle the interrupt.
>
> And announce the feature "Removal event" in bnxt.ini
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-06-28 20:17 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20180619213058.12273-1-ajit.khaparde@broadcom.com>
2018-06-19 21:30 ` [dpdk-stable] [PATCH 01/31] net/bnxt: fix clear port stats Ajit Khaparde
2018-06-19 21:30 ` [dpdk-stable] [PATCH 05/31] net/bnxt: fix dev close operation Ajit Khaparde
2018-06-26 15:28 ` Ferruh Yigit
2018-06-28 20:16 ` Ajit Khaparde
2018-06-19 21:30 ` [dpdk-stable] [PATCH 07/31] net/bnxt: fix HW Tx checksum offload check Ajit Khaparde
2018-06-19 21:30 ` [dpdk-stable] [PATCH 25/31] net/bnxt: fix Tx with multiple mbuf Ajit Khaparde
2018-06-19 21:30 ` [dpdk-stable] [PATCH 28/31] net/bnxt: fix set MTU Ajit Khaparde
2018-06-26 15:30 ` Ferruh Yigit
2018-06-28 20:13 ` Ajit Khaparde
2018-06-19 21:30 ` [dpdk-stable] [PATCH 29/31] net/bnxt: fix incorrect IO address handling in Tx Ajit Khaparde
2018-06-19 21:30 ` [dpdk-stable] [PATCH 31/31] net/bnxt: fix to move a flow to a different queue Ajit Khaparde
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).