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 80ED2235 for ; Fri, 7 Jul 2017 11:19:09 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jul 2017 02:19:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,321,1496127600"; d="scan'208";a="123755459" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga005.fm.intel.com with ESMTP; 07 Jul 2017 02:19:08 -0700 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 7 Jul 2017 02:19:08 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 7 Jul 2017 02:19:07 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.116]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.197]) with mapi id 14.03.0319.002; Fri, 7 Jul 2017 17:19:06 +0800 From: "Tan, Jianfeng" To: "Tan, Jianfeng" , "Hu, Jiayu" , "dev@dpdk.org" CC: "Ananyev, Konstantin" , "yliu@fridaylinux.org" , "stephen@networkplumber.org" , "Wu, Jingjing" , "Yao, Lei A" Thread-Topic: [dpdk-dev] [PATCH v11 1/3] lib: add Generic Receive Offload API framework Thread-Index: AQHS9u4vGY4v/D3ed0Ozm44/k6z8S6JIFb6A Date: Fri, 7 Jul 2017 09:19:06 +0000 Message-ID: References: <1498907323-17563-1-git-send-email-jiayu.hu@intel.com> <1499227716-116583-1-git-send-email-jiayu.hu@intel.com> <1499227716-116583-2-git-send-email-jiayu.hu@intel.com> <6937c9d6-cae9-e7c3-f0e9-7260227a8fc0@intel.com> In-Reply-To: <6937c9d6-cae9-e7c3-f0e9-7260227a8fc0@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 v11 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: Fri, 07 Jul 2017 09:19:10 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tan, Jianfeng > Sent: Friday, July 7, 2017 2:56 PM > To: Hu, Jiayu; dev@dpdk.org > Cc: Ananyev, Konstantin; yliu@fridaylinux.org; > stephen@networkplumber.org; Wu, Jingjing; Yao, Lei A > Subject: Re: [dpdk-dev] [PATCH v11 1/3] lib: add Generic Receive Offload = API > framework >=20 >=20 >=20 > On 7/5/2017 12:08 PM, 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 lightweight mode, the other is called heavyweight mode. > > If applications want to merge packets in a simple way and the number > > of packets is relatively small, they can use the lightweight mode. > > If applications need more fine-grained controls, they can choose the > > heavyweight mode. > > > > rte_gro_reassemble_burst is the main reassembly API which is used in > > lightweight mode and processes N packets at a time. For applications, > > performing GRO in lightweight 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 > > heavyweight mode and tries to merge N inputted packets with the packets > > in GRO reassembly tables. For applications, performing GRO in > heavyweight > > mode is relatively complicated. Before performing GRO, applications nee= d > > to create a GRO context object, which keeps reassembly tables of > > desired GRO types, by rte_gro_ctrl_create. Then applications can use > > rte_gro_reassemble to merge packets. The GROed packets are in the > > reassembly tables of the GRO context object. If applications want to ge= t > > them, applications need to manually flush them by flush API. > > > > Signed-off-by: Jiayu Hu > > --- > > config/common_base | 5 + > > lib/Makefile | 2 + > > lib/librte_gro/Makefile | 50 ++++++++++ > > lib/librte_gro/rte_gro.c | 171 > ++++++++++++++++++++++++++++++++ > > lib/librte_gro/rte_gro.h | 195 > +++++++++++++++++++++++++++++++++++++ > > lib/librte_gro/rte_gro_version.map | 12 +++ > > mk/rte.app.mk | 1 + > > 7 files changed, 436 insertions(+) > > create mode 100644 lib/librte_gro/Makefile > > create mode 100644 lib/librte_gro/rte_gro.c > > create mode 100644 lib/librte_gro/rte_gro.h > > create mode 100644 lib/librte_gro/rte_gro_version.map > > > > diff --git a/config/common_base b/config/common_base > > index 660588a..19605a2 100644 > > --- a/config/common_base > > +++ b/config/common_base > > @@ -713,6 +713,11 @@ CONFIG_RTE_LIBRTE_VHOST_DEBUG=3Dn > > CONFIG_RTE_LIBRTE_PMD_VHOST=3Dn > > > > # > > +# Compile GRO library Maybe we can add experimental mark for this library as the heavy mode APIs = are still not tested. You can do by adding below line: # EXPERIMENTAL: API may change without prior notice > > +# > > +CONFIG_RTE_LIBRTE_GRO=3Dy