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 7F5412B84 for ; Fri, 30 Jun 2017 04:08:41 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 19:08:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,284,1496127600"; d="scan'208";a="280424972" Received: from jiayu-has.sh.intel.com (HELO jiayu-Has) ([10.239.67.36]) by fmsmga004.fm.intel.com with ESMTP; 29 Jun 2017 19:08:38 -0700 Date: Fri, 30 Jun 2017 10:07:25 +0800 From: Jiayu Hu To: Stephen Hemminger Cc: dev@dpdk.org, konstantin.ananyev@intel.com, jianfeng.tan@intel.com, yliu@fridaylinux.org, jingjing.wu@intel.com, tiwei.bie@intel.com, lei.a.yao@intel.com Message-ID: <20170630020725.GA13512@jiayu-Has> References: <1498459430-116048-1-git-send-email-jiayu.hu@intel.com> <1498733940-117800-1-git-send-email-jiayu.hu@intel.com> <1498733940-117800-3-git-send-email-jiayu.hu@intel.com> <20170629105150.74b8bf88@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170629105150.74b8bf88@xeon-e3> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v8 2/3] lib/gro: add TCP/IPv4 GRO support 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, 30 Jun 2017 02:08:42 -0000 Hi Stephen, On Thu, Jun 29, 2017 at 10:51:50AM -0700, Stephen Hemminger wrote: > On Thu, 29 Jun 2017 18:58:59 +0800 > Jiayu Hu wrote: > > > + /* allocate a reassembly table for TCP/IPv4 GRO */ > > + uint32_t tcp_item_num = RTE_MIN(item_num, > > + RTE_GRO_MAX_BURST_ITEM_NUM); > > + struct gro_tcp_tbl tcp_tbl; > > + struct gro_tcp_key tcp_keys[tcp_item_num]; > > + struct gro_tcp_item tcp_items[tcp_item_num]; > > Variable size structures on stack were not supported by > CLANG, last time I checked. Why not always max size? The reason why I try to use the min value is to reduce the overhead of array initialization. But I ignore the clang issue. Thanks for your reminder. I will replace it with the max value. > > > + > > + struct rte_mbuf *unprocess_pkts[nb_pkts]; > > + uint16_t unprocess_num = 0; > > + int32_t ret; > > + uint64_t current_time; > > + > > + if ((param->desired_gro_types & RTE_GRO_TCP_IPV4) == 0) > > + return nb_pkts; > > + > > + memset(tcp_keys, 0, sizeof(struct gro_tcp_key) * > > + tcp_item_num); > > + memset(tcp_items, 0, sizeof(struct gro_tcp_item) * > > + tcp_item_num); > > Variable size memset's are slow. They generate 'rep; stoz' last > I checked in GCC and because of rep instruction it kills multi-execution > pipeline. Thanks, I will modify it. BRs, Jiayu