From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] net/enic: revert support for mbuf fast free offload Date: Thu, 02 Aug 2018 10:26:54 +0200 Message-ID: <1580713.dMrMSxmPF2@xps> References: <20180726023028.23394-1-johndale@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, ferruh.yigit@intel.com To: John Daley , Hyong Youb Kim Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id BB7581B44D for ; Thu, 2 Aug 2018 10:27:00 +0200 (CEST) In-Reply-To: <20180726023028.23394-1-johndale@cisco.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 26/07/2018 04:30, John Daley: > From: Hyong Youb Kim > > This reverts the patch that enabled mbuf fast free. > > There are two main reasons. > > First, enic_fast_free_wq_bufs is broken. When > DEV_TX_OFFLOAD_MBUF_FAST_FREE is enabled, the driver calls this > function to free transmitted mbufs. This function currently does not > reset next and nb_segs. This is simply wrong as the fast-free flag > does not imply anything about next and nb_segs. > > We could fix enic_fast_free_wq_bufs by making it to call > rte_pktmbuf_prefree_seg to reset the required fields. But, it negates > most of cycle saving. > > Second, there are customer applications that blindly enable all Tx > offloads supported by the device. Some of these applications do not > satisfy the requirements of mbuf fast free (i.e. a single pool per > queue and refcnt = 1), and end up crashing or behaving badly. > > Fixes: bcaa54c1a148 ("net/enic: support mbuf fast free offload") > > Signed-off-by: Hyong Youb Kim > Reviewed-by: John Daley Applied