I was using NULLs in the ring to cache-line pad and maintain alignment during burst dequeue. The receiving code discards the NULLs as NOPs.
Jeff On Wed, Nov 20, 2013 at 1:19 AM, Etai Lev-Ran <elevran at gmail.com> wrote: > > > 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-bounces at 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. > >
