[RFC] Testpmd Maintenance affecting DTS
Thomas Monjalon
thomas at monjalon.net
Wed Feb 9 09:53:44 CET 2022
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
More information about the dts
mailing list