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 4BBA8A057B; Mon, 23 Mar 2020 19:40:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 05D5D1C08E; Mon, 23 Mar 2020 19:40:31 +0100 (CET) Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by dpdk.org (Postfix) with ESMTP id E38D41C07E for ; Mon, 23 Mar 2020 19:40:28 +0100 (CET) Received: by mail-il1-f193.google.com with SMTP id h3so14287703ils.3 for ; Mon, 23 Mar 2020 11:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0n5BYr/2Q7jl4/5mXbR79C10bfs/WXEnRWaFJs6mY0M=; b=UNt0mJBjNoDl71iec99PHYdLMUHUtwZZsQFBlLf1LFh4jQIBLX6VuLldXDBejKo5LB 5YZU5tOCydDI0QgUUNm0XnciFFjlPW95H2/pf7vGzCf5VKyQiGWJglXeB6+DBSCgVgUI G8e3y6BNGa3Svxfm9kAdp6waK9FYVZFyqtCCsz7w3uuKBlftXcZRFQKPTOxq3maREfB2 Wbb8hlsKcJuurRzMD6p6Sd9UoXjQkOxH0JiI+flkNyBTy+kOp5shVPmuJgM5Ir3v6drB I4bNy2QVBQ6u+DI66dml+eAXnD9MNv3fzXxLzKqAcGbWJ3y3wsW82WdBYNIFLQqlqJrj 17/w== 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:content-transfer-encoding; bh=0n5BYr/2Q7jl4/5mXbR79C10bfs/WXEnRWaFJs6mY0M=; b=OFLpAKaC6N0Y4LN55c3pYHMXgiaQPmSg1V6NvIwAl5uxLNXrNocPYfAGYERK0WrzoU hXwiUtRMxBmEU05xRbpwOS8Lolrh9TXAWELKgf1mXENp8OjvCl6pYdTWqsCSfvhFQFfN z6xN/MvtxqyIz3Zi3NfCYu5xJOtWFmFB3G1DQyu1mA3rmU5s/pfXShZcxCppXTpCExSk XudauOERTaDyGeuMwQQoiWDSll3bO2yoMOs23LpkmrDdNUQzSAHhVHTFFqOOmzTu0NUZ m4v893N4KIb/p9HMQfDfXYE83Dj87EmqOC0521ERPqJQXqC/YEZVk992wsxVAiR5vW6G b1RA== X-Gm-Message-State: ANhLgQ1/aVXYqNX5JmR7pysWYjXL7i4q0F+mLi8IRNrs0JZSF+sLuJ/L S+gsxrjzRoIGrb2UfFI0folXX1GXSdFhP29CRVM= X-Google-Smtp-Source: ADFU+vuehDaFU+jnFgkJ4p6Injnk8JJKfueG+phgmGCOeE3zHTh42qtsvBGpDo/sMvSDadrxIt9+pPU4i6SGPEEunR0= X-Received: by 2002:a92:8159:: with SMTP id e86mr21234226ild.60.1584988828097; Mon, 23 Mar 2020 11:40:28 -0700 (PDT) MIME-Version: 1.0 References: <20200318190241.3150971-1-jerinj@marvell.com> <20200318190241.3150971-4-jerinj@marvell.com> <5ce75c51-cce7-cee3-da04-b3dc51607864@ericsson.com> <2fd5f760-70ff-54ac-bc85-8acae07065b9@ericsson.com> <10c79d12-ef06-2d7f-86f7-23e459ee3719@ericsson.com> In-Reply-To: <10c79d12-ef06-2d7f-86f7-23e459ee3719@ericsson.com> From: Jerin Jacob Date: Tue, 24 Mar 2020 00:10:12 +0530 Message-ID: To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: "jerinj@marvell.com" , Thomas Monjalon , Sunil Kumar Kori , "dev@dpdk.org" , "bruce.richardson@intel.com" , "david.marchand@redhat.com" , "Ananyev, Konstantin" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v1 03/32] eal/trace: implement trace register API 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 Mon, Mar 23, 2020 at 10:14 PM Mattias R=C3=B6nnblom wrote: > > On 2020-03-23 16:08, Jerin Jacob wrote: > > On Mon, Mar 23, 2020 at 8:13 PM Mattias R=C3=B6nnblom > > wrote: > >> On 2020-03-23 14:37, Jerin Jacob wrote: > >>>>> + } > >>>>> + > >>>>> + /* Initialize the trace point */ > >>>>> + if (rte_strscpy(tp->name, name, TRACE_POINT_NAME_SIZE) < 0) { > >>>>> + trace_err("name is too long"); > >>>>> + rte_errno =3D E2BIG; > >>>>> + goto free; > >>>>> + } > >>>>> + > >>>>> + /* Copy the field data for future use */ > >>>>> + if (rte_strscpy(tp->ctf_field, field, TRACE_CTF_FIELD_SIZE) <= 0) { > >>>>> + trace_err("CTF field size is too long"); > >>>>> + rte_errno =3D E2BIG; > >>>>> + goto free; > >>>>> + } > >>>>> + > >>>>> + /* Clear field memory for the next event */ > >>>>> + memset(field, 0, TRACE_CTF_FIELD_SIZE); > >>>>> + > >>>>> + /* Form the trace handle */ > >>>>> + *handle =3D sz; > >>>>> + *handle |=3D trace.nb_trace_points << __RTE_TRACE_FIELD_ID_SH= IFT; > >>>>> + *handle |=3D (uint64_t)level << __RTE_TRACE_FIELD_LEVEL_SHIFT= ; > >>>> If *handle would be a struct, you could use a bitfield instead, and = much > >>>> simplify this code. > >>> I thought that initially, Two reasons why I did not do that > >>> 1) The flags have been used in fastpath, I prefer to work with flags > >>> in fastpath so that > >> Is it really that obvious that flags are faster than bitfield > >> operations? I think most modern architectures have machine instruction= s > >> for bitfield manipulation. > > Add x86 maintainers. > > > > There were comments in ml about bitfield inefficiency usage with x86. > > > > https://protect2.fireeye.com/v1/url?k=3D2bd2d3ad-7706d931-2bd29336-8631= fc8bdea5-8a1bf17ed26f6ce6&q=3D1&e=3D0c620ac5-c028-44d9-a4e8-e04057940075&u= =3Dhttp%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F16482%2F > > > > Search for: Bitfileds are efficient on Octeon. What's about other CPUs > > you have in > > mind? x86 is not as efficient. > > > I thought both ARM and x86 had bitfield access instructions, but it > looks like I was wrong about x86. x86_64 GCC seems to convert bitfield > read to 'shr' and 'and', just like an open-coded bitfield. Bitfield > write requires more instructions. Yes. ARM64 has bitfield access instructions. considering x86, it is better to avoid bitfields. See below, > > > > Thoughts from x86 folks. > > > >>> there is no performance impact using bitfields from the compiler _if = any_. > >>> 2) In some of the places, I can simply operate on APIs like > >>> __atomic_and_fetch() with flags. > >> I think you may still use such atomic operations. Just convert the > >> struct to a uint64_t, which will essentially be a no-operation, and fi= re > >> away. > > Not sure, We think about the atomic "and" and fetch here. > > That memcpy may translate additional load/store based on the compiler > > optimization level.(say compiled with -O0) > > > I would be surprised if that happened on anything but -O0. At least > modern GCC on ARM and x86_64 don't seem to add any loads or stores. > > > I assume you are not suggesting we should optimize for -O0. No. I was just mentining that, we can not assume the code generation with -O0. Anyway considering the above point, lets use flags.