在 2023/11/3 0:51, Morten Brørup 写道:
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)" wrote:
Do we need to report this
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)" 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 defa
> From: Ferruh Yigit [mailto:ferruh.yi...@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.yi...@amd.com]
> >> Sent: Thursday, 2 November 2023 17.24
> >>
> >> On 11/2/2023 1:59 AM, lihuisong (C) wrote:
> >>>
> >>
On 11/2/2023 5:12 PM, Morten Brørup wrote:
>> From: Ferruh Yigit [mailto:ferruh.yi...@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.yi...@amd.com]
Sent: Thursday, 2 November 2023 17.24
On 11/2
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)" 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)" wrote:
> >>
> Do we need to report this size?
在 2023/11/2 0:08, Stephen Hemminger 写道:
On Wed, 1 Nov 2023 10:36:07 +0800
"lihuisong (C)" 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 hardwa
On Wed, 1 Nov 2023 10:36:07 +0800
"lihuisong (C)" 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 t
Hi Stephen,
在 2023/10/31 23:40, Stephen Hemminger 写道:
On Tue, 31 Oct 2023 10:57:45 +0800
"lihuisong (C)" wrote:
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 me
On Tue, 31 Oct 2023 10:57:45 +0800
"lihuisong (C)" wrote:
> >> 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_
> From: lihuisong (C) [mailto:lihuis...@huawei.com]
> Sent: Tuesday, 31 October 2023 03.58
>
> 在 2023/10/31 2:48, Stephen Hemminger 写道:
> > On Mon, 30 Oct 2023 09:25:34 +0800
> > "lihuisong (C)" wrote:
> >
> >>>
> The "min_rx_bufsize" in struct rte_eth_dev_info stands for the
> minimum
在 2023/10/31 2:48, Stephen Hemminger 写道:
On Mon, 30 Oct 2023 09:25:34 +0800
"lihuisong (C)" 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.
On Mon, 30 Oct 2023 09:25:34 +0800
"lihuisong (C)" 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
在 2023/10/29 23:48, Stephen Hemminger 写道:
On Sat, 28 Oct 2023 09:48:44 +0800
Huisong Li 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 mb
14 matches
Mail list logo