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 EB92AA0C41; Thu, 24 Jun 2021 03:56:17 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 723C040141; Thu, 24 Jun 2021 03:56:17 +0200 (CEST) Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) by mails.dpdk.org (Postfix) with ESMTP id 761114003C for ; Thu, 24 Jun 2021 03:56:16 +0200 (CEST) Received: by mail-qv1-f50.google.com with SMTP id j6so1911842qvp.3 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=p+NLAMVd3StwGEBMGwraZsXVuI8EQR3yruNviKkXEyQ=; b=TMdWwJFrwtySIaeFBgqiTal0RVLTL+qqNLV7/E92m/QVCm+cCDqq+LgJxhb0LviuUF fgC0S3NCp83Aae4fs5w6KftzbN9PUnnvlCLlklffbuf6+/Lqg/RTb/+yysyqF828/cos LsimAb8xK9+tdhJnGeyRZIeonJNjhTngdR64w= 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=p+NLAMVd3StwGEBMGwraZsXVuI8EQR3yruNviKkXEyQ=; b=HbXAgD52yj3EBBQUYlVZV93AGkRuVO5xj2Lt29+yaGlhEaYFXEDuTqjoXHWBaIxfe9 ur22cwEUQcjDflv3hgLPBsREAeTvBUtqecytWcLFaUs5En2uGpOWjw2k+fD4jon5zuvl EWyxlnXK/GT7J8oYAmgBQonI1D46ZCa/OnjgVFyHgizilVlNkKpSMFzDgE+JMhL3tpI3 6tIm9Ia6rVAbFr+Ez0GAslMoNyIflL5uBtIQ1hytVbpFtfV4SpszgvdN6/LkVixE7DTu d/qfvRnvF+BeEUTSgFvX4MIw+Z8oFCgrjvAVuEqkx8xl/Mx3oSR4ibFdICV3rveflxbz m6fA== X-Gm-Message-State: AOAM531tTxQ/gHS4EmUDMqWVvU7vbj9cxfocQqIXVSDJYGF1tXkO4yZV QY3iry5flo2KUnwLa1hkmrb0R5H/UHiYwFUnnmLuHQ== 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="00000000000015f27f05c5795464" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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" --00000000000015f27f05c5795464 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 > --00000000000015f27f05c5795464--