From: george.dit@gmail.com
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Move flow parsing from test-pmd to librte_cmdline
Date: Fri, 12 Jan 2018 11:57:46 +0100 [thread overview]
Message-ID: <CAN9HtFAm4BknN50zxqF-s7AqvDCWrhD43kHd8eT0MNbrQXyM0Q@mail.gmail.com> (raw)
In-Reply-To: <20180112103834.br6bq5z3sm7o2tkz@bidouze.vm.6wind.com>
Hi Gaetan,
Thanks for your quick and positive reply, I will submit a patch today.
Best regards,
Georgios
On Fri, Jan 12, 2018 at 11:38 AM, Gaëtan Rivet <gaetan.rivet@6wind.com>
wrote:
> Hi George,
>
> On Fri, Jan 12, 2018 at 10:21:41AM +0100, george.dit@gmail.com wrote:
> > Dear DPDK developers,
> >
> > In an attempt to integrate the Flow API into a third party application
> and
> > allow the e.g., insertion/deletion of NIC classification rules from that
> > application, I noticed that flow command parsing as per the most recent
> > DPDK versions (i.e., 17.08 or 17.11) might benefit from some useful
> > modifications.
> >
> > Specifically, librte_cmdline provides libraries for parsing a flow
> command
> > into tokens, but then the library for e.g., creating/deleting a flow rule
> > for a DPDK NIC resides in test-pmd (app/test-pmd/cmdline_flow.c).
> >
> > My proposal is to move the app/test-pmd/cmdline_flow.c library into
> > librte_cmdline, thus facilitate flow parsing for third party DPDK
> > applications.
> > I have a working prototype for both DPDK 17.08 and 17.11. This prototype
> > extends librte_cmdline with 2 additional files (cmdline_flow.h and .c)
> and
> > removes this functionality from test-pmd.
> > The benefit is that the functions in cmdline_flow.h can now be re-used by
> > any DPDK applications, which was not the case before.
> >
> > Do you think that the DPDK community will benefit from my patch? If so, I
> > am happy to send you the patch for review and get your feedback to
> further
> > improve it.
> > In case I missed some other way to achieve my goal (without the need to
> > patch DPDK), please let me know.
> >
> > Best regards,
>
> My opinion would that it might be interesting to have parsing helpers
> available for complex APIs such as this one, ready to be dropped into
> applications.
>
> There were contentions not too long ago about the status of rte_cmdline,
> but in any case I think it could be interesting to have your input on
> this.
>
> So don't hesitate to send it.
>
> Cheers,
> --
> Gaėtan Rivet
> 6WIND
>
--
Georgios Katsikas
Industrial Ph.D. Student
Network Intelligence Group
Decision, Networks, and Analytics (DNA) Lab
RISE SICS
E-Mail: georgios.katsikas@ri.se
prev parent reply other threads:[~2018-01-12 10:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 9:21 george.dit
2018-01-12 10:38 ` Gaëtan Rivet
2018-01-12 10:57 ` george.dit [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAN9HtFAm4BknN50zxqF-s7AqvDCWrhD43kHd8eT0MNbrQXyM0Q@mail.gmail.com \
--to=george.dit@gmail.com \
--cc=dev@dpdk.org \
--cc=gaetan.rivet@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).