From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com [209.85.128.178]) by dpdk.org (Postfix) with ESMTP id C3C8D2A5B for ; Thu, 23 Mar 2017 11:41:16 +0100 (CET) Received: by mail-wr0-f178.google.com with SMTP id l37so144530986wrc.1 for ; Thu, 23 Mar 2017 03:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=HAW/9wBj36MJ4/ZMIZ46wn4ki8TGt2PIylHpR4BaIMk=; b=dqKbw7nmCsOahhPqCub9He7Kfxgymcgd1WLwfxHBq/5Z3zF429/kgHWD/LZ8fYiNcf hNFiPifBGh701zBP5VFw40e7IgfFtQhAbZVzR2IIogspb8qbqWurCsxIjxG5LnOV0Mct W0PY8csqpFdt69/Idwe7ybSOCbhLmQFi/Gs0+PWc/Ya/XuWjCicbxhfgu4zVZHt4EUTE mRgtrUclv6Xsw/VbIaMKqRRuaTJvM/NSUK4o/k5t9EdYHIPBbXQpAcFzvBTSPu9Y7D5f ow0LDsYPfqY61O0bxxSPfCzFAfhYk7ZRV0EUxh4F0tCMPBQZwlCJ+YmEaqwZmO0K4Z8K SMGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=HAW/9wBj36MJ4/ZMIZ46wn4ki8TGt2PIylHpR4BaIMk=; b=VEoWCY1doTIWpJ2vyzt9fV6tSgoQgH4nDPZickEM65OWoSR3ZUzkw2ZnB/KAW8ZwtT dTOS/cMwvi5Gg3vk2eU4r/MUnJVovlYpzBCRiuZbzZjSw+EDl8/kV8x83wN7YfyjgvTA 0H8mToXCPBDzuOn9Y2b4iy7XLvzcGPJl1diJXvbyDfZap4OsHV0NLlSYzM9ELh6m9c0Z n2VIRKHwUw0RDV5Cw4qpK8NNZIZYG+MG/BbrCB/Gqh9l77COESDCuUAGWrwBcyP3N+zf 76d6ATAAatxL1zKKPLIPlWUwt9AbjrPfs2OJSn7iTBOuQuqaA3wt/eqk6xfITzh43yqd L68w== X-Gm-Message-State: AFeK/H1Z9ewUL0bmq/83zvgmrs7YEp9uRE+Xq8zXBfLs7elxh7Z/usYIwt01Luo/VI1G3Sdm X-Received: by 10.223.150.123 with SMTP id c56mr1805323wra.202.1490265676453; Thu, 23 Mar 2017 03:41:16 -0700 (PDT) Received: from glumotte.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id e129sm3846449wma.13.2017.03.23.03.41.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 23 Mar 2017 03:41:16 -0700 (PDT) Date: Thu, 23 Mar 2017 11:37:16 +0100 From: Olivier MATZ To: Billy McFall Cc: thomas.monjalon@6wind.com, wenzhuo.lu@intel.com, dev@dpdk.org Message-ID: <20170323113716.57e27591@glumotte.dev.6wind.com> In-Reply-To: <20170315180226.5999-2-bmcfall@redhat.com> References: <20170309205119.28170-1-bmcfall@redhat.com> <20170315180226.5999-1-bmcfall@redhat.com> <20170315180226.5999-2-bmcfall@redhat.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v7 1/3] ethdev: new API to free consumed buffers in Tx ring X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 10:41:16 -0000 Hi Billy, On Wed, 15 Mar 2017 14:02:24 -0400, Billy McFall wrote: > Add a new API to force free consumed buffers on Tx ring. API will return > the number of packets freed (0-n) or error code if feature not supported > (-ENOTSUP) or input invalid (-ENODEV). > > Signed-off-by: Billy McFall > --- > doc/guides/conf.py | 7 +++++-- > doc/guides/nics/features/default.ini | 4 +++- > doc/guides/prog_guide/poll_mode_drv.rst | 28 ++++++++++++++++++++++++++++ > doc/guides/rel_notes/release_17_05.rst | 7 ++++++- > lib/librte_ether/rte_ethdev.c | 14 ++++++++++++++ > lib/librte_ether/rte_ethdev.h | 31 +++++++++++++++++++++++++++++++ > 6 files changed, 87 insertions(+), 4 deletions(-) > [...] > --- a/doc/guides/prog_guide/poll_mode_drv.rst > +++ b/doc/guides/prog_guide/poll_mode_drv.rst > @@ -249,6 +249,34 @@ One descriptor in the TX ring is used as a sentinel to avoid a hardware race con > > When configuring for DCB operation, at port initialization, both the number of transmit queues and the number of receive queues must be set to 128. > > +Free Tx mbuf on Demand > +~~~~~~~~~~~~~~~~~~~~~~ > + > +Many of the drivers don't release the mbuf back to the mempool, or local cache, immediately after the packet has been > +transmitted. > +Instead, they leave the mbuf in their Tx ring and either perform a bulk release when the ``tx_rs_thresh`` has been > +crossed or free the mbuf when a slot in the Tx ring is needed. > + > +An application can request the driver to release used mbufs with the ``rte_eth_tx_done_cleanup()`` API. > +This API requests the driver to release mbufs that are no longer in use, independent of whether or not the > +``tx_rs_thresh`` has been crossed. > +There are two scenarios when an application may want the mbuf released immediately: > + > +* When a given packet needs to be sent to multiple destination interfaces (either for Layer 2 flooding or Layer 3 > + multi-cast). > + One option is to make a copy of the packet or a copy of the header portion that needs to be manipulated. > + A second option is to transmit the packet and then poll the ``rte_eth_tx_done_cleanup()`` API until the reference > + count on the packet is decremented. > + Then the same packet can be transmitted to the next destination interface. By reading this paragraph, it's not so clear to me that the packet that will be transmitted on all interfaces will be different from one port to another. Maybe it could be reworded to insist on that? > + > +* If an application is designed to make multiple runs, like a packet generator, and one run has completed. > + The application may want to reset to a clean state. I'd reword into: Some applications are designed to make multiple runs, like a packet generator. Between each run, the application may want to reset to a clean state. What do you mean by "clean state"? All mbufs returned into the mempools? Why would a packet generator need that? For performance? Also, do we want to ensure that all packets are actually transmitted? Can we do that with this API or should we use another API like rte_eth_tx_descriptor_status() [1] ? [1] http://dpdk.org/dev/patchwork/patch/21549/ Thanks, Olivier