From patchwork Fri Nov 3 10:27:56 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "lihuisong (C)" X-Patchwork-Id: 357 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 CA37043279; Fri, 3 Nov 2023 11:27:45 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A1DFB4027F; Fri, 3 Nov 2023 11:27:45 +0100 (CET) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by mails.dpdk.org (Postfix) with ESMTP id 6B23F40273 for ; Fri, 3 Nov 2023 11:27:43 +0100 (CET) Received: from kwepemm000004.china.huawei.com (unknown [172.30.72.54]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4SMH111FQnz1P7s1; Fri, 3 Nov 2023 18:24:37 +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; Fri, 3 Nov 2023 18:27:40 +0800 From: Huisong Li To: CC: , , , , Subject: [PATCH v5 0/3] introduce maximum Rx buffer size Date: Fri, 3 Nov 2023 18:27:56 +0800 Message-ID: <20231103102759.18886-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: dggems706-chm.china.huawei.com (10.3.19.183) 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. --- v5: - fix a valiable name - fix the log level and context in rte_eth_rx_queue_setup. 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 | 8 ++++++++ lib/ethdev/rte_ethdev.h | 10 +++++++++- 5 files changed, 27 insertions(+), 1 deletion(-)