From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id F326E2C3F for ; Mon, 21 Mar 2016 15:53:04 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP; 21 Mar 2016 07:52:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,372,1455004800"; d="scan'208";a="70435301" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.10]) by fmsmga004.fm.intel.com with SMTP; 21 Mar 2016 07:52:50 -0700 Received: by (sSMTP sendmail emulation); Mon, 21 Mar 2016 14:52:49 +0025 Date: Mon, 21 Mar 2016 14:52:49 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: "Zhang, Helin" , Stephen Hemminger , dev@dpdk.org Message-ID: <20160321145249.GA16732@bricha3-MOBL3> References: <20160318101611.2df26ef6@xeon-e3> <10753400.05iPBPOT6f@xps13> <29795767.yLuRT7a5hO@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29795767.yLuRT7a5hO@xps13> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] DPDK and HW offloads 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: Mon, 21 Mar 2016 14:53:06 -0000 On Sun, Mar 20, 2016 at 08:18:57PM +0100, Thomas Monjalon wrote: > 2016-03-20 14:17, Zhang, Helin: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > 2016-03-18 10:16, Stephen Hemminger: > > > > Right now, all those offload features are pretty much unusable in a > > > > real product without lots and lots of extra codes and huge bug > > > > surface. It bothers me enough that I would recommend removing much of the > > > filter/offload/ptype stuff from DPDK! > > > > > > One of the biggest challenge is to think about a good filtering API. > > > The offloading has some interaction with the mbuf struct. > > > > > > I would like to suggest rewriting ethdev API by keeping it as is for some time for > > > compatibility while creating a new one. What about the prefix dpdk_netdev_ to > > > progressively replace rte_eth_dev? > > > > I totally agree with to add new and generic APIs for user applications. But I don't > > think we need to remove all current APIs. Generic APIs may not support all advanced > > hardware features, while specific APIs can. Why not support all? One generic APIs for > > common users, and others APIs for advanced users. > > Yes we cannot access to every features of a device through generic API. > Until now we were trying to add an ethdev API for every features even if it > is used by only one driver. > I think we should allow a direct access to the driver by the applications and > work on generic API only for common features. Definite +1. I think that we need to start pushing driver-specific functionality to get exposed via a driver's header files. That allow users who want to extract the max functionality from a particular NIC to do so via those APIs calls, while not polluting the generic ethdev layer. On the other hand, I don't like the idea of dpdk_netdev. I think we can work within the existing rte_eth_dev framework. /Bruce