[dpdk-dev] [PATCH 01/20] eventdev: add files for eventmode helper

[Joseph, Anoob]

Hi Konstantin,


On 28-06-2018 17:14, Ananyev, Konstantin wrote:
>
>> -----Original Message-----
>> From: Joseph, Anoob [mailto:Anoob.Joseph at caviumnetworks.com]
>> Sent: Thursday, June 28, 2018 11:59 AM
>> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>; Sunil Kumar Kori <sunil.kori at nxp.com>; Richardson, Bruce
>> <bruce.richardson at intel.com>; Jerin Jacob <jerin.jacob at caviumnetworks.com>; De Lara Guarch, Pablo
>> <pablo.de.lara.guarch at intel.com>
>> Cc: Hemant Agrawal <hemant.agrawal at nxp.com>; Narayana Prasad <narayanaprasad.athreya at caviumnetworks.com>; Rao, Nikhil
>> <nikhil.rao at intel.com>; Pavan Nikhilesh <pbhagavatula at caviumnetworks.com>; dev at 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-bounces at dpdk.org] On Behalf Of Joseph, Anoob
>>>> Sent: Thursday, June 28, 2018 11:43 AM
>>>> To: Sunil Kumar Kori <sunil.kori at nxp.com>; Richardson, Bruce <bruce.richardson at intel.com>; Jerin Jacob
>>>> <jerin.jacob at caviumnetworks.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch at intel.com>
>>>> Cc: Hemant Agrawal <hemant.agrawal at nxp.com>; Narayana Prasad <narayanaprasad.athreya at caviumnetworks.com>; Rao,
>> Nikhil
>>>> <nikhil.rao at intel.com>; Pavan Nikhilesh <pbhagavatula at caviumnetworks.com>; dev at 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.joseph at caviumnetworks.com]
>>>>>> Sent: Friday, June 8, 2018 10:54 PM
>>>>>> To: Bruce Richardson <bruce.richardson at intel.com>; Jerin Jacob
>>>>>> <jerin.jacob at caviumnetworks.com>; Pablo de Lara
>>>>>> <pablo.de.lara.guarch at intel.com>
>>>>>> Cc: Anoob Joseph <anoob.joseph at caviumnetworks.com>; Hemant Agrawal
>>>>>> <hemant.agrawal at nxp.com>; Narayana Prasad
>>>>>> <narayanaprasad.athreya at caviumnetworks.com>; Nikhil Rao
>>>>>> <nikhil.rao at intel.com>; Pavan Nikhilesh
>>>>>> <pbhagavatula at caviumnetworks.com>; Sunil Kumar Kori
>>>>>> <sunil.kori at nxp.com>; dev at dpdk.org
>>>>>> Subject: [PATCH 01/20] eventdev: add files for eventmode helper
>>>>>>
>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph at 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
>
>
Existing functionality/performance would be intact. That was the whole 
idea with the helper function additions. Following would be a rough 
estimate of the additions,
1. Call to the helper function to print the usage in app_usage
2. Call to the helper function to parse the args and return the 
generated "conf"
3. Call to the helper function for initializing devs based on conf (when 
poll mode, this will return immediately)
4. Launch worker based on conf. When it's poll mode, call the existing 
poll mode worker.

Hope this approach is fine even when extended to other apps.

Thanks,
Anoob