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 3643BA04BA; Wed, 7 Oct 2020 11:04:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 195A61B3F3; Wed, 7 Oct 2020 11:04:17 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by dpdk.org (Postfix) with ESMTP id 232124C9D for ; Wed, 7 Oct 2020 11:04:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602061453; 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=OmRrtw8A7w1vjVq4AbPxSRRpBP7v7lfM9z8nPwkBJ78=; b=FGy58BbFd6RoBZRWe+FISMmYuJppNzqRMmzBAanoHxNuGDcFZb047OkF5KTtYp3aL6YXzG Xl6HCNrp0BJmBWQ+WBO3QR3yXhmxbefn0q+1uEssZaicAPTbj61lwbiyLiMNTJSzdAqO0/ AhVgcxK08MJULMy3yHxLwnHWlfGtILY= Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-30-VK1h2jN7NOqisvh89W2Ldg-1; Wed, 07 Oct 2020 05:04:12 -0400 X-MC-Unique: VK1h2jN7NOqisvh89W2Ldg-1 Received: by mail-il1-f200.google.com with SMTP id g1so1030510iln.15 for ; Wed, 07 Oct 2020 02:04:12 -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:content-transfer-encoding; bh=OmRrtw8A7w1vjVq4AbPxSRRpBP7v7lfM9z8nPwkBJ78=; b=jBjLUQGWWP3B+F6IeBhIT2Mans9/NUq6xWayXJg16gyfQzzgONfBa/i3SfdYMgDzdS akvVeKA1DbyeLfxCaWZlSeKEKKI82idBFWB1WQSO1jXs+S7xA71UaojMpCLIz0x4d/Sy iKo0SC5gnutobXGuAkq5Rtwy7d9oHaw46n1o5sgOQjlDP5zhpUmorsrUxGCnyMHOTxhv ekW8LbNNelKNhg/be4076Ak19i1zkUXAMwNKkPkOPBIPPAJmanmODeEYPTVaLvt9sxBj /oELUMXVesjp0N5wi0jwDOPvCotLWGoMB+AIt2ZBrtDULmAwIdmSMu5r98N+B4u5MOeV hXvQ== X-Gm-Message-State: AOAM5311rbWNkp58S2BuIKMLAzpb+Y/OuZeBs/5ujJOb32c6vb/jqrml zpCdYHK0hrWEXDZB2kVZSANRSnfKsni+8Apd+JAvD+HoJEnJK9SB84m+guihBWgMIJWgD2yA9GQ PimOtH16UOIvg24ygu+o= X-Received: by 2002:a6b:93d6:: with SMTP id v205mr1554165iod.188.1602061451380; Wed, 07 Oct 2020 02:04:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyHta9K36gaLM/Wc2XG9eSrubNgTkxXsGoQo85o82S+rjnvmwhGkzVezrWb6q16mTdP4Z+Jm8zXbxhAOQnGN8M= X-Received: by 2002:a6b:93d6:: with SMTP id v205mr1554151iod.188.1602061451203; Wed, 07 Oct 2020 02:04:11 -0700 (PDT) MIME-Version: 1.0 References: <1601928154-26051-1-git-send-email-timothy.mcdaniel@intel.com> In-Reply-To: From: David Marchand Date: Wed, 7 Oct 2020 11:04:00 +0200 Message-ID: To: Jerin Jacob Cc: Sunil Kumar Kori , Timothy McDaniel , Jerin Jacob Kollanukkaran , dev , Erik Gabriel Carrillo , Gage Eads , Van Haaren Harry Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com 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] [EXT] Re: [PATCH 1/1] eal: increase TRACE CTF SIZE to recommended size 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 Tue, Oct 6, 2020 at 11:58 AM Jerin Jacob wrote: > > On Tue, Oct 6, 2020 at 3:10 PM David Marchand = wrote: > > > > On Tue, Oct 6, 2020 at 11:22 AM Sunil Kumar Kori wr= ote: > > > >On Mon, Oct 5, 2020 at 10:16 PM Timothy McDaniel > > > > wrote: > > > >> > > > >> Increase TRACE_CTF_FIELD_SIZE to 448, the recommended size. > > > > > > > >Repeating the same sentence in the title and the commitlog does not = give > > > >much info. > > > > > > > >Plus, what is this "recommendation"? > > > When analyzed this issue, only one more byte was needed to fix this i= ssue but in future similar issue can occur again. > > > So increasing this value by 64 bytes which actually equals to a cache= line. That=E2=80=99s why we have suggested this size. > > > > 384 is aligned to both 64 and 128 bytes cache lines. > > 448 is only aligned to 64 bytes. > > > > Should we care about 128 bytes cache lines systems? > > it is on a slow path. 448 is OK. Ah yes, this is for the ctf description. Could it be changed to rely on dynamic allocations and we simply remove this limit? > > > > > > > > > > > > > > > > > >> Fixes "CTF field is too long" error when running with trace enable= d. > > > > > > > >Ok, you hit this limit, but it would help to get some context here. > > > >Looking at this patch in the future, we won't know why it was necess= ary. > > > > How about following commitlog: > > > > """ > > trace: increase trace point buffer size > > > > The current buffer size is not big enough to accomodate traces for new > > additions in the eventdev subsystem. > > Increase this buffer size by XXX for reason YYY. > > """ > > Looks good to me. Well in this case, there is no actual reason. The increased value is deemed "enough for now", unless we change this to dynamic allocations. --=20 David Marchand