>>> + spin_lock_irqsave(&priv->lock, flags);
>>> + --priv->tx_outstanding;
>>> + if (netif_queue_stopped(dev))
>>> + netif_wake_queue(dev);
>>> + spin_unlock_irqrestore(&priv->lock, flags);
>>
>> Why are you locking the n
On Thu, Oct 8, 2015 at 9:14 AM, Or Gerlitz wrote:
> On 10/8/2015 9:06 AM, Leon Romanovsky wrote:
>>
>> Additionally, I want to spot Or's attention on the following discussion
>> in MM-subsystem about kmalloc/vmalloc and general function to fallback
>> from one to another.
>>
>>
>
> too busy to rea
On 10/8/2015 9:06 AM, Leon Romanovsky wrote:
Additionally, I want to spot Or's attention on the following discussion
in MM-subsystem about kmalloc/vmalloc and general function to fallback
from one to another.
too busy to read them now, if you have review comments speak now and
provide them t
On Fri, Sep 25, 2015 at 08:51:22AM +0800, Wengang Wang wrote:
> Hi Or,
>
> 在 2015年09月24日 19:57, Or Gerlitz 写道:
> >On Thu, Sep 24, 2015 at 1:49 PM, Wengang Wang
> >wrote:
> >>@@ -786,8 +787,14 @@ static int create_qp_common(struct mlx4_ib_dev *dev,
> >>struct ib_pd *pd,
> >> if (
Sagi,
With the RDMA CM patch to accept RoCE
connections(https://patchwork.kernel.org/patch/7335451/) on top of
reg_api.5 branch, I have tested nfs rdma over ocrdma. Looks good.
Tested-by: Selvin Xavier
Thanks,
Selvin Xavier
> -Original Message-
> From: linux-rdma-ow...@vger.kernel.or
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
Acked-by: Or Gerlitz
---
driver
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
b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index
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,
&qp->db);
ib_umem_release(qp->umem);
} else {
- kfree(qp->sq.wrid);
-
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...
We want commits to our dri
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 of variables in log message
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: que
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 majord...@vger.kernel.org
More majordomo info at http://vge
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, tx_outstand
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 --git a/drivers/net/ethernet/
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 1034733
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() functions
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 unsubscribe from this list: send
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 determi
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 a
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 t
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 RD
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 drive
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 [ib_
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 alig
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 alignment (0x40 for mlx4 and 0x400 for mlx5). When
On 10/7/2015 6:28 PM, Doug Ledford wrote:
However, the machine is still crashing the iDRAC on reboot. I can't be
certain if it's the SRP target or iSER target causing this as they both
were brought up live at the same time and reboot cycles without either
of these work fine. So I have more inve
On 10/06/2015 05:49 PM, Or Gerlitz wrote:
> 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 t
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
capacity.
Replace the tasklet
> 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 tasklet with a workqueue to spr
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 hand
> 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: Chuck Lever
>> ---
>> fs/nfs/callback.c
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 a
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 restructu
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 'ib_uverbs_create_c
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
>
> core/uverbs
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
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)&wr_wait;
This was fixed at least twice for this driver in differe
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 majord.
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 no
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 ta
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 d
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 | 33 +
> include/li
42 matches
Mail list logo