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 9B1D0A0C46; Sat, 7 Aug 2021 16:55:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4CD4340691; Sat, 7 Aug 2021 16:55:15 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 69EC24067E for ; Sat, 7 Aug 2021 16:55:13 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D3C165C00B9; Sat, 7 Aug 2021 10:55:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 07 Aug 2021 10:55:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= MJbzPKsLswW0bh2dTAC23i2fp5FcixL+SV2b9gZ+KlY=; b=wVR6vJNxvq35T1gJ F2kwDr1ROmbC+jcyg8Wld94KBOzvS1Zbe/88WWOolMIUK+RZfpjDlG8Th1citUs/ l2zJIT5bRxK4XocCMGmRdpkgvpwMYymNXeTJFcDYpIRDwXkI4Eyl38IwjkN1VA07 UweWDvkXmObV83HVXuXZYXbqbB3Sa07qyCOwMm2J42rBzrhgY97UDxyGK5hOua3r LGFWlMsApJj5BWCHYeZ2PiEntrVyOM8o+wmCNoCqEPd2lafmFozFb1bmSwZJOTXw 4HMniVBecw1lq2jpATHYrT0tI9SJvoEeWTjHcfKYcyW1snfjIQzSRAMahtVKiNFS NcumAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=MJbzPKsLswW0bh2dTAC23i2fp5FcixL+SV2b9gZ+K lY=; b=fKdrY+eRvOvTPxMQgtCF7zSKEJPQKScDS4r1iniggJCiOZbmk9hwKFdgs wPbSWr+m5jvt6QIrtoQCssLnXgs/WNeSZo23ZAGgmhpEfZoqHey2KBkczPZVQYST igD7PSLfO0BouIenIzN3a/0djivorSOVMn3U/qetNgR45fIuqRoy0//MtoXJYiL6 f4gvhfJfySorTmsbm2Z1+gJSB+jHweVNtqWnfnDzj4Qlj5cYE1RpddjXIipxFFZv Ryi5/c0TGHY6Zz9NqsLV2hTomDJNKve4g6j6TIvaMenSunf4wKfYeI0X0PF08EKh JE6AyqjI7/TdbLIozZqnlwlFYZGzQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjeefgdekvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhgggfgtsehtufertd dttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehm ohhnjhgrlhhonhdrnhgvtheqnecuggftrfgrthhtvghrnhepudeggfdvfeduffdtfeegle fghfeukefgfffhueejtdetuedtjeeuieeivdffgeehnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnh gvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 7 Aug 2021 10:55:10 -0400 (EDT) From: Thomas Monjalon To: honnappa.nagarahalli@arm.com Cc: dev@dpdk.org, olivier.matz@6wind.com, lucp.at.work@gmail.com, david.marchand@redhat.com, ruifeng.wang@arm.com, nd@arm.com Date: Sat, 07 Aug 2021 16:55:08 +0200 Message-ID: <7793415.AuWXLK4XGA@thomas> In-Reply-To: <20210730214453.19975-1-honnappa.nagarahalli@arm.com> References: <20210730214453.19975-1-honnappa.nagarahalli@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] doc: abstract the behaviour of rte_ctrl_thread_create 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 Sender: "dev" 30/07/2021 23:44, Honnappa Nagarahalli: > The current expected behaviour of the function rte_ctrl_thread_create > is rigid which makes the implementation of the function complex. > Make the expected behaviour abstract to allow for simplified > implementation. > > With this change, the calls to pthread_setaffinity_np can be moved > to the control thread. This will avoid the use of > pthread_barrier_wait and simplify the synchronization mechanism > between rte_ctrl_thread_create and the calling thread. > > Signed-off-by: Honnappa Nagarahalli > --- > +* eal: The expected behaviour of the function ``rte_ctrl_thread_create`` > + abstracted to allow for simplified implementation. The new behaviour is > + as follows: > + Creates a control thread with the given name. The affinity of the new > + thread is based on the CPU affinity retrieved at the time rte_eal_init() > + was called, the dataplane and service lcores are then excluded. I don't understand what is different of the current API: * Wrapper to pthread_create(), pthread_setname_np() and * pthread_setaffinity_np(). The affinity of the new thread is based * on the CPU affinity retrieved at the time rte_eal_init() was called, * the dataplane and service lcores are then excluded. Anyway, there is not enough meaningful acks.