From: Stephen Hemminger <stephen@networkplumber.org>
To: Yangchao Zhou <zhouyates@gmail.com>
Cc: dev@dpdk.org, Hemant@freescale.com, stable@dpdk.org
Subject: Re: [PATCH v2] kni: fix possible alloc_q starvation when mbufs are exhausted
Date: Wed, 9 Nov 2022 08:39:09 -0800 [thread overview]
Message-ID: <20221109083909.6536bce8@hermes.local> (raw)
In-Reply-To: <20221109060434.2012064-1-zhouyates@gmail.com>
On Wed, 9 Nov 2022 14:04:34 +0800
Yangchao Zhou <zhouyates@gmail.com> wrote:
> In some scenarios, mbufs returned by rte_kni_rx_burst are not freed
> immediately. So kni_allocate_mbufs may be failed, but we don't know.
>
> Even worse, when alloc_q is completely exhausted, kni_net_tx in
> rte_kni.ko will drop all tx packets. kni_allocate_mbufs is never
> called again, even if the mbufs are eventually freed.
>
> In this patch, we always try to allocate mbufs for alloc_q.
>
> Don't worry about alloc_q being allocated too many mbufs, in fact,
> the old logic will gradually fill up alloc_q.
> Also, the cost of more calls to kni_allocate_mbufs should be acceptable.
>
> Fixes: 3e12a98fe397 ("kni: optimize Rx burst")
> Cc: Hemant@freescale.com
> Cc: stable@dpdk.org
>
> Signed-off-by: Yangchao Zhou <zhouyates@gmail.com>
Since fifo_get returning 0 (no buffers) is very common would this
change impact performance.
If the problem is pool draining might be better to make the pool
bigger.
next prev parent reply other threads:[~2022-11-09 16:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 5:13 [PATCH] kni: fix possible alloc_q starvation when mbufs are exhausted Yangchao Zhou
2022-11-09 6:04 ` [PATCH v2] " Yangchao Zhou
2022-11-09 16:39 ` Stephen Hemminger [this message]
2022-11-11 9:12 ` Matt
2022-12-09 16:15 ` Ferruh Yigit
2022-12-30 4:23 ` [PATCH v3] " Yangchao Zhou
2023-01-03 12:47 ` Ferruh Yigit
2023-01-04 11:57 ` Matt
2023-01-04 14:34 ` Ferruh Yigit
2023-03-11 9:16 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221109083909.6536bce8@hermes.local \
--to=stephen@networkplumber.org \
--cc=Hemant@freescale.com \
--cc=dev@dpdk.org \
--cc=stable@dpdk.org \
--cc=zhouyates@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.