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

[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

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

[Dumitrescu, Cristian]

Hi Yerden,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yerden
> Zhumabekov
> Sent: Monday, January 30, 2017 5:43 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] rte_port_ring and SP/MP, SC/MC flags
> 
> 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.
> 

Yes, we can detect the SP/MP and SC/MC characteristic of each rte_ring by looking inside the structure, at least at this point. As a side note, personally I see this as an implementation detail that might change, and I don't want to rely on it too much (yes, we do rely on it for validation purpose at port_ring creation time, as you state).

> 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?
> 

Yes, we could have decided to have a unified implementation of rte_port_ring reader/writer that handles the SC/MC or SP/MP aspect transparently, but we decided against it because we want to write branchless code. The unified implementation would have to test the internal S/M flag on every call of the port_ring RX/TX function, which would have a performance impact, especially when a mix of S and M port rings are used within the same app.

> 
> --
> 
> Yerden Zhumabekov

Regards,
Cristian