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 640DAA0C42 for ; Thu, 24 Jun 2021 03:56:18 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 58D9741151; Thu, 24 Jun 2021 03:56:18 +0200 (CEST) Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by mails.dpdk.org (Postfix) with ESMTP id 7742C40141 for ; Thu, 24 Jun 2021 03:56:16 +0200 (CEST) Received: by mail-qv1-f52.google.com with SMTP id u2so2491100qvp.13 for ; Wed, 23 Jun 2021 18:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eVi0q1CTzhGlyNWGL8XKItCaVpqH2pmbZJYwsdVRKNE=; b=IEPNtTGnJ1uU1pbdxybhlVCj5TOOnXt6gCOLa54HNBnC0hncgKYD20+WjosqE4/KhA /1TSlUWdyFW9ZHv5aSli2zoo3cDhKxrvu2v1wkk0eDvux8hCWZgR9x6NruB2x2Tx2dqf ZkUfxwvLQ8I2eFnSrqMdmO8GkD3J1/RbO5OEA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eVi0q1CTzhGlyNWGL8XKItCaVpqH2pmbZJYwsdVRKNE=; b=QSGk8iwQNOnQ+uPj55/N/3c+ZHFEGdKH2dwnGMSxp+7/bhviSGP8oWE855S7130FV/ 8xD87dkTYxPWRlnL0eRvJP5Ow+E8eBod+5TJPNj/il3u4mzgWUbMZyB5jtvTah3VcfD5 s7/OKGHxhqr5t2Qk54qORwLVf0ERfMS6aS+la8uI3MafiYubYE/F5yibgiRt08n0HfwY 5R494TWwFIkZpnATUGT4yvRDvM9V+PCTox6thSr6K1mAW9hKwkj70R7tdQ/DHtTEsw/k SqQ/c5E6ZD2t9CVyLkSg3jPUNUpLMfZBFy/qZ0rdSSJWjYkFKJj8lhpudd+gZTIYGyUQ GNkQ== X-Gm-Message-State: AOAM531bEmyx/4NZ3e8hG/5lsf1KYTOsER7McyUwApvOsYJAXjk6Qv91 76zDvxdcNua5icPPlteXvWLGP5/fDUBqWEWc35r9eA== X-Google-Smtp-Source: ABdhPJyLO6SwpnzYAr5m6txSc7m9Pf9RJhhCQsCJaiIuex9Qhmwxd7WeaV54bj9MjDyx62v5ZEvA4Jq49NmJ8BKSmkw= X-Received: by 2002:a0c:85c2:: with SMTP id o60mr2729598qva.30.1624499775599; Wed, 23 Jun 2021 18:56:15 -0700 (PDT) MIME-Version: 1.0 References: <4aebf99afe5bae2b25f2e5445a32243ffd6f7e97.1624359204.git.wangyunjian@huawei.com> <1624365869-31872-1-git-send-email-wangyunjian@huawei.com> In-Reply-To: <1624365869-31872-1-git-send-email-wangyunjian@huawei.com> From: Ajit Khaparde Date: Wed, 23 Jun 2021 18:55:59 -0700 Message-ID: To: wangyunjian Cc: dpdk-dev , Ferruh Yigit , Thomas Monjalon , gowrishankar.m@linux.vnet.ibm.com, dingxiaoxiong@huawei.com, dpdk stable , Cheng Liu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000015f26d05c5795463" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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" --00000000000015f26d05c5795463 Content-Type: text/plain; charset="UTF-8" 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 > --- > 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); > + 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)) { > -- > 2.23.0 > --00000000000015f26d05c5795463--