[dts][PATCH V1 1/3] test_plan/unit_tests_*: remove unit case plan

[Weiyuan Li <weiyuanx.li@intel.com>]

Remove unit case plan.

Signed-off-by: Weiyuan Li <weiyuanx.li@intel.com>
---
 test_plans/unit_tests_cmdline_test_plan.rst   |  28 --
 test_plans/unit_tests_crc_test_plan.rst       |  65 ----
 .../unit_tests_cryptodev_func_test_plan.rst   |  56 ---
 test_plans/unit_tests_dump_test_plan.rst      | 258 --------------
 test_plans/unit_tests_eal_test_plan.rst       | 327 ------------------
 .../unit_tests_event_timer_test_plan.rst      |  22 --
 test_plans/unit_tests_kni_test_plan.rst       |  42 ---
 test_plans/unit_tests_loopback_test_plan.rst  |  61 ----
 test_plans/unit_tests_lpm_test_plan.rst       |  94 -----
 test_plans/unit_tests_mbuf_test_plan.rst      |  41 ---
 test_plans/unit_tests_mempool_test_plan.rst   |  46 ---
 test_plans/unit_tests_pmd_perf_test_plan.rst  |  55 ---
 test_plans/unit_tests_power_test_plan.rst     |  63 ----
 test_plans/unit_tests_qos_test_plan.rst       |  83 -----
 test_plans/unit_tests_ring_test_plan.rst      |  98 ------
 test_plans/unit_tests_ringpmd_test_plan.rst   |  34 --
 test_plans/unit_tests_timer_test_plan.rst     |  69 ----
 17 files changed, 1442 deletions(-)
 delete mode 100644 test_plans/unit_tests_cmdline_test_plan.rst
 delete mode 100644 test_plans/unit_tests_crc_test_plan.rst
 delete mode 100644 test_plans/unit_tests_cryptodev_func_test_plan.rst
 delete mode 100644 test_plans/unit_tests_dump_test_plan.rst
 delete mode 100644 test_plans/unit_tests_eal_test_plan.rst
 delete mode 100644 test_plans/unit_tests_event_timer_test_plan.rst
 delete mode 100644 test_plans/unit_tests_kni_test_plan.rst
 delete mode 100644 test_plans/unit_tests_loopback_test_plan.rst
 delete mode 100644 test_plans/unit_tests_lpm_test_plan.rst
 delete mode 100644 test_plans/unit_tests_mbuf_test_plan.rst
 delete mode 100644 test_plans/unit_tests_mempool_test_plan.rst
 delete mode 100644 test_plans/unit_tests_pmd_perf_test_plan.rst
 delete mode 100644 test_plans/unit_tests_power_test_plan.rst
 delete mode 100644 test_plans/unit_tests_qos_test_plan.rst
 delete mode 100644 test_plans/unit_tests_ring_test_plan.rst
 delete mode 100644 test_plans/unit_tests_ringpmd_test_plan.rst
 delete mode 100644 test_plans/unit_tests_timer_test_plan.rst

diff --git a/test_plans/unit_tests_cmdline_test_plan.rst b/test_plans/unit_tests_cmdline_test_plan.rst
deleted file mode 100644
index 765f26ec..00000000
--- a/test_plans/unit_tests_cmdline_test_plan.rst
+++ /dev/null
@@ -1,28 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2010-2017 Intel Corporation
-
-===================
-Unit Tests: Cmdline
-===================
-This is the test plan for the Intel® DPDK Random Early Detection feature.
-
-This section explains how to run the unit tests for cmdline. The test can be launched
-independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> cmdline_autotest
-
-The final output of the test has to be "Test OK"
diff --git a/test_plans/unit_tests_crc_test_plan.rst b/test_plans/unit_tests_crc_test_plan.rst
deleted file mode 100644
index d7ce62f0..00000000
--- a/test_plans/unit_tests_crc_test_plan.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2017 Intel Corporation
-
-===============
-Unit Tests: CRC
-===============
-
-the unit test compare the results of scalar and sse4.2 versions individually
-with the known crc results. Some of these crc results and corresponding test
-vectors are based on the test string mentioned in ethernet specification doc
-and x.25 doc
-
-This section explains how to run the unit tests for crc computation. The test
-can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> crc_autotest
-
-The final output of the test will have to be "Test OK".
-
-Algorithm Description
-=====================
-
-In some applications, CRC (Cyclic Redundancy Check) needs to be computed
-or updated during packet processing operations. This patchset adds software
-implementation of some common standard CRCs (32-bit Ethernet CRC as per
-Ethernet/[ISO/IEC 8802-3] and 16-bit CCITT-CRC [ITU-T X.25]).
-Two versions of each 32-bit and 16-bit CRC calculation are proposed.
-
-The first version presents a fast and efficient CRC generation on
-IA processors by using the carry-less multiplication instruction PCLMULQDQ
-(i.e SSE4.2 intrinsics). In this implementation, a parallelized folding
-approach has been used to first reduce an arbitrary length buffer to a small
-fixed size length buffer (16 bytes) with the help of precomputed constants.
-The resultant single 16-bytes chunk is further reduced by Barrett reduction
-method to generate final CRC value. For more details on the implementation,
-see reference [1].
-
-The second version presents the fallback solution to support the
-CRC generation without needing any specific support from CPU (for examples-
-SSE4.2 intrinsics). It is based on generic Look-Up Table(LUT) algorithm
-that uses precomputed 256 element table as explained in reference[2].
-
-During initialization, all the data structures required for CRC computation
-are initialized. Also, x86 specific crc implementation
-(if supported by the platform) or scalar version is enabled.
-
-References:
-[1] Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction
-http://www.intel.com/content/dam/www/public/us/en/documents/allow-papers
-/fast-crc-computation-generic-polynomials-pclmulqdq-paper.pdf
-[2] A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS
-http://www.ross.net/crc/download/crc_v3.txt
diff --git a/test_plans/unit_tests_cryptodev_func_test_plan.rst b/test_plans/unit_tests_cryptodev_func_test_plan.rst
deleted file mode 100644
index 42d65616..00000000
--- a/test_plans/unit_tests_cryptodev_func_test_plan.rst
+++ /dev/null
@@ -1,56 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2016-2017 Intel Corporation
-
-=====================
-Unit Tests: Cryptodev
-=====================
-
-
-Description
-===========
-
-This document provides the plan for testing Cryptodev API via Cryptodev unit tests.
-Unit tests include supported Hardware and Software PMD(polling mode device) and supported algorithms.
-Cryptodev API provides ability to do encryption/decryption by integrating QAT(Intel@ QuickAssist
-Technology) into DPDK. The QAT provides poll mode crypto driver support for
-Intel@ QuickAssist Adapter 8950 hardware accelerator.
-
-The testing of Crytpodev API should be tested under either Intel QuickAssist Technology DH895xxC hardware
-accelerator or AES-NI library.
-
-This test suite will run all cryptodev related unit test cases. Alternatively, you could execute
-the unit tests manually by app/test DPDK application.
-
-Unit Test List
-==============
-
-- cryptodev_qat_autotest
-- cryptodev_aesni_mb_autotest
-- cryptodev_openssl_autotest
-- cryptodev_aesni_gcm_autotest
-- cryptodev_null_autotest
-- cryptodev_sw_snow3g_autotest
-- cryptodev_sw_kasumi_autotest
-- cryptodev_sw_zuc_autotest
-- cryptodev_scheduler_autotest
-
-
-Test Case Setup
-===============
-
-#. Build DPDK and app/test app
-    CC=gcc meson -Denable_kmods=True -Dlibdir=lib  --default-library=static x86_64-native-linuxapp-gcc
-    ninja -C x86_64-native-linuxapp-gcc -j 110
-
-#. Bind cryptodev devices to vfio-pci driver when test cryptodev_qat_autotest
-   ./dpdk/usertools/dpdk-devbind.py --status-dev crypto
-   ./dpdk/usertools/dpdk-devbind.py --force --bind=vfio-pci 000:1a:01.0
-
-#. Manually verify the app/test by this command, as example, in your build folder::
-
-     ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -c 1 -n 1
-     RTE>> cryptodev_qat_autotest
-
-All Unit Test Cases are listed above.
-
-Expected all tests could pass in testing.
diff --git a/test_plans/unit_tests_dump_test_plan.rst b/test_plans/unit_tests_dump_test_plan.rst
deleted file mode 100644
index ef61b307..00000000
--- a/test_plans/unit_tests_dump_test_plan.rst
+++ /dev/null
@@ -1,258 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2014-2017 Intel Corporation
-
-=====================
-Unit Tests: Dump Ring
-=====================
-
-This is the test plan for dumping the elements of Intel® DPDK ring.
-
-This section explains how to run the unit tests for dumping elements of ring.
-The test can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> dump_ring
-
-The final output of the test will be detailed elements of DPDK ring.
-
-Dump the elements of designative DPDK ring::
-
-  RTE>> dump_ring <ring_name>
-
-The final output of the test will be detailed elements of the designative DPDK ring.
-
-========================
-Unit Tests: Dump Mempool
-========================
-
-This is the test plan for dumping the elements of Intel® DPDK mempool.
-
-This section explains how to run the unit tests for dumping elements of mempool.
-The test can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> dump_mempool
-
-The final output of the test will be detailed elements of DPDK mempool.
-
-Dump the elements if designative DPDK mempool::
-
-  RTE>> dump_mempool <mempool_name>
-
-The final output of the test will be detailed elements of the designative DPDK mempool.
-
-================================
-Unit Tests: Dump Physical Memory
-================================
-
-This is the test plan for dumping the elements of Intel® DPDK physical memory.
-
-This section explains how to run the unit tests for dumping elements of memory.
-The test can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> dump_physmem
-
-The final output of the test will be detailed elements of DPDK physical memory.
-
-========================
-Unit Tests: Dump Memzone
-========================
-
-This is the test plan for dumping the elements of Intel® DPDK memzone.
-
-This section explains how to run the unit tests for dumping elements of memzone.
-The test can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> dump_memzone
-
-The final output of the test will be detailed elements of DPDK memzone.
-
-============================
-Unit Tests: Dump Struct Size
-============================
-
-This is the test plan for dumping the size of Intel® DPDK structure.
-
-This section explains how to run the unit tests for dumping structure size.
-The test can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> dump_struct_sizes
-
-The final output of the test will be the size of DPDK structure.
-
-========================
-Unit Tests: Dump Devargs
-========================
-
-This is the test plan for dumping device arguments of Intel® DPDK.
-
-This section explains how to run the unit tests for dumping device arguments.
-The test can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff -a|-b pci_address
-  RTE>> dump_devargs
-
-The final output of the test will be the pci address of allow list
-or block list.
-
-=============================
-Unit Tests: Dump malloc stats
-=============================
-
-This is the test plan for dumping malloc stats of Intel® DPDK heaps.
-
-This section explains how to run the unit tests for dumping malloc stats.
-The test can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> dump_malloc_stats
-
-The final output of the test will be the malloc stats of DPDK heap.
-
-=============================
-Unit Tests: Dump malloc heaps
-=============================
-
-This is the test plan for dumping detailed malloc status of each Intel® DPDK heap.
-
-This section explains how to run the unit tests for dumping malloc heaps.
-The test can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> dump_malloc_heaps
-
-The final output of the test will be the detailed malloc status of each DPDK heap.
-
-==========================
-Unit Tests: Dump log types
-==========================
-
-This is the test plan for dumping log level of all Intel® DPDK log types.
-
-This section explains how to run the unit tests for dumping log types.
-The test can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> dump_log_types
-
-The final output of the test will be the log level of each DPDK log type.
diff --git a/test_plans/unit_tests_eal_test_plan.rst b/test_plans/unit_tests_eal_test_plan.rst
deleted file mode 100644
index abfb4032..00000000
--- a/test_plans/unit_tests_eal_test_plan.rst
+++ /dev/null
@@ -1,327 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2010-2017 Intel Corporation
-
-===============
-Unit Tests: EAL
-===============
-
-This section describes the tests that are done to validate the EAL. Each
-test can be launched independently using the command line
-interface. These tests are implemented as a linuxapp environment
-application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-Version
-=======
-
-To Be Filled
-
-
-Common
-=======
-
-To Be Filled
-
-Eal_fs
-======
-
-To Be Filled
-
-Memory
-======
-
-- Dump the mapped memory. The python-expect script checks that at
-  least one line is dumped.
-
-- Check that memory size is different than 0.
-
-- Try to read all memory; it should not segfault.
-
-PCI
-===
-
-- Register a driver with a ``devinit()`` function.
-
-- Dump all PCI devices.
-
-- Check that the ``devinit()`` function is called at least once.
-
-Per-lcore Variables and lcore Launch
-====================================
-
-- Use ``rte_eal_mp_remote_launch()`` to call ``assign_vars()`` on
-  every available lcore. In this function, a per-lcore variable is
-  assigned to the lcore_id.
-
-- Use ``rte_eal_mp_remote_launch()`` to call ``display_vars()`` on
-  every available lcore. The function checks that the variable is
-  correctly set, or returns -1.
-
-- If at least one per-core variable was not correct, the test function
-  returns -1.
-
-Spinlock
-========
-
-- There is a global spinlock and a table of spinlocks (one per lcore).
-
-- The test function takes all of these locks and launches the
-  ``test_spinlock_per_core()`` function on each core (except the master).
-
-  - The function takes the global lock, displays something, then releases
-    the global lock.
-  - The function takes the per-lcore lock, displays something, then releases
-    the per-core lock.
-
-- The main function unlocks the per-lcore locks sequentially and
-  waits between each lock. This triggers the display of a message
-  for each core, in the correct order. The autotest script checks that
-  this order is correct.
-
-Atomic Variables
-================
-
-- The main test function performs three subtests. The first test
-  checks that the usual inc/dec/add/sub functions are working
-  correctly:
-
-  - Initialize 32-bit and 64-bit atomic variables to specific
-    values.
-
-  - These variables are incremented and decremented on each core at
-    the same time in ``test_atomic_usual()``.
-
-  - The function checks that once all lcores finish their function,
-    the value of the atomic variables are still the same.
-
-- The second test verifies the behavior of "test and set" functions.
-
-  - Initialize 32-bit and 64-bit atomic variables to zero.
-
-  - Invoke ``test_atomic_tas()`` on each lcore before doing anything
-    else. The cores are awaiting synchronization using the ``while
-    (rte_atomic32_read(&val) == 0)`` statement which is triggered by the
-    main test function. Then all cores do an
-    ``rte_atomicXX_test_and_set()`` at the same time. If it is successful,
-    it increments another atomic counter.
-
-  - The main function checks that the atomic counter was incremented
-    twice only (one for 32-bit and one for 64-bit values).
-
-- Test "add/sub and return"
-
-  - Initialize 32-bit and 64-bit atomic variables to zero.
-
-  - Invoke ``test_atomic_addsub_return()`` on each lcore. Before doing
-    anything else, the cores are waiting a synchro. Each lcore does
-    this operation several times::
-
-      tmp = atomic_add_return(&a, 1);
-      atomic_add(&count, tmp);
-      tmp = atomic_sub_return(&a, 1);
-      atomic_sub(&count, tmp+1);
-
-  - At the end of the test, the *count* value must be 0.
-
-Prefetch
-========
-
-Just test that the macro can be called and validate the compilation.
-The test always return success.
-
-Byteorder functions
-===================
-
-Check the result of optimized byte swap functions for each size (16-,
-32- and 64-bit).
-
-Logs
-====
-
-- Enable log types.
-- Set log level.
-- Execute logging functions with different types and levels; some should
-  not be displayed.
-
-Memzone
-=======
-
-- Search for three reserved zones or reserve them if they do not exist:
-
-  - One is on any socket id.
-  - The second is on socket 0.
-  - The last one is on socket 1 (if socket 1 exists).
-
-- Check that the zones exist.
-
-- Check that the zones are cache-aligned.
-
-- Check that zones do not overlap.
-
-- Check that the zones are on the correct socket id.
-
-- Check that a lookup of the first zone returns the same pointer.
-
-- Check that it is not possible to create another zone with the
-  same name as an existing zone.
-
-Memcpy
-======
-
-Create two buffers, and initialize one with random values. These are copied
-to the second buffer and then compared to see if the copy was successful.
-The bytes outside the copied area are also checked to make sure they were not
-changed.
-
-This is repeated for a number of different sizes and offsets, with
-the second buffer being cleared before each test.
-
-Debug test
-==========
-
-- Call rte_dump_stack() and rte_dump_registers().
-
-CPU flags
-=========
-
-- Using the rte_cpu_get_flag_enabled() checks for CPU features from different CPUID tables
-- Checks if rte_cpu_get_flag_enabled() properly fails on trying to check for invalid feature
-
-
-Errno
-=====
-
-Performs validation on the error message strings provided by the rte_strerror() call, to ensure that suitable strings are returned for the rte-specific error codes, as well as ensuring that for standard error codes the correct error message is returned.
-
-Interrupts
-==========
-- Check that the callback for the specific interrupt can be called.
-- Check that it is not possible to register a callback to an invalid interrupt handle.
-- Check that it is not possible to register no callback to an interrupt handle.
-- Check that it is not possible to unregister a callback to an invalid interrupt handle.
-- Check that multiple callbacks are registered to the same interrupt handle.
-- Check that it is not possible to unregister a callback with invalid parameter.
-- Check that it is not possible to enable an interrupt with invalid handle or wrong handle type.
-- Check that it is not possible to disable an interrupt with invalid handle or wrong handle type.
-
-
-Multiprocess
-============
-
-Validates that a secondary DPDK instance can be run alongside a primary when the appropriate EAL command-line flags are passed. Also validates that secondary processes cannot interfere with primary processes by creating memory objects, such as mempools or rings.
-
-String
-======
-
-Performs validation on the new string functions provided in rte_string_fns.h, ensuring that all values returned are NULL terminated, and that suitable errors are returned when called with invalid parameters.
-
-Tailq
-=====
-
-Validates that we can create and perform lookups on named tail queues within the EAL for various object types. Also ensures appropriate error codes are returned from the functions if invalid parameters are passed.
-
-Devargs
-=======
-To Be Filled
-
-Kvargs
-======
-To Be Filled
-
-Acl
-===
-Performs ACL functional validation.
-If DPDK version permits, then start with " --force-max-simd-bitwidth=0" EAL parameter.
-That will ensure validation of all supported on given HW ACL algorithms.
-
-Link_bonding
-============
-To Be Filled
-
-Hash
-====
-This does unit function test for hash features:
-
-- Average table utilization when disable extendable table function
-- Average table utilization when enable extendable table function,
-  check could reach 100% utilization
-
-
-Hash_perf
-=========
-This does the performance test with a single thread, including the cases
-with and without extendable table:
-
-- Measure cycles for add, lookup, lookup_bulk, delete
-- With/without pre-computed hash values
-- For different key lengths
-
-
-Hash_functions
-==============
-This does unit test for hash functions:
-
-- Measure cycles for hashing
-- Jhash vs rte_hash_crc
-- For different key lenthgs, seeds
-
-
-Hash_multiwriter
-================
-This does the performance and function test of multi-threads case
-– multiple writers.
-
-Introduce scalable multi-writer Cuckoo Hash insertion based on a split
-cuckoo search and move operation using Intel TSX. It can do scalable
-hash insertion with 22 cores with little performance loss and negligible
-TSX abortion rate.
-
-
-Hash_readwrite
-==============
-This does the performance and function test of multi-threads
-case – multiple reader/writer.
-
-Read-write concurrency support in rte_hash. A new flag value is added to
-indicate if read-write concurrency is needed during creation time.
-The new concurrency model is based on rte_rwlock. When Intel TSX is
-available and the users indicate to use it, the TM version of the
-rte_rwlock will be called. Both multi-writer and read-write concurrency
-are protected by the rte_rwlock instead of the x86 specific RTM
-instructions, so the x86 specific header rte_cuckoo_hash_x86.h is removed
-and the code is infused into the main .c file.
-A new rte_hash_count API is proposed to count how many keys are inserted
-into the hash table.
-
-
-Hash_hash_readwrite_lf
-======================
-This does the unit tests to check for hash lookup and bulk-lookup perf
-with lock-free enabled and with lock-free disabled. Unit tests performed
-with readers running in parallel with writers.
-Tests include:
-
-- Hash lookup on existing keys
-
-  - Hash add causing NO key-shifts of existing keys in the table
-
-- Hash lookup on existing keys likely to be on shift-path
-
-  - Hash add causing key-shifts of existing keys in the table
-
-- Hash lookup on existing keys NOT likely to be on shift-path
-
-  - Hash add causing key-shifts of existing keys in the table
-
-- Hash lookup on non-existing keys
-
-  - Hash add causing NO key-shifts of existing keys in the table
-  - Hash add causing key-shifts of existing keys in the table
-
-- Hash lookup on keys likely to be on shift-path
-
-  - Multiple writers causing key-shifts of existing keys in the table
diff --git a/test_plans/unit_tests_event_timer_test_plan.rst b/test_plans/unit_tests_event_timer_test_plan.rst
deleted file mode 100644
index c1135c06..00000000
--- a/test_plans/unit_tests_event_timer_test_plan.rst
+++ /dev/null
@@ -1,22 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2019 Marvell International Ltd
-
-=======================
-Unit Tests: Event Timer
-=======================
-This is the test plan for Event Timer Adapter auto test.
-
-This section explains how to run the unit tests for event_timer_adapter. The
-test can be launched independently using the command line interface.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff -a <timerdev-pci-bus-id>,<devargs>
-  RTE>> event_timer_adapter_test
-
-The final output of the test has to be "Test OK"
diff --git a/test_plans/unit_tests_kni_test_plan.rst b/test_plans/unit_tests_kni_test_plan.rst
deleted file mode 100644
index 163fff20..00000000
--- a/test_plans/unit_tests_kni_test_plan.rst
+++ /dev/null
@@ -1,42 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2010-2017 Intel Corporation
-
-===============
-Unit Tests: KNI
-===============
-
-This is the test plan for the Intel® DPDK KNI library.
-
-This section explains how to run the unit tests for KNI. The test can be
-launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-Case config::
-
-   For enable KNI features, need to add "-Denable_kmods=True" when build DPDK by meson.
-   CC=gcc meson -Denable_kmods=True -Dlibdir=lib  --default-library=static x86_64-native-linuxapp-gcc
-   ninja -C x86_64-native-linuxapp-gcc -j 50
-
-   rte_kni.ko is located at ./x86_64-native-linuxapp-gcc/kernel/linux/kni/
-
-The steps to run the unit test manually are as follow::
-
-  # mkdir -p x86_64-native-linuxapp-gcc/kmod
-  # cp ./x86_64-native-linuxapp-gcc/kernel/linux/kni/rte_kni.ko x86_64-native-linuxapp-gcc/kmod/
-  # cp ./x86_64-native-linuxapp-gcc/kernel/linux/igb_uio/igb_uio.ko x86_64-native-linuxapp-gcc/kmod/
-  # lsmod | grep rte_kni
-  # insmod ./<TARGET>/kmod/igb_uio.ko
-  # insmod ./<TARGET>/kmod/rte_kni.ko lo_mode=lo_mode_fifo
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test  -n 1 -c ffff
-  RTE>> kni_autotest
-  RTE>> quit
-  # rmmod rte_kni
-  # rmmod igb_uio
-
-
-The final output of the test has to be "Test OK"
diff --git a/test_plans/unit_tests_loopback_test_plan.rst b/test_plans/unit_tests_loopback_test_plan.rst
deleted file mode 100644
index ed9351db..00000000
--- a/test_plans/unit_tests_loopback_test_plan.rst
+++ /dev/null
@@ -1,61 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2014-2017 Intel Corporation
-
-====================================
-Unit Tests: single port MAC loopback
-====================================
-
-According to loopback mode, setup loopback link or not.
-If loopback mode is setted, packets will be sent to rx_q from tx_q directly.
-Else if loopback mode is disabled, packets will sent to peer port from tx_q.
-Loopback mode can be used to support testing task.
-
-
-Prerequisites
-=============
-
-Two 10Gb/25Gb/40Gb Ethernet ports of the DUT are directly connected and link is up.
-
-
-single port MAC loopback
-========================
-
-This is the test plan for unit test to verify if X710/XL710/XXV710 can enable single port
-mac loopback.
-
-Test Case: enable loopback mode
-===============================
-
-In dpdk/test/test/test_pmd_perf.c
-Set::
-
-    .lpbk_mode=1
-    #define MAX_TRAFFIC_BURST              32
-
-Then make test
-Start test::
-
-    ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -c f -n 4 -- -i
-    RTE>>pmd_perf_autotest
-
-The final output of the test will be matrix of average cycles of IO used per
-packet, and "Test OK" is printed out.
-The peer port can't receive any packet.
-
-Test Case: disable lookback mode
-================================
-
-In dpdk/test/test/test_pmd_perf.c
-Set::
-
-    .lpbk_mode=0
-    #define MAX_TRAFFIC_BURST              32
-
-Then make test
-Start test::
-
-    ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -c f -n 4 -- -i
-    RTE>>pmd_perf_autotest
-
-There is not "Test OK" presented.
-The peer port can receive all the 32 packets.
diff --git a/test_plans/unit_tests_lpm_test_plan.rst b/test_plans/unit_tests_lpm_test_plan.rst
deleted file mode 100644
index 85579f2a..00000000
--- a/test_plans/unit_tests_lpm_test_plan.rst
+++ /dev/null
@@ -1,94 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2010-2017 Intel Corporation
-
-===============
-Unit Tests: LPM
-===============
-
-This is the test plan for the Intel®  DPDK LPM Method.
-
-This section explains how to run the unit tests for LPM.The test can be
-launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> lpm_autotest
-
-
-The final output of the test has to be "Test OK"
-
-====================
-Unit Tests: LPM_ipv6
-====================
-
-This is the test plan for the Intel®  DPDK LPM Method in IPv6.
-
-This section explains how to run the unit tests for LPM in IPv6.The test can be
-launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> lpm6_autotest
-
-
-The final output of the test has to be "Test OK"
-
-
-====================
-Unit Tests: LPM_perf
-====================
-
-This section explains how to run the unit tests for LPM performance.
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> lpm_perf_autotest
-
-The final output of the test has to be "Test OK"
-
-
-=========================
-Unit Tests: LPM_ipv6_perf
-=========================
-
-This section explains how to run the unit tests for LPM IPv6
-performance. The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> lpm6_perf_autotest
-
-The final output of the test has to be "Test OK"
diff --git a/test_plans/unit_tests_mbuf_test_plan.rst b/test_plans/unit_tests_mbuf_test_plan.rst
deleted file mode 100644
index 4477aea7..00000000
--- a/test_plans/unit_tests_mbuf_test_plan.rst
+++ /dev/null
@@ -1,41 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2010-2017 Intel Corporation
-
-================
-Unit Tests: Mbuf
-================
-
-This is the test plan for the Intel® DPDK mbuf library.
-
-Description
-===========
-
-#. Allocate a mbuf pool.
-
-   - The pool contains NB_MBUF elements, where each mbuf is MBUF_SIZE
-     bytes long.
-
-#. Test multiple allocations of mbufs from this pool.
-
-   - Allocate NB_MBUF and store pointers in a table.
-   - If an allocation fails, return an error.
-   - Free all these mbufs.
-   - Repeat the same test to check that mbufs were freed correctly.
-
-#. Test data manipulation in pktmbuf.
-
-   - Alloc an mbuf.
-   - Append data using rte_pktmbuf_append().
-   - Test for error in rte_pktmbuf_append() when len is too large.
-   - Trim data at the end of mbuf using rte_pktmbuf_trim().
-   - Test for error in rte_pktmbuf_trim() when len is too large.
-   - Prepend a header using rte_pktmbuf_prepend().
-   - Test for error in rte_pktmbuf_prepend() when len is too large.
-   - Remove data at the beginning of mbuf using rte_pktmbuf_adj().
-   - Test for error in rte_pktmbuf_adj() when len is too large.
-   - Check that appended data is not corrupt.
-   - Free the mbuf.
-   - Between all these tests, check data_len and pkt_len, and
-     that the mbuf is contiguous.
-   - Repeat the test to check that allocation operations
-     reinitialize the mbuf correctly.
diff --git a/test_plans/unit_tests_mempool_test_plan.rst b/test_plans/unit_tests_mempool_test_plan.rst
deleted file mode 100644
index 1ffe41c3..00000000
--- a/test_plans/unit_tests_mempool_test_plan.rst
+++ /dev/null
@@ -1,46 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2010-2017 Intel Corporation
-
-===================
-Unit Tests: Mempool
-===================
-
-This is the test plan for the Intel® DPDK mempool library.
-
-Description
-===========
-
-#. Basic tests: done on one core with and without cache:
-
-   - Get one object, put one object
-   - Get two objects, put two objects
-   - Get all objects, test that their content is not modified and
-     put them back in the pool.
-
-#. Performance tests:
-
-   Each core get *n_keep* objects per bulk of *n_get_bulk*. Then,
-   objects are put back in the pool per bulk of *n_put_bulk*.
-
-   This sequence is done during TIME_S seconds.
-
-   This test is done on the following configurations:
-
-   - Cores configuration (*cores*)
-
-     - One core with cache
-     - Two cores with cache
-     - Max. cores with cache
-     - One core without cache
-     - Two cores without cache
-     - Max. cores without cache
-
-   - Bulk size (*n_get_bulk*, *n_put_bulk*)
-
-     - Bulk get from 1 to 32
-     - Bulk put from 1 to 32
-
-   - Number of kept objects (*n_keep*)
-
-     - 32
-     - 128
diff --git a/test_plans/unit_tests_pmd_perf_test_plan.rst b/test_plans/unit_tests_pmd_perf_test_plan.rst
deleted file mode 100644
index 43a62294..00000000
--- a/test_plans/unit_tests_pmd_perf_test_plan.rst
+++ /dev/null
@@ -1,55 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2014-2017 Intel Corporation
-
-===========================
-Unit Tests: PMD Performance
-===========================
-
-
-Prerequisites
-=============
-One 10Gb Ethernet port of the DUT is directly connected and link is up.
-
-
-Continuous Mode Performance
-===========================
-
-This is the test plan for unit test to measure cycles/packet in NIC loopback
-mode.
-
-This section explains how to run the unit tests for pmd performance with
-continues stream control mode.
-The test can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The final output of the test will be average cycles of IO used per packet.
-
-
-Burst Mode Performance
-======================
-
-This is the test plan for unit test to measure cycles/packet in NIC loopback
-mode.
-
-This section explains how to run the unit tests for pmd performance with
-burst stream control mode. For get accurate scalar fast performance, need
-disable INC_VECTOR in configuration file first.
-
-
-The test can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The final output of the test will be matrix of average cycles of IO used per
-packet.
-
-        +--------+------+--------+--------+
-        | Mode   | rxtx | rxonly | txonly |
-        +========+======+========+========+
-        | vector | 58   | 34     | 23     |
-        +--------+------+--------+--------+
-        | scalar | 89   | 51     | 38     |
-        +--------+------+--------+--------+
-        | full   | 73   | 31     | 42     |
-        +--------+------+--------+--------+
-        | hybrid | 59   | 35     | 23     |
-        +--------+------+--------+--------+
diff --git a/test_plans/unit_tests_power_test_plan.rst b/test_plans/unit_tests_power_test_plan.rst
deleted file mode 100644
index aa3938df..00000000
--- a/test_plans/unit_tests_power_test_plan.rst
+++ /dev/null
@@ -1,63 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2010-2017 Intel Corporation
-
-=========================
-Unit Tests: Power Library
-=========================
-
-This is the test plan for the Intel® DPDK Power library.
-
-Description
-===========
-
-This section explains how to run the unit tests for Power features. The test
-can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-.. Note::
-
-   * In the BIOS, turn on SpeedStep.
-
-
-The steps to run the unit test manually are as follow::
-
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> power_autotest
-
-
-The final output of the test has to be "Test OK"
-
-ACPI CPU Frequency
-==================
-
-This section explains how to run the unit tests for Power features. The test
-can be launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> power_acpi_cpufreq_autotest
-
-The final output of the test has to be "Test OK"
diff --git a/test_plans/unit_tests_qos_test_plan.rst b/test_plans/unit_tests_qos_test_plan.rst
deleted file mode 100644
index b5626ac9..00000000
--- a/test_plans/unit_tests_qos_test_plan.rst
+++ /dev/null
@@ -1,83 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2010-2017 Intel Corporation
-
-========================================
-Unit Tests: Random Early Detection (RED)
-========================================
-
-This is the test plan for the Intel® DPDK Random Early Detection feature.
-
-This section explains how to run the unit tests for RED. The test can be launched
-independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> red_autotest
-
-The final output of the test has to be "Test OK"
-
-====================
-Unit Tests: Metering
-====================
-
-This is the test plan for the Intel® DPDK Metering feature.
-
-This section explains how to run the unit tests for Meter. The test can be launched
-independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> meter_autotest
-
-The final output of the test has to be "Test OK"
-
-=====================
-Unit tests: Scheduler
-=====================
-
-This is the test plan for the Intel® DPDK Scheduler feature.
-
-This section explains how to run the unit tests for Scheduler. The test can be
-launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> sched_autotest
-
-The final output of the test has to be "Test OK"
diff --git a/test_plans/unit_tests_ring_test_plan.rst b/test_plans/unit_tests_ring_test_plan.rst
deleted file mode 100644
index 42c1fb76..00000000
--- a/test_plans/unit_tests_ring_test_plan.rst
+++ /dev/null
@@ -1,98 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2010-2017 Intel Corporation
-
-================
-Unit Tests: Ring
-================
-
-This is the test plan for the Intel® DPDK ring library.
-
-Description
-===========
-
-#. Basic tests (done on one core)
-
-   - Using single producer/single consumer functions:
-
-     - Enqueue one object, two objects, MAX_BULK objects
-     - Dequeue one object, two objects, MAX_BULK objects
-     - Check that dequeued pointers are correct
-
-   - Using multi producers/multi consumers functions:
-
-     - Enqueue one object, two objects, MAX_BULK objects
-     - Dequeue one object, two objects, MAX_BULK objects
-     - Check that dequeued pointers are correct
-
-   - Test watermark and default bulk enqueue/dequeue:
-
-     - Set watermark
-     - Set default bulk value
-     - Enqueue objects, check that -EDQUOT is returned when
-       watermark is exceeded
-     - Check that dequeued pointers are correct
-
-#. Check quota and watermark
-
-   - Start a loop on another lcore that will enqueue and dequeue
-     objects in a ring. It will monitor the value of quota (default
-     bulk count) and watermark.
-   - At the same time, change the quota and the watermark on the
-     master lcore.
-   - The slave lcore will check that bulk count changes from 4 to
-     8, and watermark changes from 16 to 32.
-
-#. Performance tests
-
-   This test is done on the following configurations:
-
-   - One core enqueuing, one core dequeuing
-   - One core enqueuing, other cores dequeuing
-   - One core dequeuing, other cores enqueuing
-   - Half of the cores enqueuing, the other half dequeuing
-
-   When only one core enqueues/dequeues, the test is done with the
-   SP/SC functions in addition to the MP/MC functions.
-
-   The test is done with different bulk size.
-
-   On each core, the test enqueues or dequeues objects during
-   TIME_S seconds. The number of successes and failures are stored on
-   each core, then summed and displayed.
-
-   The test checks that the number of enqueues is equal to the
-   number of dequeues.
-
-#. Change watermark and quota
-
-   Use the command line to change the value of quota and
-   watermark. Then dump the status of ring to check that the values
-   are correctly updated in the ring structure.
-
-============================
-Unit Tests: Ring Performance
-============================
-
-This is the test plan for the Intel®  DPDK LPM Method in IPv6.
-
-This section explains how to run the unit tests for LPM in IPv6.The test can be
-launched independently using the command line interface.
-This test is implemented as a linuxapp environment application.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff
-  RTE>> ring_perf_autotest
-
-
-The final output of the test has to be "Test OK"
diff --git a/test_plans/unit_tests_ringpmd_test_plan.rst b/test_plans/unit_tests_ringpmd_test_plan.rst
deleted file mode 100644
index 9cbc9e39..00000000
--- a/test_plans/unit_tests_ringpmd_test_plan.rst
+++ /dev/null
@@ -1,34 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2014-2017 Intel Corporation
-
-====================
-Unit Tests: Ring Pmd
-====================
-
-This is the test plan for the Intel® DPDK Ring poll mode driver feature.
-
-This section explains how to run the unit tests for ring pmd. The test can be
-launched independently using the command line interface.
-This test is implemented as a linuxapp environment application and config
-RTE_LIBRTE_PMD_RING should be modified to 'Y'.
-
-The complete test suite is launched automatically using a python-expect
-script (launched using ``make test``) that sends commands to
-the application and checks the results. A test report is displayed on
-stdout.
-
-Ring pmd unit test required two pair of virtual ethernet devices and one
-virtual ethernet devices with full rx&tx functions.
-
-The steps to run the unit test manually are as follow::
-
-  Build dpdk
-  # cd dpdk
-  # CC=gcc meson --werror -Denable_kmods=True  -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc
-  # ninja -C x86_64-native-linuxapp-gcc -j 50
-
-  # ./x86_64-native-linuxapp-gcc/app/test/dpdk-test -n 1 -c ffff --vdev='net_ring0'
-      --vdev='net_ring1'
-  RTE>> ring_pmd_autotest
-
-The final output of the test has to be "Test OK"
diff --git a/test_plans/unit_tests_timer_test_plan.rst b/test_plans/unit_tests_timer_test_plan.rst
deleted file mode 100644
index e6529108..00000000
--- a/test_plans/unit_tests_timer_test_plan.rst
+++ /dev/null
@@ -1,69 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
-   Copyright(c) 2010-2017 Intel Corporation
-
-=================
-Unit tests: Timer
-=================
-
-This section describes the test plan for the timer library.
-
-Description
-===========
-
-#. Stress tests.
-
-   The objective of the timer stress tests is to check that there are no
-   race conditions in list and status management. This test launches,
-   resets and stops the timer very often on many cores at the same
-   time.
-
-   - Only one timer is used for this test.
-   - On each core, the rte_timer_manage() function is called from the main loop
-     every 3 microseconds.
-   - In the main loop, the timer may be reset (randomly, with a
-     probability of 0.5 %) 100 microseconds later on a random core, or
-     stopped (with a probability of 0.5 % also).
-   - In callback, the timer is can be reset (randomly, with a
-     probability of 0.5 %) 100 microseconds later on the same core or
-     on another core (same probability), or stopped (same
-     probability).
-
-#. Basic test.
-
-   This test performs basic functional checks of the timers. The test
-   uses four different timers that are loaded and stopped under
-   specific conditions in specific contexts.
-
-   - Four timers are used for this test.
-   - On each core, the rte_timer_manage() function is called from main loop
-     every 3 microseconds.
-
-   The autotest python script checks that the behavior is correct:
-
-   - timer0
-
-     - At initialization, timer0 is loaded by the master core, on master core in
-       "single" mode (time = 1 second).
-     - In the first 19 callbacks, timer0 is reloaded on the same core,
-       then, it is explicitly stopped at the 20th call.
-     - At t=25s, timer0 is reloaded once by timer2.
-
-   - timer1
-
-     - At initialization, timer1 is loaded by the master core, on the
-       master core in "single" mode (time = 2 seconds).
-     - In the first 9 callbacks, timer1 is reloaded on another
-       core. After the 10th callback, timer1 is not reloaded anymore.
-
-   - timer2
-
-     - At initialization, timer2 is loaded by the master core, on the
-       master core in "periodical" mode (time = 1 second).
-     - In the callback, when t=25s, it stops timer3 and reloads timer0
-       on the current core.
-
-   - timer3
-
-     - At initialization, timer3 is loaded by the master core, on
-       another core in "periodical" mode (time = 1 second).
-     - It is stopped at t=25s by timer2.
-- 
2.27.0