From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Keith" Subject: Re: [PATCH 0/2] lib: add TCP IPv4 GRO support Date: Fri, 24 Mar 2017 15:07:37 +0000 Message-ID: References: <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> <32FED22E-7116-4B6A-894E-C81CBF7B4BBE@intel.com> <20170324072230.GU18844@yliu-dev.sh.intel.com> <20170324080633.GA2865@localhost.localdomain> <2601191342CEEE43887BDE71AB9772583FAD80A6@IRSMSX109.ger.corp.intel.com> <0C56AF3E-C8AB-4903-AD34-F39C6D74C889@intel.com> <20170324155906.4b88a38d@platinum> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "Ananyev, Konstantin" , "Hu, Jiayu" , Yuanhan Liu , "Richardson, Bruce" , Stephen Hemminger , "Yigit, Ferruh" , "dev@dpdk.org" , "Liang, Cunming" , Thomas Monjalon To: Olivier Matz Return-path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id A74CCD414 for ; Fri, 24 Mar 2017 16:07:39 +0100 (CET) In-Reply-To: <20170324155906.4b88a38d@platinum> Content-Language: en-US Content-ID: <4C7DD5E4C7545B4FA49B46872D66E9E3@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > On Mar 24, 2017, at 9:59 AM, Olivier Matz wrote: >=20 > On Fri, 24 Mar 2017 14:37:04 +0000, "Wiles, Keith" wrote: >>> On Mar 24, 2017, at 6:43 AM, Ananyev, Konstantin wrote: >>>=20 >>>=20 >>>=20 >=20 > [...] >=20 >>> Yep, that's what my take from the beginning: >>> Let's develop a librte_gro first and make it successful, then we can th= ink should >>> we (and how) put into ethdev layer. =20 >>=20 >> Let not create a gro library and put the code into librte_net as size is= not a concern yet and it is the best place to put the code. As for ip_frag= someone can move it into librte_net if someone writes the patch. >=20 > The size of a library _is_ an argument. Not the binary size in bytes, but > its API, because that's what the developper sees. Today, librte_net conta= ins > protocol headers definitions and some network helpers, and the API surfac= e > is already quite big (look at the number of lines of .h files). >=20 > I really like having a library name which matches its content. > The anwser to "what can I find in librte_gro?" is quite obvious. If we are going to talk about API surface area lets talk about ethdev then = :-) Ok, lets create a new librte_gro, but I am not convinced it is reasonable. = Maybe a better generic name is needed if we are going to add GSO to the lib= rary too. So a new name for the lib is better then librte_gro, unless you a= re going to create another library for GSO. I still think the design needs to be integrated in as a real offload as I s= tated before and that is not something I am willing let drop. >=20 >=20 > Regards > Olivier Regards, Keith