From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: DPDK and HW offloads Date: Fri, 18 Mar 2016 19:00:31 +0100 Message-ID: <10753400.05iPBPOT6f@xps13> References: <20160318101611.2df26ef6@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Helin Zhang , dev@dpdk.org To: Stephen Hemminger Return-path: Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id 78B205586 for ; Fri, 18 Mar 2016 19:02:04 +0100 (CET) Received: by mail-wm0-f48.google.com with SMTP id l68so79431374wml.0 for ; Fri, 18 Mar 2016 11:02:04 -0700 (PDT) In-Reply-To: <20160318101611.2df26ef6@xeon-e3> 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-18 10:16, Stephen Hemminger: > As I look at how the ethernet device interface in DPDK has exploded in complexity; Yes I would like to start addressing this complexity in 16.07. > it makes life very hard for end users. The goal has been to enable all the cool hardware > features, but it has put blinders on the driver devlopers; they are ignoring the fact > that real applications can't just work on one kind of hardware. +1 > The DPDK is doing a terrible job at providing abstractions. There needs to be a > real generic set of operations, and every hardware offload feature must: > * have a clear well defined API +1 > * if feature is not available in software, then the DPDK must provide > a software equivalent feature. I'm not against this idea. Looking for more opinions. > * any difference in API must be hidden from application. > * no compile config options about offload. > * tests and documentation must work for both hw and sw version > > 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?