From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=U0llKmrd8msrg6zmPMNeaD/Fz3dO9ehT0AJst4+XcJs=; b=r2QDB5noSdaNlzwV48HCbxeoC3TNnCgZNxDojKrMHKdIP17lf2kfpGqU+ioRYFT/Np s1AjQJDxhsuatGzLQE+4y190/OafflHe7H4is2IykhEgg2xWI8HF8tlhhnvguQkebZKh 5FOzTS4LoenXXZLipHwZFqB9JGr1w2tOflKrGBRVLwxpvsYGN5CxIEt3MJ0ACtP/m9wN UyHIND5WHYUz88Yg1Kqul274m56tHV/pw3udsi6ArHY24tmHOCQ7vh+H15SZsUK1AYw8 VMWw6PNKF64+UWTuhUj7dNDWeqRKlLtEB80YyU/hrYZspuIwSuQNqR+gZgcP8cWUvZTk sWfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=U0llKmrd8msrg6zmPMNeaD/Fz3dO9ehT0AJst4+XcJs=; b=GAEHfHnET4q62d0P5GNhr7woy2X7E6FgVMa/oKv9+0y13sdfRbKqt7n8gOBpX6yp4F fWxISNJJm5ITgecNE/ASrruzra30f2iuahyNmYbu8+2o5sq/Wz4W4e3w922Z8QLfIpM8 y3wx1hzgtM38XH3iNkMrp00xA2i1gGR/63TuC3FosE0M2sLGn8QdBipwuC+w8DJMb2YJ glvt4fyHxTH9UPloIwog/1K9sDLiivJANkmhHxlKrJ1Fu+WPpx5PLBVIq+WW+lvhjqZ6 qv79Igyn6Q0rTWCpkVR26lJIhrj7ndbeTzFd2bAtOPJTHGYbT/Fyif0FWdORNd8TTEtp 4NCg== X-Gm-Message-State: AD7BkJJa5IXMd7v4PdGCQ4YtiJVGtHA+roh2POhjxjh7DUyuJuAzItsLotHLevKaOYxgUQ== X-Received: by 10.98.34.200 with SMTP id p69mr19174007pfj.114.1458321359557; Fri, 18 Mar 2016 10:15:59 -0700 (PDT) Received: from xeon-e3 (static-50-53-65-230.bvtn.or.frontiernet.net. [50.53.65.230]) by smtp.gmail.com with ESMTPSA id r203sm22322332pfr.22.2016.03.18.10.15.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Mar 2016 10:15:59 -0700 (PDT) Date: Fri, 18 Mar 2016 10:16:11 -0700 From: Stephen Hemminger To: Helin Zhang , Thomas Monjalon Cc: dev@dpdk.org Message-ID: <20160318101611.2df26ef6@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [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: Fri, 18 Mar 2016 17:16:00 -0000 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!