* [rdma-core patch v3] srp_daemon: improve the debug message for is_enabled_by_rules_file
From: Honggang Li @ 2019-07-15 4:16 UTC (permalink / raw)
To: bvanassche, jgg; +Cc: linux-rdma, Honggang Li
If the target was disallowed by rule file, user can not distinguish that
from the old debug message.
pr_debug("Found an SRP target with id_ext %s - check if it allowed by rules file\n", target->id_ext);
It implicitly implied by the message next to the old debug message.
pr_debug("Found an SRP target with id_ext %s - check if it is already connected\n", target->id_ext);
The improved debug message will feedback the check result of rule file, user
no longer needs to wonder the target is allowed or not.
Signed-off-by: Honggang Li <honli@redhat.com>
---
srp_daemon/srp_daemon.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/srp_daemon/srp_daemon.c b/srp_daemon/srp_daemon.c
index a004f6a4..e85b9668 100644
--- a/srp_daemon/srp_daemon.c
+++ b/srp_daemon/srp_daemon.c
@@ -349,10 +349,11 @@ static int is_enabled_by_rules_file(struct target_details *target)
int rule;
struct config_t *conf = config;
- if (NULL == conf->rules)
+ if (NULL == conf->rules) {
+ pr_debug("Allowing SRP target with id_ext %s because not using a rules file\n", target->id_ext);
return 1;
+ }
- pr_debug("Found an SRP target with id_ext %s - check if it allowed by rules file\n", target->id_ext);
rule = -1;
do {
rule++;
@@ -392,6 +393,9 @@ static int is_enabled_by_rules_file(struct target_details *target)
target->options = conf->rules[rule].options;
+ pr_debug("SRP target with id_ext %s %s by rules file\n",
+ target->id_ext,
+ conf->rules[rule].allow ? "allowed" : "disallowed");
return conf->rules[rule].allow;
} while (1);
--
2.20.1
^ permalink raw reply related
* [PATCH v3 17/24] ethernet: remove redundant memset
From: Fuqian Huang @ 2019-07-15 3:19 UTC (permalink / raw)
Cc: Jay Cliburn, Chris Snook, David S . Miller, Michael Chan,
Vishal Kulkarni, Fugang Duan, Guo-Fu Tseng, Mirko Lindner,
Stephen Hemminger, Tariq Toukan, Saeed Mahameed, Leon Romanovsky,
Jiri Pirko, Ido Schimmel, Jon Mason, Manish Chopra, Rahul Verma,
GR-Linux-NIC-Dev, Samuel Chessman, netdev, linux-kernel,
linux-rdma, Fuqian Huang
kvzalloc already zeroes the memory during the allocation.
pci_alloc_consistent calls dma_alloc_coherent directly.
In commit 518a2f1925c3
("dma-mapping: zero memory returned from dma_alloc_*"),
dma_alloc_coherent has already zeroed the memory.
So the memset after these function is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
Changes in v3:
- Use actual commit rather than the merge commit in the commit message
drivers/net/ethernet/atheros/atlx/atl1.c | 2 --
drivers/net/ethernet/atheros/atlx/atl2.c | 1 -
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 --
drivers/net/ethernet/chelsio/cxgb4/sched.c | 1 -
drivers/net/ethernet/freescale/fec_main.c | 2 --
drivers/net/ethernet/jme.c | 5 -----
drivers/net/ethernet/marvell/skge.c | 2 --
drivers/net/ethernet/mellanox/mlx4/eq.c | 2 --
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 1 -
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 3 ---
drivers/net/ethernet/mellanox/mlxsw/pci.c | 1 -
drivers/net/ethernet/neterion/s2io.c | 1 -
drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c | 3 ---
drivers/net/ethernet/ti/tlan.c | 1 -
14 files changed, 27 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c b/drivers/net/ethernet/atheros/atlx/atl1.c
index 7c767ce9aafa..b5c6dc914720 100644
--- a/drivers/net/ethernet/atheros/atlx/atl1.c
+++ b/drivers/net/ethernet/atheros/atlx/atl1.c
@@ -1060,8 +1060,6 @@ static s32 atl1_setup_ring_resources(struct atl1_adapter *adapter)
goto err_nomem;
}
- memset(ring_header->desc, 0, ring_header->size);
-
/* init TPD ring */
tpd_ring->dma = ring_header->dma;
offset = (tpd_ring->dma & 0x7) ? (8 - (ring_header->dma & 0x7)) : 0;
diff --git a/drivers/net/ethernet/atheros/atlx/atl2.c b/drivers/net/ethernet/atheros/atlx/atl2.c
index 3a3fb5ce0fee..3aba38322717 100644
--- a/drivers/net/ethernet/atheros/atlx/atl2.c
+++ b/drivers/net/ethernet/atheros/atlx/atl2.c
@@ -291,7 +291,6 @@ static s32 atl2_setup_ring_resources(struct atl2_adapter *adapter)
&adapter->ring_dma);
if (!adapter->ring_vir_addr)
return -ENOMEM;
- memset(adapter->ring_vir_addr, 0, adapter->ring_size);
/* Init TXD Ring */
adapter->txd_dma = adapter->ring_dma ;
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 3f632028eff0..1069eb01cc55 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -2677,8 +2677,6 @@ static int bnxt_alloc_tx_rings(struct bnxt *bp)
mapping = txr->tx_push_mapping +
sizeof(struct tx_push_bd);
txr->data_mapping = cpu_to_le64(mapping);
-
- memset(txr->tx_push, 0, sizeof(struct tx_push_bd));
}
qidx = bp->tc_to_qidx[j];
ring->queue_id = bp->q_info[qidx].queue_id;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sched.c b/drivers/net/ethernet/chelsio/cxgb4/sched.c
index ba6c153ee45c..60218dc676a8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sched.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sched.c
@@ -207,7 +207,6 @@ static int t4_sched_queue_bind(struct port_info *pi, struct ch_sched_queue *p)
goto out_err;
/* Bind queue to specified class */
- memset(qe, 0, sizeof(*qe));
qe->cntxt_id = qid;
memcpy(&qe->param, p, sizeof(qe->param));
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 9d459ccf251d..e5610a4da539 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3144,8 +3144,6 @@ static int fec_enet_init(struct net_device *ndev)
return -ENOMEM;
}
- memset(cbd_base, 0, bd_size);
-
/* Get the Ethernet address */
fec_get_mac(ndev);
/* make sure MAC we just acquired is programmed into the hw */
diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index 76b7b7b85e35..0b668357db4d 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -582,11 +582,6 @@ jme_setup_tx_resources(struct jme_adapter *jme)
if (unlikely(!(txring->bufinf)))
goto err_free_txring;
- /*
- * Initialize Transmit Descriptors
- */
- memset(txring->alloc, 0, TX_RING_ALLOC_SIZE(jme->tx_ring_size));
-
return 0;
err_free_txring:
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 35a92fd2cf39..9ac854c2b371 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -2558,8 +2558,6 @@ static int skge_up(struct net_device *dev)
goto free_pci_mem;
}
- memset(skge->mem, 0, skge->mem_size);
-
err = skge_ring_alloc(&skge->rx_ring, skge->mem, skge->dma);
if (err)
goto free_pci_mem;
diff --git a/drivers/net/ethernet/mellanox/mlx4/eq.c b/drivers/net/ethernet/mellanox/mlx4/eq.c
index a5be27772b8e..c790a5fcea73 100644
--- a/drivers/net/ethernet/mellanox/mlx4/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/eq.c
@@ -1013,8 +1013,6 @@ static int mlx4_create_eq(struct mlx4_dev *dev, int nent,
dma_list[i] = t;
eq->page_list[i].map = t;
-
- memset(eq->page_list[i].buf, 0, PAGE_SIZE);
}
eq->eqn = mlx4_bitmap_alloc(&priv->eq_table.bitmap);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 3b04d8927fb1..1f3891fde2eb 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -2450,7 +2450,6 @@ int mlx5_eswitch_get_vport_stats(struct mlx5_eswitch *esw,
MLX5_SET(query_vport_counter_in, in, vport_number, vport->vport);
MLX5_SET(query_vport_counter_in, in, other_vport, 1);
- memset(out, 0, outlen);
err = mlx5_cmd_exec(esw->dev, in, sizeof(in), out, outlen);
if (err)
goto free_out;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 957d9b09dc3f..089ae4d48a82 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -1134,7 +1134,6 @@ static int esw_create_offloads_fdb_tables(struct mlx5_eswitch *esw, int nvports)
}
/* create send-to-vport group */
- memset(flow_group_in, 0, inlen);
MLX5_SET(create_flow_group_in, flow_group_in, match_criteria_enable,
MLX5_MATCH_MISC_PARAMETERS);
@@ -1293,8 +1292,6 @@ static int esw_create_vport_rx_group(struct mlx5_eswitch *esw, int nvports)
return -ENOMEM;
/* create vport rx group */
- memset(flow_group_in, 0, inlen);
-
esw_set_flow_group_source_port(esw, flow_group_in);
MLX5_SET(create_flow_group_in, flow_group_in, start_flow_index, 0);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c b/drivers/net/ethernet/mellanox/mlxsw/pci.c
index 051b19388a81..615455a21567 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -847,7 +847,6 @@ static int mlxsw_pci_queue_init(struct mlxsw_pci *mlxsw_pci, char *mbox,
&mem_item->mapaddr);
if (!mem_item->buf)
return -ENOMEM;
- memset(mem_item->buf, 0, mem_item->size);
q->elem_info = kcalloc(q->count, sizeof(*q->elem_info), GFP_KERNEL);
if (!q->elem_info) {
diff --git a/drivers/net/ethernet/neterion/s2io.c b/drivers/net/ethernet/neterion/s2io.c
index 3b2ae1a21678..e0b2bf327905 100644
--- a/drivers/net/ethernet/neterion/s2io.c
+++ b/drivers/net/ethernet/neterion/s2io.c
@@ -747,7 +747,6 @@ static int init_shared_mem(struct s2io_nic *nic)
return -ENOMEM;
}
mem_allocated += size;
- memset(tmp_v_addr, 0, size);
size = sizeof(struct rxd_info) *
rxd_count[nic->rxd_mode];
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c
index 433052f734ed..5e9f8ee99800 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c
@@ -442,10 +442,8 @@ nx_fw_cmd_create_tx_ctx(struct netxen_adapter *adapter)
goto out_free_rq;
}
- memset(rq_addr, 0, rq_size);
prq = rq_addr;
- memset(rsp_addr, 0, rsp_size);
prsp = rsp_addr;
prq->host_rsp_dma_addr = cpu_to_le64(rsp_phys_addr);
@@ -755,7 +753,6 @@ int netxen_alloc_hw_resources(struct netxen_adapter *adapter)
return -ENOMEM;
}
- memset(addr, 0, sizeof(struct netxen_ring_ctx));
recv_ctx->hwctx = addr;
recv_ctx->hwctx->ctx_id = cpu_to_le32(port);
recv_ctx->hwctx->cmd_consumer_offset =
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index b4ab1a5f6cd0..78f0f2d59e22 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -855,7 +855,6 @@ static int tlan_init(struct net_device *dev)
dev->name);
return -ENOMEM;
}
- memset(priv->dma_storage, 0, dma_size);
priv->rx_list = (struct tlan_list *)
ALIGN((unsigned long)priv->dma_storage, 8);
priv->rx_list_dma = ALIGN(priv->dma_storage_dma, 8);
--
2.11.0
^ permalink raw reply related
* [PATCH v3 13/24] IB/ipoib: remove unneeded memset
From: Fuqian Huang @ 2019-07-15 3:18 UTC (permalink / raw)
Cc: Doug Ledford, Jason Gunthorpe, linux-rdma, linux-kernel,
Fuqian Huang
vzalloc has already zeroed the memory during the allocation.
So memset is unneeded.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index aa9dcfc36cd3..c59e00a0881f 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1153,7 +1153,6 @@ static int ipoib_cm_tx_init(struct ipoib_cm_tx *p, u32 qpn,
ret = -ENOMEM;
goto err_tx;
}
- memset(p->tx_ring, 0, ipoib_sendq_size * sizeof(*p->tx_ring));
p->qp = ipoib_cm_create_tx_qp(p->dev, p);
memalloc_noio_restore(noio_flag);
--
2.11.0
^ permalink raw reply related
* [PATCH v3 12/24] RDMA/ocrdma: Remove call to memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-07-15 3:18 UTC (permalink / raw)
Cc: Selvin Xavier, Devesh Sharma, Doug Ledford, Jason Gunthorpe,
linux-rdma, linux-kernel, Fuqian Huang
In commit 518a2f1925c3
("dma-mapping: zero memory returned from dma_alloc_*"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
Changes in v3:
- Use actual commit rather than the merge commit in the commit message
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
index 5127e2ea4bdd..6e07712eb3ed 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
@@ -1351,7 +1351,6 @@ static int ocrdma_mbx_get_ctrl_attribs(struct ocrdma_dev *dev)
mqe->u.nonemb_req.sge[0].pa_hi = (u32) upper_32_bits(dma.pa);
mqe->u.nonemb_req.sge[0].len = dma.size;
- memset(dma.va, 0, dma.size);
ocrdma_init_mch((struct ocrdma_mbx_hdr *)dma.va,
OCRDMA_CMD_GET_CTRL_ATTRIBUTES,
OCRDMA_SUBSYS_COMMON,
@@ -1690,7 +1689,6 @@ static int ocrdma_mbx_create_ah_tbl(struct ocrdma_dev *dev)
goto mem_err_ah;
dev->av_tbl.pa = pa;
dev->av_tbl.num_ah = max_ah;
- memset(dev->av_tbl.va, 0, dev->av_tbl.size);
pbes = (struct ocrdma_pbe *)dev->av_tbl.pbl.va;
for (i = 0; i < dev->av_tbl.size / OCRDMA_MIN_Q_PAGE_SIZE; i++) {
@@ -2905,7 +2903,6 @@ static int ocrdma_mbx_get_dcbx_config(struct ocrdma_dev *dev, u32 ptype,
mqe_sge->pa_hi = (u32) upper_32_bits(pa);
mqe_sge->len = cmd.hdr.pyld_len;
- memset(req, 0, sizeof(struct ocrdma_get_dcbx_cfg_req));
ocrdma_init_mch(&req->hdr, OCRDMA_CMD_GET_DCBX_CONFIG,
OCRDMA_SUBSYS_DCBX, cmd.hdr.pyld_len);
req->param_type = ptype;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 11/24] RDMA/nes: Remove call to memset after pci_alloc_consistent
From: Fuqian Huang @ 2019-07-15 3:18 UTC (permalink / raw)
Cc: Faisal Latif, Doug Ledford, Jason Gunthorpe, linux-rdma,
linux-kernel, Fuqian Huang
pci_alloc_consitent calls dma_alloc_coherent directly.
In commit 518a2f1925c3
("dma-mapping: zero memory returned from dma_alloc_*"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
Changes in v3:
- Use actual commit rather than the merge commit in the commit message
drivers/infiniband/hw/nes/nes_verbs.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/infiniband/hw/nes/nes_verbs.c b/drivers/infiniband/hw/nes/nes_verbs.c
index 49024326a518..534f978f1a58 100644
--- a/drivers/infiniband/hw/nes/nes_verbs.c
+++ b/drivers/infiniband/hw/nes/nes_verbs.c
@@ -828,7 +828,6 @@ static int nes_setup_virt_qp(struct nes_qp *nesqp, struct nes_pbl *nespbl,
kunmap(nesqp->page);
return -ENOMEM;
}
- memset(nesqp->pbl_vbase, 0, 256);
/* fill in the page address in the pbl buffer.. */
tpbl = pblbuffer + 16;
pbl = (__le64 *)nespbl->pbl_vbase;
@@ -898,8 +897,6 @@ static int nes_setup_mmap_qp(struct nes_qp *nesqp, struct nes_vnic *nesvnic,
"host descriptor rings located @ %p (pa = 0x%08lX.) size = %u.\n",
mem, (unsigned long)nesqp->hwqp.sq_pbase, nesqp->qp_mem_size);
- memset(mem, 0, nesqp->qp_mem_size);
-
nesqp->hwqp.sq_vbase = mem;
mem += sizeof(struct nes_hw_qp_wqe) * sq_size;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 10/24] IB/mthca: Remove call to memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-07-15 3:18 UTC (permalink / raw)
Cc: Doug Ledford, Jason Gunthorpe, linux-rdma, linux-kernel,
Fuqian Huang
In commit 518a2f1925c3
("dma-mapping: zero memory returned from dma_alloc_*"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
Changes in v3:
- Use actual commit rather than the merge commit in the commit message
drivers/infiniband/hw/mthca/mthca_allocator.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_allocator.c b/drivers/infiniband/hw/mthca/mthca_allocator.c
index aaf10dd5364d..aef1d274a14e 100644
--- a/drivers/infiniband/hw/mthca/mthca_allocator.c
+++ b/drivers/infiniband/hw/mthca/mthca_allocator.c
@@ -214,8 +214,6 @@ int mthca_buf_alloc(struct mthca_dev *dev, int size, int max_direct,
dma_unmap_addr_set(&buf->direct, mapping, t);
- memset(buf->direct.buf, 0, size);
-
while (t & ((1 << shift) - 1)) {
--shift;
npages *= 2;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 09/24] rdma/hns: Remove call to memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-07-15 3:17 UTC (permalink / raw)
Cc: Lijun Ou, Wei Hu, Doug Ledford, Jason Gunthorpe, linux-rdma,
linux-kernel, Fuqian Huang
In commit 518a2f1925c3
("dma-mapping: zero memory returned from dma_alloc_*"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
Changes in v3:
- Use actual commit rather than the merge commit in the commit message
drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 1 -
drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 3 ---
2 files changed, 4 deletions(-)
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
index 3afd3e9330e7..a43464e292b6 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
@@ -4265,7 +4265,6 @@ static int hns_roce_v1_create_eq(struct hns_roce_dev *hr_dev,
}
eq->buf_list[i].map = tmp_dma_addr;
- memset(eq->buf_list[i].buf, 0, HNS_ROCE_BA_SIZE);
}
eq->cons_index = 0;
roce_set_field(tmp, ROCEE_CAEP_AEQC_AEQE_SHIFT_CAEP_AEQC_STATE_M,
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
index b5392cb5b20f..a4a7c5962916 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
@@ -1774,7 +1774,6 @@ static int hns_roce_init_link_table(struct hns_roce_dev *hr_dev,
goto err_alloc_buf_failed;
link_tbl->pg_list[i].map = t;
- memset(link_tbl->pg_list[i].buf, 0, buf_chk_sz);
entry[i].blk_ba0 = (t >> 12) & 0xffffffff;
roce_set_field(entry[i].blk_ba1_nxt_ptr,
@@ -5387,8 +5386,6 @@ static int hns_roce_mhop_alloc_eq(struct hns_roce_dev *hr_dev,
eq->cur_eqe_ba = eq->l0_dma;
eq->nxt_eqe_ba = 0;
- memset(eq->bt_l0, 0, eq->entries * eq->eqe_size);
-
return 0;
}
--
2.11.0
^ permalink raw reply related
* [PATCH v3 08/24] rdma/cxgb4: Remove call to memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-07-15 3:17 UTC (permalink / raw)
Cc: Potnuri Bharat Teja, Doug Ledford, Jason Gunthorpe, linux-rdma,
linux-kernel, Fuqian Huang
In commit 518a2f1925c3
("dma-mapping: zero memory returned from dma_alloc_*"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
Changes in v3:
- Use actual commit rather than the merge commit in the commit message
drivers/infiniband/hw/cxgb4/cq.c | 1 -
drivers/infiniband/hw/cxgb4/qp.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/cq.c b/drivers/infiniband/hw/cxgb4/cq.c
index 52ce586621c6..fcd161e3495b 100644
--- a/drivers/infiniband/hw/cxgb4/cq.c
+++ b/drivers/infiniband/hw/cxgb4/cq.c
@@ -104,7 +104,6 @@ static int create_cq(struct c4iw_rdev *rdev, struct t4_cq *cq,
goto err3;
}
dma_unmap_addr_set(cq, mapping, cq->dma_addr);
- memset(cq->queue, 0, cq->memsize);
if (user && ucontext->is_32b_cqe) {
cq->qp_errp = &((struct t4_status_page *)
diff --git a/drivers/infiniband/hw/cxgb4/qp.c b/drivers/infiniband/hw/cxgb4/qp.c
index e92b9544357a..4882dcbb7d20 100644
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -274,7 +274,6 @@ static int create_qp(struct c4iw_rdev *rdev, struct t4_wq *wq,
(unsigned long long)virt_to_phys(wq->sq.queue),
wq->rq.queue,
(unsigned long long)virt_to_phys(wq->rq.queue));
- memset(wq->rq.queue, 0, wq->rq.memsize);
dma_unmap_addr_set(&wq->rq, mapping, wq->rq.dma_addr);
}
--
2.11.0
^ permalink raw reply related
* [PATCH v3 07/24] rdma/cxgb3: Remove call to memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-07-15 3:17 UTC (permalink / raw)
Cc: Potnuri Bharat Teja, Doug Ledford, Jason Gunthorpe, linux-rdma,
linux-kernel, Fuqian Huang
In commit 518a2f1925c3
("dma-mapping: zero memory returned from dma_alloc_*"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
Changes in v3:
- Use actual commit rather than the merge commit in the commit message
drivers/infiniband/hw/cxgb3/cxio_hal.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.c b/drivers/infiniband/hw/cxgb3/cxio_hal.c
index 8ac72ac7cbac..0e37f55678f8 100644
--- a/drivers/infiniband/hw/cxgb3/cxio_hal.c
+++ b/drivers/infiniband/hw/cxgb3/cxio_hal.c
@@ -174,7 +174,6 @@ int cxio_create_cq(struct cxio_rdev *rdev_p, struct t3_cq *cq, int kernel)
return -ENOMEM;
}
dma_unmap_addr_set(cq, mapping, cq->dma_addr);
- memset(cq->queue, 0, size);
setup.id = cq->cqid;
setup.base_addr = (u64) (cq->dma_addr);
setup.size = 1UL << cq->size_log2;
@@ -538,8 +537,6 @@ static int cxio_hal_init_ctrl_qp(struct cxio_rdev *rdev_p)
dma_unmap_addr_set(&rdev_p->ctrl_qp, mapping,
rdev_p->ctrl_qp.dma_addr);
rdev_p->ctrl_qp.doorbell = (void __iomem *)rdev_p->rnic_info.kdb_addr;
- memset(rdev_p->ctrl_qp.workq, 0,
- (1 << T3_CTRL_QP_SIZE_LOG2) * sizeof(union t3_wr));
mutex_init(&rdev_p->ctrl_qp.lock);
init_waitqueue_head(&rdev_p->ctrl_qp.waitq);
--
2.11.0
^ permalink raw reply related
* Re: [GIT PULL] Please pull hmm changes
From: pr-tracker-bot @ 2019-07-15 3:00 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Linus Torvalds, Andrew Morton, Dan Williams, Christoph Hellwig,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org, David Airlie,
Daniel Vetter, amd-gfx@lists.freedesktop.org, Kuehling, Felix,
Deucher, Alexander, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190709192418.GA13677@ziepe.ca>
The pull request you sent on Tue, 9 Jul 2019 19:24:21 +0000:
> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus-hmm
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fec88ab0af9706b2201e5daf377c5031c62d11f7
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [GIT PULL] Please pull hmm changes
From: Linus Torvalds @ 2019-07-15 2:48 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andrew Morton, Dan Williams, Christoph Hellwig,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org, David Airlie,
Daniel Vetter, amd-gfx@lists.freedesktop.org, Kuehling, Felix,
Deucher, Alexander, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190709192418.GA13677@ziepe.ca>
On Tue, Jul 9, 2019 at 12:24 PM Jason Gunthorpe <jgg@mellanox.com> wrote:
>
> I'm sending it early as it is now a dependency for several patches in
> mm's quilt.
.. but I waited to merge it until I had time to review it more
closely, because I expected the review to be painful.
I'm happy to say that I was overly pessimistic, and that instead of
finding things to hate, I found it all looking good.
Particularly the whole "use reference counts properly, so that
lifetimes make sense and all those nasty cases can't happen" parts.
It's all merged, just waiting for the test-build to verify that I
didn't miss anything (well, at least nothing obvious).
Linus
^ permalink raw reply
* Re: [PATCH rdma-next] lib/dim: Prevent overflow in calculation of ratio statistics
From: Leon Romanovsky @ 2019-07-14 10:54 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: Doug Ledford, RDMA mailing list, Yamin Friedman
In-Reply-To: <20190712152315.GD27526@mellanox.com>
On Fri, Jul 12, 2019 at 03:23:20PM +0000, Jason Gunthorpe wrote:
> On Fri, Jul 12, 2019 at 09:03:09AM +0300, Leon Romanovsky wrote:
> > On Thu, Jul 11, 2019 at 05:31:14PM +0000, Jason Gunthorpe wrote:
> > > On Thu, Jul 11, 2019 at 08:19:22PM +0300, Leon Romanovsky wrote:
> > > > On Thu, Jul 11, 2019 at 04:11:07PM +0000, Jason Gunthorpe wrote:
> > > > > On Thu, Jul 11, 2019 at 06:47:34PM +0300, Leon Romanovsky wrote:
> > > > > > > > diff --git a/lib/dim/dim.c b/lib/dim/dim.c
> > > > > > > > index 439d641ec796..38045d6d0538 100644
> > > > > > > > +++ b/lib/dim/dim.c
> > > > > > > > @@ -74,8 +74,8 @@ void dim_calc_stats(struct dim_sample *start, struct dim_sample *end,
> > > > > > > > delta_us);
> > > > > > > > curr_stats->cpms = DIV_ROUND_UP(ncomps * USEC_PER_MSEC, delta_us);
> > > > > > > > if (curr_stats->epms != 0)
> > > > > > > > - curr_stats->cpe_ratio =
> > > > > > > > - (curr_stats->cpms * 100) / curr_stats->epms;
> > > > > > > > + curr_stats->cpe_ratio = DIV_ROUND_DOWN_ULL(
> > > > > > > > + curr_stats->cpms * 100, curr_stats->epms);
> > > > > > >
> > > > > > > This will still potentially overfow the 'int' for cpe_ratio if epms <
> > > > > > > 100 ?
> > > > > >
> > > > > > I assumed that assignment to "unsigned long long" will do the trick.
> > > > > > https://elixir.bootlin.com/linux/latest/source/include/linux/kernel.h#L94
> > > > >
> > > > > That only protects the multiply, the result of DIV_ROUND_DOWN_ULL is
> > > > > casted to int.
> > > >
> > > > It is ok, the result is "int" and it will be small, 100 in multiply
> > > > represents percentage.
> > >
> > > Percentage would be divide by 100..
> > >
> > > Like I said it will overflow if epms < 100 ...
> >
> > It is unlikely to happen because cpe_ratio is between 0 to 100 and cpms
> > * 100 is not large at all.
> >
> > UBSAN error is "theoretical" overflow.
>
> ? UBSAN is not theoretical, it only triggers if something actually
> happens. So in this case cpms*100 was very large and overflowed.
>
> Maybe it shouldn't be and that is the actual bug, but if we overflowed
> with cpms*100, then epms must be > 100 or we still overflow the
> divide.
I think that the real bug is cpms became too big.
Thanks
>
> Jason
^ permalink raw reply
* Re: regression: nvme rdma with bnxt_re0 broken
From: Selvin Xavier @ 2019-07-13 16:00 UTC (permalink / raw)
To: Yi Zhang
Cc: Parav Pandit, Daniel Jurgens, linux-rdma@vger.kernel.org,
Devesh Sharma, linux-nvme@lists.infradead.org
In-Reply-To: <5496cdb1-3c07-2d44-cb1f-2d084e5a7919@redhat.com>
On Sat, Jul 13, 2019 at 1:26 PM Yi Zhang <yi.zhang@redhat.com> wrote:
>
> Hi Salvin
>
> Confirmed the patch fixed the login issue.
>
Thanks Yi for the confirmation. I will post this patch.
> And from the dmesg I found there is only one I/O queue created, is that
> reasonable? there are more queues created during my testing for IB/iWARP.
num_comp_vectors exported by bnxt_re is 1 and this is expected due to that.
This can be increased. I will post a patch after doing some testing
for the same.
>
> # nvme connect-all -t rdma -a 172.31.40.125 -s 4420
>
> # lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> sda 8:0 0 931.5G 0 disk
> ├─sda1 8:1 0 1G 0 part /boot
> ├─sda2 8:2 0 25G 0 part /mnt/rdma-ext4
> ├─sda3 8:3 0 25G 0 part /mnt/rdma-xfs
> ├─sda4 8:4 0 1K 0 part
> ├─sda5 8:5 0 15.7G 0 part [SWAP]
> └─sda6 8:6 0 864.9G 0 part /
> nvme0n1 259:405 0 250G 0 disk
>
> # dmesg
> [ 4311.635430] nvme nvme0: new ctrl: NQN
> "nqn.2014-08.org.nvmexpress.discovery", addr 172.31.40.125:4420
> [ 4311.646687] nvme nvme0: Removing ctrl: NQN
> "nqn.2014-08.org.nvmexpress.discovery"
> [ 4311.706052] nvme nvme0: creating 1 I/O queues.
> [ 4311.717848] nvme nvme0: mapped 1/0/0 default/read/poll queues.
> [ 4311.727384] nvme nvme0: new ctrl: NQN "testnqn", addr 172.31.40.125:4420
>
> # lscpu
> Architecture: x86_64
> CPU op-mode(s): 32-bit, 64-bit
> Byte Order: Little Endian
> CPU(s): 16
> On-line CPU(s) list: 0-15
> Thread(s) per core: 2
> Core(s) per socket: 4
> Socket(s): 2
> NUMA node(s): 2
> Vendor ID: GenuineIntel
> CPU family: 6
> Model: 63
> Model name: Intel(R) Xeon(R) CPU E5-2623 v3 @ 3.00GHz
> Stepping: 2
> CPU MHz: 3283.306
> CPU max MHz: 3500.0000
> CPU min MHz: 1200.0000
> BogoMIPS: 5993.72
> Virtualization: VT-x
> L1d cache: 32K
> L1i cache: 32K
> L2 cache: 256K
> L3 cache: 10240K
> NUMA node0 CPU(s): 0,2,4,6,8,10,12,14
> NUMA node1 CPU(s): 1,3,5,7,9,11,13,15
> Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
> pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
> nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor
> ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1
> sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand
> lahf_lm abm cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp
> tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1
> avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm
> ida arat pln pts flush_l1d
>
> On 7/13/19 12:18 AM, Selvin Xavier wrote:
> > On Fri, Jul 12, 2019 at 6:22 PM Parav Pandit <parav@mellanox.com> wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: Yi Zhang <yi.zhang@redhat.com>
> >>> Sent: Friday, July 12, 2019 5:11 PM
> >>> To: Parav Pandit <parav@mellanox.com>; Selvin Xavier
> >>> <selvin.xavier@broadcom.com>
> >>> Cc: Daniel Jurgens <danielj@mellanox.com>; linux-rdma@vger.kernel.org;
> >>> Devesh Sharma <devesh.sharma@broadcom.com>; linux-
> >>> nvme@lists.infradead.org
> >>> Subject: Re: regression: nvme rdma with bnxt_re0 broken
> >>>
> >>> Hi Parav
> >>> The nvme connect still failed[1], I've paste all the dmesg log to[2], pls check it.
> >>>
> >>>
> >>> [1]
> >>> [root@rdma-perf-07 ~]$ nvme connect -t rdma -a 172.31.40.125 -s 4420 -n
> >>> testnqn
> >>> Failed to write to /dev/nvme-fabrics: Connection reset by peer
> >>> [2]
> >>> https://pastebin.com/ipvak0Sp
> >>>
> >> I think vlan_id is not initialized to 0xffff due to which ipv4 entry addition also failed with my patch.
> >> This is probably solves it. Not sure. I am not much familiar with it.
> >>
> >> Selvin,
> >> Can you please take a look?
> >>
> > Parav,
> > Thanks for the patch. I removed the change you made in struct bnxt_qplib_gid
> > and added a new structure struct bnxt_qplib_gid_info to include both
> > gid and vlan_id.
> > struct bnxt_qplib_gid is used in multiple places to memcpy or compare
> > the 16 bytes.
> > Also, added vlan checking in the destroy path also. Some more cleanup
> > possible in
> > delete_gid path. That can be done once the basic issue is fixed.
> >
> > Yi, Can you please test this patch and see if it is solving the issue?
> >
> > Thanks,
> > Selvin
> >
> > From 3d83613cfc5993bf9dae529ab0d4d25ddefff29b Mon Sep 17 00:00:00 2001
> > From: Parav Pandit <parav@mellanox.com>
> > Date: Fri, 12 Jul 2019 10:32:51 -0400
> > Subject: [PATCH] IB/bnxt_re: Honor vlan_id in GID entry comparison
> >
> > GID entry consist of GID, vlan, netdev and smac.
> > Extend GID duplicate check companions to consider vlan_id as well
> > to support IPv6 VLAN based link local addresses.
> >
> > Fixes: 823b23da7113 ("IB/core: Allow vlan link local address based RoCE GIDs")
> > Signed-off-by: Parav Pandit <parav@mellanox.com>
> > Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
> > ---
> > drivers/infiniband/hw/bnxt_re/ib_verbs.c | 7 +++++--
> > drivers/infiniband/hw/bnxt_re/qplib_res.c | 17 +++++++++++++----
> > drivers/infiniband/hw/bnxt_re/qplib_res.h | 2 +-
> > drivers/infiniband/hw/bnxt_re/qplib_sp.c | 14 +++++++++-----
> > drivers/infiniband/hw/bnxt_re/qplib_sp.h | 7 ++++++-
> > 5 files changed, 34 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> > b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> > index a91653aabf38..098ab883733e 100644
> > --- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> > +++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> > @@ -308,6 +308,7 @@ int bnxt_re_del_gid(const struct ib_gid_attr
> > *attr, void **context)
> > struct bnxt_re_dev *rdev = to_bnxt_re_dev(attr->device, ibdev);
> > struct bnxt_qplib_sgid_tbl *sgid_tbl = &rdev->qplib_res.sgid_tbl;
> > struct bnxt_qplib_gid *gid_to_del;
> > + u16 vlan_id = 0xFFFF;
> >
> > /* Delete the entry from the hardware */
> > ctx = *context;
> > @@ -317,7 +318,8 @@ int bnxt_re_del_gid(const struct ib_gid_attr
> > *attr, void **context)
> > if (sgid_tbl && sgid_tbl->active) {
> > if (ctx->idx >= sgid_tbl->max)
> > return -EINVAL;
> > - gid_to_del = &sgid_tbl->tbl[ctx->idx];
> > + gid_to_del = &sgid_tbl->tbl[ctx->idx].gid;
> > + vlan_id = sgid_tbl->tbl[ctx->idx].vlan_id;
> > /* DEL_GID is called in WQ context(netdevice_event_work_handler)
> > * or via the ib_unregister_device path. In the former case QP1
> > * may not be destroyed yet, in which case just return as FW
> > @@ -335,7 +337,8 @@ int bnxt_re_del_gid(const struct ib_gid_attr
> > *attr, void **context)
> > }
> > ctx->refcnt--;
> > if (!ctx->refcnt) {
> > - rc = bnxt_qplib_del_sgid(sgid_tbl, gid_to_del, true);
> > + rc = bnxt_qplib_del_sgid(sgid_tbl, gid_to_del,
> > + vlan_id, true);
> > if (rc) {
> > dev_err(rdev_to_dev(rdev),
> > "Failed to remove GID: %#x", rc);
> > diff --git a/drivers/infiniband/hw/bnxt_re/qplib_res.c
> > b/drivers/infiniband/hw/bnxt_re/qplib_res.c
> > index 37928b1111df..7f2571f7a13f 100644
> > --- a/drivers/infiniband/hw/bnxt_re/qplib_res.c
> > +++ b/drivers/infiniband/hw/bnxt_re/qplib_res.c
> > @@ -488,7 +488,10 @@ static int bnxt_qplib_alloc_sgid_tbl(struct
> > bnxt_qplib_res *res,
> > struct bnxt_qplib_sgid_tbl *sgid_tbl,
> > u16 max)
> > {
> > - sgid_tbl->tbl = kcalloc(max, sizeof(struct bnxt_qplib_gid), GFP_KERNEL);
> > + u16 i;
> > +
> > + sgid_tbl->tbl = kcalloc(max, sizeof(struct bnxt_qplib_gid_info),
> > + GFP_KERNEL);
> > if (!sgid_tbl->tbl)
> > return -ENOMEM;
> >
> > @@ -500,6 +503,9 @@ static int bnxt_qplib_alloc_sgid_tbl(struct
> > bnxt_qplib_res *res,
> > if (!sgid_tbl->ctx)
> > goto out_free2;
> >
> > + for (i = 0; i < max; i++)
> > + sgid_tbl->tbl[i].vlan_id = 0xffff;
> > +
> > sgid_tbl->vlan = kcalloc(max, sizeof(u8), GFP_KERNEL);
> > if (!sgid_tbl->vlan)
> > goto out_free3;
> > @@ -526,9 +532,11 @@ static void bnxt_qplib_cleanup_sgid_tbl(struct
> > bnxt_qplib_res *res,
> > for (i = 0; i < sgid_tbl->max; i++) {
> > if (memcmp(&sgid_tbl->tbl[i], &bnxt_qplib_gid_zero,
> > sizeof(bnxt_qplib_gid_zero)))
> > - bnxt_qplib_del_sgid(sgid_tbl, &sgid_tbl->tbl[i], true);
> > + bnxt_qplib_del_sgid(sgid_tbl, &sgid_tbl->tbl[i].gid,
> > + sgid_tbl->tbl[i].vlan_id, true);
> > }
> > - memset(sgid_tbl->tbl, 0, sizeof(struct bnxt_qplib_gid) * sgid_tbl->max);
> > + memset(sgid_tbl->tbl, 0, sizeof(struct bnxt_qplib_gid_info) *
> > + sgid_tbl->max);
> > memset(sgid_tbl->hw_id, -1, sizeof(u16) * sgid_tbl->max);
> > memset(sgid_tbl->vlan, 0, sizeof(u8) * sgid_tbl->max);
> > sgid_tbl->active = 0;
> > @@ -537,7 +545,8 @@ static void bnxt_qplib_cleanup_sgid_tbl(struct
> > bnxt_qplib_res *res,
> > static void bnxt_qplib_init_sgid_tbl(struct bnxt_qplib_sgid_tbl *sgid_tbl,
> > struct net_device *netdev)
> > {
> > - memset(sgid_tbl->tbl, 0, sizeof(struct bnxt_qplib_gid) * sgid_tbl->max);
> > + memset(sgid_tbl->tbl, 0, sizeof(struct bnxt_qplib_gid_info) *
> > + sgid_tbl->max);
> > memset(sgid_tbl->hw_id, -1, sizeof(u16) * sgid_tbl->max);
> > }
> >
> > diff --git a/drivers/infiniband/hw/bnxt_re/qplib_res.h
> > b/drivers/infiniband/hw/bnxt_re/qplib_res.h
> > index 30c42c92fac7..fbda11a7ab1a 100644
> > --- a/drivers/infiniband/hw/bnxt_re/qplib_res.h
> > +++ b/drivers/infiniband/hw/bnxt_re/qplib_res.h
> > @@ -111,7 +111,7 @@ struct bnxt_qplib_pd_tbl {
> > };
> >
> > struct bnxt_qplib_sgid_tbl {
> > - struct bnxt_qplib_gid *tbl;
> > + struct bnxt_qplib_gid_info *tbl;
> > u16 *hw_id;
> > u16 max;
> > u16 active;
> > diff --git a/drivers/infiniband/hw/bnxt_re/qplib_sp.c
> > b/drivers/infiniband/hw/bnxt_re/qplib_sp.c
> > index 48793d3512ac..40296b97d21e 100644
> > --- a/drivers/infiniband/hw/bnxt_re/qplib_sp.c
> > +++ b/drivers/infiniband/hw/bnxt_re/qplib_sp.c
> > @@ -213,12 +213,12 @@ int bnxt_qplib_get_sgid(struct bnxt_qplib_res *res,
> > index, sgid_tbl->max);
> > return -EINVAL;
> > }
> > - memcpy(gid, &sgid_tbl->tbl[index], sizeof(*gid));
> > + memcpy(gid, &sgid_tbl->tbl[index].gid, sizeof(*gid));
> > return 0;
> > }
> >
> > int bnxt_qplib_del_sgid(struct bnxt_qplib_sgid_tbl *sgid_tbl,
> > - struct bnxt_qplib_gid *gid, bool update)
> > + struct bnxt_qplib_gid *gid, u16 vlan_id, bool update)
> > {
> > struct bnxt_qplib_res *res = to_bnxt_qplib(sgid_tbl,
> > struct bnxt_qplib_res,
> > @@ -236,7 +236,8 @@ int bnxt_qplib_del_sgid(struct bnxt_qplib_sgid_tbl
> > *sgid_tbl,
> > return -ENOMEM;
> > }
> > for (index = 0; index < sgid_tbl->max; index++) {
> > - if (!memcmp(&sgid_tbl->tbl[index], gid, sizeof(*gid)))
> > + if (!memcmp(&sgid_tbl->tbl[index].gid, gid, sizeof(*gid)) &&
> > + vlan_id == sgid_tbl->tbl[index].vlan_id)
> > break;
> > }
> > if (index == sgid_tbl->max) {
> > @@ -262,8 +263,9 @@ int bnxt_qplib_del_sgid(struct bnxt_qplib_sgid_tbl
> > *sgid_tbl,
> > if (rc)
> > return rc;
> > }
> > - memcpy(&sgid_tbl->tbl[index], &bnxt_qplib_gid_zero,
> > + memcpy(&sgid_tbl->tbl[index].gid, &bnxt_qplib_gid_zero,
> > sizeof(bnxt_qplib_gid_zero));
> > + sgid_tbl->tbl[index].vlan_id = 0xFFFF;
> > sgid_tbl->vlan[index] = 0;
> > sgid_tbl->active--;
> > dev_dbg(&res->pdev->dev,
> > @@ -296,7 +298,8 @@ int bnxt_qplib_add_sgid(struct bnxt_qplib_sgid_tbl
> > *sgid_tbl,
> > }
> > free_idx = sgid_tbl->max;
> > for (i = 0; i < sgid_tbl->max; i++) {
> > - if (!memcmp(&sgid_tbl->tbl[i], gid, sizeof(*gid))) {
> > + if (!memcmp(&sgid_tbl->tbl[i], gid, sizeof(*gid)) &&
> > + sgid_tbl->tbl[i].vlan_id == vlan_id) {
> > dev_dbg(&res->pdev->dev,
> > "SGID entry already exist in entry %d!\n", i);
> > *index = i;
> > @@ -351,6 +354,7 @@ int bnxt_qplib_add_sgid(struct bnxt_qplib_sgid_tbl
> > *sgid_tbl,
> > }
> > /* Add GID to the sgid_tbl */
> > memcpy(&sgid_tbl->tbl[free_idx], gid, sizeof(*gid));
> > + sgid_tbl->tbl[free_idx].vlan_id = vlan_id;
> > sgid_tbl->active++;
> > if (vlan_id != 0xFFFF)
> > sgid_tbl->vlan[free_idx] = 1;
> > diff --git a/drivers/infiniband/hw/bnxt_re/qplib_sp.h
> > b/drivers/infiniband/hw/bnxt_re/qplib_sp.h
> > index 0ec3b12b0bcd..b5c4ce302c61 100644
> > --- a/drivers/infiniband/hw/bnxt_re/qplib_sp.h
> > +++ b/drivers/infiniband/hw/bnxt_re/qplib_sp.h
> > @@ -84,6 +84,11 @@ struct bnxt_qplib_gid {
> > u8 data[16];
> > };
> >
> > +struct bnxt_qplib_gid_info {
> > + struct bnxt_qplib_gid gid;
> > + u16 vlan_id;
> > +};
> > +
> > struct bnxt_qplib_ah {
> > struct bnxt_qplib_gid dgid;
> > struct bnxt_qplib_pd *pd;
> > @@ -221,7 +226,7 @@ int bnxt_qplib_get_sgid(struct bnxt_qplib_res *res,
> > struct bnxt_qplib_sgid_tbl *sgid_tbl, int index,
> > struct bnxt_qplib_gid *gid);
> > int bnxt_qplib_del_sgid(struct bnxt_qplib_sgid_tbl *sgid_tbl,
> > - struct bnxt_qplib_gid *gid, bool update);
> > + struct bnxt_qplib_gid *gid, u16 vlan_id, bool update);
> > int bnxt_qplib_add_sgid(struct bnxt_qplib_sgid_tbl *sgid_tbl,
> > struct bnxt_qplib_gid *gid, u8 *mac, u16 vlan_id,
> > bool update, u32 *index);
^ permalink raw reply
* Re: regression: nvme rdma with bnxt_re0 broken
From: Jason Gunthorpe @ 2019-07-13 12:12 UTC (permalink / raw)
To: Selvin Xavier
Cc: Parav Pandit, Yi Zhang, Daniel Jurgens,
linux-rdma@vger.kernel.org, Devesh Sharma,
linux-nvme@lists.infradead.org
In-Reply-To: <CA+sbYW3Pp=qwky+myAEkiP-9TOui+9=DSyQxivNuSEsD8K4CFA@mail.gmail.com>
On Sat, Jul 13, 2019 at 01:21:54PM +0530, Selvin Xavier wrote:
> On Fri, Jul 12, 2019 at 11:12 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Fri, Jul 12, 2019 at 09:59:38PM +0530, Selvin Xavier wrote:
> >
> > > > bnxt guys: please just delete this duplicate detection code from the
> > > > driver. Every GID provided from the core must be programmed into the
> > > > given gid table index.
> > >
> > > Jason,
> > > This check is required in bnxt_re because the HW need only one entry
> > > in its table for RoCE V1 and RoCE v2 Gids.
> >
> > The HW doesn't have a 'GID table' if it has this restriction. It
> > sounds like it has some 'IP table' or maybe 'IP and VLAN' table?
> >
> > So the driver must provide a full emulated 'GID Table' with all the
> > normal semantics.
> >
> > Which looks sort of like what the add side is doing, other than the
> > mis-naming it seems reasonable..
> >
> > But then I see this in re_create_ah:
> >
> > /*
> > * If RoCE V2 is enabled, stack will have two entries for
> > * each GID entry. Avoiding this duplicte entry in HW. Dividing
> > * the GID index by 2 for RoCE V2
> > */
> > ah->qplib_ah.sgid_index = grh->sgid_index / 2;
> >
> > Which seems completely wrong - that is making assumptions about the
> > layout of the gid table that is just not allowed.
> >
> > Surely it needs to access the per-gid driver context that add_gid set
> > and use the index into the sgid_table from there?
> >
> Agree.. We need a mapping between HW table index and GID table index.
> We can either maintain a mapping in the driver or have an ib stack function to
> get the per gid driver context from gid table index. The later makes sense
> only if other drivers also needs such interface. I am not sure any
> other driver needs
> it.
I'd prefer a core function to return that context..
Even better would be to have the core allocate a larger entry and use
container_of
Jason
^ permalink raw reply
* Re: regression: nvme rdma with bnxt_re0 broken
From: Yi Zhang @ 2019-07-13 7:56 UTC (permalink / raw)
To: Selvin Xavier, Parav Pandit
Cc: Daniel Jurgens, linux-rdma@vger.kernel.org, Devesh Sharma,
linux-nvme@lists.infradead.org
In-Reply-To: <CA+sbYW0KPjJaQcoxFLny30tdMij7ycbxADCHKkVpL2LcQW-dTw@mail.gmail.com>
Hi Salvin
Confirmed the patch fixed the login issue.
And from the dmesg I found there is only one I/O queue created, is that
reasonable? there are more queues created during my testing for IB/iWARP.
# nvme connect-all -t rdma -a 172.31.40.125 -s 4420
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 1G 0 part /boot
├─sda2 8:2 0 25G 0 part /mnt/rdma-ext4
├─sda3 8:3 0 25G 0 part /mnt/rdma-xfs
├─sda4 8:4 0 1K 0 part
├─sda5 8:5 0 15.7G 0 part [SWAP]
└─sda6 8:6 0 864.9G 0 part /
nvme0n1 259:405 0 250G 0 disk
# dmesg
[ 4311.635430] nvme nvme0: new ctrl: NQN
"nqn.2014-08.org.nvmexpress.discovery", addr 172.31.40.125:4420
[ 4311.646687] nvme nvme0: Removing ctrl: NQN
"nqn.2014-08.org.nvmexpress.discovery"
[ 4311.706052] nvme nvme0: creating 1 I/O queues.
[ 4311.717848] nvme nvme0: mapped 1/0/0 default/read/poll queues.
[ 4311.727384] nvme nvme0: new ctrl: NQN "testnqn", addr 172.31.40.125:4420
# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 63
Model name: Intel(R) Xeon(R) CPU E5-2623 v3 @ 3.00GHz
Stepping: 2
CPU MHz: 3283.306
CPU max MHz: 3500.0000
CPU min MHz: 1200.0000
BogoMIPS: 5993.72
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 10240K
NUMA node0 CPU(s): 0,2,4,6,8,10,12,14
NUMA node1 CPU(s): 1,3,5,7,9,11,13,15
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1
sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand
lahf_lm abm cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp
tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1
avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm
ida arat pln pts flush_l1d
On 7/13/19 12:18 AM, Selvin Xavier wrote:
> On Fri, Jul 12, 2019 at 6:22 PM Parav Pandit <parav@mellanox.com> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Yi Zhang <yi.zhang@redhat.com>
>>> Sent: Friday, July 12, 2019 5:11 PM
>>> To: Parav Pandit <parav@mellanox.com>; Selvin Xavier
>>> <selvin.xavier@broadcom.com>
>>> Cc: Daniel Jurgens <danielj@mellanox.com>; linux-rdma@vger.kernel.org;
>>> Devesh Sharma <devesh.sharma@broadcom.com>; linux-
>>> nvme@lists.infradead.org
>>> Subject: Re: regression: nvme rdma with bnxt_re0 broken
>>>
>>> Hi Parav
>>> The nvme connect still failed[1], I've paste all the dmesg log to[2], pls check it.
>>>
>>>
>>> [1]
>>> [root@rdma-perf-07 ~]$ nvme connect -t rdma -a 172.31.40.125 -s 4420 -n
>>> testnqn
>>> Failed to write to /dev/nvme-fabrics: Connection reset by peer
>>> [2]
>>> https://pastebin.com/ipvak0Sp
>>>
>> I think vlan_id is not initialized to 0xffff due to which ipv4 entry addition also failed with my patch.
>> This is probably solves it. Not sure. I am not much familiar with it.
>>
>> Selvin,
>> Can you please take a look?
>>
> Parav,
> Thanks for the patch. I removed the change you made in struct bnxt_qplib_gid
> and added a new structure struct bnxt_qplib_gid_info to include both
> gid and vlan_id.
> struct bnxt_qplib_gid is used in multiple places to memcpy or compare
> the 16 bytes.
> Also, added vlan checking in the destroy path also. Some more cleanup
> possible in
> delete_gid path. That can be done once the basic issue is fixed.
>
> Yi, Can you please test this patch and see if it is solving the issue?
>
> Thanks,
> Selvin
>
> From 3d83613cfc5993bf9dae529ab0d4d25ddefff29b Mon Sep 17 00:00:00 2001
> From: Parav Pandit <parav@mellanox.com>
> Date: Fri, 12 Jul 2019 10:32:51 -0400
> Subject: [PATCH] IB/bnxt_re: Honor vlan_id in GID entry comparison
>
> GID entry consist of GID, vlan, netdev and smac.
> Extend GID duplicate check companions to consider vlan_id as well
> to support IPv6 VLAN based link local addresses.
>
> Fixes: 823b23da7113 ("IB/core: Allow vlan link local address based RoCE GIDs")
> Signed-off-by: Parav Pandit <parav@mellanox.com>
> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
> ---
> drivers/infiniband/hw/bnxt_re/ib_verbs.c | 7 +++++--
> drivers/infiniband/hw/bnxt_re/qplib_res.c | 17 +++++++++++++----
> drivers/infiniband/hw/bnxt_re/qplib_res.h | 2 +-
> drivers/infiniband/hw/bnxt_re/qplib_sp.c | 14 +++++++++-----
> drivers/infiniband/hw/bnxt_re/qplib_sp.h | 7 ++++++-
> 5 files changed, 34 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> index a91653aabf38..098ab883733e 100644
> --- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> +++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> @@ -308,6 +308,7 @@ int bnxt_re_del_gid(const struct ib_gid_attr
> *attr, void **context)
> struct bnxt_re_dev *rdev = to_bnxt_re_dev(attr->device, ibdev);
> struct bnxt_qplib_sgid_tbl *sgid_tbl = &rdev->qplib_res.sgid_tbl;
> struct bnxt_qplib_gid *gid_to_del;
> + u16 vlan_id = 0xFFFF;
>
> /* Delete the entry from the hardware */
> ctx = *context;
> @@ -317,7 +318,8 @@ int bnxt_re_del_gid(const struct ib_gid_attr
> *attr, void **context)
> if (sgid_tbl && sgid_tbl->active) {
> if (ctx->idx >= sgid_tbl->max)
> return -EINVAL;
> - gid_to_del = &sgid_tbl->tbl[ctx->idx];
> + gid_to_del = &sgid_tbl->tbl[ctx->idx].gid;
> + vlan_id = sgid_tbl->tbl[ctx->idx].vlan_id;
> /* DEL_GID is called in WQ context(netdevice_event_work_handler)
> * or via the ib_unregister_device path. In the former case QP1
> * may not be destroyed yet, in which case just return as FW
> @@ -335,7 +337,8 @@ int bnxt_re_del_gid(const struct ib_gid_attr
> *attr, void **context)
> }
> ctx->refcnt--;
> if (!ctx->refcnt) {
> - rc = bnxt_qplib_del_sgid(sgid_tbl, gid_to_del, true);
> + rc = bnxt_qplib_del_sgid(sgid_tbl, gid_to_del,
> + vlan_id, true);
> if (rc) {
> dev_err(rdev_to_dev(rdev),
> "Failed to remove GID: %#x", rc);
> diff --git a/drivers/infiniband/hw/bnxt_re/qplib_res.c
> b/drivers/infiniband/hw/bnxt_re/qplib_res.c
> index 37928b1111df..7f2571f7a13f 100644
> --- a/drivers/infiniband/hw/bnxt_re/qplib_res.c
> +++ b/drivers/infiniband/hw/bnxt_re/qplib_res.c
> @@ -488,7 +488,10 @@ static int bnxt_qplib_alloc_sgid_tbl(struct
> bnxt_qplib_res *res,
> struct bnxt_qplib_sgid_tbl *sgid_tbl,
> u16 max)
> {
> - sgid_tbl->tbl = kcalloc(max, sizeof(struct bnxt_qplib_gid), GFP_KERNEL);
> + u16 i;
> +
> + sgid_tbl->tbl = kcalloc(max, sizeof(struct bnxt_qplib_gid_info),
> + GFP_KERNEL);
> if (!sgid_tbl->tbl)
> return -ENOMEM;
>
> @@ -500,6 +503,9 @@ static int bnxt_qplib_alloc_sgid_tbl(struct
> bnxt_qplib_res *res,
> if (!sgid_tbl->ctx)
> goto out_free2;
>
> + for (i = 0; i < max; i++)
> + sgid_tbl->tbl[i].vlan_id = 0xffff;
> +
> sgid_tbl->vlan = kcalloc(max, sizeof(u8), GFP_KERNEL);
> if (!sgid_tbl->vlan)
> goto out_free3;
> @@ -526,9 +532,11 @@ static void bnxt_qplib_cleanup_sgid_tbl(struct
> bnxt_qplib_res *res,
> for (i = 0; i < sgid_tbl->max; i++) {
> if (memcmp(&sgid_tbl->tbl[i], &bnxt_qplib_gid_zero,
> sizeof(bnxt_qplib_gid_zero)))
> - bnxt_qplib_del_sgid(sgid_tbl, &sgid_tbl->tbl[i], true);
> + bnxt_qplib_del_sgid(sgid_tbl, &sgid_tbl->tbl[i].gid,
> + sgid_tbl->tbl[i].vlan_id, true);
> }
> - memset(sgid_tbl->tbl, 0, sizeof(struct bnxt_qplib_gid) * sgid_tbl->max);
> + memset(sgid_tbl->tbl, 0, sizeof(struct bnxt_qplib_gid_info) *
> + sgid_tbl->max);
> memset(sgid_tbl->hw_id, -1, sizeof(u16) * sgid_tbl->max);
> memset(sgid_tbl->vlan, 0, sizeof(u8) * sgid_tbl->max);
> sgid_tbl->active = 0;
> @@ -537,7 +545,8 @@ static void bnxt_qplib_cleanup_sgid_tbl(struct
> bnxt_qplib_res *res,
> static void bnxt_qplib_init_sgid_tbl(struct bnxt_qplib_sgid_tbl *sgid_tbl,
> struct net_device *netdev)
> {
> - memset(sgid_tbl->tbl, 0, sizeof(struct bnxt_qplib_gid) * sgid_tbl->max);
> + memset(sgid_tbl->tbl, 0, sizeof(struct bnxt_qplib_gid_info) *
> + sgid_tbl->max);
> memset(sgid_tbl->hw_id, -1, sizeof(u16) * sgid_tbl->max);
> }
>
> diff --git a/drivers/infiniband/hw/bnxt_re/qplib_res.h
> b/drivers/infiniband/hw/bnxt_re/qplib_res.h
> index 30c42c92fac7..fbda11a7ab1a 100644
> --- a/drivers/infiniband/hw/bnxt_re/qplib_res.h
> +++ b/drivers/infiniband/hw/bnxt_re/qplib_res.h
> @@ -111,7 +111,7 @@ struct bnxt_qplib_pd_tbl {
> };
>
> struct bnxt_qplib_sgid_tbl {
> - struct bnxt_qplib_gid *tbl;
> + struct bnxt_qplib_gid_info *tbl;
> u16 *hw_id;
> u16 max;
> u16 active;
> diff --git a/drivers/infiniband/hw/bnxt_re/qplib_sp.c
> b/drivers/infiniband/hw/bnxt_re/qplib_sp.c
> index 48793d3512ac..40296b97d21e 100644
> --- a/drivers/infiniband/hw/bnxt_re/qplib_sp.c
> +++ b/drivers/infiniband/hw/bnxt_re/qplib_sp.c
> @@ -213,12 +213,12 @@ int bnxt_qplib_get_sgid(struct bnxt_qplib_res *res,
> index, sgid_tbl->max);
> return -EINVAL;
> }
> - memcpy(gid, &sgid_tbl->tbl[index], sizeof(*gid));
> + memcpy(gid, &sgid_tbl->tbl[index].gid, sizeof(*gid));
> return 0;
> }
>
> int bnxt_qplib_del_sgid(struct bnxt_qplib_sgid_tbl *sgid_tbl,
> - struct bnxt_qplib_gid *gid, bool update)
> + struct bnxt_qplib_gid *gid, u16 vlan_id, bool update)
> {
> struct bnxt_qplib_res *res = to_bnxt_qplib(sgid_tbl,
> struct bnxt_qplib_res,
> @@ -236,7 +236,8 @@ int bnxt_qplib_del_sgid(struct bnxt_qplib_sgid_tbl
> *sgid_tbl,
> return -ENOMEM;
> }
> for (index = 0; index < sgid_tbl->max; index++) {
> - if (!memcmp(&sgid_tbl->tbl[index], gid, sizeof(*gid)))
> + if (!memcmp(&sgid_tbl->tbl[index].gid, gid, sizeof(*gid)) &&
> + vlan_id == sgid_tbl->tbl[index].vlan_id)
> break;
> }
> if (index == sgid_tbl->max) {
> @@ -262,8 +263,9 @@ int bnxt_qplib_del_sgid(struct bnxt_qplib_sgid_tbl
> *sgid_tbl,
> if (rc)
> return rc;
> }
> - memcpy(&sgid_tbl->tbl[index], &bnxt_qplib_gid_zero,
> + memcpy(&sgid_tbl->tbl[index].gid, &bnxt_qplib_gid_zero,
> sizeof(bnxt_qplib_gid_zero));
> + sgid_tbl->tbl[index].vlan_id = 0xFFFF;
> sgid_tbl->vlan[index] = 0;
> sgid_tbl->active--;
> dev_dbg(&res->pdev->dev,
> @@ -296,7 +298,8 @@ int bnxt_qplib_add_sgid(struct bnxt_qplib_sgid_tbl
> *sgid_tbl,
> }
> free_idx = sgid_tbl->max;
> for (i = 0; i < sgid_tbl->max; i++) {
> - if (!memcmp(&sgid_tbl->tbl[i], gid, sizeof(*gid))) {
> + if (!memcmp(&sgid_tbl->tbl[i], gid, sizeof(*gid)) &&
> + sgid_tbl->tbl[i].vlan_id == vlan_id) {
> dev_dbg(&res->pdev->dev,
> "SGID entry already exist in entry %d!\n", i);
> *index = i;
> @@ -351,6 +354,7 @@ int bnxt_qplib_add_sgid(struct bnxt_qplib_sgid_tbl
> *sgid_tbl,
> }
> /* Add GID to the sgid_tbl */
> memcpy(&sgid_tbl->tbl[free_idx], gid, sizeof(*gid));
> + sgid_tbl->tbl[free_idx].vlan_id = vlan_id;
> sgid_tbl->active++;
> if (vlan_id != 0xFFFF)
> sgid_tbl->vlan[free_idx] = 1;
> diff --git a/drivers/infiniband/hw/bnxt_re/qplib_sp.h
> b/drivers/infiniband/hw/bnxt_re/qplib_sp.h
> index 0ec3b12b0bcd..b5c4ce302c61 100644
> --- a/drivers/infiniband/hw/bnxt_re/qplib_sp.h
> +++ b/drivers/infiniband/hw/bnxt_re/qplib_sp.h
> @@ -84,6 +84,11 @@ struct bnxt_qplib_gid {
> u8 data[16];
> };
>
> +struct bnxt_qplib_gid_info {
> + struct bnxt_qplib_gid gid;
> + u16 vlan_id;
> +};
> +
> struct bnxt_qplib_ah {
> struct bnxt_qplib_gid dgid;
> struct bnxt_qplib_pd *pd;
> @@ -221,7 +226,7 @@ int bnxt_qplib_get_sgid(struct bnxt_qplib_res *res,
> struct bnxt_qplib_sgid_tbl *sgid_tbl, int index,
> struct bnxt_qplib_gid *gid);
> int bnxt_qplib_del_sgid(struct bnxt_qplib_sgid_tbl *sgid_tbl,
> - struct bnxt_qplib_gid *gid, bool update);
> + struct bnxt_qplib_gid *gid, u16 vlan_id, bool update);
> int bnxt_qplib_add_sgid(struct bnxt_qplib_sgid_tbl *sgid_tbl,
> struct bnxt_qplib_gid *gid, u8 *mac, u16 vlan_id,
> bool update, u32 *index);
^ permalink raw reply
* Re: regression: nvme rdma with bnxt_re0 broken
From: Selvin Xavier @ 2019-07-13 7:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Parav Pandit, Yi Zhang, Daniel Jurgens,
linux-rdma@vger.kernel.org, Devesh Sharma,
linux-nvme@lists.infradead.org
In-Reply-To: <20190712174220.GL27512@ziepe.ca>
On Fri, Jul 12, 2019 at 11:12 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Fri, Jul 12, 2019 at 09:59:38PM +0530, Selvin Xavier wrote:
>
> > > bnxt guys: please just delete this duplicate detection code from the
> > > driver. Every GID provided from the core must be programmed into the
> > > given gid table index.
> >
> > Jason,
> > This check is required in bnxt_re because the HW need only one entry
> > in its table for RoCE V1 and RoCE v2 Gids.
>
> The HW doesn't have a 'GID table' if it has this restriction. It
> sounds like it has some 'IP table' or maybe 'IP and VLAN' table?
>
> So the driver must provide a full emulated 'GID Table' with all the
> normal semantics.
>
> Which looks sort of like what the add side is doing, other than the
> mis-naming it seems reasonable..
>
> But then I see this in re_create_ah:
>
> /*
> * If RoCE V2 is enabled, stack will have two entries for
> * each GID entry. Avoiding this duplicte entry in HW. Dividing
> * the GID index by 2 for RoCE V2
> */
> ah->qplib_ah.sgid_index = grh->sgid_index / 2;
>
> Which seems completely wrong - that is making assumptions about the
> layout of the gid table that is just not allowed.
>
> Surely it needs to access the per-gid driver context that add_gid set
> and use the index into the sgid_table from there?
>
Agree.. We need a mapping between HW table index and GID table index.
We can either maintain a mapping in the driver or have an ib stack function to
get the per gid driver context from gid table index. The later makes sense
only if other drivers also needs such interface. I am not sure any
other driver needs
it.
^ permalink raw reply
* Re: [PATCH] RDMA/siw: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-07-12 19:43 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: Bernard Metzler, Doug Ledford, linux-rdma, linux-kernel
In-Reply-To: <20190711180511.GA816@ziepe.ca>
On 7/11/19 1:05 PM, Jason Gunthorpe wrote:
>> This patch is part of the ongoing efforts to enable
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>>
>> NOTE: -Wimplicit-fallthrough will be enabled globally in v5.3. So, I
>> suggest you to take this patch for 5.3-rc1.
>
> Okay, I queued this for the current merge window then
>
Awesome. :)
Thank you both, Bernard and Jason.
--
Gustavo
^ permalink raw reply
* Re: Re: [PATCH] rdma/siw: avoid smp_store_mb() on a u64
From: Arnd Bergmann @ 2019-07-12 20:24 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Bernard Metzler, Doug Ledford, Peter Zijlstra, linux-rdma,
Linux Kernel Mailing List
In-Reply-To: <20190712151423.GG27512@ziepe.ca>
On Fri, Jul 12, 2019 at 5:14 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Fri, Jul 12, 2019 at 03:22:35PM +0200, Arnd Bergmann wrote:
> > On Fri, Jul 12, 2019 at 3:05 PM Bernard Metzler <BMT@zurich.ibm.com> wrote:
>
> Since this is coming up so late in the merge window, I'm inclined to
> take the simple path while Bernard makes a complete solution
> here. What do you think Arnd?
I don't see a problem either way, since it's a new driver, so both
disabling it on 32-bit and applying a fix that might cause something
to break is not going to make it worse for anyone compared to the
linux-5.2 release.
Arnd
^ permalink raw reply
* Re: [PATCH v4 00/25] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)
From: Sagi Grimberg @ 2019-07-12 19:40 UTC (permalink / raw)
To: Jinpu Wang
Cc: Danil Kipnis, linux-block, linux-rdma, Jens Axboe,
Christoph Hellwig, bvanassche, jgg, dledford, Roman Pen,
Greg Kroah-Hartman
In-Reply-To: <CAD9gYJKcJ47ogKL4S_KMtxpS1gPHHhqqG7-GTi-2c0cOJ-LJtw@mail.gmail.com>
> Hi Sagi,
>
>>>> Another question, from what I understand from the code, the client
>>>> always rdma_writes data on writes (with imm) from a remote pool of
>>>> server buffers dedicated to it. Essentially all writes are immediate (no
>>>> rdma reads ever). How is that different than using send wrs to a set of
>>>> pre-posted recv buffers (like all others are doing)? Is it faster?
>>> At the very beginning of the project we did some measurements and saw,
>>> that it is faster. I'm not sure if this is still true
>>
>> Its not significantly faster (can't imagine why it would be).
>> What could make a difference is probably the fact that you never
>> do rdma reads for I/O writes which might be better. Also perhaps the
>> fact that you normally don't wait for send completions before completing
>> I/O (which is broken), and the fact that you batch recv operations.
>
> I don't know how do you come to the conclusion we don't wait for send
> completion before completing IO.
>
> We do chain wr on successfull read request from server, see funtion
> rdma_write_sg,
I was referring to the client side
^ permalink raw reply
* Re: [PATCH net-next v3] net/mlx5e: Convert single case statement switch statements into if statements
From: David Miller @ 2019-07-12 18:37 UTC (permalink / raw)
To: natechancellor
Cc: saeedm, leon, borisp, netdev, linux-rdma, linux-kernel,
clang-built-linux, ndesaulniers
In-Reply-To: <20190710060614.6155-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Tue, 9 Jul 2019 23:06:15 -0700
> During the review of commit 1ff2f0fa450e ("net/mlx5e: Return in default
> case statement in tx_post_resync_params"), Leon and Nick pointed out
> that the switch statements can be converted to single if statements
> that return early so that the code is easier to follow.
>
> Suggested-by: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Applied, thanks for following up Nathan.
^ permalink raw reply
* Re: [PATCH] [net-next, netfilter] mlx5: avoid unused variable warning
From: Saeed Mahameed @ 2019-07-12 18:25 UTC (permalink / raw)
To: davem@davemloft.net, arnd@arndb.de, leon@kernel.org
Cc: Aya Levin, Maxim Mikityanskiy, Or Gerlitz, pablo@netfilter.org,
Tariq Toukan, linux-rdma@vger.kernel.org,
jakub.kicinski@netronome.com, Eran Ben Elisha,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190712085823.4111911-1-arnd@arndb.de>
On Fri, 2019-07-12 at 10:57 +0200, Arnd Bergmann wrote:
> Without CONFIG_MLX5_ESWITCH we get a harmless warning:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3467:21: error:
> unused variable 'priv' [-Werror,-Wunused-variable]
> struct mlx5e_priv *priv = netdev_priv(dev);
>
Hi Arnd,
thanks for your patch, a similar patch that addresses this issue was
already submitted and applied to net-next [1]
[1] https://www.spinics.net/lists/netdev/msg585433.html
> Hide the declaration in the same #ifdef as its usage.
>
> Fixes: 4e95bc268b91 ("net: flow_offload: add
> flow_block_cb_setup_simple()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 6d0ae87c8ded..b562ba904ea1 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -3464,7 +3464,9 @@ static LIST_HEAD(mlx5e_block_cb_list);
> static int mlx5e_setup_tc(struct net_device *dev, enum tc_setup_type
> type,
> void *type_data)
> {
> +#ifdef CONFIG_MLX5_ESWITCH
> struct mlx5e_priv *priv = netdev_priv(dev);
> +#endif
>
> switch (type) {
> #ifdef CONFIG_MLX5_ESWITCH
^ permalink raw reply
* Re: Re: Re: Re: Re: Re: [PATCH] rdma/siw: avoid smp_store_mb() on a u64
From: Bernard Metzler @ 2019-07-12 18:06 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Arnd Bergmann, Doug Ledford, Peter Zijlstra, linux-rdma,
linux-kernel
In-Reply-To: <20190712174525.GM27512@ziepe.ca>
-----"Jason Gunthorpe" <jgg@ziepe.ca> wrote: -----
>To: "Bernard Metzler" <BMT@zurich.ibm.com>
>From: "Jason Gunthorpe" <jgg@ziepe.ca>
>Date: 07/12/2019 07:45PM
>Cc: "Arnd Bergmann" <arnd@arndb.de>, "Doug Ledford"
><dledford@redhat.com>, "Peter Zijlstra" <peterz@infradead.org>,
>linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
>Subject: [EXTERNAL] Re: Re: Re: Re: Re: [PATCH] rdma/siw: avoid
>smp_store_mb() on a u64
>
>On Fri, Jul 12, 2019 at 05:40:43PM +0000, Bernard Metzler wrote:
>
>> It is because there are two levels a CQ can be armed:
>>
>> #include <infiniband/verbs.h>
>>
>> int ibv_req_notify_cq(struct ibv_cq *cq, int
>solicited_only);
>>
>> If we kick the CQ handler, we have to clear the whole
>> thing. The user later again decides how he wants to get it
>> re-armed...SOLICITED completions only, or ALL signaled.
>
>Arrange it so only one of the two bits is ever set and do two
>test-and-set bits when a SOLICITED CQE comes in?
>
right, but that's too easy ;)
I'll probably do it along those lines.
Many thanks,
Bernard.
^ permalink raw reply
* Re: Re: Re: Re: Re: [PATCH] rdma/siw: avoid smp_store_mb() on a u64
From: Jason Gunthorpe @ 2019-07-12 17:45 UTC (permalink / raw)
To: Bernard Metzler
Cc: Arnd Bergmann, Doug Ledford, Peter Zijlstra, linux-rdma,
linux-kernel
In-Reply-To: <OFAB0712BA.E95178B5-ON00258435.00611CBE-00258435.00611CC4@notes.na.collabserv.com>
On Fri, Jul 12, 2019 at 05:40:43PM +0000, Bernard Metzler wrote:
> It is because there are two levels a CQ can be armed:
>
> #include <infiniband/verbs.h>
>
> int ibv_req_notify_cq(struct ibv_cq *cq, int solicited_only);
>
> If we kick the CQ handler, we have to clear the whole
> thing. The user later again decides how he wants to get it
> re-armed...SOLICITED completions only, or ALL signaled.
Arrange it so only one of the two bits is ever set and do two
test-and-set bits when a SOLICITED CQE comes in?
Jason
^ permalink raw reply
* Re: regression: nvme rdma with bnxt_re0 broken
From: Jason Gunthorpe @ 2019-07-12 17:42 UTC (permalink / raw)
To: Selvin Xavier
Cc: Parav Pandit, Yi Zhang, Daniel Jurgens,
linux-rdma@vger.kernel.org, Devesh Sharma,
linux-nvme@lists.infradead.org
In-Reply-To: <CA+sbYW0F6Vgpa5SQX+9ge4EwWrMkJ4kQ-psEq11S00=-L_mVhg@mail.gmail.com>
On Fri, Jul 12, 2019 at 09:59:38PM +0530, Selvin Xavier wrote:
> > bnxt guys: please just delete this duplicate detection code from the
> > driver. Every GID provided from the core must be programmed into the
> > given gid table index.
>
> Jason,
> This check is required in bnxt_re because the HW need only one entry
> in its table for RoCE V1 and RoCE v2 Gids.
The HW doesn't have a 'GID table' if it has this restriction. It
sounds like it has some 'IP table' or maybe 'IP and VLAN' table?
So the driver must provide a full emulated 'GID Table' with all the
normal semantics.
Which looks sort of like what the add side is doing, other than the
mis-naming it seems reasonable..
But then I see this in re_create_ah:
/*
* If RoCE V2 is enabled, stack will have two entries for
* each GID entry. Avoiding this duplicte entry in HW. Dividing
* the GID index by 2 for RoCE V2
*/
ah->qplib_ah.sgid_index = grh->sgid_index / 2;
Which seems completely wrong - that is making assumptions about the
layout of the gid table that is just not allowed.
Surely it needs to access the per-gid driver context that add_gid set
and use the index into the sgid_table from there?
Jason
^ permalink raw reply
* Re: Re: Re: Re: Re: [PATCH] rdma/siw: avoid smp_store_mb() on a u64
From: Bernard Metzler @ 2019-07-12 17:40 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Arnd Bergmann, Doug Ledford, Peter Zijlstra, linux-rdma,
linux-kernel
In-Reply-To: <20190712153243.GI27512@ziepe.ca>
-----"Jason Gunthorpe" <jgg@ziepe.ca> wrote: -----
>To: "Bernard Metzler" <BMT@zurich.ibm.com>
>From: "Jason Gunthorpe" <jgg@ziepe.ca>
>Date: 07/12/2019 05:33PM
>Cc: "Arnd Bergmann" <arnd@arndb.de>, "Doug Ledford"
><dledford@redhat.com>, "Peter Zijlstra" <peterz@infradead.org>,
>linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
>Subject: [EXTERNAL] Re: Re: Re: Re: [PATCH] rdma/siw: avoid
>smp_store_mb() on a u64
>
>On Fri, Jul 12, 2019 at 03:24:09PM +0000, Bernard Metzler wrote:
>>
>> >To: "Bernard Metzler" <BMT@zurich.ibm.com>
>> >From: "Jason Gunthorpe" <jgg@ziepe.ca>
>> >Date: 07/12/2019 04:43PM
>> >Cc: "Arnd Bergmann" <arnd@arndb.de>, "Doug Ledford"
>> ><dledford@redhat.com>, "Peter Zijlstra" <peterz@infradead.org>,
>> >linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
>> >Subject: [EXTERNAL] Re: Re: Re: [PATCH] rdma/siw: avoid
>> >smp_store_mb() on a u64
>> >
>> >On Fri, Jul 12, 2019 at 02:35:50PM +0000, Bernard Metzler wrote:
>> >
>> >> >This looks wrong to me.. a userspace notification re-arm cannot
>be
>> >> >lost, so have a split READ/TEST/WRITE sequence can't possibly
>> >work?
>> >> >
>> >> >I'd expect an atomic test and clear here?
>> >>
>> >> We cannot avoid the case that the application re-arms the
>> >> CQ only after a CQE got placed. That is why folks are polling
>the
>> >> CQ once after re-arming it - to make sure they do not miss the
>> >> very last and single CQE which would have produced a CQ event.
>> >
>> >That is different, that is re-arm happing after a CQE placement
>and
>> >this can't be fixed.
>> >
>> >What I said is that a re-arm from userspace cannot be lost. So you
>> >can't blindly clear the arm flag with the WRITE_ONCE. It might be
>OK
>> >beacuse of the if, but...
>> >
>> >It is just goofy to write it without a 'test and clear' atomic. If
>> >the
>> >writer side consumes the notify it should always be done
>atomically.
>> >
>> Hmmm, I don't yet get why we should test and clear atomically, if
>we
>> clear anyway - is it because we want to avoid clearing a re-arm
>which
>> happens just after testing and before clearing?
>
>It is just clearer as to the intent..
>
>Are you trying to optimize away an atomic or something? That might
>work better as a dual counter scheme.
>
>> Another complication -- test_and_set_bit() operates on a single
>> bit, but we have to test two bits, and reset both, if one is
>> set.
>
>Why are two bits needed to represent armed and !armed?
>
>Jason
It is because there are two levels a CQ can be armed:
#include <infiniband/verbs.h>
int ibv_req_notify_cq(struct ibv_cq *cq, int solicited_only);
If we kick the CQ handler, we have to clear the whole
thing. The user later again decides how he wants to get it
re-armed...SOLICITED completions only, or ALL signaled.
Best,
Bernard.
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox