RE: [PATCH] fix return value error

> > Subject: [PATCH] fix return value error > > > > I checked returns in configfs (-ENOMEM), proc (-ENOENT), proc-sys (- > ENOMEM), ramfs (-ENOSPC), vfs (-ENOMEM). > > Not entirely consistent but this matches the majority. > > I agree -EPERM is pretty misleading. > > Acked-by: Mike Marciniszyn

Re: [PATCH] fix return value error

On Wed, Oct 14, 2015 at 5:17 PM, Marciniszyn, Mike wrote: >> > Subject: [PATCH] fix return value error >> > >> >> I checked returns in configfs (-ENOMEM), proc (-ENOENT), proc-sys (- >> ENOMEM), ramfs (-ENOSPC), vfs (-ENOMEM). >> >> Not entirely consistent but this

Re: [PATCH v1 for-next 0/7] Add support for multicast loopback prevention to mlx4

On Wed, 26 Aug 2015, eran ben elisha wrote: > > Do you have this in a git tree somewhere for testing? > > Yes, > please pull from https://github.com/eranbenelisha/linux branch > rebased-for-4.3/lb_prev > > If you with to get the user space as well for testing, please use: >

Re: [PATCH v2 00/16] NFS/RDMA patches for merging into v4.4

> On Oct 14, 2015, at 9:32 AM, Devesh Sharma > wrote: > > Hi Chuck, > > With the server crash fix in place, ocrdma is passing iozone on this series. > > Series Tested-By: Devesh Sharma Thanks to you and Sagi. A v3 is coming soon,

Re: [Ksummit-discuss] [TECH TOPIC] IRQ affinity

On Mon, Oct 12, 2015 at 11:41:45AM -0700, Christoph Hellwig wrote: > > Hi Ted, > > while we have a high level agreement there's still some discussion > needed. I can prepare a few slides for 10 minute discussion and then > take it to the hallways with the interested people. Thanks, The Tech

Re: Create a common verbs transport library

On Tue, Oct 13, 2015 at 08:32:25AM +0300, Moni Shoua wrote: We initially thought to implement a shared library that contains the transport logic. However, it seems that a SW Verbs transport driver would allow better code sharing. In fact, the VT driver would need only a single user-space

Re: [PATCH 0/6] IB/mad: Support devices taking pkey_index from the GSI QP

On Wed, Oct 14, 2015 at 11:29:42AM +0300, Haggai Eran wrote: > respect the pkey_index in ib_send_wr.ud for GSI packets. Apparently having > the pkey_index in a work request isn't required by the IBA > specifications, I disagree. The spec is very clear, 13.5.3.2.1 perscribes how GMP replies must

[PATCH] fix return value error

Signed-off-by: Heloise NH --- drivers/infiniband/hw/ipath/ipath_fs.c | 2 +- drivers/infiniband/hw/qib/qib_fs.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/ipath/ipath_fs.c b/drivers/infiniband/hw/ipath/ipath_fs.c index

[PATCH 0/6] IB/mad: Support devices taking pkey_index from the GSI QP

Hi, Patch 4c21b5bcef73 ("IB/cma: Add net_dev and private data checks to RDMA CM") started checking the BTH P_Key for RDMA CM requests, and this uncovered some issues with P_Key handling. In mlx5 the pkey_index in ib_wc wasn't set correctly [1]. In addition, we found out that mlx5 doesn't respect

[PATCH 2/6] IB/mad: Add QP parameters to ib_mad_qp_info

In preparation for having an array of QPs in each ib_mad_qp_info, add the qp_type and qp_num parameters to the ib_mad_qp_info struct so that clients won't need to access the QPs themselves for this information. Signed-off-by: Haggai Eran --- drivers/infiniband/core/mad.c

[PATCH 3/6] IB/core: Add capability bit to tell whether per-WR P_Key change in GSI is supported

The IB specs do not require per work-request control over the P_Key used in GMPs. Most drivers have implemented this feature, but some drivers such as ipath and mlx5 do not support it. Add a capability bit, and turn it on in drivers that lack support for per-WR P_Key. Cc: Mike Marciniszyn

Re: [PATCH rdma-RC] IB/cm: Fix sleeping while atomic when creating AH from WC

On Tue, Oct 13, 2015 at 7:18 PM, Hefty, Sean wrote: >> On Mon, Oct 12, 2015 at 7:42 PM, Hefty, Sean wrote: >> >> When IP based addressing was introduced, ib_create_ah_from_wc was >> >> changed in order to support a suitable AH. Since this AH should >>

[PATCH 5/6] IB/mad: Create multiple QPs for supporting different P_Keys

On devices that do not support sending different P_Keys on a single GSI QP, create a different UD QP for each non-zero P_Key in the P_Key table. When transmitting a MAD with a specified P_Key, send it using the right QP. Receive packets from all the QPs through the common SRQ. Signed-off-by:

[PATCH 1/6] IB/mad: Use helpers to get ib_device and ib_pd from ib_mad_agent

ib_mad_agent currently exposes an ib_qp and an ib_device unnecessarily. Replace these fields with a single ib_pd, and use helper functions to get the device and pd instead of accessing the fields directly. Signed-off-by: Haggai Eran --- drivers/infiniband/core/agent.c

[PATCH 6/6] IB/mad: P_Key change event handler

Add a device event handler to capture P_Key table change events. For devices that don't support setting the P_Key index per work request, update the per-P_Key QP table in the MAD layer, creating QPs as needed. The code currently doesn't destroy created QPs when their pkeys are cleared. This can

[PATCH 4/6] IB/mad: Use a SRQ for receiving GMPs

As a preparation for supporting multiple transmission QPs for each GSI QP, add a SRQ that will be used for all the receive buffers of these QPs. Signed-off-by: Haggai Eran --- drivers/infiniband/core/mad.c | 58 ++

[PULL REQUEST] Please pull rdma.git

Hi Linus, We have four batched up patches for the current rc kernel. Two of them are small fixes that are obvious. One of them is larger than I would like for a late stage rc pull, but we found an issue in the namespace lookup code related to RoCE and this works around the issue for now (we

Re: [PATCH] fix return value error

On 10/14/2015 2:59 PM, Leon Romanovsky wrote: On Wed, Oct 14, 2015 at 11:17 AM, Heloise NH wrote: >Signed-off-by: Heloise NH The patch is a correct one, however can you update the subject and description to be more informative? Please add that new_inode()

Re: 4.4's rdma plate

On 10/14/2015 3:56 PM, Doug Ledford wrote: Yes Or, I'm working on it. A new 4.3-rc pull request should come out today and an update on the for next area probably as well. Excellent. Re the next area, as was communicated to you multiple times, we really need the next bits to be in your

RE: [PATCH] fix return value error

> Subject: [PATCH] fix return value error > I checked returns in configfs (-ENOMEM), proc (-ENOENT), proc-sys (-ENOMEM), ramfs (-ENOSPC), vfs (-ENOMEM). Not entirely consistent but this matches the majority. I agree -EPERM is pretty misleading. Acked-by: Mike Marciniszyn