From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 900E9A034C;
Wed, 9 Nov 2022 17:39:16 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 6DC42400EF;
Wed, 9 Nov 2022 17:39:16 +0100 (CET)
Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com
[209.85.215.169])
by mails.dpdk.org (Postfix) with ESMTP id A5613400D4
for <dev@dpdk.org>; Wed, 9 Nov 2022 17:39:14 +0100 (CET)
Received: by mail-pg1-f169.google.com with SMTP id r18so16660228pgr.12
for <dev@dpdk.org>; Wed, 09 Nov 2022 08:39:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20210112.gappssmtp.com; s=20210112;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:from:to:cc:subject:date
:message-id:reply-to;
bh=UJXEuo+b8dKwjDEb1YdAjIdvH6p+giUQzuAC7vao8+w=;
b=NKo1nlpGoSiVdIxyqlxm+nlRUY9Y0UdR8vH7j5UV/SXmGzh49//DtpYyDr+lF2TE/S
AiHG6Cbyl42s6Y4oMDGc7Sw8BUFm0lLGV8RxER9t6DGsWgQK8W+y2ykCO4A8cSBmwRPF
xYfxoceT/JBp6MGH5G5ELQlEG5x7LMhlhLLbu/GYT9xZZGEDmcuQtumiiw4a/eKEmjAF
pGbJtjTKfD2UF+Ez3UFYryfuxRH8nqwupPBoH53DZsjjzQvMdTor1HBg71UT/cTNTj/E
p/IUrGKXJ8yGxQ/z7mzYqBsQMcdbfFrE772LQePmxC9ZwEHn1gW0eecFMdGwoaFtB71W
m07Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=UJXEuo+b8dKwjDEb1YdAjIdvH6p+giUQzuAC7vao8+w=;
b=PazSmT8p9EYPiOo9pgiG8f9tRpK8tmXGNPFXhSKG7AP1SRn/8S5YEOrBzIAehueKn5
FH0CSFpGuKLXEe9kVZB5wNLAKs8V2NqLqQp6vhwXewrkos8SbztiWiKYVHa/GV7PbYMQ
ANWT6TX05EJ70dhQl8I+m79Vb7rCBp2dRxwaEB/8UBxM+TZjBmy+3h8QapgVQ6+ynikH
1LA2v2MBNDaeCB8xlfm6B/cSbu8ELiWOYcDVuZD1g/5ZjajJBuTvgSw8JjIRA3zaOrXZ
8YxCT2T8PxcQzp01u0KpT6kciDx16CBCBnrBsRAkdldi3afNpV7Y0Xw5eBm/H7xGHT8K
tkHQ==
X-Gm-Message-State: ACrzQf3q5LQ5AdJI6p5ghCCiDjUrOXujdpciYtP+A+C3rwbrZRPU/Jm+
tsl1BcTK/FsVYdsK/YeBApstyg==
X-Google-Smtp-Source: AMsMyM7c/ULLb3/zwLYokox9vQi72j/4vrLUX76y/Mr10w4mOzWwdQXz6EDqXhk+1Xcbogp4tI/TVg==
X-Received: by 2002:a63:5909:0:b0:46e:c98d:e07c with SMTP id
n9-20020a635909000000b0046ec98de07cmr53006758pgb.530.1668011953824;
Wed, 09 Nov 2022 08:39:13 -0800 (PST)
Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218])
by smtp.gmail.com with ESMTPSA id
4-20020a630b04000000b0046f1e8cb30dsm7692999pgl.26.2022.11.09.08.39.12
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 09 Nov 2022 08:39:12 -0800 (PST)
Date: Wed, 9 Nov 2022 08:39:09 -0800
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
Message-ID: <20221109083909.6536bce8@hermes.local>
In-Reply-To: <20221109060434.2012064-1-zhouyates@gmail.com>
References: <20221109051339.1998037-1-zhouyates@gmail.com>
<20221109060434.2012064-1-zhouyates@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
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.