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 C72E9A034C for ; Mon, 26 Dec 2022 07:01:37 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BCFC0427EE; Mon, 26 Dec 2022 07:01:37 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 4701D40143; Mon, 26 Dec 2022 07:01:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1672034495; x=1703570495; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t/Wk9Wm7VXBUKx39wXFSBMipB1EPXyDbhPEdNzdGrNw=; b=BmhdT+/EZcfMdd62a0Ymu6a8KgJSt+QdUn7SDewpbp0xAsF/iRKxsu37 duvUrIYmLSuhbWBFwBs4utWBBcB3QCr75V3LBxIMsXALTMCXBLDiark4C nySMXPZGIUdm1K4kp7Y2NEaWkXkt6/f3OZXQ58am3ztULaXSOddOOjMAT DLM8mJhltl7bSzo76LpPna8oViWFv+ehp5Sn0n9pjrDjnRaPvFHl02ulg W2r1ndLu0R4mI523WkmiybPT/Kawhn5nVDEZiXF3AM6eWIzDJtjiwfnNT Urkp5CflZuAvZl958SeF3uGboOIedvnsC/KJuJs1MxIrCWa2zG2OT/khC w==; X-IronPort-AV: E=McAfee;i="6500,9779,10571"; a="347718947" X-IronPort-AV: E=Sophos;i="5.96,274,1665471600"; d="scan'208";a="347718947" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Dec 2022 22:01:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10571"; a="630338341" X-IronPort-AV: E=Sophos;i="5.96,274,1665471600"; d="scan'208";a="630338341" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga006.jf.intel.com with ESMTP; 25 Dec 2022 22:01:33 -0800 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Sun, 25 Dec 2022 22:01:33 -0800 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Sun, 25 Dec 2022 22:01:33 -0800 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.43) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Sun, 25 Dec 2022 22:01:33 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bv+bIUlQyq/YA+TMhePaisHoBVqj9inegjFvOI5O+/+A0LiTvxPNykOTzhBVNCkwdy86oVTsTUNcQRtQfvz1yIg5sMUNxsFq5YgtONPO1srtZAj3ABNBHPKSgOm/IMTEyCEehBeMf5Dz6sstpwluN9lZPIfbwZyZfQWcnLv/Vpz/AQoPDe97OHGQYdFbw+ougfUigDMUa0E491QAPU4qtMxOHvfW24+clnOttVipedWWzB5jeKtD2CoW1Rr2JxbN26ELAHMym7MJ7qtYOLGg/eLPAqEy9lPjl0p9XqiDfdBV4/GD6VvEDKPHFl65XuQYSSoW7KYdK+7/WKd57UU0BA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IRsDQpFv2yi5JsqYDs8P7dmOziKnX0bi6JqRGwOelMg=; b=TZWslebLprEeZLuqkUM5eVE+F1WpoSuS5ogGJmhjUBS4K4nAiCch+IA0Q54Mg80vzlOZdiySxxsEf9oCMT13wvF97bORe0UzQyFVtFvIvLGmv49tNRSYVa6GWXdwtpDbeapAXwDV0urBdAMGMIRlhIil037sj5IkWUqZL1Re9IgDY72fb6tDNpUTjVIucqDCMdiLpwV475/4mcq6Dl5gc6eOgglhzJ+BGbv9aIgP+PXOuDAMeMP2M0rVJCd6eiLZFyLwslMVbEaTqTdXHGqLlHFJrXn/WvyYWijvY6Ou+G6jSItEatV0VnD2wLGCeeARDvS19Z3/ZGuuTdTzbuJbYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from DM4PR11MB5994.namprd11.prod.outlook.com (2603:10b6:8:5d::20) by CH3PR11MB8188.namprd11.prod.outlook.com (2603:10b6:610:15e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5944.16; Mon, 26 Dec 2022 06:01:31 +0000 Received: from DM4PR11MB5994.namprd11.prod.outlook.com ([fe80::4c85:56d0:cb0b:e9ce]) by DM4PR11MB5994.namprd11.prod.outlook.com ([fe80::4c85:56d0:cb0b:e9ce%3]) with mapi id 15.20.5944.012; Mon, 26 Dec 2022 06:01:31 +0000 From: "Zhang, Qi Z" To: Mike Pattrick , "dev@dpdk.org" CC: "thomas@monjalon.net" , "david.marchand@redhat.com" , "Zhou, YidingX" , "ktraynor@redhat.com" , "stable@dpdk.org" Subject: RE: [PATCH v2] net/iavf: add lock for vf commands Thread-Topic: [PATCH v2] net/iavf: add lock for vf commands Thread-Index: AQHZFItaESRl03Dzb0CeYbLcbvSJX65/tMRQ Date: Mon, 26 Dec 2022 06:01:31 +0000 Message-ID: References: <20221220155414.266309-1-mkp@redhat.com> In-Reply-To: <20221220155414.266309-1-mkp@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR11MB5994:EE_|CH3PR11MB8188:EE_ x-ms-office365-filtering-correlation-id: 2a0838ce-0caa-4e43-f128-08dae706a2f8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: T39Wa0trGsKKm/rkZoGK2JPl/MTUnuKb8K9b/fSHVXuNkaEK90ZM5OOvDqj/iyQgije+AhPN8sv5pnf4BpWWdROo/JSQDJDSqMnyLEWcCOcJhJWZqnxDxzY6boPS5rLO1rNLpTPmXZc0GWTzN7lfJd/TN4ewAqDKugXESE1mxvCXJnFEYh9icJg/qeWrY2XVYThxa7cJ7NlZ9FqCsRXXqY1i/d3WUqlys1ksHsDHgRs5R95/t56vT1ewfHblkl4/WUtIiD+4cGlG5psPdPPSycDSHpHuhIRnt9cyPRekiZtpVqxxVyn4TlX0VTp1wsdtDcI9XLJGn1WgG3YbWDrKDjFDH87eOWydA1ZUTD83Nzb3ut7+ZxHy9dt2WXxC/HYdM7BDobexS1iUDH1qI1PxC5xQG1AahPDTnDWNoJ3yxkTa3DnLHCAKInGb8QTILW6wG5GOD8TmUHDg75YoaAr0dnFCuNNbNlY67/lu5BE2DbpJTziSKQn2TCMBMVHAqtoLeMU+htLTdyORlaPaSp9Yhh84iXkkQ6pEUOzrBSjcdqIRUY2M5ovxizI7FIJGBpcTVen+KWAoi89X1bYuWrYet2gDLy4UXveUTc51QaxmYvEbtgtQlaeYD6glUq8w7aC7msr51uBCl9GUzYvncv4GI5hiCi23+Q3XPIl3srKOwhfDJzJ780VbC3nMCdE+R5yxSdMyhC1wInO8eyJ8dyinTA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5994.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(39860400002)(136003)(346002)(366004)(396003)(376002)(451199015)(83380400001)(86362001)(38100700002)(82960400001)(122000001)(38070700005)(2906002)(52536014)(41300700001)(8936002)(5660300002)(55016003)(76116006)(478600001)(7696005)(6506007)(26005)(53546011)(9686003)(186003)(4326008)(8676002)(66946007)(71200400001)(54906003)(316002)(110136005)(66556008)(66476007)(64756008)(66446008)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?CTBi9hdh9DwMCEfqV0KmIWZbC+1zq9PqYYm6Msd1m/VHz141rtajk94SqPOT?= =?us-ascii?Q?jsajhzcxLe1MyrxQb7tyfOCISwSFcuiKkCt6BDqVd8Wke8f9i711VSqNdWKt?= =?us-ascii?Q?mtCcQQJC4+rhIeSbwEgoEKpyxQRvkq+Lo1ORCuIHE3q7MrIK++p186/HOgVa?= =?us-ascii?Q?4NT6fYH8CGT0Ckj8752TE+PNvSzrigIJHS7dpscZOG315pz/qsySyh66xdc9?= =?us-ascii?Q?OjGV9Q2TFs9N4HFr69AXyaxsidVs2hDWrLbR6YPqS3DrbfqQc8cUc4XbJj+9?= =?us-ascii?Q?lSSfkmgDSM/+EHBi+hcuGc48bFiLzU3iBrZvVVBRQk8u6pfwGIQgI6ilJvvC?= =?us-ascii?Q?q0rbfpVvvxGpTVDPfqfyVue+B+fRN/jtq2FV21ZYDO9TNsRsI/M6Ei/vGpDd?= =?us-ascii?Q?mPOWodnxNKkJUPIwg84ft93G1TLPm7scWS7Z41vez1EEaw6rAHknnQziXnmU?= =?us-ascii?Q?xSBCUzK4CbNkGkAMjuGW5rIXayBBwR/aQkbTgMDn1aW33NygU5mRily+EKIe?= =?us-ascii?Q?kz1pSDREU7NDZ1yk8U1vdQUaWgvmPRQHKntTbipgV0BS2wpllSuF53yZE0gD?= =?us-ascii?Q?tQ4GGyo1nov2I1xlLRK8q1lKIzVH/99E9VcHLcD95xyITOHCnse2FgSvweyY?= =?us-ascii?Q?HNXAbUfQgwIpZVr93Io6v8s3odxwIcyGgoCNccRk4zJPHFqyxETXsqTmdERU?= =?us-ascii?Q?3cZDsXNt2BWGDdGiTGv69LuNquSeAI0CxG5PHjyugfBxcuST3eqADAojKEC+?= =?us-ascii?Q?1dEyOdoW0X4zooeJ6Qmi/hbNb9bmTI9fmG5beaL997BZIjLL1iN8lGLZYtXe?= =?us-ascii?Q?pcTq/ts3sNhKzdlyAYiIb7Hu3fvnOl05xCNH/OHdbmxl6YAqf2EogAlm50fv?= =?us-ascii?Q?qTvbOuKMyQyuDpZ3O25xGVgol0D4whozbIyTd+092titp6iPxWt8seIv83Hi?= =?us-ascii?Q?+Tea7Kt4Tye7JImgH8i5+vBLggMqvWFc9WssYSW/TENfbQT8URAvE8MmRVN4?= =?us-ascii?Q?Gj0yUF5MF4tSEtfUqQqi+LVcEJSZEtbEy8b9Hf1LVIex1lnDJTJ2cnHCLQCL?= =?us-ascii?Q?5hb8h840tXlNVxZ0D2pmOpr72VZdT4p5MSBpECyojcDS9w7SjkjJ1w3IsQjs?= =?us-ascii?Q?rFLA4/cv1ysD8VwdDUhhfPQPFZXAmZ8OzqkXi2pYEMUTXkNeG/M0gV/iYny1?= =?us-ascii?Q?aIJHzTWnBh/mGTG0THG5/R/BdGbDj1jwpsnILha+BNXh0QJUsunv4Ya8J0hE?= =?us-ascii?Q?Wc/ZffjHhWkYlOOxqU5vbwdKW7jb/U8VPk/dzsnyN43uwOeNKjAJ+rRK9fZO?= =?us-ascii?Q?fzFfMTf0rBV4+jinGhu8GtW90Dq5j0lWzPbOu7nPd/oK7z/Zd/QZU+umD55I?= =?us-ascii?Q?hTkz4PNKOU6VMg/PqtckA3751dXu7FiW8JSTEXAbUw5LWeESc1MAIm70+Joi?= =?us-ascii?Q?VUhJZCWdEQOKLyZL6d2t2qRS1jDZN7kLEukY8tiTVRaxzMrKQXfyBGn4xoxG?= =?us-ascii?Q?rYBCzrEXkSJ5we/Ue0FhTfMMSUNW+CQc7Rq81OxeAR+t6YcJj8L+v2yIgFIH?= =?us-ascii?Q?uWkM0QkEmdSrOxr0jBpzTXvIpvnqLrBUqfgbGoWo?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5994.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a0838ce-0caa-4e43-f128-08dae706a2f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Dec 2022 06:01:31.5921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wnP457TkZHHf6DTVhfwO0v4GGyNSZaewRjJUNyn/YWi13Sn08e/7UD6jAHSRrn3xAe9+ETmrFUPDGSW5D3aF9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB8188 X-OriginatorOrg: intel.com 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 > -----Original Message----- > From: Mike Pattrick > Sent: Tuesday, December 20, 2022 11:54 PM > To: dev@dpdk.org > Cc: Zhang, Qi Z ; thomas@monjalon.net; > david.marchand@redhat.com; Zhou, YidingX ; > ktraynor@redhat.com; Mike Pattrick ; stable@dpdk.org > Subject: [PATCH v2] net/iavf: add lock for vf commands >=20 > iavf admin queue commands aren't thread-safe. Bugs surrounding this issue > can manifest in a variety of ways but frequently pend_cmd is over written= . > Simultaneously executing commands can result in a misconfigured device or > DPDK sleeping in a thread for 2 second. >=20 > Despite this limitation, vf commands may be executed from both > iavf_dev_alarm_handler() in a control thread and the applications main > thread. This is trivial to simulate in the testpmd application by creatin= g a > bond of vf's in active backup mode, and then turning the bond off and the= n > on again repeatedly. >=20 > Previously [1] was proposed as a potential solution, but this commit did = not > resolve all potential issues concerning the admin queue and has been > reverted from the stable branch. I propose adding locks until a more > complete solution is available. >=20 > [1] commit cb5c1b91f76f ("net/iavf: add thread for event callbacks") >=20 > Fixes: 48de41ca11f0 ("net/avf: enable link status update") > Fixes: 84108425054a ("net/iavf: support asynchronous virtual channel > message") > Cc: stable@dpdk.org >=20 > Signed-off-by: Mike Pattrick >=20 > --- >=20 > v2: > - Added locks around some iavf_execute_vf_cmd calls which were missed i= n > v1 > - Changed description to indicate that [1] was only reverted out of the = stable > branch. > --- > drivers/net/iavf/iavf.h | 1 + > drivers/net/iavf/iavf_vchnl.c | 90 +++++++++++++++++++++++++++++++++++ > 2 files changed, 91 insertions(+) >=20 > diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h index > 1edebab8dc..aa18650ffa 100644 > --- a/drivers/net/iavf/iavf.h > +++ b/drivers/net/iavf/iavf.h > @@ -262,6 +262,7 @@ struct iavf_info { > struct iavf_qv_map *qv_map; /* queue vector mapping */ > struct iavf_flow_list flow_list; > rte_spinlock_t flow_ops_lock; > + rte_spinlock_t aq_lock; > struct iavf_parser_list rss_parser_list; > struct iavf_parser_list dist_parser_list; > struct iavf_parser_list ipsec_crypto_parser_list; diff --git > a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c index > f92daf97f2..edb74edcac 100644 > --- a/drivers/net/iavf/iavf_vchnl.c > +++ b/drivers/net/iavf/iavf_vchnl.c > @@ -554,7 +554,9 @@ iavf_enable_vlan_strip(struct iavf_adapter *adapter) > args.in_args_size =3D 0; > args.out_buffer =3D vf->aq_resp; > args.out_size =3D IAVF_AQ_BUF_SZ; > + rte_spinlock_lock(&vf->aq_lock); > ret =3D iavf_execute_vf_cmd(adapter, &args, 0); > + rte_spinlock_unlock(&vf->aq_lock); > if (ret) > PMD_DRV_LOG(ERR, "Failed to execute command of" > " OP_ENABLE_VLAN_STRIPPING"); > @@ -575,7 +577,9 @@ iavf_disable_vlan_strip(struct iavf_adapter *adapter) > args.in_args_size =3D 0; > args.out_buffer =3D vf->aq_resp; > args.out_size =3D IAVF_AQ_BUF_SZ; > + rte_spinlock_lock(&vf->aq_lock); > ret =3D iavf_execute_vf_cmd(adapter, &args, 0); > + rte_spinlock_unlock(&vf->aq_lock); > if (ret) > PMD_DRV_LOG(ERR, "Failed to execute command of" > " OP_DISABLE_VLAN_STRIPPING"); > @@ -604,7 +608,9 @@ iavf_check_api_version(struct iavf_adapter *adapter) > args.out_buffer =3D vf->aq_resp; > args.out_size =3D IAVF_AQ_BUF_SZ; >=20 > + rte_spinlock_lock(&vf->aq_lock); > err =3D iavf_execute_vf_cmd(adapter, &args, 0); > + rte_spinlock_unlock(&vf->aq_lock); Instead of wrapping lock and unlock every place, can we add a new wrap func= tion e.g.: iavf_execute_vf_cmd_safe?=20