[PATCH v3 0/3] introduce maximum Rx buffer size

lihuisong (C) lihuisong at huawei.com
Mon Oct 30 02:25:34 CET 2023


在 2023/10/29 23:48, Stephen Hemminger 写道:
> On Sat, 28 Oct 2023 09:48:44 +0800
> Huisong Li <lihuisong at 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.
>
> .


More information about the dev mailing list