Hi Florin,
I tried vppcom_epoll_wait() on 2 different servers by using a simple
application ( with only 1 worker thread) . But, still vppcom_epoll_wait()
is not being timed out if I do not use use-mq-eventfd .
Here are the server details -
server 1 - Red hat 7.5 , vpp release - 20.01
server 2 - Centos 8.1 , vpp release - 20.05
thanks,
-Raj
On Tue, Aug 4, 2020 at 10:24 AM Florin Coras <fcoras.li...@gmail.com> wrote:
> Hi Raj,
>
> Interesting. For some reason, the message queue’s underlying
> pthread_cond_timedwait does not work in your setup. Not sure what to make
> of that, unless maybe you’re trying to epoll wait from multiple threads
> that share the same message queue. That is not supported since each thread
> must have its own message queue, i.e., all threads that call epoll should
> be registered as workers. Alternatively, some form of locking or vls,
> instead of vcl, should be used.
>
> The downside to switching the message queue to eventfd notifications,
> instead of mutext/condvar, is that waits are inefficient, i.e., they act
> pretty much like spinlocks. Do keep that in mind.
>
> Regards,
> Florin
>
> On Aug 4, 2020, at 6:37 AM, Raj Kumar <raj.gauta...@gmail.com> wrote:
>
> Hi Florin,
> After adding use-mq-eventfd in VCL configuration, it is working as
> expected.
> Thanks! for your help.
>
> vcl {
> rx-fifo-size 4000000
> tx-fifo-size 4000000
> app-scope-local
> app-scope-global
> use-mq-eventfd
> api-socket-name /tmp/vpp-api.sock
> }
>
> thanks,
> -Raj
>
> On Tue, Aug 4, 2020 at 12:08 AM Florin Coras <fcoras.li...@gmail.com>
> wrote:
>
>> Hi Raj,
>>
>> Glad to hear that issue is solved. What vcl config are you running? Did
>> you configure use-mq-eventd?
>>
>> Regards,
>> Florin
>>
>> On Aug 3, 2020, at 8:33 PM, Raj Kumar <raj.gauta...@gmail.com> wrote:
>>
>> Hi Florin,
>> This issue is resolved now. In my application, on receiving the kill
>> signal main thread was sending phread_cancel() to the child thread
>> because of that child thread was not exiting gracefully.
>> I have one question; it seems that vppcom_epoll_wait(epfd, rcvEvents,
>> MAX_RETURN_EVENTS, 60000.0) is not returning after timed out if the timeout
>> value is a non zero value. It timed out only if the timeout value is 0.
>> The issue that I am facing is that if there is no traffic at all (
>> receiver is just listening on the connections ) then the worker thread is
>> not exiting as it is blocked by vppcom_epoll_wait().
>>
>> Thanks,
>> -Raj
>>
>>
>>
>> On Wed, Jul 29, 2020 at 11:23 PM Florin Coras <fcoras.li...@gmail.com>
>> wrote:
>>
>>> Hi Raj,
>>>
>>> In that case it should work. Just from the trace lower it’s hard to
>>> figure out what exactly happened. Also, keep in mind that vcl is not thread
>>> safe, so make sure you’re not trying to share sessions or allow two workers
>>> to interact with the message queue(s) at the same time.
>>>
>>> Regards,
>>> Florin
>>>
>>> On Jul 29, 2020, at 8:17 PM, Raj Kumar <raj.gauta...@gmail.com> wrote:
>>>
>>> Hi Florin,
>>> I am using kill <pid> to stop the application. But , the application has
>>> a kill signal handler and after receiving the signal it is exiting
>>> gracefully.
>>> About vppcom_app_exit, I think this function is registered with atexit()
>>> inside vppcom_app_create() so it should call when the application exits.
>>> Even, I also tried this vppcom_app_exit() explicitly before exiting the
>>> application but still I am seeing the same issue.
>>>
>>> My application is a multithreaded application. Can you please suggest
>>> some cleanup functions ( vppcom functions) that I should call before
>>> exiting a thread and the main application for a proper cleanup.
>>> I also tried vppcom_app_destroy() before exiting the main application
>>> but still I am seeing the same issue.
>>>
>>> thanks,
>>> -Raj
>>>
>>> On Wed, Jul 29, 2020 at 5:34 PM Florin Coras <fcoras.li...@gmail.com>
>>> wrote:
>>>
>>>> Hi Raj,
>>>>
>>>> Does stopping include a call to vppcom_app_exit or killing the
>>>> applications? If the latter, the apps might be killed with some
>>>> mutexes/spinlocks held. For now, we only support the former.
>>>>
>>>> Regards,
>>>> Florin
>>>>
>>>> > On Jul 29, 2020, at 1:49 PM, Raj Kumar <raj.gauta...@gmail.com>
>>>> wrote:
>>>> >
>>>> > Hi,
>>>> > In my UDP application , I am using VPP host stack to receive packets
>>>> and memIf to transmit packets. There are a total 6 application connected to
>>>> VPP.
>>>> > if I stop the application(s) then VPP is crashing. In vpp
>>>> configuration , 4 worker threads are configured. If there is no worker
>>>> thread configured then I do not see this crash.
>>>> > Here is the VPP task trace -
>>>> > (gdb) bt
>>>> > #0 0x00007ffff51818df in raise () from /lib64/libc.so.6
>>>> > #1 0x00007ffff516bcf5 in abort () from /lib64/libc.so.6
>>>> > #2 0x000055555555c123 in os_panic () at
>>>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vpp/vnet/main.c:366
>>>> > #3 0x00007ffff6b466bb in vlib_worker_thread_barrier_sync_int
>>>> (vm=0x7ffff6d78200 <vlib_global_main>, func_name=<optimized out>)
>>>> > at
>>>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlib/threads.c:1529
>>>> > #4 0x00007ffff7bc5ef0 in vl_msg_api_handler_with_vm_node
>>>> > (am=am@entry=0x7ffff7dd2ea0
>>>> <api_global_main>,
>>>> > vlib_rp=vlib_rp@entry=0x7fee7c001000, the_msg=0x7fee7c02bbd8,
>>>> vm=vm@entry=0x7ffff6d78200 <vlib_global_main>,
>>>> > node=node@entry=0x7fffb6295000, is_private=is_private@entry=1
>>>> '\001')
>>>> > at
>>>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlibapi/api_shared.c:596
>>>> > #5 0x00007ffff7bb000f in void_mem_api_handle_msg_i (is_private=1
>>>> '\001', node=0x7fffb6295000, vm=0x7ffff6d78200 <vlib_global_main>,
>>>> > vlib_rp=0x7fee7c001000, am=0x7ffff7dd2ea0 <api_global_main>)
>>>> > at
>>>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlibmemory/memory_api.c:698
>>>> > #6 vl_mem_api_handle_msg_private (vm=vm@entry=0x7ffff6d78200
>>>> <vlib_global_main>, node=node@entry=0x7fffb6295000,
>>>> reg_index=<optimized out>)
>>>> > at
>>>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlibmemory/memory_api.c:762
>>>> > #7 0x00007ffff7bbe346 in vl_api_clnt_process (vm=<optimized out>,
>>>> node=0x7fffb6295000, f=<optimized out>)
>>>> > at
>>>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlibmemory/vlib_api.c:370
>>>> > #8 0x00007ffff6b161d6 in vlib_process_bootstrap (_a=<optimized out>)
>>>> > at
>>>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vlib/main.c:1502
>>>> > #9 0x00007ffff602ac0c in clib_calljmp () from
>>>> /lib64/libvppinfra.so.20.05
>>>> > #10 0x00007fffb5e93dd0 in ?? ()
>>>> > #11 0x00007ffff6b19821 in dispatch_process (vm=0x7ffff6d78200
>>>> <vlib_global_main>, p=0x7fffb6295000, last_time_stamp=15931923011231136,
>>>> > f=0x0) at
>>>> /usr/src/debug/vpp-20.05-9~g0bf9c294c_dirty.x86_64/src/vppinfra/types.h:133
>>>> > #12 0x7f0f660000009024 in ?? ()
>>>> >
>>>> >
>>>> > Thanks,
>>>> > -Raj
>>>> >
>>>>
>>>>
>>>
>>>
>>>
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17140): https://lists.fd.io/g/vpp-dev/message/17140
Mute This Topic: https://lists.fd.io/mt/75873900/21656
Mute #vpp-hoststack:
https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-hoststack
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
