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 5D968A04FD for ; Wed, 9 Nov 2022 17:39:17 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4EA3740156; Wed, 9 Nov 2022 17:39:17 +0100 (CET) Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by mails.dpdk.org (Postfix) with ESMTP id A7004400EF for ; Wed, 9 Nov 2022 17:39:14 +0100 (CET) Received: by mail-pf1-f181.google.com with SMTP id q9so17203249pfg.5 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=cspkHVtC8fDpRnOcBiimcUev4HC7IaGunHOGSourvxPJ1z8/WZN9gzt23v+ujUq8GA +L85OowAkb6ZWzIkpsqEFsn+kPxd/9MCGCsEoi58NqvL9AIaoBIy5S+437PkVu5g5yAT zfPtnw5jQb3hXncoorxYKCEvRGIFinJDJw8Qj+rysmOKcSVj6+bCoerrc2Wn7QB6MEon aI2pCVucEjnuWXbNbQNGjhd4mOd6fzb2dc2lEdWZLtdEWvBVoLp0gs1EVqgF/jfQcPTP xDy51R1PCywvl5xoYAPSg89hBr6S57AJV9ttT5yWj3NHydlCBca/4TlwGM0KdOuGXyq+ nD5A== X-Gm-Message-State: ACrzQf1NrNHc4QLKg60CruUZ8woabKdtts+EOW92Q+GnSalhgdlXqcUM dLJqBBDTY5Nx+8T2Wny3nNGLRw== 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: 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 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.