> You really can't use DPDK reliably without EAL threads and ideally > isolated CPU's. The problem is that one thread can end up waiting > for resources from another thread that is not running but scheduler > wants to put it on the same CPU.
Upon reviewing the code, I think RTS is the best alternative as it'll never wait on unscheduled threads since it only spins on atomic changes, while the classic and HTS could. To answer my own questions as far as I understand upon code review: > > The env_abstraction_layer documentation describes the “non-preemptive” > > constraint of rte_ring, and although it doesn't sound like our case > > should deadlock due to this, perhaps given the many threads and > > workers the performance penalty could reach such a long hang? I think it shouldn't deadlock but could hit a very high performance penalty. > > The documentation of rte_ring describes alternative MP modes such as > > RTS and HTS that help to avoid the Lock-Waiter-Preemption (LWP) > > problem, does it mean it would avoid the problem described in the > > env_abstraction_layer above? I think RTS mitigates it but I don't see how HTS would (even the deadlock could happen I think). > > I wonder if in our case where we have non-preemptive dpdk workers and > > preemptive pthread threads, whether we can mix the MP mode while > > enqueuing on the same ring? i.e. configure the ring with RTS/HTS mode > > and have the dpdk workers use rte_ring_mp_enqueue() while other > > threads use the generic rte_ring_enqueue() which will result RTS/HTS > > enqueue? I don't think MP modes can be mixed. > > Also, as both RTS and HTS help to avoid the LWP problem, and HTS does > > it with a single CAS while RTS requires two of them according to the > > doc, is there any reason to use RTS over HTS? HTS waits for prod_head==prod_tail while RTS is more relaxed and allows multiple producers to enqueue at the same time.
