> 在 2015年12月2日，下午5:30，Maxim Uvarov <maxim.uva...@linaro.org> 写道： > > 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). Glad to see this. I will begin to shape the code using odp_queue API.
> > Best regards, > Maxim.
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
