From mboxrd@z Thu Jan  1 00:00:00 1970
From: Yuanhan Liu <yliu@fridaylinux.org>
Subject: Re: [PATCH v10 1/3] lib: add Generic Receive Offload API
	framework
Date: Tue, 4 Jul 2017 16:11:55 +0800
Message-ID: <20170704081155.GJ11626@yliu-home>
References: <1498805618-63649-1-git-send-email-jiayu.hu@intel.com>
 <1498907323-17563-1-git-send-email-jiayu.hu@intel.com>
 <1498907323-17563-2-git-send-email-jiayu.hu@intel.com>
 <9ccb015f-c635-3080-f732-6412998aacca@intel.com>
 <ED946F0BEFE0A141B63BABBD629A2A9B3876F07F@shsmsx102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "Tan, Jianfeng" <jianfeng.tan@intel.com>, "dev@dpdk.org" <dev@dpdk.org>,
 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 "stephen@networkplumber.org" <stephen@networkplumber.org>,
 "Wu, Jingjing" <jingjing.wu@intel.com>, "Yao, Lei A" <lei.a.yao@intel.com>,
 "Bie, Tiwei" <tiwei.bie@intel.com>
To: "Hu, Jiayu" <jiayu.hu@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pg0-f43.google.com (mail-pg0-f43.google.com [74.125.83.43])
 by dpdk.org (Postfix) with ESMTP id E7C0E2A58
 for <dev@dpdk.org>; Tue,  4 Jul 2017 10:12:03 +0200 (CEST)
Received: by mail-pg0-f43.google.com with SMTP id j186so106650446pge.2
 for <dev@dpdk.org>; Tue, 04 Jul 2017 01:12:03 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <ED946F0BEFE0A141B63BABBD629A2A9B3876F07F@shsmsx102.ccr.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Mon, Jul 03, 2017 at 05:56:20AM +0000, Hu, Jiayu wrote:
> > > +/**
> > > + * GRO table, which is used to merge packets. It keeps many reassembly
> > > + * tables of desired GRO types. Applications need to create GRO tables
> > > + * before using rte_gro_reassemble to perform GRO.
> > > + */
> > > +struct gro_tbl {
> > > +	uint64_t desired_gro_types;	/**< GRO types to perform */
> > > +	/* max TTL measured in nanosecond */
> > > +	uint64_t max_timeout_cycles;
> > > +	/* max length of merged packet measured in byte */
> > > +	uint32_t max_packet_size;
> > > +	/* reassebly tables of desired GRO types */
> > > +	void *tbls[RTE_GRO_TYPE_MAX_NUM];
> > > +};
> > > +
> > > +void *rte_gro_tbl_create(const
> > > +		const struct rte_gro_param *param)
> > 
> > The name of this API and the definition of struct gro_tbl involve some
> > confusion. A gro table contains gro tables? I suppose a better name is
> > needed, for example, struct gro_ctl.
> 
> Actually, a GRO table includes N reassembly tables. But gro_tbl is not a good
> name. I will change the name. Thanks.

Haven't looked at the details yet, but, probably, gro_ctx (context) is a better
and more typical name?

	--yliu