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 E812B58CF for ; Mon, 15 Aug 2016 22:41:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by compass.polito.it (Postfix) with ESMTP id AB397100238 for ; Mon, 15 Aug 2016 22:41:52 +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-transfer-encoding:content-type :content-type:cc:to:subject:subject:message-id:date:date:from :from:references:in-reply-to:received:mime-version:received :received:received; s=y2k10; t=1471293711; bh=CNDwDQkT5HJXRWOA92 z/VzkFbTLGT/FNXvgP1t2oYxU=; b=B403QecYj+zo5rA9WxC9G3B7BSOnyA5Feq 4fd0+Aw/3YwOr0Eq9pLCapA9mNX2KdGshLdrRNWVChi5ENYSLywwKOgN0Ue9dWFH oy1bl3fP810qiDa8gG1KikFOYSD1/UdpuLS/E5MT2F6K/pL+lSILacpvNSGURzbW Wxe7B34a4= X-Virus-Scanned: amavisd-new at studenti.polito.it X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-100 required=3.5 tests=[ALL_TRUSTED=-5, BAYES_00=-1.5] 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 a9BKNWu6jFYg for ; Mon, 15 Aug 2016 22:41:51 +0200 (CEST) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) (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 14547100235 for ; Mon, 15 Aug 2016 22:41:51 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id i5so126173518wmg.0 for ; Mon, 15 Aug 2016 13:41:51 -0700 (PDT) X-Gm-Message-State: AEkooutQ8HER0jLhFave8FSN3a7Yi03Vffh517KMPDUM8GOsbjjhjTpMyNd4QkMfA0sm3Xnrxdx0I078KX+i8Q== X-Received: by 10.25.23.210 with SMTP id 79mr5349482lfx.200.1471293710632; Mon, 15 Aug 2016 13:41:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.5.207 with HTTP; Mon, 15 Aug 2016 13:41:49 -0700 (PDT) In-Reply-To: <20160516131633.GA22356@bricha3-MOBL3> References: <20160510093629.GA1508@bricha3-MOBL3> <20160516131633.GA22356@bricha3-MOBL3> From: =?UTF-8?Q?Mauricio_V=C3=A1squez?= Date: Mon, 15 Aug 2016 22:41:49 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Bruce Richardson Cc: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 15 Aug 2016 20:41:53 -0000 Finally I have some time to have a look to it. On Mon, May 16, 2016 at 3:16 PM, Bruce Richardson wrote: > On Mon, May 16, 2016 at 03:12:10PM +0200, Mauricio V=C3=A1squez wrote: >> Hello Bruce, >> >> Although having this support does not harm anyone, I am not convinced th= at >> it is useful, mainly because there exists the single-thread limitation i= n >> 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 >> > I agree. > If you want, please submit a patch to remove this behaviour and see > if anyone objects to it. If there are no objections, I have no problem ac= cepting > the patch. > > However, since this is a behaviour change to existing functionality, we m= ay > need to implement function versionning for this for ABI compatibility. Pl= ease > take that into account when drafting any patch. > Do you think that versioning is required in this case? If anyone is using a functionality that is not supposed to work in that way, should we care about it? I am not against versioning, I just want to know if it is worthy to do. > Regards, > /Bruce > >> 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 multi= ple >> > > consumers/producer flag enabled. >> > > >> > > According to the design principles, the application should not invok= e >> > those >> > > functions on the same queue on different cores, then I think that at= omic >> > > 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 t= he >> > 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 =3D (uint16_t)rte_ring_dequeue_burst(r->r= ng, >> > 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 wit= h >> > removing >> > it, since all other PMDs have the restriction that the queues are >> > single-thread >> > only. >> > >> > Regards, >> > /Bruce >> > Regards, Mauricio V