From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id A43AB1B207 for ; Mon, 3 Dec 2018 05:59:40 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2018 20:59:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,309,1539673200"; d="scan'208";a="126520163" Received: from juan.sh.intel.com ([10.67.118.154]) by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2018 20:59:38 -0800 From: Lijuan Tu To: dts@dpdk.org Cc: Lijuan Tu Date: Mon, 3 Dec 2018 21:27:26 +0800 Message-Id: <1543843646-137919-1-git-send-email-lijuan.tu@intel.com> X-Mailer: git-send-email 1.8.3.1 Subject: [dts] [PATCH] test_plans: fix doc build warning. X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: test suite reviews and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 04:59:41 -0000 Signed-off-by: Lijuan Tu --- 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