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 8FBDAA0597; Tue, 21 Apr 2020 16:25:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DCAA21D154; Tue, 21 Apr 2020 16:25:12 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 2DFBC1C43A for ; Tue, 21 Apr 2020 16:25:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587479110; 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=SHj1LuORMo5AEexfaBJ34dbUG3G2f4KCPUOmkTHPCcE=; b=I3cdhgltqL+Wku5e+ItDNYNx3zKoat1uoaknOLGLhW+ure1df636J0QfpG4niF/wGT3GtD us+1v1VwJxyzKG+7hC0ZTRF0vhVQCdW5R1vO9anutjQNNtlBIUOPLO+UZXHUXqAkPm+kLJ 17Z542Z/nbKkqEWVkOfEkCITbf309u4= Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-406-xIqJGX9KMWqSoP0L4ajJrQ-1; Tue, 21 Apr 2020 10:25:06 -0400 X-MC-Unique: xIqJGX9KMWqSoP0L4ajJrQ-1 Received: by mail-ua1-f69.google.com with SMTP id z20so2436511uag.19 for ; Tue, 21 Apr 2020 07:25:06 -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=ItBZLiHSr4f5PWF/LO4/hm9+sGoNVCIZsCmHxqr/Wzc=; b=Y8AnENKnOU1qsuUw4uiQyZsScUlKOY22VZ0zPsnIerKscwqqPrIlQEnTuapZEbEBgp fwqebe23osyI+YVZfuA/yhECMTnMC2qR4YH827IYd9Qx5JPaHyvpxfCTCuBSCzesLYfx 6seLWkHG46L1Vreg+VIxIW9TTUiT/VKShVW7kSKYTuuSc5IDK4L0J3qdai48Kb/dN5If ae07G+vGorsBbiQN3Ni3EgVogEkYxI5m2Ph91MTK11bdNwL74sjTZZQ8dplEREXAAbZb nJHC3QXI22zTr6+XlpFbtsFQy1/mlA7r1ZZyk/nGIuj6v2AI3yw+PCcU4bEJHvPLdOAx pXGg== X-Gm-Message-State: AGi0PuZSdUcf5BCsPPnFt+pMBcb1ROfY/Z8mNx4WNFxuPJtmq4XLsBbc mt/6QgLZJa+H3mEUuH2/h61L7pOS0eMFnKJhYFcSUk53OVBN3FG2jeK9oRLZF3h66gtlBgV8wu4 GJCxAqp+hXr1fDGfBtfg= X-Received: by 2002:a05:6102:1043:: with SMTP id h3mr16113703vsq.39.1587479106136; Tue, 21 Apr 2020 07:25:06 -0700 (PDT) X-Google-Smtp-Source: APiQypIADLkegeHCvtt6qKFtDFM/CYgj1n6lkQyMbWbkg8/0hSejPJOgfQhxhH+7PQB2YPNisj33rSvfzw9Xl1KX7j8= X-Received: by 2002:a05:6102:1043:: with SMTP id h3mr16113686vsq.39.1587479105824; Tue, 21 Apr 2020 07:25:05 -0700 (PDT) MIME-Version: 1.0 References: <20200413150116.734047-1-jerinj@marvell.com> <20200419100133.3232316-1-jerinj@marvell.com> <20200419100133.3232316-28-jerinj@marvell.com> In-Reply-To: From: David Marchand Date: Tue, 21 Apr 2020 16:24:54 +0200 Message-ID: To: Jerin Jacob Cc: Jerin Jacob Kollanukkaran , dev , Thomas Monjalon , Bruce Richardson , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Sunil Kumar Kori X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v6 27/33] eal/trace: add unit test cases 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 Tue, Apr 21, 2020 at 3:54 PM Jerin Jacob wrote: > > On Tue, Apr 21, 2020 at 6:23 PM David Marchand > wrote: > > > > On Sun, Apr 19, 2020 at 12:03 PM wrote: > > > > > > From: Sunil Kumar Kori > > > > > > Example commands to run UT and check the traces with babeltrace viewe= r. > > > > > > - Delete the existing /root/dpdk-traces/ directory if needed. > > > > sudo rm -rf /root/dpdk-traces/ > > > > > > - Start the dpdk-test > > > > sudo ./build/app/test/dpdk-test -c 0x3 - --trace=3D.* > > > > Unit tests are there to do sanity/non regression checks. > > Here you describe a manual test procedure. > > Could it work in the CI for the functional parts? > > Except for test_trace_mode() all test cases run with trace disabled. > The trace memory will be allocated per thread IFF the trace is enabled. > I would like to disable trace by default and enable only if " --trace=3D.= *" > provided. Not sure what is the next step here? > > 1) Add this test case in app/test/meson.build under "fast_tests" ? > 2) Can CI start with --trace=3D? If yes, is it required? what would the > integration challenges like > filesystem need for storing the traces etc. > > Thoughts? - At least putting in fast_tests will get us basic checks on the rte_trace_= API. - Running with the traces on and checking against a reference (but ignoring the timestamps) would be nice. I did not think this through. > > > diff --git a/app/test/test_trace_register.c b/app/test/test_trace_reg= ister.c > > > new file mode 100644 > > > index 000000000..1735149a2 > > > --- /dev/null > > > +++ b/app/test/test_trace_register.c > > > @@ -0,0 +1,17 @@ > > > +/* SPDX-License-Identifier: BSD-3-Clause > > > + * Copyright(C) 2020 Marvell International Ltd. > > > + */ > > > +#define RTE_TRACE_POINT_REGISTER_SELECT /* Select trace point regist= er macros */ > > > > I noticed this comment is copy/pasted in all trace points "register" co= de. > > This does not help. > > > > The documentation on the other side does not describe this macro which > > is quite important for developers adding tracepoints to their code > > (Thomas already commented about it on the doc patch). > > > We have the following comments in the header file. > Let me know, what else you would like to mention here? > > /** > * Macro to select rte_trace_point_emit_* definition for trace register f= unction > * > * rte_trace_point_emit_* emits different definitions for trace function. > * Application must define RTE_TRACE_POINT_REGISTER_SELECT before includi= ng > * rte_trace_point.h in the C file where RTE_TRACE_POINT_REGISTER used. > * > * @see RTE_TRACE_POINT_REGISTER > */ > #define RTE_TRACE_POINT_REGISTER_SELECT > Maybe summarize this in doc/guides/prog_guide/trace_lib.rst: the trace function and its name to be similar. However, it is recommended = to have a similar name for a better naming convention. +The special macro ``RTE_TRACE_POINT_REGISTER_SELECT`` must be defined befo= re +including the header for the tracepoint registration to work properly. + The user must register the tracepoint before the ``rte_eal_init`` invocati= on. The user can use the ``RTE_INIT`` construction scheme to achieve the same. --=20 David Marchand