From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63781C282CE for ; Tue, 4 Jun 2019 15:49:53 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 0024B20717 for ; Tue, 4 Jun 2019 15:49:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0024B20717 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CC01B1BC22; Tue, 4 Jun 2019 17:49:51 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 88B841BC14 for ; Tue, 4 Jun 2019 17:49:50 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ECE7F83F4C; Tue, 4 Jun 2019 15:49:41 +0000 (UTC) Received: from localhost.localdomain (unknown [10.18.25.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 90BA56134B; Tue, 4 Jun 2019 15:49:34 +0000 (UTC) To: David Marchand , dev@dpdk.org Cc: thomas@monjalon.net, aconole@redhat.com References: <1559638792-8608-1-git-send-email-david.marchand@redhat.com> From: Michael Santana Francisco Organization: Red Hat Message-ID: <81c5f665-97ac-c4d0-8281-8f195c63195e@redhat.com> Date: Tue, 4 Jun 2019 11:49:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <1559638792-8608-1-git-send-email-david.marchand@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 04 Jun 2019 15:49:44 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 00/14] Unit tests fixes for CI X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: msantana@redhat.com List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 6/4/19 4:59 AM, David Marchand wrote: > This is a joint effort to make the unit tests ready for CI. > The first 8 patches are fixes that I had accumulated. > Then the second part of the series focuses on skipping tests when some > requirements are not fulfilled so that we can start them in a restrained > environment like Travis virtual machines that gives us two cores and does > not have specific hw devices. > > We are still not ready for enabling those tests in Travis. > At least, the following issues remain: > - some fixes on librte_acl have not been merged yet [1], > - the tests on --file-prefix are still ko, and have been isolated in a > test that we could disable while waiting for the fixes, > - rwlock_autotest and hash_readwrite_lf_autotest are taking a little more > than 10s, It would be a good idea to increase timeout. These are probably not the only tests that would pass with just a little bit more time > - librte_table unit test crashes on ipv6 [2], > - the "perf" tests are taking way too long for my taste, We should still fix them. However I don't know if we should be running the perf test for every job and every patch on travis. It takes too long. The travis queue will be delayed too far behind for it to be of any use. OTOH we could have one job as part of the travis build dedicated to running tests (or just perf test). It's still time consuming but better than running the test on every travis job. For this to work we would need to decreased the timeout for the perf tests as the timeout for it and the travis are both 10 minutes > - the shared build unit tests all fail when depending on mempool since > the mempool drivers are not loaded, > > 1: http://patchwork.dpdk.org/project/dpdk/list/?series=4242 > 2: https://bugs.dpdk.org/show_bug.cgi?id=285 > > Comments/reviews welcome! >