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 2AE79A04B7; Tue, 13 Oct 2020 21:45:27 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 03F241DB72; Tue, 13 Oct 2020 21:45:25 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by dpdk.org (Postfix) with ESMTP id C9A0D1DB6D for ; Tue, 13 Oct 2020 21:45:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602618320; 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=gDL85tPSDE8jD94nCKdLtbY+wuuSTwDS3yCGr64P2AM=; b=N/CgQ2DcdtY2ccv+kKISa5hsqFaJGYNuGWZo9T/Z4IWAnysvxCspePlCnWP8RNz7PXnUXt uD0he+0t4XXyTEl9IY0oGLDgzxsbPwk63d6I8pQAm+U51BPVv1io6rsQ1xPpKYk/NDuH4G 3laIGjpS8PSEQrCyx6n9ucQyftoQPRo= Received: from mail-vs1-f72.google.com (mail-vs1-f72.google.com [209.85.217.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-437-rLhKhgFzMLu1PslAEI0gzA-1; Tue, 13 Oct 2020 15:45:18 -0400 X-MC-Unique: rLhKhgFzMLu1PslAEI0gzA-1 Received: by mail-vs1-f72.google.com with SMTP id s2so308954vsj.21 for ; Tue, 13 Oct 2020 12:45:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gDL85tPSDE8jD94nCKdLtbY+wuuSTwDS3yCGr64P2AM=; b=TBSQwNx8Q0pksY7YtEjUeNO0o2jwt3u7WlXGsKl6Ff0/sSMa1TAkQVbZ9M1dJ9mZ4+ 5P1Isb8MSi3PIjJ5RCNr4nd16xjb5SmdveTtR0d7cQpgtoBPzbHBN0OsG8cexHItOoWb T4LOEHokJUKkdG1wWYL5ZfREqK17ha9aBE72gX2jlhV+NQMtP+d1Q11lz1AFYRapykVI DNBEgtl2yQK3jZpH+voCtaYEUeOqoyp69K1sMjBPyyKQMECE9RsN1SGnYSOjJmtNWveN UQiGk6GFR+l3g62NTik2IgNnGVB6GTCTA31mnDYvKXUtkVHHH5myFCq4VsTCx+B8a46G bOMA== X-Gm-Message-State: AOAM530tAwT9+GhYKDvH2WiEFrX8YXMwXVxj3S4HJH51g6Mui5qkReLV KZDCumVQntXLdh+YrqwzEeYEh//k4qG2gSVwnXNWHDx7qUIP8I6XUmAFGMBHjtL8EFp1pH4Umdt HFB16PuAWDsTGV06J0sc= X-Received: by 2002:a67:68c9:: with SMTP id d192mr1324005vsc.5.1602618317679; Tue, 13 Oct 2020 12:45:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+tPB/R15QgSkn1Y7R3iVMYivJW1/EChl6LO0gVB+ya6/PdFgk8S2QHh4ikF20BKVwoPRIuBEtd4UfkjO5RK4= X-Received: by 2002:a67:68c9:: with SMTP id d192mr1323992vsc.5.1602618317435; Tue, 13 Oct 2020 12:45:17 -0700 (PDT) MIME-Version: 1.0 References: <20200724134506.11959-1-harry.van.haaren@intel.com> <20200914143118.84791-1-harry.van.haaren@intel.com> <20200914143118.84791-2-harry.van.haaren@intel.com> In-Reply-To: From: David Marchand Date: Tue, 13 Oct 2020 21:45:06 +0200 Message-ID: To: Harry van Haaren Cc: dev , Lukasz Wojciechowski , Honnappa Nagarahalli , Phil Yang , Aaron Conole Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v6 2/2] test/service: fix race condition on stopping lcore 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" Hello Harry, Long time no see :-) On Mon, Sep 21, 2020 at 4:51 PM David Marchand wrote: > > On Mon, Sep 14, 2020 at 4:30 PM Harry van Haaren > wrote: > > > > This commit fixes a potential race condition in the tests > > where the lcore running a service would increment a counter > > that was already reset by the test-suite thread. The resulting > > race-condition incremented value could cause CI failures, as > > indicated by DPDK's CI. > > > > This patch fixes the race-condition by making use of the > > added rte_service_lcore_active() API, which indicates when > > a service-core is no longer in the service-core polling loop. > > > > The unit test makes use of the above function to detect when > > all statistics increments are done in the service-core thread, > > and then the unit test continues finalizing and checking state. > > > > Fixes: f28f3594ded2 ("service: add attribute API") > > > > Reported-by: David Marchand > > Signed-off-by: Harry van Haaren > > Reviewed-by: Phil Yang > > Reviewed-by: Honnappa Nagarahalli > We probably need a followup fix for: https://travis-ci.com/github/DPDK/dpdk/jobs/398954463#L10088 The race is in service_attr_get where we look at/reset spent cycles while a service lcore is still running. Quoting this test code: rte_service_lcore_stop(slcore_id); TEST_ASSERT_EQUAL(0, rte_service_attr_get(id, attr_calls, &attr_value), "Valid attr_get() call didn't return success"); TEST_ASSERT_EQUAL(1, (attr_value > 0), "attr_get() call didn't get call count (zero)"); TEST_ASSERT_EQUAL(0, rte_service_attr_reset_all(id), "Valid attr_reset_all() return success"); TEST_ASSERT_EQUAL(0, rte_service_attr_get(id, attr_id, &attr_value), "Valid attr_get() call didn't return success"); -- David Marchand