DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Hari Kumar Vemula <hari.kumarx.vemula@intel.com>
Cc: dev@dpdk.org, john.mcnamara@intel.com, reshma.pattan@intel.com,
	marko.kovacevic@intel.com, jananeex.m.parthasarathy@intel.com
Subject: Re: [dpdk-dev] [PATCH v4] doc: add meson ut info in prog guide
Date: Thu, 31 Jan 2019 14:49:28 +0000	[thread overview]
Message-ID: <20190131144928.GA155780@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <1548397251-2053-1-git-send-email-hari.kumarx.vemula@intel.com>

On Fri, Jan 25, 2019 at 06:20:51AM +0000, Hari Kumar Vemula wrote:
> Add a programmer's guide section for meson ut
> 
> Signed-off-by: Hari Kumar Vemula <hari.kumarx.vemula@intel.com>
> ---
> v4: Typos corrected
> v3: Modified
> v2: Removed enhancement details
> ---

Some sections I think need rewording to be written more from an end-user
rather than developer point of view, since this text is focused on running unit
tests rather than on writing them. Some additional spelling/grammar
corrections below also.

NOTE: Since this is in the programmers guide, maybe the intention is to
have it more at the programmer level. In which case, you need more info on
writing tests, and what return values should be used etc. other than
"TEST_SKIPPED", and can skip some of the detail on running tests.

Regards,
/Bruce

>  doc/guides/prog_guide/index.rst    |   1 +
>  doc/guides/prog_guide/meson_ut.rst | 159 +++++++++++++++++++++++++++++
>  2 files changed, 160 insertions(+)
>  create mode 100644 doc/guides/prog_guide/meson_ut.rst
> 
> diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
> index 6726b1e8d..f4274573f 100644
> --- a/doc/guides/prog_guide/index.rst
> +++ b/doc/guides/prog_guide/index.rst
> @@ -58,6 +58,7 @@ Programmer's Guide
>      source_org
>      dev_kit_build_system
>      dev_kit_root_make_help
> +    meson_ut
>      extend_dpdk
>      build_app
>      ext_app_lib_make_help
> diff --git a/doc/guides/prog_guide/meson_ut.rst b/doc/guides/prog_guide/meson_ut.rst
> new file mode 100644
> index 000000000..9485b1e63
> --- /dev/null
> +++ b/doc/guides/prog_guide/meson_ut.rst
> @@ -0,0 +1,159 @@
> +..  SPDX-License-Identifier: BSD-3-Clause
> +
> +    Copyright(c) 2014-2018 Intel Corporation.

Should be just 2019, or 2018-2019, since this doc was not started in 2014.

> +
> +.. _Meson:
> +
> +Meson_UT
> +========
> +
> +The meson build for unit tests under different categories is supported using 'test/test/meson.build'.
> +
This line is not wrong, just probably unnecessary. Consider omitting it, I
think, since this doc is about using the unit tests rather than about the
source code layout or individual files.

> +This document describes the below list in detail.
> +
> +*  Building and Running the unit tests.
> +*  Grouping of testcases.
> +*  Parallel and non parallel tests.
> +*  Test suites.
Are test suites not the same as the grouping of test cases?

> +*  How to run different test suites.
> +*  Support for skipped tests.
> +
> +
> +
> +Building and Running the unit tests
> +-----------------------------------
> +
> +*  Create the meson build output folder using command.
> +
> +   ``$ meson <build_dir>``
> +
> +*  Enter into build output folder, which was created by above command.
> +
> +   ``$ cd build``
> +
> +*  Compile DPDK using `$ ninja`.

Like the other commands above, this should be put on its own line.

> +   The output file of the build will be available in meson build folder.
> +   After successful ninja command, binary `dpdk-test` is created in `build/test/test/`.
> +
> +*  Run the unit testcases.
> +
> +   ``$ ninja test`` (or) ``$ meson test``
> +
> +*   To run specific test case via meson command.
> +
> +   ``$ meson test <test case>`` (or) ``$ ninja test <test case>``
> +
> +
> +
> +Grouping of testcases
> +---------------------
> +
> +Testcases has been grouped into below four different groups based on conditions

has -> have.
Remove the word "below" as it's unnecessary.

> +of time duration and performance of the individual testcase.
> +
> +*  fast_parallel_test_names
> +*  fast_non_parallel_test_names
> +*  perf_test_names
> +*  driver_test_names
> +*  dump_test_names

Since you are listing the groups, I think you should just put the groups
without using the official variable names, which looks wrong and doesn't
add any info. Instead the list should be:

* fast tests which can be run in parallel
* fast tests which must run serially
* performance tests
* driver tests
* tests which produce lists of objects as output, and therefore that need manual checking

> +
> +Parallel and non parallel tests
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +By default, meson will run test cases in parallel. However `is_parallel` argument
> +of `test()` in meson.build can be used to run tests in parallel or non-parallel
> +mode based on its functionality. Test cases marked with `is_parallel : true` will
> +run in parallel and tests marked with `is_parallel : false` will run in non-parallel.
> +While non-parallel test is running, no other test should run.
> +Parallel and non parallel test cases are grouped under the `fast_parallel_test_names`
> +and `fast_non_parallel_test_names`.
> +

The above paragraph is too low level. It can probably be dropped or
abbreviated to a single sentence included in the previous section. Again,
this text seems targeted at users, not developers, so variable names in the
meson.build file are irrelevant.

> +
> +
> +Test suites
> +~~~~~~~~~~~
> +
> +Tests are grouped into test suites in meson.build and these suite names can be provided
> +as argument to `meson test` as `--suite ???project_name:label???`.
> +
> +    Ex: ``$ meson test --suite ???DPDK:fast-tests???``
> +
> +Running different test suites
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Below are commands to run testcases using option `suite`
> +
> +*  Test cases from the groups `fast_parallel_test_names` and `fast_non_parallel_test_names`

Again, drop the variable names. Not relevant for users.

> +   are run under 10seconds and below is the meson command to run them.

"are run under 10seconds" -> "should take less than 10 seconds"

> +
> +   ``$ meson test --suite DPDK:fast-tests``
> +
> +*  Test cases from the group `perf_test_names` are run under 600 seconds
> +   and below is the meson command to run them.
> +
> +   ``$ meson test --suite DPDK:perf-tests``
> +
> +*  Test cases from the group `driver_test_names` are run under 600 seconds
> +   and below is the meson command to run them.
> +
> +   ``$ meson test --suite DPDK:driver-tests``
> +
> +*  Test cases from the group `dump_test_names` are run under 600 seconds

Since these just output things, do they really need a 600 second timeout?
Do we even need to mention it?

> +   and below is the meson command to run them.
> +
> +   ``$ meson test --suite DPDK:dump-tests``
> +
> +
> +
> +Skipped testcases
> +-----------------
> +
> +Some unit test cases have dependency on external libraries, driver modules or

"have dependency" -> "have a dependency"

> +config flags, without which the test cases cannot be run. Such test cases
> +should return TEST_SKIPPED when mentioned dependencies are not enabled. To make
> +test cases run user should enable relevant dependencies. Below are the few
> +current scenarios when test cases are skipped:

Needs rewording for a more user-focused point of view, since TEST_SKIPPED
is an internal "magic number" in the code. Something like:
"Such test cases will be reported out as skipped if they cannot run. To
enable those test cases, the user should ensure the required dependencies
are met. Below are a few possible causes why tests may be skipped and how
they may be resolved:"

> +
> +#. External library dependency paths are not set.

The high-level problem is more that the library is not found, not that the
path is unset. The solution is to set the path to the dependency if
necessary.

> +#. Config flag for the dependent library is not enabled.
> +#. Dependent driver modules are not installed on the system.
> +
> +Dependent library paths can be set using below

"To help find missing libraries, the user can specify addition search paths
for those libraries as below:"

> +
> +*  Single path ``$ export LIBRARY_PATH=path``
> +
> +*  Multiple paths ``$ export LIBRARY_PATH=path1:path2:path3``
> +
> +Dependent library headers path can be stated as part of meson build command as below.

"Some functionality may be disabled due to library headers being missed as part of
the build. To specify an addition search path for headers at configuration
time, use one of the commands below:"

> +
> +*  Single path ``$ CFLAGS=-I/path meson build``
> +
> +*  Multiple paths ``$ CFLAGS=-I/path1 -I/path2 meson build``
> +
> +Below examples shows how to export libraries and their header paths.
> +
> +To specify single library at a time.
> +
> +        ``$ export LIBRARY_PATH=/root/wireless_libs/zuc/``
> +        ``$ CFLAGS=-I/root/wireless_libs/zuc/include meson build``
> +
> +To specify multiple libraries at a time.
> +
> +        ``$ export LIBRARY_PATH=/root/wireless_libs/zuc/:/root/wireless_libs/`` \
> +                                                    ``libsso_kasumi/build/``
> +        ``$ CFLAGS=-I/root/wireless_libs/zuc/include -I/root/wireless_libs/`` \
> +                                        ``libsso_kasumi/include meson build``
> +
> +
> +
> +Summery of Commands to run meson UTs

"Summary"

> +------------------------------------
> +
> +*   To run all test cases
> +       ``$ meson test``
> +*   To run specific test
> +       ``$ meson test testcase_name``
> +        Ex:``$ meson test acl_autotest``
> +*   To run specific test suite
> +       ``$ meson test --suite DPDK:suite_name``
> +        Ex:``$ meson test --suite DPDK:fast-tests``
> -- 
> 2.17.2
> 

  reply	other threads:[~2019-01-31 14:49 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <yes>
2018-12-12 11:35 ` [dpdk-dev] [PATCH] doc: add meson ut enhancements " Hari Kumar Vemula
2019-01-20 12:04   ` Thomas Monjalon
2019-01-23  6:37   ` [dpdk-dev] [PATCH v2] doc: add meson ut info " Hari Kumar Vemula
2019-01-23 10:53     ` Bruce Richardson
2019-01-24 13:41     ` [dpdk-dev] [PATCH v3] " Hari Kumar Vemula
2019-01-24 14:15       ` Richardson, Bruce
2019-01-25  6:20       ` [dpdk-dev] [PATCH v4] " Hari Kumar Vemula
2019-01-31 14:49         ` Bruce Richardson [this message]
2019-02-02 10:28         ` [dpdk-dev] [PATCH v5] " Hari Kumar Vemula
2019-03-04 17:05           ` Bruce Richardson
2019-04-22 22:35           ` Thomas Monjalon
2019-04-22 22:35             ` Thomas Monjalon
2019-05-01 11:39             ` Mcnamara, John
2019-05-01 11:39               ` Mcnamara, John
2019-06-06 11:59           ` [dpdk-dev] [PATCH v6] " Hari Kumar Vemula
2019-07-08 19:40             ` Thomas Monjalon
2019-07-08 20:18               ` Aaron Conole
2019-07-09 18:57                 ` Michael Santana Francisco
2019-07-22 12:39                   ` Parthasarathy, JananeeX M
2019-07-22 12:53                     ` Thomas Monjalon
2019-07-22 13:53                       ` Bruce Richardson
2019-07-23 11:34                         ` Parthasarathy, JananeeX M
2019-08-07 13:56             ` [dpdk-dev] [PATCH v7] " Agalya Babu RadhaKrishnan
2019-08-07 14:16               ` Jerin Jacob Kollanukkaran
2019-08-07 15:47               ` Michael Santana Francisco
2019-08-12 12:40               ` [dpdk-dev] [PATCH v8] " Jananee Parthasarathy
2020-02-16 10:28                 ` Thomas Monjalon
2019-01-03 12:28 ` [dpdk-dev] [PATCH v2] eal: fix core number validation Hari kumar Vemula
2019-01-03 13:03   ` David Marchand
2019-01-07  7:05   ` Hari Kumar Vemula
2019-01-07 10:25   ` [dpdk-dev] [PATCH v3] " Hari Kumar Vemula
2019-01-10 10:11     ` David Marchand
2019-01-11 14:15   ` [dpdk-dev] [PATCH v4] " Hari Kumar Vemula
2019-01-11 15:06     ` David Marchand
2019-01-14 10:28     ` [dpdk-dev] [PATCH v5] " Hari Kumar Vemula
2019-01-14 14:39       ` David Marchand
2019-01-17 12:13     ` [dpdk-dev] [PATCH v6] " Hari Kumar Vemula
2019-01-17 12:19       ` Bruce Richardson
2019-01-17 12:32         ` David Marchand
2019-01-17 16:31       ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2019-01-07 13:01 ` [dpdk-dev] [PATCH] net/bonding: fix create bonded device test failure Hari Kumar Vemula
2019-01-07 18:44   ` Chas Williams
2019-01-08 10:27     ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2019-01-08 11:14     ` [dpdk-dev] " Vemula, Hari KumarX
2019-01-15 17:37   ` Pattan, Reshma
2019-01-28  7:28   ` [dpdk-dev] [PATCH v2] " Hari Kumar Vemula
2019-01-31 23:40     ` Chas Williams
2019-02-05 13:39     ` [dpdk-dev] [PATCH v3] " Hari Kumar Vemula
2019-02-07 13:34       ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit

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=20190131144928.GA155780@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=hari.kumarx.vemula@intel.com \
    --cc=jananeex.m.parthasarathy@intel.com \
    --cc=john.mcnamara@intel.com \
    --cc=marko.kovacevic@intel.com \
    --cc=reshma.pattan@intel.com \
    /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).