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 0B25CA00C4; Mon, 18 Apr 2022 08:42:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ECA4A410E6; Mon, 18 Apr 2022 08:42:00 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 63C3940141 for ; Mon, 18 Apr 2022 08:41:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650264119; x=1681800119; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Oqb0z7puo8FHKO3nf0EXL1kxJ1MWNxfaTfRUwnCy72I=; b=BgPqB772astsRmUEDIrEbhN4olma2OwJj1ip5x7PYBQqDj5Re/xgXfyp Bbz9DdPrTqFnBHmkiSHqVcBfw7JFQxpHEgTNMyvWFoERvnTP8wj66rGtF 7t/MJRwvvn5ebEIGsQ05yHF9YIbbKdx4Yia+hNYiOK04nJUAJVSd5SJ3X 0jmY09y+5m4GQy3z72sMTalVfWM9KsUtMseYpjDoGts4XQwySSRMq775Y gYB/ouhuuP3MIHKg1Yq0giU4FgRuuQ1XSjwBD9TJAlOz3ZCS2SfAAfMwS c0RrrZmOUbSparqYvDw2tAOPNtTmEn5PHiaC07B4NJoGuwwKmBlW+rVy2 A==; X-IronPort-AV: E=McAfee;i="6400,9594,10320"; a="245353933" X-IronPort-AV: E=Sophos;i="5.90,269,1643702400"; d="scan'208";a="245353933" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Apr 2022 23:41:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,269,1643702400"; d="scan'208";a="529402824" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by orsmga002.jf.intel.com with ESMTP; 17 Apr 2022 23:41:58 -0700 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Sun, 17 Apr 2022 23:41:56 -0700 Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by fmsmsx605.amr.corp.intel.com ([10.18.126.85]) with mapi id 15.01.2308.027; Sun, 17 Apr 2022 23:41:56 -0700 From: "Zhang, Qi Z" To: "Zhang, Ke1X" , "Li, Xiaoyun" , "Wu, Jingjing" , "Xing, Beilei" , "dev@dpdk.org" CC: "Zhang, Ke1X" Subject: RE: [PATCH v2] net/iavf: fix iavf crashed on dev_stop when running in multi-process mode Thread-Topic: [PATCH v2] net/iavf: fix iavf crashed on dev_stop when running in multi-process mode Thread-Index: AQHYT+LtoHxi9mWwcU2+K3iwM8pjKaz1PfjQ Date: Mon, 18 Apr 2022 06:41:56 +0000 Message-ID: <8bbb379fea394ddd8c8ad1e6d6e7e47a@intel.com> References: <20220402095120.637740-1-ke1x.zhang@intel.com> <20220414092902.176462-1-ke1x.zhang@intel.com> In-Reply-To: <20220414092902.176462-1-ke1x.zhang@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.6.401.20 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 > -----Original Message----- > From: Ke Zhang > Sent: Thursday, April 14, 2022 5:29 PM > To: Li, Xiaoyun ; Wu, Jingjing ; > Xing, Beilei ; dev@dpdk.org > Cc: Zhang, Ke1X > Subject: [PATCH v2] net/iavf: fix iavf crashed on dev_stop when running i= n > multi-process mode It's not a good practice to take the failure test case as the title, please= describe what actually the patch fixed. e.g.: fix mbuf release function point corrupt in multi-process >=20 > In the multi process environment, the sub process operates on the shared > memory and changes the function pointer of the main process, resulting in > the failure to find the address of the function when main process releasi= ng, > resulting in crash. >=20 > Signed-off-by: Ke Zhang > --- > drivers/net/iavf/iavf_rxtx.c | 31 ++++++++++++++++--------------- > 1 file changed, 16 insertions(+), 15 deletions(-) >=20 > diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c = index > 16e8d021f9..1cef985fcc 100644 > --- a/drivers/net/iavf/iavf_rxtx.c > +++ b/drivers/net/iavf/iavf_rxtx.c > @@ -2822,12 +2822,12 @@ iavf_set_rx_function(struct rte_eth_dev *dev) > if (vf->vf_res->vf_cap_flags & > VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC) > use_flex =3D true; > - > - for (i =3D 0; i < dev->data->nb_rx_queues; i++) { > - rxq =3D dev->data->rx_queues[i]; > - (void)iavf_rxq_vec_setup(rxq); > + if (rte_eal_process_type() =3D=3D RTE_PROC_PRIMARY) { > + for (i =3D 0; i < dev->data->nb_rx_queues; i++) { > + rxq =3D dev->data->rx_queues[i]; > + (void)iavf_rxq_vec_setup(rxq); > + } > } Now, you force rxq->ops only can be owned by primary process, which is not = necessary. Its better we still allow a secondary process to stop a queue (which will c= all rxq->ops)