From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 7E5BDC34A for ; Sat, 9 May 2015 18:41:08 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 09 May 2015 09:41:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,397,1427785200"; d="scan'208";a="723320483" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by fmsmga002.fm.intel.com with ESMTP; 09 May 2015 09:41:07 -0700 Received: from orsmsx111.amr.corp.intel.com (10.22.240.12) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sat, 9 May 2015 09:41:06 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by ORSMSX111.amr.corp.intel.com (10.22.240.12) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sat, 9 May 2015 09:41:06 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.26]) by fmsmsx111.amr.corp.intel.com ([169.254.12.169]) with mapi id 14.03.0224.002; Sat, 9 May 2015 09:41:06 -0700 From: "Wiles, Keith" To: "Clark, Gilbert" Thread-Topic: [dpdk-dev] Getting started - sanity check Thread-Index: AQHQinbxKMrie7+BgESYyLYr5gbDGA== Date: Sat, 9 May 2015 16:41:06 +0000 Message-ID: References: <1431188832058.4524@ohio.edu> In-Reply-To: <1431188832058.4524@ohio.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Sat, 09 May 2015 16:41:08 -0000 Sent from my iPhone > On May 9, 2015, at 9:27 AM, Clark, Gilbert wrote: >=20 >=20 > Hi folks: >=20 > 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 s= o 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. T= his 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 a= re sent [1], I wanted to make sure I'm on track and not just misunderstandi= ng the way something works [2]. The mbufs are free as needed or when a watermark is hit in the driver. One = other thing I found is you need to send enough packets to hit the water mar= k for the tx mbufs start to get freed. Also you have to have enough mbufs a= llocated to hit these watermarks. I just pick two times the ring size just = to be safe.=20 Hope that helps.=20 >=20 > Thanks, > Gilbert Clark >=20 > [1] From http://dpdk.org/doc/api/rte__ethdev_8h.html : >=20 > It is the responsibility of the rte_eth_tx_burst() function to transparen= tly 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 co= de to do that somewhere else that I'm missing?