-----Original Message-----
From: Michel Machado <mic...@digirati.com.br>
Sent: Friday, August 24, 2018 7:34 AM
To: Wang, Yipeng1 <yipeng1.w...@intel.com>; Honnappa Nagarahalli
<honnappa.nagaraha...@arm.com>; Fu, Qiaobin <qiaob...@bu.edu>
Cc: dev@dpdk.org; Doucette, Cody, Joseph <douce...@bu.edu>; Wiles, Keith
<keith.wi...@intel.com>; Gobriel, Sameh <sameh.gobr...@intel.com>; Tai, Charlie
<charlie....@intel.com>; Stephen Hemminger <step...@networkplumber.org>; nd
<n...@arm.com>; Richardson, Bruce <bruce.richard...@intel.com>; De Lara Guarch,
Pablo <pablo.de.lara.gua...@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2] hash table: add an iterator over conflicting
entries
On 08/23/2018 08:33 PM, Wang, Yipeng1 wrote:
> I think with Honnappa suggested "uint32_t* next", we may need a little
> bit tricks to make it work with the extra linked list.
> The performance may not be optimal though comparing to your original approach.
> Is this important to your use case?
It is. We are developing a DDoS protection system, and have chosen DPDK
because it was the fastest framework in the evaluations we considered. We need
to find the conflicting entries when a critical flow table of our system is
overloaded due to an ongoing attack, so the more efficient we can evaluate the
merits of an incoming flow against the conflicting flows already in the table,
the higher the chances we find the flows that should be in the flow table.
We've compromised with Honnappa under the understanding that once the
underlying algorithm changes, there would be 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.
My only concern was to do with keeping the interfaces across APIs consistent. I
am fine with changing 'uint32_t *next' as long as we change 'rte_hash_iterate'
API as well.
[ ]'s
Michel Machado
