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 21181A00C2; Sun, 20 Feb 2022 22:56:09 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A15734068C; Sun, 20 Feb 2022 22:56:08 +0100 (CET) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by mails.dpdk.org (Postfix) with ESMTP id ACFB340395 for ; Sun, 20 Feb 2022 22:56:07 +0100 (CET) Received: by mail-lf1-f41.google.com with SMTP id j7so15205144lfu.6 for ; Sun, 20 Feb 2022 13:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1NW4eF5x3X+v4WPbgvlLUtP6DsLxZu1VQwPsAMFLiX8=; b=Tp5rz5u5sKxyvJbjZnSwQEG3Pv/7Rwz4JIZF2qNm9vfyHcEBR4AHXlF6kMWwxR/w9J YCV/2h6PmjcIWqWHcEzUhefpi6VPfDWAO1sRWs92AyMxFMV5oOoHn0b8xUSljiKqHCA+ bc+ROQdRmbWn5P3KyrjuXCuoXLYkIASoAUj02/m6xdJe7z78IAKNjTppKsnV+gcadlP7 GRpEL9AQTvqFvPe/IVUTfOSdt/afEvzjuJ5laB8RLZ0Vg4GPn+2LP+AH3A/axWW9T/QG Do2lmo5ohNxQoDltyeGUijAYw4+9smm1AFilM9zRYPOszSVKuq9HAUWSRjRCSvvfhU1M Xm2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1NW4eF5x3X+v4WPbgvlLUtP6DsLxZu1VQwPsAMFLiX8=; b=4eYG8cK+84SZ3C8b7jKR2973hZW+VCVCe0aVJ/J/gltq9u7z2UpO1M8a8BGFIBG6Yd OY7eMXqnHckhQRweQ+crw+EFbqpLNE3Jf5UMOsDNi4boVCi9i/mP77FfhimFICMkvpgn KkLCG1NNGReKM6JbIJpe06dWQQ5J37hUuVLQT1K4OHB2bZZd82H2EpikUP3OfoqBK88O Xq+dMq0hLZZFuELRhoXYNJoO0M3Dzc3nTZ1zcK1q6TFuy3GMpSb+FWtGs2OW46qYQsRe 9XxY49VnPe9Pu1jNzgFeqeJs3NT5QFHx2Frip2u0vT/jT9kfWhQ+FIxhketXbeGb9kA8 a/nA== X-Gm-Message-State: AOAM530Ffy7YOeJ5Lvr0mMcuqCjyfTHAl/GKQRLv3Q8nwg1a+htfsAB8 /NY4wAV7jaNoPAL7ChsxRMQ= X-Google-Smtp-Source: ABdhPJzxZ+1OrsOXQLLNuZ7ljVqFO8jcdwZoLRpG5iIfvs7mJ+5IqWk4LfdP3Mf+LjaKq+o1p6evbw== X-Received: by 2002:a05:6512:3c9b:b0:440:10a2:dc11 with SMTP id h27-20020a0565123c9b00b0044010a2dc11mr11656104lfv.584.1645394167032; Sun, 20 Feb 2022 13:56:07 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id m18sm986362ljg.48.2022.02.20.13.56.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Feb 2022 13:56:06 -0800 (PST) Date: Mon, 21 Feb 2022 00:56:05 +0300 From: Dmitry Kozlyuk To: "Ananyev, Konstantin" 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 Message-ID: <20220221005605.3c11746e@sovereign> In-Reply-To: References: <20220209024755.GA9377@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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 = 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 pthread > > one. Still, we want ABI compatibility and same thread behavior between > > platforms. The most elegant solution we found was the current representation, > > 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 change, it would break all the Windows user space. Naty, DmitryM, Tyler, what do you think?