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.