diff mbox

[dpdk-dev] app/test: reduced duration of red_autotest

Message ID 1465307358-115427-1-git-send-email-tomasz.kantecki@intel.com (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers

Commit Message

Kantecki, Tomasz June 7, 2016, 1:49 p.m. UTC 
  'red_autotest' changed to run only functional tests without test #4 which was
taking ~53 seconds. 'red_autotest' takes ~12[s] now.
'red_perf' has been added to run performance tests only (~26[s]).
'red_all' has been added to run all functional tests (including #4) and
perfromance tests. This reflects current 'red_autotest' behavior (~92[s]).
---
 app/test/test_red.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 65 insertions(+), 10 deletions(-)

Comments

Thomas Monjalon June 7, 2016, 2:03 p.m. UTC | #1 
Hi Tomasz,

Thanks for splitting tests.

2016-06-07 14:49, Tomasz Kantecki:
> 'red_autotest' changed to run only functional tests without test #4 which was
> taking ~53 seconds. 'red_autotest' takes ~12[s] now.

12s is long for a functional test. We are used to have tests of less than 1s.
Do you think this magnitude order can be achieved for red tests?
Kantecki, Tomasz June 7, 2016, 3:12 p.m. UTC | #2 
Hi Thomas,

> 12s is long for a functional test. We are used to have tests of less than 1s.
> Do you think this magnitude order can be achieved for red tests?

This is a real challenge :) Let me take another look into it.

Regards,
Tomasz
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
Kantecki, Tomasz June 8, 2016, 3:56 p.m. UTC | #3 
Hi Thomas,
 
> > 12s is long for a functional test. We are used to have tests of less than 1s.
> > Do you think this magnitude order can be achieved for red tests?
> 
> This is a real challenge :) Let me take another look into it.

I had a 2nd look into this test suite and reducing time for functional tests is doable but labor intensive. Let me explain:
RED/WRED algorithm is time based (packet queue events in time). For tracking time the test uses TSC (x86 time stamp counter). This could be replaced with some fake time stamp in functional tests and result in significant reduction of execution time. It needs couple of days to carefully replace TSC with a fake time stamp solution without breaking test logic.

Alternatively, one or two more test cases can be removed from the fast_test. A few experiments with this option give me test duration at 5[s] level. I guess this too much off from the 1[s] target.

Regards,
Tomasz


--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
Thomas Monjalon June 8, 2016, 4:22 p.m. UTC | #4 
2016-06-08 15:56, Kantecki, Tomasz:
> Hi Thomas,
>  
> > > 12s is long for a functional test. We are used to have tests of less than 1s.
> > > Do you think this magnitude order can be achieved for red tests?
> > 
> > This is a real challenge :) Let me take another look into it.
> 
> I had a 2nd look into this test suite and reducing time for functional tests is doable but labor intensive. Let me explain:
> RED/WRED algorithm is time based (packet queue events in time). For tracking time the test uses TSC (x86 time stamp counter). This could be replaced with some fake time stamp in functional tests and result in significant reduction of execution time. It needs couple of days to carefully replace TSC with a fake time stamp solution without breaking test logic.

Sorry, I haven't dived into the code, but I don't understand how we get
some seconds delays in a code for fast processing on nano-second CPU.
Are you sure you cannot have the same result with less iterations and
shorter timeouts?
diff mbox

Patch

diff --git a/app/test/test_red.c b/app/test/test_red.c
index 81c9d67..a0a942c 100644
--- a/app/test/test_red.c
+++ b/app/test/test_red.c
@@ -1747,6 +1747,16 @@  struct tests func_tests[] = {
 	{ &ovfl_test1_config, ovfl_test1 },
 };
 
+struct tests func_tests_quick[] = {
+	{ &func_test1_config, func_test1 },
+	{ &func_test2_config, func_test2 },
+	{ &func_test3_config, func_test3 },
+	/* no test 4 as it takes a lot of time */
+	{ &func_test5_config, func_test5 },
+	{ &func_test6_config, func_test6 },
+	{ &ovfl_test1_config, ovfl_test1 },
+};
+
 struct tests perf_tests[] = {
 	{ &perf1_test1_config, perf1_test },
 	{ &perf1_test2_config, perf1_test },
@@ -1850,27 +1860,60 @@  test_invalid_parameters(void)
 	return 0;
 }
 
+static void
+show_stats(const uint32_t num_tests, const uint32_t num_pass)
+{
+	if (num_pass == num_tests)
+		printf("[total: %u, pass: %u]\n", num_tests, num_pass);
+	else
+		printf("[total: %u, pass: %u, fail: %u]\n", num_tests, num_pass,
+		       num_tests - num_pass);
+}
+
+static int
+tell_the_result(const uint32_t num_tests, const uint32_t num_pass)
+{
+	return (num_pass == num_tests) ? 0 : 1;
+}
+
 static int
 test_red(void)
 {
 	uint32_t num_tests = 0;
 	uint32_t num_pass = 0;
-	int ret = 0;
 
 	if (test_invalid_parameters() < 0)
 		return -1;
+	run_tests(func_tests_quick, RTE_DIM(func_tests_quick),
+		  &num_tests, &num_pass);
+	show_stats(num_tests, num_pass);
+	return tell_the_result(num_tests, num_pass);
+}
+
+static int
+test_red_perf(void)
+{
+	uint32_t num_tests = 0;
+	uint32_t num_pass = 0;
 
-	run_tests(func_tests, RTE_DIM(func_tests), &num_tests, &num_pass);
 	run_tests(perf_tests, RTE_DIM(perf_tests), &num_tests, &num_pass);
+	show_stats(num_tests, num_pass);
+	return tell_the_result(num_tests, num_pass);
+}
 
-	if (num_pass == num_tests) {
-		printf("[total: %u, pass: %u]\n", num_tests, num_pass);
-		ret = 0;
-	} else {
-		printf("[total: %u, pass: %u, fail: %u]\n", num_tests, num_pass, num_tests - num_pass);
-		ret = -1;
-	}
-	return ret;
+static int
+test_red_all(void)
+{
+	uint32_t num_tests = 0;
+	uint32_t num_pass = 0;
+
+	if (test_invalid_parameters() < 0)
+		return -1;
+
+	run_tests(func_tests, RTE_DIM(func_tests), &num_tests, &num_pass);
+	run_tests(perf_tests, RTE_DIM(perf_tests), &num_tests, &num_pass);
+	show_stats(num_tests, num_pass);
+	return tell_the_result(num_tests, num_pass);
 }
 
 static struct test_command red_cmd = {
@@ -1878,3 +1921,15 @@  static struct test_command red_cmd = {
 	.callback = test_red,
 };
 REGISTER_TEST_COMMAND(red_cmd);
+
+static struct test_command red_cmd_perf = {
+	.command = "red_perf",
+	.callback = test_red_perf,
+};
+REGISTER_TEST_COMMAND(red_cmd_perf);
+
+static struct test_command red_cmd_all = {
+	.command = "red_all",
+	.callback = test_red_all,
+};
+REGISTER_TEST_COMMAND(red_cmd_all);