From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id C77C21B44B for ; Thu, 2 Aug 2018 10:19:56 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2018 01:19:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,434,1526367600"; d="scan'208";a="77650941" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga001.fm.intel.com with ESMTP; 02 Aug 2018 01:19:54 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.110]) by irsmsx105.ger.corp.intel.com ([169.254.7.195]) with mapi id 14.03.0319.002; Thu, 2 Aug 2018 09:19:53 +0100 From: "Ananyev, Konstantin" To: Jerin Jacob , Stephen Hemminger CC: "Joseph, Anoob" , Thomas Monjalon , "dev@dpdk.org" , "Richardson, Bruce" , "De Lara Guarch, Pablo" , Narayana Prasad , Hemant Agrawal , Sunil Kumar Kori , "Rao, Nikhil" Thread-Topic: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode additions Thread-Index: AQHUKWVEpfA3xxjs9ka3kRVIAeujS6SrDP8AgAAJBACAAQjiQA== Date: Thu, 2 Aug 2018 08:19:53 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258E6D4D959@IRSMSX102.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> <20180801095414.7bc34b30@xeon-e3> <20180801172628.GA471@jerin> In-Reply-To: <20180801172628.GA471@jerin> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTEwNmFkYmYtYTRhZS00NzY3LThkYWYtYTc2ZDkyMjYwMTNlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiS04zRmRTUzRhUFl3UzYyVTRQcTVmRW1QQWwwbzMzUmJNMzQ3M00zakpvRm5hNlwvU3hZMjhuVGM4XC8zeVBxSmpUIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 08:19:57 -0000 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 main= tenance. > > > > If discussion does not happen, you can request it to the technical = board. > > > > > > > Event dev framework and various adapters enable multiple packet handl= ing > > > 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 rea= l > > > world performance for a system when it's using event device for packe= t > > > handling and when it's done via polling on queues. > > > > > > The following patch submitted by Sunil was looking to address this is= sue > > > 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 additi= ons. > > > > > > The scope of this effort has increased since the submission, as now w= e > > > 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 addi= ng > > > 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. >=20 > 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. >=20 > 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:=20 keep packet processing code common, that would be used by both poll and eve= nt modes.=20 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 >=20 > # 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? >=20 > > > > As the number of examples increases, probably also need to have > > a roadmap or decision chart to explain the advangage/disadvantage > > of each architecture. > >