From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by dpdk.org (Postfix) with ESMTP id 8E49D5AA0 for ; Thu, 11 Jun 2015 14:06:25 +0200 (CEST) Received: by wiga1 with SMTP id a1so73796426wig.0 for ; Thu, 11 Jun 2015 05:06:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=DvJlZ1JIH7MZpJQdek4tiibUo/PXf5Co+VmGcuVOQbU=; b=FTf/xzAaAxgypizIumYvPjruXMODoX+7o/QTDR0k6loCDq8RB2nbZV617IrQvT3BV4 JTAIcw2wYx0QtStkWgJJMsPHVpOE+l7y4DXiZzVAF7NDnsET/z5ccLu0GVbG8TNfTtrt MRhUmWYtDiaAa3j9ofvTVS8ncxglcD5WBDoegOsslzRPiJuhmPSmvYmEpg+h7lCBnMX4 0xpEoeKb12CfgcMfT+sF5SjWZX9jk4ckdWLi/Aokxm9R/xx/RksnI5GoY9IhXIcyCO8e Bsb8ne91s4rs43ZreqW98gDMl6L7NBvLB79vUOmHYPtels8LQHxhQElccjNd6p2UxtAW EE/Q== X-Gm-Message-State: ALoCoQmfN3FKr1MwqKxyI8WuXQiPRwoFKZY5ug0dEz3rlcgW/fDLy1fEQr5cMUZVHzuQ4RlTmm9h X-Received: by 10.180.81.70 with SMTP id y6mr29471094wix.14.1434024385438; Thu, 11 Jun 2015 05:06:25 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id ul1sm779004wjc.30.2015.06.11.05.06.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2015 05:06:24 -0700 (PDT) From: Thomas Monjalon To: Cristian Dumitrescu Date: Thu, 11 Jun 2015 14:05:29 +0200 Message-ID: <1611677.koeNccEWQN@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <1433775024-29866-1-git-send-email-cristian.dumitrescu@intel.com> References: <1433775024-29866-1-git-send-email-cristian.dumitrescu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] doc: guidelines for library statistics 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: Thu, 11 Jun 2015 12:06:26 -0000 Hi Cristian, Thanks for trying to make a policy clearer. We need to make a decision in the coming week. Below are comments on the style and content. 2015-06-08 15:50, Cristian Dumitrescu: > doc/guides/guidelines/statistics.rst | 42 ++++++++++++++++++++++++++= ++++++++++ Maybe we should have a more general file like design.rst. In order to have a lot of readers of such guidelines, they must be conc= ise. Please wrap lines to be not too long and/or split lines after the end o= f a sentence. > +Library Statistics > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +Description > +----------- > + > +This document describes the guidelines for DPDK library-level statis= tics counter support. This includes guidelines for turning library stat= istics on and off, requirements for preventing ABI changes when library= statistics are turned on and off, etc. Should we consider that driver stats and lib stats are different in DPD= K? Why? > +Motivation to allow the application to turn library statistics on an= d off > +--------------------------------------------------------------------= ----- > + > +It is highly recommended that each library provides statistics count= ers to allow the application to monitor the library-level run-time even= ts. Typical counters are: number of packets received/dropped/transmitte= d, number of buffers allocated/freed, number of occurrences for specifi= c events, etc. > + > +Since the resources consumed for library-level statistics counter co= llection have to be spent out of the application budget and the counter= s collected by some libraries might not be relevant for the current app= lication, in order to avoid any unwanted waste of resources and/or perf= ormance for the application, the application is to decide at build time= whether the collection of library-level statistics counters should be = turned on or off for each library individually. It would be good to have acknowledgements or other opinions on this. Some of them were expressed in other threads. Please comment here. > +Library-level statistics counters can be relevant or not for specifi= c applications: > +* For application A, counters maintained by library X are always rel= evant and the application needs to use them to implement certain featur= es, as traffic accounting, logging, application-level statistics, etc. = In this case, the application requires that collection of statistics co= unters for library X is always turned on; > +* For application B, counters maintained by library X are only usefu= l during the application debug stage and not relevant once debug phase = is over. In this case, the application may decide to turn on the collec= tion of library X statistics counters during the debug phase and later = on turn them off; Users of binary package have not this choice. > +* For application C, counters maintained by library X are not releva= nt at all. It might me that the application maintains its own set of st= atistics counters that monitor a different set of run-time events than = library X (e.g. number of connection requests, number of active users, = etc). It might also be that application uses multiple libraries (librar= y X, library Y, etc) and it is interested in the statistics counters of= library Y, but not in those of library X. In this case, the applicatio= n may decide to turn the collection of statistics counters off for libr= ary X and on for library Y. > + > +The statistics collection consumes a certain amount of CPU resources= (cycles, cache bandwidth, memory bandwidth, etc) that depends on: > +* Number of libraries used by the current application that have stat= istics counters collection turned on; > +* Number of statistics counters maintained by each library per objec= t type instance (e.g. per port, table, pipeline, thread, etc); > +* Number of instances created for each object type supported by each= library; > +* Complexity of the statistics logic collection for each counter: wh= en only some occurrences of a specific event are valid, several conditi= onal branches might involved in the decision of whether the current occ= urrence of the event should be counted or not (e.g. on the event of pac= ket reception, only TCP packets with destination port within a certain = range should be recorded), etc. > + > +Mechanism to allow the application to turn library statistics on and= off > +--------------------------------------------------------------------= ---- > + > +Each library that provides statistics counters should provide a sing= le build time flag that decides whether the statistics counter collecti= on is enabled or not for this library. This flag should be exposed as a= variable within the DPDK configuration file. When this flag is set, al= l the counters supported by current library are collected; when this fl= ag is cleared, none of the counters supported by the current library ar= e collected: > + > +=09#DPDK file =E2=80=9C./config/common_linuxapp=E2=80=9D, =E2=80=9C.= /config/common_bsdapp=E2=80=9D, etc > +=09CONFIG_RTE_LIBRTE__COLLECT_STATS=3Dy/n Why not simply CONFIG_RTE_LIBRTE__STATS (without COLLECT)= ? > +The default value for this DPDK configuration file variable (either = =E2=80=9Cyes=E2=80=9D or =E2=80=9Cno=E2=80=9D) is left at the decision = of each library. > + > +Prevention of ABI changes due to library statistics support > +----------------------------------------------------------- > + > +The layout of data structures and prototype of functions that are pa= rt of the library API should not be affected by whether the collection = of statistics counters is turned on or off for the current library. In = practical terms, this means that space is always allocated in the API d= ata structures for statistics counters and the statistics related API f= unctions are always built into the code, regardless of whether the stat= istics counter collection is turned on or off for the current library. > + > +When the collection of statistics counters for the current library i= s turned off, the counters retrieved through the statistics related API= functions should have the default value of zero.