From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: DPDK and HW offloads Date: Fri, 18 Mar 2016 10:16:11 -0700 Message-ID: <20160318101611.2df26ef6@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Helin Zhang , Thomas Monjalon Return-path: Received: from mail-pf0-f170.google.com (mail-pf0-f170.google.com [209.85.192.170]) by dpdk.org (Postfix) with ESMTP id 273DB2C6E for ; Fri, 18 Mar 2016 18:16:00 +0100 (CET) Received: by mail-pf0-f170.google.com with SMTP id x3so175905759pfb.1 for ; Fri, 18 Mar 2016 10:16:00 -0700 (PDT) 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" As I look at how the ethernet device interface in DPDK has exploded in complexity; 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. 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 * if feature is not available in software, then the DPDK must provide a software equivalent feature. * 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!