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 86468A0565; Mon, 23 Mar 2020 16:08:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 393B71C069; Mon, 23 Mar 2020 16:08:23 +0100 (CET) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by dpdk.org (Postfix) with ESMTP id D2A591C02C for ; Mon, 23 Mar 2020 16:08:21 +0100 (CET) Received: by mail-io1-f68.google.com with SMTP id c19so14450399ioo.6 for ; Mon, 23 Mar 2020 08:08:21 -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=UJGpq1wBFVmSFmiuQ1ZSZq6YxGpuR09ZHQH5REBn/9c=; b=ky7Z1R50rW8L9AzmBfEi1Y+jBQnWA9LM1z5CSE+AG3Pdn/q7L8Cc/69Pl/yI2SUt8v 8csDJRY1x9yU/LlwLZYwLZAqgDBYcUHVRcSbtSGbWIljlPVMd4cEne+/yU9l3999lcfH ZV4w3IS/+yxD9t9X795yCxKajkWI9DsFCDJ4ATtwBAzinidBtuP5RKMcsn7kGjoDWxC5 IXqOxZx3fgbAMTVGnvROgstmendam7h1Pk1cjEhoG+jgmEgmwjZuXJYlEEyYCDrah/94 ffKNrhEeH5OMycS8Nu7ufVFXYHHZMrVTleSqq+RGBfc3ZzbArU0/CyL2e27XaI23J8BO Tz3w== 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=UJGpq1wBFVmSFmiuQ1ZSZq6YxGpuR09ZHQH5REBn/9c=; b=JkOStgdkbOAD8Y6q+pnBWawXnCZXUATbLsM61GRXLZEbjymVyAB6V+kckLPDZzBDIW hiAHxmrTUnZivKrrjNkvoAmcF4Hq4vERVDc81hJfxtDMQw7q6Z9NJI2X9UA2awDrozX1 napvd1NF7YZLVz4qHaXpiLxCWkuwIkUJcmSyRIVBYh0gLyhSKgHPPUHH+ECIz6CVVnHW IMeL5JqkaIbfAYG8W4eJDIU9I0NHIQ6+Det9hshXZI94ZGNu9NvEDLeHb2qvWVC/6b26 o3Hw1f3jhT4mmVMgmFfy6LNFJ0l2CIpNii5ZmirGyUZ2ymQYwWxljCxz26Igw+9gL8tr 3vNw== X-Gm-Message-State: ANhLgQ320R8TwDZx2rNDLdx7LH4jjYuw1qValGfj7p3FGX44atbX7Ecg U69WgepDNNDYYMRqNwDk4uagf0BNP1Knl3eYJsw= X-Google-Smtp-Source: ADFU+vt+w4fBLHNxRm/pykVBSpc9a4Ndbfd/M2c9uGgF7RTJBy/Oc00E82hwGp1V5v5Ki2sIc908e7GZA1e/pm5ondY= X-Received: by 2002:a6b:580d:: with SMTP id m13mr10283316iob.59.1584976101082; Mon, 23 Mar 2020 08:08:21 -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> In-Reply-To: <2fd5f760-70ff-54ac-bc85-8acae07065b9@ericsson.com> From: Jerin Jacob Date: Mon, 23 Mar 2020 20:38:05 +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 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_SHIF= T; > >>> + *handle |=3D (uint64_t)level << __RTE_TRACE_FIELD_LEVEL_SHIFT; > >> If *handle would be a struct, you could use a bitfield instead, and mu= ch > >> 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 instructions > for bitfield manipulation. Add x86 maintainers. There were comments in ml about bitfield inefficiency usage with x86. http://patches.dpdk.org/patch/16482/ Search for: Bitfileds are efficient on Octeon. What's about other CPUs you have in mind? x86 is not as efficient. Thoughts from x86 folks. > > there is no performance impact using bitfields from the compiler _if an= y_. > > 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 fire > 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) > > > static uint64_t > > __rte_trace_raw(struct trace *t) > > { > > uint64_t raw; > > memcpy(&raw, t, sizeof(struct trace)); > > return raw; > > } > >