From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: DPDK and HW offloads Date: Sun, 20 Mar 2016 20:18:57 +0100 Message-ID: <29795767.yLuRT7a5hO@xps13> References: <20160318101611.2df26ef6@xeon-e3> <10753400.05iPBPOT6f@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: "Zhang, Helin" , Stephen Hemminger Return-path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 621082BB4 for ; Sun, 20 Mar 2016 20:20:34 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id l68so86632145wml.0 for ; Sun, 20 Mar 2016 12:20:34 -0700 (PDT) In-Reply-To: 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" 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.