From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F376F45A03; Tue, 24 Sep 2024 17:58:01 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CA33E402B9; Tue, 24 Sep 2024 17:58:01 +0200 (CEST) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) by mails.dpdk.org (Postfix) with ESMTP id 096D54028E for ; Tue, 24 Sep 2024 17:58:01 +0200 (CEST) Received: by mail-ot1-f51.google.com with SMTP id 46e09a7af769-711009878ccso3401990a34.2 for ; Tue, 24 Sep 2024 08:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727193480; x=1727798280; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fpYIKkZjgMmqeZucixRoL9AqSHcdnCXnkk6gZGiwEqQ=; b=LYVQujPpLoGftrh0IRPYShPdQAyEZakMv/G+NMI2nbUthVMdrPsEkTxPWwmxto0VcX uBip72ryKlseGP3hP0m4rVGG6TwPpCOgidpJseUCS14MCtaTK5Yhtlrdi6GJo4h5y+4s EhvWkq5I+HAgz6kWIWA2V2jBH3CrpTUoipiL0EVW/Q2KAFJAkbbpsuIyMQ/Pu7BAQ/dW u5HS7bqOZXg8rEv4DH4z4s2NedWSi/dptA5Kb18GRywZ3DdTqt02K34+BCgfK9zvpghM IQ6UgiGtX0pQnzgmTTNojJpiBtazjFUDJ5lmxbzwD+IjGVHayLgrYZVsqVJj7U+Fdr3I 5n1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727193480; x=1727798280; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fpYIKkZjgMmqeZucixRoL9AqSHcdnCXnkk6gZGiwEqQ=; b=rLxaVrbuOhKRzmE5vNc0VQq7b7KNUmgqMSVLyKK19FNdDUquHo5DKm3OpywB98Ci6G JuLDGBTIQXyzCOkKyIO3mF9/UV8BLrkwoVty/beqmpHN4zr67C+StuMzkquuNEH6BcIV GfMwjubmeVnY12mzoO2gbV0gLDoCRMEveooLUqHM9z0IBlSHnLIH4/rlbsIbRtEe9olS IwKR2bv6rGN61tDiDFMo3pfzcj4oAORxLHEnAn7J47BLphgiKi38a14PFVL4esTvCK2q qVsaweqhsbVDfdt6mVsqH8e9ZkEdUFBiTc9FGLvN3oiykYyfskETbNU9xjSTKKBZfInX 18QA== X-Forwarded-Encrypted: i=1; AJvYcCUGj7DwbdLCiFHaQB5+2+lA3DuQugr0sFxEi1cF8PdU4hhTxkAjDcus8DSgfr927yFBWQ8=@dpdk.org X-Gm-Message-State: AOJu0YxaacYs8abpPdRpmfzZllpkxo4UbMQagSQc5WdJ17PMEdWWUQSz qYH+8UjvKI5KLx03IMAo87wieTeLxkVkcGrA+oREQoOnqNoCyQzYvpgMEgnu1raoNvd4DmcDn5J QgGjzWVIXohAeQ/Ry2ZBUPKU6piw= X-Google-Smtp-Source: AGHT+IE0GqvimofIXzUvvG8HUOsAxSdycZxDUXnl5whKLAC5cJnxmr8dBjgYjIr9gyPRCIVMYXS7rx6rapoUIm5Gbqs= X-Received: by 2002:a05:6358:e49a:b0:1bc:7c89:6018 with SMTP id e5c5f4694b2df-1bc99d18dc3mr489731355d.9.1727193480003; Tue, 24 Sep 2024 08:58:00 -0700 (PDT) MIME-Version: 1.0 References: <20240918085551.231015-1-mb@smartsharesystems.com> <20240924133957.1505113-1-mb@smartsharesystems.com> <98CBD80474FA8B44BF855DF32C47DC35E9F72A@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F72A@smartserver.smartshare.dk> From: Jerin Jacob Date: Tue, 24 Sep 2024 21:27:33 +0530 Message-ID: Subject: Re: [PATCH v4] eal: add build-time option to omit trace To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: Jerin Jacob , Sunil Kumar Kori , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Sep 24, 2024 at 9:23=E2=80=AFPM Morten Br=C3=B8rup wrote: > > > From: Jerin Jacob [mailto:jerinjacobk@gmail.com] > > Sent: Tuesday, 24 September 2024 11.42 > > > > On Tue, Sep 24, 2024 at 7:10=E2=80=AFPM Morten Br=C3=B8rup > > wrote: > > > > > > Some applications want to omit the trace feature. > > > Either to reduce the memory footprint, to reduce the exposed attack > > > surface, or for other reasons. > > > > > > This patch adds an option in rte_config.h to include or omit trace in > > the > > > build. Trace is included by default. > > > > > > Omitting trace works by omitting all trace points. > > > For API and ABI compatibility, the trace feature itself remains. > > > > > > Signed-off-by: Morten Br=C3=B8rup > > > --- > > > v4: > > > * Added check for generic trace enabled when registering trace points= , > > in > > > RTE_INIT. (Jerin Jacob) > > > * Test application uses function instead of macro to check if generic > > > trace is enabled. (Jerin Jacob) > > > * Performance test application uses function to check if generic trac= e > > is > > > enabled. > > > v3: > > > * Simpler version with much fewer ifdefs. (Jerin Jacob) > > > v2: > > > * Added/modified macros required for building applications with trace > > > omitted. > > > > > > > > +/** > > > + * @internal > > > > Since it is used in app/test. Can we remove it as internal and make > > symbol as rte_trace_point_is_enabled > > I don't think we should make functions public if only used for test purpo= ses. > > Do you think it is useful for normal usage too? Does rte_trace_is_enabled= () not suffice? It will be good for an app to know, Is trace feature disabled if the application cares about. Yes. rte_trace_is_enabled() suffice. > > > > > > + * > > > + * Test if the tracepoint compile-time option is enabled. > > > + * > > > + * @return > > > + * true if tracepoint enabled, false otherwise. > > > + */ > > > +__rte_experimental > > > +static __rte_always_inline bool > > > +__rte_trace_point_generic_is_enabled(void) > > > > Do we need to keep _generic_ > > Other internal functions have _generic_ too, so I added it. > If we decide to make it public, I agree _generic_ should be removed. > > > > > Rest looks good to me.