From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 523C04A63 for ; Tue, 26 May 2015 12:13:27 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP; 26 May 2015 03:13:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,497,1427785200"; d="scan'208";a="731714294" Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98]) by fmsmga002.fm.intel.com with ESMTP; 26 May 2015 03:13:25 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by PGSMSX106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 26 May 2015 18:13:23 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.120]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.94]) with mapi id 14.03.0224.002; Tue, 26 May 2015 18:13:22 +0800 From: "Fu, JingguoX" To: "Tang, HaifengX" , "dts@dpdk.org" Thread-Topic: [dts 03/28] add unit_test_eal rst file into dts Thread-Index: AQHQl4FZEIXDHfCv+EmsaAX2MD8rHp2OChOw Date: Tue, 26 May 2015 10:13:21 +0000 Message-ID: <6BD6202160B55B409D4232931158226266F73F@SHSMSX101.ccr.corp.intel.com> References: <1432623448-19146-1-git-send-email-haifengx.tang@intel.com> <1432623448-19146-3-git-send-email-haifengx.tang@intel.com> In-Reply-To: <1432623448-19146-3-git-send-email-haifengx.tang@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BK5L BU0m BtLp CDCy CKA2 DaBd DePr D7cF Ee8n FIPx GIBw Hn9h I7GW JyyB J819 MsIg; 1; ZAB0AHMAQABkAHAAZABrAC4AbwByAGcA; Sosha1_v1; 7; {C29FEF6A-A298-44D3-B0AF-9B269D80E8D1}; agBpAG4AZwBnAHUAbwB4AC4AZgB1AEAAaQBuAHQAZQBsAC4AYwBvAG0A; Tue, 26 May 2015 10:13:19 GMT; UgBFADoAIABbAGQAdABzACAAMAAzAC8AMgA4AF0AIABhAGQAZAAgAHUAbgBpAHQAXwB0AGUAcwB0AF8AZQBhAGwAIAByAHMAdAAgAGYAaQBsAGUAIABpAG4AdABvACAAZAB0AHMA x-cr-puzzleid: {C29FEF6A-A298-44D3-B0AF-9B269D80E8D1} x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Fu, JingguoX" Subject: Re: [dts] [dts 03/28] add unit_test_eal rst file into dts 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: Tue, 26 May 2015 10:13:28 -0000 > -----Original Message----- > From: Tang, HaifengX > Sent: Tuesday, May 26, 2015 14:57 > To: dts@dpdk.org > Cc: Fu, JingguoX; Tang, HaifengX > Subject: [dts 03/28] add unit_test_eal rst file into dts >=20 > --- > test_plans/unit_tests_eal_test_plan.rst | 315 > +++++++++++++++++++++++++++++++ > 1 files changed, 315 insertions(+), 0 deletions(-) > create mode 100644 test_plans/unit_tests_eal_test_plan.rst >=20 > diff --git a/test_plans/unit_tests_eal_test_plan.rst > b/test_plans/unit_tests_eal_test_plan.rst > new file mode 100644 > index 0000000..c1f8950 > --- /dev/null > +++ b/test_plans/unit_tests_eal_test_plan.rst > @@ -0,0 +1,315 @@ > +.. Copyright (c) <2010>, Intel Corporation > + All rights reserved. > + > + Redistribution and use in source and binary forms, with or without > + modification, are permitted provided that the following conditions > + are met: > + > + - Redistributions of source code must retain the above copyright > + notice, this list of conditions and the following disclaimer. > + > + - Redistributions in binary form must reproduce the above copyright > + notice, this list of conditions and the following disclaimer in > + the documentation and/or other materials provided with the > + distribution. > + > + - Neither the name of Intel Corporation nor the names of its > + contributors may be used to endorse or promote products derived > + from this software without specific prior written permission. > + > + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > + "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > + LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS > + FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE > + COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, > + INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES > + (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR > + SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > + HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > + STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED > + OF THE POSSIBILITY OF SUCH DAMAGE. > + > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +EAL Autotests > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +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 > +=3D=3D=3D=3D=3D=3D=3D > + > +To Be Filled > + > + > +Common > +=3D=3D=3D=3D=3D=3D=3D > + > +To Be Filled > + > +Eal_fs > +=3D=3D=3D=3D=3D=3D > + > +To Be Filled > + > +Memory > +=3D=3D=3D=3D=3D=3D > + > +- 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 > +=3D=3D=3D > + > +- 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 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +- 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 > +=3D=3D=3D=3D=3D=3D=3D=3D > + > +- 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 release= s > + the global lock. > + - The function takes the per-lcore lock, displays something, then rele= ases > + 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. > + > +Rwlock > +=3D=3D=3D=3D=3D=3D > + > +- There is a global rwlock and a table of rwlocks (one per lcore). > + > +- The test function takes all of these locks and launches the > + ``test_rwlock_per_core()`` function on each core (except the master). > + > + - The function takes the global write lock, display something, > + then releases the global lock. > + - Then, it takes the per-lcore write lock, display something, and > + releases the per-core lock. > + - Finally, a read lock is taken during 100 ms, then released. > + > +- 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. > + > + Then, it tries to take the global write lock and display the last > + message. The autotest script checks that the message order is correct. > + > +Atomic Variables > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +- 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 synchronizatioin using the ``while > + (rte_atomic32_read(&val) =3D=3D 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 successfu= l, > + 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 =3D atomic_add_return(&a, 1); > + atomic_add(&count, tmp); > + tmp =3D atomic_sub_return(&a, 1); > + atomic_sub(&count, tmp+1); > + > + - At the end of the test, the *count* value must be 0. > + > +Prefetch > +=3D=3D=3D=3D=3D=3D=3D=3D > + > +Just test that the macro can be called and validate the compilation. > +The test always return success. > + > +Byteorder functions > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +Check the result of optimized byte swap functions for each size (16-, > +32- and 64-bit). > + > +Cycles Test > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +- Loop N times and check that the timer alway increments and > + never decrements during this loop. > + > +- Wait one second using rte_usleep() and check that the increment > + of cycles is correct with regard to the frequency of the timer. > + > +Logs > +=3D=3D=3D=3D > + > +- Enable log types. > +- Set log level. > +- Execute logging functions with different types and levels; some should > + not be displayed. > + > +Memzone > +=3D=3D=3D=3D=3D=3D=3D > + > +- 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 > +=3D=3D=3D=3D=3D=3D > + > +Create two buffers, and initialise one with random values. These are cop= ied > +to the second buffer and then compared to see if the copy was successful= l. > +The bytes outside the copied area are also checked to make sure they wer= e not > +changed. > + > +This is repeated for a number of different sizes and offsets, with > +the second buffer being cleared before each test. > + > +Debug test > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +- Call rte_dump_stack() and rte_dump_registers(). > + > +Alarm > +=3D=3D=3D=3D=3D > + > +- Check that the callback for the alarm can to be called. > +- Check that it is not possible to set alarm with invalid time value. > +- Check that it is not possible to set alarm without a callback. > +- Check that it is not possible to cancel alarm without a callback point= er. > +- Check that multiple callbacks for the alarm can be called. > +- Check that the number of removed and unremoved alarms are correct. > +- Check that no callback is called if all alarm removed. > +- Check that it is not possible to cancel an alarm within the callback i= tself. > +- Check that the callback which is the head of all is able to be removed= . > +- Check that all alarms for the same callback can be cancelled. > + > + > +CPU flags > +=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +- Using the rte_cpu_get_flag_enabled() checks for CPU features from diff= erent > CPUID tables > +- Checks if rte_cpu_get_flag_enabled() properly fails on trying to check= for > invalid feature > + > + > +Errno > +=3D=3D=3D=3D=3D > + > +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 t= he > correct error message is returned. > + > +Interrupts > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +- 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 han= dle. > +- 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 hand= le or > wrong handle type. > +- Check that it is not possible to disable an interrupt with invalid han= dle > or wrong handle type. > + > + > +Multiprocess > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +Validates that a secondary Intel DPDK instance can be run alongside a pr= imary > when the appropriate EAL command-line flags are passed. Also validates th= at > secondary processes cannot interfere with primary processes by creating m= emory > objects, such as mempools or rings. > + > +String > +=3D=3D=3D=3D=3D=3D > + > +Performs validation on the new string functions provided in rte_string_f= ns.h, > ensuring that all values returned are NULL terminated, and that suitable > errors are returned when called with invalid parameters. > + > +Tailq > +=3D=3D=3D=3D=3D > + > +Validates that we can create and perform lookups on named tail queues wi= thin > the EAL for various object types. Also ensures appropriate error codes ar= e > returned from the functions if invalid parameters are passed. > + > +Devargs > +=3D=3D=3D=3D=3D=3D=3D > +To Be Filled > + > +Kvargs > +=3D=3D=3D=3D=3D=3D > +To Be Filled > + > +Acl > +=3D=3D=3D > +To Be Filled > + > +Link_bonding > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +To Be Filled > -- > 1.7.4.4 Acked-by: Jingguo Fu