From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: DPDK and HW offloads Date: Mon, 21 Mar 2016 14:52:49 +0000 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 Cc: "Zhang, Helin" , Stephen Hemminger , dev@dpdk.org To: Thomas Monjalon 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) Content-Disposition: inline In-Reply-To: <29795767.yLuRT7a5hO@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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