* [dpdk-users] DPDK hash table dynamic growth @ 2017-04-17 15:47 Fu, Qiaobin 2017-04-17 16:54 ` Stephen Hemminger 0 siblings, 1 reply; 6+ messages in thread From: Fu, Qiaobin @ 2017-04-17 15:47 UTC (permalink / raw) To: users Hello, Currently, I am using the hash library to handle network flows defined as source and destination IP addresses. I need to find a way to alleviate memory pressure when the table is full. However, after some research, I didn’t find any hints on the dynamic growth in the hash library. Could anyone point me some hints on this? Thanks. Best, Qiaobin ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-users] DPDK hash table dynamic growth 2017-04-17 15:47 [dpdk-users] DPDK hash table dynamic growth Fu, Qiaobin @ 2017-04-17 16:54 ` Stephen Hemminger 2017-04-17 17:30 ` Alex Kiselev 0 siblings, 1 reply; 6+ messages in thread From: Stephen Hemminger @ 2017-04-17 16:54 UTC (permalink / raw) To: Fu, Qiaobin; +Cc: users On Mon, 17 Apr 2017 15:47:59 +0000 "Fu, Qiaobin" <qiaobinf@bu.edu> wrote: > Hello, > > Currently, I am using the hash library to handle network flows defined as source and destination IP addresses. I need to find a way to alleviate memory pressure when the table is full. However, after some research, I didn’t find any hints on the dynamic growth in the hash library. Could anyone point me some hints on this? Thanks. > > Best, > Qiaobin If you need growing hash table, I recommend the lock-free hash table in the Linux userspace RCU library; rather than the more limited DPDK one. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-users] DPDK hash table dynamic growth 2017-04-17 16:54 ` Stephen Hemminger @ 2017-04-17 17:30 ` Alex Kiselev 2017-04-17 17:44 ` Fu, Qiaobin 0 siblings, 1 reply; 6+ messages in thread From: Alex Kiselev @ 2017-04-17 17:30 UTC (permalink / raw) To: Stephen Hemminger; +Cc: Fu, Qiaobin, users I would take a look at: 1) http://preshing.com/20160201/new-concurrent-hash-maps-for-cpp/ 2) https://github.com/efficient/libcuckoo 3) http://high-scale-lib.cvs.sourceforge.net/viewvc/high-scale-lib/high-scale-lib/org/cliffc/high_scale_lib/NonBlockingHashMap.java?view=markup https://www.youtube.com/watch?v=HJ-719EGIts https://www.youtube.com/watch?v=WYXgtXWejRM But there is a catch, none of them is written in C. 2017-04-17 19:54 GMT+03:00 Stephen Hemminger <stephen@networkplumber.org>: > On Mon, 17 Apr 2017 15:47:59 +0000 > "Fu, Qiaobin" <qiaobinf@bu.edu> wrote: > >> Hello, >> >> Currently, I am using the hash library to handle network flows defined as source and destination IP addresses. I need to find a way to alleviate memory pressure when the table is full. However, after some research, I didn’t find any hints on the dynamic growth in the hash library. Could anyone point me some hints on this? Thanks. >> >> Best, >> Qiaobin > > If you need growing hash table, I recommend the lock-free hash table in the Linux userspace RCU library; > rather than the more limited DPDK one. -- -- Kiselev Alexander ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-users] DPDK hash table dynamic growth 2017-04-17 17:30 ` Alex Kiselev @ 2017-04-17 17:44 ` Fu, Qiaobin 2017-04-17 20:06 ` Alex Kiselev 0 siblings, 1 reply; 6+ messages in thread From: Fu, Qiaobin @ 2017-04-17 17:44 UTC (permalink / raw) To: Alex Kiselev; +Cc: Stephen Hemminger, users Thanks @Alex and @Stephen for pointing these valuable materials to me! Maybe it’s better that I can clarify my scenarios more. Actually, we are using RSS (source + destination IP) to distribute packets, so we are maintaining one hash table per lcore (thread), and there is no need for synchronization issue in our case. If there are more solutions, please let me know. I will compare the solutions, and pick up the best suitable one. Best, Qiaobin On Apr 17, 2017, at 1:30 PM, Alex Kiselev <kiselev99@gmail.com<mailto:kiselev99@gmail.com>> wrote: I would take a look at: 1) http://preshing.com/20160201/new-concurrent-hash-maps-for-cpp/ 2) https://github.com/efficient/libcuckoo 3) http://high-scale-lib.cvs.sourceforge.net/viewvc/high-scale-lib/high-scale-lib/org/cliffc/high_scale_lib/NonBlockingHashMap.java?view=markup https://www.youtube.com/watch?v=HJ-719EGIts https://www.youtube.com/watch?v=WYXgtXWejRM But there is a catch, none of them is written in C. 2017-04-17 19:54 GMT+03:00 Stephen Hemminger <stephen@networkplumber.org>: On Mon, 17 Apr 2017 15:47:59 +0000 "Fu, Qiaobin" <qiaobinf@bu.edu> wrote: Hello, Currently, I am using the hash library to handle network flows defined as source and destination IP addresses. I need to find a way to alleviate memory pressure when the table is full. However, after some research, I didn’t find any hints on the dynamic growth in the hash library. Could anyone point me some hints on this? Thanks. Best, Qiaobin If you need growing hash table, I recommend the lock-free hash table in the Linux userspace RCU library; rather than the more limited DPDK one. -- -- Kiselev Alexander ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-users] DPDK hash table dynamic growth 2017-04-17 17:44 ` Fu, Qiaobin @ 2017-04-17 20:06 ` Alex Kiselev 2017-04-18 5:08 ` Shyam Shrivastav 0 siblings, 1 reply; 6+ messages in thread From: Alex Kiselev @ 2017-04-17 20:06 UTC (permalink / raw) To: Fu, Qiaobin; +Cc: Stephen Hemminger, users If you need only a single reader and a single writer solution you can use any existing hash table implementation and build on top of it your own resizable version. You can try a straightforward approach. Create a new bigger hash table when the old is full and just copy key/values into it. A new reader/lookup function should take into account that during resizing there can be more then one hash table and check all of them. And I wouldn't copy all keys at once, but instead I'd copy N keys at one iteration of the lcore main loop so the resizing process don't block other operations. пн, 17 апр. 2017 г. в 20:44, Fu, Qiaobin <qiaobinf@bu.edu>: > Thanks @Alex and @Stephen for pointing these valuable materials to me! > > Maybe it’s better that I can clarify my scenarios more. Actually, we are > using RSS (source + destination IP) to distribute packets, so we are > maintaining one hash table per lcore (thread), and there is no need for > synchronization issue in our case. If there are more solutions, please let > me know. I will compare the solutions, and pick up the best suitable one. > > Best, > Qiaobin > > On Apr 17, 2017, at 1:30 PM, Alex Kiselev <kiselev99@gmail.com> wrote: > > I would take a look at: > > 1) http://preshing.com/20160201/new-concurrent-hash-maps-for-cpp/ > 2) https://github.com/efficient/libcuckoo > 3) > > http://high-scale-lib.cvs.sourceforge.net/viewvc/high-scale-lib/high-scale-lib/org/cliffc/high_scale_lib/NonBlockingHashMap.java?view=markup > https://www.youtube.com/watch?v=HJ-719EGIts > https://www.youtube.com/watch?v=WYXgtXWejRM > > But there is a catch, none of them is written in C. > > 2017-04-17 19:54 GMT+03:00 Stephen Hemminger <stephen@networkplumber.org>: > > On Mon, 17 Apr 2017 15:47:59 +0000 > "Fu, Qiaobin" <qiaobinf@bu.edu> wrote: > > Hello, > > Currently, I am using the hash library to handle network flows defined as > source and destination IP addresses. I need to find a way to alleviate > memory pressure when the table is full. However, after some research, I > didn’t find any hints on the dynamic growth in the hash library. Could > anyone point me some hints on this? Thanks. > > Best, > Qiaobin > > > If you need growing hash table, I recommend the lock-free hash table in > the Linux userspace RCU library; > rather than the more limited DPDK one. > > > > > -- > -- > Kiselev Alexander > > > -- -- Kiselev Alexander ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-users] DPDK hash table dynamic growth 2017-04-17 20:06 ` Alex Kiselev @ 2017-04-18 5:08 ` Shyam Shrivastav 0 siblings, 0 replies; 6+ messages in thread From: Shyam Shrivastav @ 2017-04-18 5:08 UTC (permalink / raw) To: Alex Kiselev; +Cc: Fu, Qiaobin, Stephen Hemminger, users For theory on growing/shrinking hash tables useful MIT class https://www.youtube.com/watch?v=BRO7mVIFt08 On Tue, Apr 18, 2017 at 1:36 AM, Alex Kiselev <kiselev99@gmail.com> wrote: > If you need only a single reader and a single writer solution you can use > any existing hash table implementation and build on top of it your own > resizable version. You can try a straightforward approach. Create a new > bigger hash table when the old is full and just copy key/values into it. A > new reader/lookup function should take into account that during resizing > there can be more then one hash table and check all of them. And I wouldn't > copy all keys at once, but instead I'd copy N keys at one iteration of the > lcore main loop so the resizing process don't block other operations. > > пн, 17 апр. 2017 г. в 20:44, Fu, Qiaobin <qiaobinf@bu.edu>: > > > Thanks @Alex and @Stephen for pointing these valuable materials to me! > > > > Maybe it’s better that I can clarify my scenarios more. Actually, we are > > using RSS (source + destination IP) to distribute packets, so we are > > maintaining one hash table per lcore (thread), and there is no need for > > synchronization issue in our case. If there are more solutions, please > let > > me know. I will compare the solutions, and pick up the best suitable one. > > > > Best, > > Qiaobin > > > > On Apr 17, 2017, at 1:30 PM, Alex Kiselev <kiselev99@gmail.com> wrote: > > > > I would take a look at: > > > > 1) http://preshing.com/20160201/new-concurrent-hash-maps-for-cpp/ > > 2) https://github.com/efficient/libcuckoo > > 3) > > > > http://high-scale-lib.cvs.sourceforge.net/viewvc/high- > scale-lib/high-scale-lib/org/cliffc/high_scale_lib/ > NonBlockingHashMap.java?view=markup > > https://www.youtube.com/watch?v=HJ-719EGIts > > https://www.youtube.com/watch?v=WYXgtXWejRM > > > > But there is a catch, none of them is written in C. > > > > 2017-04-17 19:54 GMT+03:00 Stephen Hemminger <stephen@networkplumber.org > >: > > > > On Mon, 17 Apr 2017 15:47:59 +0000 > > "Fu, Qiaobin" <qiaobinf@bu.edu> wrote: > > > > Hello, > > > > Currently, I am using the hash library to handle network flows defined as > > source and destination IP addresses. I need to find a way to alleviate > > memory pressure when the table is full. However, after some research, I > > didn’t find any hints on the dynamic growth in the hash library. Could > > anyone point me some hints on this? Thanks. > > > > Best, > > Qiaobin > > > > > > If you need growing hash table, I recommend the lock-free hash table in > > the Linux userspace RCU library; > > rather than the more limited DPDK one. > > > > > > > > > > -- > > -- > > Kiselev Alexander > > > > > > -- > -- > Kiselev Alexander > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-04-18 5:08 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-17 15:47 [dpdk-users] DPDK hash table dynamic growth Fu, Qiaobin 2017-04-17 16:54 ` Stephen Hemminger 2017-04-17 17:30 ` Alex Kiselev 2017-04-17 17:44 ` Fu, Qiaobin 2017-04-17 20:06 ` Alex Kiselev 2017-04-18 5:08 ` Shyam Shrivastav
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).