* rte_mempool_ops support "ring_sp_sc" in single thread mode
@ 2023-07-13 4:12 jiangheng (G)
0 siblings, 0 replies; only message in thread
From: jiangheng (G) @ 2023-07-13 4:12 UTC (permalink / raw)
To: olivier.matz, andrew.rybchenko; +Cc: users
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
Whether rte_mempool_ops need supports the scenario where the producer and consumer are in the same thread?
Currently, "ring_sp_sc" can be used in this scenario, but its dequeue and enqueue functions have memory barriers, which are not required in the same single thread.
In addition, the number of r.prod and r.cons keeps increasing, and the recently released mbuf cannot be reused, which also affects the performance. If the cache is not enabled.
we can refer to mempool cache to implement "ring_single_thread_sp_sc". In this simple scenario, the performance should be improved.
This scenario is common:
Such as mbuf mempool. dpdk NICs receives a packet, the protocol stack processes and releases the packet. The alloc and release of the mbuf are in the same thread.
If it makes sense, I can offer a patch
[-- Attachment #2: Type: text/html, Size: 3574 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2023-07-13 4:12 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-13 4:12 rte_mempool_ops support "ring_sp_sc" in single thread mode jiangheng (G)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).