Re: [dpdk-dev] rte_ring_sc_dequeue returns 0 but sets packet to NULL

[Jeff Venable <jeff@tracevector.com>]

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@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@dpdk.org] On Behalf Of Jose Gavine Cueto
> Sent: Tuesday, November 19, 2013 12:35 PM
> To: dev@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.
>
>