DPDK patches and discussions
 help / color / mirror / Atom feed
From: Sunil Kumar Kori <skori@marvell.com>
To: David Marchand <david.marchand@redhat.com>,
	Jerin Jacob <jerinjacobk@gmail.com>
Cc: Timothy McDaniel <timothy.mcdaniel@intel.com>,
	Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	dev <dev@dpdk.org>,
	Erik Gabriel Carrillo <erik.g.carrillo@intel.com>,
	Gage Eads <gage.eads@intel.com>,
	"Van Haaren Harry" <harry.van.haaren@intel.com>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 1/1] eal: increase TRACE CTF SIZE to recommended size
Date: Wed, 7 Oct 2020 10:07:17 +0000	[thread overview]
Message-ID: <CY4PR18MB1622EED1D78EA3648252FC8BB40A0@CY4PR18MB1622.namprd18.prod.outlook.com> (raw)
In-Reply-To: <CAJFAV8wPhja9LMH1OMW4A9ocxU3e_VqGVG+kth6pLhxqFJEGQw@mail.gmail.com>



Regards
Sunil Kumar Kori

>-----Original Message-----
>From: David Marchand <david.marchand@redhat.com>
>Sent: Wednesday, October 7, 2020 2:34 PM
>To: Jerin Jacob <jerinjacobk@gmail.com>
>Cc: Sunil Kumar Kori <skori@marvell.com>; Timothy McDaniel
><timothy.mcdaniel@intel.com>; Jerin Jacob Kollanukkaran
><jerinj@marvell.com>; dev <dev@dpdk.org>; Erik Gabriel Carrillo
><erik.g.carrillo@intel.com>; Gage Eads <gage.eads@intel.com>; Van Haaren
>Harry <harry.van.haaren@intel.com>
>Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 1/1] eal: increase TRACE CTF SIZE to
>recommended size
>
>On Tue, Oct 6, 2020 at 11:58 AM Jerin Jacob <jerinjacobk@gmail.com> wrote:
>>
>> On Tue, Oct 6, 2020 at 3:10 PM David Marchand
><david.marchand@redhat.com> wrote:
>> >
>> > On Tue, Oct 6, 2020 at 11:22 AM Sunil Kumar Kori <skori@marvell.com>
>wrote:
>> > > >On Mon, Oct 5, 2020 at 10:16 PM Timothy McDaniel
>> > > ><timothy.mcdaniel@intel.com> 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
>issue but in future similar issue can occur again.
>> > > So increasing this value by 64 bytes which actually equals to a cache line.
>That’s 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?
Changing it to dynamic allocation is difficult because if we do this then every time memory is to reallocated.
So IMO, It is okay to keep it static with enough size.
>
>
>>
>> >
>> > >
>> > > >
>> > > >
>> > > >> Fixes "CTF field is too long" error when running with trace enabled.
>> > > >
>> > > >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
>necessary.
>> >
>> > 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.
>
>
>
>--
>David Marchand


  reply	other threads:[~2020-10-07 10:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05 20:02 [dpdk-dev] " Timothy McDaniel
2020-10-06  8:45 ` David Marchand
2020-10-06  9:22   ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-10-06  9:39     ` David Marchand
2020-10-06  9:58       ` Jerin Jacob
2020-10-07  9:04         ` David Marchand
2020-10-07 10:07           ` Sunil Kumar Kori [this message]
2020-10-07 12:34             ` David Marchand
2020-10-08  7:33 ` [dpdk-dev] " David Marchand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CY4PR18MB1622EED1D78EA3648252FC8BB40A0@CY4PR18MB1622.namprd18.prod.outlook.com \
    --to=skori@marvell.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=erik.g.carrillo@intel.com \
    --cc=gage.eads@intel.com \
    --cc=harry.van.haaren@intel.com \
    --cc=jerinj@marvell.com \
    --cc=jerinjacobk@gmail.com \
    --cc=timothy.mcdaniel@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).