Re: [PATCH] RDMA/cma: Make CM response timeout and # CM retries configurable

On 2/22/2019 10:36 AM, Jason Gunthorpe wrote: > On Sun, Feb 17, 2019 at 06:09:09PM +0100, Håkon Bugge wrote: >> During certain workloads, the default CM response timeout is too >> short, leading to excessive retries. Hence, make it configurable >> through sysctl. While at it, also make number of

Re: [PATCH 0/5] RDMA: reg_remote_mr

On 1/29/2019 7:26 AM, Joel Nider wrote: > As discussed at LPC'18, there is a need to be able to register a memory > region (MR) on behalf of another process. One example is the case of > post-copy container migration, in which CRIU is responsible for setting > up the migration, but the contents

Re: [PATCH RFC] iw_cxgb4: drop check - dead code

On 1/23/2019 3:44 PM, Jason Gunthorpe wrote: > On Sun, Jan 20, 2019 at 02:27:13AM +0100, Nicholas Mc Guire wrote: >> The kmalloc is called with | __GFP_NOFAIL so there is no point in >> checking the return value - it either returns valid storage or it would >> hang/terminate there. But it is

Re: [PATCH RFC] iw_cxgb4: drop check - dead code

On 1/23/2019 12:30 PM, Jason Gunthorpe wrote: > On Sun, Jan 20, 2019 at 02:27:13AM +0100, Nicholas Mc Guire wrote: >> The kmalloc is called with | __GFP_NOFAIL so there is no point in >> checking the return value - it either returns valid storage or it would >> hang/terminate there. But it is

Re: [PATCH RFC] iw_cxgb4: drop check - dead code

On 1/23/2019 12:30 PM, Jason Gunthorpe wrote: > On Sun, Jan 20, 2019 at 02:27:13AM +0100, Nicholas Mc Guire wrote: >> The kmalloc is called with | __GFP_NOFAIL so there is no point in >> checking the return value - it either returns valid storage or it would >> hang/terminate there. But it is

Re: [PATCH 1/8] infiniband: cxgb4: no need to check return value of debugfs_create functions

Hey Greg, On 1/22/2019 9:17 AM, Greg Kroah-Hartman wrote: > When calling debugfs functions, there is no need to ever check the > return value. The function can work or not, but the code logic should > never do something different based on this. > > Cc: Steve Wise > Cc:

Re: [PATCH] infiniband/hw/cxgb4/qp.c: Use dma_zalloc_coherent

wq->memsize, >dma_addr, > GFP_KERNEL); > if (!wq->queue) > goto err_free_rqtpool; > > - memset(wq->queue, 0, wq->memsize); > dma_unmap_addr_set(wq, mapping, wq->dma_addr); > > wq->bar2_va = c4iw_bar2_addrs(rdev, wq->qid, CXGB4_BAR2_QTYPE_EGRESS, > Acked-by: Steve Wise

Re: [PATCH] infiniband/hw/cxgb4/qp.c: Use dma_zalloc_coherent

wq->memsize, >dma_addr, > GFP_KERNEL); > if (!wq->queue) > goto err_free_rqtpool; > > - memset(wq->queue, 0, wq->memsize); > dma_unmap_addr_set(wq, mapping, wq->dma_addr); > > wq->bar2_va = c4iw_bar2_addrs(rdev, wq->qid, CXGB4_BAR2_QTYPE_EGRESS, > Acked-by: Steve Wise

Re: [PATCH] infiniband/hw/cxgb3/cxio_hal.c: Use dma_zalloc_coherent

wq->dma_addr); > wq->doorbell = (void __iomem *)rdev_p->rnic_info.kdb_addr; > if (!kernel_domain) > Acked-by: Steve Wise

Re: [PATCH] infiniband/hw/cxgb3/cxio_hal.c: Use dma_zalloc_coherent

wq->dma_addr); > wq->doorbell = (void __iomem *)rdev_p->rnic_info.kdb_addr; > if (!kernel_domain) > Acked-by: Steve Wise

Re: [PATCH] infiniband/hw/cxgb3/cxio_hal.c: Use dma_zalloc_coherent

wq->dma_addr); > wq->doorbell = (void __iomem *)rdev_p->rnic_info.kdb_addr; > if (!kernel_domain) > Acked-by: Steve Wise

Re: [PATCH] infiniband/hw/cxgb3/cxio_hal.c: Use dma_zalloc_coherent

wq->dma_addr); > wq->doorbell = (void __iomem *)rdev_p->rnic_info.kdb_addr; > if (!kernel_domain) > Acked-by: Steve Wise

Re: [PATCH] RDMA/cxgb3: Fix unintended sign extension

utx_cmd = (T3_UTX_MEM_WRITE << 28) | (addr + i * 3); > utx_cmd <<= 32; > - utx_cmd |= (utx_len << 28) | ((utx_len << 2) + 1); > + utx_cmd |= ((u64)utx_len << 28) | ((utx_len << 2) + 1); > *wqe = cpu_to_be64(utx_cmd); > wqe++; > copy_data = (u8 *) data + i * 96; > Acked-by: Steve Wise

Re: [PATCH] RDMA/cxgb3: Fix unintended sign extension

utx_cmd = (T3_UTX_MEM_WRITE << 28) | (addr + i * 3); > utx_cmd <<= 32; > - utx_cmd |= (utx_len << 28) | ((utx_len << 2) + 1); > + utx_cmd |= ((u64)utx_len << 28) | ((utx_len << 2) + 1); > *wqe = cpu_to_be64(utx_cmd); > wqe++; > copy_data = (u8 *) data + i * 96; > Acked-by: Steve Wise

RE: [PATCH] iw_cxgb4: fix a missing-check bug

n Wang > Subject: Re: [PATCH] iw_cxgb4: fix a missing-check bug > > On Sat, Oct 20, 2018 at 6:41 PM Steve Wise > wrote: > > > > Hey Wenwen, > > > > > Subject: [PATCH] iw_cxgb4: fix a missing-check bug > > > > > > In c4iw_flush_hw_cq

RE: [PATCH] iw_cxgb4: fix a missing-check bug

n Wang > Subject: Re: [PATCH] iw_cxgb4: fix a missing-check bug > > On Sat, Oct 20, 2018 at 6:41 PM Steve Wise > wrote: > > > > Hey Wenwen, > > > > > Subject: [PATCH] iw_cxgb4: fix a missing-check bug > > > > > > In c4iw_flush_hw_cq

RE: [PATCH] iw_cxgb4: fix a missing-check bug

Hey Wenwen, > Subject: [PATCH] iw_cxgb4: fix a missing-check bug > > In c4iw_flush_hw_cq, the next CQE is acquired through t4_next_hw_cqe(). In > t4_next_hw_cqe(), the CQE, i.e., 'cq->queue[cq->cidx]', is checked to see > whether it is valid through t4_valid_cqe(). If it is valid, the address of

RE: [PATCH] iw_cxgb4: fix a missing-check bug

Hey Wenwen, > Subject: [PATCH] iw_cxgb4: fix a missing-check bug > > In c4iw_flush_hw_cq, the next CQE is acquired through t4_next_hw_cqe(). In > t4_next_hw_cqe(), the CQE, i.e., 'cq->queue[cq->cidx]', is checked to see > whether it is valid through t4_valid_cqe(). If it is valid, the address of

Re: [PATCH] iw_cxgb4: Use proper enumerated type in c4iw_bar2_addrs

values from that type so Clang is satisfied without > changing the meaning of the code. > > T4_BAR2_QTYPE_EGRESS = CXGB4_BAR2_QTYPE_EGRESS = 0 > T4_BAR2_QTYPE_INGRESS = CXGB4_BAR2_QTYPE_INGRESS = 1 > > Reported-by: Nick Desaulniers > Signed-off-by: Nathan Chancellor Looks correct, Thanks. Acked-by: Steve Wise

Re: [PATCH] iw_cxgb4: Use proper enumerated type in c4iw_bar2_addrs

values from that type so Clang is satisfied without > changing the meaning of the code. > > T4_BAR2_QTYPE_EGRESS = CXGB4_BAR2_QTYPE_EGRESS = 0 > T4_BAR2_QTYPE_INGRESS = CXGB4_BAR2_QTYPE_INGRESS = 1 > > Reported-by: Nick Desaulniers > Signed-off-by: Nathan Chancellor Looks correct, Thanks. Acked-by: Steve Wise

Re: [PATCH] RDMA/cxgb4: remove redundant null pointer check before kfree_skb

iniband/hw/cxgb4/qp.c | 3 +-- > 2 files changed, 2 insertions(+), 4 deletions(-) Acked-by: Steve Wise

Re: [PATCH] RDMA/cxgb4: remove redundant null pointer check before kfree_skb

iniband/hw/cxgb4/qp.c | 3 +-- > 2 files changed, 2 insertions(+), 4 deletions(-) Acked-by: Steve Wise

RE: linux-next: build failure after merge of the block tree

ker...@vger.kernel.org>; Steve Wise > Subject: Re: linux-next: build failure after merge of the block tree > > On Thu, Jul 26, 2018 at 10:48:21AM -0700, Jens Axboe wrote: > > >> inline_page_count = num_pages(port->inline_data_size); > > >>

RE: linux-next: build failure after merge of the block tree

ker...@vger.kernel.org>; Steve Wise > Subject: Re: linux-next: build failure after merge of the block tree > > On Thu, Jul 26, 2018 at 10:48:21AM -0700, Jens Axboe wrote: > > >> inline_page_count = num_pages(port->inline_data_size); > > >>

RE: linux-next: build failure after merge of the block tree

Hey Stephen: > I have applied the following merge fix patch for today: > > From: Stephen Rothwell > Date: Thu, 26 Jul 2018 14:32:15 +1000 > Subject: [PATCH] nvme-dma: merge fix up for replacement of max_sge > > Signed-off-by: Stephen Rothwell > --- > drivers/nvme/host/rdma.c | 2 +- >

RE: linux-next: build failure after merge of the block tree

Hey Stephen: > I have applied the following merge fix patch for today: > > From: Stephen Rothwell > Date: Thu, 26 Jul 2018 14:32:15 +1000 > Subject: [PATCH] nvme-dma: merge fix up for replacement of max_sge > > Signed-off-by: Stephen Rothwell > --- > drivers/nvme/host/rdma.c | 2 +- >

Re: [PATCH] iw_cxgb4: add INFINIBAND_ADDR_TRANS dependency

On 5/30/2018 5:25 PM, Jason Gunthorpe wrote: > On Wed, May 30, 2018 at 05:10:35PM -0500, Steve Wise wrote: >> >> On 5/30/2018 5:04 PM, Jason Gunthorpe wrote: >>> On Wed, May 30, 2018 at 11:58:18PM +0200, Arnd Bergmann wrote: >>>> The newly added fill

Re: [PATCH] iw_cxgb4: add INFINIBAND_ADDR_TRANS dependency

On 5/30/2018 5:25 PM, Jason Gunthorpe wrote: > On Wed, May 30, 2018 at 05:10:35PM -0500, Steve Wise wrote: >> >> On 5/30/2018 5:04 PM, Jason Gunthorpe wrote: >>> On Wed, May 30, 2018 at 11:58:18PM +0200, Arnd Bergmann wrote: >>>> The newly added fill

Re: [PATCH] iw_cxgb4: add INFINIBAND_ADDR_TRANS dependency

On 5/30/2018 5:04 PM, Jason Gunthorpe wrote: > On Wed, May 30, 2018 at 11:58:18PM +0200, Arnd Bergmann wrote: >> The newly added fill_res_ep_entry function fails to link if >> CONFIG_INFINIBAND_ADDR_TRANS is not set: >> >> drivers/infiniband/hw/cxgb4/restrack.o: In function `fill_res_ep_entry':

Re: [PATCH] iw_cxgb4: add INFINIBAND_ADDR_TRANS dependency

On 5/30/2018 5:04 PM, Jason Gunthorpe wrote: > On Wed, May 30, 2018 at 11:58:18PM +0200, Arnd Bergmann wrote: >> The newly added fill_res_ep_entry function fails to link if >> CONFIG_INFINIBAND_ADDR_TRANS is not set: >> >> drivers/infiniband/hw/cxgb4/restrack.o: In function `fill_res_ep_entry':

Re: linux-next: build warning after merge of the rdma tree

On 5/14/2018 1:09 PM, Steve Wise wrote: > > On 5/14/2018 1:03 PM, Jason Gunthorpe wrote: >> On Mon, May 07, 2018 at 09:44:54AM +1000, Stephen Rothwell wrote: >>> Hi all, >>> >>> After merging the rdma tree, today's linux-next build (x86_64 >>> allm

Re: linux-next: build warning after merge of the rdma tree

On 5/14/2018 1:09 PM, Steve Wise wrote: > > On 5/14/2018 1:03 PM, Jason Gunthorpe wrote: >> On Mon, May 07, 2018 at 09:44:54AM +1000, Stephen Rothwell wrote: >>> Hi all, >>> >>> After merging the rdma tree, today's linux-next build (x86_64 >>> allm

Re: linux-next: build warning after merge of the rdma tree

On 5/14/2018 1:03 PM, Jason Gunthorpe wrote: > On Mon, May 07, 2018 at 09:44:54AM +1000, Stephen Rothwell wrote: >> Hi all, >> >> After merging the rdma tree, today's linux-next build (x86_64 >> allmodconfig) produced this warning: >> >> drivers/infiniband/hw/cxgb4/restrack.c: In function

Re: linux-next: build warning after merge of the rdma tree

On 5/14/2018 1:03 PM, Jason Gunthorpe wrote: > On Mon, May 07, 2018 at 09:44:54AM +1000, Stephen Rothwell wrote: >> Hi all, >> >> After merging the rdma tree, today's linux-next build (x86_64 >> allmodconfig) produced this warning: >> >> drivers/infiniband/hw/cxgb4/restrack.c: In function

RE: [PATCH] IB/cxgb4: use skb_put_zero()/__skb_put_zero

> <yuehaib...@huawei.com> > Subject: [PATCH] IB/cxgb4: use skb_put_zero()/__skb_put_zero > > Use the recently introduced helper to replace the pattern of > skb_put_zero/__skb_put() && memset(). > > Signed-off-by: YueHaibing <yuehaib...@huawei.com> Looks ok. Reviewed-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH] IB/cxgb4: use skb_put_zero()/__skb_put_zero

/cxgb4: use skb_put_zero()/__skb_put_zero > > Use the recently introduced helper to replace the pattern of > skb_put_zero/__skb_put() && memset(). > > Signed-off-by: YueHaibing Looks ok. Reviewed-by: Steve Wise

Re: [PATCH v4 4/6] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On 3/22/2018 9:52 AM, Sinan Kaya wrote: > On 3/22/2018 9:40 AM, Steve Wise wrote: >> I think all these iw_cxgb4 changes should be reverted until we really have a >> plan for multi-platform that works. > I know you are looking to have support for PowerPC. > > Isn't thi

Re: [PATCH v4 4/6] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On 3/22/2018 9:52 AM, Sinan Kaya wrote: > On 3/22/2018 9:40 AM, Steve Wise wrote: >> I think all these iw_cxgb4 changes should be reverted until we really have a >> plan for multi-platform that works. > I know you are looking to have support for PowerPC. > > Isn't thi

RE: [PATCH v4 4/6] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

> > On 2018-03-22 08:24, ok...@codeaurora.org wrote: > > On 2018-03-22 02:44, kbuild test robot wrote: > >> Hi Sinan, > >> > >> Thank you for the patch! Yet something to improve: > >> > >> [auto build test ERROR on linus/master] > >> [also build test ERROR on v4.16-rc6 next-20180321] > >> [if

RE: [PATCH v4 4/6] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

> > On 2018-03-22 08:24, ok...@codeaurora.org wrote: > > On 2018-03-22 02:44, kbuild test robot wrote: > >> Hi Sinan, > >> > >> Thank you for the patch! Yet something to improve: > >> > >> [auto build test ERROR on linus/master] > >> [also build test ERROR on v4.16-rc6 next-20180321] > >> [if

RE: [PATCH v4 4/6] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

_relaxed(*src, dst); > > > src++; > > > dst++; > > > count--; > > > > This is another case where writes can be re-ordered.. IIRC dst is WC > > BAR memory, so the NIC should tolerate re-ordering, but Steve will > > have to ack this. > > > > Yes, this is WC BAR memory. The goal is that pio_copy() will enable write- > combining this into a single 64B pci-e transaction. > I'd like to see the PPC issue resolved...but Acked-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH v4 4/6] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

gt; > src++; > > > dst++; > > > count--; > > > > This is another case where writes can be re-ordered.. IIRC dst is WC > > BAR memory, so the NIC should tolerate re-ordering, but Steve will > > have to ack this. > > > > Yes, this is WC BAR memory. The goal is that pio_copy() will enable write- > combining this into a single 64B pci-e transaction. > I'd like to see the PPC issue resolved...but Acked-by: Steve Wise

RE: [PATCH v4 4/6] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

> On Mon, Mar 19, 2018 at 10:47:46PM -0400, Sinan Kaya wrote: > > Code includes wmb() followed by writel(). writel() already has a barrier on > > some architectures like arm64. > > > > This ends up CPU observing two barriers back to back before executing > the > > register write. > > > > Since

RE: [PATCH v4 4/6] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

> On Mon, Mar 19, 2018 at 10:47:46PM -0400, Sinan Kaya wrote: > > Code includes wmb() followed by writel(). writel() already has a barrier on > > some architectures like arm64. > > > > This ends up CPU observing two barriers back to back before executing > the > > register write. > > > > Since

RE: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

ID_V(wq->rq.bar2_qid), > +wq->rq.bar2_va + SGE_UDB_KDOORBELL); > } > > /* Flush user doorbell area writes. */ > wmb(); > return; > } > - writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db); > + __raw_writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db); > + mmiowmb(); > } > > Yes, this is what chelsio recommended to me. Reviewed-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

ID_V(wq->rq.bar2_qid), > +wq->rq.bar2_va + SGE_UDB_KDOORBELL); > } > > /* Flush user doorbell area writes. */ > wmb(); > return; > } > - writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db); > + __raw_writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db); > + mmiowmb(); > } > > Yes, this is what chelsio recommended to me. Reviewed-by: Steve Wise

RE: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

> > On 3/16/2018 5:05 PM, Steve Wise wrote: > >> Code includes wmb() followed by writel(). writel() already has a barrier > > on > >> some architectures like arm64. > >> > >> This ends up CPU observing two barriers back to back before executing

RE: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

> > On 3/16/2018 5:05 PM, Steve Wise wrote: > >> Code includes wmb() followed by writel(). writel() already has a barrier > > on > >> some architectures like arm64. > >> > >> This ends up CPU observing two barriers back to back before executing

RE: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

> > On Fri, Mar 16, 2018 at 04:05:10PM -0500, Steve Wise wrote: > > > Code includes wmb() followed by writel(). writel() already has a barrier > > on > > > some architectures like arm64. > > > > > > This ends up CPU observing two barriers back to

RE: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

> > On Fri, Mar 16, 2018 at 04:05:10PM -0500, Steve Wise wrote: > > > Code includes wmb() followed by writel(). writel() already has a barrier > > on > > > some architectures like arm64. > > > > > > This ends up CPU observing two barriers back to

RE: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

> Code includes wmb() followed by writel(). writel() already has a barrier on > some architectures like arm64. > > This ends up CPU observing two barriers back to back before executing the > register write. > > Since code already has an explicit barrier call, changing writel() to >

RE: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

> Code includes wmb() followed by writel(). writel() already has a barrier on > some architectures like arm64. > > This ends up CPU observing two barriers back to back before executing the > register write. > > Since code already has an explicit barrier call, changing writel() to >

RE: [PATCH] IB/cxgb3: remove cxio_dbg.c

> > cxio_dbg.c is uncompiled since commit 2b540355cd2f ("RDMA/cxgb3: > cleanups") > 10 years after, we could remove it. > > Signed-off-by: Corentin Labbe <cla...@baylibre.com> Acked-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH] IB/cxgb3: remove cxio_dbg.c

> > cxio_dbg.c is uncompiled since commit 2b540355cd2f ("RDMA/cxgb3: > cleanups") > 10 years after, we could remove it. > > Signed-off-by: Corentin Labbe Acked-by: Steve Wise

RE: [PATCH] infiniband: cxgb4: use ktime_get for timestamps

.h | 4 ++-- > > drivers/infiniband/hw/cxgb4/qp.c | 6 +++--- > > drivers/infiniband/hw/cxgb4/t4.h | 4 ++-- > > 4 files changed, 22 insertions(+), 26 deletions(-) > > Steve? This changes the format of the debugfs files, so please ack it > if it is Ok.. >

RE: [PATCH] infiniband: cxgb4: use ktime_get for timestamps

drivers/infiniband/hw/cxgb4/qp.c | 6 +++--- > > drivers/infiniband/hw/cxgb4/t4.h | 4 ++-- > > 4 files changed, 22 insertions(+), 26 deletions(-) > > Steve? This changes the format of the debugfs files, so please ack it > if it is Ok.. > I apologiz

RE: [PATCH] iw_cxgb4: make pointer reg_workq static

kq' > was not declared. Should it be static? > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Looks correct. This fixes a recent commit. Reviewed-by: Steve Wise <sw...@opengridcomputing.com> Fixes: 1c8f1da5d851 ("iw_cxgb4: Fix possible circular dependency locking warning") Thanks, Steve.

RE: [PATCH] iw_cxgb4: make pointer reg_workq static

d it be static? > > Signed-off-by: Colin Ian King Looks correct. This fixes a recent commit. Reviewed-by: Steve Wise Fixes: 1c8f1da5d851 ("iw_cxgb4: Fix possible circular dependency locking warning") Thanks, Steve.

RE: [PATCH] RDMA/cxgb3: Convert timers to use timer_setup()

> In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. Also removes an unused timer. > > Cc: Steve Wise <sw...@chelsio.com> >

RE: [PATCH] RDMA/cxgb4: Convert timers to use timer_setup()

> > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. Also removes an unused timer and > drops a redundant initialization. > &g

RE: [PATCH] RDMA/cxgb3: Convert timers to use timer_setup()

> In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. Also removes an unused timer. > > Cc: Steve Wise > Cc: Doug Ledford > Cc:

RE: [PATCH] RDMA/cxgb4: Convert timers to use timer_setup()

> > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. Also removes an unused timer and > drops a redundant initialization. > >

RE: [PATCH] RDMA/cxgb3: remove redundant first assignement of sqp

ns up warning: "warning: Value stored to 'sqp' during its > initialization is never read" > > Fixes: a58e58fafdff ("RDMA/cxgb3: Wrap the software send queue pointer as > needed on flush") > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Acked-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH] RDMA/cxgb3: remove redundant first assignement of sqp

ue stored to 'sqp' during its > initialization is never read" > > Fixes: a58e58fafdff ("RDMA/cxgb3: Wrap the software send queue pointer as > needed on flush") > Signed-off-by: Colin Ian King Acked-by: Steve Wise

RE: [Patch v2 00/19] CIFS: Implement SMBDirect

> I have put the patch v3 in the following location: > https://github.com/longlimsft/linux-next/tree/patch_v3 > > I will be sending it out soon. Please give it a try. > Hey Long, how do I request a CIFS RDMA mount from the Linux client? Is there a mount.cifs option? If so, where can I get the

RE: [Patch v2 00/19] CIFS: Implement SMBDirect

> I have put the patch v3 in the following location: > https://github.com/longlimsft/linux-next/tree/patch_v3 > > I will be sending it out soon. Please give it a try. > Hey Long, how do I request a CIFS RDMA mount from the Linux client? Is there a mount.cifs option? If so, where can I get the

RE: [Patch v2 00/19] CIFS: Implement SMBDirect

> > > > Hey Long, > > > > What testing have you done with this on the various rdma transports? Does > > it work over IB, RoCE, and iWARP providers? > > Hi Steve, > > Currently all the tests have been done over Infiniband. We haven't tested on RoCE > or iWARP, but planned to do it in the

RE: [Patch v2 00/19] CIFS: Implement SMBDirect

> > > > Hey Long, > > > > What testing have you done with this on the various rdma transports? Does > > it work over IB, RoCE, and iWARP providers? > > Hi Steve, > > Currently all the tests have been done over Infiniband. We haven't tested on RoCE > or iWARP, but planned to do it in the

RE: [Patch v2 00/19] CIFS: Implement SMBDirect

> > From: Long Li > > Starting with SMB2 dialect 3.0, Microsoft introduced SMBDirect transport protocol > for transferring upper layer (SMB2) payload over RDMA via Infiniband, RoCE or > iWARP. The prococol is published in [MS-SMBD] (https://msdn.microsoft.com/en- >

RE: [Patch v2 00/19] CIFS: Implement SMBDirect

> > From: Long Li > > Starting with SMB2 dialect 3.0, Microsoft introduced SMBDirect transport protocol > for transferring upper layer (SMB2) payload over RDMA via Infiniband, RoCE or > iWARP. The prococol is published in [MS-SMBD] (https://msdn.microsoft.com/en- > us/library/hh536346.aspx). >

RE: [PATCH 1/2] RDMA/uverbs: Fix the check for port number

Mustafa Ismail <mustafa.ism...@intel.com> Looks good. Reviewed-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH 2/2] RDMA/core: Initialize port_num in qp_attr

> Initialize the port_num for iWARP in rdma_init_qp_attr. > > Signed-off-by: Mustafa Ismail <mustafa.ism...@intel.com> Looks fine. Reviewed-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH 1/2] RDMA/uverbs: Fix the check for port number

Mustafa Ismail Looks good. Reviewed-by: Steve Wise

RE: [PATCH 2/2] RDMA/core: Initialize port_num in qp_attr

> Initialize the port_num for iWARP in rdma_init_qp_attr. > > Signed-off-by: Mustafa Ismail Looks fine. Reviewed-by: Steve Wise

RE: [PATCH] cxgb4: Remove some dead code

Acked-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH] cxgb4: Remove some dead code

Acked-by: Steve Wise

RE: [RFC 4/8] p2pmem: Add debugfs "stats" file

> > > + p2pmem_debugfs_root = debugfs_create_dir("p2pmem", NULL); > > + if (!p2pmem_debugfs_root) > > + pr_info("could not create debugfs entry, continuing\n"); > > + > > Why continue? I think it'd be better to just fail it. > Because not having debugfs support isn't fatal to

RE: [RFC 4/8] p2pmem: Add debugfs "stats" file

> > > + p2pmem_debugfs_root = debugfs_create_dir("p2pmem", NULL); > > + if (!p2pmem_debugfs_root) > > + pr_info("could not create debugfs entry, continuing\n"); > > + > > Why continue? I think it'd be better to just fail it. > Because not having debugfs support isn't fatal to

RE: [RFC 2/8] cxgb4: setup pcie memory window 4 and create p2pmem region

> > > > +static void setup_memwin_p2pmem(struct adapter *adap) > > +{ > > + unsigned int mem_base = t4_read_reg(adap, > CIM_EXTMEM2_BASE_ADDR_A); > > + unsigned int mem_size = t4_read_reg(adap, > CIM_EXTMEM2_ADDR_SIZE_A); > > + > > + if (!use_p2pmem) > > + return; > > This is

RE: [RFC 2/8] cxgb4: setup pcie memory window 4 and create p2pmem region

> > > > +static void setup_memwin_p2pmem(struct adapter *adap) > > +{ > > + unsigned int mem_base = t4_read_reg(adap, > CIM_EXTMEM2_BASE_ADDR_A); > > + unsigned int mem_size = t4_read_reg(adap, > CIM_EXTMEM2_ADDR_SIZE_A); > > + > > + if (!use_p2pmem) > > + return; > > This is

RE: [PATCH 4/4] cxgb4: Convert PDBG to pr_debug

nfiniband/hw/cxgb4/t4.h | 22 +-- > 10 files changed, 368 insertions(+), 362 deletions(-) Looks good (and thanks). Reviewed-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH 4/4] cxgb4: Convert PDBG to pr_debug

| 22 +-- > 10 files changed, 368 insertions(+), 362 deletions(-) Looks good (and thanks). Reviewed-by: Steve Wise

RE: [PATCH 3/4] cxgb4: Use more common logging style

w/cxgb4/provider.c | 4 +- > drivers/infiniband/hw/cxgb4/qp.c | 5 +- > drivers/infiniband/hw/cxgb4/resource.c | 18 +++- > drivers/infiniband/hw/cxgb4/t4.h | 2 +- > 10 files changed, 97 insertions(+), 129 deletions(-) > Looks good (and thanks). Reviewed-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH 3/4] cxgb4: Use more common logging style

4 +- > drivers/infiniband/hw/cxgb4/qp.c | 5 +- > drivers/infiniband/hw/cxgb4/resource.c | 18 +++- > drivers/infiniband/hw/cxgb4/t4.h | 2 +- > 10 files changed, 97 insertions(+), 129 deletions(-) > Looks good (and thanks). Reviewed-by: Steve Wise

RE: [PATCH 1/4] cxgb3: Use more common logging style

def pr_fmt > +#undef pr_fmt > +#endif Is the ifdef/undef needed? I see other modules just define pr_fmt() regardless. Otherwise, looks good (and thanks). Reviewed-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH 1/4] cxgb3: Use more common logging style

> +#endif Is the ifdef/undef needed? I see other modules just define pr_fmt() regardless. Otherwise, looks good (and thanks). Reviewed-by: Steve Wise

RE: [PATCH 2/4] cxgb3: Convert PDBG to pr_debug

band/hw/cxgb3/iwch_mem.c | 2 +- > drivers/infiniband/hw/cxgb3/iwch_provider.c | 101 +++--- > drivers/infiniband/hw/cxgb3/iwch_provider.h | 9 +- > drivers/infiniband/hw/cxgb3/iwch_qp.c | 60 > 13 files changed, 329 insertions(+), 330 deletions(-) > Looks good (and thanks). Reviewed-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH 2/4] cxgb3: Convert PDBG to pr_debug

| 2 +- > drivers/infiniband/hw/cxgb3/iwch_provider.c | 101 +++--- > drivers/infiniband/hw/cxgb3/iwch_provider.h | 9 +- > drivers/infiniband/hw/cxgb3/iwch_qp.c | 60 > 13 files changed, 329 insertions(+), 330 deletions(-) > Looks good (and thanks). Reviewed-by: Steve Wise

RE: [PATCH] IB/cxgb3: header should be defining CXGB3_ABI_USER_H

Acked-by: Steve Wise <sw...@chelsio.com>

RE: [PATCH] IB/cxgb3: header should be defining CXGB3_ABI_USER_H

Acked-by: Steve Wise

RE: [PATCH 1/1] IB/cxgb3: fix misspelling in header guard

> > Use CXGB3_... instead of CXBG3_... > > Signed-off-by: Nicolas Iooss <nicolas.iooss_li...@m4x.org> Acked-by: Steve Wise <sw...@chelsio.com>

RE: [PATCH 1/1] IB/cxgb3: fix misspelling in header guard

> > Use CXGB3_... instead of CXBG3_... > > Signed-off-by: Nicolas Iooss Acked-by: Steve Wise

RE: [PATCH 1/1] infiniband: hw: cxgb4: set errno on failure

Acked-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH 1/1] infiniband: hw: cxgb4: set errno on failure

Acked-by: Steve Wise

RE: [PATCH v3] IB/cxgb4: Mark symbols static for _free_qp

eo...@mellanox.com> Ignore my comment on v2... Acked-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH v3] IB/cxgb4: Mark symbols static for _free_qp

in the file in which it is declared > and don't need a declaration, but can be made static. > so this patch marks it 'static'. > > Signed-off-by: Baoyou Xie > Reviewed-by: Yuval Shaia > Reviewed-by: Leon Romanovsky Ignore my comment on v2... Acked-by: Steve Wise

RE: [PATCH v2] fix:infiniband:hw:cxgb4:qp:mark symbols static where possible

> Subject: [PATCH v2] fix:infiniband:hw:cxgb4:qp:mark symbols static where possible > Is "fix:infiniband:hw:cxgb4:qp:" some standard way patches are being submitted these days? Usually it would be the module name, something like: iw_cxgb4: make _free_qp() static Steve

RE: [PATCH v2] fix:infiniband:hw:cxgb4:qp:mark symbols static where possible

> Subject: [PATCH v2] fix:infiniband:hw:cxgb4:qp:mark symbols static where possible > Is "fix:infiniband:hw:cxgb4:qp:" some standard way patches are being submitted these days? Usually it would be the module name, something like: iw_cxgb4: make _free_qp() static Steve

RE: [PATCH 05/22] IB/cma: Remove deprecated create_singlethread_workqueue

AIM has been set to ensure forward progress under > memory pressure. > > Signed-off-by: Bhaktipriya Shridhar <bhaktipriy...@gmail.com> Looks fine. Reviewed-by: Steve Wise <sw...@opengridcomputing.com>

RE: [PATCH 05/22] IB/cma: Remove deprecated create_singlethread_workqueue

AIM has been set to ensure forward progress under > memory pressure. > > Signed-off-by: Bhaktipriya Shridhar Looks fine. Reviewed-by: Steve Wise

  1   2   3   4   5   6   7   >