Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library

Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library

[Jerin Jacob Kollanukkaran]

> -----Original Message-----
> From: Anoob Joseph
> Sent: Thursday, June 20, 2019 9:15 AM
> To: Mattias Rönnblom <mattias.ronnblom@ericsson.com>; Jerin Jacob
> Kollanukkaran <jerinj@marvell.com>; Nikhil Rao <nikhil.rao@intel.com>; Erik
> Gabriel Carrillo <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> <abhinandan.gujjar@intel.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>
> Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org;
> Lukas Bartosik <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Hemant Agrawal <hemant.agrawal@nxp.com>;
> Nipun Gupta <nipun.gupta@nxp.com>; Harry van Haaren
> <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>
> Subject: RE: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper
> library
> > However, the flexibility and many of the parameters are there for a
> > reason (those there aren't should be deprecated). I would expect a
> > real-world application to tweak quite a few of them. I know our applications
> do.
> >
> > I worry I have is that if you put eventmode (in its current form)
> > forward as a generic framework, applications might start using it,
> > only to realize it's not flexible enough, and then eventmode is just
> > an extra layer, increasing rather than reducing complexity. Or even
> > worse, the application's developers are forced to do a big-bang switch
> > over to using the event and ethernet device APIs directly, in case
> > they can't patch DPDK to work around the eventmode- assumption-that-
> didn't-hold-for-them.
> >
> > You could always add flexibility to the framework (as you encounter a
> > need for it), but then it will grow in complexity as well.
> >
> > A less ambitious approach would be to instead do a properly
> > modularized, non-trivial eventdev example application, for the
> > applications to start off from, instead of a generic library.
> >
> > I would expect it to be very difficult to design a truly generic
> > application framework for eventdev-based applications. Such a
> > framework would tie everything that's needed in a non-trivial
> > application together. If successful, it would be a huge step toward
> > making DPDK an operating system for packet processing applications.
> 
> [Anoob] The idea here is not to deprecate any event dev APIs. I do agree that all
> the configuration exposed by eventdev & adapters are required for various
> requirements in the real world applications. But the requirement to understand
> & use all this configuration is making the applications complicated and causes
> significant effort from anyone who would want to get started with event mode.
> The idea of helper is to allow an easy framework for applications to get started
> with eventmode, and then use various options from C/L or config file (both
> planned) to override the configuration as required. DPDK has components like
> crypto-scheduler which abstracts lot of configuration and simplify usage from
> application's perspective. This effort is on similar lines.
> 
> My patchset is a followup to http://patches.dpdk.org/patch/37955 , wherein the
> approach of introducing a helper library for event mode was mooted. The initial
> patch proposed additions in one application, and that involved huge code
> additions just for doing the configuration.
> 
> The helper library will be experimental while we add event-mode support for
> other applications like l3fwd & ipsec-secgw. I expect the helper library to be
> complete over the course of those applications also using the helper library.


I have only concern about moving this as library inside eventdev that till we have mature
version of helper library the eventdev library ABI will not stable(i.e .so file version needs
to be incremented as when a change needed). Which align with Mattias thoughts for
some other reason:. How about moving this code to
1) example/common or
2) to specific application itself, once at least two applications starts using it then move
to Eventdev library.

Thoughts?




> 
> >
> > What event devices have you tested with?
> 
> [Anoob] Eventmode helper is tested with the following combinations,
>     1. event-octeontx event PMD & nicvf eth PMD
>     2. event-octeontx event PMD & eth-octeontx eth PMD

Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library

[Anoob Joseph]

Hi Jerin, Mattias,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Jerin Jacob Kollanukkaran
> Sent: Tuesday, June 25, 2019 4:03 PM
> To: Anoob Joseph <anoobj@marvell.com>; Mattias Rönnblom
> <mattias.ronnblom@ericsson.com>; Nikhil Rao <nikhil.rao@intel.com>; Erik
> Gabriel Carrillo <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> <abhinandan.gujjar@intel.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>
> Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org;
> Lukas Bartosik <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van Haaren <harry.van.haaren@intel.com>; Liang Ma
> <liang.j.ma@intel.com>
> Subject: RE: [dpdk-dev] Re: [PATCH 00/39] adding eventmode helper library
> 
> > -----Original Message-----
> > From: Anoob Joseph
> > Sent: Thursday, June 20, 2019 9:15 AM
> > To: Mattias Rönnblom <mattias.ronnblom@ericsson.com>; Jerin Jacob
> > Kollanukkaran <jerinj@marvell.com>; Nikhil Rao <nikhil.rao@intel.com>;
> > Erik Gabriel Carrillo <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> > <abhinandan.gujjar@intel.com>; Bruce Richardson
> > <bruce.richardson@intel.com>; Pablo de Lara
> > <pablo.de.lara.guarch@intel.com>
> > Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>;
> dev@dpdk.org;
> > Lukas Bartosik <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
> > <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>;
> > Nipun Gupta <nipun.gupta@nxp.com>; Harry van Haaren
> > <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>
> > Subject: RE: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode
> > helper library
> > > However, the flexibility and many of the parameters are there for a
> > > reason (those there aren't should be deprecated). I would expect a
> > > real-world application to tweak quite a few of them. I know our
> > > applications
> > do.
> > >
> > > I worry I have is that if you put eventmode (in its current form)
> > > forward as a generic framework, applications might start using it,
> > > only to realize it's not flexible enough, and then eventmode is just
> > > an extra layer, increasing rather than reducing complexity. Or even
> > > worse, the application's developers are forced to do a big-bang
> > > switch over to using the event and ethernet device APIs directly, in
> > > case they can't patch DPDK to work around the eventmode-
> > > assumption-that-
> > didn't-hold-for-them.
> > >
> > > You could always add flexibility to the framework (as you encounter
> > > a need for it), but then it will grow in complexity as well.
> > >
> > > A less ambitious approach would be to instead do a properly
> > > modularized, non-trivial eventdev example application, for the
> > > applications to start off from, instead of a generic library.
> > >
> > > I would expect it to be very difficult to design a truly generic
> > > application framework for eventdev-based applications. Such a
> > > framework would tie everything that's needed in a non-trivial
> > > application together. If successful, it would be a huge step toward
> > > making DPDK an operating system for packet processing applications.
> >
> > [Anoob] The idea here is not to deprecate any event dev APIs. I do
> > agree that all the configuration exposed by eventdev & adapters are
> > required for various requirements in the real world applications. But
> > the requirement to understand & use all this configuration is making
> > the applications complicated and causes significant effort from anyone who
> would want to get started with event mode.
> > The idea of helper is to allow an easy framework for applications to
> > get started with eventmode, and then use various options from C/L or
> > config file (both
> > planned) to override the configuration as required. DPDK has
> > components like crypto-scheduler which abstracts lot of configuration
> > and simplify usage from application's perspective. This effort is on similar
> lines.
> >
> > My patchset is a followup to http://patches.dpdk.org/patch/37955 ,
> > wherein the approach of introducing a helper library for event mode
> > was mooted. The initial patch proposed additions in one application,
> > and that involved huge code additions just for doing the configuration.
> >
> > The helper library will be experimental while we add event-mode
> > support for other applications like l3fwd & ipsec-secgw. I expect the
> > helper library to be complete over the course of those applications also
> using the helper library.
> 
> 
> I have only concern about moving this as library inside eventdev that till we
> have mature version of helper library the eventdev library ABI will not
> stable(i.e .so file version needs to be incremented as when a change
> needed). Which align with Mattias thoughts for some other reason:. How
> about moving this code to
> 1) example/common or
> 2) to specific application itself, once at least two applications starts using it
> then move to Eventdev library.
> 
> Thoughts?

[Anoob] Either location is not a problem if there is a consensus. Earlier the suggestion was to move it to library (when the patch was submitted with changes added in app).

Since there are other comments, which are being addressed, I would like to send the next series with the current layout itself. And when we have an agreement on the location to be used, I'll make the changes. Is that fine?

> 
> 
> 
> 
> >
> > >
> > > What event devices have you tested with?
> >
> > [Anoob] Eventmode helper is tested with the following combinations,
> >     1. event-octeontx event PMD & nicvf eth PMD
> >     2. event-octeontx event PMD & eth-octeontx eth PMD

Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library

[Jerin Jacob Kollanukkaran]

> -----Original Message-----
> From: Anoob Joseph
> Sent: Thursday, June 27, 2019 10:58 AM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Mattias Rönnblom
> <mattias.ronnblom@ericsson.com>; Nikhil Rao <nikhil.rao@intel.com>; Erik
> Gabriel Carrillo <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> <abhinandan.gujjar@intel.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>
> Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org;
> Lukas Bartosik <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van Haaren <harry.van.haaren@intel.com>; Liang Ma
> <liang.j.ma@intel.com>
> Subject: RE: [dpdk-dev] Re: [PATCH 00/39] adding eventmode helper library
> 
> Hi Jerin, Mattias,
> 
> Please see inline.
> 
> Thanks,
> Anoob
> 
> > -----Original Message-----
> > From: Jerin Jacob Kollanukkaran
> > Sent: Tuesday, June 25, 2019 4:03 PM
> > To: Anoob Joseph <anoobj@marvell.com>; Mattias Rönnblom
> > <mattias.ronnblom@ericsson.com>; Nikhil Rao <nikhil.rao@intel.com>;
> > Erik Gabriel Carrillo <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> > <abhinandan.gujjar@intel.com>; Bruce Richardson
> > <bruce.richardson@intel.com>; Pablo de Lara
> > <pablo.de.lara.guarch@intel.com>
> > Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>;
> dev@dpdk.org;
> > Lukas Bartosik <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
> > <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>;
> > Nipun Gupta <nipun.gupta@nxp.com>; Harry van Haaren
> > <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>
> > Subject: RE: [dpdk-dev] Re: [PATCH 00/39] adding eventmode helper
> > library
> >
> > > -----Original Message-----
> > > From: Anoob Joseph
> > > Sent: Thursday, June 20, 2019 9:15 AM
> > > To: Mattias Rönnblom <mattias.ronnblom@ericsson.com>; Jerin Jacob
> > > Kollanukkaran <jerinj@marvell.com>; Nikhil Rao
> > > <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> > > <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> > > <abhinandan.gujjar@intel.com>; Bruce Richardson
> > > <bruce.richardson@intel.com>; Pablo de Lara
> > > <pablo.de.lara.guarch@intel.com>
> > > Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>;
> > dev@dpdk.org;
> > > Lukas Bartosik <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
> > > <pbhagavatula@marvell.com>; Hemant Agrawal
> > <hemant.agrawal@nxp.com>;
> > > Nipun Gupta <nipun.gupta@nxp.com>; Harry van Haaren
> > > <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>
> > > Subject: RE: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode
> > > helper library
> > > > However, the flexibility and many of the parameters are there for
> > > > a reason (those there aren't should be deprecated). I would expect
> > > > a real-world application to tweak quite a few of them. I know our
> > > > applications
> > > do.
> > > >
> > > > I worry I have is that if you put eventmode (in its current form)
> > > > forward as a generic framework, applications might start using it,
> > > > only to realize it's not flexible enough, and then eventmode is
> > > > just an extra layer, increasing rather than reducing complexity.
> > > > Or even worse, the application's developers are forced to do a
> > > > big-bang switch over to using the event and ethernet device APIs
> > > > directly, in case they can't patch DPDK to work around the
> > > > eventmode-
> > > > assumption-that-
> > > didn't-hold-for-them.
> > > >
> > > > You could always add flexibility to the framework (as you
> > > > encounter a need for it), but then it will grow in complexity as well.
> > > >
> > > > A less ambitious approach would be to instead do a properly
> > > > modularized, non-trivial eventdev example application, for the
> > > > applications to start off from, instead of a generic library.
> > > >
> > > > I would expect it to be very difficult to design a truly generic
> > > > application framework for eventdev-based applications. Such a
> > > > framework would tie everything that's needed in a non-trivial
> > > > application together. If successful, it would be a huge step
> > > > toward making DPDK an operating system for packet processing
> applications.
> > >
> > > [Anoob] The idea here is not to deprecate any event dev APIs. I do
> > > agree that all the configuration exposed by eventdev & adapters are
> > > required for various requirements in the real world applications.
> > > But the requirement to understand & use all this configuration is
> > > making the applications complicated and causes significant effort
> > > from anyone who
> > would want to get started with event mode.
> > > The idea of helper is to allow an easy framework for applications to
> > > get started with eventmode, and then use various options from C/L or
> > > config file (both
> > > planned) to override the configuration as required. DPDK has
> > > components like crypto-scheduler which abstracts lot of
> > > configuration and simplify usage from application's perspective.
> > > This effort is on similar
> > lines.
> > >
> > > My patchset is a followup to http://patches.dpdk.org/patch/37955 ,
> > > wherein the approach of introducing a helper library for event mode
> > > was mooted. The initial patch proposed additions in one application,
> > > and that involved huge code additions just for doing the configuration.
> > >
> > > The helper library will be experimental while we add event-mode
> > > support for other applications like l3fwd & ipsec-secgw. I expect
> > > the helper library to be complete over the course of those
> > > applications also
> > using the helper library.
> >
> >
> > I have only concern about moving this as library inside eventdev that
> > till we have mature version of helper library the eventdev library ABI
> > will not stable(i.e .so file version needs to be incremented as when a
> > change needed). Which align with Mattias thoughts for some other
> > reason:. How about moving this code to
> > 1) example/common or
> > 2) to specific application itself, once at least two applications
> > starts using it then move to Eventdev library.
> >
> > Thoughts?
> 
> [Anoob] Either location is not a problem if there is a consensus. Earlier the
> suggestion was to move it to library (when the patch was submitted with
> changes added in app).


If there NO objections then lets move to example/common.

Cc: techboard@dpdk.org for final decision on the location.





> 
> Since there are other comments, which are being addressed, I would like to
> send the next series with the current layout itself. And when we have an
> agreement on the location to be used, I'll make the changes. Is that fine?
> 
> >
> >
> >
> >
> > >
> > > >
> > > > What event devices have you tested with?
> > >
> > > [Anoob] Eventmode helper is tested with the following combinations,
> > >     1. event-octeontx event PMD & nicvf eth PMD
> > >     2. event-octeontx event PMD & eth-octeontx eth PMD

Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library

[Mattias Rönnblom]

On 2019-06-28 05:37, Jerin Jacob Kollanukkaran wrote:

>>>
>>> I have only concern about moving this as library inside eventdev that
>>> till we have mature version of helper library the eventdev library ABI
>>> will not stable(i.e .so file version needs to be incremented as when a
>>> change needed). Which align with Mattias thoughts for some other
>>> reason:. How about moving this code to
>>> 1) example/common or
>>> 2) to specific application itself, once at least two applications
>>> starts using it then move to Eventdev library.
>>>
>>> Thoughts?
>>
>> [Anoob] Either location is not a problem if there is a consensus. Earlier the
>> suggestion was to move it to library (when the patch was submitted with
>> changes added in app).
> 
> 
> If there NO objections then lets move to example/common.
> 

That sounds like a good idea to me.

I wish I had more time to devote to eventmode, so I could be more 
constructive than basically just saying "it's a hard problem" and "the 
proposed solution seems not generic-enough by far" - but I don't at the 
moment.

Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library

[Thomas Monjalon]

28/06/2019 05:37, Jerin Jacob Kollanukkaran:
> From: Anoob Joseph
> > From: Jerin Jacob Kollanukkaran
> > > From: Anoob Joseph
> > > > The helper library will be experimental while we add event-mode
> > > > support for other applications like l3fwd & ipsec-secgw. I expect
> > > > the helper library to be complete over the course of those
> > > > applications also using the helper library.

You are doing a copy of l2fwd example to add event mode.
It was the decision from the techboard to not complicate the original
l2fwd. But it makes me nervous to see some code duplicated,
especially if you plan to do the same for l3fwd and ipsec-secgw.
We are not going to duplicate every examples. We should re-consider.

> > > I have only concern about moving this as library inside eventdev that
> > > till we have mature version of helper library the eventdev library ABI
> > > will not stable(i.e .so file version needs to be incremented as when a
> > > change needed). Which align with Mattias thoughts for some other
> > > reason:. How about moving this code to
> > > 1) example/common or
> > > 2) to specific application itself, once at least two applications
> > > starts using it then move to Eventdev library.
> > >
> > > Thoughts?
> > 
> > [Anoob] Either location is not a problem if there is a consensus. Earlier the
> > suggestion was to move it to library (when the patch was submitted with
> > changes added in app).

If there is only one user, making it grow in the application looks to be
the best thing to do.
Should we use it in more applications before it is more mature?
If not, we could move the code in eventdev library when we will
use it in more examples.

> If there NO objections then lets move to example/common.

If we really want to have this library standalone in examples,
I suggest to give it a name and not use a "common" directory.

Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library

[Mattias Rönnblom]

On 2019-06-28 10:40, Thomas Monjalon wrote:
> 28/06/2019 05:37, Jerin Jacob Kollanukkaran:
>> From: Anoob Joseph
>>> From: Jerin Jacob Kollanukkaran
>>>> From: Anoob Joseph
>>>>> The helper library will be experimental while we add event-mode
>>>>> support for other applications like l3fwd & ipsec-secgw. I expect
>>>>> the helper library to be complete over the course of those
>>>>> applications also using the helper library.
> 
> You are doing a copy of l2fwd example to add event mode.
> It was the decision from the techboard to not complicate the original
> l2fwd. But it makes me nervous to see some code duplicated,
> especially if you plan to do the same for l3fwd and ipsec-secgw.
> We are not going to duplicate every examples. We should re-consider.
> 
>>>> I have only concern about moving this as library inside eventdev that
>>>> till we have mature version of helper library the eventdev library ABI
>>>> will not stable(i.e .so file version needs to be incremented as when a
>>>> change needed). Which align with Mattias thoughts for some other
>>>> reason:. How about moving this code to
>>>> 1) example/common or
>>>> 2) to specific application itself, once at least two applications
>>>> starts using it then move to Eventdev library.
>>>>
>>>> Thoughts?
>>>
>>> [Anoob] Either location is not a problem if there is a consensus. Earlier the
>>> suggestion was to move it to library (when the patch was submitted with
>>> changes added in app).
> 
> If there is only one user, making it grow in the application looks to be
> the best thing to do.
> Should we use it in more applications before it is more mature?
> If not, we could move the code in eventdev library when we will
> use it in more examples.
> 
>> If there NO objections then lets move to example/common.
> 
> If we really want to have this library standalone in examples,
> I suggest to give it a name and not use a "common" directory.
> 
> 

Another solution would be to keep it in a separate git repo, potentially 
together with a few forked DPDK example applications and new 
purpose-built example applications, until it's mature enough.

It's a bolt-on, not an integral part of eventdev or any other 
lower-layer infrastructure, so you don't need the whole DPDK tree.

Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Anoob Joseph]

Hi Thomas, Jerin,

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> Sent: Friday, June 28, 2019 2:10 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Anoob Joseph
> <anoobj@marvell.com>
> Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> <abhinandan.gujjar@intel.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van Haaren <harry.van.haaren@intel.com>; Liang Ma
> <liang.j.ma@intel.com>; techboard@dpdk.org
> Subject: [EXT] Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper
> library
> 
> External Email
> 
> ----------------------------------------------------------------------
> 28/06/2019 05:37, Jerin Jacob Kollanukkaran:
> > From: Anoob Joseph
> > > From: Jerin Jacob Kollanukkaran
> > > > From: Anoob Joseph
> > > > > The helper library will be experimental while we add event-mode
> > > > > support for other applications like l3fwd & ipsec-secgw. I
> > > > > expect the helper library to be complete over the course of
> > > > > those applications also using the helper library.
> 
> You are doing a copy of l2fwd example to add event mode.
> It was the decision from the techboard to not complicate the original l2fwd.
> But it makes me nervous to see some code duplicated, especially if you plan
> to do the same for l3fwd and ipsec-secgw.
> We are not going to duplicate every examples. We should re-consider.
> 

[Anoob] For l3fwd & ipsec-secgw, the plan is to add eventmode in the original application itself. If you have concerns about code duplication in l2fwd-event, the changes can be added to l2fwd itself. Please advise on how to proceed.
 
> > > > I have only concern about moving this as library inside eventdev
> > > > that till we have mature version of helper library the eventdev
> > > > library ABI will not stable(i.e .so file version needs to be
> > > > incremented as when a change needed). Which align with Mattias
> > > > thoughts for some other reason:. How about moving this code to
> > > > 1) example/common or
> > > > 2) to specific application itself, once at least two applications
> > > > starts using it then move to Eventdev library.
> > > >
> > > > Thoughts?
> > >
> > > [Anoob] Either location is not a problem if there is a consensus.
> > > Earlier the suggestion was to move it to library (when the patch was
> > > submitted with changes added in app).
> 
> If there is only one user, making it grow in the application looks to be the
> best thing to do.
> Should we use it in more applications before it is more mature?
> If not, we could move the code in eventdev library when we will use it in
> more examples.
> 

[Anoob] The proposal with l2fwd-event was to present an easy enough example so that the APIs can be decided before moving onto complex examples. Additions to l3fwd & ipsec-secgw is in the pipeline.

> > If there NO objections then lets move to example/common.
> 
> If we really want to have this library standalone in examples, I suggest to give
> it a name and not use a "common" directory.
> 

[Anoob] I would suggest to add the eventmode code in 'examples/utils'.

What is being added here can be treated as a utility library. Almost all examples have duplicated code for the entire conf parsing, ethdev init etc. Anyone who would attempt a new application will have to duplicate lot of code. So a similar exercise with regular poll mode is also possible. 

As for build, we will have the following options,

1. From the examples/<example>/Makefile, build *helper*.o files ( '../utils/eventmode_helper.o') and prepare the binary. So each application will build its own version of *helper*.c
    +SRCS-y += ../utils/eventmode_helper.c

2. Make 'examples/utils' a separate library. This way, all applications can directly link without having to build separately.

Please do suggest on which would be a good way to execute.

Thanks,
Anoob

Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Anoob Joseph]

Hi Thomas, Jerin,

Is there any consensus on how we should proceed? Can this be taken up by techboard?

Thanks,
Anoob

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Anoob Joseph
> Sent: Friday, June 28, 2019 5:04 PM
> To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>
> Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> <erik.g.carrillo@intel.com>; Abhinandan Gujjar <abhinandan.gujjar@intel.com>;
> Bruce Richardson <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry van
> Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> techboard@dpdk.org
> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper
> library
> 
> Hi Thomas, Jerin,
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > Sent: Friday, June 28, 2019 2:10 PM
> > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Anoob Joseph
> > <anoobj@marvell.com>
> > Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> > Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> > <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> > <abhinandan.gujjar@intel.com>; Bruce Richardson
> > <bruce.richardson@intel.com>; Pablo de Lara
> > <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> > <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> > Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> > <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van
> > Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> > techboard@dpdk.org
> > Subject: [EXT] Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper
> > library
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > 28/06/2019 05:37, Jerin Jacob Kollanukkaran:
> > > From: Anoob Joseph
> > > > From: Jerin Jacob Kollanukkaran
> > > > > From: Anoob Joseph
> > > > > > The helper library will be experimental while we add
> > > > > > event-mode support for other applications like l3fwd &
> > > > > > ipsec-secgw. I expect the helper library to be complete over
> > > > > > the course of those applications also using the helper library.
> >
> > You are doing a copy of l2fwd example to add event mode.
> > It was the decision from the techboard to not complicate the original l2fwd.
> > But it makes me nervous to see some code duplicated, especially if you
> > plan to do the same for l3fwd and ipsec-secgw.
> > We are not going to duplicate every examples. We should re-consider.
> >
> 
> [Anoob] For l3fwd & ipsec-secgw, the plan is to add eventmode in the original
> application itself. If you have concerns about code duplication in l2fwd-event,
> the changes can be added to l2fwd itself. Please advise on how to proceed.
> 
> > > > > I have only concern about moving this as library inside eventdev
> > > > > that till we have mature version of helper library the eventdev
> > > > > library ABI will not stable(i.e .so file version needs to be
> > > > > incremented as when a change needed). Which align with Mattias
> > > > > thoughts for some other reason:. How about moving this code to
> > > > > 1) example/common or
> > > > > 2) to specific application itself, once at least two
> > > > > applications starts using it then move to Eventdev library.
> > > > >
> > > > > Thoughts?
> > > >
> > > > [Anoob] Either location is not a problem if there is a consensus.
> > > > Earlier the suggestion was to move it to library (when the patch
> > > > was submitted with changes added in app).
> >
> > If there is only one user, making it grow in the application looks to
> > be the best thing to do.
> > Should we use it in more applications before it is more mature?
> > If not, we could move the code in eventdev library when we will use it
> > in more examples.
> >
> 
> [Anoob] The proposal with l2fwd-event was to present an easy enough example
> so that the APIs can be decided before moving onto complex examples.
> Additions to l3fwd & ipsec-secgw is in the pipeline.
> 
> > > If there NO objections then lets move to example/common.
> >
> > If we really want to have this library standalone in examples, I
> > suggest to give it a name and not use a "common" directory.
> >
> 
> [Anoob] I would suggest to add the eventmode code in 'examples/utils'.
> 
> What is being added here can be treated as a utility library. Almost all examples
> have duplicated code for the entire conf parsing, ethdev init etc. Anyone who
> would attempt a new application will have to duplicate lot of code. So a similar
> exercise with regular poll mode is also possible.
> 
> As for build, we will have the following options,
> 
> 1. From the examples/<example>/Makefile, build *helper*.o files (
> '../utils/eventmode_helper.o') and prepare the binary. So each application will
> build its own version of *helper*.c
>     +SRCS-y += ../utils/eventmode_helper.c
> 
> 2. Make 'examples/utils' a separate library. This way, all applications can directly
> link without having to build separately.
> 
> Please do suggest on which would be a good way to execute.
> 
> Thanks,
> Anoob

Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Jerin Jacob Kollanukkaran]

> -----Original Message-----
> From: Anoob Joseph
> Sent: Tuesday, July 2, 2019 7:47 PM
> To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>
> Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> <erik.g.carrillo@intel.com>; Abhinandan Gujjar <abhinandan.gujjar@intel.com>;
> Bruce Richardson <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry van
> Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> techboard@dpdk.org
> Subject: RE: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper
> library
> 
> Hi Thomas, Jerin,
> 
> Is there any consensus on how we should proceed? Can this be taken up by
> techboard?

For me it make sense to  move these helper functions to examples/.. and make it as standalone(not as library)
Suggested directory(In the order of my preference). No strong preference on the directory name though
1) examples/helper  or
2) examples/common or
3) examples/utils

Thomas? Bruce?


> 
> Thanks,
> Anoob
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Anoob Joseph
> > Sent: Friday, June 28, 2019 5:04 PM
> > To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob Kollanukkaran
> > <jerinj@marvell.com>
> > Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> > Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> > <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> > <abhinandan.gujjar@intel.com>; Bruce Richardson
> > <bruce.richardson@intel.com>; Pablo de Lara
> > <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> > <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> > Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> > <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van
> > Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> > techboard@dpdk.org
> > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode
> > helper library
> >
> > Hi Thomas, Jerin,
> >
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > > Sent: Friday, June 28, 2019 2:10 PM
> > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Anoob Joseph
> > > <anoobj@marvell.com>
> > > Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> > > Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> > > <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> > > <abhinandan.gujjar@intel.com>; Bruce Richardson
> > > <bruce.richardson@intel.com>; Pablo de Lara
> > > <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> > > <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>;
> > > Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant
> > > Agrawal <hemant.agrawal@nxp.com>; Nipun Gupta
> <nipun.gupta@nxp.com>;
> > > Harry
> > van
> > > Haaren <harry.van.haaren@intel.com>; Liang Ma
> > > <liang.j.ma@intel.com>; techboard@dpdk.org
> > > Subject: [EXT] Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper
> > > library
> > >
> > > External Email
> > >
> > > --------------------------------------------------------------------
> > > --
> > > 28/06/2019 05:37, Jerin Jacob Kollanukkaran:
> > > > From: Anoob Joseph
> > > > > From: Jerin Jacob Kollanukkaran
> > > > > > From: Anoob Joseph
> > > > > > > The helper library will be experimental while we add
> > > > > > > event-mode support for other applications like l3fwd &
> > > > > > > ipsec-secgw. I expect the helper library to be complete over
> > > > > > > the course of those applications also using the helper library.
> > >
> > > You are doing a copy of l2fwd example to add event mode.
> > > It was the decision from the techboard to not complicate the original l2fwd.
> > > But it makes me nervous to see some code duplicated, especially if
> > > you plan to do the same for l3fwd and ipsec-secgw.
> > > We are not going to duplicate every examples. We should re-consider.
> > >
> >
> > [Anoob] For l3fwd & ipsec-secgw, the plan is to add eventmode in the
> > original application itself. If you have concerns about code
> > duplication in l2fwd-event, the changes can be added to l2fwd itself. Please
> advise on how to proceed.
> >
> > > > > > I have only concern about moving this as library inside
> > > > > > eventdev that till we have mature version of helper library
> > > > > > the eventdev library ABI will not stable(i.e .so file version
> > > > > > needs to be incremented as when a change needed). Which align
> > > > > > with Mattias thoughts for some other reason:. How about moving
> > > > > > this code to
> > > > > > 1) example/common or
> > > > > > 2) to specific application itself, once at least two
> > > > > > applications starts using it then move to Eventdev library.
> > > > > >
> > > > > > Thoughts?
> > > > >
> > > > > [Anoob] Either location is not a problem if there is a consensus.
> > > > > Earlier the suggestion was to move it to library (when the patch
> > > > > was submitted with changes added in app).
> > >
> > > If there is only one user, making it grow in the application looks
> > > to be the best thing to do.
> > > Should we use it in more applications before it is more mature?
> > > If not, we could move the code in eventdev library when we will use
> > > it in more examples.
> > >
> >
> > [Anoob] The proposal with l2fwd-event was to present an easy enough
> > example so that the APIs can be decided before moving onto complex
> examples.
> > Additions to l3fwd & ipsec-secgw is in the pipeline.
> >
> > > > If there NO objections then lets move to example/common.
> > >
> > > If we really want to have this library standalone in examples, I
> > > suggest to give it a name and not use a "common" directory.
> > >
> >
> > [Anoob] I would suggest to add the eventmode code in 'examples/utils'.
> >
> > What is being added here can be treated as a utility library. Almost
> > all examples have duplicated code for the entire conf parsing, ethdev
> > init etc. Anyone who would attempt a new application will have to
> > duplicate lot of code. So a similar exercise with regular poll mode is also
> possible.
> >
> > As for build, we will have the following options,
> >
> > 1. From the examples/<example>/Makefile, build *helper*.o files (
> > '../utils/eventmode_helper.o') and prepare the binary. So each
> > application will build its own version of *helper*.c
> >     +SRCS-y += ../utils/eventmode_helper.c
> >
> > 2. Make 'examples/utils' a separate library. This way, all
> > applications can directly link without having to build separately.
> >
> > Please do suggest on which would be a good way to execute.
> >
> > Thanks,
> > Anoob

Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Bruce Richardson]

On Tue, Jul 02, 2019 at 02:26:34PM +0000, Jerin Jacob Kollanukkaran wrote:
> > -----Original Message-----
> > From: Anoob Joseph
> > Sent: Tuesday, July 2, 2019 7:47 PM
> > To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob Kollanukkaran
> > <jerinj@marvell.com>
> > Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> > Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> > <erik.g.carrillo@intel.com>; Abhinandan Gujjar <abhinandan.gujjar@intel.com>;
> > Bruce Richardson <bruce.richardson@intel.com>; Pablo de Lara
> > <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> > <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> > Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> > <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry van
> > Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> > techboard@dpdk.org
> > Subject: RE: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper
> > library
> > 
> > Hi Thomas, Jerin,
> > 
> > Is there any consensus on how we should proceed? Can this be taken up by
> > techboard?
> 
> For me it make sense to  move these helper functions to examples/.. and make it as standalone(not as library)
> Suggested directory(In the order of my preference). No strong preference on the directory name though
> 1) examples/helper  or
> 2) examples/common or
> 3) examples/utils
> 
> Thomas? Bruce?
> 
No strong opinions. In terms of naming, "common" seems to be the usual
(dare I say common) name used in DPDK for shared code resources such as
this.

For what exactly is being proposed, is there a short version of the
suggested approach and the logic behind it?

Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Thomas Monjalon]

02/07/2019 16:26, Jerin Jacob Kollanukkaran:
> From: Anoob Joseph
> > Hi Thomas, Jerin,
> > 
> > Is there any consensus on how we should proceed? Can this be taken up by
> > techboard?

OK, let me give my detailed opinion.
Summary: I don't like this situation at all.

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.

About the copy of the example itself, you are copying it as first patch
of this series and then do improvements only to the copy, leaving the
original behind.

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.

> For me it make sense to  move these helper functions to examples/.. and make it as standalone(not as library)
> Suggested directory(In the order of my preference). No strong preference on the directory name though
> 1) examples/helper  or
> 2) examples/common or
> 3) examples/utils

If we are not able to give it a better name than "helper" or "utils",
it is like moving it in a trash folder.

And last but not least, there is not a lot of reaction to this series.

So my suggestion is to do your PoC in a standalone example,
improving the original example at the same time, and try to improve
the eventdev library if possible. Then we should not propagate
this design to more examples until we have a proof that it is a progress.

Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Anoob Joseph]

Hi Thomas, Bruce,

> 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 dynamically 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 application 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 application which would need to run in eventmode. Eventmode helper abstracts this. For an existing application to be moved to eventmode, all it would take is couple of function calls and fine-tuned worker thread.

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 additions in l3fwd application. It involved addition of lot of code, and Bruce wanted to make the additions common. Jerin suggested to add these in event dev library.

The second iteration involved additions in l2fwd and introduced eventmode in eventdev library. Then it was up for discussions again and it was decided 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 be used to finalize the event-mode library before extending to other applications.

Now this is the third iteration.

> 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 every application would need the code duplicated (how the code for lcore-port-queue conf required for eth devs is repeated in every app) or be kept common. 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.

The idea of this helper is to allow applications to run in "eventmode". Hence the name, eventmode_helper. 

> About the copy of the example itself, you are copying it as first patch of this
> series and then do improvements only to the copy, leaving the original behind.

My original proposal (additions to l2fwd) was fixing quite a lot of things in the original app. Bruce was hesitant about the changes and suggested improvements only in the new app. I can add improvements in l2fwd also, if that's what you suggest. IMO, keeping both apps similar would be better for maintenance of l2fwd-event also. So, please suggest the approach.

> So my suggestion is to do your PoC in a standalone example, improving the
> original example at the same time, and try to improve the eventdev library if
> possible. Then we should not propagate this design to more examples until we
> have a proof that it is a progress.

That is the proposal right now. L2fwd-event would be the standalone example. If code duplication is not a concern, I'll move the eventmode helper files to l2fwd-event directory. Then we can continue working on adding the features there before moving onto other examples.

Please conclude deciding the approach to be taken.

Thanks,
Anoob

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, July 2, 2019 8:27 PM
> To: Anoob Joseph <anoobj@marvell.com>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org; Mattias
> Rönnblom <mattias.ronnblom@ericsson.com>; Nikhil Rao
> <nikhil.rao@intel.com>; Erik Gabriel Carrillo <erik.g.carrillo@intel.com>;
> Abhinandan Gujjar <abhinandan.gujjar@intel.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry van
> Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> techboard@dpdk.org
> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper
> library
> 
> 02/07/2019 16:26, Jerin Jacob Kollanukkaran:
> > From: Anoob Joseph
> > > Hi Thomas, Jerin,
> > >
> > > Is there any consensus on how we should proceed? Can this be taken
> > > up by techboard?
> 
> OK, let me give my detailed opinion.
> Summary: I don't like this situation at all.
> 
> 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.
> 
> About the copy of the example itself, you are copying it as first patch of this
> series and then do improvements only to the copy, leaving the original behind.
> 
> 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.
> 
> > For me it make sense to  move these helper functions to examples/..
> > and make it as standalone(not as library) Suggested directory(In the
> > order of my preference). No strong preference on the directory name
> > though
> > 1) examples/helper  or
> > 2) examples/common or
> > 3) examples/utils
> 
> If we are not able to give it a better name than "helper" or "utils", it is like
> moving it in a trash folder.
> 
> And last but not least, there is not a lot of reaction to this series.
> 
> So my suggestion is to do your PoC in a standalone example, improving the
> original example at the same time, and try to improve the eventdev library if
> possible. Then we should not propagate this design to more examples until we
> have a proof that it is a progress.
> 

Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Mattias Rönnblom]

On 2019-07-02 18:18, Anoob Joseph wrote:
> Hi Thomas, Bruce,
> 
>> 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 dynamically 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 application 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 application which would need to run in eventmode. Eventmode helper abstracts this. 
> 

A question I asked myself when I had a look at the patch set is: does 
eventmode really abstract processing pipeline configuration, or is it 
merely making a bunch of assumptions and hard-coding a bunch of 
configuration parameters.

Merely reducing flexibility doesn't qualify as abstraction, I would say.

 > For an existing application to be moved to eventmode, all it would 
take is couple of function calls and fine-tuned worker thread.

If you want to use eventdev as a very complex implementation of software 
RSS, sure.

If you have a problem which solution requires a multi-stage pipeline, 
going from a run-to-completion model to a scheduled pipeline is going to 
have a big impact on your code base, and eventdev configuration will be 
a relatively minor part of the work, in the typical case, I would expect.

> 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 additions in l3fwd application. It involved addition of lot of code, and Bruce wanted to make the additions common. Jerin suggested to add these in event dev library.
> 
> The second iteration involved additions in l2fwd and introduced eventmode in eventdev library. Then it was up for discussions again and it was decided 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 be used to finalize the event-mode library before extending to other applications.
> 
> Now this is the third iteration.
> 

What is your point?

>> 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 every application would need the code duplicated (how the code for lcore-port-queue conf required for eth devs is repeated in every app) or be kept common. 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.
> 

OK, so in real-world applications, duplicating eventdev configuration is 
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.

For the DPDK example applications, the situation is very different. Many 
trivial applications with a similar structure. I'm sure solving the 
framework problem for this subset of applications is easier, but I would 
expect such a library would have limited value outside the realm of the 
example directory. Although it might make the DPDK example code base 
more maintainable, my fear is that it'll just confuse the reader of the 
example applications. Now they have to understand a framework *and* an 
application, and not only the example application. Add 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 
applications.

The DPDK APIs shouldn't be optimized for example applications.

Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Anoob Joseph]

Hi Mattias,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> Sent: Tuesday, July 2, 2019 11:08 PM
> To: Anoob Joseph <anoobj@marvell.com>; Thomas Monjalon
> <thomas@monjalon.net>; Bruce Richardson <bruce.richardson@intel.com>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org; Nikhil Rao
> <nikhil.rao@intel.com>; Erik Gabriel Carrillo <erik.g.carrillo@intel.com>;
> Abhinandan Gujjar <abhinandan.gujjar@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry van
> Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> techboard@dpdk.org
> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper
> library
> 
> On 2019-07-02 18:18, Anoob Joseph wrote:
> > Hi Thomas, Bruce,
> >
> >> 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 dynamically 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 application
> 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 application which
> would need to run in eventmode. Eventmode helper abstracts this.
> >
> 
> A question I asked myself when I had a look at the patch set is: does eventmode
> really abstract processing pipeline configuration, or is it merely making a bunch
> of assumptions and hard-coding a bunch of configuration parameters.
> 
> Merely reducing flexibility doesn't qualify as abstraction, I would say.

[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. 
 
> 
>  > For an existing application to be moved to eventmode, all it would take is
> couple of function calls and fine-tuned worker thread.
> 
> If you want to use eventdev as a very complex implementation of software RSS,
> sure.
> 
> If you have a problem which solution requires a multi-stage pipeline, going from
> a run-to-completion model to a scheduled pipeline is going to have a big impact
> on your code base, and eventdev configuration will be a relatively minor part of
> the work, in the typical case, I would expect.

[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.

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.

> 
> > 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 additions in
> l3fwd application. It involved addition of lot of code, and Bruce wanted to make
> the additions common. Jerin suggested to add these in event dev library.
> >
> > The second iteration involved additions in l2fwd and introduced eventmode in
> eventdev library. Then it was up for discussions again and it was decided 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 be used to
> finalize the event-mode library before extending to other applications.
> >
> > Now this is the third iteration.
> >
> 
> What is your point?

[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.
 
> 
> >> 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 every
> application would need the code duplicated (how the code for lcore-port-queue
> conf required for eth devs is repeated in every app) or be kept common. 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.
> >
> 
> OK, so in real-world applications, duplicating eventdev configuration is 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.
> 
> For the DPDK example applications, the situation is very different. Many trivial
> applications with a similar structure. I'm sure solving the framework problem for
> this subset of applications is easier, but I would expect such a library would have
> limited value outside the realm of the example directory. Although it might make
> the DPDK example code base more maintainable, my fear is that it'll just confuse
> the reader of the example applications. Now they have to understand a
> framework *and* an application, and not only the example application. Add 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 applications.
> 
> The DPDK APIs shouldn't be optimized for example applications.

[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?

None of the DPDK APIs would be modified in this effort.

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.

Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Thomas Monjalon]

03/07/2019 03:35, Anoob Joseph:
> From: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> > 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 dynamically 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 application
> > 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 application which
> > would need to run in eventmode. Eventmode helper abstracts this.
> > 
> > A question I asked myself when I had a look at the patch set is: does eventmode
> > really abstract processing pipeline configuration, or is it merely making a bunch
> > of assumptions and hard-coding a bunch of configuration parameters.
> > 
> > Merely reducing flexibility doesn't qualify as abstraction, I would say.
> 
> [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 take is
> > couple of function calls and fine-tuned worker thread.
> > 
> > If you want to use eventdev as a very complex implementation of software RSS,
> > sure.
> > 
> > If you have a problem which solution requires a multi-stage pipeline, going from
> > a run-to-completion model to a scheduled pipeline is going to have a big impact
> > on your code base, and eventdev configuration will be a relatively minor part of
> > the work, in the typical case, I would expect.
> 
> [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.
> 
> 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 additions in
> > l3fwd application. It involved addition of lot of code, and Bruce wanted to make
> > the additions common. Jerin suggested to add these in event dev library.
> > >
> > > The second iteration involved additions in l2fwd and introduced eventmode in
> > eventdev library. Then it was up for discussions again and it was decided 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 be used to
> > finalize the event-mode library before extending to other applications.
> > >
> > > Now this is the third iteration.
> > 
> > What is your point?
> 
> [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 every
> > > application would need the code duplicated (how the code for lcore-port-queue
> > > conf required for eth devs is repeated in every app) or be kept common. 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 is 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.
> > 
> > For the DPDK example applications, the situation is very different. Many trivial
> > applications with a similar structure. I'm sure solving the framework problem for
> > this subset of applications is easier, but I would expect such a library would have
> > limited value outside the realm of the example directory. Although it might make
> > the DPDK example code base more maintainable, my fear is that it'll just confuse
> > the reader of the example applications. Now they have to understand a
> > framework *and* an application, and not only the example application. Add 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 applications.
> > 
> > The DPDK APIs shouldn't be optimized for example applications.
> 
> [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.
> 
> 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.

Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Anoob Joseph]

Hi Thomas,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, July 3, 2019 2:21 PM
> To: Anoob Joseph <anoobj@marvell.com>
> Cc: Mattias Rönnblom <mattias.ronnblom@ericsson.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; dev@dpdk.org; Nikhil Rao <nikhil.rao@intel.com>;
> Erik Gabriel Carrillo <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> <abhinandan.gujjar@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van Haaren <harry.van.haaren@intel.com>; Liang Ma
> <liang.j.ma@intel.com>; techboard@dpdk.org
> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper
> library
> 
> 03/07/2019 03:35, Anoob Joseph:
> > From: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> > > 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
> > > dynamically 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
> > > application 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 application which would need to run in eventmode.
> Eventmode helper abstracts this.
> > >
> > > A question I asked myself when I had a look at the patch set is:
> > > does eventmode really abstract processing pipeline configuration, or
> > > is it merely making a bunch of assumptions and hard-coding a bunch of
> configuration parameters.
> > >
> > > Merely reducing flexibility doesn't qualify as abstraction, I would say.
> >
> > [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.

[Anoob]  Following is from the original cover letter.

<snip>
Usage:
     ./l2fwd-event -- <EAL args> -- <l2fwd args> -- --transfer-mode 1

The above command would invoke eventmode and with the default conf loaded, traffic on one port would be delivered to all enabled cores.

Planned features,
1. Eventmode helper library doesn't intialize ethdev. Since all
   applications already do this, eventmode helper would start
   from reconfiguring.
2. All features of eventdev and adapters can be exposed to the user
   using common CL arguments. The framework for achieving the same
   is already in place. It has to be extended to support more
   features.
3. Documentation is pending.

Created new app based on discussions,
http://patchwork.dpdk.org/cover/40884/
https://patches.dpdk.org/patch/40901/

Tested with nicvf eth PMD and event_octeontx event PMD on Marvell's CN83XX platform.

<snip>

I thought this would be sufficient, but the above got truncated in some of the emails. I hadn't realized that the mail thread lost this info.

> 
> > >  > For an existing application to be moved to eventmode, all it
> > > would take is couple of function calls and fine-tuned worker thread.
> > >
> > > If you want to use eventdev as a very complex implementation of
> > > software RSS, sure.
> > >
> > > If you have a problem which solution requires a multi-stage
> > > pipeline, going from a run-to-completion model to a scheduled
> > > pipeline is going to have a big impact on your code base, and
> > > eventdev configuration will be a relatively minor part of the work, in the
> typical case, I would expect.
> >
> > [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.
> >
> > 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)?

[Anoob] Aim is not to introduce a processing pipeline. Instead, the usage of the event device for handling packets. All example applications receive and send packets using eth Rx burst & Tx burst. In eventmode, application would do enqueue_burst & dequeue_burst from event device. When working with events, application will be able to use eventdev for achieving atomic updates (like sequence number in case of ipsec).

> > > > 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
> > > additions in l3fwd application. It involved addition of lot of code,
> > > and Bruce wanted to make the additions common. Jerin suggested to add
> these in event dev library.
> > > >
> > > > The second iteration involved additions in l2fwd and introduced
> > > > eventmode in
> > > eventdev library. Then it was up for discussions again and it was
> > > decided 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 be used to finalize the event-mode
> library before extending to other applications.
> > > >
> > > > Now this is the third iteration.
> > >
> > > What is your point?
> >
> > [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.
> 

[Anoob] I can understand the frustration. The patches were divided properly and the header(rte_eventmode_helper.h) was sufficiently documented so that information was not lost at any point. As I said earlier, some information was lost, and hence the current predicament.
 
> > > >> 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
> > > > every application would need the code duplicated (how the code for
> > > > lcore-port-queue conf required for eth devs is repeated in every
> > > > app) or be kept common. 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?
> 

[Anoob] May be I'm repeating the same thing. But here it goes...

For ethdev, all applications have code to parse the port-queue-lcore config. And every application has the same code to setup the ethdev with the mentioned conf. Eventdev with Rx adapter & Tx adapter is just like an eth device with more configurable properties. So the same code for doing the configuration has to be added to every application. Sunil's first attempt was this way and there were discussions about how much code would be duplicated when attempted for another application.

For ethdev config, is the code duplicated right now? Yes.
Is that a problem? No. Because the number of lines is not that much.
For eventdev config, will the number of lines increase? Yes. 
 
> > > OK, so in real-world applications, duplicating eventdev
> > > configuration is 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.
> > >
> > > For the DPDK example applications, the situation is very different.
> > > Many trivial applications with a similar structure. I'm sure solving
> > > the framework problem for this subset of applications is easier, but
> > > I would expect such a library would have limited value outside the
> > > realm of the example directory. Although it might make the DPDK
> > > example code base more maintainable, my fear is that it'll just
> > > confuse the reader of the example applications. Now they have to
> > > understand a framework *and* an application, and not only the
> > > example application. Add 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 applications.
> > >
> > > The DPDK APIs shouldn't be optimized for example applications.
> >
> > [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.

[Anoob] Idea was never to fork any example. If we are in agreement with going with just l2fwd-event (and all the code in one directory), I can start working on v2 patches with the agreed changes.

Also, what is your suggestion on when we can take up a more complicated example (let's say ipsec-secgw)? When would you say things are settled down?
 
> 
> > None of the DPDK APIs would be modified in this effort.
> >
> > 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.
> 
> 

Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Thomas Monjalon]

03/07/2019 11:37, Anoob Joseph:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 03/07/2019 03:35, Anoob Joseph:
> > > [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.
> 
> [Anoob] Idea was never to fork any example. If we are in agreement with going with just l2fwd-event (and all the code in one directory), I can start working on v2 patches with the agreed changes.
> 
> Also, what is your suggestion on when we can take up a more complicated example (let's say ipsec-secgw)? When would you say things are settled down?

It was discussed in the techboard today.
Please read the summary below.

We want to keep l2fwd as simple as possible.
So we agree to have a fork of l2fwd for eventdev.

It was proposed to integrate eventdev in l2fwd, l3fwd and ipsec-secgw.
l2fwd will get eventdev integration in its fork l2fwd-event.
l3fwd will get eventdev integration in a separate file.
ipsec-secgw will get more complex eventdev integration.
We don't expect to have more examples impacted.
There will be no code shared for eventdev integration between the examples.

Hope it clarifies the situation.

Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library

[Anoob Joseph]

Hi Thomas,

> It was discussed in the techboard today.
> Please read the summary below.
> 
> We want to keep l2fwd as simple as possible.
> So we agree to have a fork of l2fwd for eventdev.
> 
> It was proposed to integrate eventdev in l2fwd, l3fwd and ipsec-secgw.
> l2fwd will get eventdev integration in its fork l2fwd-event.
> l3fwd will get eventdev integration in a separate file.
> ipsec-secgw will get more complex eventdev integration.
> We don't expect to have more examples impacted.
> There will be no code shared for eventdev integration between the
> examples.

Thanks for taking this up in the techboard meeting. The above plan looks fine to me. Will prepare v2 with the above mentioned changes.

Thanks,
Anoob

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, July 3, 2019 10:01 PM
> To: Anoob Joseph <anoobj@marvell.com>
> Cc: Mattias Rönnblom <mattias.ronnblom@ericsson.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; dev@dpdk.org; Nikhil Rao <nikhil.rao@intel.com>;
> Erik Gabriel Carrillo <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> <abhinandan.gujjar@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van Haaren <harry.van.haaren@intel.com>; Liang Ma
> <liang.j.ma@intel.com>; techboard@dpdk.org
> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper
> library
> 
> 03/07/2019 11:37, Anoob Joseph:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 03/07/2019 03:35, Anoob Joseph:
> > > > [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.
> >
> > [Anoob] Idea was never to fork any example. If we are in agreement with
> going with just l2fwd-event (and all the code in one directory), I can start
> working on v2 patches with the agreed changes.
> >
> > Also, what is your suggestion on when we can take up a more complicated
> example (let's say ipsec-secgw)? When would you say things are settled
> down?
> 
> It was discussed in the techboard today.
> Please read the summary below.
> 
> We want to keep l2fwd as simple as possible.
> So we agree to have a fork of l2fwd for eventdev.
> 
> It was proposed to integrate eventdev in l2fwd, l3fwd and ipsec-secgw.
> l2fwd will get eventdev integration in its fork l2fwd-event.
> l3fwd will get eventdev integration in a separate file.
> ipsec-secgw will get more complex eventdev integration.
> We don't expect to have more examples impacted.
> There will be no code shared for eventdev integration between the
> examples.
> 
> Hope it clarifies the situation.
> 

Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library

[Mattias Rönnblom]

On 2019-06-07 11:48, Jerin Jacob Kollanukkaran wrote:
>> -----Original Message-----
>> From: Anoob Joseph <anoobj@marvell.com>
>> Sent: Monday, June 3, 2019 11:02 PM
>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Nikhil Rao
>> <nikhil.rao@intel.com>; Erik Gabriel Carrillo <erik.g.carrillo@intel.com>;
>> Abhinandan Gujjar <abhinandan.gujjar@intel.com>; Bruce Richardson
>> <bruce.richardson@intel.com>; Pablo de Lara
>> <pablo.de.lara.guarch@intel.com>
>> Cc: Anoob Joseph <anoobj@marvell.com>; Narayana Prasad Raju Athreya
>> <pathreya@marvell.com>; dev@dpdk.org; Lukas Bartosik
>> <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
>> <pbhagavatula@marvell.com>; Hemant Agrawal
>> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
>> van Haaren <harry.van.haaren@intel.com>; Mattias Rönnblom
>> <mattias.ronnblom@ericsson.com>; Liang Ma <liang.j.ma@intel.com>
>> Subject: [PATCH 00/39] adding eventmode helper library
>>
>> This series adds support for eventmode helper library and l2fwd-event
>> application.
>>
>> First 13 patches creates a new l2fwd application (l2fwd-event). Minor code
>> reorganization is done to faciliate seamless integration of eventmode.
>>
>> Next 22 patches adds eventmode helper library. This library abstracts the
>> configuration of event device & Rx-Tx event adapters. The library can be
>> extended to allow users to control all the configuration exposed by adapters
>> and eth device.
>>
>> Last 4 patches implements eventmode in l2fwd-event application. With
>> event device and adapters, fine tuned threads (based on dev
>> capabilities) can be drafted to maximize performance. Eventmode library
>> facilitates this and l2fwd-event demonstrates this usage.
>>
>> With the introduction of eventmode helper library, any poll mode application
>> can be converted to an eventmode application with simple steps, enabling
>> multi-core scaling and dynamic load balancing to various example
>> applications.
> 
> 
> Anyone planning to review this changes?
> I will spend time to review this. Requesting the review from other eventdev stake holders.
> 

A more extensive description of the purpose of the eventmode helper 
library would be helpful.

Is this supposed to be a generic framework for real-world applications, 
or only something to simplify DPDK the implementation of DPDK example 
programs and similar?

Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library

[Jerin Jacob Kollanukkaran]

> -----Original Message-----
> From: Anoob Joseph <anoobj@marvell.com>
> Sent: Monday, June 3, 2019 11:02 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Nikhil Rao
> <nikhil.rao@intel.com>; Erik Gabriel Carrillo <erik.g.carrillo@intel.com>;
> Abhinandan Gujjar <abhinandan.gujjar@intel.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>
> Cc: Anoob Joseph <anoobj@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; dev@dpdk.org; Lukas Bartosik
> <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van Haaren <harry.van.haaren@intel.com>; Mattias Rönnblom
> <mattias.ronnblom@ericsson.com>; Liang Ma <liang.j.ma@intel.com>
> Subject: [PATCH 00/39] adding eventmode helper library
> 
> This series adds support for eventmode helper library and l2fwd-event
> application.
> 
> First 13 patches creates a new l2fwd application (l2fwd-event). Minor code
> reorganization is done to faciliate seamless integration of eventmode.
> 
> Next 22 patches adds eventmode helper library. This library abstracts the
> configuration of event device & Rx-Tx event adapters. The library can be
> extended to allow users to control all the configuration exposed by adapters
> and eth device.
> 
> Last 4 patches implements eventmode in l2fwd-event application. With
> event device and adapters, fine tuned threads (based on dev
> capabilities) can be drafted to maximize performance. Eventmode library
> facilitates this and l2fwd-event demonstrates this usage.
> 
> With the introduction of eventmode helper library, any poll mode application
> can be converted to an eventmode application with simple steps, enabling
> multi-core scaling and dynamic load balancing to various example
> applications.


Anyone planning to review this changes?
I will spend time to review this. Requesting the review from other eventdev stake holders.

[dpdk-dev] [PATCH 00/39] adding eventmode helper library

[Anoob Joseph]

This series adds support for eventmode helper library and l2fwd-event
application.

First 13 patches creates a new l2fwd application (l2fwd-event). Minor
code reorganization is done to faciliate seamless integration of
eventmode.

Next 22 patches adds eventmode helper library. This library abstracts
the configuration of event device & Rx-Tx event adapters. The library
can be extended to allow users to control all the configuration
exposed by adapters and eth device.

Last 4 patches implements eventmode in l2fwd-event application. With
event device and adapters, fine tuned threads (based on dev
capabilities) can be drafted to maximize performance. Eventmode
library facilitates this and l2fwd-event demonstrates this usage.

With the introduction of eventmode helper library, any poll mode
application can be converted to an eventmode application with simple
steps, enabling multi-core scaling and dynamic load balancing to
various example applications.

Usage:
     ./l2fwd-event -- <EAL args> -- <l2fwd args> -- --transfer-mode 1

The above command would invoke eventmode and with the default conf
loaded, traffic on one port would be delivered to all enabled cores.

Planned features,
1. Eventmode helper library doesn't intialize ethdev. Since all
   applications already do this, eventmode helper would start
   from reconfiguring.
2. All features of eventdev and adapters can be exposed to the user
   using common CL arguments. The framework for achieving the same
   is already in place. It has to be extended to support more
   features.
3. Documentation is pending.

Created new app based on discussions,
http://patchwork.dpdk.org/cover/40884/
https://patches.dpdk.org/patch/40901/

Tested with nicvf eth PMD and event_octeontx event PMD on Marvell's
CN83XX platform.

Anoob Joseph (39):
  examples/l2fwd-event: create copy of l2fwd
  examples/l2fwd-event: move macros to common header
  examples/l2fwd-event: move structures to common header
  examples/l2fwd-event: move global vars to common header
  examples/l2fwd-event: move dataplane code to new file
  examples/l2fwd-event: remove unused header includes
  examples/l2fwd-event: move drain buffers to new function
  examples/l2fwd-event: optimize check for master core
  examples/l2fwd-event: move periodic tasks to new func
  examples/l2fwd-event: do timer updates only on master
  examples/l2fwd-event: move pkt send code to a new func
  examples/l2fwd-event: use fprintf in usage print
  examples/l2fwd-event: improvements to the usage print
  eventdev: add files for eventmode helper
  eventdev: add routines for logging eventmode helper
  eventdev: add eventmode CL options framework
  eventdev: allow application to set ethernet portmask
  eventdev: add framework for eventmode conf
  eventdev: add common initialize routine for eventmode devs
  eventdev: add eventdevice init for eventmode
  eventdev: add eventdev port-lcore link
  eventdev: add option to specify schedule mode for app stage
  eventdev: add placeholder for ethdev init
  eventdev: add Rx adapter init in eventmode
  eventdev: add routine to validate conf
  eventdev: add default conf for event devs field in conf
  eventdev: add default conf for Rx adapter conf
  eventdev: add default conf for event port-lcore link
  eventdev: add routines to display the eventmode conf
  eventdev: add routine to access eventmode link info
  eventdev: add routine to access event queue for eth Tx
  eventdev: add routine to launch eventmode workers
  eventdev: add Tx adapter support
  eventdev: add support for internal ports
  eventdev: display Tx adapter conf
  examples/l2fwd-event: add eventmode for l2fwd
  examples/l2fwd-event: add eventmode worker
  examples/l2fwd-event: add eventmode worker
  examples/l2fwd-event: add eventmode worker

 config/common_base                                 |    1 +
 examples/Makefile                                  |    1 +
 examples/l2fwd-event/Makefile                      |   57 +
 examples/l2fwd-event/l2fwd_common.h                |   63 +
 examples/l2fwd-event/l2fwd_worker.c                | 1121 +++++++++++++
 examples/l2fwd-event/l2fwd_worker.h                |   16 +
 examples/l2fwd-event/main.c                        |  585 +++++++
 examples/l2fwd-event/meson.build                   |   14 +
 lib/librte_eal/common/eal_common_log.c             |    1 +
 lib/librte_eal/common/include/rte_log.h            |    1 +
 lib/librte_eventdev/Makefile                       |    6 +-
 lib/librte_eventdev/meson.build                    |    3 +
 lib/librte_eventdev/rte_eventdev_version.map       |    8 +
 lib/librte_eventdev/rte_eventmode_helper.c         | 1678 ++++++++++++++++++++
 lib/librte_eventdev/rte_eventmode_helper.h         |  241 +++
 .../rte_eventmode_helper_internal.h                |  144 ++
 lib/librte_eventdev/rte_eventmode_helper_prints.c  |  223 +++
 17 files changed, 4161 insertions(+), 2 deletions(-)
 create mode 100644 examples/l2fwd-event/Makefile
 create mode 100644 examples/l2fwd-event/l2fwd_common.h
 create mode 100644 examples/l2fwd-event/l2fwd_worker.c
 create mode 100644 examples/l2fwd-event/l2fwd_worker.h
 create mode 100644 examples/l2fwd-event/main.c
 create mode 100644 examples/l2fwd-event/meson.build
 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
 create mode 100644 lib/librte_eventdev/rte_eventmode_helper_prints.c

-- 
2.7.4