From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com
 [209.85.220.41]) by dpdk.org (Postfix) with ESMTP id 446805A73
 for <dev@dpdk.org>; Mon, 16 Mar 2015 21:33:05 +0100 (CET)
Received: by padcy3 with SMTP id cy3so74891570pad.3
 for <dev@dpdk.org>; Mon, 16 Mar 2015 13:33:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-type:content-transfer-encoding;
 bh=Xxe1aC8lUcQg1FHkKq6ea8P6UnI3G2/cGfkJZ5xLRlw=;
 b=UxoeuGSlIq/nxKcgbyhrrXfucPItQR1qul86LF3SYwWHDsECyclhsVusPeF+MKnIv1
 aQ/l9XuXjok/ax4vwWtQUr0kBaPdi2n9gGCVpLwvUzh0s3V7PNv6GZbtuOFiOyq5bQ3d
 oeAiC5pyPnEJyQFhhhO8JHkqWbl8dAUpC+0iueogjayXSsVh01jZEKbIKkJgrafJL1BO
 GXxRVpqjUhcI9erxS3z0JFcH2ihDVKbrS08unIAlYogUYY08VYyfgXpM9JqDKUGR7dA0
 5x1Fup25rdc1E44GbUF5DyRy7WrauZz2RCyDWZzcP0xWrMWgBUp+Z/7KM66shFIBZ0MQ
 L1zg==
X-Gm-Message-State: ALoCoQnQ3JEGlBoPO3v54n0Mqq7Mum4x3YxKDt0LIEOvnjr+ohBs3cWZCv56DO9gXoGmgRVNVHpi
X-Received: by 10.66.169.137 with SMTP id ae9mr141176339pac.7.1426537984661;
 Mon, 16 Mar 2015 13:33:04 -0700 (PDT)
Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net.
 [50.53.82.155])
 by mx.google.com with ESMTPSA id z6sm18708502pdm.78.2015.03.16.13.33.03
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 16 Mar 2015 13:33:03 -0700 (PDT)
Date: Mon, 16 Mar 2015 13:33:04 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
Message-ID: <20150316133304.5a0e2b48@urahara>
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D89126323235E5@IRSMSX108.ger.corp.intel.com>
References: <1426004018-25948-1-git-send-email-stephen@networkplumber.org>
 <1426004018-25948-6-git-send-email-stephen@networkplumber.org>
 <3EB4FA525960D640B5BDFFD6A3D89126323225F4@IRSMSX108.ger.corp.intel.com>
 <20150312160626.47315f49@urahara>
 <3EB4FA525960D640B5BDFFD6A3D8912632323539@IRSMSX108.ger.corp.intel.com>
 <20150316131112.6a945025@urahara>
 <3EB4FA525960D640B5BDFFD6A3D89126323235E5@IRSMSX108.ger.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <dev@dpdk.org>, Stephen Hemminger <shemming@brocade.com>
Subject: Re: [dpdk-dev] [PATCH v2 5/6] rte_sched: allow reading statistics
 without clearing
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: Mon, 16 Mar 2015 20:33:05 -0000

On Mon, 16 Mar 2015 20:21:39 +0000
"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com> wrote:

> When stats read is decoupled from stats clear, the exchange operation cannot fix this.
> 
> To your point: when stats are cleared on read, would it make sense to use the exchange operation? In my opinion, it does not make sense, as the rte_sched API is not thread safe (for performance reasons), which is explicitly  stated. As clearly documented, the scheduler enqueue and dequeue operations need to run on the same CPU core. Therefore, IMHO having a thread safe stats read function while the main functional API is not thread safe is not going to add value.

Agreed but for a different reason.
It is safe but not consistent to read statistics from another management thread.
As long as no other thread is making changes to underlying configuration only
the values might change while packets in flight. Making all the statistics
fully atomic_t would be a performance killer.