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 61E2F43267; Thu, 2 Nov 2023 02:59:07 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2CCCA42E11; Thu, 2 Nov 2023 02:59:07 +0100 (CET) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id 35FED42DEF for ; Thu, 2 Nov 2023 02:59:05 +0100 (CET) Received: from kwepemm000004.china.huawei.com (unknown [172.30.72.56]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4SLRl45YdPzMm9k; Thu, 2 Nov 2023 09:54:40 +0800 (CST) Received: from [10.67.121.59] (10.67.121.59) 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 09:59:01 +0800 Message-ID: <177b8c04-a8f5-3889-dd26-474122b0be50@huawei.com> Date: Thu, 2 Nov 2023 09:59:01 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH v3 0/3] introduce maximum Rx buffer size To: Stephen Hemminger CC: , , , , , =?UTF-8?Q?Morten_Br=c3=b8rup?= References: <20230808040234.12947-1-lihuisong@huawei.com> <20231028014847.27149-1-lihuisong@huawei.com> <20231029084838.122acb9e@hermes.local> <20231030114850.799f2bce@fedora> <20231031084017.64b9f342@fedora> <20231101090847.105f0fa1@fedora> From: "lihuisong (C)" In-Reply-To: <20231101090847.105f0fa1@fedora> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.59] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) 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 在 2023/11/2 0:08, Stephen Hemminger 写道: > On Wed, 1 Nov 2023 10:36:07 +0800 > "lihuisong (C)" wrote: > >>> Do we need to report this size? It's a common feature for all PMDs. >>> It would make sense then to have max_rx_bufsize set to 16K by default >>> in ethdev, and PMD could then raise/lower based on hardware. >> It is not appropriate to set to 16K by default in ethdev layer. >> Because I don't see any check for the upper bound in some driver, like >> axgbe, enetc and so on. >> I'm not sure if they have no upper bound. >> And some driver's maximum buffer size is "16384(16K) - 128" >> So it's better to set to UINT32_MAX by default. >> what do you think? > The goal is always giving application a working upper bound, and enforcing > that as much as possible in ethdev layer. It doesnt matter which pattern > does that. Fortunately, telling application an incorrect answer is not fatal. > If over estimated, application pool would be wasting space. > If under estimated, application will get more fragmented packets. I know what you mean. If we set UINT32_MAX, it just means that driver don't report this upper bound. This is also a very common way of handling. And it has no effect on the drivers that doesn't report this value. On the contrary, if we set a default value (like 16K) in ethdev, user may be misunderstood and confused by that, right? After all, this isn't the real upper bound of all drivers. And this fixed default value may affect the behavior of some driver that I didn't find their upper bound. So I'd like to keep it as UINT32_MAX. > > .