* [dpdk-dev] rte_ring_sc_dequeue returns 0 but sets packet to NULL
@ 2013-11-19 10:35 Jose Gavine Cueto
[not found] ` <000301cee54e$bb49d170$31dd7450$@com>
0 siblings, 1 reply; 5+ messages in thread
From: Jose Gavine Cueto @ 2013-11-19 10:35 UTC (permalink / raw)
To: dev
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.
^ permalink raw reply [flat|nested] 5+ messages in thread[parent not found: <000301cee54e$bb49d170$31dd7450$@com>]
[parent not found: <CAJ5bv6G+BiB2XSg-sUDeQLg85=S02+Y0m79CjBxfQo=aQOGBXw@mail.gmail.com>]
[parent not found: <002f01cee5c9$eb6bf0b0$c243d210$@com>]
[parent not found: <CAJ5bv6H3ye9LkA5M4SB_QjADjHOx1hnw7RQkVBrJ3nzHeGaEBg@mail.gmail.com>]
[parent not found: <CAGNKSKc+=SeWXhohZWte4k8OjQz9q=i4seqm7JznQQB6T9sWoA@mail.gmail.com>]
[parent not found: <CAJ5bv6GM5vX8QR+bg8gmiEBtGYeQ15iKRmyRGyZ2Tv4VEDqagw@mail.gmail.com>]
* Re: [dpdk-dev] rte_ring_sc_dequeue returns 0 but sets packet to NULL [not found] ` <CAJ5bv6GM5vX8QR+bg8gmiEBtGYeQ15iKRmyRGyZ2Tv4VEDqagw@mail.gmail.com> @ 2013-11-20 9:19 ` Etai Lev-Ran 2013-11-20 18:32 ` Jeff Venable 2013-11-22 9:54 ` Richardson, Bruce 0 siblings, 2 replies; 5+ messages in thread From: Etai Lev-Ran @ 2013-11-20 9:19 UTC (permalink / raw) To: dev 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] rte_ring_sc_dequeue returns 0 but sets packet to NULL 2013-11-20 9:19 ` Etai Lev-Ran @ 2013-11-20 18:32 ` Jeff Venable 2013-11-20 19:20 ` elevran 2013-11-22 9:54 ` Richardson, Bruce 1 sibling, 1 reply; 5+ messages in thread From: Jeff Venable @ 2013-11-20 18:32 UTC (permalink / raw) To: Etai Lev-Ran; +Cc: dev 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. > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] rte_ring_sc_dequeue returns 0 but sets packet to NULL 2013-11-20 18:32 ` Jeff Venable @ 2013-11-20 19:20 ` elevran 0 siblings, 0 replies; 5+ messages in thread From: elevran @ 2013-11-20 19:20 UTC (permalink / raw) To: Jeff Venable; +Cc: dev 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. >> >> > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] rte_ring_sc_dequeue returns 0 but sets packet to NULL 2013-11-20 9:19 ` Etai Lev-Ran 2013-11-20 18:32 ` Jeff Venable @ 2013-11-22 9:54 ` Richardson, Bruce 1 sibling, 0 replies; 5+ messages in thread From: Richardson, Bruce @ 2013-11-22 9:54 UTC (permalink / raw) To: Etai Lev-Ran, dev > 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-11-22 9:53 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-19 10:35 [dpdk-dev] rte_ring_sc_dequeue returns 0 but sets packet to NULL Jose Gavine Cueto
[not found] ` <000301cee54e$bb49d170$31dd7450$@com>
[not found] ` <CAJ5bv6G+BiB2XSg-sUDeQLg85=S02+Y0m79CjBxfQo=aQOGBXw@mail.gmail.com>
[not found] ` <002f01cee5c9$eb6bf0b0$c243d210$@com>
[not found] ` <CAJ5bv6H3ye9LkA5M4SB_QjADjHOx1hnw7RQkVBrJ3nzHeGaEBg@mail.gmail.com>
[not found] ` <CAGNKSKc+=SeWXhohZWte4k8OjQz9q=i4seqm7JznQQB6T9sWoA@mail.gmail.com>
[not found] ` <CAJ5bv6GM5vX8QR+bg8gmiEBtGYeQ15iKRmyRGyZ2Tv4VEDqagw@mail.gmail.com>
2013-11-20 9:19 ` Etai Lev-Ran
2013-11-20 18:32 ` Jeff Venable
2013-11-20 19:20 ` elevran
2013-11-22 9:54 ` Richardson, Bruce
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).