On 2025/7/2 13:56, Morten Brørup wrote:
>> From: huangdengdui [mailto:huangdeng...@huawei.com]
>> Sent: Wednesday, 2 July 2025 04.38
>>
>> Hi everyone,
>>
>> The current rte_net_get_ptype() only supports parsing packets with a
>> single 0x8100 VLAN tag
Hi everyone,
The current rte_net_get_ptype() only supports parsing packets with a single
0x8100 VLAN tag and two 0x88a8 VLAN tags,
but does not support processing packets with two 0x8100 VLAN tags.
Some network cards (e.g., hns3) do support parsing packets with two 0x8100 VLAN
tags.
Can this A
On 2025/6/30 1:40, Stephen Hemminger wrote:
> On Wed, 11 Jun 2025 16:19:00 +0800
> Dengdui Huang wrote:
>
>> +#pragma pack(1)
>> +#define HNS3_MBX_PRIO_SHIFT 4
>> +#define HNS3_MBX_PRIO_MASK 0xFu
>> +struct hns3_mbx_tc_config {
>> +/*
>> + * Each four bits correspond to one priority's
Hi, maintainers,
Kindly ping for reviews.
The CI compilation errors have been checked and are not introduced by this
patch.
We hope to merge these patches into the 25.07 version.
Thanks.
On 2025/6/11 16:18, Dengdui Huang wrote:
> This patchset adds the VF multi-TCs feature.
>
> Chengwen Feng
On 2025/6/9 23:21, Stephen Hemminger wrote:
> On Mon, 9 Jun 2025 09:58:27 +
> Sivaprasad Tummala wrote:
>
>> Previously, the TX burst size was fixed at 256, leading to performance
>> degradation in certain scenarios.
>>
>> This patch introduces logic to set the TX burst size to match the
>>
On 2025/6/10 1:13, Stephen Hemminger wrote:
> On Mon, 9 Jun 2025 21:06:49 +0800
> Dengdui Huang wrote:
>
>> +rem = dma_addr & (HNS3_RX_DMA_ADDR_ALIGN_128 - 1);
>> +if ((rx_offload & RTE_ETH_RX_OFFLOAD_TCP_LRO) && rem > 0) {
>> +hns3_err(hw, "Hardware GRO is not supported whe
On 2025/6/10 1:12, Stephen Hemminger wrote:
> On Mon, 9 Jun 2025 21:06:51 +0800
> Dengdui Huang wrote:
>
>> Currently, When RTE_ETH_RX_OFFLOAD_VLAN_FILTER offload is set,
>> driver wouldn't select Rx vector algorithm. Actually, this
>> algorithm support it, so open it.
>>
>> Fixes: a3d4f4d291d7
On 2025/5/27 4:53, Stephen Hemminger wrote:
> On Fri, 23 May 2025 10:55:55 +0800
> Dengdui Huang wrote:
>
>> After parsing the GTP packet header, the next protocol type should
>> be converted from RTE_GTP_TYPE_IPV4/IPV6 to RTE_ETHER_TYPE_IPV4/IPV6.
>> Otherwise, the next protocol cannot be pars
Acked-by: Dengdui Huang
On 2025/5/21 13:11, sk...@marvell.com wrote:
> From: Sunil Kumar Kori
>
> While parsing packet headers, offset must be added to get next
> header but for geneve header parsing offset is overwritten.
> Also inner_l2_len is not set in case of geneve packets.
>
> Fixes: 64
I have also found some bugs about the tunnel packet type parsing API[1],
including one of the problems fixed by this patch.
[1] https://patchwork.dpdk.org/project/dpdk/list/?series=35233
On 2025/5/21 13:11, sk...@marvell.com wrote:
> From: Sunil Kumar Kori
>
> While parsing packet headers, off
Tested-by: Dengdui Huang
The issue addressed by this patch is the same as the one fixed by the patch [1]
pushed by Haijie.
However, this patch is better, and I have already tested it on the Kunpeng
platform.
Please make the changes based on Konstantin's review comments and push the next
versio
Hi, Jiale, this patch can solve the issues[1] you reported. Can you review this
patch and add a Tested-by tag?
[1]
https://bugs.dpdk.org/show_bug.cgi?id=1672
On 2025/4/17 20:37, Dengdui Huang wrote:
> After parsing the GTP packet header, the next protocol type should
> be converted from RTE_GTP_
Acked-by: Dengdui Huang
On 2025/4/2 16:47, Jie Hai wrote:
> I am moving on to other things and dengdui is going to
> take over the role of hns3 maintainer. Update the
> MAINTAINERS accordingly.
>
> Signed-off-by: Jie Hai
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(
On 2025/4/2 22:45, Morten Brørup wrote:
>> From: Dengdui Huang [mailto:huangdeng...@huawei.com]
>> Sent: Wednesday, 2 April 2025 14.25
>>
>> The communication pipe may be unavailable, for example,
>> when the lcore role is ROLE_OFF or ROLE_NON_EAL.
>> So check whether the pipe is available before
On 2025/4/3 5:16, Dmitry Kozlyuk wrote:
> On 02.04.2025 15:42, Dengdui Huang wrote:
>> When the process address space is insufficient,
>> mmap will fail, which will cause an infinite loop.
>> This pathc fix it.
>>
>> Fixes: c4b89ecb64ea ("eal: introduce memory management wrappers")
>> Cc: sta...@
On 2025/3/27 17:32, Morten Brørup wrote:
>> From: Dengdui Huang [mailto:huangdeng...@huawei.com]
>> Sent: Thursday, 27 March 2025 10.01
>>
>> The worker_id may come from user input.
>> So it is necessary to verify it.
>>
>> Fixes: a95d70547c57 ("eal: factorize lcore main loop")
>> Cc: sta...@dpdk
On 2025/3/21 23:58, Stephen Hemminger wrote:
> On Fri, 21 Mar 2025 12:03:16 +0800
> Dengdui Huang wrote:
>
>> When a core that is not used by the rte is specified in the config
>> for testing, the problem of infinite loop occurs. The root cause
>> is that the program waits for the completion of
On 2025/3/21 15:49, David Marchand wrote:
> On Fri, Mar 21, 2025 at 5:03 AM Dengdui Huang wrote:
>>
>> After CPU isolation is configured, an infinite loop occurs when
>> dma-perf is executed using the default config file.
>>
>> This patchset fix it.
>>
>> Dengdui Huang (2):
>> eal: fix wake a
On 2025/1/25 1:34, Stephen Hemminger wrote:
> On Fri, 24 Jan 2025 17:59:57 +0800
> Dengdui Huang wrote:
>
>> diff --git a/lib/mbuf/rte_mbuf.c b/lib/mbuf/rte_mbuf.c
>> index 559d5ad8a7..c828200ea1 100644
>> --- a/lib/mbuf/rte_mbuf.c
>> +++ b/lib/mbuf/rte_mbuf.c
>> @@ -771,7 +771,7 @@ const char
On 2025/1/24 22:34, Morten Brørup wrote:
>> From: Dengdui Huang [mailto:huangdeng...@huawei.com]
>> Sent: Friday, 24 January 2025 11.00
>>
>> After discussion[1], the drivers do not include the CRC in the packet
>> length calculation. This will cause users to be confused about whether
>> the mbuf
On 2025/1/15 17:38, Morten Brørup wrote:
>> From: huangdengdui [mailto:huangdeng...@huawei.com]
>> Sent: Wednesday, 15 January 2025 07.52
>>
>> On 2025/1/15 0:39, Morten Brørup wrote:
>>> mbuf: add fast free bulk function
>>>
>>> When putti
On 2025/1/15 0:39, Morten Brørup wrote:
> mbuf: add fast free bulk function
>
> When putting an mbuf back into its mempool, there are certain requirements
> to the mbuf. Specifically, some of its fields must be initialized.
>
> These requirements are in fact invariants about free mbufs, held in
On 2025/1/10 1:03, Stephen Hemminger wrote:
> On Thu, 9 Jan 2025 15:43:12 +0800
> huangdengdui wrote:
>
>> On 2025/1/9 0:57, Stephen Hemminger wrote:
>>> On Wed, 8 Jan 2025 10:40:43 +0800
>>> Jie Hai wrote:
>>>
>>>> On 2024/12/31 1:55
On 2025/1/11 1:19, Stephen Hemminger wrote:
> On Fri, 10 Jan 2025 17:37:15 +0800
> Dengdui Huang wrote:
>
>> +#define DEFAULT_PREFECH_OFFSET 4
>
> Spelling
I made a mistake. I'll fix it for the next version.
On 2025/1/11 1:20, Stephen Hemminger wrote:
> This will make it slower for many platforms.
> GCC will unroll a loop of fixed small size, which is what we want.
Do you mean to replace option with a macro?
But most of prefetch_offset are used with the nb_rx, So using macros is the
same as using o
On 2025/1/8 21:42, Konstantin Ananyev wrote:
>
>
>>
>> The prefetch window depending on the hardware platform. The current prefetch
>> policy may not be applicable to all platforms. In most cases, the number of
>> packets received by Rx burst is small (64 is used in most performance
>> reports
On 2025/1/9 0:57, Stephen Hemminger wrote:
> On Wed, 8 Jan 2025 10:40:43 +0800
> Jie Hai wrote:
>
>> On 2024/12/31 1:55, Stephen Hemminger wrote:
>>> On Mon, 30 Dec 2024 14:54:03 +0800
>>> Jie Hai wrote:
>>>
From: Jie Hai
To: , , ,
, , Chengwen
Feng , "Wei Hu (Xavie
On 2024/11/30 1:12, Stephen Hemminger wrote:
> On Fri, 29 Nov 2024 09:36:43 +0800
> Jie Hai wrote:
>
>>> +
>>> +static inline void
>>> +hns3_recalculate_crc(struct rte_mbuf *m)
>>> +{
>>> + char *append_data;
>>> + uint32_t crc;
>>> +
>>> + crc = rte_net_crc_calc(rte_pktmbuf_mtod(m, void
On 2024/11/26 1:45, Stephen Hemminger wrote:
> On Fri, 19 Jul 2024 17:04:15 +0800
> Jie Hai wrote:
>
>> +static inline void
>> +hns3_recalculate_crc(struct rte_mbuf *m)
>> +{
>> +char *append_data;
>> +uint32_t crc;
>> +
>> +crc = rte_net_crc_calc(rte_pktmbuf_mtod(m, void *),
>> +
On 2024/11/7 2:57, Stephen Hemminger wrote:
> On Tue, 14 Nov 2023 16:24:56 +0800
> Dengdui Huang wrote:
>
>> The function strerror() is insecure in a multi-thread environment.
>> This series of patches fix it. In this patchset, only the libs and
>> drivers are modified.
>
> strerror is ok in m
On 2024/10/26 5:56, Thomas Monjalon wrote:
> 24/10/2024 08:47, huangdengdui:
>> On 2024/10/23 23:42, Stephen Hemminger wrote:
>>> On Wed, 23 Oct 2024 16:28:10 +0800
>>> Dengdui Huang wrote:
>>>
>>>> The function strerror() is insecure in a mu
Hi, Stephen Hemminger
On 2024/10/23 23:42, Stephen Hemminger wrote:
> On Wed, 23 Oct 2024 16:28:10 +0800
> Dengdui Huang wrote:
>
>> The function strerror() is insecure in a multi-thread environment.
>> It is better to use rte_strerror() instead of strerror().
>> In this patchset, only the libs
On 2024/7/2 15:40, Chaoyong He wrote:
> From: Zerun Fu
>
> For the primary process, the logic loops all BARs and will skip
> the map of BAR with an invalid physical address (0), also will
> assign 'uio_res->nb_maps' with the real mapped BARs number. But
> for the secondary process, instead of l
For the patchset,
Reviewed-by: Dengdui Huang
On 2024/3/18 19:18, Chengwen Feng wrote:
> I found a couple of issues when I revisited the argparse_autotest
> output, so got this patchset.
>
> Chengwen Feng (6):
> argparse: refine error message
> argparse: remove dead code
> argparse: replace
On 2024/6/27 22:28, David Marchand wrote:
> On Wed, Apr 17, 2024 at 11:32 AM Dengdui Huang
> wrote:
>>
>> The version variable is not initialized. Therefore, if the -V option
>> is not specified, the value of $version is obtained from the context,
>> which may cause the version map parsing fail
On 2024/6/26 5:07, Damodharam Ammepalli wrote:
> On Wed, Jun 19, 2024 at 8:23 PM huangdengdui wrote:
>>
>> Hi Damodharam
>> Here are some suggestions. See below.
>>
> Thank you for the review.
>
>> On 2024/6/18 4:34, Damodharam Ammepalli wrote:
>&g
Hi Damodharam
Here are some suggestions. See below.
On 2024/6/18 4:34, Damodharam Ammepalli wrote:
> Update the eth_dev_ops structure with new function vectors
> to get, get capabilities and set ethernet link speed lanes.
> Update the testpmd to provide required config and information
> display in
Hi, Ferruh
Sorry for replying your email very late.
The answers to your questions are as follows. Please correct me if I am wrong.
On 2024/4/4 21:58, Ferruh Yigit wrote:
>
> Hi Dengdui, Damodharam,
>
> As details of the implementation under discussion, I have a high level
> question.
>
> Why/wh
On 2024/4/9 10:50, Stephen Hemminger wrote:
> On Tue, 9 Apr 2024 10:06:01 +0800
> huangdengdui wrote:
>
>> On 2024/4/8 16:45, Ferruh Yigit wrote:
>>> On 4/8/2024 6:52 AM, huangdengdui wrote:
>>>>
>>>>
>>>> On 2024/4/6 0:44, Stephen
On 2024/4/8 16:45, Ferruh Yigit wrote:
> On 4/8/2024 6:52 AM, huangdengdui wrote:
>>
>>
>> On 2024/4/6 0:44, Stephen Hemminger wrote:
>>> On Sat, 30 Mar 2024 15:44:09 +0800
>>> Dengdui Huang wrote:
>>>
>>>> When the port's
On 2024/4/6 0:44, Stephen Hemminger wrote:
> On Sat, 30 Mar 2024 15:44:09 +0800
> Dengdui Huang wrote:
>
>> When the port's timestamping function failed to initialize
>> (for example, the device does not support PTP), the packets
>> received by the hardware do not contain the timestamp.
>> In
On 2024/4/2 4:07, Thomas Monjalon wrote:
> 30/03/2024 12:38, huangdengdui:
>> But, there are different solutions for the device to report the setting
>> lane capability, as following:
>> 1. Like the current patch, reporting device capabilities in speed and
>>lane
;>>>
>>>> 在 2024/3/26 18:30, Thomas Monjalon 写道:
>>>>> 26/03/2024 02:42, lihuisong (C):
>>>>>> 在 2024/3/25 17:30, Thomas Monjalon 写道:
>>>>>>> 25/03/2024 07:24, huangdengdui:
>>>>>>>> On
On 2024/3/22 21:58, Thomas Monjalon wrote:
> 22/03/2024 08:09, Dengdui Huang:
>> -#define RTE_ETH_LINK_SPEED_10G RTE_BIT32(8) /**< 10 Gbps */
>> -#define RTE_ETH_LINK_SPEED_20G RTE_BIT32(9) /**< 20 Gbps */
>> -#define RTE_ETH_LINK_SPEED_25G RTE_BIT32(10) /**< 25 Gbps */
>> -#define
On 2024/3/21 16:28, Thomas Monjalon wrote:
> 21/03/2024 03:02, huangdengdui:
>>
>> On 2024/3/20 20:31, Ferruh Yigit wrote:
>>> On 3/18/2024 9:26 PM, Damodharam Ammepalli wrote:
>>>> On Mon, Mar 18, 2024 at 7:56 AM Thomas Monjalon
>>>> wr
On 2024/3/20 20:31, Ferruh Yigit wrote:
> On 3/18/2024 9:26 PM, Damodharam Ammepalli wrote:
>> On Mon, Mar 18, 2024 at 7:56 AM Thomas Monjalon wrote:
>>>
>>> 12/03/2024 08:52, Dengdui Huang:
Some speeds can be achieved with different number of lanes. For example,
100Gbps can be achiev
On 2024/3/19 11:02, Stephen Hemminger wrote:
> On Tue, 12 Mar 2024 15:52:36 +0800
> Dengdui Huang wrote:
>
>> -ret = snprintf(str, len, "Link up at %s %s %s",
>> +ret = snprintf(str, len, "Link up at %s %ulanes %s %s",
>
> Don't you want a space after %u?
>
> Could yo
On 2024/3/16 5:47, Damodharam Ammepalli wrote:
> On Tue, Mar 12, 2024 at 12:52 AM Dengdui Huang
> wrote:
>>
>> Extended speed command for setting lane number and
>> Show info print lane number.
>>
>> Signed-off-by: Dengdui Huang
>> ---
>> app/test-pmd/cmdline.c | 110 +++
On 2024/2/29 17:25, Ferruh Yigit wrote:
> On 2/29/2024 3:58 AM, huangdengdui wrote:
>>
>>
>> On 2024/2/28 21:07, Ferruh Yigit wrote:
>>> On 2/28/2024 2:27 AM, huangdengdui wrote:
>>>>
>>>>
>>>> On 2024/2/27 0:43, Ferruh Yigit wro
On 2024/2/28 21:07, Ferruh Yigit wrote:
> On 2/28/2024 2:27 AM, huangdengdui wrote:
>>
>>
>> On 2024/2/27 0:43, Ferruh Yigit wrote:
>>> On 2/26/2024 3:16 AM, Jie Hai wrote:
>>>> On 2024/2/23 21:53, Ferruh Yigit wrote:
>>>>&g
On 2024/2/27 0:43, Ferruh Yigit wrote:
> On 2/26/2024 3:16 AM, Jie Hai wrote:
>> On 2024/2/23 21:53, Ferruh Yigit wrote:
>>> On 2/20/2024 3:58 AM, Jie Hai wrote:
Hi, Ferruh,
Thanks for your review.
On 2024/2/7 22:15, Ferruh Yigit wrote:
> On 2/6/2024 1:10 AM, Jie Hai
On 2024/1/26 14:23, fengchengwen wrote:
> Hi Dengdui,
>
> On 2024/1/26 10:41, Dengdui Huang wrote:
>> On multi-process scenario, each process creates flows based on the
>> number of queues. When nbcore is greater than 1, multiple cores may
>> use the same queue to forward packet, like:
>> dpdk-
On 2023/10/8 10:47, fengchengwen wrote:
> Hi Dengdui,
>
> On 2023/10/8 9:56, Dengdui Huang wrote:
>> Command help string is missing 'mcast_addr add|remove'.
>> This patch add it.
>>
>> Fixes: 8fff667578a7 ("app/testpmd: new command to add/remove multicast MAC
>> addresses")
>> Cc: sta...@dpdk.
On 2023/9/29 1:23, Ferruh Yigit wrote:
> On 8/2/2023 7:23 AM, Dengdui Huang wrote:
>> Add command to flush multicast MAC address
>> Usage:
>> mcast_addr flush :
>> flush multicast MAC address on port_id
>>
>> Signed-off-by: Dengdui Huang
>> ---
>> app/test-pmd/cmdline.c
在 2023/8/2 12:16, Stephen Hemminger 写道:
> On Wed, 2 Aug 2023 10:41:46 +0800
> huangdengdui wrote:
>
>> 在 2023/8/1 23:18, Stephen Hemminger 写道:
>>> On Tue, 1 Aug 2023 10:43:04 +0800
>>> Dengdui Huang wrote:
>>>
>>>> diff --git a/app/
在 2023/8/1 23:18, Stephen Hemminger 写道:
> On Tue, 1 Aug 2023 10:43:04 +0800
> Dengdui Huang wrote:
>
>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
>> index 0d0723f659..2d9d925776 100644
>> --- a/app/test-pmd/cmdline.c
>> +++ b/app/test-pmd/cmdline.c
>> @@ -494,6 +494,9 @@ sta
在 2023/8/1 23:18, Stephen Hemminger 写道:
> On Tue, 1 Aug 2023 10:43:04 +0800
> Dengdui Huang wrote:
>
>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
>> index 0d0723f659..2d9d925776 100644
>> --- a/app/test-pmd/cmdline.c
>> +++ b/app/test-pmd/cmdline.c
>> @@ -494,6 +494,9 @@ sta
Hi Cheng,
Few comments inline. Please check.
Thanks,
Dengdui
On 2023/6/13 12:31, Cheng Jiang wrote:
> There are many high-performance DMA devices supported in DPDK now, and
> these DMA devices can also be integrated into other modules of DPDK as
> accelerators, such as Vhost. Before integrating
On 2023/6/2 20:47, Ferruh Yigit wrote:
> On 6/2/2023 8:52 AM, Dengdui Huang wrote:
>> The API rte_eth_dev_is_valid_rxq/txq which
>> is used to check if Rx/Tx queue is valid.
>> If the queue has been setup, it is considered valid.
>>
>> Signed-off-by: Dengdui Huang
>> ---
>> doc/guides/rel_notes/r
On 2023/6/2 6:13, Ferruh Yigit wrote:
> On 5/31/2023 5:31 PM, Ferruh Yigit wrote:
>> On 5/22/2023 2:58 PM, Andrew Rybchenko wrote:
>>> On 5/22/23 16:09, Dengdui Huang wrote:
The API rte_eth_dev_is_valid_rxq/txq checks
the port ID validity and then the Rx/Tx queue ID is valid.
>>>
>>> What
On 2023/5/22 21:58, Andrew Rybchenko wrote:
> On 5/22/23 16:09, Dengdui Huang wrote:
>> The API rte_eth_dev_is_valid_rxq/txq checks
>> the port ID validity and then the Rx/Tx queue ID is valid.
>
> What is valid Tx/Rx queue? It depends on on caller
> expectations. Some functions are satisfied with
On 2023/5/16 23:12, Stephen Hemminger wrote:
> On Tue, 16 May 2023 19:00:21 +0800
> Dengdui Huang wrote:
>
>> When input queue id is invalid, it will lead to
>> Segmentation fault, like:
>>
>> dpdk-testpmd -a :01:00.0 -- -i
>> testpmd> show port 0 txq/rxq 99 desc 0 status
>> Segmentation fa
62 matches
Mail list logo
