From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id DACC21B28D for ; Fri, 6 Oct 2017 10:54:07 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Oct 2017 01:54:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,482,1500966000"; d="scan'208";a="1202914524" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.37]) by fmsmga001.fm.intel.com with SMTP; 06 Oct 2017 01:54:05 -0700 Received: by (sSMTP sendmail emulation); Fri, 06 Oct 2017 09:54:04 +0100 Date: Fri, 6 Oct 2017 09:54:04 +0100 From: Bruce Richardson To: Roger B Melton Cc: jingjing.wu@intel.com, dev@dpdk.org Message-ID: <20171006085403.GA24124@bricha3-MOBL3.ger.corp.intel.com> References: <20171005191111.27557-1-rmelton@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171005191111.27557-1-rmelton@cisco.com> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.8.3 (2017-05-23) Subject: Re: [dpdk-dev] [PATCH] net/i40e: Improve i40evf buffer cleanup in tx vector mode 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, 06 Oct 2017 08:54:08 -0000 On Thu, Oct 05, 2017 at 03:11:11PM -0400, Roger B Melton wrote: > --- > > i40evf tx vector logic frees mbufs, but it does not remove the > mbufs from software rings which leads to double frees. This change > corrects that oversight. We've validated this fix within our application. > Hi Roger, I'm a little concerned here by this driver fix, since if we are getting double frees of mbufs there must be another bug somewhere in tracking the free ring elements. Clearing the entries to NULL introduces extra writes to the vector code path which will likely have a performance impact, but also should be unnecessary, given proper tracking of the ring status. Can you provide us with some details as to how to reproduce the issue, especially with a public sample app? I'd really like to look more into why this is happening, and if other fixes may work. Thanks, /Bruce