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 7CA8BA034C; Thu, 24 Feb 2022 18:29:37 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6F0A441143; Thu, 24 Feb 2022 18:29:37 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id BB3424113D for ; Thu, 24 Feb 2022 18:29: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=1645723776; x=1677259776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dqzdOM3hryiZKKeIeAobdeRzWOmsN81LpZubyuyR9VI=; b=JH44EgZp/Jp0NcC8SS3KI37bEIT5J3bOjK9U2+Sa4uk6UoqWggSFDkPf wE2Cr+QvNZBz9ITePpT26Mo150j5/1F7/U5qGCAeTTKsbn44LgOGGYMST Kn1fvOSL/9w2NFpIXWACkvO2K6MZXbnBPiZBId5lrfZfFoYHptWxglOrQ LpGLWe7vlmoWR3rwhAABboKJ4vTEJFCNW1uSCYd66nE5b5IYrud9eSdm7 jAMrrGeQaQOEQKsQNon8RHm36T7jaKexV845BHgFkwMNqcVwsRiK8aY3f n7U3ESDjfl7aGMN4J1XMS0MXnJEToHNRDMxXFqJxUf2TNp8wolzZ9Ztd8 g==; X-IronPort-AV: E=McAfee;i="6200,9189,10268"; a="249879164" X-IronPort-AV: E=Sophos;i="5.90,134,1643702400"; d="scan'208";a="249879164" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Feb 2022 09:29:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,134,1643702400"; d="scan'208";a="639798728" Received: from orsmsx605.amr.corp.intel.com ([10.22.229.18]) by orsmga004.jf.intel.com with ESMTP; 24 Feb 2022 09:29:07 -0800 Received: from orsmsx605.amr.corp.intel.com (10.22.229.18) by ORSMSX605.amr.corp.intel.com (10.22.229.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 24 Feb 2022 09:29:06 -0800 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx605.amr.corp.intel.com (10.22.229.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21 via Frontend Transport; Thu, 24 Feb 2022 09:29:06 -0800 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.40) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.20; Thu, 24 Feb 2022 09:29:06 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BQ+Fj7/GeQ+nF1lmY4xvCG54u/fGzr3LVrCYlhqbmds4TBerzEQplvGH0WfizUjUcgtHaZyOTvPKmoAuLoCmEXHOjtg9yShH+8NR54RZAOHnrOLsEhEHoT/skYV41N1yDuKYclZog+OQ8tjU9TnfqLf7HxN38OduuhExHwnyGox59N0RpZqhx+a2xWwtNyJgVXNlWQzEYCb9HZryGaQnU/M0JnqvovO4LOJsozOWzWJng+wjBQGXn49UDeGl+NHQWWF7Vxk5f1OZcWU0b37rUxby1jG/j6AE8pbJKbsU7nkV0BhMVi2XRRDO+QksKKRA/ITMlzGu4jL+XU2qK8TNKQ== 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=4qS1r+e2J/1shmy0qIDLafvtcutCZEAo9poxchLVZL0=; b=Si87rmvyAy8Hu3Wotn5/XCosVtcbjqy87+GuygmqqNSxySTo2QstE1ohfLT6OPp0ld8QS+P1XR0TDH7rqlhN20NByQu+mn8OfD11a97ZQXpJq6eHfn76On3PdIaXYIDZXlxwrxIY19ayHbpEBt03NttvoWwrIZWQL9PbaUUVN46wRHfz0dXlMsEd0gpzL4WPboAh8wxPzYiouVtcrH2ol5Pmhoh0bV8xhh3WO9mM5tSDfC9zwYI+7TYbx3Z+zUd1yQsqZnQ/17N83EwoB7h/mdCZdS8xwAYt7O3yI5u26jhQG45REh7FqqA8Ajethoy7gNWlFCnYCSfdN6Xkjcbx7A== 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 BY5PR11MB4482.namprd11.prod.outlook.com (2603:10b6:a03:1ca::33) by BN9PR11MB5259.namprd11.prod.outlook.com (2603:10b6:408:134::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22; Thu, 24 Feb 2022 17:29:03 +0000 Received: from BY5PR11MB4482.namprd11.prod.outlook.com ([fe80::91b:df28:d0f3:82b]) by BY5PR11MB4482.namprd11.prod.outlook.com ([fe80::91b:df28:d0f3:82b%7]) with mapi id 15.20.5017.022; Thu, 24 Feb 2022 17:29:03 +0000 From: "Ananyev, Konstantin" To: Dmitry Kozlyuk CC: Narcisa Ana Maria Vasile , "Richardson, Bruce" , "david.marchand@redhat.com" , "dev@dpdk.org" , "dmitrym@microsoft.com" , "khot@microsoft.com" , "navasile@microsoft.com" , "ocardona@microsoft.com" , "Kadam, Pallavi" , "roretzla@microsoft.com" , "talshn@nvidia.com" , "thomas@monjalon.net" Subject: RE: [PATCH v18 8/8] eal: implement functions for mutex management Thread-Topic: [PATCH v18 8/8] eal: implement functions for mutex management Thread-Index: AQHYHJKgDSc+9S1pUkOHtzuhRV7rcayKhbuAgACgGpCAEepWgIAEZsIAgAGNWRA= Date: Thu, 24 Feb 2022 17:29:03 +0000 Message-ID: References: <20220209024755.GA9377@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20220221005605.3c11746e@sovereign> <20220223200854.29910906@sovereign> In-Reply-To: <20220223200854.29910906@sovereign> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.200.16 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1673cd47-35d3-460f-bbb8-08d9f7bb272f x-ms-traffictypediagnostic: BN9PR11MB5259:EE_ x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8rJW6mr/Ob4M5apXn1CT/x+xnso9pdOzbJo5LnCBqwud/DrZO4pPgJsGQYcN6tQc7qW22ID0L9PRZzLh5AANB6i329b9lPlsCd4UoqQob6uKLYJy0ZLTy8/0UqsPL69S/2YJsc9C/u/cV3w7FujfL4czcH1xklQJwYgG3xWYGQ6ez3Gd9jeQzx3ErlavWKBZDz2NeTjYoWEFdmJuK/zhpsoPEQcCjNvlH987n98ydpEuP5JtHws7DpeAUYyJluYwX7IhejJPAbfOkpLpvNMO07qyt/zjWKx7J+Z6QPdHJxg9xuMAHrt6BjJLMAobl0tMwrcuvT/QtZWQ2esD3XuaNP8kzgDVjD/XYZQ73VBAJZ0bOIGTgEf00UAjhx1PlD8CkK7FyT82+IM5Lyl8DC43KJ/h2RTKBrnpVQcA0cAjZ9blzmtnzUWk3lit0ZgeKgMknYMnpQAhmqvKBrgUUFTdrG62t31HMtwFZ4mwg8dYqno3pjHkMo5SfwWRhxaZ06rsYYPyR/f7Rl7irxVNpxsPZHONXmLfcuSVpip6tT2jQo0Tuft6CDqxbAKXMbon4R99cGgtpTPPLpJcmjs7AmdOceeQ1lxnu/bFUuBPQT4Tag/s3aP9ECo/Ic2BNrVvrn56yGC4bLQsSxo/VdBXLs1hPzSAxlLfjoxT+rqE8od6U/CspO2uPRjgyoHSNCTEAEx/QPa5UWmB+GtU4KDmVKDPIMtrabkQIThwIAda4y44HMh32PmgTDW1ZCL8UbptxVROu3/b26Fm7+IKn7mdEFsF92t9Y7dcm/iRhWEeK+YGbv8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4482.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(83380400001)(7696005)(54906003)(6916009)(6506007)(52536014)(5660300002)(7416002)(8936002)(9686003)(508600001)(71200400001)(966005)(64756008)(66446008)(76116006)(316002)(86362001)(38100700002)(66556008)(38070700005)(4326008)(66476007)(2906002)(186003)(122000001)(55016003)(33656002)(82960400001)(66946007)(8676002)(26005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?CMamBtvzFKAcVi/ZnFlEQTK+AAQLwAt44DILfcj7mwaIlG0A/vR/HDi5pwo6?= =?us-ascii?Q?NGuHrk+xbEzlTSNtCuhII7B3fPBihfkBMluCqV5b7nKLYt/QYGbLL0Of2r9O?= =?us-ascii?Q?7BWd3XfRfwcRbDmvEv2eE75GCCaPnfB+Y0zaoQsRz4TtJN4wIEy6HDpX2dGj?= =?us-ascii?Q?fltTgAZSKsq5IWhQ3q3ij7+g2EgRfzS9chjWeQOoyZNV8RgvfDdXLyqEnoJA?= =?us-ascii?Q?mNCW/RYlO2ichgqbIp8ZtzU2IRF+BGyvVVyvN68GmhW6D0X+O2EhpYwwEnSQ?= =?us-ascii?Q?LksOPKZ7VwdxTUGO9HjJjyxHkA9JZmivFuo+VtxwX6l/3PpCgJ/M2z+vrqIU?= =?us-ascii?Q?en/3UeShIqdeDuF2BIcptG7wtRtwYYKd9NGD3LgdhxYDdTUlSpiGlpfIjCjD?= =?us-ascii?Q?QGXZaukmxSxaVrto3rkC0zwuiyleW45iTeUjsrZNh6/WAsl9uUFSQFs+ebjl?= =?us-ascii?Q?srz5NPzUGslOqtfBtDDMBS+aSPjyCSMMdhcDxGAg/DvVg6WQDHwPUDcv+dh6?= =?us-ascii?Q?vQxG6bYhUczynN3JGlcyCnxEoyHnB9KB5Dx12QVNCQJzy2YDKCYWdKz6/qYW?= =?us-ascii?Q?9DKaOMKp1tebcYibaCE5h66M+WFof9p93JajDil2hhWB1WsBh1vAo/JWC6TP?= =?us-ascii?Q?lYK8tMML27TgR3pwqBy5BZPC3GqqqN7arH7Eq+8VwXbyeHDiNzT6Frm1ehii?= =?us-ascii?Q?wgEE8LFHiEOqQLNer6pIgPka1l+zhnKh8g2VduE/KYI8GJQubzGZoa+u/+0f?= =?us-ascii?Q?mYHQ0FBpDpoE3JhEoBPj6UR+s6vNfqTTKLzGhlXmXaKB9jJSuc+MQtVc7qSK?= =?us-ascii?Q?jwT4QqVslz+krUFYtZwkLp/3Q7XhD8FBvD39ZtdmhT1rvTp9u3tbzSBLbfE+?= =?us-ascii?Q?tIJO1rV2oPgwXzFsS1RfUSqnDmXtsotFo2GMAuhfFByF+aD9xdj3OoRqXJJj?= =?us-ascii?Q?m8+0Vk1eSjDeJXFk9jdsm+tFRDBOMGpmfSuHUIcWDkQX8aJFyfp87WePPUx+?= =?us-ascii?Q?Cr9DBjZy1EDMEJZGXISCgN5B2RuVcad4DOMOM5Csa1nvBC2BILzwoxEPsSzY?= =?us-ascii?Q?jsUFZswqYudKL5IcKn4BBVjAHi0dsfNVAM7MfaA8C8WxsmhvKNnRFkpUe8rP?= =?us-ascii?Q?EByasRIniwvvlf1Atgn2fr7T94YAM71Fk9CG0PoD2I5NpCvYxCTPmjE4Vi2F?= =?us-ascii?Q?yPBEcklhTnpio20ekxTVFGm2C8G82hZBeTYLFo2JeclzeCRZwNFJOYZOM9zb?= =?us-ascii?Q?K54FbSIzoM7B7l0HxpqR/vym1SrNGcKzkW4cVz9sLZGgDqPLsVCUWI9FLBCS?= =?us-ascii?Q?L0MSvwbRPmSJm+xHf/76CgQrd6ZQf649TPfFu30wEjkfP17GIRGesxZP9So2?= =?us-ascii?Q?BN8HhI0Vj4/gBR0CLHgp/VcEc1yF4Z4517uos1PBIsnJbA2q/xUjRqZFKYKY?= =?us-ascii?Q?iajRT40r9Z1CsJ5l7PiOifLDATWwLiAgU0YlDe+0mskPM6o+p1IY1es7jehm?= =?us-ascii?Q?0+Xv33Ag1+5H4Jw5VIFPF/4P3/pwUUucpgCiqdFYfiS/kEYjPYV3D8PUvZc9?= =?us-ascii?Q?LOQht1JPPuOKgvQQ/dqR0UaY81waC4b/TLm4KvtYxUZm1YGXK5CmzbALjBb3?= =?us-ascii?Q?XDXMi7iXOH2xeD2vRXnz8AKvqiKUHuzBuaQxnAjC8Vp9TOnaJs8cUPfvAvF4?= =?us-ascii?Q?cwxkDQ=3D=3D?= 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: BY5PR11MB4482.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1673cd47-35d3-460f-bbb8-08d9f7bb272f X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2022 17:29:03.7083 (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: KmxO+a6fNNlsj/HTWXrFs0/VlJbCQmXDJR6ZQ0UBK/1yxGuLWM3O+lIUAxLw0BG8pdjfD5Ffm6QBqB7ugPPIk6QnbVCo5FjHA5Fij35AE1Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR11MB5259 X-OriginatorOrg: intel.com 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 Hi Dmitry, > 2022-02-21 00:56 (UTC+0300), Dmitry Kozlyuk: > > 2022-02-09 13:57 (UTC+0000), Ananyev, Konstantin: > > > > > Actually, please scrap that comment. > > > > > Obviously it wouldn't work for static variables, > > > > > and doesn't make much sense. > > > > > Though few thoughts remain: > > > > > for posix we probably don't need an indirection and > > > > > rte_thread_mutex can be just typedef of pthread_mutex_t. > > > > > also for posix we don't need RTE_INIT constructor for each > > > > > static mutex initialization. > > > > > Something like: > > > > > #define RTE_STATIC_INITIALIZED_MUTEX(mx) \ > > > > > rte_thread_mutex_t mx =3D PTHREAD_MUTEX_INITIALIZER > > > > > should work, I think. > > > > > Konstantin > > > > > > > > Thank you for reviewing, Konstantin! > > > > Some context for the current representation of mutex > > > > can be found in v9, patch 7/10 of this patchset. > > > > > > > > Originally we've typedef'ed the pthread_mutex_t on POSIX, just > > > > like you are suggesting here. > > > > However, on Windows there's no static initializer similar to the pt= hread > > > > one. Still, we want ABI compatibility and same thread behavior betw= een > > > > platforms. The most elegant solution we found was the current repre= sentation, > > > > as suggested by Dmitry K. > > > > > > Yes, I agree it is a problem with Windows for static initializer. > > > But why we can't have different structs typedef for mutex > > > for posix and windows platforms? > > > > Yes, I agree that having different mutex types on *nix and Windows > > is a great idea. It will avoid ABI change for *nix > > and will guarantee no performance impact. > > > > Maybe wrap pthread_mutex_t into a struct to have a distinct type > > and to force using only DPDK API with it? > > > > [...] > > > Yes, on Windows rte_thread_mutex still wouldn't work for MP, > > > but that's the same as with current design. > > > > MP support is not planned for Windows and it is unknown if it ever will= be, > > so it's not an issue. > > Data location is. > > The reason rte_thread_mutex_t is not a typedef of CRITICAL_SECTION > > (akin to pthread_mutex_t) is to avoid including Windows headers > > into DPDK public headers, because Windows headers can break user code > > by some macros they define. > > Maybe instead of a pointer it could be an opaque array: > > > > #define RTE_PTHREAD_MUTEX_SIZE 40 > > > > struct rte_pthread_mutex_t { > > uint8_t opaque[RTE_PTHREAD_MUTEX_SIZE]; > > }; > > > > where RTE_PTHREAD_MUTEX_SIZE is actually sizeof(CRITICAL_SECTION). > > Win32 ABI is remarkably stable, I don't think this constant will ever c= hange, > > it would break all the Windows user space. > > Naty, DmitryM, Tyler, what do you think? >=20 > Conclusion from offline call: yes, this is OK to do so. >=20 > However, DmitryM suggested using Slim Reader-Writer lock (SRW): > https://docs.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--s= rw--locks > instead of CRITICAL_SECTION. > It seems to be a much better option: >=20 > * sizeof(SRWLOCK) =3D=3D 8 (technically "size of a pointer"), > same as sizeof(pthread_mutex_t) on a typical Linux. > Layout of data structures containing rte_thread_mutex_t > can be the same on Windows and Unix, > which simplifies design and promises similar less performance differenc= es. >=20 > * Can be taken by multiple readers and one writer, > which is semantically similar to pthread_mutex_t Not sure I understand you here: pthread_mutex provides only mutually-exclusive lock semantics. For RW lock there exists: pthread_rwlock_t. Off-course you can use rwlock fo exclusive locking too - if all callers will use only writer locks, but usually that's no point to d= o that - mutexes are simpler and faster. That's for posix-like systems, don't know much about Windows environment :) > (CRITICAL_SECTION can only be taken by a single thread). >=20 > Technically it can be a "typedef uintptr_t" or a structure wrapping it. Again can't say much about Windows, but pthread_mutex_t can (and is) bigger then then 8 bytes.=20