DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Owen Hilyard <ohilyard@iol.unh.edu>
Cc: dts@dpdk.org, dev <dev@dpdk.org>, ci@dpdk.org, rasland@nvidia.com
Subject: Re: [RFC] Testpmd Maintenance affecting DTS
Date: Wed, 09 Feb 2022 09:53:44 +0100	[thread overview]
Message-ID: <5238984.Sb9uPGUboI@thomas> (raw)
In-Reply-To: <CAHx6DYBFV_rO6BafdrFNgyN5YHA78fg83MDw625qptTJDiWCiA@mail.gmail.com>

08/02/2022 22:34, Owen Hilyard:
> Currently, DTS tests DPDK via the example applications (/examples) and the
> apps (/app) included with DPDK. The DTS Working group has been trying to
> move to primarily using Testpmd, since it is the most complete and only
> using one application causes less maintenance work. Since Testpmd provides
> a text interface into DPDK, it must be continually updated to expose this
> new functionality, sometimes it may lag behind the current feature set of
> DPDK. For example, Testpmd currently does not support all of the options
> available for rte flow, which limits the testing coverage that can be
> provided by DTS for RTE flow. Because DTS is a Python application, it is
> not able to directly interface with DPDK. This means that whenever Testpmd
> falls behind DPDK, those unexposed parts of DPDK are functionally
> untestable as far as DTS is concerned. DTS is the tool used by the CI and
> labs to functionally test DPDK in a working configuration, compared to the
> unit testing, that may test individual components or parts of the stack.
> The DTS improvements WG and the Community Lab have a goal to continue the
> expansion of the test functional and performance test coverage of DPDK.
> This means that there must be some way for everything that the DPDK
> community wants to be tested to be exposed to DTS. I have a few possible
> solutions to this problem:
> 
> 
>    1.
> 
>    Continue to update Testpmd every time new functionality is added to DPDK
>    to expose that functionality

Yes, any feature in ethdev should have a testpmd entry.
Which part of rte_flow is not testable with testpmd?

In general, any device API should be testable with the app/ directory.

>    2.
> 
>    Use a parser generator or some other method to make adding new options
>    to Testpmd much easier, updating this every time new functionality is added
>    to testpmd

Please could you elaborate how it would work?

>    3.
> 
>    Create a dedicated testing application for DPDK that uses a binding
>    generator and Python’s XMLRPC to allow more programmatic access to DPDK on
>    the DUT, adding new RPC calls to expose new functionality.

Why do you need RPC when a binding is generated?

> I personally think that option 3 is the best because it would involve a bit
> of work up front to make it much easier to expose parts of DPDK to DTS.
> This is because after the initial work is done, we would just need to write
> a wrapper function in C to expose the functionality we want, and then
> expose the wrapper function via RPC.

I think having a Python binding has 3 drawbacks:
- performance is not good
- it is testing a binding, not the real API
- it is a huge maintenance effort for everybody


> If you have thoughts or suggestions, we will be discussing this at the DTS
> working group meeting.
> 
> 2:00 PM UTC, Wednesday, February 16
> https://armltd.zoom.us/j/97503259680?pwd=VVlmWnlnTXJkVGkwR2JOU3R3b3Vndz09&from=addon




  reply	other threads:[~2022-02-09  8:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08 21:34 Owen Hilyard
2022-02-09  8:53 ` Thomas Monjalon [this message]
2022-02-09 15:33   ` Owen Hilyard

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=5238984.Sb9uPGUboI@thomas \
    --to=thomas@monjalon.net \
    --cc=ci@dpdk.org \
    --cc=dev@dpdk.org \
    --cc=dts@dpdk.org \
    --cc=ohilyard@iol.unh.edu \
    --cc=rasland@nvidia.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).