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 0E60B43272; Fri, 3 Nov 2023 03:13:18 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D228740265; Fri, 3 Nov 2023 03:13:17 +0100 (CET) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id A988E4021E for ; Fri, 3 Nov 2023 03:13:15 +0100 (CET) Received: from kwepemm000004.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4SM45w5YC8zvQH5; Fri, 3 Nov 2023 10:13:08 +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; Fri, 3 Nov 2023 10:13:11 +0800 Message-ID: <148fd6ac-9e03-da01-dcf7-bf95d37088c4@huawei.com> Date: Fri, 3 Nov 2023 10:13:10 +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: =?UTF-8?Q?Morten_Br=c3=b8rup?= , Ferruh Yigit , Stephen Hemminger CC: , , , 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> <177b8c04-a8f5-3889-dd26-474122b0be50@huawei.com> <2e2a17cc-6dc2-4ce2-bed8-d3e7239b83ff@amd.com> <98CBD80474FA8B44BF855DF32C47DC35E9EFCB@smartserver.smartshare.dk> From: "lihuisong (C)" In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EFCB@smartserver.smartshare.dk> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.59] 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 在 2023/11/3 0:51, Morten Brørup 写道: >> From: Ferruh Yigit [mailto:ferruh.yigit@amd.com] >> Sent: Thursday, 2 November 2023 17.24 >> >> On 11/2/2023 1:59 AM, lihuisong (C) wrote: >>> 在 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. >>> >> >> Hi Stephen, Morten, >> >> I saw scattered Rx mentioned, there may be some misalignment, >> the purpose of the patch is not to enable application to set as big as >> possible mbuf size, so that application can escape from parsing >> multi-segment mbufs. >> Indeed application can provide a large mbuf anyway, to have same >> result, >> without knowing this information. >> >> Main motivation is other way around, device may have restriction on >> buffer size that a single descriptor can address, independent from >> scattered Rx used, if mbuf size is bigger than this device limit, each >> mbuf will have some unused space. >> Patch has intention to inform this max per mbuf/descriptor buffer size, >> so that application doesn't allocate bigger mbuf and waste memory. > Good point! +1 > > Let's categorize this patch series as a memory optimization for applications that support jumbo frames, but are trying to avoid (or reduce) scattered RX. :-) User can select to receive jumbo frames in one mbuf or descriptor rather then multi-mbuf even if no this patch. In other words, using big Rx buffer size is just a way to receive jumbo frames. >