DPDK patches and discussions
 help / color / mirror / Atom feed
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Wang, Yipeng1" <yipeng1.wang@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>,
	Dharmik Thakkar <Dharmik.Thakkar@arm.com>,
	 "Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>,
	nd <nd@arm.com>, "Gobriel, Sameh" <sameh.gobriel@intel.com>
Subject: Re: [dpdk-dev] [PATCH v3 2/7] hash: support do not recycle on delete
Date: Tue, 16 Oct 2018 01:25:30 +0000	[thread overview]
Message-ID: <AM6PR08MB36721C77E95580B797CA853F98FE0@AM6PR08MB3672.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <D2C4A16CA39F7F4E8E384D204491D7A6614EFB44@FMSMSX151.amr.corp.intel.com>


> >
> >rte_hash_lookup_xxx APIs return the index of the element in the key
> >store. Application(reader) can use that index to reference other data
> >structures in its scope. Because of this, the index should not be
> >recycled till the application completes using the index.
> >RTE_HASH_EXTRA_FLAGS_RECYCLE_ON_DEL is introduced to support this.
> >When this flag is enabled rte_hash_del_xxx APIs do not free the
> >key-store index/internal memory associated with the deleted entry. The
> >new API rte_hash_free_key_with_position should be called to free the
> >key-store index/internal memory after calling rte_hash_del_xxx APIs.
> >
> > 	uint8_t ext_table_support;     /**< Enable extendable bucket table */
> >+	uint8_t recycle_on_del;
> >+	/**< If internal memory/key-store entry should be
> >+	 * freed on calling the rte_hash_del_xxx APIs.
> >+	 * If this is set, rte_hash_free_key_with_position must be
> [Wang, Yipeng] If this is *not* set?
Agree.

> 
> >+/** Flag to disable freeing of internal memory/indices on hash delete.
> >+ * Refer to rte_hash_del_xxx APIs for more details.
> >+ */
> >+#define RTE_HASH_EXTRA_FLAGS_RECYCLE_ON_DEL 0x10
> >+
> [Wang, Yipeng] Maybe call it FREE_AFTER_DEL or NO_FREE_ON_DEL?
> Recycle_on_del Sounds like we do the recycle at the delete time, which is
> opposite to the meaning.
> 
> Change *recycle* to *free* to be consistent with the function API name.
> I guess I suggested to use *recycle* at beginning, but as a second thought, I
> think *free* is more user friendly than recycle. Recycle makes more sense to
> developers.
> And you already use *free* for the function name.
Will change it to 'NO_FREE_ON_DEL'. It will be disabled by default. Will be enabled by default for RW-Concurrency-LF.

> 
> > /**
> >  * The type of hash value of a key.
> >  * It should be a value of at least 32bit with fully random pattern.
> >@@ -236,6 +243,10 @@ rte_hash_add_key_with_hash(const struct rte_hash
> >*h, const void *key, hash_sig_t
> >  * and should only be called from one thread by default.
> >  * Thread safety can be enabled by setting flag during
> >  * table creation.
> >+ * If RTE_HASH_EXTRA_FLAGS_RECYCLE_ON_DEL is enabled,
> >+ * the hash library's internal memory/index will not be freed by this
> >+ * API. rte_hash_free_key_with_position API must be called
> >+ additionally
> >+ * to free the internal memory/index associated with the key.
> [Wang, Yipeng] Maybe more explicit on the use case for this flag: This
> behavior is useful for multi-threading applications which may still have
> threads referencing the position after deletion (or other words of which you
> think more clear).
I don't think we should address any particular use case here as there can be many which we might not have imagined. IMO, it is better to do this in documentation where we can talk about use cases (that we know and want to address) and how to use these APIs.

> 
> Otherwise
> Reviewed-by: Yipeng Wang <yipeng1.wang@intel.com>

  reply	other threads:[~2018-10-16  1:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-12  6:31 [dpdk-dev] [PATCH v3 0/7] Address reader-writer concurrency in rte_hash Honnappa Nagarahalli
2018-10-12  6:31 ` [dpdk-dev] [PATCH v3 1/7] hash: separate multi-writer from rw-concurrency Honnappa Nagarahalli
2018-10-13  1:02   ` Wang, Yipeng1
2018-10-15 20:15     ` Honnappa Nagarahalli
2018-10-12  6:31 ` [dpdk-dev] [PATCH v3 2/7] hash: support do not recycle on delete Honnappa Nagarahalli
2018-10-13  1:17   ` Wang, Yipeng1
2018-10-16  1:25     ` Honnappa Nagarahalli [this message]
2018-10-12  6:31 ` [dpdk-dev] [PATCH v3 3/7] hash: correct key store element alignment Honnappa Nagarahalli
2018-10-13  1:20   ` Wang, Yipeng1
2018-10-16 23:26     ` Honnappa Nagarahalli
2018-10-12  6:31 ` [dpdk-dev] [PATCH v3 4/7] hash: add memory ordering to avoid race conditions Honnappa Nagarahalli
2018-10-13  1:56   ` Wang, Yipeng1
2018-10-16 23:28     ` Honnappa Nagarahalli
2018-10-12  6:31 ` [dpdk-dev] [PATCH v3 5/7] hash: fix rw concurrency while moving keys Honnappa Nagarahalli
2018-10-13  2:07   ` Wang, Yipeng1
2018-10-12  6:31 ` [dpdk-dev] [PATCH v3 6/7] hash: enable lock-free reader-writer concurrency Honnappa Nagarahalli
2018-10-13  2:32   ` Wang, Yipeng1
2018-10-17 13:54     ` Honnappa Nagarahalli
2018-10-12  6:31 ` [dpdk-dev] [PATCH v3 7/7] test/hash: read-write lock-free concurrency test Honnappa Nagarahalli
2018-10-13  2:52   ` Wang, Yipeng1

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=AM6PR08MB36721C77E95580B797CA853F98FE0@AM6PR08MB3672.eurprd08.prod.outlook.com \
    --to=honnappa.nagarahalli@arm.com \
    --cc=Dharmik.Thakkar@arm.com \
    --cc=Gavin.Hu@arm.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=nd@arm.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=sameh.gobriel@intel.com \
    --cc=yipeng1.wang@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).