On 11/2/2023 4:51 PM, Morten Brørup wrote: >> From: Ferruh Yigit [mailto:ferruh.yi...@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)" <lihuis...@huawei.com> 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! > > 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. > :-) >
It is a memory optimization patch, but again nothing to do with jumbo frames or scattered Rx.
