All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Kozlyuk <dkozlyuk@oss.nvidia.com>
To: Aaron Conole <aconole@redhat.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Slava Ovsiienko <viacheslavo@oss.nvidia.com>,
	Anatoly Burakov <anatoly.burakov@intel.com>
Subject: Re: [dpdk-dev] [PATCH v6 3/3] app/test: add allocator performance autotest
Date: Tue, 12 Oct 2021 14:48:11 +0000	[thread overview]
Message-ID: <CH0PR12MB5091D28E24476FAFA5D000AFB9B69@CH0PR12MB5091.namprd12.prod.outlook.com> (raw)
In-Reply-To: <f7tr1cqe4d9.fsf@redhat.com>

> This isn't really a test, imho.  There are no assert()s.  How does a developer who
> tries to fix a bug in this area know what is acceptable?
> 
> Please switch the printf()s to RTE_LOG calls, and add some RTE_TEST_ASSERT
> calls to enforce some time range at the least.
> Otherwise this test will not really be checking the performance - just giving a
> report somewhere.

I just followed DPDK naming convention of test_xxx_perf.c / xxx_perf_autotest.
They all should really be called benchmarks.
They help developers to see how the code changes affect performance.
I don't understand how this "perf test" is not in line with existing ones
and where it should properly reside.

I'm not totally opposed to replacing printf() with RTE_LOG(), but all other test use printf().
The drawback of the change is inconsistency, what is the benefit?

> Also, I don't understand the way the memset test works here.  You do one large
> memset at the very beginning and then extrapolate the time it would take.  Does
> that hold any value or should we do a memset in each iteration and enforce a
> scaled time?

As explained above, we don't need to enforce anything, we want a report.
I've never seen a case with one NUMA node where memset() time would not scale linearly,
but benchmarks should be precise so I'll change it to memset()'ing the allocated area, thanks. 

  reply	other threads:[~2021-10-12 14:48 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05 12:49 [dpdk-dev] [PATCH 21.11 0/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-07-05 12:49 ` [dpdk-dev] [PATCH 21.11 1/3] eal/linux: make hugetlbfs analysis reusable Dmitry Kozlyuk
2021-07-05 12:49 ` [dpdk-dev] [PATCH 21.11 2/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-07-05 12:49 ` [dpdk-dev] [PATCH 21.11 3/3] app/test: add allocator performance autotest Dmitry Kozlyuk
2021-07-16 11:08 ` [dpdk-dev] [PATCH 21.11 v2 0/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-07-16 11:08   ` [dpdk-dev] [PATCH 21.11 v2 1/3] eal/linux: make hugetlbfs analysis reusable Dmitry Kozlyuk
2021-07-16 11:08   ` [dpdk-dev] [PATCH 21.11 v2 2/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-07-16 11:08   ` [dpdk-dev] [PATCH 21.11 v2 3/3] app/test: add allocator performance autotest Dmitry Kozlyuk
2021-08-09  9:45   ` [dpdk-dev] [PATCH 21.11 v2 0/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-08-30  8:21     ` Dmitry Kozlyuk
2021-09-14 10:34   ` [dpdk-dev] [PATCH v3 " Dmitry Kozlyuk
2021-09-14 10:34     ` [dpdk-dev] [PATCH v3 1/3] eal/linux: make hugetlbfs analysis reusable Dmitry Kozlyuk
2021-09-14 12:48       ` John Levon
2021-09-14 12:57         ` Dmitry Kozlyuk
2021-09-16 12:08       ` John Levon
2021-09-14 10:34     ` [dpdk-dev] [PATCH v3 2/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-09-14 10:34     ` [dpdk-dev] [PATCH v3 3/3] app/test: add allocator performance autotest Dmitry Kozlyuk
2021-09-20 12:52     ` [dpdk-dev] [PATCH v4 0/3] eal: add memory pre-allocation from existing files dkozlyuk
2021-09-20 12:53       ` [dpdk-dev] [PATCH v4 1/3] eal/linux: make hugetlbfs analysis reusable dkozlyuk
2021-09-20 12:53       ` [dpdk-dev] [PATCH v4 2/3] eal: add memory pre-allocation from existing files dkozlyuk
2021-09-20 12:53       ` [dpdk-dev] [PATCH v4 3/3] app/test: add allocator performance autotest dkozlyuk
2021-09-21  8:16       ` [dpdk-dev] [PATCH v5 0/3] eal: add memory pre-allocation from existing files dkozlyuk
2021-09-21  8:16         ` [dpdk-dev] [PATCH v5 1/3] eal/linux: make hugetlbfs analysis reusable dkozlyuk
2021-09-22 13:52           ` John Levon
2021-10-05 17:36           ` Thomas Monjalon
2021-10-08 15:33             ` John Levon
2021-10-08 15:50               ` Dmitry Kozlyuk
2021-09-21  8:16         ` [dpdk-dev] [PATCH v5 2/3] eal: add memory pre-allocation from existing files dkozlyuk
2021-09-21  8:16         ` [dpdk-dev] [PATCH v5 3/3] app/test: add allocator performance autotest dkozlyuk
2021-10-11  8:56         ` [dpdk-dev] [PATCH v6 0/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-10-11  8:56           ` [dpdk-dev] [PATCH v6 1/3] eal/linux: make hugetlbfs analysis reusable Dmitry Kozlyuk
2021-10-13  8:16             ` David Marchand
2021-10-13  9:21               ` Dmitry Kozlyuk
2021-10-11  8:56           ` [dpdk-dev] [PATCH v6 2/3] eal: add memory pre-allocation from existing files Dmitry Kozlyuk
2021-10-12 15:37             ` David Marchand
2021-10-12 15:55               ` Dmitry Kozlyuk
2021-10-12 17:32                 ` David Marchand
2021-10-12 21:09                   ` Dmitry Kozlyuk
2021-10-13 10:18                     ` David Marchand
2021-11-08 14:27                       ` Dmitry Kozlyuk
2021-11-08 17:45                         ` David Marchand
2021-10-11  8:56           ` [dpdk-dev] [PATCH v6 3/3] app/test: add allocator performance autotest Dmitry Kozlyuk
2021-10-12 13:53             ` Aaron Conole
2021-10-12 14:48               ` Dmitry Kozlyuk [this message]
2021-10-15 13:47                 ` Aaron Conole
2021-10-11 18:52           ` [dpdk-dev] [PATCH v6 0/3] eal: add memory pre-allocation from existing files Thomas Monjalon
2021-10-11 21:12             ` [dpdk-dev] [dpdk-ci] " Lincoln Lavoie
2021-10-12  6:54               ` Thomas Monjalon

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=CH0PR12MB5091D28E24476FAFA5D000AFB9B69@CH0PR12MB5091.namprd12.prod.outlook.com \
    --to=dkozlyuk@oss.nvidia.com \
    --cc=aconole@redhat.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=viacheslavo@oss.nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.