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 00B15A00C2; Thu, 8 Dec 2022 23:15:18 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9016240E28; Thu, 8 Dec 2022 23:15:18 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 321C140685 for ; Thu, 8 Dec 2022 23:15:17 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 71A4B20B6C40; Thu, 8 Dec 2022 14:15:16 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 71A4B20B6C40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1670537716; bh=1fKoSb0PcMpaMZocT9S1qtjiVxAha1IZg9dDS0ICmdk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oUlWT1artUkM6IpN0Jh/bW8VN+pwAQkYTYH5sUb9NuIIoQ3FeBMh/hbcy40cVhtBz 2kxCms3MgmJsJW34OwRZ4G/Wcos9BF/165XXCRWjBEfGaalNfJz7KMPJe+RUTd5p1O MVZEHzKrS9SHQE/n7Z9Av9GK0c+Tt4AAZKmppBLU= Date: Thu, 8 Dec 2022 14:15:16 -0800 From: Tyler Retzlaff To: Mattias =?iso-8859-1?Q?R=F6nnblom?= Cc: dev@dpdk.org, thomas@monjalon.net, david.marchand@redhat.com, stephen@networkplumber.org, olivier.matz@6wind.com, mb@smartsharesystems.com Subject: Re: [PATCH v2 1/3] eal: add rte control thread create API Message-ID: <20221208221516.GA6209@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1670271868-11364-1-git-send-email-roretzla@linux.microsoft.com> <1670347706-23802-1-git-send-email-roretzla@linux.microsoft.com> <1670347706-23802-2-git-send-email-roretzla@linux.microsoft.com> <5b080d72-f7a8-232d-86a1-9164a005fcfb@lysator.liu.se> <20221207163839.GB14713@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <3e6b1bb8-e97d-17b1-207e-ef9d0447480d@lysator.liu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3e6b1bb8-e97d-17b1-207e-ef9d0447480d@lysator.liu.se> User-Agent: Mutt/1.5.21 (2010-09-15) 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 On Thu, Dec 08, 2022 at 10:59:13PM +0100, Mattias Rönnblom wrote: > On 2022-12-07 17:38, Tyler Retzlaff wrote: > > > >> > >>>+ } u; > >>> void *arg; > >>> int ret; > >> > >>Why is 'ret' needed? (This question is unrelated to your patch.) > > > >i'm not the original author so difficult to answer authoritatively. but > >if i have to speculate i'd say it might be to work around the windows > >pthread_join stub being implemented as a noop. specifically it didn't > >communicate the return value from the start_routine. > > > >the recently added rte_thread_join addresses this (which > >rte_control_thread_create uses) and could remove ret parameter and to > >avoid touching the new function implementation in the future it can not > >use ret now. > > > >i'll make this change in v3. > > > >for the original function i will leave the code as is to minimize the > >diff. when rte_ctrl_thread_create is removed i'll make a note to > >eliminate the ret parameter as well. > > > > I would focus on minimizing the complexity of the end result, rather > than the size of the patch. agreed, that's why i decided to leave it as is. more change than is needed right now and simpler to make after the old api is removed. > >>>+ /* Wait for the control thread to initialize successfully */ > >>>+ while ((ctrl_thread_status = > >>>+ __atomic_load_n(¶ms->ctrl_thread_status, > >>>+ __ATOMIC_ACQUIRE)) == CTRL_THREAD_LAUNCHING) { > >>>+ /* Yield the CPU. Using sched_yield call requires maintaining > >>>+ * another implementation for Windows as sched_yield is not > >>>+ * supported on Windows. > >>>+ */ > >> > >>sched_yield() also doesn't necessarily yield the CPU. > > > >copied from original code and understood, but are you requesting a > >change here or just a comment correction? can you offer wording you > >would find suitable? > > > > I would just remove the comment. sounds good, i'll remove it in the next rev. thanks!