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 E29BF459D7; Fri, 20 Sep 2024 13:02:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CEE8E43417; Fri, 20 Sep 2024 13:02:14 +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 95ACD427C9 for ; Fri, 20 Sep 2024 13:02:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1726830133; 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=vcI83PLDzDu0alDoMcAR1uH9y224ntwFCWPsiniSOWo=; b=bgKtaACu5LV9FghEAjGOm8Vv9dPg8VyXI9JnBqUYvH68LiyOj+Y7pVQMGkrg/2keuh9RZn XFjXp3ad8t6uS2Y2VXSAVLUH8/GlBlPkVDTEQTjd9Ax+OwAufiK9Y24tdlV5DLgerkUQr0 u4JWHJ5CygyVsZkJJExkDkVEDuMPABo= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-594-p39hnEySOBGgBTYZD1-jrg-1; Fri, 20 Sep 2024 07:02:12 -0400 X-MC-Unique: p39hnEySOBGgBTYZD1-jrg-1 Received: by mail-lf1-f69.google.com with SMTP id 2adb3069b0e04-535699f7a6bso1796932e87.2 for ; Fri, 20 Sep 2024 04:02:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726830130; x=1727434930; 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=vcI83PLDzDu0alDoMcAR1uH9y224ntwFCWPsiniSOWo=; b=ovihKT1ofCl4oIreJMvcJPpBzd53NPuIzV7pobr6ioUeOSOgH2/ekBQ2E5lnlncyXi Ohqbq3hoi1qGnS3Itdk7LP3QLOBJfIBlZMw1BgRNfGZ7QY5VStS2BMM3/rJmNrYp4bT5 JPIngDc0VeI6S9jkM2rf1fHeo4efm4WQq5XFiA3ovINsy1VvxLwvfgU0fKDOKVJ7+rU3 p+s0gAvOU/YUsAzPuA/ZkcWAKlxAjrMkEp0h04XFsYwmYGThKHIllvCHqgmPcktT5Oii BY3AsYIAJKdhiDNVOz0/hjqZDif5jcb9cmcXJma0sYdkkIXqgvfxApDYIYnDwYem1+xg AEbg== X-Gm-Message-State: AOJu0YzQlSQkI9H7s1LygSmBCSHYCF3Ygua4a0RckPMq8j34xPZimkJe WnuXunixj5fTgKfI3vetRht17rzElHnnkKTVanyy+Wn8ZBlsC/2Ptu6e+4iDUPmnMgWgM/jEvij WNosXxlZQXQvBueH2Lk+RTlOk3Hpz5zhddT65mVDiAUPb51tsIQCsAqKdqu7vFyC+kato56YdSr MCLMZnSFhifDv/bUA= X-Received: by 2002:a05:6512:3c8d:b0:52c:e3bd:c70b with SMTP id 2adb3069b0e04-536ac2ce398mr1606361e87.1.1726830130492; Fri, 20 Sep 2024 04:02:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEhnar4BtYpkh17njeNTtwhZl57jf4MIHweE3LFIxt/pNROjY7EuU18GGkDNEw1/HEnZpihyk0zCo9E2I9eINk= X-Received: by 2002:a05:6512:3c8d:b0:52c:e3bd:c70b with SMTP id 2adb3069b0e04-536ac2ce398mr1606337e87.1.1726830130088; Fri, 20 Sep 2024 04:02:10 -0700 (PDT) MIME-Version: 1.0 References: <20240909110356.23757-1-bruce.richardson@intel.com> In-Reply-To: <20240909110356.23757-1-bruce.richardson@intel.com> From: David Marchand Date: Fri, 20 Sep 2024 13:01:58 +0200 Message-ID: Subject: Re: [PATCH] net/iavf: delay VF reset command To: Bruce Richardson Cc: dev@dpdk.org, kaiwenx.deng@intel.com, stable@dpdk.org 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 Mon, Sep 9, 2024 at 1:04=E2=80=AFPM Bruce Richardson wrote: > > Commit 0f9ec0cbd2a9 ("net/iavf: fix VF reset when using DCF"), > introduced a VF-reset adminq call into the reset sequence for iavf. > However, that call was very early in the sequence before other adminq > commands had been sent. > > To delay the VF reset, we can put the message sending in the "dev_close" > function, right before the adminq is shut down, and thereby guaranteeing > that we won't have any subsequent issues with adminq messages. > > In the process of making this change, we can also use the iavf_vf_reset > function from common/iavf, rather than hard-coding the message sending > lower-level calls in the net driver. > > Fixes: e74e1bb6280d ("net/iavf: enable port reset") > Fixes: 0f9ec0cbd2a9 ("net/iavf: fix VF reset when using DCF") > Cc: kaiwenx.deng@intel.com > Cc: stable@dpdk.org > > Signed-off-by: Bruce Richardson I see this patch is already merged, but as I was investigating iavf internals, I remembered this patch and relooked at it. Sending a reset request to the PF while closing the device seems saner to m= e. It also aligns the DPDK iavf driver behavior to the Linux kernel iavf drive= r. Reviewed-by: David Marchand Thanks Bruce. --=20 David Marchand