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

["Etai Lev-Ran" <elevran@gmail.com>]

 

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.