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 C412EA04AB; Wed, 6 Nov 2019 15:18:51 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4DA4A1C1D5; Wed, 6 Nov 2019 15:18:51 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 5B9461C1D5 for ; Wed, 6 Nov 2019 15:18:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573049928; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SANla6WY4ajm6ZB0xUwMmsJqlTH1qz3hqIF+WIgofqU=; b=GZA/Xr5w7M5gjo+FE1xNApFSbTx29xZopORe/HBqs48xTlPCrjwnfhoLB7gX9JwabTo8gZ kXreqJgmF09fH906IQJvXV4p/dJ2wnAAaS2UR1PsII1E04Qbcsv0TnlxbG3EYENJ+r4r/3 u6EqoGNkJmJBkoVy1X1/EOM+16M0X1k= Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-429-JHC5tF8qNrGm_YGUeMRj4Q-1; Wed, 06 Nov 2019 09:18:46 -0500 Received: by mail-ua1-f72.google.com with SMTP id r39so4246900uad.3 for ; Wed, 06 Nov 2019 06:18:46 -0800 (PST) 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=8687+YAGM4vENbB/6ES1zn+jeCG84+VTugqQIZ4gd2I=; b=NDDOU2dvNcEX7+64aH3Ohw8DuU800BS8EfXJbkASR3O+lUiBzbKN+TbfekY5xi7aQy Swkd/7/5Ak8c6ytA7Ta3BlraUURnxYdhXAPOWXpit5nr0myoP4s+DQltGhuUe7KzCxRL x0YWZVRNLq/9rHWYTLbCBbshoDQHFZR5PEYSBX7nXiD5Tf6Zp98rskmZqpPBST04ZWMX KUvpR0Pj0WBb6MExlXXgKnrvudM4xKaN3ARnXeOskEu/UTTN9SYSbvH0mvXexfRDM8VK ZHzNLWpmdNLftmzmOi77RqH8oppvT4Jr87hZ2zy28aFrAMP1XYjUDIh9HP9iS/iXYSgm usjQ== X-Gm-Message-State: APjAAAUJCcxLePi4w7q75ysIV5EWaxfdXx5aTk+3ObAATTJjwrAQQaxw Bsccg26XdRFwujQt0fe4snMuipUwy9jAcMCKTgGHJVHck8MJKbsOU+CReY7HrYg8H1cIbacwmUO smqJUgDnW+qHby3WipFA= X-Received: by 2002:a05:6102:75c:: with SMTP id v28mr1408704vsg.105.1573049925726; Wed, 06 Nov 2019 06:18:45 -0800 (PST) X-Google-Smtp-Source: APXvYqyJlsAM54JvnYF61IfHtIVhTNI64H/Dm7VX1hUQ3vZYF9hDtWAt/0jorOfBxX51+sLDMZU7c6P8R1h9EVfsLCc= X-Received: by 2002:a05:6102:75c:: with SMTP id v28mr1408684vsg.105.1573049925301; Wed, 06 Nov 2019 06:18:45 -0800 (PST) MIME-Version: 1.0 References: <20191018182112.115448-1-drc@ibm.com> <20191018203041.22074-1-drc@linux.vnet.ibm.com> In-Reply-To: <20191018203041.22074-1-drc@linux.vnet.ibm.com> From: David Marchand Date: Wed, 6 Nov 2019 15:18:34 +0100 Message-ID: To: David Christensen Cc: dev X-MC-Unique: JHC5tF8qNrGm_YGUeMRj4Q-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v4] app/test: add tests for atomic exchanges 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" On Fri, Oct 18, 2019 at 10:31 PM David Christensen wrote: > > The test works by creating a token comprised of random data > and a CRC8 value, using the rte_atomicXX_exchange to exchange > the new token for a previously generated token, and then > verifying that the exchanged data is intact (i.e. the CRC8 > is still correct for the data). Thanks, can you rebase this on master? > > Signed-off-by: David Christensen > --- > v4: > * Fix build error due to use of variable initialization > in "for" statement. > > v3: > * Actually fixed build issue on all platforms caused by > misspelling of rte_atomic64_inc > > v2: > * Fixed build issue on all platforms caused by misspelling > of rte_atomic64_inc > > app/test/test_atomic.c | 176 ++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 174 insertions(+), 2 deletions(-) > > diff --git a/app/test/test_atomic.c b/app/test/test_atomic.c > index 43be30ec0..858c6d7f9 100644 > --- a/app/test/test_atomic.c > +++ b/app/test/test_atomic.c > @@ -1,10 +1,12 @@ > /* SPDX-License-Identifier: BSD-3-Clause > * Copyright(c) 2010-2014 Intel Corporation > + * Copyright(c) 2019 Arm Limited > */ > > #include > #include > #include > +#include > #include > > #include > @@ -13,6 +15,8 @@ > #include > #include > #include > +#include > +#include > > #include "test.h" > > @@ -20,7 +24,7 @@ > * 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 > + * - The main test function performs four subtests. The first test Let's drop this sentence. No point in maintaining the number of subtests. > * checks that the usual inc/dec/add/sub functions are working > * correctly: > * > @@ -61,11 +65,26 @@ > * atomic_sub(&count, tmp+1); > * > * - At the end of the test, the *count* value must be 0. > + * > + * - Test "atomic exchange" > + * > + * - Create a 64 bit token that can be tested for data integrity > + * > + * - Invoke ``test_atomic_exchange`` on each lcore. Before doing > + * anything else, the cores wait for a synchronization event. > + * Each core then does the follwoing for N iterations: > + * > + * Generate a new token with a data integrity check > + * Exchange the new token for previously generated token > + * Increment a counter if a corrupt token was received > + * > + * - At the end of the test, the number of corrupted tokens must be 0. > + * > */ > > #define NUM_ATOMIC_TYPES 3 > > -#define N 10000 > +#define N 1000000 > > static rte_atomic16_t a16; > static rte_atomic32_t a32; > @@ -216,6 +235,127 @@ test_atomic_dec_and_test(__attribute__((unused)) vo= id *arg) > return 0; > } > > +/* > + * Helper definitions/variables/functions for > + * atomic exchange tests > + */ > +typedef union { > + uint16_t u16; > + uint8_t u8[2]; > +} rte_u16_t; > + > +typedef union { > + uint32_t u32; > + uint16_t u16[2]; > + uint8_t u8[4]; > +} rte_u32_t; > + > +typedef union { > + uint64_t u64; > + uint32_t u32[2]; > + uint16_t u16[4]; > + uint8_t u8[8]; > +} rte_u64_t; Please, don't use such names for internal types. It gives the impression those are EAL types.. but I don't feel like we need them, so let's just avoid adding them in EAL, now. --=20 David Marchand