在 2023/10/29 23:48, Stephen Hemminger 写道:
On Sat, 28 Oct 2023 09:48:44 +0800
Huisong Li <lihuis...@huawei.com> wrote:
The "min_rx_bufsize" in struct rte_eth_dev_info stands for the minimum
Rx buffer size supported by hardware. Actually, some engines also have
the maximum Rx buffer specification, like, hns3.
If mbuf data room size in mempool is greater then the maximum Rx buffer
size supported by HW, the data size application used in each mbuf is just
as much as the maximum Rx buffer size supported by HW instead of the whole
data room size.
So introduce maximum Rx buffer size which is not enforced just to report
user to avoid memory waste.
I am not convinced this is really necessary.
Your device will use up to 4K of buffer size, not sure why an application
would want to use much larger than that because it would be wasting
a lot of buffer space (most packets are smaller) anyway.
The only case where it might be useful is if application is using jumbo
frames (9K) and the application was not able to handle multi segment packets.
Yeah, it is useful if user want a large packet (like, 6K) is in a mbuf.
But, in current layer, user don't know what the maximum buffer size per
descriptor supported by HW is.
Not handling multi segment packets in SW is just programmer laziness.
User do decide their implement based on their cases in project.
May it be a point for this that user don't want to do memcpy for multi
segment packets and just use the first mbuf memory.
Now that there is the "min_rx_bufsize" to report in ethdev layer.
Anyway, DPDK is indeed the lack of the way to report the maximum Rx
buffer size per hw descriptor.
.
