From: Ferruh Yigit <ferruh.yigit@amd.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
"lihuisong (C)" <lihuisong@huawei.com>,
"Stephen Hemminger" <stephen@networkplumber.org>
Cc: dev@dpdk.org, thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru,
liuyonglong@huawei.com
Subject: Re: [PATCH v3 0/3] introduce maximum Rx buffer size
Date: Thu, 2 Nov 2023 17:35:34 +0000 [thread overview]
Message-ID: <97728b24-9d20-4477-b586-b0d5def10303@amd.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EFCD@smartserver.smartshare.dk>
On 11/2/2023 5:12 PM, Morten Brørup wrote:
>> From: Ferruh Yigit [mailto:ferruh.yigit@amd.com]
>> Sent: Thursday, 2 November 2023 18.06
>>
>> On 11/2/2023 4:51 PM, Morten Brørup wrote:
>>>> 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)" <lihuisong@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.
>
> I expect all NICs to support standard Ethernet frames without scattered RX.
>
> So I consider this patch related to jumbo frames (and non-scattered RX). Is there any other use case?
>
I was thinking this is mainly for miss configuration by the application,
but if done intentionally yes intention of the application can be to
receive jumbo frames.
next prev parent reply other threads:[~2023-11-02 17:35 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 4:02 [RFC] ethdev: " Huisong Li
2023-08-11 12:07 ` Andrew Rybchenko
2023-08-15 8:16 ` lihuisong (C)
2023-08-15 11:10 ` [PATCH v1 0/3] " Huisong Li
2023-08-15 11:10 ` [PATCH v1 1/3] ethdev: " Huisong Li
2023-09-28 15:56 ` Ferruh Yigit
2023-10-24 12:21 ` lihuisong (C)
2023-08-15 11:10 ` [PATCH v1 2/3] app/testpmd: add maximum Rx buffer size display Huisong Li
2023-08-15 11:10 ` [PATCH v1 3/3] net/hns3: report maximum buffer size Huisong Li
2023-10-27 4:15 ` [PATCH v2 0/3] introduce maximum Rx " Huisong Li
2023-10-27 4:15 ` [PATCH v2 1/3] ethdev: " Huisong Li
2023-10-27 6:27 ` fengchengwen
2023-10-27 7:40 ` Morten Brørup
2023-10-28 1:23 ` lihuisong (C)
2023-10-27 4:15 ` [PATCH v2 2/3] app/testpmd: add maximum Rx buffer size display Huisong Li
2023-10-27 6:28 ` fengchengwen
2023-10-27 4:15 ` [PATCH v2 3/3] net/hns3: report maximum buffer size Huisong Li
2023-10-27 6:17 ` fengchengwen
2023-10-28 1:48 ` [PATCH v3 0/3] introduce maximum Rx " Huisong Li
2023-10-28 1:48 ` [PATCH v3 1/3] ethdev: " Huisong Li
2023-10-29 15:43 ` Stephen Hemminger
2023-10-30 3:08 ` lihuisong (C)
2023-10-28 1:48 ` [PATCH v3 2/3] app/testpmd: add maximum Rx buffer size display Huisong Li
2023-10-28 1:48 ` [PATCH v3 3/3] net/hns3: report maximum buffer size Huisong Li
2023-10-29 15:48 ` [PATCH v3 0/3] introduce maximum Rx " Stephen Hemminger
2023-10-30 1:25 ` lihuisong (C)
2023-10-30 18:48 ` Stephen Hemminger
2023-10-31 2:57 ` lihuisong (C)
2023-10-31 7:48 ` Morten Brørup
2023-10-31 15:40 ` Stephen Hemminger
2023-11-01 2:36 ` lihuisong (C)
2023-11-01 16:08 ` Stephen Hemminger
2023-11-02 1:59 ` lihuisong (C)
2023-11-02 16:23 ` Ferruh Yigit
2023-11-02 16:51 ` Morten Brørup
2023-11-02 17:05 ` Ferruh Yigit
2023-11-02 17:12 ` Morten Brørup
2023-11-02 17:35 ` Ferruh Yigit [this message]
2023-11-03 2:13 ` lihuisong (C)
2023-11-02 12:16 ` [PATCH v4 " Huisong Li
2023-11-02 12:16 ` [PATCH v4 1/3] ethdev: " Huisong Li
2023-11-02 16:35 ` Ferruh Yigit
2023-11-03 2:21 ` lihuisong (C)
2023-11-03 3:30 ` Ferruh Yigit
2023-11-03 6:27 ` lihuisong (C)
2023-11-02 12:16 ` [PATCH v4 2/3] app/testpmd: add maximum Rx buffer size display Huisong Li
2023-11-02 16:42 ` Ferruh Yigit
2023-11-03 2:39 ` lihuisong (C)
2023-11-03 3:53 ` Ferruh Yigit
2023-11-03 6:37 ` lihuisong (C)
2023-11-02 12:16 ` [PATCH v4 3/3] net/hns3: report maximum buffer size Huisong Li
2023-11-03 10:27 ` [PATCH v5 0/3] introduce maximum Rx " Huisong Li
2023-11-03 10:27 ` [PATCH v5 1/3] ethdev: " Huisong Li
2023-11-03 12:37 ` Ivan Malov
2023-11-03 10:27 ` [PATCH v5 2/3] app/testpmd: add maximum Rx buffer size display Huisong Li
2023-11-03 10:27 ` [PATCH v5 3/3] net/hns3: report maximum buffer size Huisong Li
2023-11-03 11:53 ` [PATCH v5 0/3] introduce maximum Rx " Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=97728b24-9d20-4477-b586-b0d5def10303@amd.com \
--to=ferruh.yigit@amd.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=lihuisong@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=mb@smartsharesystems.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).