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 020EB968 for ; Mon, 19 Jun 2017 06:02:18 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jun 2017 21:02:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,359,1493708400"; d="scan'208";a="99257791" Received: from debian-zgviawfucg.sh.intel.com (HELO debian-ZGViaWFuCg) ([10.239.67.43]) by orsmga004.jf.intel.com with ESMTP; 18 Jun 2017 21:02:16 -0700 Date: Mon, 19 Jun 2017 12:03:44 +0800 From: Tiwei Bie To: Jiayu Hu 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: <20170619040344.GA8069@debian-ZGViaWFuCg> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1497770469-16661-2-git-send-email-jiayu.hu@intel.com> User-Agent: Mutt/1.7.2 (2016-11-26) 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 04:02:19 -0000 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? > 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. Best regards, Tiwei Bie