Re: [RFC] Testpmd Maintenance affecting DTS

[Thomas Monjalon <thomas@monjalon.net>]

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