DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wang, Yipeng1" <yipeng1.wang@intel.com>
To: Dharmik Thakkar <dharmik.thakkar@arm.com>,
	"Gobriel, Sameh" <sameh.gobriel@intel.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 2/2] test/hash: lock-free rw concurrency test ext bkt
Date: Mon, 1 Apr 2019 18:55:47 +0000	[thread overview]
Message-ID: <D2C4A16CA39F7F4E8E384D204491D7A673E48A51@ORSMSX104.amr.corp.intel.com> (raw)
In-Reply-To: <20190325210838.2853-3-dharmik.thakkar@arm.com>

A little bit improvement on commit-message maybe needed.

>-----Original Message-----
>From: Dharmik Thakkar [mailto:dharmik.thakkar@arm.com]
>Sent: Monday, March 25, 2019 2:09 PM
>To: Wang, Yipeng1 <yipeng1.wang@intel.com>; Gobriel, Sameh <sameh.gobriel@intel.com>; Richardson, Bruce
><bruce.richardson@intel.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>Cc: dev@dpdk.org; Dharmik Thakkar <dharmik.thakkar@arm.com>
>Subject: [PATCH v2 2/2] test/hash: lock-free rw concurrency test ext bkt
[Wang, Yipeng] *for* ext bucket
>
>Add unit test to check for hash lookup and bulk-lookup perf.
[Wang, Yipeng] for extendable bucket feature.
>Test with lock-free enabled and with lock-free disabled.
[Wang, Yipeng] It is tested with both lock-free enabled and disabled case.
>
>Test include:
>
>- hash lookup on keys in ext bkt,
>hash delete causing key-shifts of keys from ext bkt to secondary bkt
[Wang, Yipeng] 
Two test scenarios right? A bit of formatting..
Tests include:
- hash lookup on keys in ext bucket.
- hash delete causing key-shifts of keys from ext bucket to secondary bucket.

>
>Suggested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
>Signed-off-by: Dharmik Thakkar <dharmik.thakkar@arm.com>
>---
>+/*
>+ * Test lookup perf:
>+ * Reader(s) lookup keys present in the extendable bkt.
>+ */
>+static int
>+test_hash_add_ks_lookup_hit_extbkt(struct rwc_perf *rwc_perf_results,
>+				int rwc_lf, int htm, int ext_bkt)
>+{
>+	unsigned int n, m;
>+	uint64_t i;
>+	int use_jhash = 0;
>+	uint8_t write_type;
>+	uint8_t read_type = READ_PASS_KEY_SHIFTS_EXTBKT;
>+
>+	rte_atomic64_init(&greads);
>+	rte_atomic64_init(&gread_cycles);
>+
>+	if (init_params(rwc_lf, use_jhash, htm, ext_bkt) != 0)
>+		goto err;
>+	printf("\nTest: Hash add - key-shifts, read - hit (ext_bkt)\n");
>+	for (m = 0; m < 2; m++) {
>+		if (m == 1) {
>+			printf("\n** With bulk-lookup **\n");
>+			read_type |= BULK_LOOKUP;
>+		}
>+		for (n = 0; n < NUM_TEST; n++) {
>+			unsigned int tot_lcore = rte_lcore_count();
>+			if (tot_lcore < rwc_core_cnt[n] + 1)
>+				goto finish;
>+
>+			printf("\nNumber of readers: %u\n", rwc_core_cnt[n]);
>+
>+			rte_atomic64_clear(&greads);
>+			rte_atomic64_clear(&gread_cycles);
>+
>+			rte_hash_reset(tbl_rwc_test_param.h);
>+			write_type = WRITE_NO_KEY_SHIFT;
>+			if (write_keys(write_type) < 0)
>+				goto err;
>+			write_type = WRITE_KEY_SHIFT;
>+			if (write_keys(write_type) < 0)
>+				goto err;
>+			writer_done = 0;
>+			for (i = 1; i <= rwc_core_cnt[n]; i++)
>+				rte_eal_remote_launch(test_rwc_reader,
>+						(void *)(uintptr_t)read_type,
>+							enabled_core_ids[i]);
>+			for (i = 0; i < tbl_rwc_test_param.count_keys_ks_extbkt;
>+			     i++) {
>+				if (rte_hash_del_key(tbl_rwc_test_param.h,
>+					tbl_rwc_test_param.keys_ks_extbkt + i)
>+							< 0) {
>+					printf("Delete Failed: %u\n",
>+					tbl_rwc_test_param.keys_ks_extbkt[i]);
>+					goto err;
>+				}
>+			}
>+			writer_done = 1;
>+			rte_eal_mp_wait_lcore();
[Wang, Yipeng] Not requirement for this perf patch, but is it better to read the shifted key again
Just to verify the logic? If not difficult please add.

  parent reply	other threads:[~2019-04-01 18:55 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20 22:35 [dpdk-dev] [PATCH 0/2] hash: add lock free support for " Dharmik Thakkar
2019-03-20 22:35 ` Dharmik Thakkar
2019-03-20 22:35 ` [dpdk-dev] [PATCH 1/2] hash: add lock free support for extendable bucket Dharmik Thakkar
2019-03-20 22:35   ` Dharmik Thakkar
2019-03-22 23:48   ` Wang, Yipeng1
2019-03-22 23:48     ` Wang, Yipeng1
2019-03-25 20:10     ` Dharmik Thakkar
2019-03-25 20:10       ` Dharmik Thakkar
2019-03-20 22:35 ` [dpdk-dev] [PATCH 2/2] test/hash: lock-free rw concurrency test ext bkt Dharmik Thakkar
2019-03-20 22:35   ` Dharmik Thakkar
2019-03-25 21:08 ` [dpdk-dev] [PATCH v2 0/2] hash: add lock free support for " Dharmik Thakkar
2019-03-25 21:08   ` Dharmik Thakkar
2019-03-25 21:08   ` [dpdk-dev] [PATCH v2 1/2] hash: add lock free support for extendable bucket Dharmik Thakkar
2019-03-25 21:08     ` Dharmik Thakkar
2019-04-01 18:20     ` Wang, Yipeng1
2019-04-01 18:20       ` Wang, Yipeng1
2019-04-01 20:16       ` Dharmik Thakkar
2019-04-01 20:16         ` Dharmik Thakkar
2019-03-25 21:08   ` [dpdk-dev] [PATCH v2 2/2] test/hash: lock-free rw concurrency test ext bkt Dharmik Thakkar
2019-03-25 21:08     ` Dharmik Thakkar
2019-04-01 18:55     ` Wang, Yipeng1 [this message]
2019-04-01 18:55       ` Wang, Yipeng1
2019-04-01 20:06       ` Dharmik Thakkar
2019-04-01 20:06         ` Dharmik Thakkar
2019-04-01 22:18   ` [dpdk-dev] [PATCH v3 0/2] hash: add lock free support for " Dharmik Thakkar
2019-04-01 22:18     ` Dharmik Thakkar
2019-04-01 22:18     ` [dpdk-dev] [PATCH v3 1/2] hash: add lock free support for extendable bucket Dharmik Thakkar
2019-04-01 22:18       ` Dharmik Thakkar
2019-04-01 22:18     ` [dpdk-dev] [PATCH v3 2/2] test/hash: lock-free rw concurrency test ext bkt Dharmik Thakkar
2019-04-01 22:18       ` Dharmik Thakkar
2019-04-01 22:52       ` Wang, Yipeng1
2019-04-01 22:52         ` Wang, Yipeng1
2019-04-01 23:08     ` [dpdk-dev] [PATCH v4 0/2] hash: add lock free support for " Dharmik Thakkar
2019-04-01 23:08       ` Dharmik Thakkar
2019-04-01 23:08       ` [dpdk-dev] [PATCH v4 1/2] hash: add lock free support for extendable bucket Dharmik Thakkar
2019-04-01 23:08         ` Dharmik Thakkar
2019-04-01 23:08       ` [dpdk-dev] [PATCH v4 2/2] test/hash: lock-free rw concurrency test ext bkt Dharmik Thakkar
2019-04-01 23:08         ` Dharmik Thakkar
2019-04-02  0:57         ` Thomas Monjalon
2019-04-02  0:57           ` Thomas Monjalon
2019-04-02 19:44           ` Dharmik Thakkar
2019-04-02 19:44             ` Dharmik Thakkar
2019-04-02 19:44       ` [dpdk-dev] [PATCH v5 0/2] hash: add lock free support for " Dharmik Thakkar
2019-04-02 19:44         ` Dharmik Thakkar
2019-04-02 19:44         ` [dpdk-dev] [PATCH v5 1/2] hash: add lock free support for extendable bucket Dharmik Thakkar
2019-04-02 19:44           ` Dharmik Thakkar
2019-04-02 19:44         ` [dpdk-dev] [PATCH v5 2/2] test/hash: lock-free rw concurrency test ext bkt Dharmik Thakkar
2019-04-02 19:44           ` Dharmik Thakkar
2019-04-03 18:56         ` [dpdk-dev] [PATCH v5 0/2] hash: add lock free support for " Thomas Monjalon
2019-04-03 18:56           ` 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=D2C4A16CA39F7F4E8E384D204491D7A673E48A51@ORSMSX104.amr.corp.intel.com \
    --to=yipeng1.wang@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=dharmik.thakkar@arm.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=sameh.gobriel@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).