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 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 ; Wed, 9 Nov 2022 17:39:14 +0100 (CET) Received: by mail-pg1-f169.google.com with SMTP id r18so16660228pgr.12 for ; 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 To: Yangchao Zhou 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, 9 Nov 2022 14:04:34 +0800 Yangchao Zhou 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 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.