[dpdk-dev] rte_port_ring and SP/MP, SC/MC flags

[Yerden Zhumabekov]

Hello,

I'd like to use rte_port_ring abstract in my application and I'm a 
little confused about how it treats underlying ring flags.

According to DPDK API reference, when creating a ring (via 
rte_ring_create()/rte_ring_init()), RING_F_SP_ENQ/RING_F_SC_DEQ may be 
specified. These flags affect the choice of MP/SP, MC/SC operation when 
using 'default' ring enq/deq API, i.e. 
rte_ring_enqueue()/rte_ring_dequeue(), 
rte_ring_enqueue_bulk()/rte_ring_dequeue_bulk(), 
rte_ring_enqueue_burst()/rte_ring_dequeue_burst().

These API then choose which version of enq/deq to use considering the 
flags. If you use designated API straightforward, those API (*_mp_*, 
*_sc_* etc.) don't care about these flags and perform required 
operations right away.

When I use rte_port_ring abstraction, '.f_create()' functions check for 
flags which were used when creating an underlying ring (see 
lib/librte_port/rte_port_ring.c:75). But then different call tables use 
designated ring API which makes checking flags pointless.

I find it confusing to be forced to choose between SP/MP, SC/MC twice, 
when creating ring at first and creating abstraction afterwards. And I 
see no point in checking for ring flags when creating abstraction 
because it really does not affect the operation of this abstraction 
anyway. Is this behaviour anyhow justified?


-- 

Yerden Zhumabekov