From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Etai Lev-Ran" <elevran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: rte_ring_sc_dequeue returns 0 but sets packet to NULL
Date: Wed, 20 Nov 2013 11:19:52 +0200
Message-ID: <003d01cee5d1$acbee400$063cac00$@com>
References: <CAJ5bv6GPxs++faBwwnm9wfQbSxPbXO6PtQ2NY+Wg3oUs57ddpA@mail.gmail.com>
 <000301cee54e$bb49d170$31dd7450$@com>
 <CAJ5bv6G+BiB2XSg-sUDeQLg85=S02+Y0m79CjBxfQo=aQOGBXw@mail.gmail.com>
 <002f01cee5c9$eb6bf0b0$c243d210$@com>
 <CAJ5bv6H3ye9LkA5M4SB_QjADjHOx1hnw7RQkVBrJ3nzHeGaEBg@mail.gmail.com>
 <CAGNKSKc+=SeWXhohZWte4k8OjQz9q=i4seqm7JznQQB6T9sWoA@mail.gmail.com>
 <CAJ5bv6GM5vX8QR+bg8gmiEBtGYeQ15iKRmyRGyZ2Tv4VEDqagw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
To: <dev-VfR2kkLFssw@public.gmane.org>
Return-path: <dev-bounces-VfR2kkLFssw@public.gmane.org>
In-Reply-To: <CAJ5bv6GM5vX8QR+bg8gmiEBtGYeQ15iKRmyRGyZ2Tv4VEDqagw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Content-language: en-us
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev-VfR2kkLFssw@public.gmane.org>
List-Help: <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=subscribe>
Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org
Sender: "dev" <dev-bounces-VfR2kkLFssw@public.gmane.org>

=20

Hi Pepe,

=20

I=E2=80=99m assuming you=E2=80=99re creating and accessing the ring =
safely (i.e., single/multiple consumers and producers).

=20

Based on the code, these return values are possible if the ring somehow =
got a NULL object pointer enqueued to it.=20

>>From the ring=E2=80=99s perspective the entries are valid, and since the =
dequeue does not check for NULL object pointers,=20

you=E2=80=99re getting back element(s) that happen to be NULL.

=20

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?)=20

- returning an EINVAL error code if any object in a burst is NULL and =
aborting all enqueue (ie. all or none)

=20

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