From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com
 [209.85.220.43]) by dpdk.org (Postfix) with ESMTP id 8433AB7FD
 for <dev@dpdk.org>; Sat, 21 Feb 2015 02:53:33 +0100 (CET)
Received: by padet14 with SMTP id et14so12210770pad.11
 for <dev@dpdk.org>; Fri, 20 Feb 2015 17:53:33 -0800 (PST)
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=zYfKJ8szoI25BN04VQp7xVZzS5XXE5pKgXbmrOrivTo=;
 b=X1eH76toONuaJlE+xUDnxxUmKSzjx8KR4bQnpnUPQIQjCnqQ0G6AQWq6ifaGzluIFs
 pSiU1UKxGeYe/Ome87i3QkKnWV850yzlxSUJL2SqRz/6GqN+6VDyHOHkEEN82CpFmyMa
 b79G6wZ78KL2fiZ7zv47ukar4sGVaAk0LdqtkatUNGDlTzTer5OcduNvJNNybgSF3Tes
 I0haaiSZj6ZEvpmf4n+CwHGgqyXcifLP7CSL0Un9471T9/trN3m14SbKTiRcMG5Gzztf
 RKNA1LByDYDO3Oryeh2mzkTY8mj86oo1RLwLz5utiVAj24B+YQfIFcLvEaMh/SXN3gqO
 5JYA==
X-Gm-Message-State: ALoCoQlysL7ynH+3PP4zwAXIaiY2buaHn4LYJ9ZRtjPRx4VYAjnnDYNvnI76VOGeXZY3deVI7B6E
X-Received: by 10.70.35.15 with SMTP id d15mr794715pdj.61.1424483612901;
 Fri, 20 Feb 2015 17:53:32 -0800 (PST)
Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net.
 [50.53.82.155])
 by mx.google.com with ESMTPSA id hu12sm15179686pdb.41.2015.02.20.17.53.32
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 20 Feb 2015 17:53:32 -0800 (PST)
Date: Fri, 20 Feb 2015 17:53:27 -0800
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
Message-ID: <20150220175327.742d8676@urahara>
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891263231B3B2@IRSMSX108.ger.corp.intel.com>
References: <1423116841-19799-4-git-send-email-stephen@networkplumber.org>
 <20150220115256.7557e716@urahara>
 <3EB4FA525960D640B5BDFFD6A3D891263231B33C@IRSMSX108.ger.corp.intel.com>
 <2937997.VuavGYZbL6@xps13>
 <3EB4FA525960D640B5BDFFD6A3D891263231B3B2@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>
Subject: Re: [dpdk-dev] [PATCH v2 4/7] rte_sched: don't clear statistics
 when	read
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: Sat, 21 Feb 2015 01:53:34 -0000

On Fri, 20 Feb 2015 21:28:55 +0000
"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com> wrote:

> Agree.
> Stephen, how about a run-time solution (I agree it would be much better, why did I not consider this in the first place?) of adding a new bool parameter in struct rte_sched_port_params: clear_stats_on_reset?
> Both stats read function get the port handle (struct rte_sched_port *) as parameter, so there should be no ripple effect to propagate this flag.

Why not read_and_clear function if absolutely necessary.