From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9EAEC43E78; Mon, 15 Apr 2024 10:32:52 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1B4624026C; Mon, 15 Apr 2024 10:32:52 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 76EDE400EF for ; Mon, 15 Apr 2024 10:32:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713169969; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MV3AQpqzqB52o+eWJzKwXZEdas4MCyDXnUoxIqzo8bU=; b=E0a5WwEYyB5xoJce6Ep8yA1gNbug48vC+9N+E4KnQ6zSDtDJ/5e1K3isiLym5ShAlSthwV K/htW0+9No7oc9y80xcGTubIbGGFlS6IDQ1JeeRvgWEQkNA7Jj0MnXBH95o8net0UMFRx5 ZGJrrN77cnkxC+TdX4sWtvgk2H1jCZ4= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-606-hLVQtCAKNhumpapy62VBDg-1; Mon, 15 Apr 2024 04:32:48 -0400 X-MC-Unique: hLVQtCAKNhumpapy62VBDg-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2d86787efa3so23569181fa.1 for ; Mon, 15 Apr 2024 01:32:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713169967; x=1713774767; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MV3AQpqzqB52o+eWJzKwXZEdas4MCyDXnUoxIqzo8bU=; b=nBZHY90fJjdZfiTrW4skbky10XPpZDY2upEyGh6/Vb3IJ1/PxVz8QhsKADzLcC4LPg /6BZnArYtm/Q5entvs5ANqU8QXmAVpsMi87ML56DpTtqnLXdDFo9uDlCyimTcLNm2iPg Z8zMC2zR3Z+bSGA9xZQ5fnetN/gjVoH5hVqNhr4ygtoLZjx0hi6xyBu3q54AvuSxIc0u rZ5Sp8vtf4RsXbZPn1/ZdoRIM0AKcOHPFgFZusy9ZsuYhIs4DOIoDeeM/p66A765uMK2 e/wC6eYBURFAzNuMP2yhHwR/Y2lZyRBNoT/jEvJBM40oOvTa0toGU0RA8pFSj6hpNF+d xMRA== X-Gm-Message-State: AOJu0YzBmKUQ03im++9JweOtkTmA/IMv3NWoapn+YwqV0aK0IKboHJ8J yDk7eanrli7N0Y8DqOR4d2isE/IweCvG+/1EMVKduKBTFOkog19W/tyqMvabs7r8zWlfhhKChIv U8FMRyFlqq7B4YE62DBTUYk+uwqp+ePGhg66pqN9uhvnySa+XTEDyh3LIaDaCRfgLyJFEO3hP8W PpREbAVSLo6u7cHUM= X-Received: by 2002:a2e:9916:0:b0:2d6:f5c6:e5a1 with SMTP id v22-20020a2e9916000000b002d6f5c6e5a1mr7272776lji.12.1713169966958; Mon, 15 Apr 2024 01:32:46 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHkZPl975qCBjrgcoAhJoL59+2zXae9gj3iBv6hHApeqwIGzmL+SSHioVB60PSmufZr3/MsKh3xuyr+cwBB/2o= X-Received: by 2002:a2e:9916:0:b0:2d6:f5c6:e5a1 with SMTP id v22-20020a2e9916000000b002d6f5c6e5a1mr7272747lji.12.1713169966508; Mon, 15 Apr 2024 01:32:46 -0700 (PDT) MIME-Version: 1.0 References: <20240405125039.897933-1-david.marchand@redhat.com> <20240405144604.906695-1-david.marchand@redhat.com> <20240405144604.906695-3-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Mon, 15 Apr 2024 10:32:34 +0200 Message-ID: Subject: Re: [PATCH v2 2/8] net/ice: enhance debug when HW fails to transmit To: Bruce Richardson Cc: dev@dpdk.org, thomas@monjalon.net, ferruh.yigit@amd.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, Apr 11, 2024 at 10:42=E2=80=AFAM Bruce Richardson wrote: > > On Thu, Apr 11, 2024 at 10:30:19AM +0200, David Marchand wrote: > > On Mon, Apr 8, 2024 at 5:23=E2=80=AFPM Bruce Richardson > > wrote: > > > > > > On Fri, Apr 05, 2024 at 04:45:56PM +0200, David Marchand wrote: > > > > At the moment, if the driver sets an incorrect Tx descriptor, the H= W > > > > will raise a MDD event reported as: > > > > ice_interrupt_handler(): OICR: MDD event > > > > > > > > Add some debug info for this case and the VF index in all logs. > > > > > > > > Signed-off-by: David Marchand > > > > --- > > > > drivers/net/ice/ice_ethdev.c | 29 +++++++++++++++++++++++++---- > > > > 1 file changed, 25 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_eth= dev.c > > > > index 87385d2649..fd494e6b3b 100644 > > > > --- a/drivers/net/ice/ice_ethdev.c > > > > +++ b/drivers/net/ice/ice_ethdev.c > > > > @@ -1389,6 +1389,7 @@ ice_interrupt_handler(void *param) > > > > uint32_t oicr; > > > > uint32_t reg; > > > > uint8_t pf_num; > > > > + uint16_t vf_num; > > > > uint8_t event; > > > > uint16_t queue; > > > > int ret; > > > > @@ -1432,28 +1433,48 @@ ice_interrupt_handler(void *param) > > > > if (reg & GL_MDET_TX_PQM_VALID_M) { > > > > pf_num =3D (reg & GL_MDET_TX_PQM_PF_NUM_M) >> > > > > GL_MDET_TX_PQM_PF_NUM_S; > > > > + vf_num =3D (reg & GL_MDET_TX_PQM_VF_NUM_M) >> > > > > + GL_MDET_TX_PQM_VF_NUM_S; > > > > event =3D (reg & GL_MDET_TX_PQM_MAL_TYPE_M) >= > > > > > GL_MDET_TX_PQM_MAL_TYPE_S; > > > > queue =3D (reg & GL_MDET_TX_PQM_QNUM_M) >> > > > > GL_MDET_TX_PQM_QNUM_S; > > > > > > > > PMD_DRV_LOG(WARNING, "Malicious Driver Detect= ion event " > > > > - "%d by PQM on TX queue %d PF# %d"= , > > > > - event, queue, pf_num); > > > > + "%d by PQM on TX queue %d PF# %d = VF# %d", > > > > + event, queue, pf_num, vf_num); > > > > } > > > > > > > Would this output be misleading in the case where there is no VF invo= lved > > > and the actual MDD error comes from the PF? > > > > I will check, but IIRC, the queue here is an "absolute" queue number > > that should help figure out whether it is the PF or a VF in the case > > vf_num =3D=3D 0. > > > Yes, that is my understanding too. Maybe in future we can use the queue > number to identify if it's a VF of not. If the PF is the error cause, I > think the VF details should be omitted. IIUC there is a set of other registers (per PF and per VF) that would make it easier to point and blame. On the other hand, such a change seems more risky to me and I would prefer someone from Intel owns it :-). I'll go back with simply adding the TXPDU check which already helped me understand where to look when debugging. --=20 David Marchand