From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; Mon, 23 Mar 2020 19:40:28 +0100 (CET)
Received: by mail-il1-f193.google.com with SMTP id h3so14287703ils.3
for <dev@dpdk.org>; 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>
<CALBAE1N=JcHcJQS4oo7_a+SX=BKxQB-xyD+yS7kytVCHQ4P6-Q@mail.gmail.com>
<2fd5f760-70ff-54ac-bc85-8acae07065b9@ericsson.com>
<CALBAE1PXhp8FQoss5vzOaw583FuEgitVVgeFUm8HkGXRsTre8A@mail.gmail.com>
<10c79d12-ef06-2d7f-86f7-23e459ee3719@ericsson.com>
In-Reply-To: <10c79d12-ef06-2d7f-86f7-23e459ee3719@ericsson.com>
From: Jerin Jacob <jerinjacobk@gmail.com>
Date: Tue, 24 Mar 2020 00:10:12 +0530
Message-ID: <CALBAE1NMcnoxD04U7uwz4V2Jkm5APp6B669p9QVLbG8EDFm-Zw@mail.gmail.com>
To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= <mattias.ronnblom@ericsson.com>
Cc: "jerinj@marvell.com" <jerinj@marvell.com>,
Thomas Monjalon <thomas@monjalon.net>,
Sunil Kumar Kori <skori@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"david.marchand@redhat.com" <david.marchand@redhat.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
On Mon, Mar 23, 2020 at 10:14 PM Mattias R=C3=B6nnblom
<mattias.ronnblom@ericsson.com> wrote:
>
> On 2020-03-23 16:08, Jerin Jacob wrote:
> > On Mon, Mar 23, 2020 at 8:13 PM Mattias R=C3=B6nnblom
> > <mattias.ronnblom@ericsson.com> 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.