From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 257B9A0487 for ; Wed, 3 Jul 2019 10:55:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1FBB71B951; Wed, 3 Jul 2019 10:51:30 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id 0C96958C4; Wed, 3 Jul 2019 10:51:28 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 940B9E91; Wed, 3 Jul 2019 04:51:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 03 Jul 2019 04:51:28 -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=mesmtp; bh=ljS//lSrvx6qcT5SDKY4kD18Unl5N65bbZ+Tj1obUUs=; b=Xs0K0uoZzG0v aLhK9SK61AVZoPH9XmZ5zo9f0AASqWsxw64Ivic7by27Onuy3Ta9+YRweCQDy7GZ F6PBIJw+PQo38pO16YZTZkML31C0ZJixIIjY8IbbsL2yd1udCEasUwWa7iOaakRO tDMXDM2CUUscnxuajgiTqTYnq8gWpxc= 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=ljS//lSrvx6qcT5SDKY4kD18Unl5N65bbZ+Tj1obU Us=; b=UoZTwA8qZw7AbxjUHRJlXTpmp534imQKkJSWGcdpGyEQg1QT1eDHig9bK YGC4VtVZ2Qq7wvInlwDRx1PRAh65BLA1k7gH3ejXOordz6L0JBejs8ngEvSrFa5I qSGOnQ5SgacomTEDJdw7DXLFVaGHSZyxclRf0k8zvFA7TWlJb2Xt4qqwNo6IiZQW zRfAjWAv7/fpQGLDzT8BNIGydhQeve6UvvzOtGV1zZPEKlIFmGAcuRdNO5wqPo5w Vm/HHLDXQFc9KALFCwS0FpRwY13lUnveAe4IFxGZKm8FY/T0k3Hu/hTYVkybDGBj iya2tSdI8Z64PJNMjvjKBXtsmyVuQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrfedtgddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id EC526380089; Wed, 3 Jul 2019 04:51:25 -0400 (EDT) From: Thomas Monjalon To: Anoob Joseph Cc: Mattias =?ISO-8859-1?Q?R=F6nnblom?= , Bruce Richardson , Jerin Jacob Kollanukkaran , "dev@dpdk.org" , Nikhil Rao , Erik Gabriel Carrillo , Abhinandan Gujjar , Pablo de Lara , Narayana Prasad Raju Athreya , Lukas Bartosik , Pavan Nikhilesh Bhagavatula , Hemant Agrawal , Nipun Gupta , Harry van Haaren , Liang Ma , "techboard@dpdk.org" Date: Wed, 03 Jul 2019 10:51:24 +0200 Message-ID: <1729509.9S1lrLiWIz@xps> In-Reply-To: References: <27d46871-fa0c-1144-b7fa-8c57154478b3@ericsson.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 03/07/2019 03:35, Anoob Joseph: > From: Mattias R=F6nnblom > > On 2019-07-02 18:18, Anoob Joseph wrote: > > >> For what exactly is being proposed, is there a short version of the = suggested > > approach and the logic behind it? > > >> I think eventdev should be simple to use and could be added to any > > >> example like l2fwd. The idea of forking an example, where we should > > >> be able to have an unified API, is a proof of failure. > > > > > > As Mattias had mentioned earlier, eventdev is complicated because of a > > reason. It exposes lot of configuration which can be used to dynamicall= y load- > > balance real world traffic. With various adapters like, Rx adapter, Tx = adapter, > > crypto adapter etc getting implemented, applications can better utilize > > capabilities of event device. But all the existing example applications= in DPDK is > > designed around mbufs and polling of cores on various devices. If an ap= plication > > has to fully leverage capabilities of an event device, it has to setup = all these > > adapters and devices. And, as Mattias had mentioned, this involves lot = of > > configuration. This configuration would be repeated for every applicati= on which > > would need to run in eventmode. Eventmode helper abstracts this. > >=20 > > A question I asked myself when I had a look at the patch set is: does e= ventmode > > really abstract processing pipeline configuration, or is it merely maki= ng a bunch > > of assumptions and hard-coding a bunch of configuration parameters. > >=20 > > Merely reducing flexibility doesn't qualify as abstraction, I would say. >=20 > [Anoob] The idea is not to remove flexibility. > All options of adapters would be exposed as command line > args/ config file. For the first version, I didn't add it > because it would exponentially increase the code. You neither added it, nor explained it will come. That's the main issue here: we are missing the big picture because you did not write a clear explanation in the cover letter. > > > For an existing application to be moved to eventmode, all it would t= ake is > > couple of function calls and fine-tuned worker thread. > >=20 > > If you want to use eventdev as a very complex implementation of softwar= e RSS, > > sure. > >=20 > > If you have a problem which solution requires a multi-stage pipeline, g= oing from > > a run-to-completion model to a scheduled pipeline is going to have a bi= g impact > > on your code base, and eventdev configuration will be a relatively mino= r part of > > the work, in the typical case, I would expect. >=20 > [Anoob] Why do you say this approach cannot work in multi stage > environment? You need to increase the number of event ports & queues > as required (using command line args). Few ports & queues would be > used by Rx adapter & Tx adapter. Rest will be available for the > application to do the multi-stage pipeline. >=20 > Also, for some applications, this complexity is not needed. > Say, for l2fwd, none of this complexity is needed. > When we attempt ipsec-secgw, multi-stage might come into picture. Again, we need to get the big picture. If you are trying to achieve a processing pipeline, why not using Packet Framework (librte_pipeline)? > > > Just to remind, this is the 3rd iteration of submitting patches. The = first set of > > patches were submitted by Sunil Kori from NXP and that involved additio= ns in > > l3fwd application. It involved addition of lot of code, and Bruce wante= d to make > > the additions common. Jerin suggested to add these in event dev library. > > > > > > The second iteration involved additions in l2fwd and introduced event= mode in > > eventdev library. Then it was up for discussions again and it was decid= ed that for > > l2fwd, a new application for eventmode would be drafted, but for l3fwd = & ipsec- > > secgw, the original application would get additions. L2fwd-event will b= e used to > > finalize the event-mode library before extending to other applications. > > > > > > Now this is the third iteration. > >=20 > > What is your point? >=20 > [Anoob] We had been doing back and forth regarding approaches. > If applications like l2fwd, l3fwd, ipsec-secgw etc shouldn't deal > with events, it could've been decided in the first submission itself. You cannot blame us. Yes we want this model to be demonstrated in examples. And we try to understand how it can be efficient for the user, but we are missing the big picture. At every iteration we get parts of the explanations, so we give some recommendations based on what we understand. > > >> About the helper, I see some command line processing and other things > > which have nothing to do in a library. > > >> Actually I fail to understand the global idea of this helper. > > >> There is no description of what this helper is, and even no name for= it. > > > > > > All the eventmode configuration need to be user defined. So either ev= ery > > > application would need the code duplicated (how the code for lcore-po= rt-queue > > > conf required for eth devs is repeated in every app) or be kept commo= n. Again, > > > that can be kept as a separate header and can be copied around. I don= 't see any > > > issue, if you are fine with it. User configuration may be defined differently in every applications. If something is *really* common to all applications, why it is not in eventdev library from the beginning? > > OK, so in real-world applications, duplicating eventdev configuration i= s not a > > major concern. You will have very few applications, and if they have a = similar > > structure, you can reuse your proprietary framework. If they don't, no = big deal. > > Just an additional 1% of application code to maintain. > >=20 > > For the DPDK example applications, the situation is very different. Man= y trivial > > applications with a similar structure. I'm sure solving the framework p= roblem for > > this subset of applications is easier, but I would expect such a librar= y would have > > limited value outside the realm of the example directory. Although it m= ight make > > the DPDK example code base more maintainable, my fear is that it'll jus= t confuse > > the reader of the example applications. Now they have to understand a > > framework *and* an application, and not only the example application. A= dd to > > this that the framework you just spent time understanding will also not= provide - > > at least not in its current form - a good foundation for non-trivial ap= plications. > >=20 > > The DPDK APIs shouldn't be optimized for example applications. >=20 > [Anoob] Initially the target would be only DPDK applications. > As I had mentioned earlier, I'm dropping the idea of making > this a library/common code. My proposal is to have all the code > in l2fwd-event application itself. > In that case, would you have any problem? No I think that's fine to do whatever you want in this forked example. But remind that you won't be allowed to fork one more example until things are settled down and approved by the technical board. > None of the DPDK APIs would be modified in this effort. >=20 > When Bruce looked at the patches I had submitted to l2fwd, > his opinion was, there is lot of code to just do initialization > & configuration. But here you are saying, that code is very minimal > compared to the applications. > These are all perspectives and I would like to get a consensus.