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 1D660A0C41; Thu, 24 Jun 2021 09:43:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0853F4115F; Thu, 24 Jun 2021 09:43:16 +0200 (CEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by mails.dpdk.org (Postfix) with ESMTP id E041E4003C; Thu, 24 Jun 2021 09:43:13 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 3B8233200708; Thu, 24 Jun 2021 03:43:12 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 24 Jun 2021 03:43:13 -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= lccksH1KUpJxphbw7z03Oezm0jqkYVC0lipK5SbATBI=; b=5XzZJ5rtQe7yE+QS zjOlJ0UwZiKP0DIYvpt+2QEZGjHiA5giEq8y8IGWu/KAmo9sadJ8a8UOpFH7JkU/ 2iCwabFStoZPhsT2aSkO9hn2SYkMbGHXXNZlneuE23RuTq0kmNBXrEAxfox7N86s dlkOr5zKlPbep4Wg6aOsEFl/9/MwNuHp84/Q2dNPa2pD7i2uM9vAqi2miTgH8+c0 v8609tfOe81vhGZJUsBqkkjrGrmlTS6PH77HXfzjS3s5AbfOWUlJG26WGunu1Yqd jp03mxO+qgXPdQcl/zZ3lJ1MB0NoBB7vdvLG711CBii+RNY/GTxF3dOG0iRqp5aV mSM7Mw== 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=lccksH1KUpJxphbw7z03Oezm0jqkYVC0lipK5SbAT BI=; b=qYbz2CMO/mR8EF+E1nbLIPSmgga4nwUuYRXtkHJ8fIwwAZ7eNFWnIlG+4 wi5IbqClz4lQ7HQ3t/calz4A6L5dRRbbgmHw+3uocSpQesxkMPfSLzFBEdIq7g4R b8my28fwVI1MGFuG3hH8Fm9lHdsrTRuXvtw05boUDf/+uRhLKAYmr8YXREprO8cc T6mgyC0wOiImEf26L3a+w5fDV3K6P/HOEBLTOhVea4brmdZYxd/EkkbwHer/gIoZ RJJayCV9kqvBkKfiaPxH63H/BIYfexfyTIU+RjkndHGMEorSGr5vzqd6Ohx2Pz1Z Xsl1fINb2didlAhnezqs8It/pnyiA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeeggedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 24 Jun 2021 03:43:10 -0400 (EDT) From: Thomas Monjalon To: wangyunjian Cc: stable@dpdk.org, dpdk-dev , Ferruh Yigit , gowrishankar.m@linux.vnet.ibm.com, dingxiaoxiong@huawei.com, dpdk stable , Cheng Liu , Ajit Khaparde Date: Thu, 24 Jun 2021 09:43:09 +0200 Message-ID: <7665074.qKJ98HmJnh@thomas> In-Reply-To: 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-dev] [dpdk-stable] [PATCH v3] kni: fix mbuf allocation for alloc FIFO 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" 24/06/2021 03:55, Ajit Khaparde: > On Tue, Jun 22, 2021 at 5:44 AM wangyunjian wrote: > > > > 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 > Acked-by: Ajit Khaparde Applied, thanks