Hello Florin, > > Agreed that it looks like vl_api_clnt_process sleeps, probably because it > hit a queue size of 0, but memclnt_queue_callback or the timeout, albeit > 20s is a lot, should wake it up.
It doesn't look like vl_api_clnt_process would have woken up later. Firstly, because QUEUE_SIGNAL_EVENT was already signaled and vm->queue_signal_pending was set. And memclnt_queue_callback() is only triggered if vm->queue_signal_pending is unset. Thus, no new calls of memclnt_queue_callback() would have happened while vm->queue_signal_pending was set. Secondly, the timer id that vl_api_clnt_process holds belongs to another process node. Even if the timer was valid, the other process node would have been triggered by it. > > So, given that QUEUE_SIGNAL_EVENT is set, the only thing that comes to > mind is that maybe somehow vlib_process_signal_event context gets > corrupted. Could you run a debug image and see if anything asserts? Is > vlib_process_signal_event called by chance from a worker? It's problematic to run a debug version of VPP on the affected instances. There are no signs of vlib_process_signal_event() being called from a worker thread. If look at memclnt_queue_callback(), it is called only in the main thread. Regards, Alexander
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22508): https://lists.fd.io/g/vpp-dev/message/22508 Mute This Topic: https://lists.fd.io/mt/96500275/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] -=-=-=-=-=-=-=-=-=-=-=-
