From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id 574A79618
 for <dev@dpdk.org>; Tue, 10 May 2016 11:36:33 +0200 (CEST)
Received: from fmsmga004.fm.intel.com ([10.253.24.48])
 by orsmga101.jf.intel.com with ESMTP; 10 May 2016 02:36:32 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.24,604,1455004800"; d="scan'208";a="100399792"
Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.220.76])
 by fmsmga004.fm.intel.com with SMTP; 10 May 2016 02:36:30 -0700
Received: by  (sSMTP sendmail emulation); Tue, 10 May 2016 10:36:29 +0025
Date: Tue, 10 May 2016 10:36:29 +0100
From: Bruce Richardson <bruce.richardson@intel.com>
To: Mauricio =?iso-8859-1?Q?V=E1squez?=
 <mauricio.vasquezbernal@studenti.polito.it>
Cc: dev@dpdk.org
Message-ID: <20160510093629.GA1508@bricha3-MOBL3>
References: <CAPwdgqjR1eSt5ewcdm93WNT-ZX7ychWUSdSZvbU22Rapat3ybQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAPwdgqjR1eSt5ewcdm93WNT-ZX7ychWUSdSZvbU22Rapat3ybQ@mail.gmail.com>
Organization: Intel Shannon Ltd.
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [dpdk-dev] Ring PMD: why are stats counters atomic?
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2016 09:36:33 -0000

On Tue, May 10, 2016 at 11:13:08AM +0200, Mauricio Vásquez wrote:
> Hello,
> 
> Per-queue stats counters are defined as rte_atomic64_t, in the tx/rx
> functions, they are atomically increased if the rings have the multiple
> consumers/producer flag enabled.
> 
> According to the design principles, the application should not invoke those
> functions on the same queue on different cores, then I think that atomic
> increasing is not necessary.
> 
> Is there something wrong with my reasoning?, If not, I am willing to send a
> patch.
> 
> Thank you very much,
> 
Since the rte_rings, on which the ring pmd is obviously based, have multi-producer
and multi-consumer support built-in, I thought it might be useful in the ring
PMD itself to allow multiple threads to access the ring queues at the same time,
if the underlying rings are marked as MP/MC safe. When doing enqueues and dequeue
from the ring, the stats are either incremented atomically, or non-atomically,
depending on the underlying queue type.

        const uint16_t nb_rx = (uint16_t)rte_ring_dequeue_burst(r->rng,
                        ptrs, nb_bufs);
        if (r->rng->flags & RING_F_SC_DEQ)
                r->rx_pkts.cnt += nb_rx;
        else
                rte_atomic64_add(&(r->rx_pkts), nb_rx);

If people don't think this behaviour is worthwhile keeping, I'm ok with removing
it, since all other PMDs have the restriction that the queues are single-thread
only.

Regards,
/Bruce