From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCH v2] drivers/net: add support for IF-MIB and EtherLike-MIB for e1000 Date: Tue, 27 Jun 2017 12:36:07 +0100 Message-ID: <1ab6bff3-7f84-ef00-b015-edb92ee73d40@intel.com> References: <20170522143202.22424-2-michalx.k.jastrzebski@intel.com> <1498470133-29788-1-git-send-email-radu.nicolau@intel.com> <4375ffd8-6957-7f53-a9b0-081e705a5eb1@intel.com> <20170627112139.GB105608@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Radu Nicolau , dev@dpdk.org, wenzhuo.lu@intel.com, reshma.pattan@intel.com, michalx.k.jastrzebski@intel.com, deepak.k.jain@intel.com, harry.van.haaren@intel.com, piotrx.t.azarewicz@intel.com To: Bruce Richardson Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 65066374 for ; Tue, 27 Jun 2017 13:36:11 +0200 (CEST) In-Reply-To: <20170627112139.GB105608@bricha3-MOBL3.ger.corp.intel.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 6/27/2017 12:21 PM, Bruce Richardson wrote: > On Tue, Jun 27, 2017 at 12:08:56PM +0100, Ferruh Yigit wrote: >> On 6/26/2017 10:42 AM, Radu Nicolau wrote: >>> From: Michal Jastrzebski >>> >>> If-MIB xstats: >>> ifNumber >>> ifIndex >>> ifType >>> ifMtu >>> ifSpeed >>> ifPhysAddress >>> ifOperStatus >>> ifLastChange >>> ifHighSpeed >>> ifConnectorPresent >>> ifCounterDiscontinuityTime >>> >>> EtherLike-MIB xstats: >>> dot3PauseOperMode >>> dot3StatsDuplexStatus >>> dot3StatsRateControlAbility >>> dot3StatsRateControlStatus >>> dot3ControlFunctionsSupported >>> >>> -updated in v2: coding style >>> >>> Signed-off-by: Piotr Azarewicz >>> Signed-off-by: Michal Jastrzebski >>> Signed-off-by: Radu Nicolau >> >> <...> >> >> This patch implements MIBs for some Intel drivers using xstats, this is >> easy way to get some information from PMDs. >> >> But there was a outstanding comment to make this ethdev layer. >> >> So I believe we have two options: >> >> [1] >> Each PMD implements MIBs using xstats, this is pragmatic solution and >> each PMD can implement whichever MIBs they want. >> >> [2] >> Implement a ethdev layer API and add a new dev_ops to get MIBs, API can >> use existing methods to get required information, and if it fails can >> call dev_ops which can be similar to the xstats. >> Because of API all PMDs can have a small amount of support by default >> and they can implement dev_ops for more support. >> >> >> Although 2) looks more generic and proper, I am not really sure if that >> is overkill and if this worth to the effort and to have new API and >> dev_ops, comparing current method is easy to implement, any comments? >> > > For 2, does the "use existing methods" include calling xstats? If so, > then we can just drop the requirement for 2 to have any new functions > implemented in the driver. Instead, have the information provided by > drivers in the normal xstats call, but have a new ethdev API to provide > that information to the app - basically hiding the xstats complexity > underneath. I was thinking another dev_ops similar to xstats, but re-using xstats can be better idea here. so option 2 becomes: [2] An eth_dev API to use existing APIs to get information from PMDs and wrap MIBs related xstats calls. But I believe if option 2 is overkill for this task question is still valid. Thanks, ferruh