Re: [vpp-dev] Timer expiry spikes in TW timer implementation
Thanks Dave!!!. I could see precision was indeed the problem. I think it is because the slots are missed due to below check in tw_timer_expire_timers_internal(...) when now time is behind the calculated next_run_time. * /* Shouldn't happen */* * if (PREDICT_FALSE (now < tw->next_run_time))* *return callback_vector_arg;* This leads to nticks loop - *for (i = 0; i < nticks; i++) *run for more than once in subsequent advance wheels ,internally calling registered callbacks nticks times based on conditions. I could not improve much on precision given the system constraints.I tried another approach in which return vector list from tw_timer_expire_timers_internal(...) is used instead of callback mechanism. I got result as expected i.e vec_len(expired_timer) as 1. I was expecting it to behave similarly and return vec_len as nticks times because internally it must be creating a vector, but that is not the case. Do you see any difference in approach callback mechanism and return vectors are implemented in tw_timer_expire_timers_XXX(...). Thanks, -Shaligram On Sun, 9 Dec 2018 at 05:32, Dave Barach (dbarach) wrote: > Probably due to the vpp process sitting in an epoll_pwait(). See > .../src/vlib/unix/input.c:linux_epoll_input_inline(...). > > > > The tw_timer code does its best, but if you don’t call the > tw_timer_expire_timers_XXX(...) method precisely it won’t yield the sort of > precision you’re looking for. > > > > If you configure the timer wheel at 100ms granularity you should expect > timers to pop within +-50 ms of when you expect them to pop, even if you > call the tw_timer_expire_timers_XXX method precisely. The code picks the > nearest slot, and if slots are 100ms wide, well, you get the idea. > > > > Dave > > > > *From:* vpp-dev@lists.fd.io *On Behalf Of * > shaligra...@gmail.com > *Sent:* Saturday, December 8, 2018 1:54 PM > *To:* vpp-dev@lists.fd.io > *Subject:* [vpp-dev] Timer expiry spikes in TW timer implementation > > > > Hi, > > I am trying to implement single 10sec precision periodic timer using TW. > Below is the config. using the reference from test_tw_timer.c (Really > helpful). > > tw_timer_wheel_init_2t_1w_2048sl with 0.1 sec granularity. > tw_timer_start_2t_1w_2048sl with 100 as ticks. > I have used the process node approach > with tw_timer_expire_timers_2t_1w_2048sl check at every 0.1 sec > using vlib_process_suspend(...). In the callback, timer is again started. > > My expectation was I would be receiving callback > to expired_timer_single_callback() at every 10 sec. > In actual, the callbacks are getting called at every 10sec apart. But > sometimes there are some unwanted callback at irregular frequency for the > same handle( i.e timer_id, pool_index). Note that this is the case either > for main_core or workers. For erroneous scenarios, time diff from previous > callback is inorder of ~ 0.1 ms(expected 10sec). > > Any pointers would of great help. > > Thanks, > -Shaligram > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11591): https://lists.fd.io/g/vpp-dev/message/11591 Mute This Topic: https://lists.fd.io/mt/28677304/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] calling VLIB_CONFIG_FUNCTION on same parameter block #vpp #vpp
Hi,
I want to share the parameter block across different plugins.
startup.conf has --
foo {
timeout 10
..
..
}
Plugin A - VLIB_CONFIG_FUNCTION(foo_fn_a, "foo")
Plugin B - VLIB_CONFIG_FUNCTION(foo_fn_b, "foo")
Is this possible ? I am not able to get the parameter block -foo shared. Any
guidance to achieve that please.
Thanks,
Shaligram
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12468): https://lists.fd.io/g/vpp-dev/message/12468
Mute This Topic: https://lists.fd.io/mt/30309100/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP and Non-VPP Communication #vpp
Yes, It can definitely be done via mmap the memory and marking the thread process shared. *fd=shm_open(...);* *mmap(NULL, shmSize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);* *...* *pthread_mutexattr_setpshared(, PTHREAD_PROCESS_SHARED);* *pthread_mutex_init(>lock, ); * *Regards,* *Shaligram Prakash* On Thu, 11 Apr 2019 at 17:13, wrote: > Can VPP and non-VPP Linux process share a single database (say shared > memory)? -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#12762): https://lists.fd.io/g/vpp-dev/message/12762 > Mute This Topic: https://lists.fd.io/mt/31029666/1192919 > Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=2729900 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [shaligra...@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13051): https://lists.fd.io/g/vpp-dev/message/13051 Mute This Topic: https://lists.fd.io/mt/31029666/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Bihash memory requirement #vpp_stability
At this moment, I don't see a leak, but will keep an eye out. I doubled hash_size for clib_bihash_init, the same run was able to sustain from ~30min to ~9hr. It crashed at same logic of split_and_rehash. source code is integrated one with other s/w components. Its gonna take some time to snip off relevant piece. It would be helpful if you point to a rough formula to derive the parameters for clib_bihash_init to support N number_of_expected_records. Thanks, Shaligram On Sat, 4 May 2019 at 01:13, Dave Barach (dbarach) wrote: > We routinely test to 200M (key,value) pairs, so scaling shouldn’t be an > issue. Are you absolutely sure that you’re not leaking (key, value) pairs? > It’s easy to imagine a test code bug which leaks memory [ask me how I know > that ]. > > > > Can you share your test code? > > > > HTH... Dave > > > > *From:* vpp-dev@lists.fd.io *On Behalf Of * > shaligram.prakash > *Sent:* Friday, May 3, 2019 2:48 PM > *To:* vpp-dev@lists.fd.io > *Subject:* [vpp-dev] Bihash memory requirement #vpp_stability > > > > Hello, > > Past days, I am trying to understand the VPP Bihash memory requirements & > bucket sizing. It would good if someone points to reference. > I have a capable system to scale up to 1 million connections. > > Started experiment with few hundreds of connections. There will be > thousands of add/deletes happening in the system, but caped to 100 at once. > max_connections = 100, workers =4. hash table is per worker. > I am using clib_bihash - 16_8 with initialized as nbuckets = > max_connection/BIHASH_KVP_PER_PAGE and *memory_size*=max_connection*1024. > (1024.. I considered 1K of memory per connection). > While experimenting, system is crashing at different places on couple of > runs with out_of_memory in ~30min run > >1. clib_bihash_add_del_16_8(hash >delete)->make_working_copy_16_8->clib_mem_alloc_aligned->OOM. >2. clib_bihash_add_del_16_8(hash add) -> >split_and_rehash_16_8(old_log2_pages=old_log2_pages@entry >=2, new_log2_pages=new_log2_pages@entry=3) ->value_alloc_16_8->OOM > > My queries: > >- Assuming nbuckets is set correctly as per Bihash cookbook, How is >the memory_size for hash deduced ? I think I have kept it low. Is there a >guideline to deduce it considering this needs to scaled up to millions. >- Can we minimize the hash collision resulting in rehash via nbuckets >or memory_size ? > > > Thanks, > Shaligram > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12926): https://lists.fd.io/g/vpp-dev/message/12926 Mute This Topic: https://lists.fd.io/mt/31486852/21656 Mute #vpp_stability: https://lists.fd.io/mk?hashtag=vpp_stability=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] crashing in vlib_frame_vector_byte_offset
Hi, I am facing a crash in the below code. It's 12 worker/1 core setup. we are using bit old VPP - 20.09. function under suspect is --- buffer_send_to_node() * vlib_frame_t *frame; * u32 *to_next; * * frame = vlib_get_frame_to_node (vm, node_index); * frame->n_vectors = 1; * to_next = vlib_frame_vector_args (frame); * * to_next[0] = buffer_index; * * vlib_put_frame_to_node (vm, node_index, frame ); * return; The crash is seen at #3 #4 vlib_frame_vector_byte_offset (scalar_size=) at /home/jenkins/vpp/build-root/install-vpp-native/vpp/include/vlib/node_funcs.h:259 #5 vlib_frame_vector_args (f=) at /home/jenkins/vpp/build-root/install-vpp-native/vpp/include/vlib/node_funcs.h:270 #6 buffer_send_to_node (vm=vm@entry=0x7fc406c323c0, node_index=332, buffer_index=buffer_index@entry=19753015) at /home/jenkins/test_buffer.c:1105 .. .. #11 0x7fc43bfbd702 in dispatch_node (last_time_stamp=61944131704815156, frame=0x7fc40695c500, dispatch_state=VLIB_NODE_STATE_POLLING, type=VLIB_NODE_TYPE_INTERNAL, node=0x7fc4107c0480, vm=0x7fc406c323c0) at /home/jenkins/vpp/src/vlib/main.c:1197 #12 dispatch_pending_node (vm=vm@entry=0x7fc406c323c0, pending_frame_index=pending_frame_index@entry=4, last_time_stamp=61944131704815156) at /home/jenkins/vpp/src/vlib/main.c:1355 Can an allocated frame at line 4 be freed via dispatch_pending_node in any conditions ? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22437): https://lists.fd.io/g/vpp-dev/message/22437 Mute This Topic: https://lists.fd.io/mt/96175435/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] crashing in vlib_frame_vector_byte_offset
On Tue, Jan 10, 2023 at 06:04 AM, Zhang, Fan wrote: > > vnet_hw_if_tx_frame_t [Typo - 12 worker/1 main core setup] This function is used to send packet at buffer_index to destination node_index[say ip4-lookup]. It works as expected except this case from production environment . what happens if we enqueue to many frames to the to-node frame & VLIB_FRAME_FREE_AFTER_DISPATCH is marked for those. Can there be a case of freeing up the frame during dispatch_node leading to this race. Looking for some pointers!! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22439): https://lists.fd.io/g/vpp-dev/message/22439 Mute This Topic: https://lists.fd.io/mt/96175435/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
