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

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

[Jose Gavine Cueto]

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.

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

[Etai Lev-Ran]

 

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.

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

[Jeff Venable]

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.
>
>

Re: [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@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.
>>
>>
>

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

[Richardson, Bruce]

> 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?
> 
[BR] As well as the use case already mentioned of passing using NULLs, there is also the scenario where we want to use the rings to pass integers e.g. uintptr_t values as array indexes, instead of pointers. While NULL may not be a valid pointer value, zero is a very common integer value.