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> 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 > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9024): https://lists.fd.io/g/vpp-dev/message/9024 View All Messages In Topic (2): https://lists.fd.io/g/vpp-dev/topic/18048596 Mute This Topic: https://lists.fd.io/mt/18048596/21656 New Topic: https://lists.fd.io/g/vpp-dev/post Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656 Group Home: https://lists.fd.io/g/vpp-dev Contact Group Owner: vpp-dev+ow...@lists.fd.io Terms of Service: https://lists.fd.io/static/tos Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub -=-=-=-=-=-=-=-=-=-=-=-
signature.asc
Description: Message signed with OpenPGP
