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 4D01ED003 for ; Fri, 24 Mar 2017 07:18:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490336331; x=1521872331; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2SDZ83B5xjZdKKGcY5o60FNapg4dV3d9Pnr0h8yqXn0=; b=iBgqroSHcOgxtXsckJdVlvY4aiot2pr45h1SUkSmw1G9xwRHhCd34uFv OwbYGHcsT5LKY2ZM7DzJR/cZrnCqBw==; Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2017 23:18:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,213,1486454400"; d="scan'208";a="78874350" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga005.jf.intel.com with ESMTP; 23 Mar 2017 23:18:49 -0700 Received: from fmsmsx126.amr.corp.intel.com (10.18.125.43) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 23 Mar 2017 23:18:49 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.235]) by FMSMSX126.amr.corp.intel.com ([169.254.1.127]) with mapi id 14.03.0319.002; Thu, 23 Mar 2017 23:18:49 -0700 From: "Wiles, Keith" To: "Hu, Jiayu" CC: "Ananyev, Konstantin" , "Richardson, Bruce" , Stephen Hemminger , Yuanhan Liu , "Yigit, Ferruh" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support Thread-Index: AQHSou9HGbI2XQXRT0SMpTSJ0l69vaGhXiuAgADH34CAADY2gIAAD3+AgAAqRwCAABfzgIAAL+AAgADcygCAAEHVgA== Date: Fri, 24 Mar 2017 06:18:48 +0000 Message-ID: <32FED22E-7116-4B6A-894E-C81CBF7B4BBE@intel.com> References: <1490175137-108413-1-git-send-email-jiayu.hu@intel.com> <1B893F1B-4DA8-4F88-9583-8C0BAA570832@intel.com> <20170323021502.GA114662@localhost.localdomain> <20170323062433.GA120139@localhost.localdomain> <59AF69C657FD0841A61C55336867B5B066729E3F@IRSMSX103.ger.corp.intel.com> <20170323102135.GA124301@localhost.localdomain> <2601191342CEEE43887BDE71AB9772583FAD410A@IRSMSX109.ger.corp.intel.com> <20170324022310.GA129105@localhost.localdomain> In-Reply-To: <20170324022310.GA129105@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.84.105] Content-Type: text/plain; charset="us-ascii" Content-ID: <780903B4B3E1F4429FDDD74C06EEE46E@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 06:18:51 -0000 > On Mar 23, 2017, at 9:23 PM, Hu, Jiayu wrote: >=20 > On Thu, Mar 23, 2017 at 09:12:56PM +0800, Ananyev, Konstantin wrote: >> Hi everyone, >>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Hu, Jiayu >>>>> Sent: Thursday, March 23, 2017 6:25 AM >>>>> To: Wiles, Keith >>>>> Cc: Yuanhan Liu ; Richardson, Bruce >>>>> ; Yigit, Ferruh ; >>>>> Ananyev, Konstantin >>>>> Subject: Re: [dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support >>>>>=20 >>>>> On Thu, Mar 23, 2017 at 01:29:06PM +0800, Wiles, Keith wrote: >>>>>>=20 >>>>>>> On Mar 22, 2017, at 9:15 PM, Hu, Jiayu wrote: >>>>>>>=20 >>>>>>> On Wed, Mar 22, 2017 at 10:19:41PM +0800, Wiles, Keith wrote: >>>>>>>> Off list. >>>>>>>>=20 >>>>>>>> This support for GRO, seems it needs to be a feature for all ether= net >>>>> devices and some way the developer can enable this feature like the o= ther >>>>> offloads in DPDK. The GRO support should be set by the developer and = then >>>>> the apis are called within ethdev or the PMD to process the packets. = The >>>>> code is generic and creating a library is not the best overall soluti= on >>>>> IMO. >>>>>>>=20 >>>>>>> Indeed, in this patchset, GRO is just proposed as a application-use= d >>>>> library. >>>>>>> But actually, these GRO APIs can also be used by ethdev and PMD. Fo= r >>>>>>> example, register rte_gro_tcp4_reassemble_burst as a rx callback. >>>>>>> Therefore, maybe we can support GRO in two ways. The one is a >>>>>>> application-used library, the other is a device feature. Applicatio= ns >>>>> decide which one to use. >>>>>>>=20 >>>>>>> How do you think of it? >>>>>>=20 >>>>>> I would prefer to use it only in a offload design, meaning the GRO i= s >>>>> just another ethernet offload the user can turn on. Using something l= ike a >>>>> RX callback to handle the GRO for the developer. This way he just tur= ns it >>>>> on in via a ethdev offload support feature and then setup the RX call= back >>>>> via ethdev. The developer only needs to enable the feature and never = calls >>>>> GRO APIs. >>>>>=20 >>>>> The advantage of providing an application-used GRO library can enable= more >>>>> flexibility to applications. Applications can flexibly use GRO functi= ons >>>>> according to own realistic scenario. Therefore, I think it makes sens= e to >>>>> provide an application-used GRO library. >>>>>>=20 >>>>>> Adding a new GRO library may not get much support and having a whole >>>>> library for GRO seems a bit odd. >>>>>=20 >>>>> In my opinion, we just need to provide one GRO library. But it can be= used >>>>> by ethernet devices and applications at the same time. Ethernet devic= es >>>>> use it to provide an offload feature. If applications want more >>>>> flexibility, they can just turn off this device feature, and use GRO = APIs >>>>> directly. >>>>>=20 >>>>> +Konstantin >>>>>=20 >>>>=20 >>>> [Apologies for the basic questions, I haven't studied the patchset in = detail] >>>> Rather than adding a whole new library for it, can it just fit into li= brte_net or an existing lib? Are we planning a sample to show off >>> tighter integration with ethdev or changes to the ethdev library to tra= nsparently use the library when needed? >>>=20 >>> Currently, we have an individual library, librte_ip_frag, which provide= s IP fragment >>> and ressembly abilities. Similiarly, DPDK GRO will provide reassembly a= bility for >>> various of protocols, not only TCP. So I think it's good to make a new = library for >>> this feature. >>>=20 >>> About GRO, we had a discussion two monthes ago. You can see it in >>> http://dpdk.org/ml/archives/dev/2017-January/056276.html >>> In that discussion, we agree to support GRO in two steps. The first is = to implement >>> GRO as a standalone library, and see how much performance we can get. T= he second >>> step is to discuss how to integrate GRO into DPDK. Therefore, if we agr= ee to support >>> GRO as a device feature, we need to discuss how to enable/disable this = device feature. >>> Once we reach an agreement, there will be a sample to demonstrate the i= ntegration. >>=20 >> I think that having a separate library for GRO is a step in a right dire= ction. >>> From my perspective - it provides a clean and flexible way to use that = feature. >> If later someone would like to put GRO into ethdev layer (or particular = PMD), >> he can use existing librte_gro for that. >=20 > Agree. I think introducing more flexibility is an important thing for app= lications. Creating a new library just for GRO is not a reasonable solution, but addin= g that support to an existing library like librte_net would be cleaner and = not create yet another library. Creating more flexibility is not the best goal as we really want to make GR= O easy and simple for the developer to use for any device without having to= change his applications to take advantage of the feature. Some times provi= ding more flexibility just means making it more complexed and more APIs the= developer needs to understand. Providing GRO as a offload feature is the b= etter direction as it makes it simple for an application to use. If we provide GRO as a standard offload similar to the other offloads we cu= rrently have makes it easy for the developer. The best goal for a feature i= s the best performance for the application without having the application m= ake even more APIs calls along with simple and easy to use. >=20 >> I didn't have a closer look yet, but I think that caught my attention: >> API fir the lib seems too IPv4/TCP oriented - >> though I understand that the most common case and should be implemented = first. >> I wonder can we have it a bit more generic and extendable, so user can s= pecify what combination of protocols >> he is interested in (let say: ipv4/tcp, ipv6/tcp, etc.). >> Even if right now we'll have it implemented only for ipv4/tcp. >> Then internally we can have some check is that supported or not and if y= es setup things accordingly. >=20 > Indeed, current apis are too specific. It's not very friendly to applicat= ions. > Maybe we can use macro to define the combination of protocols, like GRO_T= CP_IPV4 > and GRO_UDP_IPV6; and provide a generic setup function and reassembly fun= ction. > Both of them perform different operations according to the macro value in= putted > by the application. >=20 >> BTW, that's for 17.08, right? >=20 > Yes, it's for 17.08. >=20 > Jiayu >>=20 >> Konstantin >>=20 >>=20 Regards, Keith