From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=aCaCMu6pzqHBuY/5v6afSWoh3qvxKkpAwr0W+sEeRVM=; b=vt/sLg2V3hF0SZk9dBYDyDxEmaS83IpkAUcjAwgOhb/Vgul/B5VLVQ08Uc/Em2cpOE bR9s/8+zSRBpUDxUVfEf21SuCPuecJKvTI6CXOxu6hS2hP01FUO5oNxi9kC+EEsxfYWm vAyut5/+GUITmwxBvvlr18xZ22XG6H4joVdwBAIiX7SvZUBtstyjZtqZfeVBIyvUWU2S 37UvGQdWLtZJ3RgnYIAoLET5qVbYUpcnFtyblAiM2ljySXM4ytkx5lNMDyslRzT3MB84 g3KQEVCqCfGHtB5Gzt3WYCh8RRznO6WOGDLELVHrH8IHwas26KNbe9Nx8PK4jvoMDffR iomw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=aCaCMu6pzqHBuY/5v6afSWoh3qvxKkpAwr0W+sEeRVM=; b=EBlLnFjOBZTT50mGGeXQKD8/9xLI/lW/ZtnKmlBSt0WVdC1SI5c4s6hr2QGbLl8wev eE1zYgLH238UP+YBhYS5nChOkt8f6/YVd4Ar7SISYqkLT1sp3AxW2875Crn/3EnZAv7v /5jkuvz5LKrFp6i8XNuJDuruhSdRlKaw3JhpwAX4bIPP/tswq1bTfqoPtaF+S4LnRlLh LDPx9AxutZbmnpOt+wNVL/ZuYF7B7Il2PYeCF3YCCUI9u025j8FqOrs4hN9niZWZOmoP RTbuNHpJ0+6wolFLvujNZe4GY5M6r2MHhwYEcRAAx8fbCgrPTgVJwR8jfXQFTZfaV3Ip jECQ== X-Gm-Message-State: AD7BkJKAepDqDscq1cq1qGP42vnhU5GwHttKLN0JG/LvCPqSTOo83dZ+PahzwpXEKrGzduAB X-Received: by 10.194.123.131 with SMTP id ma3mr17221352wjb.107.1458324124278; Fri, 18 Mar 2016 11:02:04 -0700 (PDT) Received: from xps13.localnet (91.111.75.86.rev.sfr.net. [86.75.111.91]) by smtp.gmail.com with ESMTPSA id av3sm13190582wjc.44.2016.03.18.11.02.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Mar 2016 11:02:03 -0700 (PDT) From: Thomas Monjalon To: Stephen Hemminger Cc: Helin Zhang , dev@dpdk.org Date: Fri, 18 Mar 2016 19:00:31 +0100 Message-ID: <10753400.05iPBPOT6f@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160318101611.2df26ef6@xeon-e3> References: <20160318101611.2df26ef6@xeon-e3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [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 18:02:04 -0000 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?