RE: [PATCH] IB/addr: Improve address resolution callback scheduling
> From: Or Kehati > > As of the callback model, the address resolution logic always does > context switch to a work-queue to deliver the address resolution event. > > When the IP address is already cached in the system arp table, > we're going through the following call chain: > > rdma_resolve_ip --> addr_resolve (cache hit) --> > > which ends up with doing: > > queue_req --> set_timeout (now) --> mod_delayed_work(,, delay=1) > > We actually do realize that the timeout should be zero, but the > code forces it to a minimum of one jiffie. > > Using one jiffie as the minimum delay value results in a less optimized > scheduling of executing this work item by the workqueue, which on the > below testbed costs about 3-4ms out of 12ms total time. > > To fix that, we let the minimum delay to be zero. Note that the > connect step times change too, as there are address resolution > calls from that flow. > > The results were taken from running both client and server on the > same node, over mlx4 RoCE port. > > before --> > step total ms max ms min us us / conn > create id:0.01 0.01 6.00 6.00 > resolve addr :4.02 4.014013.004016.00 > resolve route:0.18 0.18 182.00 183.00 > create qp:1.15 1.151150.001150.00 > connect :6.73 6.736730.006731.00 > disconnect :0.55 0.55 549.00 550.00 > destroy :0.01 0.01 9.00 9.00 > > after --> > step total ms max ms min us us / conn > create id:0.01 0.01 6.00 6.00 > resolve addr :0.05 0.05 49.00 52.00 > resolve route:0.21 0.21 207.00 208.00 > create qp:1.10 1.101104.001104.00 > connect :1.22 1.221220.001221.00 > disconnect :0.71 0.71 713.00 713.00 > destroy :0.01 0.01 9.00 9.00 > > Signed-off-by: Or Kehati > Signed-off-by: Or Gerlitz Acked-by: Sean Hefty -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WRITE/SEND to multiple destinations
Stupid me. I totally forgot about the XRC transport: http://mvapich.cse.ohio-state.edu/static/media/publications/abstract/koop-cluster08.pdf. --Anuj On Mon, Nov 3, 2014 at 10:05 PM, Anuj Kalia wrote: > For the RC transport, the answer is yes. You definitely need one queue > pair per client at the server, although it could be possible for the > QPs at the server to share an event channel. > > But UD transport is also pretty "reliable" as packet loss in any > InfiniBand transport is extremely rare. A rather high ballpark is one > in a billion. > > --Anuj > > On Mon, Nov 3, 2014 at 5:59 PM, Just Floaterions > wrote: >> Thank you for your help. So the question is, for reliable connections, do I >> need separate event channel/queue-pairs for each connection? >> >> On Mon, Nov 3, 2014 at 3:50 PM, Anuj Kalia wrote: >>> >>> You can do SEND/RECV over Unreliable Datagram multicast which could be >>> beneficial in your situation (i.e., better than 1-1 connections). You >>> can't use multicast for READs or WRITEs. >>> >>> --Anuj >>> >>> On Sun, Nov 2, 2014 at 9:32 PM, floaterions wrote: >>> > Hello everyone, >>> > >>> > As a newbie to the world of InfiniBand programming, >>> > I would appreciate your helps on my somewhat general and basic question. >>> > >>> > Assume that I have a server, and N clients (N > 1). >>> > I would like my server to set all clients' memory buffers to some value >>> > V. >>> > How would I go about this problem? >>> > So far, I've managed to establish 1-1 connections using >>> > READ/WRITE/SEND/RECEIVE. >>> > So I guess the core of my question is: >>> > how 1-to-N connections are established in InfiniBand, and >>> > if, in this regard, there is any difference between >>> > RDMA verbs (READ/WRITE) vs. SEND/RECEIVE? >>> > >>> > -- >>> > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in >>> > the body of a message to majord...@vger.kernel.org >>> > More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WRITE/SEND to multiple destinations
For the RC transport, the answer is yes. You definitely need one queue pair per client at the server, although it could be possible for the QPs at the server to share an event channel. But UD transport is also pretty "reliable" as packet loss in any InfiniBand transport is extremely rare. A rather high ballpark is one in a billion. --Anuj On Mon, Nov 3, 2014 at 5:59 PM, Just Floaterions wrote: > Thank you for your help. So the question is, for reliable connections, do I > need separate event channel/queue-pairs for each connection? > > On Mon, Nov 3, 2014 at 3:50 PM, Anuj Kalia wrote: >> >> You can do SEND/RECV over Unreliable Datagram multicast which could be >> beneficial in your situation (i.e., better than 1-1 connections). You >> can't use multicast for READs or WRITEs. >> >> --Anuj >> >> On Sun, Nov 2, 2014 at 9:32 PM, floaterions wrote: >> > Hello everyone, >> > >> > As a newbie to the world of InfiniBand programming, >> > I would appreciate your helps on my somewhat general and basic question. >> > >> > Assume that I have a server, and N clients (N > 1). >> > I would like my server to set all clients' memory buffers to some value >> > V. >> > How would I go about this problem? >> > So far, I've managed to establish 1-1 connections using >> > READ/WRITE/SEND/RECEIVE. >> > So I guess the core of my question is: >> > how 1-to-N connections are established in InfiniBand, and >> > if, in this regard, there is any difference between >> > RDMA verbs (READ/WRITE) vs. SEND/RECEIVE? >> > >> > -- >> > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in >> > the body of a message to majord...@vger.kernel.org >> > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 net-next 2/3] cxgb4: Cleanup macros so they follow the same style and look consistent
Various patches have ended up changing the style of the symbolic macros/register
defines and some of them used the macros/register defines that matches the
output of the script from the hardware team.
As a result, the current kernel.org files are a mix of different macro styles.
Since this macro/register defines is used by different drivers a
few patch series have ended up adding duplicate macro/register define entries
with different styles. This makes these register define/macro files a complete
mess and we want to make them clean and consistent. This patch cleans up a part
of it.
Signed-off-by: Hariprasad Shenai
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 32 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 16 +++--
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c |6 +-
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 72 +++-
drivers/scsi/csiostor/csio_hw_t4.c | 15 ++--
drivers/scsi/csiostor/csio_hw_t5.c | 21 +++---
drivers/scsi/csiostor/csio_init.c |6 +-
7 files changed, 106 insertions(+), 62 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index e86b5fe..aa75c91 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -128,30 +128,30 @@ int t4_setup_debugfs(struct adapter *adap)
t4_debugfs_files,
ARRAY_SIZE(t4_debugfs_files));
- i = t4_read_reg(adap, MA_TARGET_MEM_ENABLE);
- if (i & EDRAM0_ENABLE) {
- size = t4_read_reg(adap, MA_EDRAM0_BAR);
- add_debugfs_mem(adap, "edc0", MEM_EDC0, EDRAM_SIZE_GET(size));
+ i = t4_read_reg(adap, A_MA_TARGET_MEM_ENABLE);
+ if (i & F_EDRAM0_ENABLE) {
+ size = t4_read_reg(adap, A_MA_EDRAM0_BAR);
+ add_debugfs_mem(adap, "edc0", MEM_EDC0, G_EDRAM0_SIZE(size));
}
- if (i & EDRAM1_ENABLE) {
- size = t4_read_reg(adap, MA_EDRAM1_BAR);
- add_debugfs_mem(adap, "edc1", MEM_EDC1, EDRAM_SIZE_GET(size));
+ if (i & F_EDRAM1_ENABLE) {
+ size = t4_read_reg(adap, A_MA_EDRAM1_BAR);
+ add_debugfs_mem(adap, "edc1", MEM_EDC1, G_EDRAM1_SIZE(size));
}
if (is_t4(adap->params.chip)) {
- size = t4_read_reg(adap, MA_EXT_MEMORY_BAR);
- if (i & EXT_MEM_ENABLE)
+ size = t4_read_reg(adap, A_MA_EXT_MEMORY_BAR);
+ if (i & F_EXT_MEM_ENABLE)
add_debugfs_mem(adap, "mc", MEM_MC,
- EXT_MEM_SIZE_GET(size));
+ G_EXT_MEM_SIZE(size));
} else {
- if (i & EXT_MEM_ENABLE) {
- size = t4_read_reg(adap, MA_EXT_MEMORY_BAR);
+ if (i & F_EXT_MEM0_ENABLE) {
+ size = t4_read_reg(adap, A_MA_EXT_MEMORY0_BAR);
add_debugfs_mem(adap, "mc0", MEM_MC0,
- EXT_MEM_SIZE_GET(size));
+ G_EXT_MEM0_SIZE(size));
}
- if (i & EXT_MEM1_ENABLE) {
- size = t4_read_reg(adap, MA_EXT_MEMORY1_BAR);
+ if (i & F_EXT_MEM1_ENABLE) {
+ size = t4_read_reg(adap, A_MA_EXT_MEMORY1_BAR);
add_debugfs_mem(adap, "mc1", MEM_MC1,
- EXT_MEM_SIZE_GET(size));
+ G_EXT_MEM1_SIZE(size));
}
}
return 0;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 172f68b..65ce937 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -3802,7 +3802,7 @@ int cxgb4_read_tpte(struct net_device *dev, u32 stag,
__be32 *tpte)
{
struct adapter *adap;
u32 offset, memtype, memaddr;
- u32 edc0_size, edc1_size, mc0_size, mc1_size;
+ u32 edc0_size, edc1_size, mc0_size, mc1_size, size;
u32 edc0_end, edc1_end, mc0_end, mc1_end;
int ret;
@@ -3816,9 +3816,12 @@ int cxgb4_read_tpte(struct net_device *dev, u32 stag,
__be32 *tpte)
* and EDC1. Some cards will have neither MC0 nor MC1, most cards have
* MC0, and some have both MC0 and MC1.
*/
- edc0_size = EDRAM_SIZE_GET(t4_read_reg(adap, MA_EDRAM0_BAR)) << 20;
- edc1_size = EDRAM_SIZE_GET(t4_read_reg(adap, MA_EDRAM1_BAR)) << 20;
- mc0_size = EXT_MEM_SIZE_GET(t4_read_reg(adap, MA_EXT_MEMORY_BAR)) << 20;
+ size = t4_read_reg(adap, A_MA_EDRAM0_BAR);
+ edc0_size = G_EDRAM0_SIZE(size) << 20;
+ size = t4_read_reg(adap, A_MA_EDRAM1_BAR);
+ edc1_size = G_EDRAM1_SIZE(size) <<
[PATCHv2 net-next 1/3] cxgb4: Add cxgb4_debugfs.c, move all debugfs code to new file
Signed-off-by: Hariprasad Shenai
---
drivers/net/ethernet/chelsio/cxgb4/Makefile|1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 158
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h | 52 +++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 97 +
5 files changed, 217 insertions(+), 92 deletions(-)
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h
diff --git a/drivers/net/ethernet/chelsio/cxgb4/Makefile
b/drivers/net/ethernet/chelsio/cxgb4/Makefile
index 1df65c9..b852807 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/Makefile
+++ b/drivers/net/ethernet/chelsio/cxgb4/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_CHELSIO_T4) += cxgb4.o
cxgb4-objs := cxgb4_main.o l2t.o t4_hw.o sge.o
cxgb4-$(CONFIG_CHELSIO_T4_DCB) += cxgb4_dcb.o
+cxgb4-$(CONFIG_DEBUG_FS) += cxgb4_debugfs.o
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 3c481b2..dad1ea9 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -1085,4 +1085,5 @@ void t4_db_dropped(struct adapter *adapter);
int t4_fwaddrspace_write(struct adapter *adap, unsigned int mbox,
u32 addr, u32 val);
void t4_sge_decode_idma_state(struct adapter *adapter, int state);
+void t4_free_mem(void *addr);
#endif /* __CXGB4_H__ */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
new file mode 100644
index 000..e86b5fe
--- /dev/null
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -0,0 +1,158 @@
+/*
+ * This file is part of the Chelsio T4 Ethernet driver for Linux.
+ *
+ * Copyright (c) 2003-2014 Chelsio Communications, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "cxgb4.h"
+#include "t4_regs.h"
+#include "t4fw_api.h"
+#include "cxgb4_debugfs.h"
+#include "l2t.h"
+
+static ssize_t mem_read(struct file *file, char __user *buf, size_t count,
+ loff_t *ppos)
+{
+ loff_t pos = *ppos;
+ loff_t avail = file_inode(file)->i_size;
+ unsigned int mem = (uintptr_t)file->private_data & 3;
+ struct adapter *adap = file->private_data - mem;
+ __be32 *data;
+ int ret;
+
+ if (pos < 0)
+ return -EINVAL;
+ if (pos >= avail)
+ return 0;
+ if (count > avail - pos)
+ count = avail - pos;
+
+ data = t4_alloc_mem(count);
+ if (!data)
+ return -ENOMEM;
+
+ spin_lock(&adap->win0_lock);
+ ret = t4_memory_rw(adap, 0, mem, pos, count, data, T4_MEMORY_READ);
+ spin_unlock(&adap->win0_lock);
+ if (ret) {
+ t4_free_mem(data);
+ return ret;
+ }
+ ret = copy_to_user(buf, data, count);
+
+ t4_free_mem(data);
+ if (ret)
+ return -EFAULT;
+
+ *ppos = pos + count;
+ return count;
+}
+
+static const struct file_operations mem_debugfs_fops = {
+ .owner = THIS_MODULE,
+ .open= simple_open,
+ .read= mem_read,
+ .llseek = default_llseek,
+};
+
+static void add_debugfs_mem(struct adapter *adap, const char *name,
+ unsigned int idx, unsigned int size_mb)
+{
+ struct dentry *de;
+
+ de = debugfs_create_file(name, S_IRUSR, adap->debugfs_root,
+
[PATCHv2 net-next 3/3] cxgb4: Cleanup macros so they follow the same style and look consistent, part 2
Various patches have ended up changing the style of the symbolic macros/register defines and some of them used the macros/register defines that matches the output of the script from the hardware team. As a result, the current kernel.org files are a mix of different macro styles. Since this macro/register defines is used by different drivers a few patch series have ended up adding duplicate macro/register define entries with different styles. This makes these register define/macro files a complete mess and we want to make them clean and consistent. This patch cleans up a part of it. Signed-off-by: Hariprasad Shenai --- drivers/infiniband/hw/cxgb4/cm.c | 56 drivers/infiniband/hw/cxgb4/cq.c |8 +- drivers/infiniband/hw/cxgb4/mem.c | 14 +- drivers/infiniband/hw/cxgb4/qp.c | 26 ++-- drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |2 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.h |6 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 60 drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 15 +- drivers/net/ethernet/chelsio/cxgb4/sge.c | 32 ++-- drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 121 +++--- drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 142 + drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 32 ++-- drivers/net/ethernet/chelsio/cxgb4vf/t4vf_common.h |2 +- drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c | 150 +- drivers/scsi/csiostor/csio_attr.c |8 +- drivers/scsi/csiostor/csio_hw.c| 14 +- drivers/scsi/csiostor/csio_lnode.c | 18 +- drivers/scsi/csiostor/csio_mb.c| 172 ++-- drivers/scsi/csiostor/csio_scsi.c | 24 ++-- drivers/scsi/csiostor/csio_wr.h|2 +- drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 35 ++-- 21 files changed, 509 insertions(+), 430 deletions(-) diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c index fb61f66..5c0e3b9 100644 --- a/drivers/infiniband/hw/cxgb4/cm.c +++ b/drivers/infiniband/hw/cxgb4/cm.c @@ -472,10 +472,10 @@ static void send_flowc(struct c4iw_ep *ep, struct sk_buff *skb) skb = get_skb(skb, flowclen, GFP_KERNEL); flowc = (struct fw_flowc_wr *)__skb_put(skb, flowclen); - flowc->op_to_nparams = cpu_to_be32(FW_WR_OP(FW_FLOWC_WR) | - FW_FLOWC_WR_NPARAMS(8)); - flowc->flowid_len16 = cpu_to_be32(FW_WR_LEN16(DIV_ROUND_UP(flowclen, - 16)) | FW_WR_FLOWID(ep->hwtid)); + flowc->op_to_nparams = cpu_to_be32(V_FW_WR_OP(FW_FLOWC_WR) | + V_FW_FLOWC_WR_NPARAMS(8)); + flowc->flowid_len16 = cpu_to_be32(V_FW_WR_LEN16(DIV_ROUND_UP(flowclen, + 16)) | V_FW_WR_FLOWID(ep->hwtid)); flowc->mnemval[0].mnemonic = FW_FLOWC_MNEM_PFNVFN; flowc->mnemval[0].val = cpu_to_be32(FW_PFVF_CMD_PFN @@ -803,16 +803,16 @@ static void send_mpa_req(struct c4iw_ep *ep, struct sk_buff *skb, req = (struct fw_ofld_tx_data_wr *)skb_put(skb, wrlen); memset(req, 0, wrlen); req->op_to_immdlen = cpu_to_be32( - FW_WR_OP(FW_OFLD_TX_DATA_WR) | - FW_WR_COMPL(1) | - FW_WR_IMMDLEN(mpalen)); + V_FW_WR_OP(FW_OFLD_TX_DATA_WR) | + F_FW_WR_COMPL | + V_FW_WR_IMMDLEN(mpalen)); req->flowid_len16 = cpu_to_be32( - FW_WR_FLOWID(ep->hwtid) | - FW_WR_LEN16(wrlen >> 4)); + V_FW_WR_FLOWID(ep->hwtid) | + V_FW_WR_LEN16(wrlen >> 4)); req->plen = cpu_to_be32(mpalen); req->tunnel_to_proxy = cpu_to_be32( - FW_OFLD_TX_DATA_WR_FLUSH(1) | - FW_OFLD_TX_DATA_WR_SHOVE(1)); + F_FW_OFLD_TX_DATA_WR_FLUSH | + F_FW_OFLD_TX_DATA_WR_SHOVE); mpa = (struct mpa_message *)(req + 1); memcpy(mpa->key, MPA_KEY_REQ, sizeof(mpa->key)); @@ -897,16 +897,16 @@ static int send_mpa_reject(struct c4iw_ep *ep, const void *pdata, u8 plen) req = (struct fw_ofld_tx_data_wr *)skb_put(skb, wrlen); memset(req, 0, wrlen); req->op_to_immdlen = cpu_to_be32( - FW_WR_OP(FW_OFLD_TX_DATA_WR) | - FW_WR_COMPL(1) | - FW_WR_IMMDLEN(mpalen)); + V_FW_WR_OP(FW_OFLD_TX_DATA_WR) | + F_FW_WR_COMPL | + V_FW_WR_IMMDLEN(mpalen)); req->flowid_len16 = cpu_to_be32( - FW_WR_FLOWID(ep->hwtid) | - FW_WR_LEN16(wrlen >> 4)); + V_FW_WR_FLOWID(ep->hwtid) | + V_FW_WR_LEN16(wrlen >> 4)); req->plen = cpu_to_be32(mpalen); req->tunnel_to_proxy = cpu_to_be32( -
[PATCHv2 net-next 0/3] RDMA/cxgb4,cxgb4vf,cxgb4i,csiostor: Cleanup macros
Hi, This series moves the debugfs code to a new file debugfs.c and cleans up macros/register defines. It's not really the "hardware" which generates these hardware constant symbolic macros/register defines of course, it's scripts developed by the hardware team. Various patches have ended up changing the style of the symbolic macros/register defines and some of them used the macros/register defines that matches the output of the script from the hardware team. As a result, the current kernel.org files are a mix of different macro styles. Since this macro/register defines is used by five different drivers, a few patch series have ended up adding duplicate macro/register define entries with different styles. This makes these register define/macro files a complete mess and we want to make them clean and consistent. Will post few more series so that we can cover all the macros so that they all follow the same style to be consistent. The patches series is created against 'net-next' tree. And includes patches on cxgb4, cxgb4vf, iw_cxgb4, csiostor and cxgb4i driver. We have included all the maintainers of respective drivers. Kindly review the change and let us know in case of any review comments. Thanks V2: Changes the description and cover-letter content to answer David Miller's question Hariprasad Shenai (3): cxgb4: Add cxgb4_debugfs.c, move all debugfs code to new file cxgb4: Cleanup macros so they follow the same style and look consistent cxgb4: Cleanup macros so they follow the same style and look consistent, part 2 drivers/infiniband/hw/cxgb4/cm.c | 56 +++--- drivers/infiniband/hw/cxgb4/cq.c |8 +- drivers/infiniband/hw/cxgb4/mem.c | 14 +- drivers/infiniband/hw/cxgb4/qp.c | 26 ++-- drivers/net/ethernet/chelsio/cxgb4/Makefile|1 + drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |3 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.h |6 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 158 ++ drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h | 52 ++ drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 173 +--- drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 15 +- drivers/net/ethernet/chelsio/cxgb4/sge.c | 32 ++-- drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 127 +++--- drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 72 +++-- drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 142 drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 32 ++-- drivers/net/ethernet/chelsio/cxgb4vf/t4vf_common.h |2 +- drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c | 150 +- drivers/scsi/csiostor/csio_attr.c |8 +- drivers/scsi/csiostor/csio_hw.c| 14 +- drivers/scsi/csiostor/csio_hw_t4.c | 15 +- drivers/scsi/csiostor/csio_hw_t5.c | 21 ++- drivers/scsi/csiostor/csio_init.c |6 +- drivers/scsi/csiostor/csio_lnode.c | 18 +- drivers/scsi/csiostor/csio_mb.c| 172 ++-- drivers/scsi/csiostor/csio_scsi.c | 24 ++-- drivers/scsi/csiostor/csio_wr.h|2 +- drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 35 ++-- 28 files changed, 816 insertions(+), 568 deletions(-) create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WRITE/SEND to multiple destinations
You can do SEND/RECV over Unreliable Datagram multicast which could be beneficial in your situation (i.e., better than 1-1 connections). You can't use multicast for READs or WRITEs. --Anuj On Sun, Nov 2, 2014 at 9:32 PM, floaterions wrote: > Hello everyone, > > As a newbie to the world of InfiniBand programming, > I would appreciate your helps on my somewhat general and basic question. > > Assume that I have a server, and N clients (N > 1). > I would like my server to set all clients' memory buffers to some value V. > How would I go about this problem? > So far, I've managed to establish 1-1 connections using > READ/WRITE/SEND/RECEIVE. > So I guess the core of my question is: > how 1-to-N connections are established in InfiniBand, and > if, in this regard, there is any difference between > RDMA verbs (READ/WRITE) vs. SEND/RECEIVE? > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 0/3] RDMA/cxgb4,cxgb4vf,cxgb4i,csiostor: Cleanup macros
From: Hariprasad Shenai Date: Mon, 3 Nov 2014 17:46:51 +0530 > This series moves the debugfs code to a new file debugfs.c, Cleans up macros > so > that they match the hardware generated one. How does "hardware generate the macros"? I don't understand what this means at all. Whatever your better explanation is, you'll have include it in a respun version of this patch series. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH libibverbs] Add MR re-registeration
On Mon, Nov 03, 2014 at 10:28:25AM +0200, Matan Barak wrote:
> On 3/11/2014 4:50 AM, Jason Gunthorpe wrote:
> >On Sun, Nov 02, 2014 at 11:30:05AM +0200, Or Gerlitz wrote:
> >
> >>@@ -886,7 +887,7 @@ struct ibv_context_ops {
> >>int (*dealloc_pd)(struct ibv_pd *pd);
> >>struct ibv_mr * (*reg_mr)(struct ibv_pd *pd, void *addr, size_t
> >> length,
> >> int access);
> >>- struct ibv_mr * (*rereg_mr)(struct ibv_mr *mr,
> >>+ int (*rereg_mr)(struct ibv_mr *mr,
> >>int flags,
> >>struct ibv_pd *pd, void *addr,
> >>size_t length,
> >
> >What is going on here?
> >
> >Signatures in the ops structure should not be changed without quite a
> >bit more explanation. I'd like to see this in a dedicated patch with a
> >proper discussion about why it is safe...
> I don't mind re-spin this change into another patch, but since I
> don't consider the current state of libibverbs as having memory
> re-registration support, I don't think it's necessary.
Even so, this changes ABI senstive structures so it needs to be in a
dedicated patch and you must include this rational for why it is safe.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix Penguin Penalty 17th October2014 ( mail-archive.com )
Dear Sir Did your website get hit by Google Penguin update on October 17th 2014? What basically is Google Penguin Update? It is actually a code name for Google algorithm which aims at decreasing your websites search engine rankings that violate Googles guidelines by using black hat SEO techniques to rank your webpage by giving number of spammy links to the page. We are one of those few SEO companies that can help you avoid penalties from Google Updates like Penguin and Panda. Our clients have survived all the previous and present updates with ease. They have never been hit because we use 100% white hat SEO techniques to rank Webpages. Simple thing that we do to keep websites away from any Penguin or Panda penalties is follow Google guidelines and we give Google users the best answers to their queries. If you are looking to increase the quality of your websites and to get more targeted traffic or save your websites from these Google penalties email us back with your interest. We will be glad to serve you and help you grow your business. Regards Vince G SEO Manager ( TOB ) B7 Green Avenue, Amritsar 143001 Punjab NO CLICK in the subject to STOP EMAILS -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH opensm] Better way to handle polling other MASTER SM
From: Alex Netes
In the case where another MASTER SM disappears, call
OSM_SM_SIGNAL_POLLING_TIMEOUT to reconfigure the fabric from scratch.
Signed-off-by: Alex Netes
Signed-off-by: Hal Rosenstock
---
opensm/osm_drop_mgr.c |3 ---
opensm/osm_state_mgr.c |7 +++
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/opensm/osm_drop_mgr.c b/opensm/osm_drop_mgr.c
index ab06bf8..8441f89 100644
--- a/opensm/osm_drop_mgr.c
+++ b/opensm/osm_drop_mgr.c
@@ -257,9 +257,6 @@ static void drop_mgr_remove_port(osm_sm_t * sm, IN
osm_port_t * p_port)
OSM_LOG(sm->p_log, OSM_LOG_VERBOSE,
"Cleaned SM for port guid 0x%016" PRIx64 "\n",
cl_ntoh64(port_guid));
- /* clean up the polling_sm_guid */
- if (sm->polling_sm_guid == p_sm->smi.guid)
- sm->polling_sm_guid = 0;
free(p_sm);
}
diff --git a/opensm/osm_state_mgr.c b/opensm/osm_state_mgr.c
index 9798b41..1dc6e19 100644
--- a/opensm/osm_state_mgr.c
+++ b/opensm/osm_state_mgr.c
@@ -1404,10 +1404,17 @@ repeat_discovery:
* need to wait for that SM to relinquish
control
* of its portion of the subnet. C14-60.2.1.
* Also - need to start polling on that SM. */
+ CL_PLOCK_EXCL_ACQUIRE(sm->p_lock);
sm->polling_sm_guid = p_remote_sm->smi.guid;
+ CL_PLOCK_RELEASE(sm->p_lock);
osm_sm_state_mgr_process(sm,
OSM_SM_SIGNAL_WAIT_FOR_HANDOVER);
return;
+ } else if (sm->polling_sm_guid) {
+ /* Stop polling SM if it's not found */
+ osm_sm_state_mgr_process(sm,
+
OSM_SM_SIGNAL_POLLING_TIMEOUT);
+ return;
}
}
}
--
1.7.8.2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] IB/isert: Adjust CQ size to HW limits
> -Original Message- > From: Sagi Grimberg [mailto:sa...@dev.mellanox.co.il] > Sent: Sunday, November 02, 2014 4:37 AM > To: Chris Moore; linux-rdma@vger.kernel.org > Cc: Nicholas A. Bellinger > Subject: Re: [PATCH] IB/isert: Adjust CQ size to HW limits > > On 10/31/2014 9:50 PM, Chris Moore wrote: > > > > This is the isert version of the patch that Minh Tran submitted for iser. > > isert has the same issue of trying to create a CQ with more CQEs than > > are supported by the hardware. > > > > ib_isert is maintained in target-devel. Can you resend it there? > > Thanks! > > Sagi. Yep, no problem, I'll do that. There was another issue in ib_isert.c that Nic proposed a fix for in an email back on 10/22. This was the issue with attr.cap.max_send_sge being set to (device->dev_attr.max_sge - 2) instead of just device->dev_attr.max_sge. Should I post that issue to target-devel as well? Thanks, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 3/3] cxgb4: Cleanup macros to match the HW generated one, part 2
Signed-off-by: Hariprasad Shenai --- drivers/infiniband/hw/cxgb4/cm.c | 56 drivers/infiniband/hw/cxgb4/cq.c |8 +- drivers/infiniband/hw/cxgb4/mem.c | 14 +- drivers/infiniband/hw/cxgb4/qp.c | 26 ++-- drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |2 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.h |6 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 60 drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 15 +- drivers/net/ethernet/chelsio/cxgb4/sge.c | 32 ++-- drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 121 +++--- drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 142 + drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 32 ++-- drivers/net/ethernet/chelsio/cxgb4vf/t4vf_common.h |2 +- drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c | 150 +- drivers/scsi/csiostor/csio_attr.c |8 +- drivers/scsi/csiostor/csio_hw.c| 14 +- drivers/scsi/csiostor/csio_lnode.c | 18 +- drivers/scsi/csiostor/csio_mb.c| 172 ++-- drivers/scsi/csiostor/csio_scsi.c | 24 ++-- drivers/scsi/csiostor/csio_wr.h|2 +- drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 35 ++-- 21 files changed, 509 insertions(+), 430 deletions(-) diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c index fb61f66..5c0e3b9 100644 --- a/drivers/infiniband/hw/cxgb4/cm.c +++ b/drivers/infiniband/hw/cxgb4/cm.c @@ -472,10 +472,10 @@ static void send_flowc(struct c4iw_ep *ep, struct sk_buff *skb) skb = get_skb(skb, flowclen, GFP_KERNEL); flowc = (struct fw_flowc_wr *)__skb_put(skb, flowclen); - flowc->op_to_nparams = cpu_to_be32(FW_WR_OP(FW_FLOWC_WR) | - FW_FLOWC_WR_NPARAMS(8)); - flowc->flowid_len16 = cpu_to_be32(FW_WR_LEN16(DIV_ROUND_UP(flowclen, - 16)) | FW_WR_FLOWID(ep->hwtid)); + flowc->op_to_nparams = cpu_to_be32(V_FW_WR_OP(FW_FLOWC_WR) | + V_FW_FLOWC_WR_NPARAMS(8)); + flowc->flowid_len16 = cpu_to_be32(V_FW_WR_LEN16(DIV_ROUND_UP(flowclen, + 16)) | V_FW_WR_FLOWID(ep->hwtid)); flowc->mnemval[0].mnemonic = FW_FLOWC_MNEM_PFNVFN; flowc->mnemval[0].val = cpu_to_be32(FW_PFVF_CMD_PFN @@ -803,16 +803,16 @@ static void send_mpa_req(struct c4iw_ep *ep, struct sk_buff *skb, req = (struct fw_ofld_tx_data_wr *)skb_put(skb, wrlen); memset(req, 0, wrlen); req->op_to_immdlen = cpu_to_be32( - FW_WR_OP(FW_OFLD_TX_DATA_WR) | - FW_WR_COMPL(1) | - FW_WR_IMMDLEN(mpalen)); + V_FW_WR_OP(FW_OFLD_TX_DATA_WR) | + F_FW_WR_COMPL | + V_FW_WR_IMMDLEN(mpalen)); req->flowid_len16 = cpu_to_be32( - FW_WR_FLOWID(ep->hwtid) | - FW_WR_LEN16(wrlen >> 4)); + V_FW_WR_FLOWID(ep->hwtid) | + V_FW_WR_LEN16(wrlen >> 4)); req->plen = cpu_to_be32(mpalen); req->tunnel_to_proxy = cpu_to_be32( - FW_OFLD_TX_DATA_WR_FLUSH(1) | - FW_OFLD_TX_DATA_WR_SHOVE(1)); + F_FW_OFLD_TX_DATA_WR_FLUSH | + F_FW_OFLD_TX_DATA_WR_SHOVE); mpa = (struct mpa_message *)(req + 1); memcpy(mpa->key, MPA_KEY_REQ, sizeof(mpa->key)); @@ -897,16 +897,16 @@ static int send_mpa_reject(struct c4iw_ep *ep, const void *pdata, u8 plen) req = (struct fw_ofld_tx_data_wr *)skb_put(skb, wrlen); memset(req, 0, wrlen); req->op_to_immdlen = cpu_to_be32( - FW_WR_OP(FW_OFLD_TX_DATA_WR) | - FW_WR_COMPL(1) | - FW_WR_IMMDLEN(mpalen)); + V_FW_WR_OP(FW_OFLD_TX_DATA_WR) | + F_FW_WR_COMPL | + V_FW_WR_IMMDLEN(mpalen)); req->flowid_len16 = cpu_to_be32( - FW_WR_FLOWID(ep->hwtid) | - FW_WR_LEN16(wrlen >> 4)); + V_FW_WR_FLOWID(ep->hwtid) | + V_FW_WR_LEN16(wrlen >> 4)); req->plen = cpu_to_be32(mpalen); req->tunnel_to_proxy = cpu_to_be32( - FW_OFLD_TX_DATA_WR_FLUSH(1) | - FW_OFLD_TX_DATA_WR_SHOVE(1)); + F_FW_OFLD_TX_DATA_WR_FLUSH | + F_FW_OFLD_TX_DATA_WR_SHOVE); mpa = (struct mpa_message *)(req + 1); memset(mpa, 0, sizeof(*mpa)); @@ -977,16 +977,16 @@ static int send_mpa_reply(struct c4iw_ep *ep, const void *pdata, u8 plen) req = (struct fw_ofld_tx_data_wr *) skb_put(skb, wrlen); memset(req, 0, wrlen); req->op_to_immdlen = cpu_to_be32( - FW_WR_OP(FW_OFLD_TX_DATA_WR) | - FW_WR_COMPL(1) | -
[PATCH net-next 0/3] RDMA/cxgb4,cxgb4vf,cxgb4i,csiostor: Cleanup macros
Hi, This series moves the debugfs code to a new file debugfs.c, Cleans up macros so that they match the hardware generated one. Will post few more series so that we can cover all the macros so that they all follow the same conventions and looks clean. The patches series is created against 'net-next' tree. And includes patches on cxgb4, cxgb4vf, iw_cxgb4, csiostor and cxgb4i driver. We have included all the maintainers of respective drivers. Kindly review the change and let us know in case of any review comments. Thanks Hariprasad Shenai (3): cxgb4: Add cxgb4_debugfs.c, move all debugfs code to new file cxgb4: Cleanup macros to match the HW generated one cxgb4: Cleanup macros to match the HW generated one, part 2 drivers/infiniband/hw/cxgb4/cm.c | 56 +++--- drivers/infiniband/hw/cxgb4/cq.c |8 +- drivers/infiniband/hw/cxgb4/mem.c | 14 +- drivers/infiniband/hw/cxgb4/qp.c | 26 ++-- drivers/net/ethernet/chelsio/cxgb4/Makefile|1 + drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |3 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.h |6 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 158 ++ drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h | 52 ++ drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 173 +--- drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 15 +- drivers/net/ethernet/chelsio/cxgb4/sge.c | 32 ++-- drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 127 +++--- drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 72 +++-- drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 142 drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 32 ++-- drivers/net/ethernet/chelsio/cxgb4vf/t4vf_common.h |2 +- drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c | 150 +- drivers/scsi/csiostor/csio_attr.c |8 +- drivers/scsi/csiostor/csio_hw.c| 14 +- drivers/scsi/csiostor/csio_hw_t4.c | 15 +- drivers/scsi/csiostor/csio_hw_t5.c | 21 ++- drivers/scsi/csiostor/csio_init.c |6 +- drivers/scsi/csiostor/csio_lnode.c | 18 +- drivers/scsi/csiostor/csio_mb.c| 172 ++-- drivers/scsi/csiostor/csio_scsi.c | 24 ++-- drivers/scsi/csiostor/csio_wr.h|2 +- drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 35 ++-- 28 files changed, 816 insertions(+), 568 deletions(-) create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 1/3] cxgb4: Add cxgb4_debugfs.c, move all debugfs code to new file
Signed-off-by: Hariprasad Shenai
---
drivers/net/ethernet/chelsio/cxgb4/Makefile|1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 158
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h | 52 +++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 97 +
5 files changed, 217 insertions(+), 92 deletions(-)
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h
diff --git a/drivers/net/ethernet/chelsio/cxgb4/Makefile
b/drivers/net/ethernet/chelsio/cxgb4/Makefile
index 1df65c9..b852807 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/Makefile
+++ b/drivers/net/ethernet/chelsio/cxgb4/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_CHELSIO_T4) += cxgb4.o
cxgb4-objs := cxgb4_main.o l2t.o t4_hw.o sge.o
cxgb4-$(CONFIG_CHELSIO_T4_DCB) += cxgb4_dcb.o
+cxgb4-$(CONFIG_DEBUG_FS) += cxgb4_debugfs.o
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 3c481b2..dad1ea9 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -1085,4 +1085,5 @@ void t4_db_dropped(struct adapter *adapter);
int t4_fwaddrspace_write(struct adapter *adap, unsigned int mbox,
u32 addr, u32 val);
void t4_sge_decode_idma_state(struct adapter *adapter, int state);
+void t4_free_mem(void *addr);
#endif /* __CXGB4_H__ */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
new file mode 100644
index 000..e86b5fe
--- /dev/null
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -0,0 +1,158 @@
+/*
+ * This file is part of the Chelsio T4 Ethernet driver for Linux.
+ *
+ * Copyright (c) 2003-2014 Chelsio Communications, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "cxgb4.h"
+#include "t4_regs.h"
+#include "t4fw_api.h"
+#include "cxgb4_debugfs.h"
+#include "l2t.h"
+
+static ssize_t mem_read(struct file *file, char __user *buf, size_t count,
+ loff_t *ppos)
+{
+ loff_t pos = *ppos;
+ loff_t avail = file_inode(file)->i_size;
+ unsigned int mem = (uintptr_t)file->private_data & 3;
+ struct adapter *adap = file->private_data - mem;
+ __be32 *data;
+ int ret;
+
+ if (pos < 0)
+ return -EINVAL;
+ if (pos >= avail)
+ return 0;
+ if (count > avail - pos)
+ count = avail - pos;
+
+ data = t4_alloc_mem(count);
+ if (!data)
+ return -ENOMEM;
+
+ spin_lock(&adap->win0_lock);
+ ret = t4_memory_rw(adap, 0, mem, pos, count, data, T4_MEMORY_READ);
+ spin_unlock(&adap->win0_lock);
+ if (ret) {
+ t4_free_mem(data);
+ return ret;
+ }
+ ret = copy_to_user(buf, data, count);
+
+ t4_free_mem(data);
+ if (ret)
+ return -EFAULT;
+
+ *ppos = pos + count;
+ return count;
+}
+
+static const struct file_operations mem_debugfs_fops = {
+ .owner = THIS_MODULE,
+ .open= simple_open,
+ .read= mem_read,
+ .llseek = default_llseek,
+};
+
+static void add_debugfs_mem(struct adapter *adap, const char *name,
+ unsigned int idx, unsigned int size_mb)
+{
+ struct dentry *de;
+
+ de = debugfs_create_file(name, S_IRUSR, adap->debugfs_root,
+
[PATCH net-next 2/3] cxgb4: Cleanup macros to match the HW generated one
Signed-off-by: Hariprasad Shenai
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 32 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 16 +++--
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c |6 +-
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 72 +++-
drivers/scsi/csiostor/csio_hw_t4.c | 15 ++--
drivers/scsi/csiostor/csio_hw_t5.c | 21 +++---
drivers/scsi/csiostor/csio_init.c |6 +-
7 files changed, 106 insertions(+), 62 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index e86b5fe..aa75c91 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -128,30 +128,30 @@ int t4_setup_debugfs(struct adapter *adap)
t4_debugfs_files,
ARRAY_SIZE(t4_debugfs_files));
- i = t4_read_reg(adap, MA_TARGET_MEM_ENABLE);
- if (i & EDRAM0_ENABLE) {
- size = t4_read_reg(adap, MA_EDRAM0_BAR);
- add_debugfs_mem(adap, "edc0", MEM_EDC0, EDRAM_SIZE_GET(size));
+ i = t4_read_reg(adap, A_MA_TARGET_MEM_ENABLE);
+ if (i & F_EDRAM0_ENABLE) {
+ size = t4_read_reg(adap, A_MA_EDRAM0_BAR);
+ add_debugfs_mem(adap, "edc0", MEM_EDC0, G_EDRAM0_SIZE(size));
}
- if (i & EDRAM1_ENABLE) {
- size = t4_read_reg(adap, MA_EDRAM1_BAR);
- add_debugfs_mem(adap, "edc1", MEM_EDC1, EDRAM_SIZE_GET(size));
+ if (i & F_EDRAM1_ENABLE) {
+ size = t4_read_reg(adap, A_MA_EDRAM1_BAR);
+ add_debugfs_mem(adap, "edc1", MEM_EDC1, G_EDRAM1_SIZE(size));
}
if (is_t4(adap->params.chip)) {
- size = t4_read_reg(adap, MA_EXT_MEMORY_BAR);
- if (i & EXT_MEM_ENABLE)
+ size = t4_read_reg(adap, A_MA_EXT_MEMORY_BAR);
+ if (i & F_EXT_MEM_ENABLE)
add_debugfs_mem(adap, "mc", MEM_MC,
- EXT_MEM_SIZE_GET(size));
+ G_EXT_MEM_SIZE(size));
} else {
- if (i & EXT_MEM_ENABLE) {
- size = t4_read_reg(adap, MA_EXT_MEMORY_BAR);
+ if (i & F_EXT_MEM0_ENABLE) {
+ size = t4_read_reg(adap, A_MA_EXT_MEMORY0_BAR);
add_debugfs_mem(adap, "mc0", MEM_MC0,
- EXT_MEM_SIZE_GET(size));
+ G_EXT_MEM0_SIZE(size));
}
- if (i & EXT_MEM1_ENABLE) {
- size = t4_read_reg(adap, MA_EXT_MEMORY1_BAR);
+ if (i & F_EXT_MEM1_ENABLE) {
+ size = t4_read_reg(adap, A_MA_EXT_MEMORY1_BAR);
add_debugfs_mem(adap, "mc1", MEM_MC1,
- EXT_MEM_SIZE_GET(size));
+ G_EXT_MEM1_SIZE(size));
}
}
return 0;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 172f68b..65ce937 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -3802,7 +3802,7 @@ int cxgb4_read_tpte(struct net_device *dev, u32 stag,
__be32 *tpte)
{
struct adapter *adap;
u32 offset, memtype, memaddr;
- u32 edc0_size, edc1_size, mc0_size, mc1_size;
+ u32 edc0_size, edc1_size, mc0_size, mc1_size, size;
u32 edc0_end, edc1_end, mc0_end, mc1_end;
int ret;
@@ -3816,9 +3816,12 @@ int cxgb4_read_tpte(struct net_device *dev, u32 stag,
__be32 *tpte)
* and EDC1. Some cards will have neither MC0 nor MC1, most cards have
* MC0, and some have both MC0 and MC1.
*/
- edc0_size = EDRAM_SIZE_GET(t4_read_reg(adap, MA_EDRAM0_BAR)) << 20;
- edc1_size = EDRAM_SIZE_GET(t4_read_reg(adap, MA_EDRAM1_BAR)) << 20;
- mc0_size = EXT_MEM_SIZE_GET(t4_read_reg(adap, MA_EXT_MEMORY_BAR)) << 20;
+ size = t4_read_reg(adap, A_MA_EDRAM0_BAR);
+ edc0_size = G_EDRAM0_SIZE(size) << 20;
+ size = t4_read_reg(adap, A_MA_EDRAM1_BAR);
+ edc1_size = G_EDRAM1_SIZE(size) << 20;
+ size = t4_read_reg(adap, A_MA_EXT_MEMORY0_BAR);
+ mc0_size = G_EXT_MEM0_SIZE(size) << 20;
edc0_end = edc0_size;
edc1_end = edc0_end + edc1_size;
@@ -3838,9 +3841,8 @@ int cxgb4_read_tpte(struct net_device *dev, u32 stag,
__be32 *tpte)
/* T4 only has a single memory channel */
goto err;
} else {
- mc1_size = EXT_MEM_SIZE_GET(
- t4_read_reg(adap,
- MA_EXT_MEMORY1_BAR)) << 20;
+
Re: CRASH 3.18-rc2, 3.17.1, isert_connect_request
W dniu 03.11.2014 o 12:27, Sagi Grimberg pisze: On 11/3/2014 12:28 PM, Adam Mazur wrote: Can someone help us with these crashes? We are not able to recreate it on demand, but it takes 30 minutes to a few hours to appear the crash. We've seen it on kernel 3.17.1 and 3.18-rc2. Hay Adam, CC'ing target-devel mailing list (where iser target is maintained). So I stepped on this issue as well, and I actually have a fix for it in the pipe. I'm planning to test it with a few other fixes for a little while longer before I submit the code. In general, This crash occurs due to a race between tpg shutdown (or np disable) and RDMA_CM connect requests happening in parallel. iser target tries to reference a tpg attribute while the np->tpg_np is actually NULL. How many targets/initiators/portals did you use? HCA? Hi Sagi, There are about 300 targets (lvm volumes), 4 initiators, two portals. HCA by lspci: 05:00.0 InfiniBand: Mellanox Technologies MT25204 [InfiniHost III Lx HCA] (rev 20) Subsystem: Mellanox Technologies MT25204 [InfiniHost III Lx HCA] Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at df50 (64-bit, non-prefetchable) [size=1M] Memory at de80 (64-bit, prefetchable) [size=8M] Capabilities: [40] Power Management version 2 Capabilities: [48] Vital Product Data Capabilities: [90] MSI: Enable- Count=1/32 Maskable- 64bit+ Capabilities: [84] MSI-X: Enable+ Count=32 Masked- Capabilities: [60] Express Endpoint, MSI 00 Kernel driver in use: ib_mthca root@portal-1:~# mstflint -d 05:00.0 q Image type: Failsafe FW Version: 1.2.0 I.S. Version:1 Device ID: 25204 Chip Revision: A0 Description: Node Port1Sys image GUIDs: 0005ad0c75c8 0005ad0c75c9 0005ad0c75cb Board ID: (MT_026002) VSD: PSID:MT_026002 root@portal-2:~# mstflint -d 05:00.0 q Image type: Failsafe I.S. Version:1 Chip Revision: A0 Description: Node Port1Sys image GUIDs: 0005ad0c7010 0005ad0c7011 0005ad0c7013 Board ID: (MT_026002) VSD: PSID:MT_026002 Would it be possible to send you some patches to test as well? Absolutely, we can immediately test any patch on any kernel version. Thanks Adam -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CRASH 3.18-rc2, 3.17.1, isert_connect_request
On 11/3/2014 12:28 PM, Adam Mazur wrote:
Can someone help us with these crashes? We are not able to recreate it
on demand, but it takes 30 minutes to a few hours to appear the crash.
We've seen it on kernel 3.17.1 and 3.18-rc2.
Hay Adam,
CC'ing target-devel mailing list (where iser target is maintained).
So I stepped on this issue as well, and I actually have a fix for it
in the pipe. I'm planning to test it with a few other fixes for a little
while longer before I submit the code.
In general, This crash occurs due to a race between tpg shutdown (or
np disable) and RDMA_CM connect requests happening in parallel. iser
target tries to reference a tpg attribute while the np->tpg_np is
actually NULL.
How many targets/initiators/portals did you use? HCA?
Would it be possible to send you some patches to test as well?
Thanks for the report!
Sagi.
On 3.18-rc2 it leaves such tracebacks:
BUG: unable to handle kernel NULL pointer dereference at 0720
IP: [] isert_connect_request.isra.48+0x2fd/0x7d0
[ib_isert]
PGD 0
Oops: [#1] SMP
Modules linked in: target_core_user uio target_core_pscsi
target_core_file target_core_iblock dm_thin_pool(OE) dm_persistent_data
dm_bio_prison dm_bufio libcrc32c gpio_ich intel_powerclamp core
temp kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel dcdbas ast
aesni_intel ttm drm_kms_helper aes_x86_64 lrw gf128mul glue_helper
ablk_helper cryptd drm syscopyarea sysfillrect sysimgblt
joydev serio_raw i7core_edac ib_mthca ib_isert lpc_ich edac_core
iscsi_target_mod ipmi_si 8250_fintek mac_hid ib_iser ipmi_msghandler
libiscsi scsi_transport_iscsi rdma_ucm ib_uverbs rdma_cm iw_
cm ib_ipoib ib_srpt ib_cm ib_sa target_core_mod configfs ib_umad ib_mad
ib_core ib_addr lp parport bcache raid10 raid456 async_raid6_recov
async_memcpy async_pq async_xor async_tx xor hid_generi
c usbhid hid raid6_pq igb raid1 ahci i2c_algo_bit raid0 dca libahci ptp
megaraid_sas pps_core multipath linear
CPU: 3 PID: 23400 Comm: kworker/3:2 Tainted: G OE
3.18.0-031800rc2-generic #201410281737
Hardware name: Dell FS12-TY / ,
BIOS C99Q3B23 08/16/2012
Workqueue: ib_cm cm_work_handler [ib_cm]
task: 8803ca928000 ti: 8803ca8b8000 task.ti: 8803ca8b8000
RIP: 0010:[] []
isert_connect_request.isra.48+0x2fd/0x7d0 [ib_isert]
RSP: 0018:8803ca8bbbf8 EFLAGS: 00010283
RAX: RBX: 8803e53b0800 RCX: 9484
RDX: 880424b08000 RSI: 8803e8638d80 RDI: 88042ec03d00
RBP: 8803ca8bbc48 R08: 000173e0 R09: ea000fa18e00
R10: c060ab31 R11: R12: 880424b08000
R13: 88041a2a7400 R14: 88041215f800 R15:
FS: () GS:88042f26()
knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0720 CR3: 01c16000 CR4: 07e0
Stack:
8803e53b0c58 8803ca8bbc9a 880412a2a680 8800b7a16000
c9750cad0500 88041a2a7400 8803ca8bbc88 880411ca3800
88042750e400 8803ca8bbc68 c05dcded
Call Trace:
[] isert_cma_handler+0x11d/0x170 [ib_isert]
[] cma_req_handler+0x196/0x430 [rdma_cm]
[] cm_process_work+0x30/0x140 [ib_cm]
[] cm_req_handler+0x274/0x3a0 [ib_cm]
[] cm_work_handler+0xb5/0x1d4 [ib_cm]
[] process_one_work+0x14e/0x460
[] worker_thread+0x11b/0x3f0
[] ? create_worker+0x1e0/0x1e0
[] kthread+0xc9/0xe0
[] ? flush_kthread_worker+0x90/0x90
[] ret_from_fork+0x7c/0xb0
[] ? flush_kthread_worker+0x90/0x90
Code: be 01 00 00 00 48 89 c7 e8 c1 af e4 ff 48 3d 00 f0 ff ff 48 89
83 90 05 00 00 0f 87 80 04 00 00 49 8b 86 78 01 00 00 48 8b 40 08 <0f>
b6 90 20 07 00 00 84 d2 74 0e 48 8b 45 c8 80 78 04 00 0f 84
RIP [] isert_connect_request.isra.48+0x2fd/0x7d0
[ib_isert]
RSP
CR2: 0720
---[ end trace b8718ad554264a63 ]---
followed by:
BUG: unable to handle kernel paging request at ffd8
IP: [] kthread_data+0x10/0x20
PGD 1c19067 PUD 1c1b067 PMD 0
Oops: [#2] SMP
Modules linked in: target_core_user uio target_core_pscsi
target_core_file target_core_iblock dm_thin_pool(OE) dm_persistent_data
dm_bio_prison dm_bufio libcrc32c gpio_ich intel_powerclamp coretemp kvm
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel dcdbas ast aesni_intel
ttm drm_kms_helper aes_x86_64 lrw gf128mul glue_helper ablk_helper
cryptd drm syscopyarea sysfillrect sysimgblt joydev serio_raw
i7core_edac ib_mthca ib_isert lpc_ich edac_core iscsi_target_mod ipmi_si
8250_fintek mac_hid ib_iser ipmi_msghandler libiscsi
scsi_transport_iscsi rdma_ucm ib_uverbs rdma_cm iw_cm ib_ipoib ib_srpt
ib_cm ib_sa target_core_mod configfs ib_umad ib_mad ib_core ib_addr lp
parport bcache raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor hid_generic usbhid hid raid6_pq igb raid1 ahci
i2c_algo_bit raid0 dca libahci ptp megaraid_sas pps_core multip
CRASH 3.18-rc2, 3.17.1, isert_connect_request
Can someone help us with these crashes? We are not able to recreate it on demand, but it takes 30 minutes to a few hours to appear the crash. We've seen it on kernel 3.17.1 and 3.18-rc2. On 3.18-rc2 it leaves such tracebacks: BUG: unable to handle kernel NULL pointer dereference at 0720 IP: [] isert_connect_request.isra.48+0x2fd/0x7d0 [ib_isert] PGD 0 Oops: [#1] SMP Modules linked in: target_core_user uio target_core_pscsi target_core_file target_core_iblock dm_thin_pool(OE) dm_persistent_data dm_bio_prison dm_bufio libcrc32c gpio_ich intel_powerclamp core temp kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel dcdbas ast aesni_intel ttm drm_kms_helper aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd drm syscopyarea sysfillrect sysimgblt joydev serio_raw i7core_edac ib_mthca ib_isert lpc_ich edac_core iscsi_target_mod ipmi_si 8250_fintek mac_hid ib_iser ipmi_msghandler libiscsi scsi_transport_iscsi rdma_ucm ib_uverbs rdma_cm iw_ cm ib_ipoib ib_srpt ib_cm ib_sa target_core_mod configfs ib_umad ib_mad ib_core ib_addr lp parport bcache raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor hid_generi c usbhid hid raid6_pq igb raid1 ahci i2c_algo_bit raid0 dca libahci ptp megaraid_sas pps_core multipath linear CPU: 3 PID: 23400 Comm: kworker/3:2 Tainted: G OE 3.18.0-031800rc2-generic #201410281737 Hardware name: Dell FS12-TY / , BIOS C99Q3B23 08/16/2012 Workqueue: ib_cm cm_work_handler [ib_cm] task: 8803ca928000 ti: 8803ca8b8000 task.ti: 8803ca8b8000 RIP: 0010:[] [] isert_connect_request.isra.48+0x2fd/0x7d0 [ib_isert] RSP: 0018:8803ca8bbbf8 EFLAGS: 00010283 RAX: RBX: 8803e53b0800 RCX: 9484 RDX: 880424b08000 RSI: 8803e8638d80 RDI: 88042ec03d00 RBP: 8803ca8bbc48 R08: 000173e0 R09: ea000fa18e00 R10: c060ab31 R11: R12: 880424b08000 R13: 88041a2a7400 R14: 88041215f800 R15: FS: () GS:88042f26() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0720 CR3: 01c16000 CR4: 07e0 Stack: 8803e53b0c58 8803ca8bbc9a 880412a2a680 8800b7a16000 c9750cad0500 88041a2a7400 8803ca8bbc88 880411ca3800 88042750e400 8803ca8bbc68 c05dcded Call Trace: [] isert_cma_handler+0x11d/0x170 [ib_isert] [] cma_req_handler+0x196/0x430 [rdma_cm] [] cm_process_work+0x30/0x140 [ib_cm] [] cm_req_handler+0x274/0x3a0 [ib_cm] [] cm_work_handler+0xb5/0x1d4 [ib_cm] [] process_one_work+0x14e/0x460 [] worker_thread+0x11b/0x3f0 [] ? create_worker+0x1e0/0x1e0 [] kthread+0xc9/0xe0 [] ? flush_kthread_worker+0x90/0x90 [] ret_from_fork+0x7c/0xb0 [] ? flush_kthread_worker+0x90/0x90 Code: be 01 00 00 00 48 89 c7 e8 c1 af e4 ff 48 3d 00 f0 ff ff 48 89 83 90 05 00 00 0f 87 80 04 00 00 49 8b 86 78 01 00 00 48 8b 40 08 <0f> b6 90 20 07 00 00 84 d2 74 0e 48 8b 45 c8 80 78 04 00 0f 84 RIP [] isert_connect_request.isra.48+0x2fd/0x7d0 [ib_isert] RSP CR2: 0720 ---[ end trace b8718ad554264a63 ]--- followed by: BUG: unable to handle kernel paging request at ffd8 IP: [] kthread_data+0x10/0x20 PGD 1c19067 PUD 1c1b067 PMD 0 Oops: [#2] SMP Modules linked in: target_core_user uio target_core_pscsi target_core_file target_core_iblock dm_thin_pool(OE) dm_persistent_data dm_bio_prison dm_bufio libcrc32c gpio_ich intel_powerclamp coretemp kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel dcdbas ast aesni_intel ttm drm_kms_helper aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd drm syscopyarea sysfillrect sysimgblt joydev serio_raw i7core_edac ib_mthca ib_isert lpc_ich edac_core iscsi_target_mod ipmi_si 8250_fintek mac_hid ib_iser ipmi_msghandler libiscsi scsi_transport_iscsi rdma_ucm ib_uverbs rdma_cm iw_cm ib_ipoib ib_srpt ib_cm ib_sa target_core_mod configfs ib_umad ib_mad ib_core ib_addr lp parport bcache raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor hid_generic usbhid hid raid6_pq igb raid1 ahci i2c_algo_bit raid0 dca libahci ptp megaraid_sas pps_core multipath linear CPU: 3 PID: 23400 Comm: kworker/3:2 Tainted: G DOE 3.18.0-031800rc2-generic #201410281737 Hardware name: Dell FS12-TY / , BIOS C99Q3B23 08/16/2012 task: 8803ca928000 ti: 8803ca8b8000 task.ti: 8803ca8b8000 RIP: 0010:[] [] kthread_data+0x10/0x20 RSP: 0018:8803ca8bb808 EFLAGS: 00010096 RAX: RBX: 0003 RCX: 81ec8e40 RDX: RSI: 0003 RDI: 8803ca928000 RBP: 8803ca8bb808 R08: R09: R10: R11: e5b0 R12: 0003 R13: 8803ca928538 R14: 0001 R15:
Re: [PATCH libibverbs] Add MR re-registeration
On 3/11/2014 4:50 AM, Jason Gunthorpe wrote:
On Sun, Nov 02, 2014 at 11:30:05AM +0200, Or Gerlitz wrote:
@@ -886,7 +887,7 @@ struct ibv_context_ops {
int (*dealloc_pd)(struct ibv_pd *pd);
struct ibv_mr * (*reg_mr)(struct ibv_pd *pd, void *addr, size_t
length,
int access);
- struct ibv_mr * (*rereg_mr)(struct ibv_mr *mr,
+ int (*rereg_mr)(struct ibv_mr *mr,
int flags,
struct ibv_pd *pd, void *addr,
size_t length,
What is going on here?
Signatures in the ops structure should not be changed without quite a
bit more explanation. I'd like to see this in a dedicated patch with a
proper discussion about why it is safe...
(I admit, I'm confused how this patch is adding rereg_mr when it
already sort of seems to exist)
Jason
Lets present the facts first - Neither ibv_rereg_mr nor the kernel ABI
and command structure exist before this patch. The only thing that did
exist was an API between libibverbs and the provider library.
As there was no way for a userspace program to ask for memory
re-registration, AFAIK this op wasn't used by any provider.
Furthermore, re-registering a MR shouldn't change the user's MR handle!
Hence, there's no need to return information that the user already
knows. Does ibv_modify_qp return struct ibv_qp? Both verbs should act
similarly.
I don't mind re-spin this change into another patch, but since I don't
consider the current state of libibverbs as having memory
re-registration support, I don't think it's necessary.
Matan
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/12] IB/srp: Use block layer tags
On Mon, Nov 03, 2014 at 01:22:18PM +0530, Kashyap Desai wrote: > I also used below setting in slave_alloc(), so that first Inquiry command > received by driver also has valid Tag in (Non-MQ mode). > sdev->tagged_supported = 1 > Without above setting Inquiry command comes with 0xFF. If I see below code > in scsi_scan.c, it looks like tagged_supported value should be popped by > after actual value reported from Inquiry command. > > if ((sdev->scsi_level >= SCSI_2) && (inq_result[7] & 2) && > !(*bflags & BLIST_NOTQ)) > sdev->tagged_supported = 1; > > Does it means what driver set in slave_alloc is OK to get Inquiry commands > with valid Tag ? > What will happen if Target really does not support Tagged command queue > and driver overwrite it in slave_alloc ? I think the right thing here is to better differenciate between assigning a software tag, and a SCSI tagged command. That is, we should assign a request->tag value for every command if we enable host wide tags, independent of issuing an actual tagged command. I'll send a series of patches for this ASAP. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH for-next 2/5] IB/core: Add support for extended query device caps
Add extensible query device capabilities verb to allow adding new features.
ib_uverbs_ex_query_device is added and copy_query_dev_fields is used to copy
capability fields to be used by both ib_uverbs_query_device and
ib_uverbs_ex_query_device.
Signed-off-by: Eli Cohen
---
drivers/infiniband/core/uverbs.h | 1 +
drivers/infiniband/core/uverbs_cmd.c | 127 +++---
drivers/infiniband/core/uverbs_main.c | 3 +-
include/uapi/rdma/ib_user_verbs.h | 12 +++-
4 files changed, 100 insertions(+), 43 deletions(-)
diff --git a/drivers/infiniband/core/uverbs.h b/drivers/infiniband/core/uverbs.h
index 643c08a025a5..b716b0815644 100644
--- a/drivers/infiniband/core/uverbs.h
+++ b/drivers/infiniband/core/uverbs.h
@@ -258,5 +258,6 @@ IB_UVERBS_DECLARE_CMD(close_xrcd);
IB_UVERBS_DECLARE_EX_CMD(create_flow);
IB_UVERBS_DECLARE_EX_CMD(destroy_flow);
+IB_UVERBS_DECLARE_EX_CMD(query_device);
#endif /* UVERBS_H */
diff --git a/drivers/infiniband/core/uverbs_cmd.c
b/drivers/infiniband/core/uverbs_cmd.c
index 5ba2a86aab6a..da3fd8cdd86e 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -378,6 +378,52 @@ err:
return ret;
}
+static void copy_query_dev_fields(struct ib_uverbs_file *file,
+ struct ib_uverbs_query_device_resp *resp,
+ struct ib_device_attr *attr)
+{
+ resp->fw_ver= attr->fw_ver;
+ resp->node_guid = file->device->ib_dev->node_guid;
+ resp->sys_image_guid= attr->sys_image_guid;
+ resp->max_mr_size = attr->max_mr_size;
+ resp->page_size_cap = attr->page_size_cap;
+ resp->vendor_id = attr->vendor_id;
+ resp->vendor_part_id= attr->vendor_part_id;
+ resp->hw_ver= attr->hw_ver;
+ resp->max_qp= attr->max_qp;
+ resp->max_qp_wr = attr->max_qp_wr;
+ resp->device_cap_flags = attr->device_cap_flags;
+ resp->max_sge = attr->max_sge;
+ resp->max_sge_rd= attr->max_sge_rd;
+ resp->max_cq= attr->max_cq;
+ resp->max_cqe = attr->max_cqe;
+ resp->max_mr= attr->max_mr;
+ resp->max_pd= attr->max_pd;
+ resp->max_qp_rd_atom= attr->max_qp_rd_atom;
+ resp->max_ee_rd_atom= attr->max_ee_rd_atom;
+ resp->max_res_rd_atom = attr->max_res_rd_atom;
+ resp->max_qp_init_rd_atom = attr->max_qp_init_rd_atom;
+ resp->max_ee_init_rd_atom = attr->max_ee_init_rd_atom;
+ resp->atomic_cap= attr->atomic_cap;
+ resp->max_ee= attr->max_ee;
+ resp->max_rdd = attr->max_rdd;
+ resp->max_mw= attr->max_mw;
+ resp->max_raw_ipv6_qp = attr->max_raw_ipv6_qp;
+ resp->max_raw_ethy_qp = attr->max_raw_ethy_qp;
+ resp->max_mcast_grp = attr->max_mcast_grp;
+ resp->max_mcast_qp_attach = attr->max_mcast_qp_attach;
+ resp->max_total_mcast_qp_attach = attr->max_total_mcast_qp_attach;
+ resp->max_ah= attr->max_ah;
+ resp->max_fmr = attr->max_fmr;
+ resp->max_map_per_fmr = attr->max_map_per_fmr;
+ resp->max_srq = attr->max_srq;
+ resp->max_srq_wr= attr->max_srq_wr;
+ resp->max_srq_sge = attr->max_srq_sge;
+ resp->max_pkeys = attr->max_pkeys;
+ resp->local_ca_ack_delay= attr->local_ca_ack_delay;
+ resp->phys_port_cnt = file->device->ib_dev->phys_port_cnt;
+}
+
ssize_t ib_uverbs_query_device(struct ib_uverbs_file *file,
const char __user *buf,
int in_len, int out_len)
@@ -398,47 +444,7 @@ ssize_t ib_uverbs_query_device(struct ib_uverbs_file *file,
return ret;
memset(&resp, 0, sizeof resp);
-
- resp.fw_ver= attr.fw_ver;
- resp.node_guid = file->device->ib_dev->node_guid;
- resp.sys_image_guid= attr.sys_image_guid;
- resp.max_mr_size = attr.max_mr_size;
- resp.page_size_cap = attr.page_size_cap;
- resp.vendor_id = attr.vendor_id;
- resp.vendor_part_id= attr.vendor_part_id;
- resp.hw_ver= attr.hw_ver;
- resp.max_qp= attr.max_qp;
- resp.max_qp_wr = attr.max_qp_wr;
- resp.device_cap_flags = attr.device_cap_flags;
- resp.max_sge = attr.max_sge;
- resp.max_sge_rd= attr.max_sge_rd;
- resp.max_cq= attr.max_cq;
- resp.max_cqe = attr.max_cqe;
- resp.max_mr=
[PATCH for-next 3/5] IB/core: Extend atomic operations
Further enhance the extended atomic operations support as was introduced
in commit 5e80ba8ff0bd "IB/core: Add support for masked atomic operations".
1. Allow arbitrary argument sizes. The original extended atomics commit defined
64 bits arguments. This patch allows arbitrary arguments which are power of 2
bytes in size.
2. Add the option to define response for atomic operations in network order.
enum ib_atomic_cap is extended to have big endian variants.
The device attributes struct defines three new fields:
log_atomic_arg_sizes - is a bit mask which encodes which argument sizes are
supported. A set bit at location n (zero based) means an argument of size 2 ^ n
is supported.
max_fa_bit_boundary - Max fetch and add bit boundary. Multi field fetch and add
operations use a bit mask that defines bit locations where carry bit is not
passed to the next higher order bit. So, if this field has the value 64, it
means that the max value subject to fetch and add is 64 bits which means no
carry from bit 63 to 64 or from bit 127 to 128 etc.
log_max_atomic_inline - atomic arguments can be inline in the WQE or be
referenced through a memory key. This value defines the max inline argument
size possible.
Signed-off-by: Eli Cohen
---
drivers/infiniband/core/uverbs_cmd.c | 16 +++-
include/rdma/ib_verbs.h | 7 ++-
include/uapi/rdma/ib_user_verbs.h| 14 ++
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/uverbs_cmd.c
b/drivers/infiniband/core/uverbs_cmd.c
index da3fd8cdd86e..f66686e40ae6 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -445,6 +445,8 @@ ssize_t ib_uverbs_query_device(struct ib_uverbs_file *file,
memset(&resp, 0, sizeof resp);
copy_query_dev_fields(file, &resp, &attr);
+ if (resp.atomic_cap > IB_ATOMIC_GLOB)
+ resp.atomic_cap = IB_ATOMIC_NONE;
if (copy_to_user((void __user *) (unsigned long) cmd.response,
&resp, sizeof resp))
@@ -3281,7 +3283,7 @@ int ib_uverbs_ex_query_device(struct ib_uverbs_file *file,
if (err)
return err;
- if (cmd.comp_mask)
+ if (cmd.comp_mask & ~IB_UVERBS_EX_QUERY_DEV_MAX_MASK)
return -EINVAL;
err = device->query_device(device, &attr);
@@ -3292,6 +3294,18 @@ int ib_uverbs_ex_query_device(struct ib_uverbs_file
*file,
copy_query_dev_fields(file, &resp.base, &attr);
resp.comp_mask = 0;
+ if (cmd.comp_mask & IB_UVERBS_EX_QUERY_DEV_MASKED_ATOMIC) {
+ resp.atomics.masked_atomic_cap = attr.masked_atomic_cap;
+ resp.atomics.log_atomic_arg_sizes = attr.log_atomic_arg_sizes;
+ resp.atomics.max_fa_bit_boundary = attr.max_fa_bit_boundary;
+ resp.atomics.log_max_atomic_inline = attr.log_max_atomic_inline;
+ resp.comp_mask |= IB_UVERBS_EX_QUERY_DEV_MASKED_ATOMIC;
+ } else {
+ resp.atomics.masked_atomic_cap = IB_ATOMIC_NONE;
+ resp.atomics.log_atomic_arg_sizes = 0;
+ resp.atomics.max_fa_bit_boundary = 0;
+ resp.atomics.log_max_atomic_inline = 0;
+ }
err = ib_copy_to_udata(ucore, &resp, sizeof(resp));
if (err)
return err;
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 470a011d6fa4..7f1d20a3f4c7 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -140,7 +140,9 @@ enum ib_signature_guard_cap {
enum ib_atomic_cap {
IB_ATOMIC_NONE,
IB_ATOMIC_HCA,
- IB_ATOMIC_GLOB
+ IB_ATOMIC_GLOB,
+ IB_ATOMIC_HCA_REPLY_BE,
+ IB_ATOMIC_GLOB_REPLY_BE,
};
struct ib_device_attr {
@@ -186,6 +188,9 @@ struct ib_device_attr {
u8 local_ca_ack_delay;
int sig_prot_cap;
int sig_guard_cap;
+ u32 log_atomic_arg_sizes; /* bit-mask of supported
sizes */
+ u32 max_fa_bit_boundary;
+ u32 log_max_atomic_inline;
};
enum ib_mtu {
diff --git a/include/uapi/rdma/ib_user_verbs.h
b/include/uapi/rdma/ib_user_verbs.h
index ed8c3d9da42c..ec98fe636f2b 100644
--- a/include/uapi/rdma/ib_user_verbs.h
+++ b/include/uapi/rdma/ib_user_verbs.h
@@ -202,13 +202,27 @@ struct ib_uverbs_query_device_resp {
__u8 reserved[4];
};
+enum {
+ IB_UVERBS_EX_QUERY_DEV_MASKED_ATOMIC= 1 << 0,
+ IB_UVERBS_EX_QUERY_DEV_LAST = 1 << 1,
+ IB_UVERBS_EX_QUERY_DEV_MAX_MASK = IB_UVERBS_EX_QUERY_DEV_LAST -
1,
+};
+
struct ib_uverbs_ex_query_device {
__u32 comp_mask;
};
+struct ib_uverbs_ex_atomic_caps {
+ __u32 masked_atomic_cap;
+ __u32 log_atomic_arg_sizes; /* bit-mask of supported sizes */
+ __u32 max_fa_bit_boundary;
+ __u32 log_max_atomic_inline;
+};
+
struct ib_uverbs_ex_qu
[PATCH for-next 5/5] IB/mlx4: Modify mlx4 to comply with extended atomic definitions
Set the extended masked atomic capabilities. For ConnectX devices argument size is fixed to 8 bytes and bit boundary is 64. Signed-off-by: Eli Cohen --- drivers/infiniband/hw/mlx4/main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c index bda5994ceb68..6fb7ad51ce0a 100644 --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -223,6 +223,9 @@ static int mlx4_ib_query_device(struct ib_device *ibdev, props->atomic_cap = dev->dev->caps.flags & MLX4_DEV_CAP_FLAG_ATOMIC ? IB_ATOMIC_HCA : IB_ATOMIC_NONE; props->masked_atomic_cap = props->atomic_cap; + props->log_atomic_arg_sizes = 8; + props->max_fa_bit_boundary = 64; + props->log_max_atomic_inline = 8; props->max_pkeys = dev->dev->caps.pkey_table_len[1]; props->max_mcast_grp = dev->dev->caps.num_mgms + dev->dev->caps.num_amgms; props->max_mcast_qp_attach = dev->dev->caps.num_qp_per_mgm; -- 2.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH for-next 4/5] IB/mlx5: Add extended atomic support
Connect-IB extended atomic operations provides masked compare and swap and
multi field fetch and add operations with arguments sizes bigger than 64 bits.
Also, Connect-IB supports BE replies to atomic opertation, add that
to the advertized capabilities.
Add the required functionality to mlx5 and publish capabilities.
Signed-off-by: Eli Cohen
---
drivers/infiniband/hw/mlx5/main.c | 47 +-
drivers/infiniband/hw/mlx5/qp.c| 26 ++--
drivers/net/ethernet/mellanox/mlx5/core/fw.c | 51 +++-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 21 +++---
include/linux/mlx5/device.h| 4 +-
include/linux/mlx5/driver.h| 55 ++
include/linux/mlx5/mlx5_ifc.h | 20 ++
7 files changed, 194 insertions(+), 30 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/main.c
b/drivers/infiniband/hw/mlx5/main.c
index 1ba6c42e4df8..3c6fa99c4256 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -151,6 +151,47 @@ static void free_comp_eqs(struct mlx5_ib_dev *dev)
spin_unlock(&table->lock);
}
+static void update_atomic_caps(struct mlx5_caps*caps,
+ struct ib_device_attr *props)
+{
+ struct mlx5_atomic_caps *atom = &caps->atom;
+ unsigned long last;
+ unsigned long arg;
+ int tmp;
+
+ tmp = MLX5_ATOMIC_OPS_CMP_SWAP | MLX5_ATOMIC_OPS_FETCH_ADD;
+ if (((atom->atomic_ops & tmp) == tmp) && (atom->atomic_sizes_qp & 8)) {
+ if (atom->requestor_endianess)
+ props->atomic_cap = IB_ATOMIC_HCA;
+ else
+ props->atomic_cap = IB_ATOMIC_HCA_REPLY_BE;
+ } else {
+ props->atomic_cap = IB_ATOMIC_NONE;
+ }
+
+ tmp = MLX5_ATOMIC_OPS_MASKED_CMP_SWAP |
MLX5_ATOMIC_OPS_MASKED_FETCH_ADD;
+ if (((atom->atomic_ops & tmp) == tmp)) {
+ if (atom->requestor_endianess)
+ props->masked_atomic_cap = IB_ATOMIC_HCA;
+ else
+ props->masked_atomic_cap = IB_ATOMIC_HCA_REPLY_BE;
+ } else {
+ props->masked_atomic_cap = IB_ATOMIC_NONE;
+ }
+ if ((props->atomic_cap != IB_ATOMIC_NONE) ||
+ (props->masked_atomic_cap != IB_ATOMIC_NONE)) {
+ props->log_atomic_arg_sizes = caps->atom.atomic_sizes_qp;
+ props->max_fa_bit_boundary = 64;
+ arg = (unsigned long)props->log_atomic_arg_sizes;
+ last = find_last_bit(&arg, sizeof(arg));
+ props->log_max_atomic_inline = min_t(unsigned long, last, 6);
+ } else {
+ props->log_atomic_arg_sizes = 0;
+ props->max_fa_bit_boundary = 0;
+ props->log_max_atomic_inline = 0;
+ }
+}
+
static int mlx5_ib_query_device(struct ib_device *ibdev,
struct ib_device_attr *props)
{
@@ -235,8 +276,7 @@ static int mlx5_ib_query_device(struct ib_device *ibdev,
props->max_srq_sge = max_rq_sg - 1;
props->max_fast_reg_page_list_len = (unsigned int)-1;
props->local_ca_ack_delay = gen->local_ca_ack_delay;
- props->atomic_cap = IB_ATOMIC_NONE;
- props->masked_atomic_cap = IB_ATOMIC_NONE;
+ update_atomic_caps(&dev->mdev->caps, props);
props->max_pkeys = be16_to_cpup((__be16 *)(out_mad->data +
28));
props->max_mcast_grp = 1 << gen->log_max_mcg;
props->max_mcast_qp_attach = gen->max_qp_mcg;
@@ -1374,6 +1414,9 @@ static void *mlx5_ib_add(struct mlx5_core_dev *mdev)
(1ull << IB_USER_VERBS_CMD_CLOSE_XRCD);
}
+ dev->ib_dev.uverbs_ex_cmd_mask |=
+ (1ull << IB_USER_VERBS_EX_CMD_QUERY_DEVICE);
+
err = init_node_data(dev);
if (err)
goto err_eqs;
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index 9ca39ad68cb8..47ca93ce214f 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -1254,7 +1254,27 @@ int mlx5_ib_destroy_qp(struct ib_qp *qp)
return 0;
}
-static __be32 to_mlx5_access_flags(struct mlx5_ib_qp *qp, const struct
ib_qp_attr *attr,
+static u32 atomic_mode_qp(struct mlx5_ib_dev *dev)
+{
+ struct mlx5_atomic_caps *acaps = &dev->mdev->caps.atom;
+ unsigned long mask;
+ unsigned long tmp;
+
+ mask = acaps->atomic_sizes_qp & acaps->atomic_sizes_dc;
+
+ tmp = find_last_bit(&mask, 8 * sizeof(mask));
+ if (tmp < 2 || tmp >= 16)
+ return MLX5_ATOMIC_MODE_NONE << 16;
+
+ if (tmp == 2)
+ return MLX5_ATOMIC_MODE_CX << 16;
+
+ return tmp << 16;
+}
+
+static __be32 to_mlx5_access_flags(struct mlx5_ib_dev *dev,
+ struct mlx5_ib_qp *qp,
+
[PATCH for-next 1/5] IB/mlx5: Fix sparse warnings
1. Add required __acquire/__release statements to balance spinlock usage.
2. Change the index parameter of begin_wqe() to be unsigned to match supplied
argument type.
Signed-off-by: Eli Cohen
---
drivers/infiniband/hw/mlx5/qp.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index e261a53f9a02..9ca39ad68cb8 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -1011,9 +1011,14 @@ static void mlx5_ib_lock_cqs(struct mlx5_ib_cq *send_cq,
struct mlx5_ib_cq *recv
}
} else {
spin_lock_irq(&send_cq->lock);
+ __acquire(&recv_cq->lock);
}
} else if (recv_cq) {
spin_lock_irq(&recv_cq->lock);
+ __acquire(&send_cq->lock);
+ } else {
+ __acquire(&send_cq->lock);
+ __acquire(&recv_cq->lock);
}
}
@@ -1033,10 +1038,15 @@ static void mlx5_ib_unlock_cqs(struct mlx5_ib_cq
*send_cq, struct mlx5_ib_cq *re
spin_unlock_irq(&recv_cq->lock);
}
} else {
+ __release(&recv_cq->lock);
spin_unlock_irq(&send_cq->lock);
}
} else if (recv_cq) {
+ __release(&send_cq->lock);
spin_unlock_irq(&recv_cq->lock);
+ } else {
+ __release(&recv_cq->lock);
+ __release(&send_cq->lock);
}
}
@@ -2411,7 +2421,7 @@ static u8 get_fence(u8 fence, struct ib_send_wr *wr)
static int begin_wqe(struct mlx5_ib_qp *qp, void **seg,
struct mlx5_wqe_ctrl_seg **ctrl,
-struct ib_send_wr *wr, int *idx,
+struct ib_send_wr *wr, unsigned *idx,
int *size, int nreq)
{
int err = 0;
@@ -2737,6 +2747,8 @@ out:
if (bf->need_lock)
spin_lock(&bf->lock);
+ else
+ __acquire(&bf->lock);
/* TBD enable WC */
if (0 && nreq == 1 && bf->uuarn && inl && size > 1 && size <=
bf->buf_size / 16) {
@@ -2753,6 +2765,8 @@ out:
bf->offset ^= bf->buf_size;
if (bf->need_lock)
spin_unlock(&bf->lock);
+ else
+ __release(&bf->lock);
}
spin_unlock_irqrestore(&qp->sq.lock, flags);
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH for-next 0/5] Extended atomics enhancements
Hi Roland, the first patch in this series cleans some sparse warnings. The rest of the patches introudce extensions to verbs to add support for extended atomic operations over Connect-IB As your IB tree isn't yet rebased to 3.18-rc1, this series was generated against net-next to account for mlx5 changes which went in rc1 and are assumed by some of the patches. Eli Eli Cohen (5): IB/mlx5: Fix sparse warnings IB/core: Add support for extended query device caps IB/core: Extend atomic operations IB/mlx5: Add extended atomic support IB/mlx4: Modify mlx4 to comply with extended atomic definitions drivers/infiniband/core/uverbs.h | 1 + drivers/infiniband/core/uverbs_cmd.c | 141 ++--- drivers/infiniband/core/uverbs_main.c | 3 +- drivers/infiniband/hw/mlx4/main.c | 3 + drivers/infiniband/hw/mlx5/main.c | 47 - drivers/infiniband/hw/mlx5/qp.c| 42 +++- drivers/net/ethernet/mellanox/mlx5/core/fw.c | 51 - drivers/net/ethernet/mellanox/mlx5/core/main.c | 21 ++-- include/linux/mlx5/device.h| 4 +- include/linux/mlx5/driver.h| 55 -- include/linux/mlx5/mlx5_ifc.h | 20 include/rdma/ib_verbs.h| 7 +- include/uapi/rdma/ib_user_verbs.h | 26 - 13 files changed, 346 insertions(+), 75 deletions(-) -- 2.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
