From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 6B22C326C for <dev@dpdk.org>; Tue, 4 Apr 2017 18:18:51 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id o81so29860761wmb.1 for <dev@dpdk.org>; Tue, 04 Apr 2017 09:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=HKgX9V6o1Qsrz9oNhW80pKEZyx8g2MF67OM638M015A=; b=YokixlJEpNd5xlcJLGqky1LeOVyn8ROSQ5CS38E0qKd4TVNuCjCzI5Ag+OJ+xS/axL UnVAMDKqFgqsOzJGqaiDy55svShrRIsgxqcJQmPi29ZBvLkcrV/ARHGmFiRpODGggZTj 59yX9hQzV9pwmBrRjkqCMX8E2chJqa31sGjMo1FiuHd/ans8U38ppdBZaf5Euze74coe StoAsT657/G79CvGw+sdxDWc/iXxGCgu62+JX35mBhtUETtKQxGgirHLVtbFLnNMIpsT 1EU1VNrt3WYCwd7VOgDYtyYFyBbItw123SwSM/1cKRmGj8r9bIAw7piJJvDI9Wu8ra4c xi3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=HKgX9V6o1Qsrz9oNhW80pKEZyx8g2MF67OM638M015A=; b=Vd168MHGk1inmriKBo0pEtFrOASpca4lZPFUtxqvaDdFOHsR0t4qaeIrLF+DDhUvC+ t9Sbdrnfy4VEJe3tw7uHDxlLFC31quDWKe0WXOGh37j3dq1cEorF/ujz0Eopm2+SdbaS +U/vWtY3aJcOPWv2ZX8sXWiBfOE74LDIesm1VeyehVRgJ/w2M+4Fwucm9aM8vdTOnXB1 D+vsKhNDJPKMeHw8rX0s3AU9Em3YYGFMR5kCWf90IKXCMgckuD1wV5oi2+UQy5+EVgRh OyzM9Uwm6bO8wlaNbXpkJdh/6FXFtHFCPPN8kGcsqdTiQSE5aJdFj974vVQbUA1Vv5r5 H9pQ== X-Gm-Message-State: AFeK/H1cA1mHyHDbjjp2VDULhyHAHHmh4j/KnU6ymudm0/roWIbO1w7R FGdDssDReLlTExZI X-Received: by 10.28.12.147 with SMTP id 141mr15661135wmm.8.1491322730844; Tue, 04 Apr 2017 09:18:50 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id e129sm19050412wma.13.2017.04.04.09.18.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 09:18:50 -0700 (PDT) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: "Van Haaren, Harry" <harry.van.haaren@intel.com> Cc: dev@dpdk.org, "Kozak, KubaX" <kubax.kozak@intel.com>, "Kulasek, TomaszX" <tomaszx.kulasek@intel.com>, "Piasecki, JacekX" <jacekx.piasecki@intel.com>, "Jastrzebski, MichalX K" <michalx.k.jastrzebski@intel.com> Date: Tue, 04 Apr 2017 18:18:49 +0200 Message-ID: <6167487.QzSI3n9msi@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <E923DB57A917B54B9182A2E928D00FA612A28F4A@IRSMSX102.ger.corp.intel.com> References: <1490910640-244285-2-git-send-email-michalx.k.jastrzebski@intel.com> <2943087.L4hhIMZ3WY@xps13> <E923DB57A917B54B9182A2E928D00FA612A28F4A@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Subject: Re: [dpdk-dev] [PATCH v3 1/3] add new xstats API retrieving by id X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <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: Tue, 04 Apr 2017 16:18:52 -0000 2017-04-04 15:45, Van Haaren, Harry: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2017-04-03 14:09, Jacek Piasecki: > > > From: Michal Jastrzebski <michalx.k.jastrzebski@intel.com> > > > > > > Extended xstats API in ethdev library to allow grouping of stats > > > logically so they can be retrieved per logical grouping =E2=80=93= managed > > > by the application. > > > Changed existing functions rte_eth_xstats_get_names and > > > rte_eth_xstats_get to use a new list of arguments: array of ids > > > and array of values. ABI versioning mechanism was used to > > > support backward compatibility. > > > Introduced two new functions rte_eth_xstats_get_all and > > > rte_eth_xstats_get_names_all which keeps functionality of the > > > previous ones (respectively rte_eth_xstats_get and > > > rte_eth_xstats_get_names) but use new API inside. > >=20 > > Sorry, I still do not understand why we should complicate the API. > > What is not possible with the existing API? >=20 >=20 > The current API only allows retrieval of *all* of the NIC statistics = at once. Given this requires a MMIO read PCI transaction per statistic = it is an inefficient way of retrieving just a few key statistics. My un= derstanding is that often a monitoring agent only has an interest in a = few key statistics, and the current API forces wasting CPU time and PCI= e bandwidth in retrieving *all* statistics; even those that the applica= tion didn't explicitly show an interest in. >=20 > The more flexible API as implemented in this patchset allow retrieval= of statistics per ID. If a PMD wishes, it can be implemented to read j= ust the required NIC registers. As a result, the monitoring application= no longer wastes PCIe bandwidth and CPU time. Thanks for the explanation. It has never been explained before. > > The v1 was submitted in the last days of the proposal deadline, > > v2 in the last minutes of integration deadline, > > and v3 is submitted after the deadline. > >=20 > > Given it is late and it is still difficult to understand the benefi= t, > > I think it won't make the release 17.05. >=20 >=20 > All in all, the value add to DPDK of this patchset is to enable appli= cations request statistics of interest to them, and to allow PMDs imple= ment the statistic functions more efficiently if they wish. As a bonus,= the ethdev and eventdev xstats APIs will have a consistent design, as = eventdev already uses this optimized ID based method. >=20 > Unless there are serious concerns about the current API (which should= have been flagged between a v1 and now), I don't see a reason to not u= pdate the API to use this improved method. If there are concerns about = how to update applications to the new API, that can be addressed in a d= ocumentation patch if the community feels there is value in that? I have commented on the need of explanation 3 days after the v1. There was no answer. So the review stopped at this point. Then one month later (last Thursday), a v2 appears which "replaced grouping mechanism to use mechanism based on IDs". So you cannot say it "should have been flagged between a v1 and now". Just because of the lack of communication, I do not want to spend these= days reviewing the API. It needs time and it will wait.