From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id E0F20968 for ; Mon, 19 Jun 2017 07:14:55 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jun 2017 22:14:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,359,1493708400"; d="scan'208";a="1142600448" Received: from unknown (HELO localhost.localdomain) ([10.239.128.239]) by orsmga001.jf.intel.com with ESMTP; 18 Jun 2017 22:14:52 -0700 Date: Mon, 19 Jun 2017 13:16:03 +0800 From: Jiayu Hu To: Tiwei Bie Cc: dev@dpdk.org, konstantin.ananyev@intel.com, yliu@fridaylinux.org, keith.wiles@intel.com, jianfeng.tan@intel.com, lei.a.yao@intel.com Message-ID: <20170619051603.GA40946@localhost.localdomain> References: <1496833731-53653-1-git-send-email-jiayu.hu@intel.com> <1497770469-16661-1-git-send-email-jiayu.hu@intel.com> <1497770469-16661-2-git-send-email-jiayu.hu@intel.com> <20170619040344.GA8069@debian-ZGViaWFuCg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170619040344.GA8069@debian-ZGViaWFuCg> User-Agent: Mutt/1.7.1 (2016-10-04) Subject: Re: [dpdk-dev] [PATCH v5 1/3] lib: add Generic Receive Offload API framework 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: Mon, 19 Jun 2017 05:14:56 -0000 On Mon, Jun 19, 2017 at 12:03:44PM +0800, Tiwei Bie wrote: > On Sun, Jun 18, 2017 at 03:21:07PM +0800, Jiayu Hu wrote: > > Generic Receive Offload (GRO) is a widely used SW-based offloading > > technique to reduce per-packet processing overhead. It gains > > performance by reassembling small packets into large ones. This > > patchset is to support GRO in DPDK. To support GRO, this patch > > implements a GRO API framework. > > > > To enable more flexibility to applications, DPDK GRO is implemented as > > a user library. Applications explicitly use the GRO library to merge > > small packets into large ones. DPDK GRO provides two reassembly modes. > > One is called lightweigth mode, the other is called heavyweight mode. > > If applications want merge packets in a simple way, they can use > > lightweigth mode. If applications need more fine-grained controls, > > they can choose heavyweigth mode. > > > > rte_gro_reassemble_burst is the main reassembly API which is used in > > lightweigth mode and processes N packets at a time. For applications, > > performing GRO in lightweigth mode is simple. They just need to invoke > > rte_gro_reassemble_burst. Applications can get GROed packets as soon as > > rte_gro_reassemble_burst returns. > > > > rte_gro_reassemble is the main reassembly API which is used in > > lightweigth mode and processes one packet at a time. For applications, > > Should be heavyweight here? Sorry for typo error. It should be 'heavyweight' here. > > > performing GRO in heavyweigth mode is relatively complicated. Before > > performing GRO, applications need to create a GRO table by > > rte_gro_tbl_create. Then they can use rte_gro_reassemble to process > > packets one by one. The processed packets are in the GRO table. If > > applications want to get them, applications need to manually flush > > them by flush APIs. > > > > Few typos: > > s/lightweigth/lightweight/g > s/heavyweigth/heavyweight/g > > Besides, it's a bit confusing. Based on your comments in below mail: > > http://dpdk.org/ml/archives/dev/2017-June/068113.html > > The rte_gro_reassemble_burst() is used in heavyweight mode. But it > is inconsistent with the description in above commit message. I am so sorry for these typo errors. rte_gro_reassemble_burst is used in lightweight mode and rte_gro_reassemble is used in heavyweight mode. Thanks, Jiayu > > Best regards, > Tiwei Bie