Hi Pepe,
I?m assuming you?re creating and accessing the ring safely (i.e., single/multiple consumers and producers). Based on the code, these return values are possible if the ring somehow got a NULL object pointer enqueued to it. >From the ring?s perspective the entries are valid, and since the dequeue does >not check for NULL object pointers, you?re getting back element(s) that happen to be NULL. If this is indeed the case, I would propose the following patch: - Adding a check for NULL object pointers to ENQUEUE_PTRS in rte_ring.h (in debug code so not to hurt performance?) - returning an EINVAL error code if any object in a burst is NULL and aborting all enqueue (ie. all or none) IMHO, adding NULL objects is likely an error not a legitimate use case for adding ring elements. Can anyone think of a use case where adding NULL pointer objects makes sense? Best regards, Etai -----Original Message----- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jose Gavine Cueto Sent: Tuesday, November 19, 2013 12:35 PM To: dev at dpdk.org Subject: [dpdk-dev] rte_ring_sc_dequeue returns 0 but sets packet to NULL Hi, I am encountering a strange behavior of rte_ring_sc_dequeue, though I'm not yet sure what causes this. I have a code: rc = rte_ring_sc_dequeue(fwdp->rxtx_rings->xmit_ring, &rpackets); At first dequeue, rpackets gets a correct address of an rte_mbuf, however at the second dequeue it returns 0 which is successful but sets the rte_mbuf result to a NULL value. Is this even possible, because its happening in my scenario. Or it could be just there's something wrong with my code. Cheers, Pepe -- To stop learning is like to stop loving.
