From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 3A7F91B34A for ; Tue, 30 Jan 2018 01:14:54 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D012020C47; Mon, 29 Jan 2018 19:14:53 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 29 Jan 2018 19:14:53 -0500 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=L6YbSts8+nzShsaJLZ08viraoF pFKGtOLG4iV95sT0M=; b=qIFrDkM5ifPy1fDAFgOsLS/vlFo6GRpVQEQmm2HtzX +z1aepgYK5vCuUu/R4vLM5RM2Nc2v6xRipwFbUzAPVJzLdYz10QTNcZJ177QL2y5 7SyZ4uHWdsf7Kh7nt7529P7DOnvZuK/E/sxPPwisusPPkX36uOxPfXJ8leohUEMr A= 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=fm1; bh=L6YbSt s8+nzShsaJLZ08viraoFpFKGtOLG4iV95sT0M=; b=f9KWJqNDYZXla0csYa6lTI fDIcydIug8MVKx1f8dJr3nbzDmk4U+VRZic6YPG1cw0YQedJNPgzMP/dwSBJcwsY DTa2H/SM/Ksfl6hwK/CT+q7dPBiULjQ4xm0NT/1Lre5mrJtn/g9RK5PG9TcQ8fDA QvCJ76dQLpz9E0HTUGBdxgOaKhe8D5Nk8k/TvxdrvtsxZQFVi6xZHaav0VEVIA5i 0gV7bbnElJktZlEkgerswL4OJRYHjzL8Bico+jt47Py4kGAQuDZ9RyBA+yzN5jqM FxsJ03OP8HHIYx08ys20goeaFc+RE0b3BFV6M8nFEikV55Q2JLIesqo8UczBoI5w == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 6FA4A248AF; Mon, 29 Jan 2018 19:14:53 -0500 (EST) From: Thomas Monjalon To: "Guo, Jia" , Bruce Richardson , harry.van.haaren@intel.com Cc: dev@dpdk.org, stephen@networkplumber.org, gaetan.rivet@6wind.com, jingjing.wu@intel.com, motih@mellanox.com, ferruh.yigit@intel.com, konstantin.ananyev@intel.com, shreyansh.jain@nxp.com, helin.zhang@intel.com Date: Tue, 30 Jan 2018 01:14:06 +0100 Message-ID: <2094855.jKUssMJQjQ@xps> In-Reply-To: <4dba572b-38e1-33b8-2009-c7d977b8b012@intel.com> References: <1516248723-16985-3-git-send-email-jia.guo@intel.com> <20180126165340.GA21468@bricha3-MOBL3.ger.corp.intel.com> <4dba572b-38e1-33b8-2009-c7d977b8b012@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH V13 1/3] eal: add uevent monitor api and callback func X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 00:14:54 -0000 27/01/2018 04:48, Guo, Jia: > On 1/27/2018 12:53 AM, Bruce Richardson wrote: > > On Fri, Jan 26, 2018 at 11:49:35AM +0800, Jeff Guo wrote: > >> + ret = rte_service_lcore_add(slcore); > >> + if (ret) { > >> + RTE_LOG(ERR, EAL, "dev event monitor lcore add fail"); > >> + return ret; > >> + } > >> + > > I don't think you should be taking another service core for this purpose > > without the user asking for it. I also don't think service cores is the > > right "tool" for monitoring the epoll. Rather than using a non-blocking > > poll on a service core, I think you should look to reuse the existing > > infrastructure for handling interrupts in the EAL, which relies on a > > separate thread blocked on fd's awaiting input. > > bruce, seems that you might be see the other view of the mountain, so if > service cores tools basically be born to need user knowledge and > control it, and it is no need to add user to control service tool in the > case, i thinks we might not use the existing interrupts infrastructure > because it is the device uevent not interrupt as the same functional > scope , we could use a separate thread which i have used before in v7 > to specialize poll the uevent, please check v7 part to see if it is good. The v7 was using pthread_create, so it was not the right solution. > @tomas, do you agree with that above , or other suggestion, could it be > got agreement all or let it improvement later? I have no issue about using rte_service. I think the other events processing in EAL could use rte_service. Maybe Harry has a different view? My main concerns are: 1/ There is not enough review 2/ The callback lookup is using device name from uevent 3/ There is no reference to the rte_device struct Minor extra requirement: the new __rte_experimental should be used, see http://dpdk.org/commit/77b7b81e32e