From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 7413937A6 for <dev@dpdk.org>; Fri, 30 Jun 2017 15:51:26 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 199DF205FD; Fri, 30 Jun 2017 09:51:26 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 30 Jun 2017 09:51:26 -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:x-sasl-enc; s=mesmtp; bh=Ogjdf+SNGEJn61B +Qvh7zx4vAFRxYbqRRmLshBKoc48=; b=BFD/2VG6P3dSvfp4Ts0g4tkAp28qenv 7ic1btIFirp9uQuu3g0jLz8XnE7soUzMQ3MJPc7QQgFNXzDNwtPePRFd/3n/Y+AR LWnh2T/Mrf3UhqkUOw/B2DmzUwbkJIBiILFJdmHcO/VJKYgnrHoLes/npxiHG44K EwQO0KM6b2ww= 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:x-sasl-enc; s= fm1; bh=Ogjdf+SNGEJn61B+Qvh7zx4vAFRxYbqRRmLshBKoc48=; b=MJqoSt3z YnY+Y5RMn/sAUpHwewmwDU6lt5E+5q8+camhXIab5pEx9jaUB3iexVnBStZ6jzmn 9eQXQ/HTAQLJaVv1/0uwbtIdcqlkVDw26afNfg40Cw5CLcWYGQ2RkpLra4/XkOuk 9xKxwQ3NZV3XIWnlfB0wFvGuw065KMFiachpLO77138KADZJDszoxuwWKXAAZ11F xGNO6+qP2QzmfdACdtcurn0Vp/+IOZc3v2DQYftqzJ7H5N1k81p3XsFR6ujCpJSu lzHL6zhQFbGoWVdNc5FpZrWoOyBRLHu4kjI3Z0qDLHPUk3Tv+0MpgrOBiJwxZmih AdMKsbxUQK4RUw== X-ME-Sender: <xms:XldWWZjxmrAVpHkOfsEEmy_9cv07MkzjYeA0dZJjEJadf9SM5uQN7g> X-Sasl-enc: BfPgzuRfN9t21rPKnI7Ta49QnD2xeX8cCu269Kqk1AIi 1498830685 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C1FE77E755; Fri, 30 Jun 2017 09:51:25 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Van Haaren, Harry" <harry.van.haaren@intel.com> Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "Richardson, Bruce" <bruce.richardson@intel.com>, dev@dpdk.org, "Wiles, Keith" <keith.wiles@intel.com> Date: Fri, 30 Jun 2017 15:51:25 +0200 Message-ID: <13779354.Liqf8ceSdn@xps> In-Reply-To: <E923DB57A917B54B9182A2E928D00FA640C34846@IRSMSX102.ger.corp.intel.com> References: <E923DB57A917B54B9182A2E928D00FA640C33E88@IRSMSX102.ger.corp.intel.com> <20170630132054.GC4578@jerin> <E923DB57A917B54B9182A2E928D00FA640C34846@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] Service lcores and Application lcores X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://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: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 30 Jun 2017 13:51:26 -0000 30/06/2017 15:24, Van Haaren, Harry: > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > From: "Van Haaren, Harry" <harry.van.haaren@intel.com> > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > From: "Van Haaren, Harry" <harry.van.haaren@intel.com> > > > <snip previous non-related items> > > > > > > > > I don't think providing a remote-launch API is actually beneficial. Remote-launching > > a > > > > single service > > > > > is equivalent to adding that lcore as a service-core, and mapping it to just that > > single > > > > service. > > > > > The advantage of adding it as a service core, is future-proofing for if more > > services > > > > need to be added > > > > > to that core in future, and statistics of the service core infrastructure. A > > convenience > > > > API could be > > > > > provided to perform the core_add(), service_start(), enable_on_service() and > > > > core_start() APIs in one. > > > > > > > > > > Also, the remote_launch API doesn't solve the original problem - what if an > > application > > > > lcore wishes > > > > > to run one iteration of a service "manually". The remote_launch style API does not > > solve > > > > this problem. > > > > > > > > Agree with problem statement. But, remote_launch() operates on lcores not on > > > > not necessary on 1:1 mapped physical cores. > > > > > > > > By introducing "rte_service_iterate", We are creating a parallel infrastructure to > > > > run the service on non DPDK service lcores aka normal lcores. > > > > Is this really required? Is there any real advantage for > > > > application not use builtin service lcore infrastructure, rather than iterating over > > > > "rte_service_iterate" and run on normal lcores. If we really want to mux > > > > a physical core to N lcore, EAL already provides that in the form of threads. > > > > > > > > I think, providing too many parallel options for the same use case may be > > > > a overkill. > > > > > > > > Just my 2c. > > > > > > > > > The use-case that the rte_service_iterate() caters for is one where the application > > > wishes to run a service on an "ordinary app lcore", together with an application > > workload. > > > > > > For example, the eventdev-scheduler and one worker can be run on the same lcore. If the > > schedule() running thread *must* be a service lcore, we would not be able to also use that > > lcore as an application worker core. > > > > > > That was my motivation for adding this API, I do agree with you above; it is a second > > "parallel" method to run a service. I think there's enough value in enabling the use-case > > as per example above to add it. > > > > > > > > > Do you see enough value in the use-case above to add the API? > > > > The above use case can be realized like --lcores='(0-1)@1'(Two lcore on > > an physical core). I believe, application writers never want to write a > > code based on specific number of cores available in the system. If they > > do then they will be stuck on running on another environment and too > > many combination to address. > > Good point. > > > For me it complicates service lcore usage. But someone think, it will useful then > > I don't have strong objection. > > We can easily add APIs later - and removing them isn't so easy. +1 from me leave it out for now, and we can see about adding it for 17.11 if the need arises. > > Thanks for your input, I'll spin a v3 without the rte_service_iterate() function, and that should be it then! I agree to leave it and keep things simple.