From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: Ring PMD: why are stats counters atomic?
Date: Tue, 10 May 2016 10:36:29 +0100
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-Transfer-Encoding: quoted-printable
Cc: dev@dpdk.org
To: Mauricio =?iso-8859-1?Q?V=E1squez?=
 <mauricio.vasquezbernal@studenti.polito.it>
Return-path: <dev-bounces@dpdk.org>
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)
Content-Disposition: inline
In-Reply-To: <CAPwdgqjR1eSt5ewcdm93WNT-ZX7ychWUSdSZvbU22Rapat3ybQ@mail.gmail.com>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Tue, May 10, 2016 at 11:13:08AM +0200, Mauricio V=E1squez wrote:
> Hello,
>=20
> 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.
>=20
> According to the design principles, the application should not invoke t=
hose
> functions on the same queue on different cores, then I think that atomi=
c
> increasing is not necessary.
>=20
> Is there something wrong with my reasoning?, If not, I am willing to se=
nd a
> patch.
>=20
> Thank you very much,
>=20
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 sam=
e 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-atomic=
ally,
depending on the underlying queue type.

        const uint16_t nb_rx =3D (uint16_t)rte_ring_dequeue_burst(r->rng,
                        ptrs, nb_bufs);
        if (r->rng->flags & RING_F_SC_DEQ)
                r->rx_pkts.cnt +=3D 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 r=
emoving
it, since all other PMDs have the restriction that the queues are single-=
thread
only.

Regards,
/Bruce