From patchwork Sat Oct 28 01:48:44 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "lihuisong (C)" X-Patchwork-Id: 324 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 7A7234321C; Sat, 28 Oct 2023 03:48:45 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5FF8740A6C; Sat, 28 Oct 2023 03:48:31 +0200 (CEST) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by mails.dpdk.org (Postfix) with ESMTP id CA65240291 for ; Sat, 28 Oct 2023 03:48:25 +0200 (CEST) Received: from kwepemm000004.china.huawei.com (unknown [172.30.72.56]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4SHMmm1nJdz1L9Cw; Sat, 28 Oct 2023 09:45:28 +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; Sat, 28 Oct 2023 09:48:23 +0800 From: Huisong Li To: CC: , , , , Subject: [PATCH v3 0/3] introduce maximum Rx buffer size Date: Sat, 28 Oct 2023 09:48:44 +0800 Message-ID: <20231028014847.27149-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. --- 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 ++ drivers/net/hns3/hns3_common.c | 1 + lib/ethdev/rte_ethdev.c | 7 +++++++ lib/ethdev/rte_ethdev.h | 10 +++++++++- 4 files changed, 19 insertions(+), 1 deletion(-)