Re: [PATCH RESEND] svcrdma: handle rdma read with a non-zero initial page offset

On Wed, Oct 07, 2015 at 01:33:05PM -0400, Doug Ledford wrote: > On 10/07/2015 01:01 PM, J. Bruce Fields wrote: > > On Tue, Oct 06, 2015 at 01:44:25PM -0400, Doug Ledford wrote: > >> On 09/28/2015 05:46 PM, Steve Wise wrote: > >>> The server rdma_read_chunk_lcl() and rdma_read_chunk_frmr()

Re: [PATCH v1 00/24] New fast registration API

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

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

There are several hits that WR buffer allocation(kmalloc) failed. It failed at order 3 and/or 4 contigous pages allocation. At the same time there are actually 100MB+ free memory but well fragmented. So try vmalloc when kmalloc failed. Signed-off-by: Wengang Wang

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

On 9/24/2015 1:49 PM, Wengang Wang wrote: @@ -1050,8 +1057,9 @@ static void destroy_qp_common(struct mlx4_ib_dev *dev, struct mlx4_ib_qp *qp, >db); ib_umem_release(qp->umem); } else { - kfree(qp->sq.wrid); -

Re: [PATCH] IB/mlx4: correct order of variables in log

On 9/28/2015 5:08 AM, Wengang Wang wrote: There is a mis-order in mlx4 log. Fix it. Signed-off-by: Wengang Wang I wanted to ack it, but wait... We want commits to our driver to start with Capital letter so please resubmit with this title IB/mlx4: Use correct order

Re: [PATCH] IPoIB: serialize changing on tx_outstanding

Hi Leon, thanks for review. 在 2015年10月08日 12:33, Leon Romanovsky 写道: On Mon, Sep 28, 2015 at 01:42:10PM +0800, Wengang Wang wrote: The changing on tx_outstanding should be protected by spinlock or to be atomic operations. Such log is found in dmesg: Sep 16 14:20:53 naep11x06 kernel: ib0:

Re: [PATCH] IPoIB: serialize changing on tx_outstanding

Hi, Any comment on this patch? thanks, wengang 在 2015年09月28日 13:42, Wengang Wang 写道: The changing on tx_outstanding should be protected by spinlock or to be atomic operations. Such log is found in dmesg: Sep 16 14:20:53 naep11x06 kernel: ib0: queue stopped 1, tx_head 1034733, tx_tail

Re: [PATCH] IB/mlx4: correct order of variables in log

Hi, Any comment on this patch? thanks, wengang 在 2015年09月28日 10:08, Wengang Wang 写道: There is a mis-order in mlx4 log. Fix it. Signed-off-by: Wengang Wang --- drivers/net/ethernet/mellanox/mlx4/cmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH] IB/mlx4: correct order of variables in log

Thanks Or. I will resend the revised(title) the patch with your Ack. thanks, wengang 在 2015年10月08日 12:52, Or Gerlitz 写道: On 9/28/2015 5:08 AM, Wengang Wang wrote: There is a mis-order in mlx4 log. Fix it. Signed-off-by: Wengang Wang I wanted to ack it, but wait...

Re: [PATCH] IPoIB: serialize changing on tx_outstanding

On Mon, Sep 28, 2015 at 01:42:10PM +0800, Wengang Wang wrote: > The changing on tx_outstanding should be protected by spinlock or to be > atomic operations. > > Such log is found in dmesg: > > Sep 16 14:20:53 naep11x06 kernel: ib0: queue stopped 1, tx_head 1034733, > tx_tail 1034733,

Re: [PATCH] IB/mlx4: correct order of variables in log

On 9/28/2015 5:08 AM, Wengang Wang wrote: There is a mis-order in mlx4 log. Fix it. Signed-off-by: Wengang Wang Acked-by: Or Gerlitz -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to

[PATCH V2] IB/mlx4: Use correct order of variables in log message

There is a mis-order in mlx4 log. Fix it. Signed-off-by: Wengang Wang Acked-by: Or Gerlitz --- drivers/net/ethernet/mellanox/mlx4/cmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c

Re: [PATCH v1 00/24] New fast registration API

On Tue, Oct 06, 2015 at 11:37:40AM +0300, Sagi Grimberg wrote: > 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 > alignment. Just curious: why

Re: [PATCH v1 00/24] New fast registration API

On Wed, Oct 07, 2015 at 12:25:25PM +0300, Sagi Grimberg wrote: > Bart suggested that having to sync once for the entire page list might > perform better than coherent memory. I'll settle either way since using > non-coherent memory might cause higher-order allocations due to > alignment, so it's

[PATCH] RDMA/cxgb4: re-fix 32-bit build warning

Casting a pointer to __be64 produces a warning on 32-bit architectures: drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] req->wr.wr_lo = (__force __be64)_wait; This was fixed at least twice for this driver in different

Re: [PATCH v2 16/16] NFS: Enable client side NFSv4.1 backchannel to use other transports

On Tue, Oct 6, 2015 at 6:00 PM, Chuck Lever wrote: > 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 |

Re: [PATCH v1 00/24] New fast registration API

I don't really care either way, it just seemed like an odd change hiding in here that I missed when reviewing earlier. OK, so I'm sticking with it until someone suggests otherwise. Sagi. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to

Re: [PATCH v1 00/24] New fast registration API

On 10/7/2015 12:20 PM, Christoph Hellwig wrote: On Tue, Oct 06, 2015 at 11:37:40AM +0300, Sagi Grimberg wrote: 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

Re: [PATCH] IB/core: avoid 32-bit warning

Hi, Le mercredi 07 octobre 2015 à 16:19 +0300, Sagi Grimberg a écrit : > On 10/7/2015 3:29 PM, Arnd Bergmann wrote: > > The INIT_UDATA() macro requires a pointer or unsigned long argument > > for > > both input and output buffer, and all callers had a cast from when > > the code was merged until

Re: [PATCH v2 16/16] NFS: Enable client side NFSv4.1 backchannel to use other transports

> On Oct 7, 2015, at 5:14 AM, Leon Romanovsky wrote: > > On Tue, Oct 6, 2015 at 6:00 PM, Chuck Lever wrote: >> Pass the correct backchannel transport class to svc_create_xprt() >> when setting up an NFSv4.1 backchannel transport. >> >> Signed-off-by:

Re: [PATCH] IB/core: avoid 32-bit warning

On 10/7/2015 3:29 PM, Arnd Bergmann wrote: The INIT_UDATA() macro requires a pointer or unsigned long argument for both input and output buffer, and all callers had a cast from when the code was merged until a recent restructuring, so now we get core/uverbs_cmd.c: In function

[PATCH] IB/core: avoid 32-bit warning

The INIT_UDATA() macro requires a pointer or unsigned long argument for both input and output buffer, and all callers had a cast from when the code was merged until a recent restructuring, so now we get core/uverbs_cmd.c: In function 'ib_uverbs_create_cq': core/uverbs_cmd.c:1481:66: warning: cast

Re: [PATCH] IB/core: avoid 32-bit warning

On Wednesday 07 October 2015 16:19:27 Sagi Grimberg wrote: > On 10/7/2015 3:29 PM, Arnd Bergmann wrote: > > The INIT_UDATA() macro requires a pointer or unsigned long argument for > > both input and output buffer, and all callers had a cast from when > > the code was merged until a recent

Re: [PATCH] IB/core: avoid 32-bit warning

Hi, Le mercredi 07 octobre 2015 à 14:29 +0200, Arnd Bergmann a écrit : > The INIT_UDATA() macro requires a pointer or unsigned long argument > for both input and output buffer, and all callers had a cast from > when the code was merged until a recent restructuring, so now we get > >

Re: [PATCH v2 06/16] xprtrdma: Use workqueue to process RPC/RDMA replies

On 10/6/2015 5:59 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 the tasklet with a workqueue to spread reply handling across all CPUs. This also moves RPC/RDMA reply

Re: [PATCH v2 06/16] xprtrdma: Use workqueue to process RPC/RDMA replies

On 10/7/2015 5:48 PM, Chuck Lever wrote: On Oct 7, 2015, at 10:39 AM, Sagi Grimberg wrote: On 10/6/2015 5:59 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

Re: [PATCH v2 06/16] xprtrdma: Use workqueue to process RPC/RDMA replies

> On Oct 7, 2015, at 10:39 AM, Sagi Grimberg wrote: > > On 10/6/2015 5:59 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 the

Re: [PATCH RESEND] svcrdma: handle rdma read with a non-zero initial page offset

On 10/07/2015 01:01 PM, J. Bruce Fields wrote: > On Tue, Oct 06, 2015 at 01:44:25PM -0400, Doug Ledford wrote: >> 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

Re: [PATCH v1 00/24] New fast registration API

On 10/7/2015 6:46 PM, Bart Van Assche wrote: On 10/06/2015 11:42 PM, Sagi Grimberg wrote: 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

Seeing WARN_ON in ib_dealloc_pd from ipoib in kernel 4.3-rc1-debug

This started popping up (not sure if it's new to 4.3-rc1). Happens when unloading the provider driver (mlx4/mlx5 in my case). Has anyone seen this? kernel: [ cut here ] kernel: WARNING: CPU: 2 PID: 6012 at drivers/infiniband/core/verbs.c:283 ib_dealloc_pd+0x5b/0xa0

Re: Seeing WARN_ON in ib_dealloc_pd from ipoib in kernel 4.3-rc1-debug

On 10/07/2015 11:51 AM, Sagi Grimberg wrote: > This started popping up (not sure if it's new to 4.3-rc1). > > Happens when unloading the provider driver (mlx4/mlx5 in my case). > > Has anyone seen this? > > kernel: [ cut here ] > kernel: WARNING: CPU: 2 PID: 6012 at

Re: Seeing WARN_ON in ib_dealloc_pd from ipoib in kernel 4.3-rc1-debug

Sagi, On 10/7/15 8:51 AM, Sagi Grimberg wrote: This started popping up (not sure if it's new to 4.3-rc1). Happens when unloading the provider driver (mlx4/mlx5 in my case). Has anyone seen this? Not sure it is useful but yes I have seen similar dump with RDS on 4.3-rc1. I later found that

Re: Seeing WARN_ON in ib_dealloc_pd from ipoib in kernel 4.3-rc1-debug

On Wed, Oct 7, 2015 at 6:51 PM, Sagi Grimberg wrote: > This started popping up (not sure if it's new to 4.3-rc1). > Happens when unloading the provider driver (mlx4/mlx5 in my case). > Has anyone seen this? yes, I think to see it over the last 1-2 years Or. -- To

Re: [PATCH v1 00/24] New fast registration API

On 10/07/2015 02:20 AM, Christoph Hellwig wrote: On Tue, Oct 06, 2015 at 11:37:40AM +0300, Sagi Grimberg wrote: 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

Re: [PATCH RESEND] svcrdma: handle rdma read with a non-zero initial page offset

On Tue, Oct 06, 2015 at 01:44:25PM -0400, Doug Ledford wrote: > 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