From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id B5DB72C67 for ; Sun, 20 Mar 2016 15:17:28 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 20 Mar 2016 07:17:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,366,1455004800"; d="scan'208";a="937839046" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga002.jf.intel.com with ESMTP; 20 Mar 2016 07:17:27 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 20 Mar 2016 07:17:27 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 20 Mar 2016 07:17:26 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.132]) by shsmsx102.ccr.corp.intel.com ([169.254.2.232]) with mapi id 14.03.0248.002; Sun, 20 Mar 2016 22:17:24 +0800 From: "Zhang, Helin" To: Thomas Monjalon , Stephen Hemminger CC: "dev@dpdk.org" Thread-Topic: DPDK and HW offloads Thread-Index: AQHRgTnpKX4AqVZ7fUGhVdPwiPzo3J9e94+AgANqlIA= Date: Sun, 20 Mar 2016 14:17:23 +0000 Message-ID: References: <20160318101611.2df26ef6@xeon-e3> <10753400.05iPBPOT6f@xps13> In-Reply-To: <10753400.05iPBPOT6f@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYmEwNThiMmQtZDg3Mi00OTlkLTgxNDktZDgyNWE5YTM1ZWFkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImpaMVwvaHFSSWJCOENJVVA2WWdObXRqUU1GbFlRR2lSRVhyK2xtSFdXbmhjPSJ9 x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Sun, 20 Mar 2016 14:17:29 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Saturday, March 19, 2016 2:01 AM > To: Stephen Hemminger > Cc: Zhang, Helin ; dev@dpdk.org > Subject: Re: DPDK and HW offloads >=20 > 2016-03-18 10:16, Stephen Hemminger: > > As I look at how the ethernet device interface in DPDK has exploded in > > complexity; >=20 > Yes I would like to start addressing this complexity in 16.07. >=20 > > 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. >=20 > +1 Agree that DPDK needs to add common APIs from application's point of view. >=20 > > The DPDK is doing a terrible job at providing abstractions. There > > needs to be a real generic set of operations, and every hardware offloa= d > feature must: > > * have a clear well defined API >=20 > +1 >=20 > > * if feature is not available in software, then the DPDK must provide > > a software equivalent feature. >=20 > I'm not against this idea. Looking for more opinions. >=20 > > * 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 t= he > filter/offload/ptype stuff from DPDK! >=20 > One of the biggest challenge is to think about a good filtering API. > The offloading has some interaction with the mbuf struct. >=20 > 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 generi= c APIs for common users, and others APIs for advanced users.