From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from compass.polito.it (compass.polito.it [130.192.55.110]) by dpdk.org (Postfix) with ESMTP id DF1229A9E for ; Mon, 16 May 2016 15:12:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by compass.polito.it (Postfix) with ESMTP id 9F2C21000E6 for ; Mon, 16 May 2016 15:12:12 +0200 (CEST) Authentication-Results: compass.polito.it (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=studenti.polito.it DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= studenti.polito.it; h=content-type:content-type:cc:to:from:from :subject:subject:message-id:date:date:references:in-reply-to :received:mime-version:received:received:received; s=y2k10; t= 1463404331; bh=i5S011966Smm/oG2GkwM23A3YBX/OsGcor6l30y1RCk=; b=n 3h7wFzq7gCgu/XagEUNQ1f5Ptmf5oq6YQ2Kp/YjVcrjvZcczOGuZijleqO+gIDna dZtQmzhzHmPr7xIKCiLYOJ/woNCSwh6cdyL6APsCFd26J6hSZqtvCT+yW09jYiLT ExpuYtbF+aT7LdGDEWJexqpIRv+twZwZF2uiHaxrmU= X-Virus-Scanned: amavisd-new at studenti.polito.it X-Spam-Flag: NO X-Spam-Score: -5.897 X-Spam-Level: X-Spam-Status: No, score=-5.897 tagged_above=-100 required=3.5 tests=[ALL_TRUSTED=-5, AWL=0.602, BAYES_00=-1.5, HTML_MESSAGE=0.001] autolearn=ham Received: from compass.polito.it ([127.0.0.1]) by localhost (compass.polito.it [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rexnrAeauL_h for ; Mon, 16 May 2016 15:12:11 +0200 (CEST) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: s203403@studenti.polito.it) by compass.polito.it (Postfix) with ESMTPSA id 17BFE1000BB for ; Mon, 16 May 2016 15:12:11 +0200 (CEST) Received: by mail-lf0-f44.google.com with SMTP id m64so116300019lfd.1 for ; Mon, 16 May 2016 06:12:11 -0700 (PDT) X-Gm-Message-State: AOPr4FUVSAjxXUEm5J3Z/02wRY9l++EYOMXP3X5w+MQeakk8VC3EaiallPjZ40BQVGShv0I9yNMsa0p/FarfWw== MIME-Version: 1.0 X-Received: by 10.25.147.68 with SMTP id v65mr11657625lfd.9.1463404330686; Mon, 16 May 2016 06:12:10 -0700 (PDT) Received: by 10.25.4.200 with HTTP; Mon, 16 May 2016 06:12:10 -0700 (PDT) In-Reply-To: <20160510093629.GA1508@bricha3-MOBL3> References: <20160510093629.GA1508@bricha3-MOBL3> Date: Mon, 16 May 2016 15:12:10 +0200 X-Gmail-Original-Message-ID: Message-ID: From: =?UTF-8?Q?Mauricio_V=C3=A1squez?= To: Bruce Richardson Cc: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 13:12:13 -0000 Hello Bruce, Although having this support does not harm anyone, I am not convinced that it is useful, mainly because there exists the single-thread limitation in other PMDs. Then, if an application has to use different kind of NICs (i.e, different PMDs) it has to implement the locking strategies. On the other hand, if an application only uses rte_rings, it could just use the rte_ring library. Thanks, Mauricio V On Tue, May 10, 2016 at 11:36 AM, Bruce Richardson < bruce.richardson@intel.com> wrote: > On Tue, May 10, 2016 at 11:13:08AM +0200, Mauricio V=C3=A1squez 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 atomi= c > > 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 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-atomically, > 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 > removing > it, since all other PMDs have the restriction that the queues are > single-thread > only. > > Regards, > /Bruce >