From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 01707C400 for ; Mon, 11 May 2015 12:12:31 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 11 May 2015 03:12:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,405,1427785200"; d="scan'208";a="727133566" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.220.77]) by orsmga002.jf.intel.com with SMTP; 11 May 2015 03:12:13 -0700 Received: by (sSMTP sendmail emulation); Mon, 11 May 2015 11:12:11 +0025 Date: Mon, 11 May 2015 11:12:11 +0100 From: Bruce Richardson To: "Clark, Gilbert" Message-ID: <20150511101210.GA12804@bricha3-MOBL3> References: <1431188832058.4524@ohio.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1431188832058.4524@ohio.edu> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Getting started - sanity check X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 10:12:32 -0000 On Sat, May 09, 2015 at 04:27:12PM +0000, Clark, Gilbert wrote: > > Hi folks: > > I'm brand new to DPDK.  Read about it off and on occasionally, but never had the chance to sit down and play with things until now.  It's been fun so far: just been working on a few toy applications to get myself started. > > I have run into a question, though: when calling rte_eth_tx_burst with a ring-backed PMD I've set up, the mbufs I've sent never seem to be freed.  This seems to make some degree of sense, but ... since I'm new, and because the documentation says rte_eth_tx_burst should eventually free mbufs that are sent [1], I wanted to make sure I'm on track and not just misunderstanding the way something works [2]. > > Thanks, > Gilbert Clark > > [1] From http://dpdk.org/doc/api/rte__ethdev_8h.html : > > It is the responsibility of the rte_eth_tx_burst() function to transparently free the memory buffers of packets previously sent > > [2] From lib/librte_pmd_ring.c: > > static uint16_t > eth_ring_tx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs) > { > void **ptrs = (void *)&bufs[0]; > struct ring_queue *r = q; > const uint16_t nb_tx = (uint16_t)rte_ring_enqueue_burst(r->rng, > ptrs, nb_bufs); > if (r->rng->flags & RING_F_SP_ENQ) { > r->tx_pkts.cnt += nb_tx; > r->err_pkts.cnt += nb_bufs - nb_tx; > } else { > rte_atomic64_add(&(r->tx_pkts), nb_tx); > rte_atomic64_add(&(r->err_pkts), nb_bufs - nb_tx); > } > return nb_tx; > } > > This doesn't ever appear to free a transmitted mbuf ... unless there's code to do that somewhere else that I'm missing? Indeed it doesn't free the mbufs, because this is not a PMD backed by real hardware so the packets are never actually transmitted anywhere, just passed to the other end of the ring. To behave strictly like a physical PMD, we would copy the sent packet to a new buffer on RX, and free the old one. However, in this case, we take a shortcut and just pass the same mbuf on RX as was passed on TX, which saves the cycles for buffer management. To see buffer freeing on TX occur, I suggest you look at some of the other PMDs, perhaps the e1000/igb PMD? /Bruce