From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <bruce.richardson@intel.com> Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id CA8BC2661 for <dev@dpdk.org>; Mon, 13 Aug 2018 11:27:11 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Aug 2018 02:27:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,232,1531810800"; d="scan'208";a="64484631" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.107]) by orsmga007.jf.intel.com with SMTP; 13 Aug 2018 02:27:07 -0700 Received: by (sSMTP sendmail emulation); Mon, 13 Aug 2018 10:27:06 +0100 Date: Mon, 13 Aug 2018 10:27:05 +0100 From: Bruce Richardson <bruce.richardson@intel.com> To: "Joseph, Anoob" <Anoob.Joseph@caviumnetworks.com> Cc: Thomas Monjalon <thomas@monjalon.net>, "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, Jerin Jacob <jerin.jacob@caviumnetworks.com>, Stephen Hemminger <stephen@networkplumber.org>, "dev@dpdk.org" <dev@dpdk.org>, Narayana Prasad <narayanaprasad.athreya@caviumnetworks.com>, Hemant Agrawal <hemant.agrawal@nxp.com>, Sunil Kumar Kori <sunil.kori@nxp.com>, "Rao, Nikhil" <nikhil.rao@intel.com> Message-ID: <20180813092705.GA11396@bricha3-MOBL.ger.corp.intel.com> References: <1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com> <1531289248-20025-1-git-send-email-anoob.joseph@caviumnetworks.com> <3685021.sWt9K18E1B@xps> <e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com> <20180801095414.7bc34b30@xeon-e3> <20180801172628.GA471@jerin> <2601191342CEEE43887BDE71AB977258E6D4D959@IRSMSX102.ger.corp.intel.com> <fd4dd899-00b2-b7e3-6acc-29af0571ce2f@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <fd4dd899-00b2-b7e3-6acc-29af0571ce2f@caviumnetworks.com> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions 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://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 13 Aug 2018 09:27:12 -0000 On Mon, Aug 13, 2018 at 12:52:19PM +0530, Joseph, Anoob wrote: > Hi Bruce, Pablo, > > If there are no more issues about the approach, can you review the patches > and give the feedback? > > Please do note that this series doesn't add any event mode specific code. > That will come as a different patch series after incorporating Jerin's > comments. > > Thanks, > Anoob My main concern is with l2fwd, rather than l3fwd, which is already fairly complicated. I could see l3fwd being updated to allow an eventmode without too many problems. With l2fwd, the only issue I have is with the volume of code involved. l2fwd is currently a very simple application which fits in a single file. With these updates it's no longer such a simple, approachable app, rather it becomes one which takes a bit of studying a switching between files to fully understand. The data path is only a very small part of the app, so by adding an event-based path to the same app we have very little code saving. Therefore, I think having a separate l2fwd-eventdev would be better for this case. Two simpler to understand apps is better than one more complicated on IMHO. My 2c. /Bruce > On 02-08-2018 13:49, Ananyev, Konstantin wrote: > > External Email > > > > Hi everyone, > > > > > > > > In order to get this series accepted, we need more discussions > > > > > > with more people involved. > > > > > > So it will miss 18.08. > > > > > > > > > > > > It can be discussed in a more global discussion about examples maintenance. > > > > > > If discussion does not happen, you can request it to the technical board. > > > > > > > > > > > Event dev framework and various adapters enable multiple packet handling > > > > > schemes, as opposed to the traditional polling on queues. But these > > > > > features are not integrated into any established example application. > > > > > There are specific example applications for event dev etc, which can be > > > > > used to analyze an event device or a particular eventdev adapter, but > > > > > there is no standard application which can be used to compare the real > > > > > world performance for a system when it's using event device for packet > > > > > handling and when it's done via polling on queues. > > > > > > > > > > The following patch submitted by Sunil was looking to address this issue > > > > > with l3fwd, > > > > > https://mails.dpdk.org/archives/dev/2018-March/093131.html > > > > > > > > > > Bruce & Jerin reviewed the patch and suggested the addition of helper > > > > > functions to abstract the event mode additions in applications, > > > > > https://mails.dpdk.org/archives/dev/2018-April/096879.html > > > > > > > > > > This effort of adding helper functions for eventmode was taken up > > > > > following the above suggestion. The idea is to add eventmode without > > > > > touching the existing code path. All the eventmode specific additions > > > > > would go into library so that these need not be repeated for every > > > > > application. And since there is no change in the existing code path, > > > > > performance for any vendor should not have any impact with the additions. > > > > > > > > > > The scope of this effort has increased since the submission, as now we > > > > > have Tx adapter as well. Sunil & Konstantin had clarified their > > > > > concerns, and gave green flag to this approach. > > > > > https://mails.dpdk.org/archives/dev/2018-June/105730.html > > > > > https://mails.dpdk.org/archives/dev/2018-July/106453.html > > > > > > > > > > I guess Bruce was opening this question to the community. For compute > > > > > intense applications like ipsec-secgw, eventmode might be the right > > > > > approach in the first place. Such complex applications would need a > > > > > scheduler to perform dynamic load balancing. Addition of eventmode in > > > > > l2fwd was to float around the idea which can then be scaled for more > > > > > complex applications. > > > > > > > > > > If maintainers doesn't have any objection to this, I'm fine with adding > > > > > this in the next release. > > > > > > > > > > Thanks, > > > > > Anoob > > > > It is important that DPDK has good examples of how to use existing > > > > frameworks and libraries. These applications are what most customers > > > > build their applications from and they provide basis for testing. > > > > > > > > The DPDK needs to continue to support multiple usage models. This > > > > is one of its strong points. I would rather leave existing l2fwd > > > > and l3fwd alone and instead make new examples that use the frameworks. > > > > If nothing else haveing l2fwd and l2fwd-eventdev would allow for > > > > performance comparisons. > > > Unlike other applications example, there wont be any change in packet > > > processing functions in eventdev vs poll mode case. Only worker > > > schematics will change and that can be moved to separated files. > > > something like worker_poll.c and worker_event.c and both of them > > > use common packet processing functions using mbuf. > > > > > > The only disadvantage of having separate application would be packet > > > processing code duplication. Which is non trivial for l3fwd, IPSec > > > application IMO. > > Personally I am ok with original design suggestion: > > keep packet processing code common, that would be used by both poll and event modes. > > We could just have a command-line parameter in which mode the app will run. > > Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so). > > Konstantin > > > # Are we fine with code duplication in example application like l3fwd and > > > IPSec? > > > # if yes, Are we fine with keeping l2fwd _as is_ to reduce the > > > complexity and l2fwd-eventdev supports both modes wherever possible? > > > > > > > As the number of examples increases, probably also need to have > > > > a roadmap or decision chart to explain the advangage/disadvantage > > > > of each architecture. > > > > >