From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by dpdk.org (Postfix) with ESMTP id 7EA06156 for ; Wed, 20 Nov 2013 20:19:30 +0100 (CET) Received: by mail-pa0-f54.google.com with SMTP id rd3so4631791pab.13 for ; Wed, 20 Nov 2013 11:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y4MGras/QoCOjN7cHOZMD4HfW7eKXrEFgC2SP8BWA5U=; b=PloOt2f7n9zu95I/Yzm9unuUJeb2xqMb5MuOHEsqYg/INjhJnAhoQDk2tgA0bhpEMC AWKr9Rb5ht2jPiV4zEWEGs8EHREl6dGp2PVoOv9QpSKyuCOcnRa6L03hcYRfuiqydl/O 8Lo5YHYVsqT0++U3J9Decyz6PZ+bNqEwOPiMqMlZr9ZT37aa0kiyVF9XQrLzu+APbqe0 q/TskK5+z/ksoeOUCcj8gzQY9AOaCNydM23spANoSPnNkKp0w85LGhLuZ6QlSZjJ97LM zqzH0yQkqJ4ot4oVGeWRehOjvoatEDbbjK8tPADD3ASCqGm4AAZHyi737fqSBvPpCnNo p20w== MIME-Version: 1.0 X-Received: by 10.68.130.169 with SMTP id of9mr2301113pbb.79.1384975227697; Wed, 20 Nov 2013 11:20:27 -0800 (PST) Received: by 10.66.11.168 with HTTP; Wed, 20 Nov 2013 11:20:27 -0800 (PST) Received: by 10.66.11.168 with HTTP; Wed, 20 Nov 2013 11:20:27 -0800 (PST) In-Reply-To: References: <000301cee54e$bb49d170$31dd7450$@com> <002f01cee5c9$eb6bf0b0$c243d210$@com> <003d01cee5d1$acbee400$063cac00$@com> Date: Wed, 20 Nov 2013 21:20:27 +0200 Message-ID: From: elevran To: Jeff Venable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] rte_ring_sc_dequeue returns 0 but sets packet to NULL X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 19:19:31 -0000 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!=3DNULL may be treated as a specific case of obj!=3Dmarker, 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 =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 20 =D7=91=D7=A0=D7=95=D7=91 2013 20:32= , "Jeff Venable" =D7=9B=D7=AA=D7=91: > 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 wrote: > >> >> >> Hi Pepe, >> >> >> >> I=E2=80=99m assuming you=E2=80=99re creating and accessing the ring safe= ly (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=E2=80=99s perspective the entries are valid, and since the= dequeue >> does not check for NULL object pointers, >> >> you=E2=80=99re 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 NUL= L >> >> 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, howeve= r >> at >> the second dequeue it returns 0 which is successful but sets the rte_mbu= f >> 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. >> >> >