From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id BEBA16A6E for ; Tue, 28 Mar 2017 15:57:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490709471; x=1522245471; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TlNClM5QKDJfNaw2GUQN8htnpsWLUgvcKJABaB0oXjA=; b=QSPJGS7ifsTM62AyXVDC9OGsWKW6WQ+nYinROM/t3KTNzbbKYYnt1WYt TL1LdJaV0+Y2p0G45FwVLUdrCHxIiA==; Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 06:57:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,236,1486454400"; d="scan'208";a="949019045" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga003.jf.intel.com with ESMTP; 28 Mar 2017 06:57:50 -0700 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 28 Mar 2017 06:57:50 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 28 Mar 2017 06:57:49 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.212]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.253]) with mapi id 14.03.0248.002; Tue, 28 Mar 2017 21:57:47 +0800 From: "Hu, Jiayu" To: "Wiles, Keith" , Olivier Matz CC: "Ananyev, Konstantin" , Yuanhan Liu , "Richardson, Bruce" , Stephen Hemminger , "Yigit, Ferruh" , "dev@dpdk.org" , "Liang, Cunming" , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support Thread-Index: AQHSou89q+UDirHDh0a/DR3n2VARA6Gh9nLjgAAqOwCAABfzgIAAKzIggABbXACAAEHWAIAAEcwAgAAMT4CAADypAIAAMHMAgAAGKACAAAJhgIAGMOYAgACIEPA= Date: Tue, 28 Mar 2017 13:57:46 +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> <91037BB1-915A-4FFA-A839-DB474027F3CC@intel.com> In-Reply-To: <91037BB1-915A-4FFA-A839-DB474027F3CC@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] [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: Tue, 28 Mar 2017 13:57:52 -0000 > -----Original Message----- > From: Wiles, Keith > Sent: Tuesday, March 28, 2017 9:40 PM > To: Olivier Matz > Cc: Ananyev, Konstantin ; Hu, Jiayu > ; Yuanhan Liu ; > Richardson, Bruce ; Stephen Hemminger > ; Yigit, Ferruh ; > dev@dpdk.org; Liang, Cunming ; Thomas > Monjalon > Subject: Re: [dpdk-dev] [PATCH 0/2] lib: add TCP IPv4 GRO support >=20 >=20 > > On Mar 24, 2017, at 10:07 AM, Wiles, Keith wrot= e: > > > >> > >> On Mar 24, 2017, at 9:59 AM, Olivier Matz > wrote: > >> > >> On Fri, 24 Mar 2017 14:37:04 +0000, "Wiles, Keith" > wrote: > >>>> On Mar 24, 2017, at 6:43 AM, Ananyev, Konstantin > wrote: > >>>> > >>>> > >>>> > >> > >> [...] > >> > >>>> Yep, that's what my take from the beginning: > >>>> Let's develop a librte_gro first and make it successful, then we can= think > should > >>>> we (and how) put into ethdev layer. > >>> > >>> 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 so= meone > can move it into librte_net if someone writes the patch. > >> > >> 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 > contains > >> protocol headers definitions and some network helpers, and the API > surface > >> is already quite big (look at the number of lines of .h files). > >> > >> 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 t= hen :-) > > > > Ok, lets create a new librte_gro, but I am not convinced it is reasonab= le. > Maybe a better generic name is needed if we are going to add GSO to the > library too. So a new name for the lib is better then librte_gro, unless = you are > going to create another library for GSO. > > > > I still think the design needs to be integrated in as a real offload as= I stated > before and that is not something I am willing let drop. >=20 > I guess we agree to create the library librte_gro and the current code ne= eds > to be updated to be include as a real offload support to DPDK as I see no= real > conclusion to this topic. OK, I have known your opinions, and I agree with you. I will provide a real= offloading example to demonstrate the usage of librte_gro in the next patch. Thanks, Jiayu >=20 > > > >> > >> > >> Regards > >> Olivier > > > > Regards, > > Keith >=20 > Regards, > Keith