From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id EDEC77CD1 for ; Tue, 22 Aug 2017 16:24:58 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP; 22 Aug 2017 07:24:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,412,1498546800"; d="scan'208";a="1208898929" Received: from dpdk15.sh.intel.com ([10.67.111.77]) by fmsmga002.fm.intel.com with ESMTP; 22 Aug 2017 07:24:55 -0700 Date: Tue, 22 Aug 2017 22:27:04 +0800 From: Jiayu Hu To: Ferruh Yigit Cc: "dev@dpdk.org" , "Ananyev, Konstantin" , "Tan, Jianfeng" , "thomas@monjalon.net" , "Wu, Jingjing" , "Yao, Lei A" Message-ID: <20170822142704.GA115653@dpdk15.sh.intel.com> References: <1502333448-75976-1-git-send-email-jiayu.hu@intel.com> <1502960892-112960-1-git-send-email-jiayu.hu@intel.com> <1502960892-112960-2-git-send-email-jiayu.hu@intel.com> <671112a6-6ac6-7476-4270-be1a0258f06e@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <671112a6-6ac6-7476-4270-be1a0258f06e@intel.com> User-Agent: Mutt/1.7.1 (2016-10-04) Subject: Re: [dpdk-dev] [PATCH v2 1/2] app/testpmd: support the heavywight mode GRO 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, 22 Aug 2017 14:24:59 -0000 Hi Ferruh, On Tue, Aug 22, 2017 at 09:30:32AM +0100, Ferruh Yigit wrote: > On 8/22/2017 2:00 AM, Hu, Jiayu wrote: > > Hi, > >> -----Original Message----- > >> From: Yigit, Ferruh > >> Sent: Monday, August 21, 2017 7:04 PM > >> To: Hu, Jiayu ; dev@dpdk.org > >> Cc: Ananyev, Konstantin ; Tan, Jianfeng > >> ; thomas@monjalon.net; Wu, Jingjing > >> ; Yao, Lei A > >> Subject: Re: [PATCH v2 1/2] app/testpmd: support the heavywight mode GRO > >> > >> On 8/17/2017 10:08 AM, Jiayu Hu wrote: > >>> The GRO library provides two reassembly modes: lightweight mode and > >>> heavyweight mode. This patch is to support the heavyweight mode in > >>> csum forwarding engine. > >>> > >>> With the command "set port gro (heavymode|lightmode) > >> (on|off)", > >>> users can select the lightweight mode or the heavyweight mode to use. > >> With > >>> the command "set gro flush interval ", users can set the interval of > >>> flushing GROed packets from reassembly tables for the heavyweight mode. > >>> With the command "show port gro", users can display GRO > >>> configuration. > >>> > >>> Signed-off-by: Jiayu Hu > >> > >> <...> > >> > >>> lcoreid_t cpuid_idx; /**< index of logical core in CPU id table */ > >>> @@ -434,13 +436,21 @@ extern struct ether_addr > >> peer_eth_addrs[RTE_MAX_ETHPORTS]; > >>> extern uint32_t burst_tx_delay_time; /**< Burst tx delay time(us) for mac- > >> retry. */ > >>> extern uint32_t burst_tx_retry_num; /**< Burst tx retry number for mac- > >> retry. */ > >>> > >>> +#define GRO_HEAVYMODE 0x1 > >>> +#define GRO_LIGHTMODE 0x2 > >> > >> Why these are not part of the gro library? > >> Is the concept "lightweight mode and heavyweight mode" part of gro > >> library or implemented only in testpmd? > > > > Lightweight mode and heavyweight mode are two reassembly methods we > > provided in the GRO library. For applications, they are just two kinds of APIs. > > Applications can select any of them to merge packets. > > GRO modes are defined in testpmd, and kept in testpmd variables, library > seems not aware of these modes. > > What are these two APIs, rte_gro_reassemble() and > rte_gro_reassemble_burst() ? > Perhaps you can detail what Lightweight mode and heavyweight mode are, > doc also don't have much about it. > > This still looks like gro library provides common API and testpmd calls > these API with different parameters and calls these lightweight and > heavyweight, if these modes are common use case, I believe they should Yes, the GRO API doesn't show the concept of 'heavyweight' and 'lightweight'. This concept is only used to describe the supported reassembly modes in the GRO library. > be part of library. If not, instead of saying different gro modes, it > can be presented as different gro usage samples in testpmd. What does "different gro usage samples" mean? Different forwarding engines? > > testpmd good for testing dpdk, and good for providing usage sample for > APIs, but I believe it shouldn't have the concepts coded in it, > libraries should have it, that is what end user uses. > > > > > In testpmd, we want to show how to use these two reassembly modes, so > > I define two macros to present them. Users can select which one to use via > > command line. > > > >> > >>> + > >>> #define GRO_DEFAULT_FLOW_NUM 4 > >>> #define GRO_DEFAULT_ITEM_NUM_PER_FLOW DEF_PKT_BURST > >>> + > >>> +#define GRO_DEFAULT_FLUSH_INTERVAL 2 > >>> +#define GRO_MAX_FLUSH_INTERVAL 4 > >>> + > >>> struct gro_status { > >>> struct rte_gro_param param; > >>> uint8_t enable; > >>> }; > >>> extern struct gro_status gro_ports[RTE_MAX_ETHPORTS]; > >>> +extern uint32_t gro_flush_interval; > >> > >> <...>