On 10/6/2015 9:49 PM, Bart Van Assche wrote:
On 10/06/2015 01:37 AM, Sagi Grimberg wrote:
I see now the error you are referring to.
The issue is that the device requires the MR page array to have
an alignment (0x40 for mlx4 and 0x400 for mlx5). When I modified the
page array allocation to be no
On Wed, Oct 7, 2015 at 12:26 AM, Doug Ledford wrote:
> Nothing so simple unfortunately. And it isn't an IB/RoCE cluster, it's
> IB/IB/OPA/RoCE/IWARP cluster. Regardless though, that's not my problem
> and what I'm chasing.
To be precise no two transports out of IB/RoCE/iWARP/OPA are
inter-oper
On 10/06/2015 04:54 PM, Or Gerlitz wrote:
> On Tue, Oct 6, 2015 at 7:05 PM, Doug Ledford wrote:
>> I'll have some sort of answer for that soon. I spent the better part of
>> last week, and what time I worked on the weekend, plus all day yesterday
>> on the internal infrastructure here at Red Hat.
On Tue, Oct 6, 2015 at 7:05 PM, Doug Ledford wrote:
> I'll have some sort of answer for that soon. I spent the better part of
> last week, and what time I worked on the weekend, plus all day yesterday
> on the internal infrastructure here at Red Hat. We're experiencing some
> growing pains in ou
New release for infinipath-psm (3.3-7_g05f6f14_open) is available at
http://downloads.openfabrics.org/downloads/infinipath-psm/
Vlad, it is ready for the next build.
This release fixes:
BZ 2544; no longer renaming package to intel-mic-psm for xeon-phi support
The BZ has a patch to the installer
Thanks - merged all 3
--
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
On 10/06/2015 01:37 AM, Sagi Grimberg wrote:
> I see now the error you are referring to.
>
> The issue is that the device requires the MR page array to have
> an alignment (0x40 for mlx4 and 0x400 for mlx5). When I modified the
> page array allocation to be non-coherent I didn't take care of
> ali
Looks good! I will send a test report with ocrdma driver.
Reviewed-By: Devesh Sharma
On Tue, Oct 6, 2015 at 8:29 PM, Chuck Lever wrote:
> The reply tasklet is fast, but it's single threaded. After reply
> traffic saturates a single CPU, there's no more reply processing
> capacity.
>
> Replace t
On 10/06/2015 10:56 AM, Haggai Eran wrote:
> The netdev checks recently added to RDMA CM expect a valid netdev to be
> found for both InfiniBand and RoCE, but the code that find a netdev is
> only implemented for InfiniBand.
>
> Currently RoCE doesn't provide an API to find the netdev matching a
>
looks good,
Reviewed-By: Devesh Sharma
On Tue, Oct 6, 2015 at 8:29 PM, Chuck Lever wrote:
> The rb_send_bufs and rb_recv_bufs arrays are used to implement a
> pair of stacks for keeping track of free rpcrdma_req and rpcrdma_rep
> structs. Replace those arrays with free lists.
>
> To allow more
Looks Good,
Reviewed-By: Devesh Sharma
On Tue, Oct 6, 2015 at 8:29 PM, Chuck Lever wrote:
> Clean up: The error cases in rpcrdma_reply_handler() almost never
> execute. Ensure the compiler places them out of the hot path.
>
> No behavior change expected.
>
> Signed-off-by: Chuck Lever
> ---
>
Looks good,
Reviewed-By: Devesh Sharma
Will send a test-report of this series with ocrdma drivers.
On Tue, Oct 6, 2015 at 8:28 PM, Chuck Lever wrote:
> ib_req_notify_cq(IB_CQ_REPORT_MISSED_EVENTS) returns a positive
> value if WCs were added to a CQ after the last completion upcall
> but bef
Looks good!
Reviewed-By: Devesh Sharma
On Tue, Oct 6, 2015 at 8:28 PM, Chuck Lever wrote:
> Commit 8301a2c047cc ("xprtrdma: Limit work done by completion
> handler") was supposed to prevent xprtrdma's upcall handlers from
> starving other softIRQ work by letting them return to the provider
> be
On 09/30/2015 04:34 PM, Jeff Squyres wrote:
> The usnic_verbs kernel module was clearly marked with the following in
> its code:
>
> MODULE_LICENSE("Dual BSD/GPL");
>
> However, we accidentally left a few clauses of the BSD text out of the
> license header in all the source files. This commit
On 09/28/2015 05:46 PM, Steve Wise wrote:
> The server rdma_read_chunk_lcl() and rdma_read_chunk_frmr() functions
> were not taking into account the initial page_offset when determining
> the rdma read length. This resulted in a read who's starting address
> and length exceeded the base/bounds of
On 10/06/2015 12:54 PM, Sagi Grimberg wrote:
>> Then I have to see if any of the currently posted fixes for 4.3rc that
>> I haven't grabbed yet
>> resolve the iSER issue I'm seeing, then I'll move on to for-next
>> processing.
>
> Anything I can help with Doug?
I'll tell you in a few hours.
--
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 is a local_dma_lkey. Also
>>> correctly se
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 is a local_dma_lkey. Also
>> correctly set a return value in error path.
>>
>> This caused a
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
Then I have to see if any of the currently posted fixes for 4.3rc that I
haven't grabbed yet
resolve the iSER issue I'm seeing, then I'll move on to for-next processing.
Anything I can help with Doug?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a mess
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 support for LOCAL_DMA_LKEY.
Fixes: bb6c96d72879 ("xprtrdma: Replace
> On Oct 6, 2015, at 12:27 PM, Sagi Grimberg wrote:
>
>> On 10/6/2015 6:05 PM, Chuck Lever wrote:
>> Hi Sagi-
>>
>>
>>> On Oct 6, 2015, at 5:48 AM, Sagi Grimberg wrote:
>>>
>>> There is no need to require LOCAL_DMA_LKEY support in order to
>>> use fast registration as the PD allocation makes
On 10/6/2015 6:05 PM, Chuck Lever wrote:
Hi Sagi-
On Oct 6, 2015, at 5:48 AM, Sagi Grimberg wrote:
There is no need to require LOCAL_DMA_LKEY support in order to
use fast registration as the PD allocation makes sure that there
is a local_dma_lkey.
In other words, all devices now have a loc
On 10/05/2015 05:59 PM, Or Gerlitz wrote:
> On Tue, Sep 29, 2015 at 9:24 PM, Doug Ledford wrote:
>> I'm getting ready to tackle the for-next backlog.
>
> Sounds, good, rc4 is here... so lets get things going. I see that
> there is a 4.4 branch @ your kernel.org tree with the checksum bits,
> is t
Hi Sagi-
> On Oct 6, 2015, at 5:48 AM, Sagi Grimberg wrote:
>
> There is no need to require LOCAL_DMA_LKEY support in order to
> use fast registration as the PD allocation makes sure that there
> is a local_dma_lkey.
In other words, all devices now have a local DMA lkey, so the
check is unnece
Pass the correct backchannel transport class to svc_create_xprt()
when setting up an NFSv4.1 backchannel transport.
Signed-off-by: Chuck Lever
---
fs/nfs/callback.c | 33 +
include/linux/sunrpc/xprt.h |1 +
net/sunrpc/xprtrdma/transport.c |
Allow the use of other transport classes when handling a backward
direction RPC call.
Signed-off-by: Chuck Lever
---
net/sunrpc/svc.c |5 -
1 file changed, 5 deletions(-)
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index a8f579d..bc5b7b5 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunr
On NFSv4.1 mount points, the Linux NFS client uses this transport
endpoint to receive backward direction calls and route replies back
to the NFSv4.1 server.
Signed-off-by: Chuck Lever
Acked-by: "J. Bruce Fields"
---
include/linux/sunrpc/svc_rdma.h |6 +++
include/linux/sunrpc/xprt.
Pre-allocate extra send and receive Work Requests needed to handle
backchannel receives and sends.
The transport doesn't know how many extra WRs to pre-allocate until
the xprt_setup_backchannel() call, but that's long after the WRs are
allocated during forechannel setup.
So, use a fixed value for
Introduce a code path in the rpcrdma_reply_handler() to catch
incoming backward direction RPC calls and route them to the ULP's
backchannel server.
Signed-off-by: Chuck Lever
---
net/sunrpc/xprtrdma/backchannel.c | 118 +
net/sunrpc/xprtrdma/rpc_rdma.c|
xprtrdma's backward direction send and receive buffers are the same
size as the forechannel's inline threshold, and must be pre-
registered.
The consumer has no control over which receive buffer the adapter
chooses to catch an incoming backwards-direction call. Any receive
buffer can be used for e
Backward direction RPC replies are sent via the client transport's
send_request method, the same way forward direction RPC calls are
sent.
Signed-off-by: Chuck Lever
---
net/sunrpc/xprtrdma/backchannel.c | 45 +
net/sunrpc/xprtrdma/rpc_rdma.c|5
xprt_{setup,destroy}_backchannel() won't be adequate for RPC/RMDA
bi-direction. In particular, receive buffers have to be pre-
registered and posted in order to receive incoming backchannel
requests.
Add a virtual function call to allow the insertion of appropriate
backchannel setup and destructio
The reply tasklet is fast, but it's single threaded. After reply
traffic saturates a single CPU, there's no more reply processing
capacity.
Replace the tasklet with a workqueue to spread reply handling across
all CPUs. This also moves RPC/RDMA reply handling out of the soft
IRQ context and into a
The rb_send_bufs and rb_recv_bufs arrays are used to implement a
pair of stacks for keeping track of free rpcrdma_req and rpcrdma_rep
structs. Replace those arrays with free lists.
To allow more than 512 RPCs in-flight at once, each of these arrays
would be larger than a page (assuming 8-byte addr
Clean up: The error cases in rpcrdma_reply_handler() almost never
execute. Ensure the compiler places them out of the hot path.
No behavior change expected.
Signed-off-by: Chuck Lever
---
net/sunrpc/xprtrdma/rpc_rdma.c | 89 ++-
net/sunrpc/xprtrdma/verbs.c
ib_req_notify_cq(IB_CQ_REPORT_MISSED_EVENTS) returns a positive
value if WCs were added to a CQ after the last completion upcall
but before the CQ has been re-armed.
Commit 7f23f6f6e388 ("xprtrmda: Reduce lock contention in
completion handlers") assumed that when ib_req_notify_cq() returned
a posi
Now that RPC replies are processed in a workqueue, there's no need
to disable IRQs when managing send and receive buffers. This saves
noticeable overhead per RPC.
Signed-off-by: Chuck Lever
---
net/sunrpc/xprtrdma/verbs.c | 24 ++--
1 file changed, 10 insertions(+), 14 dele
After adding a swapfile on an NFS/RDMA mount and removing the
normal swap partition, I was able to push the NFS client well
into swap without any issue.
I forgot to swapoff the NFS file before rebooting. This pinned
the NFS mount and the IB core and provider, causing shutdown to
hang. I think this
Clean up: The reply tasklet is no longer used.
Signed-off-by: Chuck Lever
---
net/sunrpc/xprtrdma/verbs.c | 43 ---
1 file changed, 43 deletions(-)
diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
index cf2f5b3..a4102fc 100644
---
Commit 8301a2c047cc ("xprtrdma: Limit work done by completion
handler") was supposed to prevent xprtrdma's upcall handlers from
starving other softIRQ work by letting them return to the provider
before all CQEs have been polled.
The logic assumes the provider will call the upcall handler again
imm
Introduce client-side support for bi-directional RPC/RDMA.
Bi-directional RPC/RDMA is a pre-requisite for NFSv4.1 on RDMA
transports.
Also available in the "nfs-rdma-for-4.4" topic branch of this git repo:
git://git.linux-nfs.org/projects/cel/cel-2.6.git
Or for browsing:
http://git.linux-nfs.or
The netdev checks recently added to RDMA CM expect a valid netdev to be
found for both InfiniBand and RoCE, but the code that find a netdev is
only implemented for InfiniBand.
Currently RoCE doesn't provide an API to find the netdev matching a
given set of parameters, so this patch just disables t
There is no need to require LOCAL_DMA_LKEY support in order to
use fast registration as the PD allocation makes sure that there
is a local_dma_lkey.
This caused a NULL pointer dereference in mlx5 which removed
the support for LOCAL_DMA_LKEY.
Fixes: bb6c96d72879 ("xprtrdma: Replace global lkey wit
From: Jan Kara
Hello,
Now when the usage of get_user_pages() in media drivers got cleaned up, here
comes a series which removes knowledge about mmap_sem from a couple of other
drivers. Patches are trivial and standalone but please check, they are only
compile tested. If you are OK with them, e
From: Jan Kara
Function mthca_map_user_db() appears to call get_user_pages() without
holding mmap_sem. Fix the bug by using get_user_pages_fast() instead
which also takes care of the locking.
CC: Roland Dreier
CC: linux-rdma@vger.kernel.org
Signed-off-by: Jan Kara
---
drivers/infiniband/hw/mt
On 10/2/2015 6:37 PM, Bart Van Assche wrote:
On 10/01/2015 11:14 PM, Sagi Grimberg wrote:
Would you mind sending me your .config?
Hello Sagi,
Hi Bart,
I just sent this .config file to you off-list.
I see now the error you are referring to.
The issue is that the device requires the MR p
47 matches
Mail list logo
