From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by dpdk.org (Postfix) with ESMTP id E560BC1CC for ; Tue, 2 Feb 2016 14:47:03 +0100 (CET) Received: by mail-ob0-f169.google.com with SMTP id wb13so116598354obb.1 for ; Tue, 02 Feb 2016 05:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kCC3w+JXZghvOrcqQYmxLqrbmbmZQ4mHysoJ7xPmnw8=; b=C92gZ8ZpDqQCHm+xfHW+Kq+lnirJToTVEZrhDaz8KsujxDReU1dJLx9yLY8UtyQ7NP g/Y1881FgfZT1eaU9jKqiwy9r+HbgSEwSX+m/eD38GFCsXkJAJ/uRH67j0rJjI9Y6/OH +QAywzo1C4g9bwfz2fspTMDPNOuK/GUD7HVowk9ym9bKWY0Kf1ASOa31EW0iLwKFB4T2 bCe8M1s8Dl2/IPF7PQDH8vxCKSLMwshd4L92QR/QmJFRQKW55hhCV6X+rPCNaahMIcQc Z0sObbsfEUp9XvNKLsB8R6s4zAiAs13hDWNz1O1OtMyNzuzM4cgb8eSBs7PYRLM62ZdM Gz1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kCC3w+JXZghvOrcqQYmxLqrbmbmZQ4mHysoJ7xPmnw8=; b=J0+5mkC+MeABzvP6yG7l+iCQpnDdhP3bZf8NQoUK5M3TuF8cAaGGBKMctqKrTOJV4X ywV9nKqT0cWeeZYhObwDY88hVxvO8oH/gbKiTX5EYxk8m8QpXFE8mKyev42iErihcJzH H5K1AoCnyDpMP5YGgef3MOcklScICOJ4VaEgb7T9wx7Hv5OHYFOESNzLqaeJiRMJMvi6 RuvGwHvMQIE+ugNvzMOh+6vTy57wVKR4ISl84nEs/OsEdcy67f0XUNNooq7FjxqtjyTU XmomPwoYHOFRQqcml9PpovGueopBgj8K6kN7dBgVrX3C1HR8lc+YP+kpOQG8prResqgQ 06aA== X-Gm-Message-State: AG10YOQ+bX3zl0NDsKl3pyuFBYYOz4Zj/PRyNwiLiu11evQqiO6oIPmaA/UIsXh5+t9Nsxz7n6DyHDOCGNJ/3Q== MIME-Version: 1.0 X-Received: by 10.60.132.42 with SMTP id or10mr22784367oeb.41.1454420823364; Tue, 02 Feb 2016 05:47:03 -0800 (PST) Received: by 10.76.68.7 with HTTP; Tue, 2 Feb 2016 05:47:03 -0800 (PST) In-Reply-To: <1A27633A6DA49C4A92FCD5D4312DBF536B0AC8DC@IRSMSX106.ger.corp.intel.com> References: <74583418c4374c349bfdea0c59b84118@XCH-RCD-016.cisco.com> <1A27633A6DA49C4A92FCD5D4312DBF536B09F7A4@IRSMSX106.ger.corp.intel.com> <27428043.8pduO1a1Qt@xps13> <20160122204851.GC22985@mhcomputing.net> <1A27633A6DA49C4A92FCD5D4312DBF536B0AC8DC@IRSMSX106.ger.corp.intel.com> Date: Tue, 2 Feb 2016 08:47:03 -0500 Message-ID: From: Kyle Larose To: "Tahhan, Maryam" Content-Type: text/plain; charset=UTF-8 Cc: "dev@dpdk.org" , Igor Ryzhov , Jonas Bjurel 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: Tue, 02 Feb 2016 13:47:04 -0000 On Tue, Feb 2, 2016 at 7:44 AM, Tahhan, Maryam wrote: >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Matthew Hall >> Sent: Friday, January 22, 2016 8:49 PM >> To: Igor Ryzhov >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get() >> >> On Fri, Jan 22, 2016 at 06:02:24PM +0300, Igor Ryzhov wrote: >> > 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. >> >> To be a bit more specific it would be good to have IF-MIB ifTable with >> the items from ifXTable as well: >> > > I think the MIBs ifTable would be good for the high level stats across all the drivers for sure, we would need to take backward compatibility for the current stats into account. > >> ifIndex >> ifMtu >> ifHighSpeed >> ifPromiscuousMode >> ifPhysAddress >> ifConnectorPresent >> >> ifHCInOctets >> ifHCInUcastPkts >> ifHCInMulticastPkts >> ifHCInBroadcastPkts >> ifInDiscards >> ifInErrors >> ifInUnknownProtos >> >> ifHCOutOctets >> ifHCOutUcastPkts >> ifHCOutMulticastPkts >> ifHCOutBroadcastPkts >> ifOutDiscards >> ifOutErrors >> >> A number of things are missing or weird in the DPDK stats interface. >> Then I get stuck trying to maintain them in my app instead and it's >> annoying. >> >> Also, it is nice to get the struct populated atomically so the values are as >> self-consistent as possible. If you have to call a function separately on >> each stat it makes them self-inconsistent because it is less atomically >> populated. > > +1 I also agree about the ifTable/ifXTable. I think that a few other ethernet oriented MIBs may also be worth considering. The RMON MIB's etherStatsTable has some useful counters in it (namely, the packet size histogram counters). We could also do the dot3StatsTable from the EtherLike MIB, though I'm not sure how useful it would be. >> >> From long experience, this inconsistency is quite annoying when trying to >> make very accurate traffic measurements in network management >> software. >> >> Matthew.