* [PATCH qedr 01/10] qedr: Add RoCE driver framework
From: Ram Amrani @ 2016-10-05 15:47 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: Ariel.Elior-YGCgFSpz5w/QT0dZR+AlfA,
Michal.Kalderon-YGCgFSpz5w/QT0dZR+AlfA,
Yuval.Mintz-YGCgFSpz5w/QT0dZR+AlfA,
rajesh.borundia-YGCgFSpz5w/QT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Ram Amrani
In-Reply-To: <1475682483-9878-1-git-send-email-Ram.Amrani-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Adds a skeletal implementation of the qed* RoCE driver -
basically the ability to communicate with the qede driver and
receive notifications from it regarding various init/exit events.
Signed-off-by: Rajesh Borundia <rajesh.borundia-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Ram Amrani <Ram.Amrani-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
---
drivers/infiniband/Kconfig | 2 +
drivers/infiniband/hw/Makefile | 1 +
drivers/infiniband/hw/qedr/Kconfig | 7 +
drivers/infiniband/hw/qedr/Makefile | 3 +
drivers/infiniband/hw/qedr/main.c | 254 ++++++++++++++++++++++++++++++++++++
drivers/infiniband/hw/qedr/qedr.h | 61 +++++++++
drivers/net/ethernet/qlogic/Kconfig | 11 --
include/uapi/linux/pci_regs.h | 3 +
8 files changed, 331 insertions(+), 11 deletions(-)
create mode 100644 drivers/infiniband/hw/qedr/Kconfig
create mode 100644 drivers/infiniband/hw/qedr/Makefile
create mode 100644 drivers/infiniband/hw/qedr/main.c
create mode 100644 drivers/infiniband/hw/qedr/qedr.h
diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
index 19a418a..fb3fb89 100644
--- a/drivers/infiniband/Kconfig
+++ b/drivers/infiniband/Kconfig
@@ -89,4 +89,6 @@ source "drivers/infiniband/sw/rxe/Kconfig"
source "drivers/infiniband/hw/hfi1/Kconfig"
+source "drivers/infiniband/hw/qedr/Kconfig"
+
endif # INFINIBAND
diff --git a/drivers/infiniband/hw/Makefile b/drivers/infiniband/hw/Makefile
index 21fe401..e7a5ed9 100644
--- a/drivers/infiniband/hw/Makefile
+++ b/drivers/infiniband/hw/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_INFINIBAND_OCRDMA) += ocrdma/
obj-$(CONFIG_INFINIBAND_USNIC) += usnic/
obj-$(CONFIG_INFINIBAND_HFI1) += hfi1/
obj-$(CONFIG_INFINIBAND_HNS) += hns/
+obj-$(CONFIG_INFINIBAND_QEDR) += qedr/
diff --git a/drivers/infiniband/hw/qedr/Kconfig b/drivers/infiniband/hw/qedr/Kconfig
new file mode 100644
index 0000000..7c06d85
--- /dev/null
+++ b/drivers/infiniband/hw/qedr/Kconfig
@@ -0,0 +1,7 @@
+config INFINIBAND_QEDR
+ tristate "QLogic RoCE driver"
+ depends on 64BIT && QEDE
+ select QED_LL2
+ ---help---
+ This driver provides low-level InfiniBand over Ethernet
+ support for QLogic QED host channel adapters (HCAs).
diff --git a/drivers/infiniband/hw/qedr/Makefile b/drivers/infiniband/hw/qedr/Makefile
new file mode 100644
index 0000000..3a5b7a2
--- /dev/null
+++ b/drivers/infiniband/hw/qedr/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_INFINIBAND_QEDR) := qedr.o
+
+qedr-y := main.o
diff --git a/drivers/infiniband/hw/qedr/main.c b/drivers/infiniband/hw/qedr/main.c
new file mode 100644
index 0000000..7387d02
--- /dev/null
+++ b/drivers/infiniband/hw/qedr/main.c
@@ -0,0 +1,254 @@
+/* QLogic qedr NIC Driver
+ * Copyright (c) 2015-2016 QLogic Corporation
+ *
+ * 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 <linux/module.h>
+#include <rdma/ib_verbs.h>
+#include <rdma/ib_addr.h>
+#include <linux/netdevice.h>
+#include <linux/iommu.h>
+#include <net/addrconf.h>
+#include <linux/qed/qede_roce.h>
+#include "qedr.h"
+
+MODULE_DESCRIPTION("QLogic 40G/100G ROCE Driver");
+MODULE_AUTHOR("QLogic Corporation");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_VERSION(QEDR_MODULE_VERSION);
+
+void qedr_ib_dispatch_event(struct qedr_dev *dev, u8 port_num,
+ enum ib_event_type type)
+{
+ struct ib_event ibev;
+
+ ibev.device = &dev->ibdev;
+ ibev.element.port_num = port_num;
+ ibev.event = type;
+
+ ib_dispatch_event(&ibev);
+}
+
+static enum rdma_link_layer qedr_link_layer(struct ib_device *device,
+ u8 port_num)
+{
+ return IB_LINK_LAYER_ETHERNET;
+}
+
+static int qedr_register_device(struct qedr_dev *dev)
+{
+ strlcpy(dev->ibdev.name, "qedr%d", IB_DEVICE_NAME_MAX);
+
+ memcpy(dev->ibdev.node_desc, QEDR_NODE_DESC, sizeof(QEDR_NODE_DESC));
+ dev->ibdev.owner = THIS_MODULE;
+
+ dev->ibdev.get_link_layer = qedr_link_layer;
+
+ return 0;
+}
+
+/* QEDR sysfs interface */
+static ssize_t show_rev(struct device *device, struct device_attribute *attr,
+ char *buf)
+{
+ struct qedr_dev *dev = dev_get_drvdata(device);
+
+ return scnprintf(buf, PAGE_SIZE, "0x%x\n", dev->pdev->vendor);
+}
+
+static ssize_t show_hca_type(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ return scnprintf(buf, PAGE_SIZE, "%s\n", "HCA_TYPE_TO_SET");
+}
+
+static DEVICE_ATTR(hw_rev, S_IRUGO, show_rev, NULL);
+static DEVICE_ATTR(hca_type, S_IRUGO, show_hca_type, NULL);
+
+static struct device_attribute *qedr_attributes[] = {
+ &dev_attr_hw_rev,
+ &dev_attr_hca_type
+};
+
+static void qedr_remove_sysfiles(struct qedr_dev *dev)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(qedr_attributes); i++)
+ device_remove_file(&dev->ibdev.dev, qedr_attributes[i]);
+}
+
+static void qedr_pci_set_atomic(struct qedr_dev *dev, struct pci_dev *pdev)
+{
+ struct pci_dev *bridge;
+ u32 val;
+
+ dev->atomic_cap = IB_ATOMIC_NONE;
+
+ bridge = pdev->bus->self;
+ if (!bridge)
+ return;
+
+ /* Check whether we are connected directly or via a switch */
+ while (bridge && bridge->bus->parent) {
+ DP_DEBUG(dev, QEDR_MSG_INIT,
+ "Device is not connected directly to root. bridge->bus->number=%d primary=%d\n",
+ bridge->bus->number, bridge->bus->primary);
+ /* Need to check Atomic Op Routing Supported all the way to
+ * root complex.
+ */
+ pcie_capability_read_dword(bridge, PCI_EXP_DEVCAP2, &val);
+ if (!(val & PCI_EXP_DEVCAP2_ATOMIC_ROUTE)) {
+ pcie_capability_clear_word(pdev,
+ PCI_EXP_DEVCTL2,
+ PCI_EXP_DEVCTL2_ATOMIC_REQ);
+ return;
+ }
+ bridge = bridge->bus->parent->self;
+ }
+ bridge = pdev->bus->self;
+
+ /* according to bridge capability */
+ pcie_capability_read_dword(bridge, PCI_EXP_DEVCAP2, &val);
+ if (val & PCI_EXP_DEVCAP2_ATOMIC_COMP64) {
+ pcie_capability_set_word(pdev, PCI_EXP_DEVCTL2,
+ PCI_EXP_DEVCTL2_ATOMIC_REQ);
+ dev->atomic_cap = IB_ATOMIC_GLOB;
+ } else {
+ pcie_capability_clear_word(pdev, PCI_EXP_DEVCTL2,
+ PCI_EXP_DEVCTL2_ATOMIC_REQ);
+ }
+}
+
+static struct qedr_dev *qedr_add(struct qed_dev *cdev, struct pci_dev *pdev,
+ struct net_device *ndev)
+{
+ struct qedr_dev *dev;
+ int rc = 0, i;
+
+ dev = (struct qedr_dev *)ib_alloc_device(sizeof(*dev));
+ if (!dev) {
+ pr_err("Unable to allocate ib device\n");
+ return NULL;
+ }
+
+ DP_DEBUG(dev, QEDR_MSG_INIT, "qedr add device called\n");
+
+ dev->pdev = pdev;
+ dev->ndev = ndev;
+ dev->cdev = cdev;
+
+ qedr_pci_set_atomic(dev, pdev);
+
+ rc = qedr_register_device(dev);
+ if (rc) {
+ DP_ERR(dev, "Unable to allocate register device\n");
+ goto init_err;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(qedr_attributes); i++)
+ if (device_create_file(&dev->ibdev.dev, qedr_attributes[i]))
+ goto init_err;
+
+ DP_DEBUG(dev, QEDR_MSG_INIT, "qedr driver loaded successfully\n");
+ return dev;
+
+init_err:
+ ib_dealloc_device(&dev->ibdev);
+ DP_ERR(dev, "qedr driver load failed rc=%d\n", rc);
+
+ return NULL;
+}
+
+static void qedr_remove(struct qedr_dev *dev)
+{
+ /* First unregister with stack to stop all the active traffic
+ * of the registered clients.
+ */
+ qedr_remove_sysfiles(dev);
+
+ ib_dealloc_device(&dev->ibdev);
+}
+
+static int qedr_close(struct qedr_dev *dev)
+{
+ qedr_ib_dispatch_event(dev, 1, IB_EVENT_PORT_ERR);
+
+ return 0;
+}
+
+static void qedr_shutdown(struct qedr_dev *dev)
+{
+ qedr_close(dev);
+ qedr_remove(dev);
+}
+
+/* event handling via NIC driver ensures that all the NIC specific
+ * initialization done before RoCE driver notifies
+ * event to stack.
+ */
+static void qedr_notify(struct qedr_dev *dev, enum qede_roce_event event)
+{
+ switch (event) {
+ case QEDE_UP:
+ qedr_ib_dispatch_event(dev, 1, IB_EVENT_PORT_ACTIVE);
+ break;
+ case QEDE_DOWN:
+ qedr_close(dev);
+ break;
+ case QEDE_CLOSE:
+ qedr_shutdown(dev);
+ break;
+ case QEDE_CHANGE_ADDR:
+ qedr_ib_dispatch_event(dev, 1, IB_EVENT_GID_CHANGE);
+ break;
+ default:
+ pr_err("Event not supported\n");
+ }
+}
+
+static struct qedr_driver qedr_drv = {
+ .name = "qedr_driver",
+ .add = qedr_add,
+ .remove = qedr_remove,
+ .notify = qedr_notify,
+};
+
+static int __init qedr_init_module(void)
+{
+ return qede_roce_register_driver(&qedr_drv);
+}
+
+static void __exit qedr_exit_module(void)
+{
+ qede_roce_unregister_driver(&qedr_drv);
+}
+
+module_init(qedr_init_module);
+module_exit(qedr_exit_module);
diff --git a/drivers/infiniband/hw/qedr/qedr.h b/drivers/infiniband/hw/qedr/qedr.h
new file mode 100644
index 0000000..8014170
--- /dev/null
+++ b/drivers/infiniband/hw/qedr/qedr.h
@@ -0,0 +1,61 @@
+/* QLogic qedr NIC Driver
+ * Copyright (c) 2015-2016 QLogic Corporation
+ *
+ * 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.
+ */
+#ifndef __QEDR_H__
+#define __QEDR_H__
+
+#include <linux/pci.h>
+#include <rdma/ib_addr.h>
+#include <linux/qed/qed_if.h>
+#include <linux/qed/qede_roce.h>
+
+#define QEDR_MODULE_VERSION "8.10.10.0"
+#define QEDR_NODE_DESC "QLogic 579xx RoCE HCA"
+#define DP_NAME(dev) ((dev)->ibdev.name)
+
+#define DP_DEBUG(dev, module, fmt, ...) \
+ pr_debug("(%s) " module ": " fmt, \
+ DP_NAME(dev) ? DP_NAME(dev) : "", ## __VA_ARGS__)
+
+#define QEDR_MSG_INIT "INIT"
+
+struct qedr_dev {
+ struct ib_device ibdev;
+ struct qed_dev *cdev;
+ struct pci_dev *pdev;
+ struct net_device *ndev;
+
+ enum ib_atomic_cap atomic_cap;
+
+ u32 dp_module;
+ u8 dp_level;
+};
+#endif
diff --git a/drivers/net/ethernet/qlogic/Kconfig b/drivers/net/ethernet/qlogic/Kconfig
index 0df1391f9..1e8339a 100644
--- a/drivers/net/ethernet/qlogic/Kconfig
+++ b/drivers/net/ethernet/qlogic/Kconfig
@@ -107,15 +107,4 @@ config QEDE
---help---
This enables the support for ...
-config INFINIBAND_QEDR
- tristate "QLogic qede RoCE sources [debug]"
- depends on QEDE && 64BIT
- select QED_LL2
- default n
- ---help---
- This provides a temporary node that allows the compilation
- and logical testing of the InfiniBand over Ethernet support
- for QLogic QED. This would be replaced by the 'real' option
- once the QEDR driver is added [+relocated].
-
endif # NET_VENDOR_QLOGIC
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index 4040951..30d66b5 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -612,6 +612,8 @@
*/
#define PCI_EXP_DEVCAP2 36 /* Device Capabilities 2 */
#define PCI_EXP_DEVCAP2_ARI 0x00000020 /* Alternative Routing-ID */
+#define PCI_EXP_DEVCAP2_ATOMIC_ROUTE 0x00000040 /* Atomic Op routing */
+#define PCI_EXP_DEVCAP2_ATOMIC_COMP64 0x00000100 /* Atomic 64-bit compare */
#define PCI_EXP_DEVCAP2_LTR 0x00000800 /* Latency tolerance reporting */
#define PCI_EXP_DEVCAP2_OBFF_MASK 0x000c0000 /* OBFF support mechanism */
#define PCI_EXP_DEVCAP2_OBFF_MSG 0x00040000 /* New message signaling */
@@ -619,6 +621,7 @@
#define PCI_EXP_DEVCTL2 40 /* Device Control 2 */
#define PCI_EXP_DEVCTL2_COMP_TIMEOUT 0x000f /* Completion Timeout Value */
#define PCI_EXP_DEVCTL2_ARI 0x0020 /* Alternative Routing-ID */
+#define PCI_EXP_DEVCTL2_ATOMIC_REQ 0x0040 /* Set Atomic requests */
#define PCI_EXP_DEVCTL2_IDO_REQ_EN 0x0100 /* Allow IDO for requests */
#define PCI_EXP_DEVCTL2_IDO_CMP_EN 0x0200 /* Allow IDO for completions */
#define PCI_EXP_DEVCTL2_LTR_EN 0x0400 /* Enable LTR mechanism */
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH qedr 00/10] QLogic RDMA Driver (qedr)
From: Ram Amrani @ 2016-10-05 15:47 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: Ariel.Elior-YGCgFSpz5w/QT0dZR+AlfA,
Michal.Kalderon-YGCgFSpz5w/QT0dZR+AlfA,
Yuval.Mintz-YGCgFSpz5w/QT0dZR+AlfA,
rajesh.borundia-YGCgFSpz5w/QT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Ram Amrani
This series introduces RoCE RDMA driver for the 579xx RDMA products by
Qlogic. The RDMA support is added as an additional loadable module (qedr)
over the Ethernet qede driver.
The qedr module will support both RoCE and iWarp, although this series
only adds RoCE support.
This series was preceded by RFC v3[1].The major difference between the two
is that the required qed and qede driver changes for RDMA support were
already submitted and accepted on net-next by Dave for 4.9, see [2]. Also,
the qedr menu configuration was moved from net/ethernet to infiniband.
The series was built and tested against branch k.o/for-4.9, based on:
7958b377d0c961881471c224da9f3a3 (after importing qed/qede patches, and
more, from net-dev).
Thanks for everyone which pointed out problems in the driver.
Reference:
- [1] http://www.spinics.net/lists/linux-rdma/msg41087.html
- [2] https://www.spinics.net/lists/netdev/msg398562.html
Rajesh Borundia (10):
qedr: Add RoCE driver framework
qedr: Add support for RoCE HW init
qedr: Add support for user context verbs
qedr: Add support for PD,PKEY and CQ verbs
qedr: Add support for QP verbs
qedr: Add support for memory registeration verbs
qedr: Add support for data path
qedr: Add LL2 RoCE interface
qedr: Add GSI support
qedr: Add events support and register IB device
drivers/infiniband/Kconfig | 2 +
drivers/infiniband/hw/Makefile | 1 +
drivers/infiniband/hw/qedr/Kconfig | 7 +
drivers/infiniband/hw/qedr/Makefile | 3 +
drivers/infiniband/hw/qedr/main.c | 911 +++++++
drivers/infiniband/hw/qedr/qedr.h | 495 ++++
drivers/infiniband/hw/qedr/qedr_cm.c | 636 +++++
drivers/infiniband/hw/qedr/qedr_cm.h | 61 +
drivers/infiniband/hw/qedr/qedr_hsi.h | 56 +
drivers/infiniband/hw/qedr/qedr_hsi_rdma.h | 748 ++++++
drivers/infiniband/hw/qedr/verbs.c | 3552 ++++++++++++++++++++++++++++
drivers/infiniband/hw/qedr/verbs.h | 101 +
drivers/net/ethernet/qlogic/Kconfig | 11 -
include/uapi/linux/pci_regs.h | 3 +
include/uapi/rdma/qedr-abi.h | 106 +
15 files changed, 6682 insertions(+), 11 deletions(-)
create mode 100644 drivers/infiniband/hw/qedr/Kconfig
create mode 100644 drivers/infiniband/hw/qedr/Makefile
create mode 100644 drivers/infiniband/hw/qedr/main.c
create mode 100644 drivers/infiniband/hw/qedr/qedr.h
create mode 100644 drivers/infiniband/hw/qedr/qedr_cm.c
create mode 100644 drivers/infiniband/hw/qedr/qedr_cm.h
create mode 100644 drivers/infiniband/hw/qedr/qedr_hsi.h
create mode 100644 drivers/infiniband/hw/qedr/qedr_hsi_rdma.h
create mode 100644 drivers/infiniband/hw/qedr/verbs.c
create mode 100644 drivers/infiniband/hw/qedr/verbs.h
create mode 100644 include/uapi/rdma/qedr-abi.h
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 8/9] Remove most checks of __BYTE_ORDER
From: Christoph Hellwig @ 2016-10-05 15:37 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Tatyana Nikolova', 'Hal Rosenstock',
'Doug Ledford', 'Yishai Hadas',
'Devesh Sharma', 'Sean Hefty',
'Bart Van Assche'
In-Reply-To: <20160929222802.GC27229-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Thu, Sep 29, 2016 at 04:28:02PM -0600, Jason Gunthorpe wrote:
> In the kernel the swapping behavior of 'writel' is architecture (and
> sometimes even platform) specific. Looking at the kernel headers
> suggests that BE PPC needs an explicit swap and BE ARM does not (eg
> the hardware swaps). Maybe. There are a lot of layers of macros in
> this area..
read{s,l,q} and write{s,l,q} in the kernel always perform an implicit
bytestap, that is the device is expected to use a LE layout. This
is not architecture specific, otherwise hell would break lose.
If the device has a BE layout you'll need to use ioread*be/iowrite*be
instead.
But none of this has an affect on userspace mappings of registers, as
those don't go through the kernel read{s,l,q} and write{s,l,q} helpers,
so if you mmap the resource directly your need to manually byte swap
to whatever the hardware expects - which seems to be LE for Chelsio
and BE for Mellanox.
Btw, one thing that would be useful is to introduce endiane annoatations
for sparse in rdma-core. I've added these to a few userspace projects
already, here is the most recent example:
https://github.com/linux-nvme/nvme-cli/commit/126b8beb35b76fe9f61b137e34aea66b64c07b25
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller
From: Tejun Heo @ 2016-10-05 15:36 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Christoph Hellwig, Parav Pandit, Jason Gunthorpe, Matan Barak,
cgroups, linux-doc, Linux Kernel Mailing List, linux-rdma,
Li Zefan, Johannes Weiner, Doug Ledford, Liran Liss, Hefty, Sean,
Haggai Eran, Jonathan Corbet, james.l.morris, serge, Or Gerlitz,
Andrew Morton, linux-security-module
In-Reply-To: <20161005112257.GD9282@leon.nu>
Hello,
On Wed, Oct 05, 2016 at 02:22:57PM +0300, Leon Romanovsky wrote:
> On Wed, Oct 05, 2016 at 08:37:35AM +0200, Christoph Hellwig wrote:
> > FYI, the patches look fine to me:
> >
> > Acked-by: Christoph Hellwig <hch@lst.de>
> >
> > but we're past the merge window for 4.9 now unfortunately.
>
> IMHO, it still can make it.
Most likely, we only have three / four days till rc1 opens, I think
it's too late. Let's target the next one.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update Intel RDMA RNIC driver maintainers
From: Faisal Latif @ 2016-10-05 15:35 UTC (permalink / raw)
To: Henry Orosco
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
e1000-rdma-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
In-Reply-To: <20161005143054.4844-1-henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Wed, Oct 05, 2016 at 07:30:54AM -0700, Henry Orosco wrote:
Signed-off-by: Henry Orosco <henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cc77b9a..32f535e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6188,6 +6188,7 @@ R: Chien Tin Tung <chien.tin.tung-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> R: Mustafa Ismail <mustafa.ismail-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> R: Shiraz Saleem <shiraz.saleem-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> R: Tatyana Nikolova <tatyana.e.nikolova-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> +R: Henry Orosco <henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> L: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> S: Supported
> F: drivers/infiniband/hw/i40iw/
> --
> 2.8.3
Acked-by: Faisal Latif <faisal.latif-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 8/9] Remove most checks of __BYTE_ORDER
From: Yishai Hadas @ 2016-10-05 15:16 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Steve Wise, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Tatyana Nikolova, Hal Rosenstock, Doug Ledford, Devesh Sharma,
Sean Hefty, Bart Van Assche,
yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org
In-Reply-To: <20160930000800.GA7570-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On 9/30/2016 3:08 AM, Jason Gunthorpe wrote:
> On Thu, Sep 29, 2016 at 06:46:02PM -0500, Steve Wise wrote:
>>> I added the comment because cxgb* was the only provider that seemed to
>>> be obviously byte swapping MMIO.
>>>
>>> Since htole32 is a NOP on x86 and ARM64 the driver would work fine
>>> with or without it. Do you know this driver works on big endian
>>> powerpc? That would help answer the question for sure.
>>
>> Yes, PowerPC and arm.
>
> Okay great. Maybe Yishai can explain what mlx drivers are doing..
MLX drivers use BE format for QPN as part of writing a door bell in both
X86 and PPC BE as their NICs expect to get, code is certified to work
fine on both.
Specifically,
Upon QP creation the code uses htonl for setting qp->doorbell_qpn (see
mlx4_create_qp_ex), later on this value is used without any change upon
writing a door bell. (see mmio_writel). No PCI swap is expected.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()
From: Bart Van Assche @ 2016-10-05 14:46 UTC (permalink / raw)
To: Ming Lei
Cc: Jens Axboe, Christoph Hellwig, James Bottomley,
Martin K. Petersen, Mike Snitzer, Doug Ledford, Keith Busch,
linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-rdma@vger.kernel.org, linux-nvme@lists.infradead.org
In-Reply-To: <CACVXFVO21wDRrZtB0A5qn5KEn-rjnewQxYyN_aAWoQrKSMvmig@mail.gmail.com>
On 10/04/16 21:32, Ming Lei wrote:
> On Wed, Oct 5, 2016 at 12:16 PM, Bart Van Assche
> <bart.vanassche@sandisk.com> wrote:
>> On 10/01/16 15:56, Ming Lei wrote:
>>>
>>> If we just call the rcu/srcu read lock(or the mutex) around .queue_rq(),
>>> the above code needn't to be duplicated any more.
>>
>> Can you have a look at the attached patch? That patch uses an srcu read lock
>> for all queue types, whether or not the BLK_MQ_F_BLOCKING flag has been set.
>
> That is much cleaner now.
>
>> Additionally, I have dropped the QUEUE_FLAG_QUIESCING flag. Just like
>> previous versions, this patch has been tested.
>
> I think the flag of QUEUE_FLAG_QUIESCING is still needed because we
> have to set this flag to prevent new coming .queue_rq() from being run,
> and synchronize_srcu() won't wait for completion of that at all (see
> section of 'Update-Side Primitives' in [1]).
>
> [1] https://lwn.net/Articles/202847/
Hello Ming,
How about using the existing flag BLK_MQ_S_STOPPED instead of
introducing a new QUEUE_FLAG_QUIESCING flag? From the comment above
blk_mq_quiesce_queue() in the patch that was attached to my previous
e-mail: "Additionally, it is not prevented that new queue_rq() calls
occur unless the queue has been stopped first."
Thanks,
Bart.
^ permalink raw reply
* [PATCH] MAINTAINERS: Update Intel RDMA RNIC driver maintainers
From: Henry Orosco @ 2016-10-05 14:30 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
e1000-rdma-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
henry.orosco-ral2JQCrhuEAvxtiuMwx3w
Signed-off-by: Henry Orosco <henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cc77b9a..32f535e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6188,6 +6188,7 @@ R: Chien Tin Tung <chien.tin.tung-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
R: Mustafa Ismail <mustafa.ismail-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
R: Shiraz Saleem <shiraz.saleem-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
R: Tatyana Nikolova <tatyana.e.nikolova-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+R: Henry Orosco <henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
L: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
S: Supported
F: drivers/infiniband/hw/i40iw/
--
2.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Christoph Hellwig @ 2016-10-05 14:08 UTC (permalink / raw)
To: Atchley, Scott
Cc: Christoph Hellwig, Christoph Lameter, Linux RDMA Mailing List,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Doug Ledford,
Coulter, Susan K, shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <96C6AF13-B968-41C2-9AB3-CAB5F91D72A1-1Heg1YXhbW8@public.gmane.org>
On Wed, Oct 05, 2016 at 01:49:56PM +0000, Atchley, Scott wrote:
> Not marketing BS. Simple facts on the background of the issues. Do not mischaracterize my remarks.
It is. And so is most of this mail. If we can't have a useful
technical conversation this is pointless.
What remains from all this backtracking is that your as a board member
(but speaking just for yourself) are perfectly fine with bullying
cotributors to the Linux kernel for no good reason.
Just another reason to ignore OFA as much as possible and make sure we
can get the Linux RDMA stack up to standards, similar to how Microsoft
managed to have a state of the art stack way better than Linux at the
moment but taking things into their own hands and ignoring OFA.
Let OFA continue die a slow death by infighting of it's two main members
and the lack of a clear vision, while we'll make sure RDMA in Linux is
top notch.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Atchley, Scott @ 2016-10-05 13:49 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Christoph Lameter, Linux RDMA Mailing List,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Doug Ledford,
Coulter, Susan K, shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <20161005131811.GA24546-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> On Oct 5, 2016, at 9:18 AM, Christoph Hellwig <hch@infradead.org> wrote:
>
> [snipped the marketing BS and getting straight to the point..]
Not marketing BS. Simple facts on the background of the issues. Do not mischaracterize my remarks.
>> 5. The only one in this thread trying to force a license of others is not the OFA.
>
> That is not the case. OFA has been constantly pushing through various
> channels to force Dual licensing of RDMA related code contribute to the
> Linux kernel.
>
> Can you please confirm on behalf of the OFA board that OFA will stop
> bullying Linux kernel contributors or otherwise try to influence
> licensing of code contributed to the Linux kernel that has not been
> developed by the OFA.
>
> Once we have that sorted out I think we're all in violent agreement.
As I in my email, I do not speak for OFA or my organization. I am speaking for myself.
The issue is code was added in between the vendors’ Verbs drivers (now called providers?) and the upper layer protocols (ULPs) that is GPL only. The code standardizes common code paths that each ULP previously implemented. Hopefully the code is more stable and a fix there fixes it everywhere. This code allows the ULPs to focus on their protocol-specific behavior. Technically, this is a good thing.
The issue, I believe, from the OFA’s perspective is that code that they mostly developed and contributed (drivers and ULPs) which is dual-licensed to allow it to be used in non-Linux OSes has been reduced and something critical inserted in between that cannot be used in non-Linux OSes (*BSD or Windows). Thus, there is heartburn.
The OFA cannot change the fact that this code has been accepted in the kernel. The OFA asked that it be dual-licensed and the answer was no. The OFA cannot do anything about that.
AS for bullying Linux kernel contributors, many contributors are vendor employees and, as everywhere, the employer dictates the license for the code produced at company expense. For contributors that are not employees of OFA members, the OFA has no influence or impact, thus no means to bully.
I believe the goal of OFA’s request for dual-licensing of the new code was legitimate from their perspective. I also believe the decision of the developer is his own and no one can force him to change.
I am trying to understand the issue from both points of view. Again, I ask you to help me understand how requesting dual-licensing hurts the adoption of RDMA technology. I can understand the vendor’s concerns about having to write software twice for GPL and non-GPL environments.
Again, I am a user that wants standards that allow innovation and competition. Help me understand.
P.S. I will be neither at the LPC or the RDMA Summit.
P.P.S. Remember, I am only speaking for myself and not the OFA or my employer.
^ permalink raw reply
* Re: [PATCH v6 00/16] Add Paravirtual RDMA Driver
From: Leon Romanovsky @ 2016-10-05 13:44 UTC (permalink / raw)
To: Adit Ranadive
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
pv-drivers-pghWNbHTmq7QT0dZR+AlfA, jhansen-pghWNbHTmq7QT0dZR+AlfA,
asarwade-pghWNbHTmq7QT0dZR+AlfA,
georgezhang-pghWNbHTmq7QT0dZR+AlfA,
bryantan-pghWNbHTmq7QT0dZR+AlfA
In-Reply-To: <cover.1475458407.git.aditr-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 12351 bytes --]
On Sun, Oct 02, 2016 at 07:10:20PM -0700, Adit Ranadive wrote:
> Hi Doug, others,
>
> This patch series adds a driver for a paravirtual RDMA device. The device
> is developed for VMware's Virtual Machines and allows existing RDMA
> applications to continue to use existing Verbs API when deployed in VMs on
> ESXi. We recently did a presentation in the OFA Workshop [1] regarding this
> device.
>
> Description and RDMA Support
> ============================
> The virtual device is exposed as a dual function PCIe device. One part is
> a virtual network device (VMXNet3) which provides networking properties
> like MAC, IP addresses to the RDMA part of the device. The networking
> properties are used to register GIDs required by RDMA applications to
> communicate.
>
> These patches add support and the all required infrastructure for letting
> applications use such a device. We support the mandatory Verbs API as well
> as the base memory management extensions (Local Inv, Send with Inv and Fast
> Register Work Requests). We currently support both Reliable Connected and
> Unreliable Datagram QPs but do not support Shared Receive Queues (SRQs).
> Also, we support the following types of Work Requests:
> o Send/Receive (with or without Immediate Data)
> o RDMA Write (with or without Immediate Data)
> o RDMA Read
> o Local Invalidate
> o Send with Invalidate
> o Fast Register Work Requests
>
> This version only adds support for version 1 of RoCE. We will add RoCEv2
> support in a future patch. We do support registration of both MAC-based and
> IP-based GIDs. I have also created a git tree for our user-level driver [2].
>
> Testing
> =======
> We have tested this internally for various types of Guest OS - Red Hat,
> Centos, Ubuntu 12.04/14.04/16.04, Oracle Enterprise Linux, SLES 12
> using backported versions of this driver. The tests included several runs
> of the performance tests (included with OFED), Intel MPI PingPong benchmark
> on OpenMPI, krping for FRWRs. Mellanox has been kind enough to test the
> backported version of the driver internally on their hardware using a
> VMware provided ESX build. I have also applied and tested this with Doug's
> k.o/for-4.9 branch (commit 5603910b). Note, that this patch series should be
> applied all together. I split out the commits so that it may be easier to
> review.
>
> PVRDMA Resources
> ================
> [1] OFA Workshop Presentation -
> https://openfabrics.org/images/eventpresos/2016presentations/102parardma.pdf
> [2] Libpvrdma User-level library -
> http://git.openfabrics.org/?p=~aditr/libpvrdma.git;a=summary
> ---
> Changes v5->v6:
> - PATCH [02/16]
> - Removed the pvrdma-uapi.h file and moved common structures into
> pvrdma-abi.h.
> - Moved enums and structs common to user-level and kernel driver into
> pvrdma-abi.h.
> - Changed _exp_ to _ex_ for extended structures.
> - PATCH [03/16]
> - These functions were originally in pvrdma_uapi.h which is now removed.
> - pvrdma_uapi.h -> pvrdma_ring.h.
> - PATCH [04/16]
> - Removed the pvrdma_defs.h file. The contents of that are placed in the
> pvrdma_dev_api header file.
> - Removed include of pvrdma_ib_verbs.h.
> - PATCH [05/16]
> - Structs/enums defined in pvrdma_ib_verbs.h (removed) are now in
> pvrdma_verbs.h.
> - PATCH [06/16]
> - Update the header includes for abi and ring headers.
> - PATCH [08/16]
> - Ensure we return an error code if read from error register fails.
> - PATCH [09, 12/16]
> - Removed duplicate include of abi header.
> - PATCH [13/16]
> - Removed a duplicate include of ABI header.
> - Removed the driver release date and a const string.
> - Updated some functions to return -EFAULT instead of -EINVAL.
> - PATCH [16/16]
> - Removed maintainer info for pvrdma-abi.h.
>
> Changes v4->v5:
> - PATCH [02/16]
> - Moved pvrdma_uapi.h and pvrdma_user.h into common UAPI folder.
> - Renamed to pvrdma-uapi.h and pvrdma-abi.h respectively.
> - Prefixed unsigned vars with __.
> - PATCH [03/16]
> - Removed __ prefix for unsigned vars.
> - PATCH [04/16]
> - Update include for headers moved to UAPI.
> - Removed __ prefix for unsigned vars.
> - PATCH [05/16]
> - Update include for headers in UAPI folder.
> - Removed setting any properties that are reported by device as 0.
> - Simplified modify_port.
> - PD should be allocated first in kernel then in device.
> - Update to pvrdma_cmd_post for creating/destroying PD, Query port/device.
> - PATCH [06/16]
> - pvrdma_cmd_post takes the response code.
> - PATCH [07/16]
> - Correct var type passed to dma_alloc_coherent.
> - PATCH [08/16]
> - Moved the timeout to pvrdma_cmd_recv.
> - Added additional response code parameter to pvrdma_cmd_post.
> - PATCH [09/16]
> - Updated include for headers in UAPI folder.
> - Changed from EINVAL to ENOMEM if atomic add fails.
> - Added error code if destroy cq command failed.
> - Update to pvrdma_cmd_post for creating/destroying CQ.
> - PATCH [11/16]
> - Check the access flags correctly for DMA MR.
> - Update to pvrdma_cmd_post for creating/destroying MRs.
> - PATCH [12/16]
> - Updated include for headers in UAPI folder.
> - Update to pvrdma_cmd_post for creating/destroying/querying/modifying QPs.
> - Use the pvrdma_sge struct when posting WRs/allocating QP memory.
> - Removed two set but unused variables.
> - PATCH [13/16]
> - Removed two unnecessary lines.
> - Updated include for headers in UAPI folder.
> - Update to pvrdma_cmd_post for add/delete GIDs.
> - Add error code in dev_warn if pvrdma_cmd_post failed.
> - PATCH [16/16]
> - Added pvrdma files to common UAPI folder.
>
> Changes v3->v4:
> - Rebased on for-4.9 branch - commit 64278fe89b729
> ("Merge branch 'hns-roce' into k.o/for-4.9")
> - PATCH [01/16]
> - New in v4 - Moved vmxnet3 id to pci_ids.h
> - PATCH [02,03/16]
> - pvrdma_sge was moved into pvrdma_uapi.h
> - PATCH [04/16]
> - Removed explicit enum values.
> - PATCH [05/16]
> - Renamed priviledged -> privileged.
> - Added error numbers for command errors.
> - Removed unnecessary goto in modify_device.
> - Moved pd allocation to after command execution.
> - Removed an incorrect atomic_dec.
> - PATCH [06/16]
> - Renamed priviledged -> privileged.
> - Renamed pvrdma_flush_cqe to _pvrdma_flush_cqe since we hold a lock
> to call it.
> - Added wrapper functions for writing to UARs for CQ/QP.
> - The conversion functions are updated as func_name(dst, src) format.
> - Renamed max_gs to max_sg.
> - Added work struct for net device events.
> - PATCH [07/16]
> - Updated conversion functions to func_name(dst, src) format.
> - Removed unneeded local variables.
> - PATCH [08/16]
> - Removed the min check and added a BUILD_BUG_ON check for size.
> - PATCH [09/16]
> - Added a pvrdma_destroy_cq in the error path.
> - Renamed pvrdma_flush_cqe to _pvrdma_flush_cqe since we need a lock to
> be held while calling this.
> - Updated to use wrapper for UAR write for CQ.
> - Ensure that poll_cq does not return error values.
> - PATCH [10/16]
> - Removed an unnecessary comment.
> - PATCH [11/16]
> - Changed access flag check for DMA MR to using bit operation.
> - Removed some local variables.
> - PATCH [12/16]
> - Removed an unnecessary switch case.
> - Unified the returns in pvrdma_create_qp to use one exit point.
> - Renamed pvrdma_flush_cqe to _pvrdma_flush_cqe since we need a lock to
> be held when calling this.
> - Updated to use wrapper for UAR write for QP.
> - Updated conversion function to func_name(dst, src) format.
> - Renamed max_gs to max_sg.
> - Renamed cap variable to req_cap in pvrdma_set_sq/rq_size.
> - Changed dev_warn to dev_warn_ratelimited in pvrdma_post_send/recv.
> - Added nesting locking for flushing CQs when destroying/resetting a QP.
> - Added missing ret value.
> - PATCH [13/16]
> - Fixed some checkpatch warnings.
> - Added support for new get_dev_fw_str API.
> - Added event workqueue for netdevice events.
> - Restructured the pvrdma_pci_remove function a little bit.
> - PATCH [14/16]
> - Enforced dependency on VMXNet3 module.
>
> Changes v2->v3:
> - I reordered the patches so that the definitions of enums, structures is
> before their use (suggested by Yuval Shaia) so its easier to review.
> - Removed an unneccesary bool in pvrdma_cmd_post (suggested by Yuval Shaia).
> - Made the use of comma at end of enums consistent across files (suggested
> by Leon Romanovsky).
>
> Changes v1->v2:
> - Patch [07/15] - Addressed Yuval Shaia's comments and 32-bit build errors.
>
> ---
> Adit Ranadive (16):
> vmxnet3: Move PCI Id to pci_ids.h
> IB/pvrdma: Add user-level shared functions
> IB/pvrdma: Add functions for ring traversal
> IB/pvrdma: Add the paravirtual RDMA device specification
> IB/pvrdma: Add functions for Verbs support
> IB/pvrdma: Add paravirtual rdma device
> IB/pvrdma: Add helper functions
> IB/pvrdma: Add device command support
> IB/pvrdma: Add support for Completion Queues
> IB/pvrdma: Add UAR support
> IB/pvrdma: Add support for memory regions
> IB/pvrdma: Add Queue Pair support
> IB/pvrdma: Add the main driver module for PVRDMA
> IB/pvrdma: Add Kconfig and Makefile
> IB: Add PVRDMA driver
> MAINTAINERS: Update for PVRDMA driver
>
> MAINTAINERS | 7 +
> drivers/infiniband/Kconfig | 1 +
> drivers/infiniband/hw/Makefile | 1 +
> drivers/infiniband/hw/pvrdma/Kconfig | 7 +
> drivers/infiniband/hw/pvrdma/Makefile | 3 +
> drivers/infiniband/hw/pvrdma/pvrdma.h | 474 ++++++++++
> drivers/infiniband/hw/pvrdma/pvrdma_cmd.c | 119 +++
> drivers/infiniband/hw/pvrdma/pvrdma_cq.c | 425 +++++++++
> drivers/infiniband/hw/pvrdma/pvrdma_dev_api.h | 586 ++++++++++++
> drivers/infiniband/hw/pvrdma/pvrdma_doorbell.c | 127 +++
> drivers/infiniband/hw/pvrdma/pvrdma_main.c | 1211 ++++++++++++++++++++++++
> drivers/infiniband/hw/pvrdma/pvrdma_misc.c | 304 ++++++
> drivers/infiniband/hw/pvrdma/pvrdma_mr.c | 334 +++++++
> drivers/infiniband/hw/pvrdma/pvrdma_qp.c | 972 +++++++++++++++++++
> drivers/infiniband/hw/pvrdma/pvrdma_ring.h | 131 +++
> drivers/infiniband/hw/pvrdma/pvrdma_verbs.c | 577 +++++++++++
> drivers/infiniband/hw/pvrdma/pvrdma_verbs.h | 435 +++++++++
> drivers/net/vmxnet3/vmxnet3_int.h | 3 +-
> include/linux/pci_ids.h | 1 +
> include/uapi/rdma/Kbuild | 2 +
> include/uapi/rdma/pvrdma-abi.h | 289 ++++++
> 21 files changed, 6007 insertions(+), 2 deletions(-)
> create mode 100644 drivers/infiniband/hw/pvrdma/Kconfig
> create mode 100644 drivers/infiniband/hw/pvrdma/Makefile
> create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma.h
> create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_cmd.c
> create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_cq.c
> create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_dev_api.h
> create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_doorbell.c
> create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_main.c
> create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_misc.c
> create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_mr.c
> create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_qp.c
> create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_ring.h
> create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_verbs.c
> create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_verbs.h
> create mode 100644 include/uapi/rdma/pvrdma-abi.h
Except patch 02, looks good to me.
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Thanks
>
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v6 02/16] IB/pvrdma: Add user-level shared functions
From: Leon Romanovsky @ 2016-10-05 13:42 UTC (permalink / raw)
To: Adit Ranadive
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
pv-drivers-pghWNbHTmq7QT0dZR+AlfA, jhansen-pghWNbHTmq7QT0dZR+AlfA,
asarwade-pghWNbHTmq7QT0dZR+AlfA,
georgezhang-pghWNbHTmq7QT0dZR+AlfA,
bryantan-pghWNbHTmq7QT0dZR+AlfA
In-Reply-To: <515c704574423b16feb4c3d97847156623a8d042.1475458407.git.aditr-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]
On Sun, Oct 02, 2016 at 07:10:22PM -0700, Adit Ranadive wrote:
> We share some common structures with the user-level driver. This patch adds
> those structures and shared functions to traverse the QP/CQ rings.
>
> Reviewed-by: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Jorgen Hansen <jhansen-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> Reviewed-by: George Zhang <georgezhang-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Aditya Sarwade <asarwade-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Bryan Tan <bryantan-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Adit Ranadive <aditr-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> ---
> Changes v5->v6:
> - Removed the pvrdma-uapi.h file and moved common structures into
> pvrdma-abi.h.
> - Moved enums and structs common to user-level and kernel driver into
> pvrdma-abi.h.
> - Changed _exp_ to _ex_ for extended structures.
>
> Changes v4->v5:
> - Moved pvrdma_uapi.h and pvrdma_user.h into common UAPI folder.
> - Renamed to pvrdma-uapi.h and pvrdma-abi.h respectively.
> - Prefixed unsigned vars with __.
>
> Changes v3->v4:
> - Moved pvrdma_sge into pvrdma_uapi.h
> ---
> include/uapi/rdma/Kbuild | 2 +
> include/uapi/rdma/pvrdma-abi.h | 289 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 291 insertions(+)
> create mode 100644 include/uapi/rdma/pvrdma-abi.h
>
> diff --git a/include/uapi/rdma/Kbuild b/include/uapi/rdma/Kbuild
> index ac62908..04357ba 100644
> --- a/include/uapi/rdma/Kbuild
> +++ b/include/uapi/rdma/Kbuild
> @@ -8,3 +8,5 @@ header-y += rdma_netlink.h
> header-y += rdma_user_cm.h
> header-y += hfi/
> header-y += rdma_user_rxe.h
> +header-y += pvrdma-abi.h
> +header-y += pvrdma-uapi.h
You forgot to drop this line.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Christoph Hellwig @ 2016-10-05 13:18 UTC (permalink / raw)
To: Atchley, Scott
Cc: Christoph Hellwig, Christoph Lameter, Linux RDMA Mailing List,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Doug Ledford,
Coulter, Susan K, shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <BED3F60E-08E7-4C29-8A52-E7F879BE46A4-1Heg1YXhbW8@public.gmane.org>
[snipped the marketing BS and getting straight to the point..]
> 5. The only one in this thread trying to force a license of others is not the OFA.
That is not the case. OFA has been constantly pushing through various
channels to force Dual licensing of RDMA related code contribute to the
Linux kernel.
Can you please confirm on behalf of the OFA board that OFA will stop
bullying Linux kernel contributors or otherwise try to influence
licensing of code contributed to the Linux kernel that has not been
developed by the OFA.
Once we have that sorted out I think we're all in violent agreement.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Atchley, Scott @ 2016-10-05 13:02 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Christoph Lameter, Linux RDMA Mailing List,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Doug Ledford,
Coulter, Susan K, shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <20161005083218.GA16922-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> On Oct 5, 2016, at 4:32 AM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>
> Could someone elaborate what the OFA position is? Right now the only
> thing I know is that they are a) forcing their members to Dual license
> code nd have b) some sort of weird idea that they could also force this
> on others in some way.
Although I am sitting on the OFA board as the representative of my organization, I do not speak for the OFA. These are my observations:
1. The OFA is an organization to promote the standardization of alternative network technologies. Prior to the OFA, vendors created specialized hardware with specialized software stacks tailored to HPC. Examples include QSnet/Quadrics, GM/Myrinet MX/Myrinet, Cray Portals/SeaStar, Cray GNI/Gemini/Aries, IBM BG[LPQ], etc. The OFA evolved from the InfiniBand/Verbs trade group in order to promote additional technologies (e.g. iWarp, RoCE, PSM, etc).
2. The OFA organization, made up of various members, has rules to govern itself. Most members are also competitors. They cooperate on standards because everyone benefits by avoiding the fragmentation of the prior state of affairs (see item 1). Because they are competitors, changes are difficult and/or slow because people have to build consensus. Other members are consumers, for example the organization I represent, and we want standards and competition. The former allows us to get better products from the latter.
3. The members that contribute the most to the OFA in terms of money, staff time, and code are the vendors. They wrote much of the code that was contributed and they chose dual license, as is their right. I assume (because I do not know) that they did so to avoid writing two (or three) stacks for Linux and non-Linux environments.
4. OFA has a rule that code developed on its behalf be dual-license. They do not _force_ this on members because members decided this or they joined knowing that this was the rule. OFA cannot force anyone to join so therefore they cannot force anyone to adopt a dual-license. As mentioned in item 2, OFA members can modify their rules via an established process. If you want to change the rule, join OFA and convince the members.
5. The only one in this thread trying to force a license of others is not the OFA.
> I personally think that a) is not helpful to the adoption of RDMA
> technologies in Linux, and that b) is obviously a complete non-started
> as confirmed multiple times, which isn't just my own opinion.
If one is not a member, the OFA cannot force anything. I do not see dual-license as a hindrance to Linux kernel use or adoption. Perhaps you can help me understand better.
> Based on that I really don't understand what the point of this
> discussion is, unless OFA really needs help with an internal discussion
> to get rid of a). If Christoph really wants me to help with a) please
> do it during Plumbers as I won't be around on Saturday.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] i40iw: Remove macros I40IW_STAG_KEY_FROM_STAG and I40IW_STAG_INDEX_FROM_STAG
From: Leon Romanovsky @ 2016-10-05 12:57 UTC (permalink / raw)
To: Thomas Huth
Cc: Faisal Latif, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Chien Tin Tung,
Mustafa Ismail, Shiraz Saleem, Tatyana Nikolova, Doug Ledford,
Sean Hefty, Hal Rosenstock
In-Reply-To: <1475668538-12914-1-git-send-email-thuth-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
On Wed, Oct 05, 2016 at 01:55:38PM +0200, Thomas Huth wrote:
> The macros I40IW_STAG_KEY_FROM_STAG and I40IW_STAG_INDEX_FROM_STAG are
> apparently bad - they are using the logical "&&" operation which
> does not make sense here. It should have been a bitwise "&" instead.
> Since the macros seem to be completely unused, let's simply remove
> them so that nobody accidentially uses them in the future. And while
> we're at it, also remove the unused macro I40IW_CREATE_STAG.
>
> Signed-off-by: Thomas Huth <thuth-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Thanks,
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-core] Improve global COPYING files
From: Leon Romanovsky @ 2016-10-05 12:49 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Doug Ledford
In-Reply-To: <20160923173421.GB13920-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]
On Fri, Sep 23, 2016 at 11:34:21AM -0600, Jason Gunthorpe wrote:
> On Fri, Sep 23, 2016 at 08:10:03PM +0300, Leon Romanovsky wrote:
>
> > I sure that this question will sound dumb for you, but can we unify all
> > code under OFA's licenses (dual-license)? I don't feel comfortable with
> > this multi-license situation.
>
> It is an excellent question.
>
> To do this we would need the OFA to talk to each of the member
> companies and get them to sign some kind of legal change of copyright
> document. Assuming all of the member companies agree, and all the
> member companies are the exhaustive copyright owners then the code can
> be placed under a single uniform license.
>
> As I understand it all OFA members were required to agree to use a
> specific licensing scheme, including specific license text when they
> signed the OFA membership agreement. What we are seeing here is that
> the corporate legal side agreed to something but the developers made
> small errors along the way, and those errors were later copied by
> other developers and spread widely. So the OFA has a basis for
> requests of this nature.
>
> For instance, a legal statement from Mellanox that all code they
> contributed is available under the GPLv2 or *either* MIT or FreeBSD
> license varient would allow immediately placing all Mellanox
> copyrighted code under the single Default License. I expect this is
> what Mellanox intended to do anyhow, the fact that ibverbs and all
> their providers had an error in the COPYING file is simply
> an unfortunate mistake.
>
> These sorts of license issues are typical in historical code bases. I
> would say we are in pretty good shape, from what I can tell absolutely
> everything is unambiguously licensed under at least the GPLv2, or a
> compatible license.
>
> Almost everything is alternatively licensed under some kind of BSD
> license. The notable exception is ipathverbs and rxe. It is also
> unfortunate we have so many BSD variants.
>
> Further, almost all C code is licensed under the dual GPLv2/OpenIB.org
> (MIT) license. The kernel is similar, almost all C code is using the
> MIT variant. Hence my desire to make that the license for new code in
> the tree.
>
> I would say this is a pretty good result.
>
> My ultimate suggestion is that we push the non-default copyright into
> the impacted files, eg add short licenses headers to the man pages,
> etc, and then delete the extraneous COPYING files once every single
> file has a correct license statement. From that point we can look at
> switching individual files based on the above Legal process to the
> Default License, or just leave them as is - a historical quirk.
It looks like a lot of work to do and it can be handled by anyone.
Can OPA handle this?
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] i40iw: Remove macros I40IW_STAG_KEY_FROM_STAG and I40IW_STAG_INDEX_FROM_STAG
From: Thomas Huth @ 2016-10-05 11:55 UTC (permalink / raw)
To: Faisal Latif, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Chien Tin Tung, Mustafa Ismail, Shiraz Saleem, Tatyana Nikolova,
Doug Ledford, Sean Hefty, Hal Rosenstock
The macros I40IW_STAG_KEY_FROM_STAG and I40IW_STAG_INDEX_FROM_STAG are
apparently bad - they are using the logical "&&" operation which
does not make sense here. It should have been a bitwise "&" instead.
Since the macros seem to be completely unused, let's simply remove
them so that nobody accidentially uses them in the future. And while
we're at it, also remove the unused macro I40IW_CREATE_STAG.
Signed-off-by: Thomas Huth <thuth-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
drivers/infiniband/hw/i40iw/i40iw_user.h | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_user.h b/drivers/infiniband/hw/i40iw/i40iw_user.h
index 276bcef..0d91667 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_user.h
+++ b/drivers/infiniband/hw/i40iw/i40iw_user.h
@@ -96,12 +96,6 @@ enum i40iw_device_capabilities_const {
#define i40iw_physical_fragment u64
#define i40iw_address_list u64 *
-#define I40IW_CREATE_STAG(index, key) (((index) << 8) + (key))
-
-#define I40IW_STAG_KEY_FROM_STAG(stag) ((stag) && 0x000000FF)
-
-#define I40IW_STAG_INDEX_FROM_STAG(stag) (((stag) && 0xFFFFFF00) >> 8)
-
#define I40IW_MAX_MR_SIZE 0x10000000000L
struct i40iw_qp_uk;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH rdma-core] Add a .travis.yml file
From: Leon Romanovsky @ 2016-10-05 11:51 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Doug Ledford
In-Reply-To: <1475105337-18002-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
On Wed, Sep 28, 2016 at 05:28:57PM -0600, Jason Gunthorpe wrote:
> Necessary to use the Travis CI service.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> ---
> .travis.yml | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100644 .travis.yml
>
> Now that travis is enabled on repo, we need a yml file to make it run.
>
> Here is a basic one.
>
> I don't test with distros as old as precise and I don't expect that glibc to
> be new enough to build this (eg missing timerfd, O_CLOEXEC, etc), and the
> cmake certainly isn't. So we use the trusty 'beta' environment and install
> gcc 6.2.
I'm using 16.04 and it has gcc 5.4.0 as a default. Don't you think that
6.2 is too "new" for us and other distributions?
➜ linux-rdma git:(master) gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller
From: Leon Romanovsky @ 2016-10-05 11:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Parav Pandit, Tejun Heo, Jason Gunthorpe, Matan Barak, cgroups,
linux-doc, Linux Kernel Mailing List, linux-rdma, Li Zefan,
Johannes Weiner, Doug Ledford, Liran Liss, Hefty, Sean,
Haggai Eran, Jonathan Corbet, james.l.morris, serge, Or Gerlitz,
Andrew Morton, linux-security-module
In-Reply-To: <20161005063735.GC3086@lst.de>
[-- Attachment #1: Type: text/plain, Size: 248 bytes --]
On Wed, Oct 05, 2016 at 08:37:35AM +0200, Christoph Hellwig wrote:
> FYI, the patches look fine to me:
>
> Acked-by: Christoph Hellwig <hch@lst.de>
>
> but we're past the merge window for 4.9 now unfortunately.
IMHO, it still can make it.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv12 0/3] rdmacg: IB/core: rdma controller support
From: Leon Romanovsky @ 2016-10-05 11:22 UTC (permalink / raw)
To: Parav Pandit
Cc: cgroups, linux-doc, linux-kernel, linux-rdma, tj, lizefan, hannes,
dledford, hch, liranl, sean.hefty, jgunthorpe, haggaie, corbet,
james.l.morris, serge, ogerlitz, matanb, akpm,
linux-security-module
In-Reply-To: <1472632647-1525-1-git-send-email-pandit.parav@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
On Wed, Aug 31, 2016 at 02:07:24PM +0530, Parav Pandit wrote:
> rdmacg: IB/core: rdma controller support
>
> Patch is generated and tested against below Doug's linux-rdma
> git tree.
>
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
> Branch: master
>
> Patchset is also compiled and tested against below Tejun's cgroup tree
> using cgroup v2 mode.
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
> Branch: master
>
> Overview:
> Currently user space applications can easily take away all the rdma
> device specific resources such as AH, CQ, QP, MR etc. Due to which other
> applications in other cgroup or kernel space ULPs may not even get chance
> to allocate any rdma resources. This results into service unavailibility.
>
> RDMA cgroup addresses this issue by allowing resource accounting,
> limit enforcement on per cgroup, per rdma device basis.
>
> RDMA uverbs layer will enforce limits on well defined RDMA verb
> resources without any HCA vendor device driver involvement.
>
> RDMA uverbs layer will not do limit enforcement of HCA hw vendor
> specific resources. Instead rdma cgroup provides set of APIs
> through which vendor specific drivers can do resource accounting
> by making use of rdma cgroup.
Hi Parav,
I want to propose an extension to the RDMA cgroup which can be done as
follow-up patches.
Let's add new global type, which will control whole HCA (for example in percentages). It will
allow natively define new objects without need to introduce them to the user.
This HCA share will be overwritten by specific UVERBS types which you
already defined.
What do you think?
Except this proposal,
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Thanks.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH rdma-core] MAINTAINERS: Add backup/co-maintainer for ibacm
From: Hal Rosenstock @ 2016-10-05 11:17 UTC (permalink / raw)
To: Doug Ledford, Leon Romanovsky
Cc: Hefty, Sean, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Hal Rosenstock <hal-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 9048311..d1a29a8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -64,6 +64,7 @@ F: libi40iw/
RDMA Communication Manager Assistant (for librdmacm.so)
M: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+M: Hal Rosenstock <hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
S: Supported
F: ibacm/*
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH rdma-core] Remove unused HIDDEN gcc attribute
From: Leon Romanovsky @ 2016-10-05 11:08 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
The attribute HIDDEN was declared is almost every provider, but it wasn't
used, except in libibverbs. Let's remove it.
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
libhfi1verbs/src/hfiverbs.h | 2 --
libi40iw/src/i40iw_umain.h | 2 --
libipathverbs/src/ipathverbs.h | 2 --
libmlx4/src/mlx4.h | 2 --
libmlx5/src/mlx5.h | 2 --
libmthca/src/mthca.h | 2 --
libnes/src/nes_umain.h | 2 --
7 files changed, 14 deletions(-)
diff --git a/libhfi1verbs/src/hfiverbs.h b/libhfi1verbs/src/hfiverbs.h
index deebc65..e82ba2b 100644
--- a/libhfi1verbs/src/hfiverbs.h
+++ b/libhfi1verbs/src/hfiverbs.h
@@ -67,8 +67,6 @@
#include <infiniband/arch.h>
#include <infiniband/verbs.h>
-#define HIDDEN __attribute__((visibility ("hidden")))
-
#define PFX "hfi1: "
struct hfi1_device {
diff --git a/libi40iw/src/i40iw_umain.h b/libi40iw/src/i40iw_umain.h
index 13d3da8..719aefc 100644
--- a/libi40iw/src/i40iw_umain.h
+++ b/libi40iw/src/i40iw_umain.h
@@ -54,8 +54,6 @@
#define unlikely(x) __builtin_expect((x), 0)
#endif
-#define HIDDEN __attribute__((visibility("hidden")))
-
#define PFX "libi40iw-"
#define I40IW_BASE_PUSH_PAGE 1
diff --git a/libipathverbs/src/ipathverbs.h b/libipathverbs/src/ipathverbs.h
index 05e1c71..ff25854 100644
--- a/libipathverbs/src/ipathverbs.h
+++ b/libipathverbs/src/ipathverbs.h
@@ -47,8 +47,6 @@
#include <infiniband/arch.h>
#include <infiniband/verbs.h>
-#define HIDDEN __attribute__((visibility ("hidden")))
-
#define PFX "ipath: "
struct ipath_device {
diff --git a/libmlx4/src/mlx4.h b/libmlx4/src/mlx4.h
index 1855cfb..95a6521 100644
--- a/libmlx4/src/mlx4.h
+++ b/libmlx4/src/mlx4.h
@@ -49,8 +49,6 @@
#include <valgrind/memcheck.h>
-#define HIDDEN __attribute__((visibility ("hidden")))
-
#define PFX "mlx4: "
enum {
diff --git a/libmlx5/src/mlx5.h b/libmlx5/src/mlx5.h
index c209a79..f8674c7 100644
--- a/libmlx5/src/mlx5.h
+++ b/libmlx5/src/mlx5.h
@@ -54,8 +54,6 @@
#include <valgrind/memcheck.h>
-#define HIDDEN __attribute__((visibility("hidden")))
-
#ifdef HAVE_FUNC_ATTRIBUTE_ALWAYS_INLINE
#define ALWAYS_INLINE __attribute__((always_inline))
#else
diff --git a/libmthca/src/mthca.h b/libmthca/src/mthca.h
index da53010..b4b0b6a 100644
--- a/libmthca/src/mthca.h
+++ b/libmthca/src/mthca.h
@@ -41,8 +41,6 @@
#include <valgrind/memcheck.h>
-#define HIDDEN __attribute__((visibility ("hidden")))
-
#define PFX "mthca: "
enum mthca_hca_type {
diff --git a/libnes/src/nes_umain.h b/libnes/src/nes_umain.h
index 9129982..f3cc348 100644
--- a/libnes/src/nes_umain.h
+++ b/libnes/src/nes_umain.h
@@ -48,8 +48,6 @@
#define unlikely(x) __builtin_expect((x),0)
#endif
-#define HIDDEN __attribute__((visibility ("hidden")))
-
#define PFX "libnes: "
#define NES_QP_MMAP 1
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH rdma-core] Add travis CI status to master branch
From: Leon Romanovsky @ 2016-10-05 8:37 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
README.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/README.md b/README.md
index 51b2faf..98ec5a7 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,5 @@
+[](https://travis-ci.org/linux-rdma/rdma-core)
+
# RDMA Core Userspace Libraries and Daemons
This is the userspace components for the Linux Kernel's drivers/infiniband
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Christoph Hellwig @ 2016-10-05 8:32 UTC (permalink / raw)
To: Christoph Lameter
Cc: Atchley, Scott, Christoph Hellwig, Linux RDMA Mailing List,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Doug Ledford,
Coulter, Susan K, shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <alpine.DEB.2.20.1610050242260.27600-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
Could someone elaborate what the OFA position is? Right now the only
thing I know is that they are a) forcing their members to Dual license
code nd have b) some sort of weird idea that they could also force this
on others in some way.
I personally think that a) is not helpful to the adoption of RDMA
technologies in Linux, and that b) is obviously a complete non-started
as confirmed multiple times, which isn't just my own opinion.
Based on that I really don't understand what the point of this
discussion is, unless OFA really needs help with an internal discussion
to get rid of a). If Christoph really wants me to help with a) please
do it during Plumbers as I won't be around on Saturday.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Christoph Lameter @ 2016-10-05 7:45 UTC (permalink / raw)
To: Atchley, Scott
Cc: Christoph Hellwig, Linux RDMA Mailing List,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Doug Ledford,
Coulter, Susan K, shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <7BAAE610-98A0-47FC-993B-77401AA32F4A-1Heg1YXhbW8@public.gmane.org>
The point of the session will be to allow communication about the
different viewpoints on the subject matter of Dual Licensing. Maybe we can
come to some agreements that will allow us to move forward in a better way
with this. More communication may also help to clear up a couple of issues
and complaints. I certainly wish that Christoph Hellwig would be there to
talk about his views and also Susan Coulter as representing the OFA point
of view.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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