From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 95E6FA09E4; Thu, 28 Jan 2021 10:34:39 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 449144067A; Thu, 28 Jan 2021 10:34:39 +0100 (CET) Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) by mails.dpdk.org (Postfix) with ESMTP id 7873240395; Thu, 28 Jan 2021 10:34:37 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id 9629BCF6; Thu, 28 Jan 2021 04:34:35 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 28 Jan 2021 04:34:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= lXd/H2UMj51ulZBx1W2VaCfEDggHia52h+ORyId/X6Y=; b=mdHZFQU2FRqnSsfv ca6sJG+Hxn0dPfse1hRIdmfJmAhgKdHbCSXzTk1wTs5qB/pyKoT2onmChktxmT9v wTff5kJ7xFR3yHDY7DVDI3kYcWUJ12Xd6YF/vaY5LHPHTPXVJ9QyJ99ifXjMicmw 30bAOmtfuQn0KSyNXHft6FxXgafbk4UYbfh250zEbiq/VskFyux3AVITEIh7cZN7 QC3iguDAmhAa+//guuDx1s9iiN1wc++7Q3TRJyfdn+CaQSjVcBcoLdOkCZ2hrtP1 vJMOnFIJJ1WkKjZwkh1RgBfEjEE1zLeKt3Q3yYhjjx3biZktt2nk9OX8e0c9ine5 Ff2EUg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=lXd/H2UMj51ulZBx1W2VaCfEDggHia52h+ORyId/X 6Y=; b=LWyeHsiwwEvwhS38W2tlCsd0S2kSg5CqD/5aKNx557FDskkx+qoJHWB9s bFxoaFT9XpLWwvFAf1tCa+8A2ohUDr+NF/jhWhM6YDgCPUxhDnXZidiLnwzY/fKe uoWQb1abMFptptLWDrweZGcSSHD7/3ki1+o1lHPXFZ1b9wMHKC/5h1U5CHPNFI7f /D2vRpsM4AKxPFyDk7xvv4+XLbHNJlbPuowIA/HiWVCWQbJ4dGYdUMkzRgmSpQaS CMenPBOUBlhIOZdr8A4H1W6QUrMJZ/YEFhkMXWVcvRbilohX0nMXBz4RoncwrcN/ OjOVdP82F3C1U4hhlqZ+mlPeH8Kdw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtgddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 89E6724005E; Thu, 28 Jan 2021 04:34:33 -0500 (EST) From: Thomas Monjalon To: Slava Ovsiienko Cc: Ferruh Yigit , "dev@dpdk.org" , Raslan Darawsheh , Matan Azrad , Ori Kam , Alexander Kozyrev , "stable@dpdk.org" , bluca@debian.org, kevin.traynor@redhat.com, Christian Ehrhardt Date: Thu, 28 Jan 2021 10:34:32 +0100 Message-ID: <2182238.4QQNH6NEyb@thomas> In-Reply-To: References: <1608311697-31529-1-git-send-email-viacheslavo@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v3 1/2] net/mlx5: optimize inline mbuf freeing X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 28/01/2021 10:14, Slava Ovsiienko: > From: Ferruh Yigit > > On 1/22/2021 5:12 PM, Viacheslav Ovsiienko wrote: > > > The mlx5 PMD supports packet data inlining by pushing data to the > > > transmit descriptor. If packet is short enough and all data are > > > inline, the mbuf is not needed for data send anymore and can be freed. > > > > > > The mbuf free was performed in the most inner loop building the > > > transmit descriptors. This patch postpones the mbuf free transaction > > > to the tx_burst routine exit, optimizing the loop and allowing the > > > bulk freeing for the multiple mbufs in single pool API call. > > > > > > Cc: stable@dpdk.org > > > > > > > Hi Slava, > > > > This patch is optimization for inline mbufs, right, it is not a fix, should it be > > backported? > Not critical, but nice to have this small optimization in LTS. > > > > > cc'ed LTS maintainers. > > > > I am dropping the stable to for now in the next-net, can add it later based on > > discussion result. > > OK, let's consider this backporting in dedicated way, thank you. Consensus from techboard is to reject optimizations in LTS for now. Some acceptance guidelines will be written soon. Not sure this one will be considered.