From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 79512A0527; Wed, 15 Jul 2020 15:40:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C077A4C7B; Wed, 15 Jul 2020 15:40:01 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 7FE722C01 for ; Wed, 15 Jul 2020 15:40:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1594820399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3Lj8aVpYMuohsh2hbKfIJiSbYSlJJqbzAb0hjXIwLRo=; b=IrZDrlbLFh+3EkdYgx4vMCdlgHSr1B3vNJOM/xKNvV+zlZNj8ZFYTePXtz+hkNtORlNrjd SXT1a5ZzrS8qG9284j0bLdehlH4PmWrArYysjq4b1iUuMKFydjZvgXE1mQ4cssywbf1Knq YmZC0oFDvtk8JNcDgNzw6SvLosiKTJc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-183-uw5vqN4XNK61h-a-t3ESIQ-1; Wed, 15 Jul 2020 09:39:56 -0400 X-MC-Unique: uw5vqN4XNK61h-a-t3ESIQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DE35D100CCD4; Wed, 15 Jul 2020 13:39:54 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (ovpn-117-20.rdu2.redhat.com [10.10.117.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AE8A61002388; Wed, 15 Jul 2020 13:39:50 +0000 (UTC) From: Aaron Conole To: David Marchand Cc: Lukasz Wojciechowski , Van Haaren Harry , Igor Romanov , Honnappa Nagarahalli , Phil Yang , dev References: Date: Wed, 15 Jul 2020 09:39:49 -0400 In-Reply-To: (David Marchand's message of "Wed, 15 Jul 2020 15:28:15 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Subject: Re: [dpdk-dev] Random failure in service_autotest X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" David Marchand writes: > On Wed, Jul 15, 2020 at 3:09 PM Lukasz Wojciechowski > wrote: >> >> >> W dniu 15.07.2020 o 15:02, David Marchand pisze: >> > On Wed, Jul 15, 2020 at 2:56 PM Aaron Conole wrote: >> >> I guess the service_lcore_attr_get failed, but with no useful >> Why do you suspect service_lcore_attr_get() ? > > https://travis-ci.com/github/ovsrobot/dpdk/jobs/361097992#L18697 > > RTE>>service_autotest > + ------------------------------------------------------- + > + Test Suite : service core test suite > + ------------------------------------------------------- + > + TestCase [ 0] : unregister_all succeeded > + TestCase [ 1] : service_name succeeded > + TestCase [ 2] : service_get_by_name succeeded > Service dummy_service Summary > dummy_service: stats 1 calls 0 cycles 0 avg: 0 > Service dummy_service Summary > dummy_service: stats 0 calls 0 cycles 0 avg: 0 > + TestCase [ 3] : service_dump succeeded > + TestCase [ 4] : service_attr_get succeeded > > *** > + TestCase [ 5] : service_lcore_attr_get failed > *** > > + TestCase [ 6] : service_probe_capability succeeded > + TestCase [ 7] : service_start_stop succeeded > + TestCase [ 8] : service_lcore_add_del skipped > + TestCase [ 9] : service_lcore_start_stop succeeded > + TestCase [10] : service_lcore_en_dis_able succeeded > + TestCase [11] : service_mt_unsafe_poll skipped > + TestCase [12] : service_mt_safe_poll skipped > perf test for MT Safe: 56.9 cycles per call > + TestCase [13] : service_app_lcore_mt_safe succeeded > perf test for MT Unsafe: 83.4 cycles per call > + TestCase [14] : service_app_lcore_mt_unsafe succeeded > + TestCase [15] : service_may_be_active succeeded > + TestCase [16] : service_active_two_cores skipped > + ------------------------------------------------------- + > > >> >> information. We should have the test suite app turn the log level all >> >> the way up. I realize it will increase the log data even higher, but >> >> without it, we have no idea why this test failed. >> >> >> >> Something like the following >> >> --- >> >> >> >> diff --git a/app/test/test.c b/app/test/test.c >> >> index 94d26ab1f6..c47cb075f9 100644 >> >> --- a/app/test/test.c >> >> +++ b/app/test/test.c >> >> @@ -150,6 +150,9 @@ main(int argc, char **argv) >> >> >> >> prgname = argv[0]; >> >> >> >> + rte_log_set_global_level(RTE_LOG_DEBUG); >> >> + rte_log_set_level(RTE_LOGTYPE_EAL, RTE_LOG_DEBUG); >> >> + >> >> recursive_call = getenv(RECURSIVE_ENV_VAR); >> >> if (recursive_call != NULL) { >> >> ret = do_recursive_call(); >> >> --- >> >> >> >> That way we can at least debug when it happens. >> > Debugging is one thing. >> > But here service_lcore_attr_get() has a lot of asserts that should >> > trigger a straight error. >> > >> Yes, but without debugs enabled, the assert message won't be printed out. > > Changing the whole debug levels could have side effects on the > libraries being tested: maybe hide races (too bad) or reveal races > (that would be interesting ;-)). 6 of one, 1/2 dozen of the other. Maybe there are bugs where people run code inside log level tests that get omitted otherwise. > On the other hand, what I am saying is that using debug level logs for > test asserts might not be the best solution. Yeah, that's also a good idea :)