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 02F26459E0 for ; Fri, 20 Sep 2024 13:02:16 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ED3494342A; Fri, 20 Sep 2024 13:02:15 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id BD77443417 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-37-LglHNBA8P5iBcOg0ZqvMIg-1; Fri, 20 Sep 2024 07:02:12 -0400 X-MC-Unique: LglHNBA8P5iBcOg0ZqvMIg-1 Received: by mail-lf1-f69.google.com with SMTP id 2adb3069b0e04-53658eafe8eso1890966e87.1 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=NL0f5MyxdIcn4cYM9dvwbbNnrlbrgEXNrf4kPYThVIQtNz5Gw0KKB5uCJTqAwxtQjt fQT2wK/OjpS4Sgx1deLrxCBFR3O1g/InS8Zl+l+yQhmLJT9BoHZamRPUsbbD/lRECoEF sXFBuhL/Gdfx73Cv2AXXp/aRiAFtUCEIfBxtBpV+ypDGqpyYkzE7j5LgolwATeaNq73T 3YT1pWSkNXuZRA4ca0Y85MGg4urPg1C0DZlNRLDeCGM/DrOS/fxYWfJo+95dYZ5ARnbJ VaN6CTDTKC2eNL+P715ABt7PS/djy6kNPHdL0B3Daw74iP76v7TL6CdOhTiUuy6ESkcO RZBw== X-Forwarded-Encrypted: i=1; AJvYcCVTNFNS4JkvLp8zQcsxo9PIX+DpnDpYE9Bqrlm3HQJP6U3nqzxGyp0aolgaN6R5es4l1W34Jxc=@dpdk.org X-Gm-Message-State: AOJu0YxHSlhVLEm+f9RPUwJRmktgl1T+L+E7q3B5ZJWUb/ZRayq8d9ls ruOkEDMx/ivvAQQ7wijE/q9dbMp3gF+u9LI1jg05cTPKudio4c3EuoT5RCt1AWRf9k3Dgww3Rbt uVvOq7lBNyxfYaQXFASfo90TnegoWq6ZHgfgSxpSs6sLFWLMtBj4hXDNJh8rxSdq/hDreOuCYTP IEC3DDzaxgKe0BDkqEjsU= X-Received: by 2002:a05:6512:3c8d:b0:52c:e3bd:c70b with SMTP id 2adb3069b0e04-536ac2ce398mr1606364e87.1.1726830130494; 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: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-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