Hi Yerden, > -----Original Message----- > From: dev [mailto:dev-boun...@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
