From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E08BC76188 for ; Tue, 23 Jul 2019 06:56:02 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 091D92190F for ; Tue, 23 Jul 2019 06:56:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 091D92190F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 296B71BF8A; Tue, 23 Jul 2019 08:56:01 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id F26841BF74; Tue, 23 Jul 2019 08:55:59 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2019 23:55:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,298,1559545200"; d="scan'208";a="368770724" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga006.fm.intel.com with ESMTP; 22 Jul 2019 23:55:58 -0700 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 22 Jul 2019 23:55:58 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 22 Jul 2019 23:55:58 -0700 Received: from shsmsx105.ccr.corp.intel.com ([169.254.11.232]) by shsmsx102.ccr.corp.intel.com ([169.254.2.3]) with mapi id 14.03.0439.000; Tue, 23 Jul 2019 14:52:20 +0800 From: "Zhang, Qi Z" To: "Zhu, TaoX" , "Xing, Beilei" CC: "dev@dpdk.org" , "stable@dpdk.org" Thread-Topic: [PATCH v2] net/i40e: fix request queue fail in VF Thread-Index: AQHVPeDm0G9PpOVTBkuXpDupRRGDTabXxCiQ Date: Tue, 23 Jul 2019 06:52:20 +0000 Message-ID: <039ED4275CED7440929022BC67E7061153D6B677@SHSMSX105.ccr.corp.intel.com> References: <20190718145351.13987-1-taox.zhu@intel.com> <20190719031804.7392-1-taox.zhu@intel.com> In-Reply-To: <20190719031804.7392-1-taox.zhu@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNmU1ODAxNTctNzFlMy00NjY3LTkzMzQtMTgzZmZiODYyYWY0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiOTMrK1NzYlkrMmErSDM1UlZ1Yk44Q2ErVWpTRlZBR0owODM3V0VQQXhOeTMxVit5aDFsM0pTNXg0QmtHY0FEVSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2] net/i40e: fix request queue fail in VF X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Zhu, TaoX > Sent: Friday, July 19, 2019 11:18 AM > To: Xing, Beilei ; Zhang, Qi Z > Cc: dev@dpdk.org; Zhu, TaoX ; stable@dpdk.org > Subject: [PATCH v2] net/i40e: fix request queue fail in VF >=20 > From: Zhu Tao >=20 > When the VF configuration is larger than the number of queues reserved by= PF, > VF sends the request queue command through admin queue. When PF > received this command, it may reset the VF and send a notification before > resetting. If this notification is read by the timed task alarm, Task req= uest > queue will lost notification. This patch Mark vf_reset, pend_msg flag jus= t as > task request queue has received notification in task alarm. >=20 > Fixes: 864a800d70 ("net/i40e: remove VF interrupt handler") > Fixes: ee653bd800 ("net/i40e: determine number of queues per VF at run > time") > Cc: stable@dpdk.org >=20 > Signed-off-by: Zhu Tao > --- > drivers/net/i40e/i40e_ethdev_vf.c | 4 ++++ > 1 file changed, 4 insertions(+) >=20 > diff --git a/drivers/net/i40e/i40e_ethdev_vf.c > b/drivers/net/i40e/i40e_ethdev_vf.c > index 5be32b069..3b9740c08 100644 > --- a/drivers/net/i40e/i40e_ethdev_vf.c > +++ b/drivers/net/i40e/i40e_ethdev_vf.c > @@ -1332,6 +1332,10 @@ i40evf_handle_pf_event(struct rte_eth_dev *dev, > uint8_t *msg, > PMD_DRV_LOG(DEBUG, "VIRTCHNL_EVENT_RESET_IMPENDING > event"); > _rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_RESET, > NULL); > + if (!vf->vf_reset) { > + vf->vf_reset =3D true; > + vf->pend_msg|=3D PFMSG_RESET_IMPENDING; You current solution rely on we can always can get a dummy event after the = VIRTCHNL_EVENT_RESET_IMPENDING event we needed, but I'm not sure if it is g= uaranteed If the issue is due to the race condition between i40evf_execute_vf_cmd and= i40evf_dev_alarm_handler Why not just disable the adminq interrupt before i40evf_request_queues and = enable it back after it? > + } > break; > case VIRTCHNL_EVENT_LINK_CHANGE: > PMD_DRV_LOG(DEBUG, "VIRTCHNL_EVENT_LINK_CHANGE event"); > -- > 2.17.1