From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 0/7] Make unit tests great again Date: Tue, 12 Jun 2018 15:07:23 +0200 Message-ID: <8176896.7gnY6nVOUV@xps> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, john.mcnamara@intel.com, reshma.pattan@intel.com, bruce.richardson@intel.com, Jananee Parthasarathy To: Anatoly Burakov Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 21F351E99F for ; Tue, 12 Jun 2018 15:07:26 +0200 (CEST) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" +Cc Jananee 07/06/2018 23:01, Anatoly Burakov: > Previously, unit tests were running in groups. There were > technical reasons why that was the case (mostly having to do > with limiting memory), but it was hard to maintain and update > the autotest script. > > In 18.05, limiting of memory at DPDK startup was no longer > necessary, as DPDK allocates memory at runtime as needed. This > has the implication that the old test grouping can now be > retired and replaced with a more sensible way of running unit > tests (using multiprocessing pool of workers and a queue of > tests). This patchset accomplishes exactly that. > > This patchset conflicts with some of the earlier work on > autotests [1] [2] [3], but i think it presents a cleaner > solution for some of the problems highlighted by those patch > series. I can integrate those patches into this series if > need be. > > [1] http://dpdk.org/dev/patchwork/patch/40370/ > [2] http://dpdk.org/dev/patchwork/patch/40371/ > [3] http://dpdk.org/dev/patchwork/patch/40372/ It may be interesting to work on lists of tests as done in the following patch: http://dpdk.org/dev/patchwork/patch/40373/ The idea is to split tests in several categories: - basic and short test - longer and lower priority - performance test As a long term solution, we can think about making category an attribute inside the test itself?