From patchwork Thu Nov 2 12:16:05 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "lihuisong (C)" X-Patchwork-Id: 350 Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A6E404326E; Thu, 2 Nov 2023 13:15:54 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2C637406B8; Thu, 2 Nov 2023 13:15:54 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id E516E40262 for ; Thu, 2 Nov 2023 13:15:52 +0100 (CET) Received: from kwepemm000004.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4SLjR22S27zPnyn; Thu, 2 Nov 2023 20:11:42 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by kwepemm000004.china.huawei.com (7.193.23.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Thu, 2 Nov 2023 20:15:48 +0800 From: Huisong Li To: CC: , , , , Subject: [PATCH v4 0/3] introduce maximum Rx buffer size Date: Thu, 2 Nov 2023 20:16:05 +0800 Message-ID: <20231102121608.10170-1-lihuisong@huawei.com> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20230808040234.12947-1-lihuisong@huawei.com> References: <20230808040234.12947-1-lihuisong@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.69.192.56] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemm000004.china.huawei.com (7.193.23.18) X-CFilter-Loop: Reflected 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 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. --- v4: - fix the log in rte_eth_rx_queue_setup. - add a comment in rel_notes. v3: - fix some comments for Morten's advice. v2: - fix some comments - fix the log level when data room size is greater than maximum Rx buffer size. v1: - move max_rx_bufsize to min_rx_bufsize closer in struct rte_eth_dev_info - add max_rx_bufsize display in testpmd. - hns3 reports maximum buffer size. Huisong Li (3): ethdev: introduce maximum Rx buffer size app/testpmd: add maximum Rx buffer size display net/hns3: report maximum buffer size app/test-pmd/config.c | 2 ++ doc/guides/rel_notes/release_23_11.rst | 7 +++++++ drivers/net/hns3/hns3_common.c | 1 + lib/ethdev/rte_ethdev.c | 7 +++++++ lib/ethdev/rte_ethdev.h | 10 +++++++++- 5 files changed, 26 insertions(+), 1 deletion(-)