From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by dpdk.org (Postfix) with ESMTP id 834D18E9F for ; Fri, 22 Jan 2016 16:02:27 +0100 (CET) Received: by mail-lb0-f173.google.com with SMTP id oh2so42552018lbb.3 for ; Fri, 22 Jan 2016 07:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nfware-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=No+rX3oY5CfJ+w1lLGwmvw+c79zSkdAARKaxFQy0FHs=; b=WYZa7Vp6Fy06uGZauvTLFCtyZ3pkIoUxnvgCo7HDaTU2U9KllRGvMKstNQWoyypiwq uARoHkCGhk/XkXDvV0KQGtBJpJdcLFUnJLM78P/qRJNqhQVyq5pPjYV6Pd30cZi2caFj riI0BYWpy6VTJ8heT2ixvhWaGsn3/I9xxV9q/Q2mU4kgJNVY/KOThZIoDkoyjO0WVlcb qivXrTCKd36xi1IdE+qR/8uG4HJb92vCDkiteFPoXnqgQZZzsq5GHK3tubmDpdBeHeUH oq4egJe4qKs2LJvtZt41PmujSr+Iw1NXPsr/Ty1qK64QKCGSY3KRvQbBWMtDMi3Uu2w0 e/Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=No+rX3oY5CfJ+w1lLGwmvw+c79zSkdAARKaxFQy0FHs=; b=mOktP5v7QA9jse8r6ILZZREVUrOEmDvGrSNFmj4CkPlCWTjzLeAhU8M9Az0YbiFA4s w8Z1iu3ufi9QbnoN2lTVlDU0CaVZKcHvxXBFJleAb02csJHQv95lUvfMgCXTsohUz+OL nmYNeSBZN57UsV5Ghs4Du7cJ9CgmwEOAhCmV9zBpOLi464jWhLUfehVZsgSBbB5p5d+C cgi9tGPO+beI+7zheYDUpawHrgz5RgpxKtsQQPjnxJoPwhctS37QxiYnfRYNdXshQWXs uWsSztshqQ4J8IFrqqbQ05EKY+TsD6OCDv2IlOyzibsx/A0mYsiNwltKhx+gSN8XiCxf Porg== X-Gm-Message-State: AG10YORtxobbXNoZ6aPBDMYCJWBhJwcNoTDWWAa6DuQ+07L/On9qvXfZDYU7AmTgDadCxQ== X-Received: by 10.112.72.168 with SMTP id e8mr1429939lbv.114.1453474947248; Fri, 22 Jan 2016 07:02:27 -0800 (PST) Received: from [10.30.40.109] (vpn.arccn.ru. [95.182.74.2]) by smtp.gmail.com with ESMTPSA id o3sm947529lfb.39.2016.01.22.07.02.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 07:02:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Igor Ryzhov In-Reply-To: <27428043.8pduO1a1Qt@xps13> Date: Fri, 22 Jan 2016 18:02:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <74583418c4374c349bfdea0c59b84118@XCH-RCD-016.cisco.com> <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@IRSMSX106.ger.corp.intel.com> <27428043.8pduO1a1Qt@xps13> To: Thomas Monjalon X-Mailer: Apple Mail (2.3112) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get() 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: Fri, 22 Jan 2016 15:02:27 -0000 Hello, everyone. How about exposing stats according to IF-MIB? Statistics to be exposed are - octets, unicast packets, multicast = packets, broadcast packets, errors and discards for both TX and RX. These counters are basic and implemented by most of drivers. All other driver-specific counters can be exposed by xstats. Best regards, Igor > 22 =D1=8F=D0=BD=D0=B2. 2016 =D0=B3., =D0=B2 17:44, Thomas Monjalon = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0= =B0): >=20 > 2016-01-22 14:18, Tahhan, Maryam: >> So what can be enabled again in struct rte_eth_stats from what was = already there is the equivalent of:=20 >> * rx_length_errors >> * rx_crc_errors >> * rx_missed_errors - the deprecation notice was removed for this = field. >> * multicast >>=20 >> What should be added in to distinguish between errors and drops. = struct rte_eth_stats : >> * rx_errors >> * tx_errors >>=20 >> As for the detailed rx errors and tx errors I'm open to feedback from = you folks as to what should go in and what is too detailed. These = weren't in struct rte_eth_stats previously, they are available through = xstats and are uniformly named across the drivers. Oliver + Harry any = thoughts? >>=20 >> David I assume you are looking for all the missing fields to be = added? >=20 > They are not missing. They just not exactly match ones having a > long history in Linux kernel. > Please let's avoid to blindly mimic others without thinking > about modern needs. >=20 >>>> From: David Harton >>>>> Is there a reason the stats have been deprecated? Why not keep >>>>> the stats in line with the standard linux practices such as >>>>> rtnl_link_stats64? >=20