test suite reviews and discussions
 help / color / mirror / Atom feed
From: Lijuan Tu <lijuan.tu@intel.com>
To: dts@dpdk.org
Cc: Lijuan Tu <lijuan.tu@intel.com>
Subject: [dts]  [PATCH] test_plans: fix doc build warning.
Date: Mon,  3 Dec 2018 21:27:26 +0800	[thread overview]
Message-ID: <1543843646-137919-1-git-send-email-lijuan.tu@intel.com> (raw)

Signed-off-by: Lijuan Tu <lijuan.tu@intel.com>
---
 test_plans/crypto_perf_test_plan.rst          |  0
 test_plans/hotplug_mp_test_plan.rst           | 54 ++++++++++++++++-----------
 test_plans/index.rst                          |  9 ++++-
 test_plans/rss_to_rte_flow_test_plan.rst      | 20 ++++++----
 test_plans/runtime_queue_number_test_plan.rst |  2 +-
 test_plans/short_live_test_plan.rst           |  0
 test_plans/vf_macfilter_test_plan.rst         |  1 +
 7 files changed, 53 insertions(+), 33 deletions(-)
 mode change 100755 => 100644 test_plans/crypto_perf_test_plan.rst
 mode change 100755 => 100644 test_plans/hotplug_mp_test_plan.rst
 mode change 100755 => 100644 test_plans/short_live_test_plan.rst

diff --git a/test_plans/crypto_perf_test_plan.rst b/test_plans/crypto_perf_test_plan.rst
old mode 100755
new mode 100644
diff --git a/test_plans/hotplug_mp_test_plan.rst b/test_plans/hotplug_mp_test_plan.rst
old mode 100755
new mode 100644
index 4b9c6dd..db4758b
--- a/test_plans/hotplug_mp_test_plan.rst
+++ b/test_plans/hotplug_mp_test_plan.rst
@@ -33,30 +33,28 @@
 ==========================
 Hotplug on multi-processes
 ==========================
-Currently secondary process will only sync ethdev from primary
-process at init stage, but it will not be aware if device
-is attached/detached on primary process at runtime.
+Currently secondary process will only sync ethdev from primary process at
+init stage, but it will not be aware if device is attached/detached on
+primary process at runtime.
 
 While there is the requirement from application that take
-primary-secondary process model. The primary process work as a
-resource management process, it will create/destroy virtual device
-at runtime, while the secondary process deal with the network stuff
-with these devices.
-
-So the orignial intention is to fix this gap, but beyond that
-the patch set provide a more comprehesive solution to handle
-different hotplug cases in multi-process situation, it cover below
-scenario:
-
- Attach a device from the primary
- Detach a device from the primary
- Attach a device from a secondary
- Detach a device from a secondary
-
-In primary-secondary process model, we assume ethernet devices are
-shared by default, that means attach or detach a device on any process will
-broadcast to all other processes through mp channel then device information
-will be synchronized on all processes.
+primary-secondary process model. The primary process work as a resource
+management process, it will create/destroy virtual device at runtime,
+while the secondary process deal with the network stuff with these devices.
+
+So the orignial intention is to fix this gap, but beyond that the patch
+set provide a more comprehesive solution to handle different hotplug
+cases in multi-process situation, it cover below scenario:
+
+* Attach a device from the primary
+* Detach a device from the primary
+* Attach a device from a secondary
+* Detach a device from a secondary
+
+In primary-secondary process model, we assume ethernet devices are shared
+by default, that means attach or detach a device on any process will
+broadcast to all other processes through mp channel then device
+information will be synchronized on all processes.
 
 Any failure during attaching process will cause inconsistent status
 between processes, so proper rollback action should be considered.
@@ -65,9 +63,11 @@ between processes, so proper rollback action should be considered.
 Test Case: Attach physical device from primary or secondary
 ===========================================================
 Start sample code as primary then secondary::
+
     ./hotplug_mp --proc-type=auto
 
 Check primary and secondary processes don't have any device::
+
     example> list
     list all etherdev
 
@@ -91,9 +91,11 @@ Test Case: Detach physical device from primary or secondary
 Bind one port to igb_uio or vfio
 
 Start sample code as primary then secondary::
+
     ./hotplug_mp --proc-type=auto
 
 Check primary and secondary processes have the device::
+
     example> list
     list all etherdev
     0       0000:88:00.0
@@ -113,9 +115,11 @@ Re-bind port to kernel state
 Test Case: Attach virtual device from primary or secondary
 ==========================================================
 Start sample code as primary then secondary::
+
     ./hotplug_mp --proc-type=auto
 
 Check primary and secondary processes don't have any device::
+
     example> list
     list all etherdev
 
@@ -132,9 +136,11 @@ Quit primary and secondary processes
 Test Case: Detach virtual device from primary or secondary
 ==========================================================
 Start sample code as primary then secondary::
+
     ./hotplug_mp --proc-type=auto
 
 Check primary and secondary processes don't have any device::
+
     example> list
     list all etherdev
 
@@ -158,9 +164,11 @@ Quit primary and secondary processes
 Test Case: Repeat to attach/detach physical device from primary or secondary
 ============================================================================
 Start sample code as primary then secondary::
+
     ./hotplug_mp --proc-type=auto
 
 Check primary and secondary processes don't have any device::
+
     example> list
     list all etherdev
 
@@ -197,9 +205,11 @@ Re-bind port to kernel state
 Test Case: Repeat to attach/detach virtual device from primary or secondary
 ===========================================================================
 Start sample code as primary then secondary::
+
      ./hotplug_mp --proc-type=auto
 
 Check primary and secondary processes don't have any device::
+
      example> list
      list all etherdev
 
diff --git a/test_plans/index.rst b/test_plans/index.rst
index d4449d3..a114231 100644
--- a/test_plans/index.rst
+++ b/test_plans/index.rst
@@ -43,7 +43,6 @@ The following are the test plans for the DPDK DTS automated test system.
     cloud_filter_test_plan
     coremask_test_plan
     crypto_perf_test_plan
-    ddp_mpls_test_plan
     dual_vlan_test_plan
     dynamic_config_test_plan
     etag_test_plan
@@ -54,6 +53,7 @@ The following are the test plans for the DPDK DTS automated test system.
     ftag_test_plan
     generic_filter_test_plan
     hotplug_test_plan
+    hotplug_mp_test_plan
     ieee1588_test_plan
     interrupt_pmd_test_plan
     ipfrag_test_plan
@@ -118,10 +118,14 @@ The following are the test plans for the DPDK DTS automated test system.
     vf_kernel_test_plan
     multiple_pthread_test_plan
     qinq_filter_test_plan
-    ddp_gtp_test_plan
     generic_flow_api_test_plan
+    rss_to_rte_flow_test_plan
+    ddp_gtp_test_plan
     ddp_gtp_qregion_test_plan
+    ddp_ppp_l2tp_test_plan
+    ddp_mpls_test_plan
     runtime_queue_number_test_plan
+    dynamic_queue_test_plan
     vhost_multi_queue_qemu_test_plan
     vhost_qemu_mtu_test_plan
 
@@ -135,6 +139,7 @@ The following are the test plans for the DPDK DTS automated test system.
     unit_tests_mbuf_test_plan
     unit_tests_mempool_test_plan
     unit_tests_pmd_perf_test_plan
+    unit_tests_loopback_test_plan
     unit_tests_power_test_plan
     unit_tests_qos_test_plan
     unit_tests_ringpmd_test_plan
diff --git a/test_plans/rss_to_rte_flow_test_plan.rst b/test_plans/rss_to_rte_flow_test_plan.rst
index b95fb1e..dbbaa28 100644
--- a/test_plans/rss_to_rte_flow_test_plan.rst
+++ b/test_plans/rss_to_rte_flow_test_plan.rst
@@ -36,12 +36,15 @@ Move RSS to rte_flow
 Description
 ===========
 
-rte_flow has been actually defined to include RSS, but till now,
-RSS is out of rte_flow. It was suggested to move existing RSS to rte_flow.
-This can be better for users, and may save effort for CPK development.
-RSS enabling: now, rte_flow API enabling RSS is support on igb/ixgbe/i40e.
-RSS input set changing: now, rte flow API RSS input set is support on i40e.
-Notes:non-default RSS hash functions are not supported -- Operation not supported.
+Generic flow API (rte_flow) has been actually defined to include RSS, but
+till now, RSS is out of rte_flow. It was suggested to move existing RSS to
+rte_flow. This can be better for users, and may save effort for CPK
+development. RSS enabling: now, rte_flow API enabling RSS is support on
+igb/ixgbe/i40e. RSS input set changing: now, rte flow API RSS input set is
+support on i40e.
+
+Notes: non-default RSS hash functions are not supported -- Operation not
+supported.
 
 Prerequisites
 =============
@@ -111,7 +114,7 @@ Test case: disable and enable rss
    All the packets are distributed to all the four queues.
 
 Notes: the default RSS functions are different among several NICs.
-here shows the printing of NIC with i40e driver.
+Here shows the printing of NIC with i40e driver.
 
 Test case: enable ipv4-udp rss
 ==============================
@@ -267,6 +270,7 @@ Test case: set key and key_len
 ==============================
 
 Only i40e support key and key_len setting.
+
 1. Start the testpmd::
 
     ./testpmd -c 1ffff -n 4 -- -i --nb-cores=8 --rxq=4 --txq=4 --port-topology=chained
@@ -349,7 +353,7 @@ Only i40e support key and key_len setting.
    pkt5 is distributed to queue 0.
 
 Test case: Flow directory rule and RSS rule combination
-======================================================
+=======================================================
 
 1. Start the testpmd::
 
diff --git a/test_plans/runtime_queue_number_test_plan.rst b/test_plans/runtime_queue_number_test_plan.rst
index e1e9bc0..30eb073 100644
--- a/test_plans/runtime_queue_number_test_plan.rst
+++ b/test_plans/runtime_queue_number_test_plan.rst
@@ -290,7 +290,7 @@ Test case: VF max queue number when VF bound to kernel driver
    number is 1/4/8/16.
 
 Test case: set VF max queue number with max VFs on one PF port
-=============================================================
+==============================================================
 
 1. Set up max VFs from one PF with DPDK driver
    Create 32 vfs on four ports fortville NIC::
diff --git a/test_plans/short_live_test_plan.rst b/test_plans/short_live_test_plan.rst
old mode 100755
new mode 100644
diff --git a/test_plans/vf_macfilter_test_plan.rst b/test_plans/vf_macfilter_test_plan.rst
index a971ba0..6f07f28 100644
--- a/test_plans/vf_macfilter_test_plan.rst
+++ b/test_plans/vf_macfilter_test_plan.rst
@@ -289,6 +289,7 @@ Test Case 3: test_dpdk_2pf_2vf_1vm_mac_add_filter
 9. Use scapy to send 100 random packets with a wrong MAC to VF0, verify the
    packets can't be received by one VF and can be forward to another VF
    correctly.
+
 Test Case 4: test_dpdk_2pf_2vf_1vm_iplink_macfilter
 ===================================================
 
-- 
1.8.3.1

             reply	other threads:[~2018-12-03  4:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-03 13:27 Lijuan Tu [this message]
2018-12-03  8:38 ` Tu, Lijuan

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=1543843646-137919-1-git-send-email-lijuan.tu@intel.com \
    --to=lijuan.tu@intel.com \
    --cc=dts@dpdk.org \
    /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).