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 remov
Thanks, Chuck!
Everything looks okay to me, so I'll apply these patches and send them to Trond
before the holiday.
On 12/14/2015 04:17 PM, Chuck Lever wrote:
> For 4.5, I'd like to address the send queue accounting and
> invalidation/unmap ordering issues Jason brought up a couple of
> months ag
all the right Acks. I've added
> Anna and Bruce to Ack the NFS-related portions. Santosh should
> Ack the RDS part.
The NFS client parts look okay to me:
Acked-by: Anna Schumaker
>
> http://git.infradead.org/users/hch/rdma.git/shortlog/refs/heads/ib_device_attr
>
> Given t
Hi Chuck,
On 11/23/2015 05:14 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 remove an rpc_rqst from the pending list
On 11/02/2015 04:16 PM, Chuck Lever wrote:
>
>> On Nov 2, 2015, at 3:43 PM, Anna Schumaker wrote:
>>
>> Hi Chuck,
>>
>> Sorry for the delay in reviewing.
>>
>> On 10/24/2015 05:28 PM, Chuck Lever wrote:
>>> Forechannel transports get thei
Hi Chuck,
Sorry for the delay in reviewing.
On 10/24/2015 05:28 PM, Chuck Lever wrote:
> Forechannel transports get their own "bc_up" method to create an
> endpoint for the backchannel service.
>
> Signed-off-by: Chuck Lever
> ---
> fs/nfs/callback.c | 40
> +++--
On 10/24/2015 02:41 PM, Chuck Lever wrote:
>
>> On Oct 23, 2015, at 4:44 PM, Anna Schumaker
>> wrote:
>>
>> Hi Trond,
>>
>> The following changes since commit 7379047d5585187d1288486d4627873170d0005a:
>>
>> Linux 4.3-rc6 (2015-10-18 16:08:42
Hi Trond,
The following changes since commit 7379047d5585187d1288486d4627873170d0005a:
Linux 4.3-rc6 (2015-10-18 16:08:42 -0700)
are available in the git repository at:
git://git.linux-nfs.org/projects/anna/nfs-rdma.git tags/nfs-rdma-4.4
for you to fetch changes up to 50add18fd4c82cc1eaedc
Thanks! I'll push these out to Trond by the end of the week.
Anna
On 10/16/2015 09:23 AM, Chuck Lever wrote:
> Introduce client-side support for bi-directional RPC/RDMA.
> Bi-directional RPC/RDMA is a pre-requisite for NFSv4.1 on RDMA
> transports.
>
> Anna, these are ready for you to consider
ts
> as it maps well to sk_frags (see comment from hch
> http://marc.info/?l=linux-rdma&m=143677002622296&w=2).
Looks good to me!
Acked-by: Anna Schumaker
>
> Signed-off-by: Sagi Grimberg
> Acked-by: Christoph Hellwig
> Tested-by: Steve Wise
> Tested-by: Selvin Xav
On 10/06/2015 01:36 PM, Doug Ledford wrote:
> On 10/06/2015 01:25 PM, Anna Schumaker wrote:
>> Hi Sagi,
>>
>> On 10/06/2015 12:52 PM, Sagi Grimberg wrote:
>>> There is no need to require LOCAL_DMA_LKEY support as the
>>> PD allocation makes sure that there
Hi Sagi,
On 10/06/2015 12:52 PM, Sagi Grimberg wrote:
> There is no need to require LOCAL_DMA_LKEY support as the
> PD allocation makes sure that there is a local_dma_lkey. Also
> correctly set a return value in error path.
>
> This caused a NULL pointer dereference in mlx5 which removed
> the su
On 09/28/2015 10:50 AM, Steve Wise wrote:
>
>
>> -Original Message-----
>> From: Anna Schumaker [mailto:anna.schuma...@netapp.com]
>> Sent: Monday, September 28, 2015 9:45 AM
>> To: Steve Wise; trond.mykleb...@primarydata.com; bfie...@fieldses.org
>> Cc: l
Hi Steve,
On 09/28/2015 10:30 AM, Steve Wise wrote:
> On 9/21/2015 12:24 PM, Steve Wise wrote:
>> Otherwise a FRMR completion can cause a touch-after-free crash.
>>
>> In xprt_rdma_destroy(), call rpcrdma_buffer_destroy() only after calling
>> rpcrdma_ep_destroy().
>>
>> In rpcrdma_ep_destroy(), d
of
> the per-PD DMA lkey.
>
> The per-PD DMA lkey is always available. Convert xprtrdma to use the
> device's per-PD DMA lkey for regbufs, no matter which memory
> registration scheme is in use.
This is going through an RDMA tree somewhere, correct? You can add my:
Acked-by:
Hi Doug,
On 09/03/2015 04:11 PM, Doug Ledford wrote:
> On 07/30/2015 07:00 AM, Devesh Sharma wrote:
>> Thanks Chuck Lever for the valuable feedback and suggestions.
>>
>> This is a rework of the following patch sent almost a year back:
>> http://www.mail-archive.com/linux-rdma%40vger.kernel.org/ms
Hi Chuck,
I've applied these patches locally without a problem (and I made sure to remove
the pr_warns() in the last patch). Are you planning to submit a v5, or are
these ready for me now?
Thanks,
Anna
On 08/03/2015 01:02 PM, Chuck Lever wrote:
> Several important client-side performance and
This looks good to me:
Signed-off-by: Anna Schumaker
Thanks,
Anna
On 07/30/2015 03:32 AM, Sagi Grimberg wrote:
> Signed-off-by: Sagi Grimberg
> ---
> net/sunrpc/xprtrdma/frwr_ops.c | 6 +++---
> net/sunrpc/xprtrdma/svc_rdma_transport.c | 2 +-
> 2 f
t;>
>> /**
>> * ib_create_ah - Creates an address handle for the given address vector.
>> diff --git a/net/rds/iw.c b/net/rds/iw.c
>> index 589935661d66..5f228e00ad09 100644
>> --- a/net/rds/iw.c
>> +++ b/net/rds/iw.c
>> @@ -149,10 +149,7 @
On 07/21/2015 04:16 PM, Chuck Lever wrote:
> Hi Anna-
>
>
> On Jul 21, 2015, at 4:08 PM, Anna Schumaker wrote:
>
>> Hey Chuck,
>>
>> Just a heads up that this patch should go through the infiniband tree, and
>> not NFS :).
>
> The IB maintain
Hey Chuck,
Just a heads up that this patch should go through the infiniband tree, and not
NFS :).
Thanks,
Anna
On 07/20/2015 03:04 PM, Chuck Lever wrote:
> The verbs are obsolete. The ib_rereg_phys_mr() verb is not used by
> kernel ULPs, and the last ib_reg_phys_mr() call site in the kernel
> t
Hey Chuck,
On 07/09/2015 04:43 PM, Chuck Lever wrote:
> Repair how rpcrdma_marshal_req() chooses which RDMA message type
> to use for large non-WRITE operations so that it picks RDMA_NOMSG
> in the correct situations, and sets up the marshaling logic to
> SEND only the RPC/RDMA header.
>
> Large
Hi Chuck,
On 07/09/2015 04:43 PM, Chuck Lever wrote:
> Only the RPC/RDMA header is sent when making an RDMA_NOMSG call.
> That header resides in the first element of the iovec array
> passed to rpcrdma_ep_post().
>
> Instead of special casing the iovec element with the pad, just
> sync all the el
Hi Chuck,
On 07/09/2015 04:42 PM, Chuck Lever wrote:
> When marshaling RPC/RDMA requests, ensure the combined size of
> RPC/RDMA header and RPC header do not exceed the inline threshold.
> Endpoints typically reject RPC/RDMA messages that exceed the size
> of their receive buffers.
>
> Signed-off
On 07/10/2015 03:33 PM, Chuck Lever wrote:
>
> On Jul 10, 2015, at 3:21 PM, Anna Schumaker wrote:
>
>> Hi Chuck,
>>
>> On 07/09/2015 04:41 PM, Chuck Lever wrote:
>>> The point of larger rsize and wsize is to reduce the per-byte cost
>>> of memory reg
Hi Chuck,
On 07/09/2015 04:41 PM, Chuck Lever wrote:
> The point of larger rsize and wsize is to reduce the per-byte cost
> of memory registration and deregistration. Modern HCAs can typically
> handle a megabyte or more with a single registration operation.
>
> Signed-off-by: Chuck Lever
> ---
client uses when talking over RDMA. In addition, these patches also add
in scalability enhancements and other bugfixes.
Signed-off-by: Anna Schumaker
Chuck Lever (14):
xprtrdma: Warn when there are orphaned IB objects
memory registration modes. This should make it easier to one day increase
credit limit, rsize, and wsize.
Signed-off-by: Anna Schumaker
Chuck Lever (15):
SUNRPC: Introduce missing well-known netids
xprtrdma: Display
On 03/30/2015 02:33 PM, Chuck Lever wrote:
> This is a series of client-side patches for NFS/RDMA. In preparation
> for increasing the transport credit limit and maximum rsize/wsize,
> I've re-factored the memory registration logic into separate files,
> invoked via a method API.
>
> The series is
Hey Chuck,
I didn't see anything that needs to be fixed up in these patches. Are they
ready for me?
Anna
On 03/24/2015 04:30 PM, Chuck Lever wrote:
> This is a series of client-side patches for NFS/RDMA. In preparation
> for increasing the transport credit limit and maximum rsize/wsize,
> I've
sparse warning in the initial submission.
Signed-off-by: Anna Schumaker
Chuck Lever (1):
xprtrdma: Address sparse complaint in rpcr_to_rdmar()
net/sunrpc/xprtrdma/xprt_rdma.h | 7 ---
1 file changed, 4 insertions(+), 3
Hi Chuck,
I've applied these patches and the GPF flags patch for 3.20. Let me know if
you need anything else!
Anna
On 01/21/2015 11:01 AM, Chuck Lever wrote:
> The following series of patches for the Linux NFS client breaks up
> the per-transport buffer pool data structures. The goal is to allo
Hi Chuck,
You already answered my one question for this patch series, and I don't have
any other comments. Are these ready for me to take now? Are you planning a v3?
Thanks,
Anna
On 01/13/2015 11:24 AM, Chuck Lever wrote:
> The following series of patches for the Linux NFS client breaks up
>
On 01/16/2015 01:56 PM, Chuck Lever wrote:
>
> On Jan 16, 2015, at 1:33 PM, Anna Schumaker wrote:
>
>> Hi Chuck,
>>
>> On 01/13/2015 11:25 AM, Chuck Lever wrote:
>>> Clean up: Replace htonl and ntohl with the be32 equivalents.
>>
>> After ap
Hi Chuck,
On 01/13/2015 11:25 AM, Chuck Lever wrote:
> Clean up: Replace htonl and ntohl with the be32 equivalents.
After applying this patch I still see an ntohl() in both xprtrdma/transport.c
and xprtrdma/verbs.c. Should these be changed as well?
Thanks,
Anna
>
> Signed-off-by: Chuck Lever
Hi Chuck,
I've applied these to two different branches - one for the RDMA changes and
another for the generic client side changes. Both have been sent to Trond to
be merged with 3.19.
Anna
On 11/08/2014 08:14 PM, Chuck Lever wrote:
> Hi-
>
> This is a set of fixes and clean-ups for xprtrdma.
Hi Chuck,
It looks like this patch and the next one are general client changes, so they
might have to be submitted to Trond directly rather than going through my tree.
Trond, what do you think?
Anna
On 11/08/2014 08:15 PM, Chuck Lever wrote:
> Use the correct calculation of the maximum size o
Hey Chuck,
On 11/08/2014 08:14 PM, Chuck Lever wrote:
> The Linux NFS/RDMA server used to reject NFSv3 WRITE requests when
> pad optimization was enabled. That bug was fixed by commit
> e560e3b510d2 ("svcrdma: Add zero padding if the client doesn't send
> it").
Do we need to worry about backward
Hey Trond,
The following changes since commit 9a3c4145af32125c5ee39c0272662b47307a8323:
Linux 3.16-rc6 (2014-07-20 21:04:16 -0700)
are available in the git repository at:
git://git.linux-nfs.org/projects/anna/nfs-rdma.git nfs-rdma
for you to fetch changes up to 8079fb785e34de6dff34bd846b8b
I've applied v5 and updated my tree. Thanks, Chuck!
Anna
On 07/29/2014 05:23 PM, Chuck Lever wrote:
> The main purpose of this series is to address connection drop
> recovery issues by fixing FRMR re-use to make it less likely the
> client will deadlock due to a memory management operation error
Hey Roland, Sean and Hal.
We would like to submit this patch through the NFS tree, since the function
added to include/rdma/ib_verbs.h is only used for NFS over RDMA. Do any of you
have a problem with this patch, and can I have an acked-by if this is okay?
Thanks!
Anna
On 07/22/2014 10:52 AM,
Hi Roland,
I'm collecting changes for NFS over RDMA, and I wasn't sure if the change to
include/rdma/ib_verbs.h in this patch (adding ib_dec_rkey()) was something that
could be merged through the NFS tree. What do you think?
Thanks!
Anna
On 07/22/2014 10:52 AM, Chuck Lever wrote:
> If postin
On 07/23/2014 05:23 PM, Chuck Lever wrote:
>
>
>> On Jul 23, 2014, at 2:53 PM, Anna Schumaker
>> wrote:
>>
>> I've applied these changes and pushed them out in my nfs-rdma branch. I'm
>> planning to send a pull request to Trond on Friday so these
I've applied these changes and pushed them out in my nfs-rdma branch. I'm
planning to send a pull request to Trond on Friday so these changes can spend
some time in linux-next before the next merge window opens.
Anna
On 07/22/2014 10:50 AM, Chuck Lever wrote:
> The main purpose of this series
On 07/22/2014 05:18 PM, Chuck Lever wrote:
>
> On Jul 22, 2014, at 4:03 PM, Anna Schumaker wrote:
>
>> On 07/22/2014 10:52 AM, Chuck Lever wrote:
>>> If posting a FAST_REG_MR Work Reqeust fails, revert the rkey update
>>> to avoid subsequent IB_WC_MW_BIND_ERR
On 07/22/2014 10:52 AM, Chuck Lever wrote:
> If posting a FAST_REG_MR Work Reqeust fails, revert the rkey update
> to avoid subsequent IB_WC_MW_BIND_ERR completions.
>
> Suggested-by: Steve Wise
> Signed-off-by: Chuck Lever
> Tested-by: Shirley Ma
> Tested-by: Devesh Sharma
> ---
> include/rd
On 07/22/2014 10:51 AM, Chuck Lever wrote:
> Various reports of:
>
> rpcrdma_qp_async_error_upcall: QP error 3 on device mlx4_0
> ep 8800bfd3e848
>
> Ensure that rkeys in already-marshalled RPC/RDMA headers are
> refreshed after the QP has been replaced by a reconnect.
>
> Bu
On 07/09/2014 12:57 PM, Chuck Lever wrote:
> If posting a FAST_REG_MR Work Reqeust fails, revert the rkey update
> to avoid subsequent IB_WC_MW_BIND_ERR completions.
>
> Suggested-by: Steve Wise
> Signed-off-by: Chuck Lever
> ---
> net/sunrpc/xprtrdma/verbs.c | 27 ---
>
I'll still be taking patches, so feel free to send me things now rather than
waiting for the merge window to open!
Anna
On 07/08/2014 12:49 PM, Shirley Ma wrote:
> Most of us will be on vacation in the summer so there will be no bi-weekly
> meetings from now to Aug. We will resume the meeting i
On 06/23/2014 06:40 PM, Chuck Lever wrote:
> Commit 38ca83a5 added RDMA_CM_EVENT_TIMEWAIT_EXIT. But that status
> is relevant only for consumers that re-use their QPs on new
> connections. xprtrdma creates a fresh QP on reconnection, so that
> event should be explicitly ignored.
>
> Squelch the ala
On 06/23/2014 06:40 PM, Chuck Lever wrote:
> If posting a FAST_REG_MR Work Reqeust fails, or the FAST_REG WR
> flushes, revert the rkey update to avoid subsequent
> IB_WC_MW_BIND_ERR completions.
>
> Suggested-by: Steve Wise
> Signed-off-by: Chuck Lever
> ---
> net/sunrpc/xprtrdma/verbs.c | 39
On 06/19/2014 09:06 AM, Yan Burman wrote:
> Fix the following warning when DMA-API debug is enabled by checking
> ib_dma_map_single result:
> [ 1455.345548] [ cut here ]
> [ 1455.346863] WARNING: CPU: 3 PID: 3929 at
> /home/yanb/kernel/net-next/lib/dma-debug.c:1140 check_u
On 06/17/2014 08:39 AM, Yan Burman wrote:
> Fix the following warning when DMA-API debug is enabled by checking
> ib_dma_map_single result:
> [ 1455.345548] [ cut here ]
> [ 1455.346863] WARNING: CPU: 3 PID: 3929 at
> /home/yanb/kernel/net-next/lib/dma-debug.c:1140 check_u
On 06/09/2014 05:55 AM, Or Gerlitz wrote:
> On Thu, May 29, 2014 at 7:59 PM, Steve Wise
> wrote:
>> I tested this series over cxgb4 and mlx4, running cthon04, fio read/rand-rw,
>> and xfstests, and over mthca cthon04. No regressions.
>
> Steve, Chuck, all
>
> Where this series stands? I don't
On 05/29/2014 01:07 PM, Shirley Ma wrote:
> Attendees:
>
> Jeff Beck (NASA)
> Yan Burman (Mellanox)
> Wendy Cheng (Intel)
> Susan Coulter (LANL)
> Rupert Dance (Soft Forge)
> Chuck Lever (Oracle)
> Doug Ledford (RedHat)
> Shirley Ma (Oracle)
> Devesh Sharma (
boot if at least
> one client mount is established. I am using OpenSUSE 12.3 with the
> nfs-rdma kernel from Anna Schumaker
> (git://git.linux-nfs.org/projects/anna/nfs-rdma.git).
>
> The export on the server side is done with
> /data *(fsid=0,crossmnt,rw,mp,no_root_squash,sync,no_s
56 matches
Mail list logo
