From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by dpdk.org (Postfix) with ESMTP id 7559D1B01E for ; Wed, 24 Jan 2018 12:57:02 +0100 (CET) Received: by mail-vk0-f53.google.com with SMTP id j204so2340304vke.12 for ; Wed, 24 Jan 2018 03:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hN9Lu7KY55Ib+qGkXNjDif0T7lGGCvlTyz9AzVCYrjc=; b=bynZgJwmjWmwWC4SJucnx588+QSFyLa20iWLncePND7e9WYNUlcHaGzAofiNDv+nRZ AgBnmCmPCi3g8+anz/UZepC+oLnQSUXoDebiwJm+1jJ2LOgen38aXU1IgasSMSZiOwGB qWwgKAMYHcOq6leAoCHfssaAC3AP4rnTK3Z7Qs+61TNyl+398IDc4vwYrVoz07T6f+ga WuVC4UkSWvVZIoax2y1QFRZDLuAMlPtic2Zt2rlXuLBejXgUaH1iKqVQSgiyzSvN9QYP Mrrp14CT1J1MGbUzZ33BtPXK52PXSFrgRx+hrHcGWiLcZ2H8Ka3OyZIZZPRdZeU5rTXZ t7aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hN9Lu7KY55Ib+qGkXNjDif0T7lGGCvlTyz9AzVCYrjc=; b=b+9GpRIguI5eahxzSYZJe1aMoVLEEgPRM2xctMqreT+UYhJZ6cEOMJYDfVwxsKhXie t+wL6+JiZWIDtEv1HdQQyz/SPpJisfPlOXaJI7VjeyvrpAQ6rlzz0iUMHWxHhUSctsa3 NuWVbwOQ4wT3DPP9mfh6qmQYYw9MIXTyuppr7g14IAN4dJUQEkfqznZjJjbJmM9IcXmw dgXMm0MMaG2v68eBI50Ts3fBgT3WuKp8sQyiEg0DeXciez/UANKesk/E8Gj1fceHeqkR rjA3NE0GYDrUTB5yTBxCzDO13UdPcpLrpCGwScbUhdUEV8E/ZKHQG2wbAYOv6ZSzvWuH diDg== X-Gm-Message-State: AKwxytfh5cdA8AN4qVX6u7BrL2H/m2hB6dwybij+7naLBPPU8+5osIji TcN3XWBefCejC00wtAIqU9tK2w8BNiOKy3zmJUI= X-Google-Smtp-Source: AH8x224hh3qilLdgtDe1LjUBUoclcIdKs9ExcC1KC7B57/qYUwgVHm4ai5dNBFMaK+7iWnriHXUobhJS1rs2IWozWrQ= X-Received: by 10.31.200.133 with SMTP id y127mr4186722vkf.137.1516795021243; Wed, 24 Jan 2018 03:57:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.50.13 with HTTP; Wed, 24 Jan 2018 03:57:00 -0800 (PST) In-Reply-To: <20180116175454.GJ4256@6wind.com> References: <1515790887-64502-1-git-send-email-george.dit@gmail.com> <6A0DE07E22DDAD4C9103DF62FEBC09093B710648@shsmsx102.ccr.corp.intel.com> <20180116083958.hk4rtxfoa2y3uydk@platinum> <20180116092425.h4qecfmki2ih5shq@platinum> <20180116143132.GG4256@6wind.com> <20180116175454.GJ4256@6wind.com> From: george.dit@gmail.com Date: Wed, 24 Jan 2018 12:57:00 +0100 Message-ID: To: Adrien Mazarguil Cc: Olivier Matz , "Lu, Wenzhuo" , "dev@dpdk.org" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 1/3] app/testpmd: Moved cmdline_flow to librte_cmdline 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: , X-List-Received-Date: Wed, 24 Jan 2018 11:57:02 -0000 Hi again, I decided to simplify things for now, hence sent a new minimal patch only for testpmd (not librte_cmdline), which allows external applications to compile against it without errors. Thanks again for you time, Georgios On Tue, Jan 16, 2018 at 6:54 PM, Adrien Mazarguil wrote: > On Tue, Jan 16, 2018 at 03:54:57PM +0100, george.dit@gmail.com wrote: >> Hi Adrien, >> >> Thanks for your insights and sorry for omitting the cover letter (this is >> my first patch in DPDK). > > No problem, don't worry about that. Remember to put as much context as close > as possible to the related changes. The commit log of a patch is in fact a > more appropriate place since a cover letter is simply a summary of a > subsequent series and is discarded once applied. > >> I understand your concerns. The reason I proposed this patch is to >> facilitate a more high level vendor agnostic API for configuring and >> monitoring DPDK-based NICs. >> >> To avoid just copying thousands of lines of code into my application, do >> you think it is feasible to move at least the components (struct context, >> struct arg, struct token and the parse_* helpers) you mentioned and >> restructure testpmd in a way that allows applications to re-use all of its >> parsing features? > > Yes I think it's feasible, although at the cost of great effort because > you'd need to untangle engine code from parser code to expose the former, > the flow command being a mix of both. Proper APIs must be devised for that, > hence my question: is it really worth the trouble? > > Other contributors already asked me how they could reuse the flow command > parser to implement similar testpmd commands without copy/pasting the entire > file, so I'm already convinced separating at least the engine part makes > sense at the testpmd level. Moving it to librte_cmdline for external > applications seems more complex though. > >> I could give it a try and come back with a new patch, otherwise I am >> perfectly ok if you want to do it instead. > > While I'd certainly like to do it (at least at the testpmd level), it's > unlikely to happen anytime soon due to other priorities. > > Feel free to take care of it if you're motivated enough, just keep in mind > right now I don't think this should be exposed as a public API. I can change > my mind if you manage to make it generic enough. > >> On Tue, Jan 16, 2018 at 3:31 PM, Adrien Mazarguil < >> adrien.mazarguil@6wind.com> wrote: >> >> > George, >> > >> > I missed the original RFC thread [1][2] (you should have used it as a cover >> > letter for this series BTW) please see below. >> > >> > On Tue, Jan 16, 2018 at 10:24:25AM +0100, Olivier Matz wrote: >> > > Hi, >> > > >> > > > On Tue, Jan 16, 2018 at 9:40 AM Olivier Matz >> > wrote: >> > > > >> > > > On Tue, Jan 16, 2018 at 08:45:32AM +0000, george.dit@gmail.com wrote: >> > > > > Hi Georgios, >> > > > > >> > > > > On Mon, Jan 15, 2018 at 01:30:35AM +0000, Lu, Wenzhuo wrote: >> > > > > > Hi, >> > > > > > >> > > > > > > -----Original Message----- >> > > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Georgios >> > Katsikas >> > > > > > > Sent: Saturday, January 13, 2018 5:01 AM >> > > > > > > To: olivier.matz@6wind.com >> > > > > > > Cc: dev@dpdk.org; Georgios Katsikas >> > > > > > > Subject: [dpdk-dev] [PATCH 1/3] app/testpmd: Moved cmdline_flow >> > to >> > > > > > > librte_cmdline >> > > > > > > >> > > > > > > Signed-off-by: Georgios Katsikas >> > > > > > Looks like a good idea to move this code to the lib. >> > > > > > cc Adrien the author of this file, app/test-pmd/cmdline_flow.c. >> > > > > >> > > > > If the command line parsing of rte_flow is something that has some >> > > > > chances to be shared among multiple applications, I agree it makes >> > sense >> > > > > to move it in a library. >> > > > > >> > > > > However, my opinion is that it would be better to have a specific >> > > > > library for it, like librte_flow_cmdline, because I'm not sure that >> > > > > people linking with librte_cmdline always want to pull the rte_flow >> > > > > parsing code. >> > >> > In my opinion the entire flow command parser has nothing to do outside >> > testpmd, it's way too specific, even if another application finds it >> > useful. >> > >> > Code duplication being a bad thing, your application could as well compile >> > or even #include app/test-pmd/cmdline_flow.c directly (not pretty, I know) >> > since it would have the same internal layout as testpmd. Testpmd's Makefile >> > could be modified to spit it out as a separate library if needed. >> > >> > What could make more sense would be to extract the parser engine for >> > librte_cmdline's dynamic tokens (e.g. struct context, struct arg, struct >> > token) and possibly various generic helpers (e.g. parse_string, >> > parse_mac_addr), but not enum index nor token_list[] and friends which >> > define the layout of testpmd's flow command. >> > >> > This would enable other flow-like commands without duplicating the engine >> > every time, however I'm still not sure if making it available outside >> > testpmd is a good idea. Extracting and making it fully generic will require >> > a considerable amount of work. >> > >> > > > Hi Lu, Oliver, >> > > > >> > > > Thanks for your feedback! >> > > > You have a point here, flow commands are only a subset of the parser. >> > > > Do you want me to create this new library and send another patch? >> > > >> > > Let's first wait for Adrien's feedback, he can have counter-arguments. >> > > >> > > > I guess I have to use librte_cmdline as a template/example for >> > creating the >> > > > librte_flow_cmdline library. >> > > >> > > It can be used as an example for Makefile and .map file. >> > >> > I'm not opposed to the idea of exporting the parser engine after making it >> > properly generic, but please reconsider. Testpmd is an application made to >> > validate PMD functionality. The flow command implementation, as neat as it >> > is, remains a complex wrapper on top of the cmdline_parse API which wasn't >> > originally designed for dynamic tokens. Its syntax may evolve without >> > warning if deemed necessary. Making it public will subject it to exported >> > API/ABI constraints and likely impede future evolution. >> > >> > Assuming your application is not dragging testpmd's legacy, I think it >> > would >> > be wiser to re-implement a simpler flow command look-alike on top of a more >> > suitable command-line handling library if you like its syntax. >> > >> > [1] http://dpdk.org/ml/archives/dev/2018-January/086872.html >> > [2] Message-ID: CAN9HtFDz+imqbCKfs6a0NE0W7iF8C+-KiNB0nCRywimspjfEDg@mail. >> > gmail.com >> > >> > -- >> > Adrien Mazarguil >> > 6WIND >> > >> >> >> >> -- >> Georgios Katsikas >> Industrial Ph.D. Student >> Network Intelligence Group >> Decision, Networks, and Analytics (DNA) Lab >> RISE SICS >> E-Mail: georgios.katsikas@ri.se > > -- > Adrien Mazarguil > 6WIND -- Georgios Katsikas Industrial Ph.D. Student Network Intelligence Group Decision, Networks, and Analytics (DNA) Lab RISE SICS E-Mail: georgios.katsikas@ri.se