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 0268F43238; Sun, 29 Oct 2023 16:48:43 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CA2CF40269; Sun, 29 Oct 2023 16:48:42 +0100 (CET) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by mails.dpdk.org (Postfix) with ESMTP id 196CC400D5 for ; Sun, 29 Oct 2023 16:48:41 +0100 (CET) Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1cc2f17ab26so8307775ad.0 for ; Sun, 29 Oct 2023 08:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1698594520; x=1699199320; darn=dpdk.org; 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=GviOQgLy1vDpFeWsJXhhvpgeDPGmDQG4SloV9CbRbrM=; b=1DEX3gCX01WlAMB7BB4D+GaeCNboyKE95eUiUKTG2j/FtJ9XPL8PNRYzzfsCeOGf9B ooz/PE6HqgGVRf/BHI6WnuU7EgZRzXqYUnH8zvLmq0EeICAMucZ82OKNlg+dTjc5pQiH gaJtHh5UXJKLg3N10LGcOIK7XC39wVFbFVZgQDdoYIeaBt8j8jhsoORJTTkBXdb4+WaX rbOSfYiFdYphoJh8cxAhI9yVVRSshUpK+bD7Fc9qDFrVeF/HrhO5qDK8boVarYQRmdG6 5nTsH+77gC1l2diRxTKIzANheG/3ClWkmIshvVFomNFXavOy5+IjW7GsHZdW1f6NxdT5 Jy2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698594520; x=1699199320; 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=GviOQgLy1vDpFeWsJXhhvpgeDPGmDQG4SloV9CbRbrM=; b=OmeHm5q29qfHlYGpl90MBZL5+vMkHhqid0Sl8FYBuT/5EL2QU8ixpEjfzfSRmmhjlS 8+1x0YaFxSebapBX9GwNelJ98lSSgrsDXD3+7FNZSqYnVdNinAY99acxgTyQftJLO+HK +An/47NtpmYcwlcX1yCsHi+Jp7oar0iodr9bXyw/N3w1jEFpIyV75nMLq/XWxE9hL4E5 biainDjzVVeOg4AcVklb/IZJXYd4IKujRfdNOvPNbe0J+MH2XaZR4HjI1aoQDxJYS8+E O8k6JTBr5RBtVbNEDDfuyxePWDFfpNIHhUfPHZ1tUGceAC+d3/OWquqkD5faYbXqNp0B DHvA== X-Gm-Message-State: AOJu0Yw7RjNPV1YLWql/r7SVx6xepuqjOm5mDLNEy8zCkAtIphsMD140 +gjXlCx3abi0Yu5a3eE9bcZ2eg== X-Google-Smtp-Source: AGHT+IHRA78XdAb4QqhWPAQS0U37Z+v5z4QbNdSv+KC4+zIJiEDQxUNVKhMDUX0wg9VzMGHnmEowag== X-Received: by 2002:a17:902:db0a:b0:1cc:492c:2918 with SMTP id m10-20020a170902db0a00b001cc492c2918mr597213plx.69.1698594520222; Sun, 29 Oct 2023 08:48:40 -0700 (PDT) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id z13-20020a1709027e8d00b001bc930d4517sm4810476pla.42.2023.10.29.08.48.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 Oct 2023 08:48:40 -0700 (PDT) Date: Sun, 29 Oct 2023 08:48:38 -0700 From: Stephen Hemminger To: Huisong Li Cc: , , , , Subject: Re: [PATCH v3 0/3] introduce maximum Rx buffer size Message-ID: <20231029084838.122acb9e@hermes.local> In-Reply-To: <20231028014847.27149-1-lihuisong@huawei.com> References: <20230808040234.12947-1-lihuisong@huawei.com> <20231028014847.27149-1-lihuisong@huawei.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 Sat, 28 Oct 2023 09:48:44 +0800 Huisong Li wrote: > The "min_rx_bufsize" in struct rte_eth_dev_info stands for the minimum > Rx buffer size supported by hardware. Actually, some engines also have > the maximum Rx buffer specification, like, hns3. > > If mbuf data room size in mempool is greater then the maximum Rx buffer > size supported by HW, the data size application used in each mbuf is just > as much as the maximum Rx buffer size supported by HW instead of the whole > data room size. > > So introduce maximum Rx buffer size which is not enforced just to report > user to avoid memory waste. I am not convinced this is really necessary. Your device will use up to 4K of buffer size, not sure why an application would want to use much larger than that because it would be wasting a lot of buffer space (most packets are smaller) anyway. The only case where it might be useful is if application is using jumbo frames (9K) and the application was not able to handle multi segment packets. Not handling multi segment packets in SW is just programmer laziness.