Re: [PATCH 07/37] IB/rdmavt: Add query and modify port stubs

On Mon, Dec 07, 2015 at 03:43:28PM -0500, Dennis Dalessandro wrote: > +/** > + * rvt_query_port: Passes the query port call to the driver > + * ibdev: Verbs IB dev > + * port: port number > + * props: structure to hold returned properties > + * > + * Returns 0 on success > + */ ... > +/** > + *

Re: [PATCH 20/37] IB/rdamvt: Add post send and recv stubs

Fix typo in the subject: IB/rdam --> IB/rdma -- 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] Staging: rdma:Delete unnecessary NULL check before calling function "kmem_cache_destroy"

From: Yash Shah The kmem_cache_destroy() function tests whether its argument is NULL and then returns immediately. Thus the NULL check before calling this function is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Yash Shah

RE: warning in ext4 with nfs/rdma server

> -Original Message- > From: Chuck Lever [mailto:chuck.le...@oracle.com] > Sent: Monday, December 07, 2015 9:45 AM > To: Steve Wise > Cc: linux-rdma@vger.kernel.org; Veeresh U. Kokatnur; Linux NFS Mailing List > Subject: Re: warning in ext4 with nfs/rdma server > > Hi Steve- > > > On

Re: [PATCH 03/10] IB/qib: Use rdmavt protection domain

On Mon, Dec 7, 2015 at 10:49 PM, Dennis Dalessandro wrote: > Remove protection domain datastructure from qib and use rdmavts version. > I failed to apply this patch tried with rc3 and rc4 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the

[RFC contig pages support 0/2] Add contiguous pages support

This RFC introduces an ability to user space application to work with contiguous pages and boost its performance by reducing HCA translation's cycles. IB core introduces a new structure named 'cmem' which represents a contiguous memory and expose some APIs to work with it. IB driver can use

[RFC contig pages support 2/2] IB/mlx5: Exporting to user space the contiguous allocation capability

Extend mlx5_ib_mmap to recognize 'allocate contiguous' command. Offset field will be encoded to hold both command and its data. Last 8 bits will hold the command, this will enable future extension for further commands. Signed-off-by: Yishai Hadas ---

Re: [RFC contig pages support 1/2] IB: Supports contiguous memory operations

There is absolutely nothing IB specific here. If you want to support anonymous mmaps to allocate large contiguous pages work with the MM folks on providing that in a generic fashion. [full quote alert for reference:] On Tue, Dec 08, 2015 at 05:15:06PM +0200, Yishai Hadas wrote: > New structure

[RFC contig pages support 1/2] IB: Supports contiguous memory operations

New structure 'cmem' represents the contiguous allocated memory. It supports: Allocate, Free, 'Map to virtual address' operations, etc. Signed-off-by: Yishai Hadas --- drivers/infiniband/core/Makefile | 2 +- drivers/infiniband/core/cmem.c | 245

[RFC libibverbs 1/2] Add contiguous pages support

To enable contiguous the application should supply NULL address as part of ibv_reg_mr and turn on a bit in the access flags asking for. In that mode the provider allocates contiguous pages and it also manages the un/do_fork_range calls. An extra extended verb between the library and the provider

[RFC libibverbs 2/2] Example code to use contig pages

Example usage of contig pages. Signed-off-by: Yishai Hadas --- examples/rc_pingpong.c | 47 --- 1 file changed, 36 insertions(+), 11 deletions(-) diff --git a/examples/rc_pingpong.c b/examples/rc_pingpong.c index

[RFC libibverbs 0/2] Use MR with contiguous pages

This RFC introduces an ability to user space application to work with contiguous pages when ibv_reg_mr is used. This ability achieved by asking the provider as part of ibv_reg_mr to allocate from the kernel such a memory in a transparent way to the application. The idea is to pass NULL as part

[RFC libmlx5 PATCH] Add contiguous pages support

Add support for contiguous pages allocation when it asked for. Signed-off-by: Yishai Hadas --- src/mlx5.c | 1 + src/mlx5.h | 6 - src/verbs.c | 88 - 3 files changed, 93 insertions(+), 2 deletions(-)

[PATCH for-next 0/2] Advertise atomic operations support in mlx5

Hi Doug, This patch set adds the functionality to advertise standard atomic operations capabilities for mlx5 driver. The Hardware can be configured to work in two modes according to the device capabilities: 1. Big Endian requestor respond 2. Host Endian requestor respond If the firmware

Re: [PATCH v2 0/2] Handle mlx4 max_sge_rd correctly

On Thu, Dec 03, 2015 at 05:07:35PM +0200, Sagi Grimberg wrote: > > >Did we ever make progress on this? > > Just up to Doug to pull it in. Doug, any chance to get this into the 4.4 queue? It's annoying having to work around this driver bug in every new ULP. -- To unsubscribe from this list:

[PATCH for-next 2/2] IB/mlx5: Advertise atomic capabilities in query device

In addition, check if qp support atomic operations when asking QP access flags with IB_ACCESS_REMOTE_ATOMIC in modify QP. Signed-off-by: Eran Ben Elisha Reviewed-by: Yishai Hadas --- drivers/infiniband/hw/mlx5/main.c| 40

[PATCH for-next 1/2] net/mlx5_core: Configure HW to support atomic request in host endianness

HW is capable of 2 requestor endianness modes for standard 8 Bytes atomic: BE (0x0) and host endianness (0x1). Read the supported modes from hca atomic capabilities and configure HW to host endianness mode if supported. Signed-off-by: Eran Ben Elisha Reviewed-by: Yishai

Re: [PATCH for-next 1/2] net/mlx5_core: Configure HW to support atomic request in host endianness

On Tue, Dec 8, 2015 at 7:17 PM, Jason Gunthorpe wrote: > On Tue, Dec 08, 2015 at 06:54:15PM +0200, Eran Ben Elisha wrote: >> HW is capable of 2 requestor endianness modes for standard 8 Bytes >> atomic: BE (0x0) and host endianness (0x1). Read the supported modes

Re: [PATCH v2 0/2] Handle mlx4 max_sge_rd correctly

On 12/08/2015 01:17 PM, Doug Ledford wrote: > On 12/08/2015 01:13 PM, Sagi Grimberg wrote: >> >>> I've pulled these in. Both of them failed to apply, and the first one >>> was just flat baffling in terms of how Sagi is working from a source >>> base so different than the one in the upstream

Re: [PATCH v2 0/2] Handle mlx4 max_sge_rd correctly

On 12/08/2015 12:01 PM, Christoph Hellwig wrote: > On Thu, Dec 03, 2015 at 05:07:35PM +0200, Sagi Grimberg wrote: >> >>> Did we ever make progress on this? >> >> Just up to Doug to pull it in. > > Doug, any chance to get this into the 4.4 queue? It's annoying > having to work around this driver

Re: [PATCH for-next 1/2] net/mlx5_core: Configure HW to support atomic request in host endianness

On Tue, Dec 08, 2015 at 08:08:02PM +0200, eran ben elisha wrote: > On Tue, Dec 8, 2015 at 7:17 PM, Jason Gunthorpe > wrote: > > On Tue, Dec 08, 2015 at 06:54:15PM +0200, Eran Ben Elisha wrote: > >> HW is capable of 2 requestor endianness modes for standard 8 Bytes

Re: [PATCH v2 0/2] Handle mlx4 max_sge_rd correctly

I've pulled these in. Both of them failed to apply, and the first one was just flat baffling in terms of how Sagi is working from a source base so different than the one in the upstream kernel. They should be double checked just to make sure I'm not missing something since they were so far

Re: [RFC contig pages support 1/2] IB: Supports contiguous memory operations

On Tue, Dec 08, 2015 at 07:18:52AM -0800, Christoph Hellwig wrote: > There is absolutely nothing IB specific here. If you want to support > anonymous mmaps to allocate large contiguous pages work with the MM > folks on providing that in a generic fashion. Yes please. We already have huge page

[PATCH 1/1] Ibacm: default pkey for partitioned fabrics

From: Kaike Wan In an insecure IB fabric, the default pkey in a port is 0x, where each node is allowed to talk to any other node in the fabric, including the SA node. However, in a secure fabric, to limit member access, not all nodes can have the full-member default pkey

Re: [PATCH v2 1/2] mlx4: Expose correct max_sge_rd limit

On 10/28/2015 07:28 AM, Sagi Grimberg wrote: > mlx4 devices (ConnectX-2, ConnectX-3) has a limitation > where rdma read work queue entries cannot exceed 512 bytes. > A rdma_read wqe needs to fit in 512 bytes: > - wqe control segment (16 bytes) > - rdma segment (16 bytes) > - scatter elements (16

Re: [PATCH for-next 1/2] net/mlx5_core: Configure HW to support atomic request in host endianness

On Tue, Dec 08, 2015 at 06:54:15PM +0200, Eran Ben Elisha wrote: > HW is capable of 2 requestor endianness modes for standard 8 Bytes > atomic: BE (0x0) and host endianness (0x1). Read the supported modes > from hca atomic capabilities and configure HW to host endianness mode if > supported. Uh,

Re: [PATCH v2 0/2] Handle mlx4 max_sge_rd correctly

On 12/08/2015 01:13 PM, Sagi Grimberg wrote: > >> I've pulled these in. Both of them failed to apply, and the first one >> was just flat baffling in terms of how Sagi is working from a source >> base so different than the one in the upstream kernel. They should be >> double checked just to make

Re: [PATCH] IB/qib: Minor fixes to qib per SFF 8636

On 11/02/2015 12:13 PM, Mike Marciniszyn wrote: > From: Easwar Hariharan > > Minor errors found via code inspection during future development. > SFF 8636 defines bit position 2 to hold the status indication of > QSFP memory paging. The mask used to test for the value

Re: [PATCH 05/10] IB/qib: Use rdmavt lid defines in qib

On Mon, Dec 07, 2015 at 01:54:39PM -0700, Jason Gunthorpe wrote: > On Mon, Dec 07, 2015 at 03:49:12PM -0500, Dennis Dalessandro wrote: > > /* A multicast address requires a GRH (see ch. 8.4.1). */ > > - if (ah_attr->dlid >= QIB_MULTICAST_LID_BASE && > > - ah_attr->dlid !=

Re: [PATCH 03/37] IB/rdmavt: Add protection domain to rdmavt.

On Mon, Dec 07, 2015 at 03:13:16PM -0600, Sean Hefty wrote: > > +struct ib_pd *rvt_alloc_pd(struct ib_device *ibdev, > > + struct ib_ucontext *context, > > + struct ib_udata *udata) > > +{ > > + struct rvt_dev_info *dev = ib_to_rvt(ibdev); > > + struct

RE: [PATCH 03/37] IB/rdmavt: Add protection domain to rdmavt.

> > > +struct ib_pd *rvt_alloc_pd(struct ib_device *ibdev, > > > +struct ib_ucontext *context, > > > +struct ib_udata *udata) > > > +{ > > > + struct rvt_dev_info *dev = ib_to_rvt(ibdev); > > > + struct rvt_pd *pd; > > > + struct ib_pd *ret; > > > + > > > +

Re: 4.4's rdma plate

On Fri, Oct 23, 2015 at 5:52 PM, Doug Ledford wrote: > On 10/23/2015 02:46 AM, Or Gerlitz wrote: >> Doug, there are few singleton patches to mlxN drivers, just to make >> sure they are not left behind (thanks) >> a small mlx5 enhancement, Signed by Eli C. the driver

Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly)

On Tue, Dec 8, 2015 at 8:17 PM, Doug Ledford wrote: > > On 12/08/2015 01:13 PM, Sagi Grimberg wrote: > > > I mentioned this in v1. This patch set is applied over Christoph's > > device attributes patch. Will it go in as well? > > No, that's too big and not the right sort of

Re: [PATCH 03/37] IB/rdmavt: Add protection domain to rdmavt.

On Tue, Dec 08, 2015 at 01:17:48PM -0600, Sean Hefty wrote: > > > > +struct ib_pd *rvt_alloc_pd(struct ib_device *ibdev, > > > > + struct ib_ucontext *context, > > > > + struct ib_udata *udata) > > > > +{ > > > > + struct rvt_dev_info *dev =

Re: [PATCH 05/10] IB/qib: Use rdmavt lid defines in qib

On Tue, Dec 08, 2015 at 02:24:55PM -0500, ira.weiny wrote: > On Mon, Dec 07, 2015 at 01:54:39PM -0700, Jason Gunthorpe wrote: > > On Mon, Dec 07, 2015 at 03:49:12PM -0500, Dennis Dalessandro wrote: > > > /* A multicast address requires a GRH (see ch. 8.4.1). */ > > > - if (ah_attr->dlid >=

Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly)

On Wed, Dec 09, 2015 at 12:47:55AM +0200, Or Gerlitz wrote: > On Wed, Dec 9, 2015 at 12:04 AM, Doug Ledford wrote: > > Makes sense. > > thanks. > > > Show me what you are talking about (either a link to Ira's > > patch you are referring to or your own patch). > > The patch

Re: [PATCH 05/10] IB/qib: Use rdmavt lid defines in qib

On Tue, Dec 08, 2015 at 01:55:11PM -0700, Jason Gunthorpe wrote: On Tue, Dec 08, 2015 at 02:24:55PM -0500, ira.weiny wrote: On Mon, Dec 07, 2015 at 01:54:39PM -0700, Jason Gunthorpe wrote: > On Mon, Dec 07, 2015 at 03:49:12PM -0500, Dennis Dalessandro wrote: > > /* A multicast address

RE: [PATCH 1/1] Ibacm: default pkey for partitioned fabrics

> > +* Determine the default pkey for parsing address file as well. > > +* order of preference: first full-member non-management pkey, > > +* 0x, first pkey. > > +*/ > > This really should just be the 0 index pkey, which exactly matches how > IPoIB determines the default

Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly)

On Wed, Dec 9, 2015 at 12:04 AM, Doug Ledford wrote: > Makes sense. thanks. > Show me what you are talking about (either a link to Ira's > patch you are referring to or your own patch). The patch is three liner to add the cached attrs --

Re: [PATCH 00/37] Add rdma verbs transport library

On Mon, Dec 07, 2015 at 03:17:50PM -0600, Hefty, Sean wrote: The following series implements rdmavt. This is the rdma verbs transport software library This is going to be an annoying request, but I would rather see this named the IB transport library, unless this framework is usable over

Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly)

On Tue, Dec 08, 2015 at 03:02:44PM -0800, Christoph Hellwig wrote: > On Tue, Dec 08, 2015 at 03:59:40PM -0700, Jason Gunthorpe wrote: > > Or, can we please stop this bikeshedding. Christoph's patch is done, > > well tested and does a lot more clean up that this hacky three liner. > > > > It is a

Re: [PATCH 05/10] IB/qib: Use rdmavt lid defines in qib

On Tue, Dec 08, 2015 at 06:19:41PM -0500, Dennis Dalessandro wrote: > So what is the consensus here? Should we leave it alone for now and > potentially go back and deal with this separately? Just define the new one > as LE and use it, even though it doesn't match the rest? Something else >

Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly)

On Tue, Dec 08, 2015 at 03:59:40PM -0700, Jason Gunthorpe wrote: > Or, can we please stop this bikeshedding. Christoph's patch is done, > well tested and does a lot more clean up that this hacky three liner. > > It is a good patch, and although patchworks doesn't have my remarks > from an earlier

Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly)

On Wed, Dec 9, 2015 at 12:59 AM, Jason Gunthorpe wrote: > On Wed, Dec 09, 2015 at 12:47:55AM +0200, Or Gerlitz wrote: >> The patch is three liner to add the cached attrs -- >> http://marc.info/?l=linux-rdma=142309296813985=2 -- if you are OK >> with that, I will

Re: [PATCH 03/10] IB/qib: Use rdmavt protection domain

On Tue, Dec 08, 2015 at 12:49:59PM +0200, Moni Shoua wrote: On Mon, Dec 7, 2015 at 10:49 PM, Dennis Dalessandro wrote: Remove protection domain datastructure from qib and use rdmavts version. I failed to apply this patch tried with rc3 and rc4 Perhaps the two

Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly)

On Wed, Dec 9, 2015 at 1:13 AM, Or Gerlitz wrote: > On Wed, Dec 9, 2015 at 12:59 AM, Jason Gunthorpe > wrote: >> On Wed, Dec 09, 2015 at 12:47:55AM +0200, Or Gerlitz wrote: > >>> The patch is three liner to add the cached attrs -- >>>

Re: [PATCH v2 00/13] staging/rdma/hfi1: Driver cleanup and misc fixes

Hi Greg, Is this patch series still in your queue? I just wanted to make sure it didn't get dropped. Thanks, Jubin John -- 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

Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to wc

On Tue, Dec 08, 2015 at 09:23:18AM +0200, Moni Shoua wrote: > >> Now, when same gid value can be present in multiple entries you need > >> an extra parameter to get distinguish between them - that would be > >> the netwrok_type > > > > Eh? You are only worried about duplicates between rocev1 mode

Re: [PATCH 01/37] IB/rdmavt: Create module framework and handle driver registration

On Tue, Dec 08, 2015 at 07:55:45AM +0200, Leon Romanovsky wrote: On Mon, Dec 07, 2015 at 03:43:02PM -0500, Dennis Dalessandro wrote: +#include +#include +#include "vt.h" + +#define RDMAVT_DRIVER_VERSION "0.1" Do we really need driver version? Based on these patches thus far. Probably not.

RE: [PATCH 01/37] IB/rdmavt: Create module framework and handle driver registration

> >> +#define RDMAVT_DRIVER_VERSION "0.1" > >Do we really need driver version? > > Based on these patches thus far. Probably not. We do still have a bit more > development to go here, I added it more as a just in case but am not > steadfast in keeping it. > > What's the general rule here? Should

Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly)

On Tue, Dec 08, 2015 at 03:02:44PM -0800, Christoph Hellwig wrote: > On Tue, Dec 08, 2015 at 03:59:40PM -0700, Jason Gunthorpe wrote: > > Or, can we please stop this bikeshedding. Christoph's patch is done, > > well tested and does a lot more clean up that this hacky three liner. > > > > It is a

Re: 4.4's rdma plate

On 12/08/2015 04:07 PM, Or Gerlitz wrote: > On Fri, Oct 23, 2015 at 5:52 PM, Doug Ledford wrote: >> On 10/23/2015 02:46 AM, Or Gerlitz wrote: > >>> Doug, there are few singleton patches to mlxN drivers, just to make >>> sure they are not left behind (thanks) > >>> a small

Re: device attr cleanup (was: Handle mlx4 max_sge_rd correctly)

On 12/08/2015 04:00 PM, Or Gerlitz wrote: > On Tue, Dec 8, 2015 at 8:17 PM, Doug Ledford wrote: >> >> On 12/08/2015 01:13 PM, Sagi Grimberg wrote: > > >> >>> I mentioned this in v1. This patch set is applied over Christoph's >>> device attributes patch. Will it go in as

[PATCH v2 3/5] staging/rdma/hfi1: Clean-up unnecessary goto statements

From: Mitko Haralanov Clean-up unnecessary goto statements based on feedback from the mailing list on previous patch submissions. Reviewed-by: Ira Weiny Signed-off-by: Mitko Haralanov ---

[PATCH v2 2/5] staging/rdma/hfi1: Unconditionally clean-up SDMA queues

From: Mitko Haralanov There is no need to cleck if the packet queue is allocated when cleaning up a user context. The hfi1_user_sdma_free_queues() function already does all the required checks. Reviewed-by: Ira Weiny Signed-off-by: Mitko

[PATCH v2 4/5] staging/rdma/hfi1: Detect SDMA transmission error early

From: Mitko Haralanov It is possible for an SDMA transmission error to happen during the processing of an user SDMA transfer. In that case it is better to detect it early and abort any further attempts to send more packets. Reviewed-by: Ira Weiny

[PATCH v2 1/5] staging/rdma/hfi1: Convert to use get_user_pages_fast

From: Mitko Haralanov Convert hfi1_get_user_pages() to use get_user_pages_fast(), which is much fatster. The mm semaphore is still taken to update the pinned page count but is for a much shorter amount of time. Reviewed-by: Ira Weiny

[PATCH v2 0/5] Clean up SDMA engine code

From: Ira Weiny Various improvements to the SDMA engine code. --- Changes from V1: Fix off by one error in the last patch Mitko Haralanov (5): staging/rdma/hfi1: Convert to use get_user_pages_fast staging/rdma/hfi1: Unconditionally clean-up SDMA queues

[PATCH v2 5/5] staging/rdma/hfi1: Add page lock limit check for SDMA requests

From: Mitko Haralanov The driver pins pages on behalf of user processes in two separate instances - when the process has submitted a SDMA transfer and when the process programs an expected receive buffer. When pinning pages, the driver is required to observe the

Re: 4.4's rdma plate

On 12/08/2015 04:07 PM, Or Gerlitz wrote: > On Fri, Oct 23, 2015 at 5:52 PM, Doug Ledford wrote: >> On 10/23/2015 02:46 AM, Or Gerlitz wrote: > >>> Doug, there are few singleton patches to mlxN drivers, just to make >>> sure they are not left behind (thanks) > >>> a small

Re: [PATCH 1/1] Ibacm: default pkey for partitioned fabrics

On Tue, Dec 08, 2015 at 12:33:02PM -0500, kaike@intel.com wrote: > From: Kaike Wan > > In an insecure IB fabric, the default pkey in a port is 0x, where each > node is allowed to talk to any other node in the fabric, including the SA > node. However, in a secure