* [PATCH] iw_cxgb4: set correct FetchBurstMax for QPs
@ 2017-02-03 17:04 Steve Wise
2017-02-05 10:28 ` Greg KH
0 siblings, 1 reply; 7+ messages in thread
From: Steve Wise @ 2017-02-03 17:04 UTC (permalink / raw)
To: stable
I forgot to add the stable Cc tag when I submitted this, but it is important to
get this patch into 4.9.x:
commit b414fa01c31318383ae29d9d23cb9ca4184bbd86
Author: Steve Wise <swise@opengridcomputing.com>
Date: Thu Dec 15 08:09:35 2016 -0800
iw_cxgb4: set correct FetchBurstMax for QPs
The current QP FetchBurstMax value is 256B, which
is incorrect since a WR can exceed that value. The
result being a partial WR fetched by hardware, and
a fatal "bad WR" error posted by the SGE.
So bump the FetchBurstMax to 512B.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
I'm not sure if this is the correct way to request this, but I think I'm
following _option_2 from Documentation/stable_kernel_rules.txt.
Thanks,
Steve.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iw_cxgb4: set correct FetchBurstMax for QPs
2017-02-03 17:04 [PATCH] iw_cxgb4: set correct FetchBurstMax for QPs Steve Wise
@ 2017-02-05 10:28 ` Greg KH
2017-02-05 13:41 ` Steve Wise
0 siblings, 1 reply; 7+ messages in thread
From: Greg KH @ 2017-02-05 10:28 UTC (permalink / raw)
To: Steve Wise; +Cc: stable
On Fri, Feb 03, 2017 at 11:04:13AM -0600, Steve Wise wrote:
> I forgot to add the stable Cc tag when I submitted this, but it is important to
> get this patch into 4.9.x:
>
> commit b414fa01c31318383ae29d9d23cb9ca4184bbd86
> Author: Steve Wise <swise@opengridcomputing.com>
> Date: Thu Dec 15 08:09:35 2016 -0800
>
> iw_cxgb4: set correct FetchBurstMax for QPs
>
> The current QP FetchBurstMax value is 256B, which
> is incorrect since a WR can exceed that value. The
> result being a partial WR fetched by hardware, and
> a fatal "bad WR" error posted by the SGE.
>
> So bump the FetchBurstMax to 512B.
>
> Signed-off-by: Steve Wise <swise@opengridcomputing.com>
> Signed-off-by: Doug Ledford <dledford@redhat.com>
>
> I'm not sure if this is the correct way to request this, but I think I'm
> following _option_2 from Documentation/stable_kernel_rules.txt.
Now queued up. Are you sure this isn't also needed in the 4.4-stable
tree?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [PATCH] iw_cxgb4: set correct FetchBurstMax for QPs
2017-02-05 10:28 ` Greg KH
@ 2017-02-05 13:41 ` Steve Wise
2017-02-05 14:05 ` 'Greg KH'
0 siblings, 1 reply; 7+ messages in thread
From: Steve Wise @ 2017-02-05 13:41 UTC (permalink / raw)
To: 'Greg KH'; +Cc: stable
> > commit b414fa01c31318383ae29d9d23cb9ca4184bbd86
> > Author: Steve Wise <swise@opengridcomputing.com>
> > Date: Thu Dec 15 08:09:35 2016 -0800
> >
> > iw_cxgb4: set correct FetchBurstMax for QPs
> >
> > The current QP FetchBurstMax value is 256B, which
> > is incorrect since a WR can exceed that value. The
> > result being a partial WR fetched by hardware, and
> > a fatal "bad WR" error posted by the SGE.
> >
> > So bump the FetchBurstMax to 512B.
> >
> > Signed-off-by: Steve Wise <swise@opengridcomputing.com>
> > Signed-off-by: Doug Ledford <dledford@redhat.com>
> >
> > I'm not sure if this is the correct way to request this, but I think I'm
> > following _option_2 from Documentation/stable_kernel_rules.txt.
>
> Now queued up. Are you sure this isn't also needed in the 4.4-stable
> tree?
>
Hey Greg, At first, I didn't think it is needed because, while the bug is
indeed present in that code, it is only exposed (and causes problems) with
the new T6 hardware. But now I think I'd like the fix pulled in 4.4-stable
to avoid any issues if T6 support is pulled into that base.
Thanks!
Steve
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iw_cxgb4: set correct FetchBurstMax for QPs
2017-02-05 13:41 ` Steve Wise
@ 2017-02-05 14:05 ` 'Greg KH'
2017-02-06 14:59 ` Steve Wise
0 siblings, 1 reply; 7+ messages in thread
From: 'Greg KH' @ 2017-02-05 14:05 UTC (permalink / raw)
To: Steve Wise; +Cc: stable
On Sun, Feb 05, 2017 at 07:41:45AM -0600, Steve Wise wrote:
> > > commit b414fa01c31318383ae29d9d23cb9ca4184bbd86
> > > Author: Steve Wise <swise@opengridcomputing.com>
> > > Date: Thu Dec 15 08:09:35 2016 -0800
> > >
> > > iw_cxgb4: set correct FetchBurstMax for QPs
> > >
> > > The current QP FetchBurstMax value is 256B, which
> > > is incorrect since a WR can exceed that value. The
> > > result being a partial WR fetched by hardware, and
> > > a fatal "bad WR" error posted by the SGE.
> > >
> > > So bump the FetchBurstMax to 512B.
> > >
> > > Signed-off-by: Steve Wise <swise@opengridcomputing.com>
> > > Signed-off-by: Doug Ledford <dledford@redhat.com>
> > >
> > > I'm not sure if this is the correct way to request this, but I think I'm
> > > following _option_2 from Documentation/stable_kernel_rules.txt.
> >
> > Now queued up. Are you sure this isn't also needed in the 4.4-stable
> > tree?
> >
>
> Hey Greg, At first, I didn't think it is needed because, while the bug is
> indeed present in that code, it is only exposed (and causes problems) with
> the new T6 hardware. But now I think I'd like the fix pulled in 4.4-stable
> to avoid any issues if T6 support is pulled into that base.
How would I pull "T6" support into that kernel? I'm guessing that's a
much larger issue and isn't something that would normally happen in a
stable kernel release?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iw_cxgb4: set correct FetchBurstMax for QPs
2017-02-05 14:05 ` 'Greg KH'
@ 2017-02-06 14:59 ` Steve Wise
0 siblings, 0 replies; 7+ messages in thread
From: Steve Wise @ 2017-02-06 14:59 UTC (permalink / raw)
To: 'Greg KH'; +Cc: stable
>>> Now queued up. Are you sure this isn't also needed in the 4.4-stable
>>> tree?
>>>
>> Hey Greg, At first, I didn't think it is needed because, while the bug is
>> indeed present in that code, it is only exposed (and causes problems) with
>> the new T6 hardware. But now I think I'd like the fix pulled in 4.4-stable
>> to avoid any issues if T6 support is pulled into that base.
> How would I pull "T6" support into that kernel? I'm guessing that's a
> much larger issue and isn't something that would normally happen in a
> stable kernel release?
>
I guess that won't happen. To enable the T6 adapter several commits to
drivers/net/ethernet/chelsio/cxgb4 and drivers/infiniband/hw/cxgb4 would
have to flow into stable, and I guess that will not happen. Ok, so no
4.4-stable.
Thanks,
Steve.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iw_cxgb4: set correct FetchBurstMax for QPs
[not found] ` <20161215210330.81B67E08C3-/5N3P9jjx0xzbRFIqnYvSA@public.gmane.org>
@ 2016-12-18 18:36 ` Doug Ledford
0 siblings, 0 replies; 7+ messages in thread
From: Doug Ledford @ 2016-12-18 18:36 UTC (permalink / raw)
To: Steve Wise; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1.1: Type: text/plain, Size: 592 bytes --]
On 12/15/2016 11:09 AM, Steve Wise wrote:
> The current QP FetchBurstMax value is 256B, which
> is incorrect since a WR can exceed that value. The
> result being a partial WR fetched by hardware, and
> a fatal "bad WR" error posted by the SGE.
>
> So bump the FetchBurstMax to 512B.
>
> Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
Thanks, queued for -rc.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] iw_cxgb4: set correct FetchBurstMax for QPs
@ 2016-12-15 16:09 Steve Wise
[not found] ` <20161215210330.81B67E08C3-/5N3P9jjx0xzbRFIqnYvSA@public.gmane.org>
0 siblings, 1 reply; 7+ messages in thread
From: Steve Wise @ 2016-12-15 16:09 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
The current QP FetchBurstMax value is 256B, which
is incorrect since a WR can exceed that value. The
result being a partial WR fetched by hardware, and
a fatal "bad WR" error posted by the SGE.
So bump the FetchBurstMax to 512B.
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/qp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/qp.c b/drivers/infiniband/hw/cxgb4/qp.c
index b7ac97b..cda5542 100644
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -321,7 +321,8 @@ static int create_qp(struct c4iw_rdev *rdev, struct t4_wq *wq,
FW_RI_RES_WR_DCAEN_V(0) |
FW_RI_RES_WR_DCACPU_V(0) |
FW_RI_RES_WR_FBMIN_V(2) |
- FW_RI_RES_WR_FBMAX_V(2) |
+ (t4_sq_onchip(&wq->sq) ? FW_RI_RES_WR_FBMAX_V(2) :
+ FW_RI_RES_WR_FBMAX_V(3)) |
FW_RI_RES_WR_CIDXFTHRESHO_V(0) |
FW_RI_RES_WR_CIDXFTHRESH_V(0) |
FW_RI_RES_WR_EQSIZE_V(eqsize));
@@ -345,7 +346,7 @@ static int create_qp(struct c4iw_rdev *rdev, struct t4_wq *wq,
FW_RI_RES_WR_DCAEN_V(0) |
FW_RI_RES_WR_DCACPU_V(0) |
FW_RI_RES_WR_FBMIN_V(2) |
- FW_RI_RES_WR_FBMAX_V(2) |
+ FW_RI_RES_WR_FBMAX_V(3) |
FW_RI_RES_WR_CIDXFTHRESHO_V(0) |
FW_RI_RES_WR_CIDXFTHRESH_V(0) |
FW_RI_RES_WR_EQSIZE_V(eqsize));
--
2.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-02-06 14:59 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-03 17:04 [PATCH] iw_cxgb4: set correct FetchBurstMax for QPs Steve Wise
2017-02-05 10:28 ` Greg KH
2017-02-05 13:41 ` Steve Wise
2017-02-05 14:05 ` 'Greg KH'
2017-02-06 14:59 ` Steve Wise
-- strict thread matches above, loose matches on Subject: below --
2016-12-15 16:09 Steve Wise
[not found] ` <20161215210330.81B67E08C3-/5N3P9jjx0xzbRFIqnYvSA@public.gmane.org>
2016-12-18 18:36 ` Doug Ledford
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.