From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: Getting started - sanity check Date: Mon, 11 May 2015 11:12:11 +0100 Message-ID: <20150511101210.GA12804@bricha3-MOBL3> References: <1431188832058.4524@ohio.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: "Clark, Gilbert" 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) Content-Disposition: inline In-Reply-To: <1431188832058.4524@ohio.edu> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Sat, May 09, 2015 at 04:27:12PM +0000, Clark, Gilbert wrote: >=20 > Hi folks: >=20 > I'm brand new to DPDK.=A0 Read about it off and on occasionally, but ne= ver had the chance to sit down and play with things until now. =A0It's be= en fun so far: just been working on a few toy applications to get myself = started. >=20 > 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= .=A0 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 mb= ufs that are sent [1], I wanted to make sure I'm on track and not just mi= sunderstanding the way something works [2]. >=20 > Thanks, > Gilbert Clark >=20 > [1] From http://dpdk.org/doc/api/rte__ethdev_8h.html=A0: >=20 > It is the responsibility of the rte_eth_tx_burst() function to transpar= ently free the memory buffers of packets previously sent >=20 > [2] From lib/librte_pmd_ring.c: >=20 > static uint16_t > eth_ring_tx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs) > { > void **ptrs =3D (void *)&bufs[0]; > struct ring_queue *r =3D q; > const uint16_t nb_tx =3D (uint16_t)rte_ring_enqueue_burst(r->rng, > ptrs, nb_bufs); > if (r->rng->flags & RING_F_SP_ENQ) { > r->tx_pkts.cnt +=3D nb_tx; > r->err_pkts.cnt +=3D 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; > } >=20 > 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 rea= l hardware so the packets are never actually transmitted anywhere, just passed to th= e other end of the ring. To behave strictly like a physical PMD, we would copy th= e sent packet to a new buffer on RX, and free the old one.=20 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 othe= r PMDs, perhaps the e1000/igb PMD? /Bruce