From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 015FAA05D3 for ; Tue, 23 Apr 2019 05:39:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7C0391B4BE; Tue, 23 Apr 2019 05:39:16 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id EDA221B4A8; Tue, 23 Apr 2019 05:39:13 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Apr 2019 20:39:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,384,1549958400"; d="scan'208";a="142782826" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga008.fm.intel.com with ESMTP; 22 Apr 2019 20:39:13 -0700 Received: from fmsmsx124.amr.corp.intel.com (10.18.125.39) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Apr 2019 20:39:12 -0700 Received: from shsmsx106.ccr.corp.intel.com (10.239.4.159) by fmsmsx124.amr.corp.intel.com (10.18.125.39) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Apr 2019 20:39:12 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.93]) by SHSMSX106.ccr.corp.intel.com ([169.254.10.21]) with mapi id 14.03.0415.000; Tue, 23 Apr 2019 11:39:10 +0800 From: "Zhang, Qi Z" To: wangyunjian , "Ananyev, Konstantin" , "dev@dpdk.org" CC: xudingke , "stable@dpdk.org" , "Lilijun (Jerry, Cloud Networking)" , "Zhang, Jerry" Thread-Topic: [dpdk-dev] [PATCH] net/i40e: fix crash when calling i40e_vsi_delete_mac Thread-Index: AQHU84XELEjJ7mozyEqo2B31/UrMyKY9hIAAgAuff2A= Date: Tue, 23 Apr 2019 03:39:10 +0000 Message-ID: <039ED4275CED7440929022BC67E706115336E6A6@SHSMSX103.ccr.corp.intel.com> References: <1555149291-12432-1-git-send-email-wangyunjian@huawei.com> <2601191342CEEE43887BDE71AB9772580148A97E3D@irsmsx105.ger.corp.intel.com> <34EFBCA9F01B0748BEB6B629CE643AE60CAACBA7@DGGEMM533-MBX.china.huawei.com> In-Reply-To: <34EFBCA9F01B0748BEB6B629CE643AE60CAACBA7@DGGEMM533-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2E0ZjJmYmUtYzYzMS00Mjk1LWE1NGUtNmI0M2NmNWEyZjdkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQTFGQ01FZktHQ2FxRGoybVBtdUxaU202ZXV0MzVkZFN1ZnZuOVcxNW9TNm5MNDgzT3JSbDZVUHFMdTQ0cDlFTSJ9 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="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix crash when calling i40e_vsi_delete_mac 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" Message-ID: <20190423033910.lH8i0EM5TA4U6ZYeJMudxZEnhW1lJY1_hDD6RcWERAI@z> > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of wangyunjian > Sent: Tuesday, April 16, 2019 10:05 AM > To: Ananyev, Konstantin ; dev@dpdk.org > Cc: xudingke ; stable@dpdk.org; Lilijun (Jerry, > Cloud Networking) ; Zhang, Jerry > > Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix crash when calling > i40e_vsi_delete_mac >=20 > > > > That is not specific to i40e or macvlan filter. > > If inside your app several threads concurrently access/modify NIC > > config, then you need to provide some synchronization mechanism for > them. > > DPDK ethdev API (as most others) on itself doesn't provide any > > synchronization, leaving it up to the upper layer to choose the most > > appropriate one. > > Konstantin >=20 > Thanks. Now the lsc thread isn't controled by the upper layer. > Do you have any idea to fix it? What do you mean "the lsc thread isn't controlled by the upper layer"? you may invoke ethdev APIs in LSC callback function, and use some lock to p= revent race condition, >=20 > Thanks, > Yunjian