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

["Mattias Rönnblom" <mattias.ronnblom@ericsson.com>]

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.