ea is that once one reads the bucket location,
the information about the all entries is coming together into the
processor cache, so we can take advantage of the information that is
already there.
While the second feature is good to have, the first one is the
feature we must have in our
hich entry to evict?
Fine. We'll rewrite the patch to do so.
Thank you for the feedback.
[ ]'s
Michel Machado
l try it. Thanks for the suggestion, Stephen.
[ ]'s
Michel Machado
se to
have a simple struct to enable applications to allocate a state as a
local variable and avoid a memory allocation.
[ ]'s
Michel Machado
e' so that it can be used in other iterator APIs too.
I like this suggestion. What about the name
"rte_hash_iterator_state" to make it specific to the hash table?
[ ]'s
Michel Machado
entries_init() enables one to easily add
variations of the init function to initialize the state (e.g. using a
key instead of a sig) and still use the exactly same iterator.
[ ]'s
Michel Machado
onflict_iterator_state:
int32_t
rte_hash_iterate_conflict_entries__with_hash(const struct rte_hash *h,
const void **key, void **data, hash_sig_t sig, uint32_t *next);
[ ]'s
Michel Machado
a review of the
interface since even rte_hash_iterate() may be affected. I still think
that the v2 we proposed is the best approach here because it isolates
the interface from the underlying algorithm.
[ ]'s
Michel Machado
the interfaces across APIs consistent. I
am fine with changing 'uint32_t *next' as long as we change 'rte_hash_iterate'
API as well.
We'll patch rte_hash_iterate() as well in v3.
[ ]'s
Michel Machado
d an extra malloc()/free().
Do you foresee that the upcoming new underlying algorithm of hash
tables will need to dynamically allocate iterator states?
[ ]'s
Michel Machado
t;
rte_hash_iterate;
rte_hash_lookup_bulk_data;
rte_hash_lookup_data;
@@ -53,3 +54,10 @@ DPDK_18.08 {
rte_hash_count;
} DPDK_16.07;
+
+EXPERIMENTAL {
+ global:
+
+ rte_hash_iterator_conflict_entries_init_with_hash;
+ rte_hash_iterate_conflict_entries;
+};
A blank line may be missing here.
Do you mean a blank line before "};"?
Thank you for the careful review.
[ ]'s
Michel Machado
protection.
We are going to add the reader lock protection. Thanks.
[ ]'s
Michel Machado
Hi Yipeng,
On 09/04/2018 04:57 PM, Wang, Yipeng1 wrote:
-Original Message-
From: Michel Machado [mailto:mic...@digirati.com.br]
Exposing the private fields would bind the interface with the
current implementation of the hash table. In the way we are proposing,
one should be able
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -64,6 +66,16 @@ struct rte_hash_parameters {
/** @internal A hash table structure. */ struct rte_hash;
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * @internal A hash table iterator state structure.
+ */
+struct rte_hash_iterator_state {
+ uint8_t space[64];
I would call this 'state'. 64 can be replaced by 'RTE_CACHE_LINE_SIZE'.
Okay.
[ ]'s
Michel Machado
I may change without prior notice.
+ *
+ * @internal A hash table iterator state structure.
+ */
+struct rte_hash_iterator_state {
+ uint8_t space[64];
I would call this 'state'. 64 can be replaced by 'RTE_CACHE_LINE_SIZE'.
Okay.
I think we should not replace 64 with RTE_CACHE_LINE_SIZE because
the ABI would change based on the architecture for which it's compiled.
[ ]'s
Michel Machado
h a couple entries, this cost
is a lot to add.
This memory allocation concern is not new. Function
rte_pktmbuf_read(), for example, let applications pass buffers, which
are often allocated in the execution stack, to avoid the malloc cost.
[ ]'s
Michel Machado
cause the ABI
would change based on the architecture for which it's compiled.
Ok. May be have a #define for 64?
Ok.
[ ]'s
Michel Machado
Since rte_mbuf_core.h requires generic/rte_atomic.h, shouldn't
rte_mbuf_core.h include generic/rte_atomic.h instead of forcing users of
rte_mbuf_core.h be aware of this dependency?
[ ]'s
Michel Machado
On 8/16/19 8:53 AM, Konstantin Ananyev wrote:
Get rid of duplicate defin
Acked-by: Michel Machado
[ ]'s
Michel Machado
On 8/16/19 8:53 AM, Konstantin Ananyev wrote:
Right now RTE_CACHE_ and IOVA definitions are located inside rte_memory.h
That might cause an unwanted inclusions of arch/os specific header files.
See [1] for particular problem example.
Probabl
Acked-by: Michel Machado
[ ]'s
Michel Machado
On 8/16/19 8:53 AM, Konstantin Ananyev wrote:
Right now inclusion of rte_mbuf.h header can cause inclusion of
some arch/os specific headers.
That prevents it to be included directly by some
non-DPDK (but related) entities: KNI, BPF programs
Acked-by: Michel Machado
[ ]'s
Michel Machado
On 9/27/19 9:50 AM, Konstantin Ananyev wrote:
Right now RTE_CACHE_ and IOVA definitions are located inside rte_memory.h
That might cause an unwanted inclusions of arch/os specific header files.
See [1] for particular problem example.
Probabl
Acked-by: Michel Machado
[ ]'s
Michel Machado
On 9/27/19 9:50 AM, Konstantin Ananyev wrote:
Right now inclusion of rte_mbuf.h header can cause inclusion of
some arch/os specific headers.
That prevents it to be included directly by some
non-DPDK (but related) entities: KNI, BPF programs
Acked-by: Michel Machado
[ ]'s
Michel Machado
On 9/27/19 9:50 AM, Konstantin Ananyev wrote:
Get rid of duplicate definitions for rte_mbuf and related macros.
Include rte_mbuf_core.h instead.
Signed-off-by: Konstantin Ananyev
---
examples/bpf/mbuf.h
On 10/14/20 7:57 PM, Honnappa Nagarahalli wrote:
On 13/10/2020 18:46, Michel Machado wrote:
On 10/13/20 11:41 AM, Medvedkin, Vladimir wrote:
Hi Michel,
Could you please describe a condition when LPM gets inconsistent?
As I can see if there is no free tbl8 it will return -ENOSPC
If the final choice is for not supporting a way to retrieve the
config information on the API, we'll look for a place to keep a copy
of the parameters in our code.
IMO, this is not a performance critical path and it is not a difficult solution
to
store these values in the application. My
/2020 15:58, Michel Machado wrote:
Hi Kevin,
We do need fields max_rules and number_tbl8s of struct rte_lpm, so
the removal would force us to have another patch to our local copy of
DPDK. We'd rather avoid this new local patch because we wish to
eventually be in sync with the stock
e the same need in
IPv6 and have a local patch to work around it (see
https://github.com/cjdoucette/dpdk/commit/3eaf124a781349b8ec8cd880db26a78115cb8c8f).
Thus, an IPv4 and IPv6 solution would be best.
PS: I've added Qiaobin Fu, another Gatekeeper maintainer, to this
disscussion.
[ ]&#
On 10/13/20 3:06 PM, Medvedkin, Vladimir wrote:
On 13/10/2020 18:46, Michel Machado wrote:
On 10/13/20 11:41 AM, Medvedkin, Vladimir wrote:
Hi Michel,
Could you please describe a condition when LPM gets inconsistent? As
I can see if there is no free tbl8 it will return -ENOSPC
28 matches
Mail list logo
