[PATCH for-rc or next 1/2] IB/hfi1: Indicate DMA wait when txq is queued for wakeup

[PATCH for-rc or next 1/2] IB/hfi1: Indicate DMA wait when txq is queued for wakeup

[Dennis Dalessandro]

From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>

There is no counter for dmawait in AIP, which hampers debugging
performance issues.

Add the counter increment when the txq is queued.

Fixes: d99dc602e2a5 ("IB/hfi1: Add functions to transmit datagram ipoib packets")
Fixes: c4cf5688ea69 ("IB/hfi1: Indicate DMA wait when txq is queued for wakeup")
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
---
 drivers/infiniband/hw/hfi1/ipoib_tx.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/infiniband/hw/hfi1/ipoib_tx.c b/drivers/infiniband/hw/hfi1/ipoib_tx.c
index 993f983..e74ddbe 100644
--- a/drivers/infiniband/hw/hfi1/ipoib_tx.c
+++ b/drivers/infiniband/hw/hfi1/ipoib_tx.c
@@ -644,10 +644,13 @@ static int hfi1_ipoib_sdma_sleep(struct sdma_engine *sde,
                        /* came from non-list submit */
                        list_add_tail(&txreq->list, &txq->tx_list);
                if (list_empty(&txq->wait.list)) {
+                       struct hfi1_ibport *ibp = &sde->ppd->ibport_data;
+
                        if (!atomic_xchg(&txq->no_desc, 1)) {
                                trace_hfi1_txq_queued(txq);
                                hfi1_ipoib_stop_txq(txq);
                        }
+                       ibp->rvp.n_dmawait++;
                        iowait_queue(pkts_sent, wait->iow, &sde->dmawait);
                }


External recipient

[PATCH for-rc or next 0/2] Second attempt at two small fixups

[Dennis Dalessandro]

Word from IT dept is they got the issue addressed. Test to my gmail account
looks good so here goes shot number 2. Sorry for the extra noise. Jason will
check our your mdir sync stuff thanks for the pointer.

---

Mike Marciniszyn (2):
      IB/hfi1: Indicate DMA wait when txq is queued for wakeup
      IB/hfi1: Adjust pkey entry in index 0


 drivers/infiniband/hw/hfi1/init.c     |    7 +------
 drivers/infiniband/hw/hfi1/ipoib_tx.c |    3 +++
 2 files changed, 4 insertions(+), 6 deletions(-)

--
-Denny

[PATCH for-rc or next 1/2] IB/hfi1: Indicate DMA wait when txq is queued for wakeup

[Dennis Dalessandro]

From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>

There is no counter for dmawait in AIP, which hampers debugging
performance issues.

Add the counter increment when the txq is queued.

Fixes: d99dc602e2a5 ("IB/hfi1: Add functions to transmit datagram ipoib packets")
Fixes: c4cf5688ea69 ("IB/hfi1: Indicate DMA wait when txq is queued for wakeup")
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
---
 drivers/infiniband/hw/hfi1/ipoib_tx.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/infiniband/hw/hfi1/ipoib_tx.c b/drivers/infiniband/hw/hfi1/ipoib_tx.c
index 993f983..e74ddbe 100644
--- a/drivers/infiniband/hw/hfi1/ipoib_tx.c
+++ b/drivers/infiniband/hw/hfi1/ipoib_tx.c
@@ -644,10 +644,13 @@ static int hfi1_ipoib_sdma_sleep(struct sdma_engine *sde,
 			/* came from non-list submit */
 			list_add_tail(&txreq->list, &txq->tx_list);
 		if (list_empty(&txq->wait.list)) {
+			struct hfi1_ibport *ibp = &sde->ppd->ibport_data;
+
 			if (!atomic_xchg(&txq->no_desc, 1)) {
 				trace_hfi1_txq_queued(txq);
 				hfi1_ipoib_stop_txq(txq);
 			}
+			ibp->rvp.n_dmawait++;
 			iowait_queue(pkts_sent, wait->iow, &sde->dmawait);
 		}
 

[PATCH for-rc or next 2/2] IB/hfi1: Adjust pkey entry in index 0

[Dennis Dalessandro]

From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>

It is possible for the primary IPoIB network device associated with any
RDMA device to fail to join certain multicast groups preventing IPv6
neighbor discovery and possibly other network ULPs from working
correctly. The IPv4 broadcast group is not affected as the IPoIB
network device handles joining that multicast group directly.

This is because the primary IPoIB network device uses the pkey at
ndex 0 in the associated RDMA device's pkey table. Anytime the pkey
value of index 0 changes, the primary IPoIB network device
automatically modifies it's broadcast address
(i.e. /sys/class/net/[ib0]/broadcast), since the broadcast address
includes the pkey value, and then bounces carrier. This includes
initial pkey assignment, such as when the pkey at index 0 transitions
from the opa default of invalid (0x0000) to some value such as the
OPA default pkey for Virtual Fabric 0: 0x8001 or when the fabric manager
is restarted with a configuration change causing the pkey at index 0
to change. Many network ULPs are not sensitive to the carrier bounce
and are not expecting the broadcast address to change including the
linux IPv6 stack.  This problem does not affect IPoIB child network
devices as their pkey value is constant for all time.

To mitigate this issue, change the default pkey in at index 0 to
0x8001 to cover the predominant case and avoid issues as ipoib
comes up and the FM sweeps.

At some point, ipoib multicast support should automatically
fix non-broadcast addresses as it does with the primary broadcast
address.


Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Suggested-by: Josh Collier <josh.d.collier@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
---
 drivers/infiniband/hw/hfi1/init.c |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/init.c b/drivers/infiniband/hw/hfi1/init.c
index 0986aa0..34106e5 100644
--- a/drivers/infiniband/hw/hfi1/init.c
+++ b/drivers/infiniband/hw/hfi1/init.c
@@ -650,12 +650,7 @@ void hfi1_init_pportdata(struct pci_dev *pdev, struct hfi1_pportdata *ppd,
 
 	ppd->pkeys[default_pkey_idx] = DEFAULT_P_KEY;
 	ppd->part_enforce |= HFI1_PART_ENFORCE_IN;
-
-	if (loopback) {
-		dd_dev_err(dd, "Faking data partition 0x8001 in idx %u\n",
-			   !default_pkey_idx);
-		ppd->pkeys[!default_pkey_idx] = 0x8001;
-	}
+	ppd->pkeys[0] = 0x8001;
 
 	INIT_WORK(&ppd->link_vc_work, handle_verify_cap);
 	INIT_WORK(&ppd->link_up_work, handle_link_up);

Re: [PATCH for-rc or next 1/2] IB/hfi1: Indicate DMA wait when txq is queued for wakeup

[Jason Gunthorpe]

On Tue, Jul 06, 2021 at 01:23:45PM -0400, Dennis Dalessandro wrote:
> From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
> 
> There is no counter for dmawait in AIP, which hampers debugging
> performance issues.
> 
> Add the counter increment when the txq is queued.
> 
> Fixes: d99dc602e2a5 ("IB/hfi1: Add functions to transmit datagram ipoib packets")
> Fixes: c4cf5688ea69 ("IB/hfi1: Indicate DMA wait when txq is queued for wakeup")

Neither of these fixes lines are correct, please resend it with
correct fixes lines.

This commit message is not quite good enough to justfy adding a
counter increment to rc, can you explain how this is an existing
counter and it is a bug that this single case was not incremented?

Jason

Re: [PATCH for-rc or next 1/2] IB/hfi1: Indicate DMA wait when txq is queued for wakeup

[Dennis Dalessandro]

On 7/12/21 1:42 PM, Jason Gunthorpe wrote:
> On Tue, Jul 06, 2021 at 01:23:45PM -0400, Dennis Dalessandro wrote:
>> From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
>>
>> There is no counter for dmawait in AIP, which hampers debugging
>> performance issues.
>>
>> Add the counter increment when the txq is queued.
>>
>> Fixes: d99dc602e2a5 ("IB/hfi1: Add functions to transmit datagram ipoib packets")
>> Fixes: c4cf5688ea69 ("IB/hfi1: Indicate DMA wait when txq is queued for wakeup")
> 
> Neither of these fixes lines are correct, please resend it with
> correct fixes lines.

I believe the thinking is these are fixes that should have had the counter in
the first place.

> This commit message is not quite good enough to justfy adding a
> counter increment to rc, can you explain how this is an existing
> counter and it is a bug that this single case was not incremented?

Yeah, agree. Fine to go to for-next instead.

I don't know why zero-day builds threw up on this commit. Seems unrelated.

-Denny

Re: [PATCH for-rc or next 1/2] IB/hfi1: Indicate DMA wait when txq is queued for wakeup

[Jason Gunthorpe]

On Mon, Jul 12, 2021 at 03:33:37PM -0400, Dennis Dalessandro wrote:
> On 7/12/21 1:42 PM, Jason Gunthorpe wrote:
> > On Tue, Jul 06, 2021 at 01:23:45PM -0400, Dennis Dalessandro wrote:
> >> From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
> >>
> >> There is no counter for dmawait in AIP, which hampers debugging
> >> performance issues.
> >>
> >> Add the counter increment when the txq is queued.
> >>
> >> Fixes: d99dc602e2a5 ("IB/hfi1: Add functions to transmit datagram ipoib packets")
> >> Fixes: c4cf5688ea69 ("IB/hfi1: Indicate DMA wait when txq is queued for wakeup")
> > 
> > Neither of these fixes lines are correct, please resend it with
> > correct fixes lines.
> 
> I believe the thinking is these are fixes that should have had the counter in
> the first place.

$ git describe --contains c4cf5688ea69
Could not get sha1 for c4cf5688ea69. Skipping.

Jason

RE: [PATCH for-rc or next 1/2] IB/hfi1: Indicate DMA wait when txq is queued for wakeup

[Marciniszyn, Mike]

> >
> > Fixes: d99dc602e2a5 ("IB/hfi1: Add functions to transmit datagram
> > ipoib packets")
> > Fixes: c4cf5688ea69 ("IB/hfi1: Indicate DMA wait when txq is queued
> > for wakeup")
> 
> Neither of these fixes lines are correct, please resend it with correct fixes
> lines.

d99dc602e2a5 is ok and is clearly there and adds the file itself:

commit d99dc602e2a55a99940ba9506a7126dfa54d54ea
Author: Gary Leshner <Gary.S.Leshner@intel.com>
Date:   Mon May 11 12:05:48 2020 -0400

    IB/hfi1: Add functions to transmit datagram ipoib packets

The second one is just the patch itself.   Not sure what happened there, but Denny is going to resubmit.

Mike