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 3FF01A0C40 for ; Tue, 22 Jun 2021 22:46:28 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2E4B140687; Tue, 22 Jun 2021 22:46:28 +0200 (CEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by mails.dpdk.org (Postfix) with ESMTP id 0FC384003E; Tue, 22 Jun 2021 22:46:25 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id DD278D50; Tue, 22 Jun 2021 16:46:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 22 Jun 2021 16:46:21 -0400 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=fm1; bh= gL4B2Qisbo2DoRQH8bFGBFnsUKNSHAwHXBJe3M7LhWA=; b=WfyquymIGB7Gg8Gt hP5AruchCvOqGlvCYebWYvJ8xYLahdpUEcfwfrygz5VEXuioVEDuqRwKqCEZs2Ha Jr9ch2f1hYwKX+uPAWg5rvXpSruQR6qxCvB8FM6RK+P0TpRUaXdhsFvZzjKAcfA6 Jrt6CFoyzfk8F/1i7q/NWOHScuxPMwnTO0aQY6+5UNsd/R9aq9gfeIVWmiRy65to 0TvL9AqITwQ8dl47YquCfFbzriKSBFkIwCGFJ3n6UiGtmmqaS4RYS7dBwDhiIdTp 3Y8hPsDApvc7xv2btDGrRmnFKQhFsaRww1Yc8HHDtViJHyY8I2gZFSeZzhUfaMhu mvywxw== 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=fm3; bh=gL4B2Qisbo2DoRQH8bFGBFnsUKNSHAwHXBJe3M7Lh WA=; b=mHPp7mqkffIqlfMCxSY9ZZ2vSjWrahQdMvWaZoqwb9bJ2/IrJaMYQXSJY Z2qlEq/d1gKlnIwXnrHfbavwxaN2++uVQhbphS5LPCKCCZ6dxbJnAwoIsavBE6LR V5i4pSp5vQ3MdI2dAqMA6xgPxI2jmH1TbyGYDj108ukbXDSVqwcgH8D13qE58HPK 8bYQsCX7tyZj5GWPrYHbr7MWGge4xNvqmOnZT6KaSxISHQ1ovclSq3p6jmY15Jjv F88uItTJHZ0j1qRDn2EADk0bHVhArl45zn7AWZHwmbYAcyKLJdp+QJ3y+wQNxHTK IYCSf8hE3qpa2oyZey/CpWP69607w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeeguddgudehvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Jun 2021 16:46:19 -0400 (EDT) From: Thomas Monjalon To: Yunjian Wang , Cheng Liu Cc: dev@dpdk.org, stable@dpdk.org, ferruh.yigit@intel.com, gowrishankar.m@linux.vnet.ibm.com, dingxiaoxiong@huawei.com, wangyunjian Date: Tue, 22 Jun 2021 22:46:17 +0200 Message-ID: <3564511.TeOt0uO2Lr@thomas> In-Reply-To: <1624365869-31872-1-git-send-email-wangyunjian@huawei.com> References: <4aebf99afe5bae2b25f2e5445a32243ffd6f7e97.1624359204.git.wangyunjian@huawei.com> <1624365869-31872-1-git-send-email-wangyunjian@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3] kni: fix mbuf allocation for alloc FIFO X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 22/06/2021 14:44, wangyunjian: > From: Yunjian Wang > > In kni_allocate_mbufs(), we alloc mbuf for alloc_q as this code. > allocq_free = (kni->alloc_q->read - kni->alloc_q->write - 1) \ > & (MAX_MBUF_BURST_NUM - 1); > The value of allocq_free maybe zero, for example : > The ring size is 1024. After init, write = read = 0. Then we fill > kni->alloc_q to full. At this time, write = 1023, read = 0. > > Then the kernel send 32 packets to userspace. At this time, write > = 1023, read = 32. And then the userspace receive this 32 packets. > Then fill the kni->alloc_q, (32 - 1023 - 1) & 31 = 0, fill nothing. > ... > Then the kernel send 32 packets to userspace. At this time, write > = 1023, read = 992. And then the userspace receive this 32 packets. > Then fill the kni->alloc_q, (992 - 1023 - 1) & 31 = 0, fill nothing. > > Then the kernel send 32 packets to userspace. The kni->alloc_q only > has 31 mbufs and will drop one packet. > > Absolutely, this is a special scene. Normally, it will fill some > mbufs everytime, but may not enough for the kernel to use. > > In this patch, we always keep the kni->alloc_q to full for the kernel > to use. > > Fixes: 49da4e82cf94 ("kni: allocate no more mbuf than empty slots in queue") > Cc: stable@dpdk.org > > Signed-off-by: Cheng Liu > Signed-off-by: Yunjian Wang > Acked-by: Ferruh Yigit > --- > v3: > update patch title > v2: > add fixes tag and update commit log > --- > lib/kni/rte_kni.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/lib/kni/rte_kni.c b/lib/kni/rte_kni.c > index 9dae6a8d7c..eb24b0d0ae 100644 > --- a/lib/kni/rte_kni.c > +++ b/lib/kni/rte_kni.c > @@ -677,8 +677,9 @@ kni_allocate_mbufs(struct rte_kni *kni) > return; > } > > - allocq_free = (kni->alloc_q->read - kni->alloc_q->write - 1) > - & (MAX_MBUF_BURST_NUM - 1); > + allocq_free = kni_fifo_free_count(kni->alloc_q); Can we insert a comment here to explain the logic? > + allocq_free = (allocq_free > MAX_MBUF_BURST_NUM) ? > + MAX_MBUF_BURST_NUM : allocq_free; > for (i = 0; i < allocq_free; i++) { > pkts[i] = rte_pktmbuf_alloc(kni->pktmbuf_pool); > if (unlikely(pkts[i] == NULL)) { About the title, I don't understand the part "for alloc FIFO", given all mbufs are in a FIFO queue in KNI, right?