Yes, there are 2 options when handoff queue is full, drop or wait. Wait gives you nice back-pressure mechanism as it will slow down input worker, but it will not work in case when A handoffs to B and B handoffs to A.
-- Damjan On 23 Apr 2018, at 10:50, Ole Troan <otr...@employees.org<mailto:otr...@employees.org>> wrote: Kingwei, Yes, it's possible to dead lock in this case. We had a similar issue with the NAT implementation. While testing I think we ended up dropping when the queue was full. Best regards, Ole On 23 Apr 2018, at 10:33, Kingwel Xie <kingwel....@ericsson.com<mailto:kingwel....@ericsson.com>> wrote: Hi Damjan and all, We are currently thinking of how to utilize the handoff mechanism to serve our application logic – to run a packet re-ordering and re-transmit queue in the same worker context to avoid any lock between threads. We come across with a question when looking into the implementation of handoff. Hope you can figure it out for us. In vlib_get_worker_handoff_queue_elt -> vlib_get_frame_queue_elt : /* Wait until a ring slot is available */ while (new_tail >= fq->head_hint + fq->nelts) vlib_worker_thread_barrier_check (); We understand that the worker has wait for the any available slot from the other worker before putting buffer into it. Then the question is: is it a potential dead lock that two workers waiting for each other? F.g., Worker A and B, A is going to handoff to B but unfortunately at the same time B has the same thing to do to A, then they are both waiting forever. If it is true, is it better to drop the packet when the ring is full? I copied my colleague Lollita into this discussion, she is working on it and knows better about this hypothesis. Regards, Kingwel