> -----Original Message----- > From: Joseph, Anoob [mailto:anoob.jos...@caviumnetworks.com] > Sent: Thursday, June 28, 2018 11:59 AM > To: Ananyev, Konstantin <konstantin.anan...@intel.com>; Sunil Kumar Kori > <sunil.k...@nxp.com>; Richardson, Bruce > <bruce.richard...@intel.com>; Jerin Jacob <jerin.ja...@caviumnetworks.com>; > De Lara Guarch, Pablo > <pablo.de.lara.gua...@intel.com> > Cc: Hemant Agrawal <hemant.agra...@nxp.com>; Narayana Prasad > <narayanaprasad.athr...@caviumnetworks.com>; Rao, Nikhil > <nikhil....@intel.com>; Pavan Nikhilesh <pbhagavat...@caviumnetworks.com>; > dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 01/20] eventdev: add files for eventmode helper > > Hi Konstantin, > > On 28-06-2018 16:17, Ananyev, Konstantin wrote: > > Hi Anoob, > > > >> -----Original Message----- > >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Joseph, Anoob > >> Sent: Thursday, June 28, 2018 11:43 AM > >> To: Sunil Kumar Kori <sunil.k...@nxp.com>; Richardson, Bruce > >> <bruce.richard...@intel.com>; Jerin Jacob > >> <jerin.ja...@caviumnetworks.com>; De Lara Guarch, Pablo > >> <pablo.de.lara.gua...@intel.com> > >> Cc: Hemant Agrawal <hemant.agra...@nxp.com>; Narayana Prasad > >> <narayanaprasad.athr...@caviumnetworks.com>; Rao, > Nikhil > >> <nikhil....@intel.com>; Pavan Nikhilesh <pbhagavat...@caviumnetworks.com>; > >> dev@dpdk.org > >> Subject: Re: [dpdk-dev] [PATCH 01/20] eventdev: add files for eventmode > >> helper > >> > >> Hi Sunil, > >> > >> On 27-06-2018 11:50, Sunil Kumar Kori wrote: > >>> External Email > >>> > >>> Regards > >>> Sunil Kumar > >>> > >>>> -----Original Message----- > >>>> From: Anoob Joseph [mailto:anoob.jos...@caviumnetworks.com] > >>>> Sent: Friday, June 8, 2018 10:54 PM > >>>> To: Bruce Richardson <bruce.richard...@intel.com>; Jerin Jacob > >>>> <jerin.ja...@caviumnetworks.com>; Pablo de Lara > >>>> <pablo.de.lara.gua...@intel.com> > >>>> Cc: Anoob Joseph <anoob.jos...@caviumnetworks.com>; Hemant Agrawal > >>>> <hemant.agra...@nxp.com>; Narayana Prasad > >>>> <narayanaprasad.athr...@caviumnetworks.com>; Nikhil Rao > >>>> <nikhil....@intel.com>; Pavan Nikhilesh > >>>> <pbhagavat...@caviumnetworks.com>; Sunil Kumar Kori > >>>> <sunil.k...@nxp.com>; dev@dpdk.org > >>>> Subject: [PATCH 01/20] eventdev: add files for eventmode helper > >>>> > >>>> Signed-off-by: Anoob Joseph <anoob.jos...@caviumnetworks.com> > >>>> --- > >>>> lib/librte_eventdev/Makefile | 2 ++ > >>>> lib/librte_eventdev/rte_eventmode_helper.c | 7 +++++++ > >>>> lib/librte_eventdev/rte_eventmode_helper.h | 6 ++++++ > >>>> lib/librte_eventdev/rte_eventmode_helper_internal.h | 6 ++++++ > >>>> 4 files changed, 21 insertions(+) > >>>> create mode 100644 lib/librte_eventdev/rte_eventmode_helper.c > >>>> create mode 100644 lib/librte_eventdev/rte_eventmode_helper.h > >>>> create mode 100644 lib/librte_eventdev/rte_eventmode_helper_internal.h > >>>> > >>> Having a separate helper library to configure eventdev may be a overhead > >>> to the application > >>> as application needs to understand main DPDK API as well as helper > >>> routines. > >>> It can be kept in application as a separate file. > >> For one application we could add a new file, but if we are to enable > >> event mode with multiple applications, wouldn't this be duplication of > >> lot of code? Considering that I haven't added the required parsing > >> routines, the code additions in one application to make it eventdriven > >> would be huge. > >> > >> I do agree that making this as a library poses its own challenges, but > >> do you have something better in mind? Another option we can think of is > >> making all these changes part of some common headers and then each > >> application can include and start using these functions. I'm fine with > >> any approach, but we need to consider making at-least l3fwd & > >> ipsec-secgw also event driven. > > A quick q - does it mean that l3fwd and ipsec-secgw would become event > > driven only? > > Or it would be possible to choose (at startup or at build time) between > > current and new > > behavior? > The mode would be chosen with CL option "--transfer-mode <MODE>". When > MODE=0, the application will run in existing (poll) mode. When MODE=1, > the application would run in event mode. In that case only, event > device, eth rx adapter etc would be initialized and used.
Ok sounds good to me. > > Sample usage: ./l2fwd <EAL options> -- <app options> -- --transfer-mode > 0 #for existing behavior > > Right now mode is selected during startup. Do you think build time is > better? No, I am quite happy with suggested approach. My only concern would be to keep intact existing functionality/performance and minimize changes in the existing code. Thanks Konstantin
