From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id A79C35687 for ; Mon, 21 Nov 2016 16:25:48 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 21 Nov 2016 07:25:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,675,1473145200"; d="scan'208";a="7444939" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.64]) by orsmga002.jf.intel.com with SMTP; 21 Nov 2016 07:25:45 -0800 Received: by (sSMTP sendmail emulation); Mon, 21 Nov 2016 15:25:44 +0000 Date: Mon, 21 Nov 2016 15:25:44 +0000 From: Bruce Richardson To: Olivier Matz Cc: "Wiles, Keith" , "Damjan Marion (damarion)" , "dev@dpdk.org" Message-ID: <20161121152544.GA47052@bricha3-MOBL3.ger.corp.intel.com> References: <7E8AE555-F016-4F33-B046-A5DA86F493F3@cisco.com> <27853C4C-2482-49E0-8F60-178473276CF5@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.1 (2016-10-04) Subject: Re: [dpdk-dev] Adding API to force freeing consumed buffers in TX ring 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, 21 Nov 2016 15:25:49 -0000 On Mon, Nov 21, 2016 at 04:06:32PM +0100, Olivier Matz wrote: > Hi, > > On 11/21/2016 03:33 PM, Wiles, Keith wrote: > > > >> On Nov 21, 2016, at 4:48 AM, Damjan Marion (damarion) wrote: > >> > >> > >> Hi, > >> > >> Currently in VPP we do memcpy of whole packet when we need to do > >> replication as we cannot know if specific buffer is transmitted > >> from tx ring before we update it again (i.e. l2 header rewrite). > >> > >> Unless there is already a way to address this issue in DPDK which I’m not aware > >> of my proposal is that we provide mechanism for polling TX ring > >> for consumed buffers. This can be either completely new API or > >> extension of rte_etx_tx_burst (i.e. special case when nb_pkts=0). > >> > >> This will allows us to start polling tx ring when we expect some > >> mbuf back, instead of waiting for next tx burst (which we don’t know > >> when it will happen) and hoping that we will reach free_threshold soon. > > > > +1 > > > > In Pktgen I have the problem of not being able to reclaim all of the TX mbufs to update them for the next set of packets to send. I know this is not a common case, but I do see the case where the application needs its mbufs freed off the TX ring. Currently you need to have at least a TX ring size of mbufs on hand to make sure you can send to a TX ring. If you allocate too few you run into a deadlock case as the number of mbufs on a TX ring does not hit the flush mark. If you are sending to multiple TX rings on the same numa node from the a single TX pool you have to understand the total number of mbufs you need to have allocated to hit the TX flush on each ring. Not a clean way to handle the problems as you may have limited memory or require some logic to add more mbufs for dynamic ports. > > > > Anyway it would be great to require a way to clean up the TX done ring, using nb_pkts == 0 is the simplest way, but a new API is fine too. > >> > >> Any thoughts? > > Yes, it looks useful to have a such API. > > I would prefer another function instead of diverting the meaning of > nb_pkts. Maybe this? > > void rte_eth_tx_free_bufs(uint8_t port_id, uint16_t queue_id); > Third parameter for a limit(hint) of the number of bufs to free? If the TX ring is big, we might not want to stall other work for a long time while we free a huge number of buffers. /Bruce