From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id CEFA5A046B for ; Fri, 28 Jun 2019 11:07:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D4CED378E; Fri, 28 Jun 2019 11:07:47 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id 530013195; Fri, 28 Jun 2019 11:07:46 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id F014040014; Fri, 28 Jun 2019 11:07:45 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id DC07F40011; Fri, 28 Jun 2019 11:07:45 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.1 X-Spam-Score: -0.9 Received: from [192.168.1.59] (host-90-232-200-177.mobileonline.telia.com [90.232.200.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 346384000D; Fri, 28 Jun 2019 11:07:44 +0200 (CEST) To: Thomas Monjalon , Jerin Jacob Kollanukkaran , Anoob Joseph Cc: dev@dpdk.org, Nikhil Rao , Erik Gabriel Carrillo , Abhinandan Gujjar , Bruce Richardson , Pablo de Lara , Narayana Prasad Raju Athreya , Lukas Bartosik , Pavan Nikhilesh Bhagavatula , Hemant Agrawal , Nipun Gupta , Harry van Haaren , Liang Ma , "techboard@dpdk.org" References: <2775383.qy1u6QUkDx@xps> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: Date: Fri, 28 Jun 2019 11:07:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <2775383.qy1u6QUkDx@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.