Re: [PATCH 01/15] i40e: Add support for client interface for IWARP driver

On Wed, 2015-12-16 at 13:58 -0600, Faisal Latif wrote: > From: Anjali Singhai Jain > > This patch adds a Client interface for i40iw driver > support. Also expands the Virtchannel to support messages > from i40evf driver on behalf of i40iwvf driver. [] > diff --git

Re: [PATCH 3/3] IB core: Display 64 bit counters from the extended set

On Wed, 16 Dec 2015, Christoph Lameter wrote: > DRAFT: This is missing the check if this device supports > extended counters. Found some time and here is the patch with the detection of the extended attribute through sending a mad request. Untested. Got the info on how to do the proper mad

Re: warning in ext4 with nfs/rdma server

On Tue, Dec 08, 2015 at 07:31:56AM -0600, Steve Wise wrote: > > > > -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 > >

Re: [PATCH 15/15] i40iw: changes for build of i40iw module

> --- a/include/uapi/rdma/rdma_netlink.h > +++ b/include/uapi/rdma/rdma_netlink.h > @@ -5,6 +5,7 @@ > > enum { > RDMA_NL_RDMA_CM = 1, > + RDMA_NL_I40IW, > RDMA_NL_NES, > RDMA_NL_C4IW, > RDMA_NL_LS, /* RDMA Local Services */ This changes the values for the

[PATCH 02/15] i40iw: add main, hdr, status

i40iw_main.c contains routines for i40e <=> i40iw interface and setup. i40iw.h is header file for main device data structures. i40iw_status.h is for return status codes. Acked-by: Anjali Singhai Jain Acked-by: Shannon Nelson Signed-off-by:

[PATCH 04/15] i40iw: add puda code

i40iw_puda.[ch] are files to handle iwarp connection packets as well as exception packets over multiple privilege mode uda queues. Acked-by: Anjali Singhai Jain Acked-by: Shannon Nelson Signed-off-by: Faisal Latif ---

[PATCH 01/15] i40e: Add support for client interface for IWARP driver

From: Anjali Singhai Jain This patch adds a Client interface for i40iw driver support. Also expands the Virtchannel to support messages from i40evf driver on behalf of i40iwvf driver. This client API is used by the i40iw and i40iwvf driver to access the core driver

[PATCH 09/15] i40iw: add file to handle cqp calls

i40iw_ctrl.c provides for hardware wqe supporti and cqp. Acked-by: Anjali Singhai Jain Acked-by: Shannon Nelson Signed-off-by: Faisal Latif --- drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 4774

[PATCH 08/15] i40iw: add files for iwarp interface

i40iw_verbs.[ch] are to handle iwarp interface. Acked-by: Anjali Singhai Jain Acked-by: Shannon Nelson Signed-off-by: Faisal Latif --- drivers/infiniband/hw/i40iw/i40iw_ucontext.h | 110 ++

[PATCH 15/15] i40iw: changes for build of i40iw module

IAINTAINERS< Kconfig, Makefile and rdma_netlink.h to include i40iw Signed-off-by: Faisal Latif --- MAINTAINERS | 10 ++ drivers/infiniband/Kconfig | 1 + drivers/infiniband/hw/Makefile | 1 + include/uapi/rdma/rdma_netlink.h | 1 +

[PATCH 13/15] i40iw: virtual channel handling files

i40iw_vf.[ch] and i40iw_virtchnl[ch] are used for virtual channel support for iWARP VF module. Acked-by: Anjali Singhai Jain Acked-by: Shannon Nelson Signed-off-by: Faisal Latif ---

[PATCH 14/15] i40iw: Kconfig and Kbuild for iwarp module

Kconfig and Kbuild needed to build iwarp module. Signed-off-by: Faisal Latif --- drivers/infiniband/hw/i40iw/Kbuild | 43 + drivers/infiniband/hw/i40iw/Kconfig | 7 ++ 2 files changed, 50 insertions(+) create mode 100644

[PATCH 05/15] i40iw: add pble resource files

i40iw_pble.[ch] to manage pble resource for iwarp clients. Acked-by: Anjali Singhai Jain Acked-by: Shannon Nelson Signed-off-by: Faisal Latif --- drivers/infiniband/hw/i40iw/i40iw_pble.c | 618

[PATCH 12/15] i40iw: user kernel shared files

i40iw_user.h and i40iw_uk.c are used by both user library as well as kernel requests. Acked-by: Anjali Singhai Jain Acked-by: Shannon Nelson Signed-off-by: Faisal Latif --- drivers/infiniband/hw/i40iw/i40iw_uk.c |

[PATCH 06/15] i40iw: add hmc resource files

i40iw_hmc.[ch] are to manage hmc for the device. Acked-by: Anjali Singhai Jain Acked-by: Shannon Nelson Signed-off-by: Faisal Latif --- drivers/infiniband/hw/i40iw/i40iw_hmc.c | 823

[PATCH 11/15] i40iw: add X722 register file

X722 Hardware registers defines for iWARP component. Acked-by: Anjali Singhai Jain Acked-by: Shannon Nelson Signed-off-by: Faisal Latif --- drivers/infiniband/hw/i40iw/i40iw_register.h | 1027

[PATCH 07/15] i40iw: add hw and utils files

i40iw_hw.c, i40iw_utils.c and i40iw_osdep.h are files to handle interrupts and processing. Acked-by: Anjali Singhai Jain Acked-by: Shannon Nelson Signed-off-by: Faisal Latif --- drivers/infiniband/hw/i40iw/i40iw_hw.c

[PATCH 03/15] i40iw: add connection management code

i40iw_cm.c i40iw_cm.h are used for connection management. Acked-by: Anjali Singhai Jain Acked-by: Shannon Nelson Signed-off-by: Faisal Latif --- drivers/infiniband/hw/i40iw/i40iw_cm.c | 4447

[PATCH 10/15] i40iw: add hardware related header files

header files for hardware accesses Signed-off-by: Faisal Latif --- drivers/infiniband/hw/i40iw/i40iw_d.h| 1713 ++ drivers/infiniband/hw/i40iw/i40iw_p.h| 106 ++ drivers/infiniband/hw/i40iw/i40iw_type.h | 1308 +++

Re: [PATCH 15/15] i40iw: changes for build of i40iw module

Hi Faisal, [auto build test WARNING on net/master] [also build test WARNING on v4.4-rc5 next-20151216] [cannot apply to net-next/master] url: https://github.com/0day-ci/linux/commits/Faisal-Latif/add-Intel-R-X722-iWARP-driver/20151217-040340 config: arm-allyesconfig (attached as .config

[PATCH 00/15] add Intel(R) X722 iWARP driver

This series contains the addition of the i40iw.ko driver. This driver provides iWARP RDMA functionality for the Intel(R) X722 Ethernet controller for PCI Physical Functions. It also has support for Virtual Function driver (i40iwvf.ko) that will be part of seperate patch series. It cooperates

Re: [PATCH 02/15] i40iw: add main, hdr, status

On Wed, 2015-12-16 at 13:58 -0600, Faisal Latif wrote: > i40iw_main.c contains routines for i40e <=> i40iw interface and setup. > i40iw.h is header file for main device data structures. > i40iw_status.h is for return status codes. [] > diff --git a/drivers/infiniband/hw/i40iw/i40iw.h >

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

On 12/16/2015 01:56 AM, Moni Shoua wrote: >> The part that bothers me about this is that this statement makes sense >> when just thinking about the spec, as you say. However, once you >> consider namespaces, security implications make this statement spec >> compliant, but still unacceptable. The

Re: [PATCH] svc_rdma: use local_dma_lkey

On Wed, Dec 16, 2015 at 04:11:04PM +0100, Christoph Hellwig wrote: > We now alwasy have a per-PD local_dma_lkey available. Make use of that > fact in svc_rdma and stop registering our own MR. > > Signed-off-by: Christoph Hellwig Reviewed-by: Jason Gunthorpe

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

On Wed, Dec 16, 2015 at 08:56:01AM +0200, Moni Shoua wrote: > I can't object to that but I really would like to get an example of a > security risk. How can anyone give you an example when nobody knows exactly how mlx hardware works in this area? >From an kapi prespective, the security design

Re: [PATCH RESEND] infiniband:core:Add needed error path in cm_init_av_by_path

On Wed, Dec 16, 2015 at 11:26:39AM +0100, Michael Wang wrote: > > On 12/15/2015 06:30 PM, Jason Gunthorpe wrote: > > On Tue, Dec 15, 2015 at 05:38:34PM +0100, Michael Wang wrote: > >> The hop_limit is only suggest that the package allowed to be > >> routed, not have to, correct? > > > > If the

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

On Wed, Dec 16, 2015 at 09:57:02AM +, Liran Liss wrote: > Currently, namespaces are not supported for RoCE. IMHO, we should not be accepting rocev2 without at least basic namespace support too, since it is fairly trivial to do based on the work that is already done for verbs. An obvious

[PATCH v4 09/10] xprtrdma: Invalidate in the RPC reply handler

There is a window between the time the RPC reply handler wakes the waiting RPC task and when xprt_release() invokes ops->buf_free. During this time, memory regions containing the data payload may still be accessed by a broken or malicious server, but the RPC application has already been allowed

[PATCH v4 06/10] xprtrdma: Add ro_unmap_sync method for FRWR

FRWR's ro_unmap is asynchronous. The new ro_unmap_sync posts LOCAL_INV Work Requests and waits for them to complete before returning. Note also, DMA unmapping is now done _after_ invalidation. Signed-off-by: Chuck Lever Tested-by: Devesh Sharma

[PATCH v4 10/10] xprtrdma: Revert commit e7104a2a9606 ('xprtrdma: Cap req_cqinit').

The root of the problem was that sends (especially unsignalled FASTREG and LOCAL_INV Work Requests) were not properly flow- controlled, which allowed a send queue overrun. Now that the RPC/RDMA reply handler waits for invalidation to complete, the send queue is properly flow-controlled. Thus this

[PATCH v4 04/10] xprtrdma: Move struct ib_send_wr off the stack

For FRWR FASTREG and LOCAL_INV, move the ib_*_wr structure off the stack. This allows frwr_op_map and frwr_op_unmap to chain WRs together without limit to register or invalidate a set of MRs with a single ib_post_send(). (This will be for chaining LOCAL_INV requests). Signed-off-by: Chuck Lever

[PATCH v4 02/10] xprtrdma: xprt_rdma_free() must not release backchannel reqs

Preserve any rpcrdma_req that is attached to rpc_rqst's allocated for the backchannel. Otherwise, after all the pre-allocated backchannel req's are consumed, incoming backward calls start writing on freed memory. Somehow this hunk got lost. Fixes: f531a5dbc451 ('xprtrdma: Pre-allocate backward

[PATCH v4 03/10] xprtrdma: Disable RPC/RDMA backchannel debugging messages

Clean up. Fixes: 63cae47005af ('xprtrdma: Handle incoming backward direction') Signed-off-by: Chuck Lever Tested-by: Devesh Sharma --- net/sunrpc/xprtrdma/backchannel.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-)

[PATCH v4 05/10] xprtrdma: Introduce ro_unmap_sync method

In the current xprtrdma implementation, some memreg strategies implement ro_unmap synchronously (the MR is knocked down before the method returns) and some asynchonously (the MR will be knocked down and returned to the pool in the background). To guarantee the MR is truly invalid before the RPC

[PATCH v4 08/10] xprtrdma: Add ro_unmap_sync method for all-physical registration

physical's ro_unmap is synchronous already. The new ro_unmap_sync method just has to DMA unmap all MRs associated with the RPC request. Signed-off-by: Chuck Lever Tested-by: Devesh Sharma --- net/sunrpc/xprtrdma/physical_ops.c | 13

[PATCH v4 07/10] xprtrdma: Add ro_unmap_sync method for FMR

FMR's ro_unmap method is already synchronous because ib_unmap_fmr() is a synchronous verb. However, some improvements can be made here. 1. Gather all the MRs for the RPC request onto a list, and invoke ib_unmap_fmr() once with that list. This reduces the number of doorbells when there is

Re: [PATCH 00/15] add Intel(R) X722 iWARP driver

On Wed, 2015-12-16 at 13:58 -0600, Faisal Latif wrote: > This series contains the addition of the i40iw.ko driver. This series should probably be respun against -next instead of linus' tree. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

On Wed, Dec 16, 2015 at 03:39:16PM -0500, Doug Ledford wrote: > These patches add the concept of duplicate GIDs that are differentiated > by their RoCE version (also called network type). and by vlan, and smac, and ... Basically everything network unique about a namespace has to be encapsulted

[PATCH v4 01/10] xprtrdma: Fix additional uses of spin_lock_irqsave(rb_lock)

Clean up. rb_lock critical sections added in rpcrdma_ep_post_extra_recv() should have first been converted to use normal spin_lock now that the reply handler is a work queue. The backchannel set up code should use the appropriate helper instead of open-coding a rb_recv_bufs list add. Problem

[PATCH v4 00/10] NFS/RDMA client patches for 4.5

For 4.5, I'd like to address the send queue accounting and invalidation/unmap ordering issues Jason brought up a couple of months ago. Also available in the "nfs-rdma-for-4.5" topic branch of this git repo: git://git.linux-nfs.org/projects/cel/cel-2.6.git Or for browsing:

[PATCH 14/14] staging/rdma/hfi1: Enable TID caching feature

From: Mitko Haralanov This commit "flips the switch" on the TID caching feature implemented in this patch series. As well as enabling the new feature by tying the new function with the PSM API, it also cleans up the old unneeded code, data structure members, and

[PATCH 13/14] staging/rdma/hfi1: Add TID entry program function body

From: Mitko Haralanov The previous patch in the series added the free/invalidate function bodies. Now, it's time for the programming side. This large function takes the user's buffer, breaks it up into manageable chunks, allocates enough RcvArray groups and programs

[PATCH 11/14] staging/rdma/hfi1: Add MMU notifier callback function

From: Mitko Haralanov TID caching will rely on the MMU notifier to be told when memory is being invalidated. When the callback is called, the driver will find all RcvArray entries that span the invalidated buffer and "schedule" them to be freed by the PSM library.

[PATCH 10/14] staging/rdma/hfi1: Add Expected receive init and free functions

From: Mitko Haralanov The upcoming TID caching feature requires different data structures and, by extension, different initialization for each of the MPI processes. The two new functions (currently unused) perform the required initialization and freeing of required

[PATCH 03/14] uapi/rdma/hfi/hfi1_user.h: Convert definitions to use BIT() macro

From: Mitko Haralanov Convert bit definitions to use BIT() macro as per checkpatch.pl requirements. Reviewed-by: Ira Weiny Signed-off-by: Mitko Haralanov --- include/uapi/rdma/hfi/hfi1_user.h | 56

[PATCH 07/14] staging/rdma/hfi1: Add definitions and support functions for TID groups

From: Mitko Haralanov Definitions and functions use to manage sets of TID/RcvArray groups. These will be used by the TID cacheline functionality coming with later patches. TID groups (or RcvArray groups) are groups of TID/RcvArray entries organized in sets of 8 and

[PATCH 09/14] staging/rdma/hfi1: Convert lock to mutex

From: Mitko Haralanov The exp_lock lock does not need to be a spinlock as all its uses are in process context and allowing the process to sleep when the mutex is contended might be benefitial. Reviewed-by: Ira Weiny Signed-off-by: Mitko Haralanov

[PATCH 08/14] staging/rdma/hfi1: Start adding building blocks for TID caching

From: Mitko Haralanov Functions added by this patch are building blocks for the upcoming TID caching functionality. The functions added are currently unsed (and marked as such.) The functions' purposes are to find physically contigous pages in the user's virtual

[PATCH 02/14] uapi/rdma/hfi/hfi1_user.h: Correct comment for capability bit

From: Mitko Haralanov The HFI1_CAP_TID_UNMAP comment was incorrectly implying the opposite of what capability actually did. Correct this error. Reviewed-by: Ira Weiny Signed-off-by: Mitko Haralanov ---

[PATCH 06/14] staging/rdma/hfi1: Remove un-needed variable

From: Mitko Haralanov There is no need to use a separate variable for a return value and a label when returning right away would do just as well. Reviewed-by: Ira Weiny Signed-off-by: Mitko Haralanov ---

[PATCH 05/14] staging/rdma/hfi1: Add definitions needed for TID caching support

From: Mitko Haralanov In preparation for adding the TID caching support, there is a set of headers, structures, and variables which will be needed. This commit adds them to the hfi.h header file. Reviewed-by: Ira Weiny Signed-off-by: Mitko

[PATCH 12/14] staging/rdma/hfi1: Add TID free/clear function bodies

From: Mitko Haralanov Up to now, the functions which cleared the programmed TID entries and gave PSM the list of invalidated TID entries were just stubs. With this commit, the bodies of these functions are added. This commit is a bit asymmetric as it only contains the

Re: [PATCH 15/15] i40iw: changes for build of i40iw module

Hi Faisal, [auto build test WARNING on net/master] [also build test WARNING on v4.4-rc5 next-20151216] [cannot apply to net-next/master] url: https://github.com/0day-ci/linux/commits/Faisal-Latif/add-Intel-R-X722-iWARP-driver/20151217-040340 config: sparc-allyesconfig (attached as .config

[PATCH 00/14] Implement Expected Receive TID Caching

From: Ira Weiny Expected receives work by user-space libraries (PSM) calling into the driver with information about the user's receive buffer and have the driver DMA-map that buffer and program the HFI to receive data directly into it. This is an expensive operation as it

[PATCH 01/14] staging/rdma/hfi1: Add function stubs for TID caching

From: Mitko Haralanov Add mmu notify helper functions and TID caching function stubs in preparation for the TID caching implementation. TID caching makes use of the MMU notifier to allow the driver to respond to the user freeing memory which is allocated to the HFI.

[PATCH 04/14] uapi/rdma/hfi/hfi1_user.h: Add command and event for TID caching

From: Mitko Haralanov TID caching will use a new event to signal userland that cache invalidation has occurred and needs a matching command code that will be used to read the invalidated TIDs. Add the event bit and the new command to the exported header file. The

Re: [PATCH V3] IB/mlx4: Use vmalloc for WR buffers when needed

Hi Matt, Yes, you are right. Since the patch is already merged in, I am going to make a separated patch for that. thanks, wengang 在 2015年12月12日 04:28, Matthew Finlay 写道: Hi Wengang, I was going through your patch set here, and it seems that you missed changing kfree to kvfree in

[PATCH] IB/mlx4: Replace kfree with kvfree in mlx4_ib_destroy_srq

Commit 0ef2f05c7e02ff99c0b5b583d7dee2cd12b053f2 uses vmalloc for WR buffers when needed and uses kvfree to free the buffers. It missed changing kfree to kvfree in mlx4_ib_destroy_srq(). Reported-by: Matthew Finaly Signed-off-by: Wengang Wang ---

[PATCH 2/2] IB/mlx4: Convert kmalloc to be kmalloc_array to fix checkpatch warnings

From: Leon Romanovsky Convert kmalloc to be kmalloc_array to fix warnings below: WARNING: Prefer kmalloc_array over kmalloc with multiply + qp->sq.wrid = kmalloc(qp->sq.wqe_cnt * sizeof(u64), WARNING: Prefer kmalloc_array over kmalloc with multiply +

[PATCH 1/2] IB/mlx4: Suppress memory allocations warnings in kmalloc->__vmalloc flows

From: Leon Romanovsky Failure in kmalloc memory allocations will throw a warning about it. Such warnings are not needed anymore, since in commit 0ef2f05c7e02 ("IB/mlx4: Use vmalloc for WR buffers when needed"), fallback mechanism from kmalloc() to __vmalloc() was added.

Re: [PATCH v3 06/11] xprtrdma: Add ro_unmap_sync method for FRWR

+static void +__frwr_dma_unmap(struct rpcrdma_xprt *r_xprt, struct rpcrdma_mr_seg *seg, +int rc) +{ + struct ib_device *device = r_xprt->rx_ia.ri_device; + struct rpcrdma_mw *mw = seg->rl_mw; + int nsegs = seg->mr_nsegs; + + seg->rl_mw = NULL; + +

Re: device attr cleanup

Hi Doug, Lets stop beating, both horses and people. I do understand that 1. you don't link the removal of the attr 2. you do like the removal of all the query calls I am proposing to take the path of a patch that does exactly #2 while avoiding #1. I really don't have a strong preference

Re: [PATCH v3 09/11] SUNRPC: Introduce xprt_commit_rqst()

Hi Chuck, Sorry for the last minute comment. On 12/14/2015 04:19 PM, Chuck Lever wrote: > I'm about to add code in the RPC/RDMA reply handler between the > xprt_lookup_rqst() and xprt_complete_rqst() call site that needs > to execute outside of spinlock critical sections. > > Add a hook to

Re: [PATCH v3 04/11] xprtrdma: Move struct ib_send_wr off the stack

diff --git a/net/sunrpc/xprtrdma/xprt_rdma.h b/net/sunrpc/xprtrdma/xprt_rdma.h index 4197191..e60d817 100644 --- a/net/sunrpc/xprtrdma/xprt_rdma.h +++ b/net/sunrpc/xprtrdma/xprt_rdma.h @@ -206,6 +206,8 @@ struct rpcrdma_frmr { enum rpcrdma_frmr_state fr_state; struct

Re: device attr cleanup

On 12/16/2015 3:40 PM, Sagi Grimberg wrote: I really don't have a strong preference on either of the approaches. I just want to see this included one way or the other. sure, agree, I will send my patches tomorrow -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the

Re: [PATCH 37/37] IB/rdmavt: Add support for new memory registration API

On Wed, Dec 16, 2015 at 03:21:02PM +0200, Sagi Grimberg wrote: This question is not directly related to this patch, but given that this is a copy-paste from the qib driver I'll go ahead and take it anyway. How does qib (and rvt now) do memory key invalidation? I didn't see any reference to

RE: [PATCH for-next V2 00/11] Add RoCE v2 support

> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- > ow...@vger.kernel.org] On Behalf Of Doug Ledford > In particular, Liran piped up with this comment: > > "Also, I don't want to do any route resolution on the Rx path. A UD QP > completion just reports the details of the packet it

Re: [PATCH v3 09/11] SUNRPC: Introduce xprt_commit_rqst()

Hi Anna- > On Dec 16, 2015, at 8:48 AM, Anna Schumaker wrote: > > Hi Chuck, > > Sorry for the last minute comment. > > On 12/14/2015 04:19 PM, Chuck Lever wrote: >> I'm about to add code in the RPC/RDMA reply handler between the >> xprt_lookup_rqst() and

Re: [PATCH for-next V2 2/5] IB/core: Add ib_is_udata_cleared

On 15/12/2015 20:30, Matan Barak wrote: > Extending core and vendor verb commands require us to check that the > unknown part of the user's given command is all zeros. > Adding ib_is_udata_cleared in order to do so. > > Signed-off-by: Matan Barak Reviewed-by: Haggai Eran

Re: [PATCH for-next V2 3/5] IB/mlx5: Add support for hca_core_clock and timestamp_mask

Reporting the hca_core_clock (in kHZ) and the timestamp_mask in query_device extended verb. timestamp_mask is used by users in order to know what is the valid range of the raw timestamps, while hca_core_clock reports the clock frequency that is used for timestamps. Hi Matan, Shouldn't this

Re: [PATCH for-next V2 5/5] IB/mlx5: Mmap the HCA's core clock register to user-space

enum mlx5_ib_mmap_cmd { MLX5_IB_MMAP_REGULAR_PAGE = 0, - MLX5_IB_MMAP_GET_CONTIGUOUS_PAGES = 1, /* always last */ + MLX5_IB_MMAP_GET_CONTIGUOUS_PAGES = 1, + /* 5 is chosen in order to be compatible with old versions of libmlx5 */ +

[PATCH] svc_rdma: use local_dma_lkey

We now alwasy have a per-PD local_dma_lkey available. Make use of that fact in svc_rdma and stop registering our own MR. Signed-off-by: Christoph Hellwig --- include/linux/sunrpc/svc_rdma.h| 2 -- net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 2 +-

small svc_rdma cleanup

This makes use of the now always available local_dma_lkey, and goes on top of Chuck's "[PATCH v4 00/11] NFS/RDMA server patches for v4.5" series. -- 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 37/37] IB/rdmavt: Add support for new memory registration API

This patch exists to provide parity for what is in qib. Should we not have it? If not, why do we have: commit 38071a461f0a ("IB/qib: Support the new memory registration API") That was done by me because I saw this in qib and assumed that it was supported. Now that I found out that it isn't,

Re: [PATCH v3 04/11] xprtrdma: Move struct ib_send_wr off the stack

> On Dec 16, 2015, at 9:00 AM, Sagi Grimberg wrote: > > >> diff --git a/net/sunrpc/xprtrdma/xprt_rdma.h >> b/net/sunrpc/xprtrdma/xprt_rdma.h >> index 4197191..e60d817 100644 >> --- a/net/sunrpc/xprtrdma/xprt_rdma.h >> +++ b/net/sunrpc/xprtrdma/xprt_rdma.h >> @@

Re: [PATCH v3 04/11] xprtrdma: Move struct ib_send_wr off the stack

On Wed, Dec 16, 2015 at 10:06:33AM -0500, Chuck Lever wrote: > > Would it make sense to unionize these as they are guaranteed not to > > execute together? Some people don't like this sort of savings. > > I dislike unions because they make the code that uses > them less readable. I can define

Re: [PATCH v3 04/11] xprtrdma: Move struct ib_send_wr off the stack

> On Dec 16, 2015, at 10:11 AM, Christoph Hellwig wrote: > > On Wed, Dec 16, 2015 at 10:06:33AM -0500, Chuck Lever wrote: >>> Would it make sense to unionize these as they are guaranteed not to >>> execute together? Some people don't like this sort of savings. >> >> I

Re: [PATCH for-next V2 3/5] IB/mlx5: Add support for hca_core_clock and timestamp_mask

On Wed, Dec 16, 2015 at 4:43 PM, Sagi Grimberg wrote: > >> Reporting the hca_core_clock (in kHZ) and the timestamp_mask in >> query_device extended verb. timestamp_mask is used by users in order >> to know what is the valid range of the raw timestamps, while >>

Re: [PATCH v3 06/11] xprtrdma: Add ro_unmap_sync method for FRWR

> On Dec 16, 2015, at 8:57 AM, Sagi Grimberg wrote: > > >> +static void >> +__frwr_dma_unmap(struct rpcrdma_xprt *r_xprt, struct rpcrdma_mr_seg *seg, >> + int rc) >> +{ >> +struct ib_device *device = r_xprt->rx_ia.ri_device; >> +struct rpcrdma_mw

Re: [PATCH 3/3] IB core: Display 64 bit counters from the extended set

On Tue, 15 Dec 2015, Doug Ledford wrote: > On 12/15/2015 04:42 PM, Hal Rosenstock wrote: > > On 12/15/2015 4:20 PM, Jason Gunthorpe wrote: > >>> The unicast/multicast extended counters are not always supported - > depends on setting of PerfMgt ClassPortInfo >

Re: [PATCH v3 04/11] xprtrdma: Move struct ib_send_wr off the stack

On Wed, Dec 16, 2015 at 10:13:31AM -0500, Chuck Lever wrote: > > Shouldn't be an issue with transparent unions these days: > > > > union { > > struct ib_reg_wrfr_regwr; > > struct ib_send_wr fr_invwr; > > }; > > Right, but isn't that

Re: [PATCH] svc_rdma: use local_dma_lkey

> On Dec 16, 2015, at 10:11 AM, Christoph Hellwig wrote: > > We now alwasy have a per-PD local_dma_lkey available. Make use of that > fact in svc_rdma and stop registering our own MR. > > Signed-off-by: Christoph Hellwig Reviewed-by: Chuck Lever

Re: [PATCH] svc_rdma: use local_dma_lkey

Looks good, Reviewed-by: Sagi Grimberg -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/11] NFS/RDMA client patches for 4.5

Hi Chuck, iozone passed on ocrdma device. Link bounce fails to recover iozone traffic, however failure is not related to this patch series. I am in processes of finding out the patch which broke it. Tested-By: Devesh Sharma On Wed, Dec 16, 2015 at 1:07 AM, Anna

Re: [PATCH v4 00/11] NFS/RDMA server patches for v4.5

iozone passed on ocrdma device. Link bounce fails to recover iozone traffic, however failure is not related to this patch series. I am in processes of finding out the patch which broke it. Tested-By: Devesh Sharma On Tue, Dec 15, 2015 at 3:00 AM, Chuck Lever

Re: [PATCH 37/37] IB/rdmavt: Add support for new memory registration API

This question is not directly related to this patch, but given that this is a copy-paste from the qib driver I'll go ahead and take it anyway. How does qib (and rvt now) do memory key invalidation? I didn't see any reference to IB_WR_LOCAL_INV anywhere in the qib driver... What am I missing?

Re: [PATCH 3/3] IB core: Display 64 bit counters from the extended set

On Tue, 15 Dec 2015, Jason Gunthorpe wrote: > > The unicast/multicast extended counters are not always supported - > > depends on setting of PerfMgt ClassPortInfo > > CapabilityMask.IsExtendedWidthSupportedNoIETF (bit 10). > > Yes.. certainly this proposed patch needs to account for that and >

Re: [PATCH 3/3] IB core: Display 64 bit counters from the extended set

On 12/15/2015 04:46 PM, Doug Ledford wrote: > On 12/15/2015 04:42 PM, Hal Rosenstock wrote: >> On 12/15/2015 4:20 PM, Jason Gunthorpe wrote: The unicast/multicast extended counters are not always supported - > depends on setting of PerfMgt ClassPortInfo >

Re: [PATCH RESEND] infiniband:core:Add needed error path in cm_init_av_by_path

On 12/15/2015 06:30 PM, Jason Gunthorpe wrote: > On Tue, Dec 15, 2015 at 05:38:34PM +0100, Michael Wang wrote: >> The hop_limit is only suggest that the package allowed to be >> routed, not have to, correct? > > If the hop limit is >= 2 (?) then the GRH is mandatory. The > SM will return this

RE: [PATCH for-next V2 00/11] Add RoCE v2 support

> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- > > Since you and Jason did not reach a consensus, I have to dig in and > > see if these patches make it possible to break namespace confinement, > > either accidentally or with intentionally tricky behavior. That's > > going to take