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 6E284A0C42 for ; Wed, 23 Jun 2021 14:16:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5B418410F4; Wed, 23 Jun 2021 14:16:12 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 9652E4003E; Wed, 23 Jun 2021 14:16:09 +0200 (CEST) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4G92Cz17pGzXjjH; Wed, 23 Jun 2021 20:10:55 +0800 (CST) Received: from dggema721-chm.china.huawei.com (10.3.20.85) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Wed, 23 Jun 2021 20:16:05 +0800 Received: from dggpemm500008.china.huawei.com (7.185.36.136) by dggema721-chm.china.huawei.com (10.3.20.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 23 Jun 2021 20:16:05 +0800 Received: from dggpemm500008.china.huawei.com ([7.185.36.136]) by dggpemm500008.china.huawei.com ([7.185.36.136]) with mapi id 15.01.2176.012; Wed, 23 Jun 2021 20:16:05 +0800 From: wangyunjian To: Thomas Monjalon CC: "dev@dpdk.org" , "stable@dpdk.org" , "ferruh.yigit@intel.com" , "gowrishankar.m@linux.vnet.ibm.com" , dingxiaoxiong , "liucheng (J)" Thread-Topic: [dpdk-stable] [dpdk-dev] [PATCH v3] kni: fix mbuf allocation for alloc FIFO Thread-Index: AQHXZ2RmNF6z4cAYVEKjTjcQpes3j6sf+maAgAF/A6A= Date: Wed, 23 Jun 2021 12:16:05 +0000 Message-ID: References: <4aebf99afe5bae2b25f2e5445a32243ffd6f7e97.1624359204.git.wangyunjian@huawei.com> <1624365869-31872-1-git-send-email-wangyunjian@huawei.com> <3564511.TeOt0uO2Lr@thomas> In-Reply-To: <3564511.TeOt0uO2Lr@thomas> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.243.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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" > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Wednesday, June 23, 2021 4:46 AM > To: wangyunjian ; liucheng (J) > > Cc: dev@dpdk.org; stable@dpdk.org; ferruh.yigit@intel.com; > gowrishankar.m@linux.vnet.ibm.com; dingxiaoxiong > ; wangyunjian > Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3] kni: fix mbuf allocation= for alloc > FIFO >=20 > 22/06/2021 14:44, wangyunjian: > > From: Yunjian Wang > > > > In kni_allocate_mbufs(), we alloc mbuf for alloc_q as this code. > > allocq_free =3D (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 =3D read =3D 0. Then we fill > > kni->alloc_q to full. At this time, write =3D 1023, read =3D 0. > > > > Then the kernel send 32 packets to userspace. At this time, write =3D > > 1023, read =3D 32. And then the userspace receive this 32 packets. > > Then fill the kni->alloc_q, (32 - 1023 - 1) & 31 =3D 0, fill nothing. > > ... > > Then the kernel send 32 packets to userspace. At this time, write =3D > > 1023, read =3D 992. And then the userspace receive this 32 packets. > > Then fill the kni->alloc_q, (992 - 1023 - 1) & 31 =3D 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 =3D (kni->alloc_q->read - kni->alloc_q->write - 1) > > - & (MAX_MBUF_BURST_NUM - 1); > > + allocq_free =3D kni_fifo_free_count(kni->alloc_q); >=20 > Can we insert a comment here to explain the logic? OK, how about like this? /* Because 'read/write' maybe not volatile, so use kni_fifo_free_count() * to get the num of available elements in the fifo */ >=20 > > + allocq_free =3D (allocq_free > MAX_MBUF_BURST_NUM) ? > > + MAX_MBUF_BURST_NUM : allocq_free; > > for (i =3D 0; i < allocq_free; i++) { > > pkts[i] =3D rte_pktmbuf_alloc(kni->pktmbuf_pool); > > if (unlikely(pkts[i] =3D=3D NULL)) { >=20 > About the title, I don't understand the part "for alloc FIFO", given all = mbufs are > in a FIFO queue in KNI, right? The title is "kni: fix mbuf allocation for FIFO queue"?