Hi Hanoch, On 01/04/2016 03:43 PM, Hanoch Haim (hhaim) wrote: > Hi Oliver, > > Let's take your drawing as a reference and add my question > The use case is sending a duplicate multicast packet by many threads. > I can split it to x threads to do the job and with atomic-ref (my multicast > not mbuf) count it until it reaches zero. > > In my following example the two cores (0 and 1) sending the indirect m1/m2 do > alloc/attach/send > > core0 | core1 > --------------------------------- > |--------------------------------------- > m_const=rte_pktmbuf_alloc(mp) | > | > while true: | while True: > m1 =rte_pktmbuf_alloc(mp_64) | m2 =rte_pktmbuf_alloc(mp_64) > rte_pktmbuf_attach(m1, m_const) | rte_pktmbuf_attach(m1, > m_const) > tx_burst(m1) | tx_burst(m2) > > Is this example is not valid?
For me, m_const is not expected to be used concurrently on several cores. By "used", I mean calling a function that modifies the mbuf, which is the case for rte_pktmbuf_attach(). > BTW this is our workaround > > > core0 | core1 > --------------------------------- > |--------------------------------------- > m_const=rte_pktmbuf_alloc(mp) | > rte_mbuf_refcnt_update(m_const,1)| <<-- workaround > | > while true: | while True: > m1 =rte_pktmbuf_alloc(mp_64) | m2 =rte_pktmbuf_alloc(mp_64) > rte_pktmbuf_attach(m1, m_const) | rte_pktmbuf_attach(m1, m_const) > tx_burst(m1) | tx_burst(m2) This workaround indeed solves the issue. Another solution would be to protect the call to attach() with a lock, or call all the rte_pktmbuf_attach() on the same core. I'm open to discuss this behavior for rte_pktmbuf_attach() function (should concurrent calls be allowed or not). In any case, we may want to better document it in the doxygen API comments. Regards, Olivier
