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

[elevran]

Hi Jeff,

Understood and that makes sense.
Thanks for the reply.

Would it be possible to generalize your use case for NULL, as need for
adding special marker pointers in order to either get cache alignment or
signal the ring consumer (e.g. null object implies end of transmission)?

I think that checking object!=NULL may be treated as a specific case of
obj!=marker, where marker can be any invalid pointer value.

Patching enqueue to check for a non NULL pointer would require  change to
your code, but would possibly eliminate behavior such as observed by Pepe.

Is there interest or objections to adding the check? I don't feel strongly
either way, but would opt for it unless there are objections.

Etai
בתאריך 20 בנוב 2013 20:32, "Jeff Venable" <jeff at 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 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.
>>
>>
>