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.
