From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 13225A052B; Wed, 29 Jul 2020 16:21:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7F2C61C010; Wed, 29 Jul 2020 16:21:37 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id 3A50B1BE9A for ; Wed, 29 Jul 2020 16:21:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596032495; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6WjwOb4vo14Wa8s4Q03Ccyq1GGMCLfSqlnbxZtKKF8c=; b=F433DDhDCYFNc1orRVb0RfroYaZCW3g95ISsgebiAZFTZpDjDLuoMC1FYGRNLLIUUti7dg Eg1ySpdCRwRYIty+ZOsU0MTqXGDky7jRSi6yFxzQaQ5OjuyT6LGTEUvhNagk0qdrRaqWOg iVQvMMCCEHijYX5WFpMrnxUdtaJlLTs= Received: from mail-vs1-f69.google.com (mail-vs1-f69.google.com [209.85.217.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-96-V1FCqHg7POOOFyrP38U-aA-1; Wed, 29 Jul 2020 10:21:30 -0400 X-MC-Unique: V1FCqHg7POOOFyrP38U-aA-1 Received: by mail-vs1-f69.google.com with SMTP id i11so3068926vsk.0 for ; Wed, 29 Jul 2020 07:21:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6WjwOb4vo14Wa8s4Q03Ccyq1GGMCLfSqlnbxZtKKF8c=; b=NgklCWcG5RDGsvQPlNKiftqPpKuKNPSKg0ocn97DJ0bzBApu+21VMgiyN2H2D7Wvz5 zbcc8Xxjm18ovqv9465vTGQqXVuyU89cCaMXIJPoDoe1K+LlLd3AUOg3sj+oH/kyRwb0 Ipg5OwmFEXNb/yzTrJqEHkfziHZqRonJYO3CkxBkJsEQKk/6mC5HNrXMRMLxV/jpu8Yy G/TGi8nQ36l75knDZAnLHZAvplo8UhOUldz2egEvTuCS86AI0Ln5PhQyU/OHGXw1S7NS plqlmNZxDJBem+o5ji/8X2h8PuG3I/qUD5vMjMFOktTdNuANaJQTg0TQu8EeOMuo2+JE RMxA== X-Gm-Message-State: AOAM533tcyi5+zj7+CwHLMJ6G0qe16zrZheJIa8Nlg1JmDcdm74MNaar RN4BeuPnpoCNEYcy33Jfn+koDoQZVFcARoE+ro3/q6eKEZasTPlB1bPLKc8RYKW2LqzJH4qBg/x lW+khCA0yZqLjxBioruM= X-Received: by 2002:a67:c58c:: with SMTP id h12mr24681980vsk.141.1596032489522; Wed, 29 Jul 2020 07:21:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztXqiwKNryrC6F7QRHSHjIcyjbrCD9BgsepGHpNsaWpl3S8OXi/LstZ6qjNJ6wl+JPzlJMsL9KZFMGqrofDcg= X-Received: by 2002:a67:c58c:: with SMTP id h12mr24681942vsk.141.1596032489311; Wed, 29 Jul 2020 07:21:29 -0700 (PDT) MIME-Version: 1.0 References: <20200729063105.11299-1-feifei.wang2@arm.com> <20200729063105.11299-3-feifei.wang2@arm.com> In-Reply-To: From: David Marchand Date: Wed, 29 Jul 2020 16:21:18 +0200 Message-ID: To: Feifei Wang Cc: Honnappa Nagarahalli , Konstantin Ananyev , Gavin Hu , Olivier Matz , dev , nd , dpdk stable Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v1 2/2] test/ring: fix wrong param passed to the enqueue APIs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Jul 29, 2020 at 4:16 PM Feifei Wang wrote: > > Are we missing a check in the UT so that dequeued object is what had been > > enqueued? > > > > > Dequeue is not necessary to change because the param defined in rte_ring_dequeue > is different from that in rte_ring_enqueue: > rte_ring_enqueue(struct rte_ring *r, void *obj): obj is a pointer (object) to be added in the ring > rte_ring_dequeue(struct rte_ring *r, void **obj_p): obj_p is a pointer to a void * pointer > (object) that will be filled. That I get it. What I meant is that the test enqueues an object in a ring until it is full [1], then dequeues all the ring [2]. 1: https://git.dpdk.org/dpdk/tree/app/test/test_ring.c#n814 2: https://git.dpdk.org/dpdk/tree/app/test/test_ring.c#n825 If the test had checked that dequeued objects are the right one, we would have caught it. But on the other hand, maybe another part of the functionnal ring tests already check this and we only need to fix this issue here. -- David Marchand