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
> <mailto: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
>> <mailto: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
>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> > <mailto: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 (#17139): https://lists.fd.io/g/vpp-dev/message/17139
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]
-=-=-=-=-=-=-=-=-=-=-=-
