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 8A7F4A04B2; Mon, 4 May 2020 19:08:33 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E88A31D168; Mon, 4 May 2020 19:08:32 +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 C7CEA1D160 for ; Mon, 4 May 2020 19:08:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588612111; 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=Om/mryV9B+T2XPZ4aje9r+/bNHlWH+ImdoPrbGxrMFM=; b=dnge6U4wh0YKObBJtV11mT+VXzilyC47ZVTOlDAyf+9moJqfiSHG5yJcKYkLRK5V0B9lq/ b36BPCLu93wl/fowCbbgV49KdKOzrBhjRIqyVZUv8dg6zy8UpixQpp9+undfyftSuulUcl kd2bSQ3dQUkc3p/dzKNoxVpoz6PRe1Q= Received: from mail-vs1-f72.google.com (mail-vs1-f72.google.com [209.85.217.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-330-0WhaMp8YOEaOgZbM71z0qw-1; Mon, 04 May 2020 13:08:29 -0400 X-MC-Unique: 0WhaMp8YOEaOgZbM71z0qw-1 Received: by mail-vs1-f72.google.com with SMTP id v1so45331vsi.17 for ; Mon, 04 May 2020 10:08:29 -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=Zn5FI+i84S87L3XGTI9xniPtR/IOjs4eJ6o4hEsVQw4=; b=cWnmpHGzZmc4pNPXSvHNGaVuftgb9+AAvMUMorCTf9ACq/atoL797rADdMctdNzHXg MJphSJevvAR9posioDJjKmv/SZakhCBFeh8ooj+bzFjea7TWBVKtQ10lpgkAoZvpiSKr x6cDlWEMuzSiY1PfmgQCeYEzPoUcu6L+W7ZTTWi3DZyCEQTNpkXVEQ58WyrjmLhquAl1 OZkxyCPlB9N9+2VjmK6jdQL/i3yXQgVGlTGdUIH4SRMpAQQZQsf5JNEmAzGU+ZjvIXnP BULBWlne6YZM4NeDBk4zHZnRBKu3TstfOhyVh+hxdmETVwT9FYl8rC2zfXQzAgs6otCp y2dQ== X-Gm-Message-State: AGi0Pub+vXzcUbLI41rFhIKedweFxw6XDoQig0BMnH32uWy/hBWI2kcA xh23H92hgwCwEcBMNQ0KjSipW4Cjqo4M6z7OJafcaDQeG1UO6ZlNtKwjUDODckEiWn6eMJIIsZp HZjmMN3Xql3FpF/OOGfk= X-Received: by 2002:ab0:5ad1:: with SMTP id x17mr12489213uae.126.1588612108982; Mon, 04 May 2020 10:08:28 -0700 (PDT) X-Google-Smtp-Source: APiQypIiFhlYCP9Ed2bv6mdsc5G2ZwKG4ObIL1YnOy8EQSToop7PwdLaAv/zp+Lcmz5mVRe7FBLXwVc0qp//hUPnWlo= X-Received: by 2002:ab0:5ad1:: with SMTP id x17mr12489179uae.126.1588612108647; Mon, 04 May 2020 10:08:28 -0700 (PDT) MIME-Version: 1.0 References: <20200503203135.6493-1-david.marchand@redhat.com> <20200503203135.6493-3-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Mon, 4 May 2020 19:08:17 +0200 Message-ID: To: Jerin Jacob Cc: dpdk-dev , Thomas Monjalon , Jerin Jacob , Sunil Kumar Kori , John McNamara , Marko Kovacevic , Declan Doherty , Ferruh Yigit , Andrew Rybchenko , Olivier Matz 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 2/8] trace: simplify trace point registration 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, May 4, 2020 at 4:39 PM Jerin Jacob wrote: > > On Mon, May 4, 2020 at 7:34 PM David Marchand = wrote: > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob wrot= e: > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand wrote: > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pa= irs. > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor = part. > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > this largely grows the number of constructors been called. > > > I had concerns about the boot time of the application and/or loading > > > the shared library, that the reason why spitting > > > as two so that constructor registers a burst of traces like rte_log. > > > > I am a bit skeptical. > > In terms of cycles and looking at __rte_trace_point_register() (which > > calls malloc), the cost of calling multiple constructors instead of > > one is negligible. > > We will have a lot tracepoints latter, each one translates to the > constructor may not be a good > improvement. The scope is limited only to register function so IMO it > is okay to have split > just like rte_log. I don't see any reason why it has to be a different > than rte_log. What is similar to rte_log? There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of dynamic logtypes. > > One of the thought process is, we probably remove the constructor > scheme to all other with DPDK > and replace it with a more register scheme. In such a case, we can > skip calling the constructor all tother > when trace is disabled. Sorry, but I have a hard time understanding your point. Are you talking about application boot time? --=20 David Marchand