On 12/02/2015 10:26, HePeng wrote:
在 2015年11月30日，下午11:04，Maxim Uvarov <maxim.uva...@linaro.org> 写道：
On 11/30/2015 11:18, HePeng wrote:
Hi, Maxim,
How is everything going, about the ring?
Hello Peng,
We need to take a look it it's possible to rewrite your hash implementation to
odp queues api instead of odp ring.
That will allow to use hw queues accelerators for hash.
Maxim.
Hi Maxim,
The ring structure in cuckoo hash is just a buffer storing the “key”
address.
The hash table stores all the keys. In this implementation, it is the
hash table itself which maintains the memory of all the keys.
When add a new key, the hash table will firstly allocate an“index” of the key
using the ring, and when delete a key, the
hash table will recycle the “index” of the key into the ring. All in all, this
ring is like a free slots buffer storing all the free indexes.
In my opinion, (while I did not do this in hardware), the ring is not a
critical data structure in the scenario of hash table matching,
because only when table update happens, the hash table will need to use the
ring. Unless you use the hash table in a write-heavy
scenario, and this hardware queue can help you to ease the lock contention in
multi-core.
So my opinion is that, 1) yes, we can use the queue to replace the
ring, as long as the queue can be large enough to hold
all the hash entries. 2) But I do not think it is a critical optimization.
On the latest Tuesday call we have long discussion about that. And the
final agreement was that cuckoo has is needed but it needs to
use native odp interface. I.e. use of odp_queue instead of helper
odph_ring. The other deal is how that odp_queue is implemented.
If needed we can extend current implementation of odp_queue or add some
parameter to api. I.e. if needed we can put ring code
inside implementation and make external interface as odp_queue. In that
case platform which can work with queues in hardware
can accelerate it as other poll queues, other platform will have it in
software. You might seen that interface of the ring and
queue is about the same, i.e. it puts and gets patches to object. So it
might be not so hard to rewrite code to current queues api,
but in that form odp community will be happy to accept that patch. If
there will be some performance degradation, than we can work
on queues implementation and fix it.
So plan is:
1) have this code with queues api;
2) remove ring code completely from helper
3) move ring code inside linux-generic (I will reuse it for shm pktio ipc);
4) test performance of cuckoo hash
5) move it to odp hash API when it will be ready (to do that code should
not use other helper code, just native odp apis).
Best regards,
Maxim.
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
