From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id AEE1F4C76 for <dev@dpdk.org>; Wed, 28 Mar 2018 09:29:54 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2B9F620E54; Wed, 28 Mar 2018 03:29:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 28 Mar 2018 03:29:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=EvzvMCL1z70QbC5D+NNE3b91ga ai9vV6IVXwso1hb7E=; b=WqcmlWMU4QCTBFBtGg1fopF7z1zK4rBYyHeRT0cKU5 fFqsWs6okt1js1RdgX2/FH6pTyLk4XVa3FF8eb5iVXGl/IddChkunS8yLGt274oy OpoSFtgBR+d1jcGbpOE2VkRIta2uwkgSpJPSUpSnXlukXO0NoeGF4Ch+KSRXrEUt s= 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=EvzvMC L1z70QbC5D+NNE3b91gaai9vV6IVXwso1hb7E=; b=alVGWm+TFXU78tXc5Moer5 qQcAmPVbO7WPtUIfMV9x1ecFY3JjsTpG5OnFPKDVTvdcp42vXfXRwn/WQwhn+y9a MeZUPO70mOcJF68uYSCphFVLJJZse9FfEyJHu+a8N6T42SIPkesvcBxSjf94+YzL ooZKm5OtzkfpYaDk4E/077KWhlaVd6ZdXCZa9Eom/92XTd7ny3O6Wt0Gckt0R9j7 c9PWvc82Oqg4Va+mx/IKLFAZ2NThXePQn686idjbBGoQ2er2B/O34PcosXsCv454 oW92WSHK8/vsIkgGjCMvs+XMJXNKYxNPzn4nYnuCKXrbm9fBaith0L8DVGJ8wvMg == X-ME-Sender: <xms:ckS7WtEprH4bklnv9xitfQ9fVQAWyo-iPMVosl_qEu09KGHsNWSFng> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 5EF8210259; Wed, 28 Mar 2018 03:29:53 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Tan, Jianfeng" <jianfeng.tan@intel.com> Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "Van Haaren, Harry" <harry.van.haaren@intel.com> Date: Wed, 28 Mar 2018 09:29:35 +0200 Message-ID: <2563064.olffpIeeN1@xps> In-Reply-To: <ED26CBA2FAD1BF48A8719AEF02201E36514A9BC0@SHSMSX103.ccr.corp.intel.com> References: <cde1ac06bc0f7e6193df6582d8b8a3b62fe51d09.1522159146.git.anatoly.burakov@intel.com> <3396888.LEadjR7LpM@xps> <ED26CBA2FAD1BF48A8719AEF02201E36514A9BC0@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6 2/2] eal: add asynchronous request API to DPDK IPC X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 28 Mar 2018 07:29:55 -0000 28/03/2018 04:08, Tan, Jianfeng: > Hi Thomas , > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 27/03/2018 15:59, Anatoly Burakov: > > > Under the hood, we create a separate thread to deal with replies to > > > asynchronous requests, that will just wait to be notified by the > > > main thread, or woken up on a timer. > > > > I really don't like that a library is creating a thread. > > We don't even know where the thread is created (which core). > > Can it be a rte_service? or in the interrupt thread? > > Agree that we'd better not adding so many threads in a library. > > I was considering to merge all the threads into the interrupt thread, however, we don't have an interrupt thread in freebsd. Further, we don't implement alarm API in freebsd. That's why I tend to current implementation, and optimize it later. I would prefer we improve the current code now instead of polluting more with more uncontrolled threads. > For rte_service, it may be not a good idea to reply on it as it needs explicit API calls to setup. I don't see the issue of the explicit API. The IPC is a new service.