Makes sense, thanks. I'll push it to next-dts.

Reviewed-by: Patrick Robb <probb@iol.unh.edu>

On Fri, Nov 14, 2025 at 1:59 PM Dean Marx <dmarx@iol.unh.edu> wrote:

> Rewrite the section of dts.rst outlining use of the DTS
> framework in writing test suites to properly reflect
> the current state of the DTS API and how to use it.
>
> Signed-off-by: Dean Marx <dmarx@iol.unh.edu>
> ---
>  doc/guides/tools/dts.rst | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/doc/guides/tools/dts.rst b/doc/guides/tools/dts.rst
> index f0abfdcb7a..195e8f752a 100644
> --- a/doc/guides/tools/dts.rst
> +++ b/doc/guides/tools/dts.rst
> @@ -503,20 +503,19 @@ Leveraging the DTS framework in writing testsuites
>
>  One should avoid directly importing DTS framework code to their
> testsuites where possible.
>  Instead, for performing common processes required in testsuites,
> -one should use (or add to) the list of methods provided in the
> ``Testsuite`` class
> -(the base class of all testsuites).
> +one should use (or add to) the list of methods provided in the ``api``
> module.
>
>  For instance, for sending a list of packets,
>  one should work through the packet transmitting function
> -already made available in the ``TestSuite`` class,
> +already made available in the ``api`` module,
>  instead of directly importing the DTS traffic generator class
>  and using that class in one's testsuite implementation.
>  It is also acceptable to import and instantiate classes for various DPDK
> applications.
>  For instance, writing a testsuite for a simple packet forwarding operation
> -would involve importing the DTS ``TestPmd`` class,
> +would involve importing the DTS ``TestPmd`` class from the ``api`` module,
>  instantiating ``TestPmd``, calling ``TestPmd``'s ``start()`` method,
>  and then sending traffic via one of the traffic transmitting functions
> -exposed in the ``Testsuite`` class.
> +exposed in the ``api`` module.
>
>  Test Case Verification
>  ~~~~~~~~~~~~~~~~~~~~~~
> --
> 2.51.0
>
>