Hello,
When I tried to use the x710 NIC whose driver is i40e to enable LACP
dedicated queue, the LACP negotiation fails.
GDB debugging shows that the current packet sending function type is VECTOR.
After I forcibly change the packet
sending function to another type, LACP negotiation succeeds
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Friday, June 18, 2021 9:37 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: liucheng (J) ; dingxiaoxiong
>
> Subject: Re: [dpdk-dev] [PATCH] kni: fix wrong mbuf alloc count in
> kni_allocate
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Monday, June 21, 2021 7:26 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: liucheng (J) ; dingxiaoxiong
>
> Subject: Re: [dpdk-dev] [PATCH] kni: fix wrong mbuf alloc count in
> kni_allocate
From: Yunjian Wang
In kni_allocate_mbufs(), we alloc mbuf for alloc_q as this code.
allocq_free = (kni->alloc_q->read - kni->alloc_q->write - 1) \
& (MAX_MBUF_BURST_NUM - 1);
The value of allocq_free maybe zero, for example :
The ring size is 1024. After init, write = read = 0. Th
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Tuesday, June 22, 2021 8:28 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: tho...@monjalon.net; gowrishanka...@linux.vnet.ibm.com;
> dingxiaoxiong ; sta...@dpdk.org; liucheng (J)
>
> Sub
From: Yunjian Wang
In kni_allocate_mbufs(), we alloc mbuf for alloc_q as this code.
allocq_free = (kni->alloc_q->read - kni->alloc_q->write - 1) \
& (MAX_MBUF_BURST_NUM - 1);
The value of allocq_free maybe zero, for example :
The ring size is 1024. After init, write = read = 0. Th
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Wednesday, June 23, 2021 4:46 AM
> To: wangyunjian ; liucheng (J)
>
> Cc: dev@dpdk.org; sta...@dpdk.org; ferruh.yi...@intel.com;
> gowrishanka...@linux.vnet.ibm.com; dingxiao
From: Yunjian Wang
Currently, new user mem maps are checked if they are adjacent to
an existing mem map and if so, the mem map entries are merged.
It doesn't check for duplicate mem maps, so if the API is called
with the same mem map multiple times, they will occupy multiple
mem map entries. Thi
Hi all,
The igb_uio.ko is moved to the dpdk-kmods repository snice DPDK 20.11,
but the dpdk-kmods does not currently have any stable version.
Is there any release stable versions or LTS versions planned for dpdk-kmods
to publish?
Thanks,
Yunjian
> -Original Message-
> From: Wang, Haiyue [mailto:haiyue.w...@intel.com]
> Sent: Friday, September 17, 2021 11:47 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: Xing, Beilei ; Yang, Qiming
> ; Zhang, Qi Z ; dingxiaoxiong
>
> Subject: RE: [dpdk-dev] [PATCH 4/4] net/ixg
> -Original Message-
> From: Wang, Haiyue [mailto:haiyue.w...@intel.com]
> Sent: Wednesday, September 22, 2021 2:23 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: Xing, Beilei ; Yang, Qiming
> ; Zhang, Qi Z ; dingxiaoxiong
>
> Subject: RE: [dpdk-dev] [PATCH v2 4/4] ne
> -Original Message-
> From: Wang, Haiyue [mailto:haiyue.w...@intel.com]
> Sent: Wednesday, September 22, 2021 3:05 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: Xing, Beilei ; Yang, Qiming
> ; Zhang, Qi Z ; dingxiaoxiong
>
> Subject: RE: [dpdk-dev] [PATCH v2 4
From: Yunjian Wang
This patch fixes the use-after-free bug which was reported by Coverity
Scan in the mlx5_dma_unmap function.
Coverity issue: 371679
Fixes: 992e6df3dafe ("common/mlx5: free MR resource on device DMA unmap")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
drivers/net/mlx5/
> -Original Message-
> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> Sent: Thursday, May 4, 2023 7:46 AM
> To: Konstantin Ananyev ; wangyunjian
>
> Cc: dev@dpdk.org; luyicai ; sta...@dpdk.org; nd
> ; nd
> Subject: RE: [dpdk-dev] [PATCH v2]
> -Original Message-
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Thursday, January 5, 2023 4:34 PM
> To: wangyunjian ; Thomas Monjalon
>
> Cc: dev@dpdk.org; qi.z.zh...@intel.com; anatoly.bura...@intel.com;
> Huangshaozhang ; sta...@dpdk.org;
&g
> -Original Message-
> From: Loftus, Ciara [mailto:ciara.lof...@intel.com]
> Sent: Thursday, February 22, 2024 7:06 PM
> To: Tahhan, Maryam ; wangyunjian
>
> Cc: dev@dpdk.org; ferruh.yi...@amd.com; sta...@dpdk.org
> Subject: RE: [PATCH] net/af_xdp: fix resources le
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> Sent: Monday, December 4, 2023 10:10 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: ciara.lof...@intel.com; qi.z.zh...@intel.com; xudingke
> ; Lilijun (Jerry) ;
> sta...@dpdk.org
> Subject: Re
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> Sent: Tuesday, December 5, 2023 5:42 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: ciara.lof...@intel.com; qi.z.zh...@intel.com; xudingke
> ; Lilijun (Jerry) ;
> sta...@dpdk.org
> Subject: Re
> -Original Message-
> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> Sent: Wednesday, April 19, 2023 7:53 AM
> To: wangyunjian ; dev@dpdk.org
> Cc: konstantin.v.anan...@yandex.ru; luyicai ;
> sta...@dpdk.org; nd ; Honnappa Nagarahalli
> ; nd
> -Original Message-
> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> Sent: Thursday, April 20, 2023 5:44 AM
> To: wangyunjian ; dev@dpdk.org
> Cc: konstantin.v.anan...@yandex.ru; luyicai ;
> sta...@dpdk.org; nd ; nd
> Subject: RE: [dpdk-dev]
Friendly ping.
> -Original Message-
> From: wangyunjian
> Sent: Tuesday, August 23, 2022 2:46 PM
> To: dev@dpdk.org
> Cc: ma...@nvidia.com; rasl...@nvidia.com; viachesl...@nvidia.com;
> dkozl...@nvidia.com; Huangshaozhang ;
> wangyunjian ; sta...@dpdk.org
> Subject
Friendly ping.
> -Original Message-
> From: wangyunjian
> Sent: Tuesday, August 23, 2022 2:46 PM
> To: dev@dpdk.org
> Cc: ma...@nvidia.com; rasl...@nvidia.com; viachesl...@nvidia.com;
> dkozl...@nvidia.com; Huangshaozhang ;
> wangyunjian ; sta...@dpdk.org
> Subject
I agree with you. Can you fix it?
Thanks
Yunjian
> -Original Message-
> From: Slava Ovsiienko [mailto:viachesl...@nvidia.com]
> Sent: Tuesday, September 27, 2022 3:36 AM
> To: wangyunjian ; dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; Dmitry Kozlyuk
Hi All,
It is expected that the ixgbe_dev_set_link_down function is called to make
the link status of the NIC down. However, the invoking is successful, but
link status is still up. Anyone have some good ideas?
dpdk version:DPDK 21.11
firmware-version:0x86d5
NIC:Intel Corporation 82599 10 G
Friendly ping.
> -Original Message-
> From: wangyunjian
> Sent: Monday, December 7, 2020 7:09 PM
> To: dev@dpdk.org
> Cc: david.march...@redhat.com; tho...@monjalon.net;
> anatoly.bura...@intel.com; Lilijun (Jerry) ;
> xudingke
> ; wangyunjian ;
> sta...@dp
From: Yunjian Wang
Coverity flags that 'ctx->tunnel' variable is used before
it's checked for NULL. This patch fixes this issue.
Coverity issue: 366201
Fixes: 868d2e342cf3 ("net/mlx5: fix tunnel offload hub multi-thread protection")
Signed-off-by: Yunjian Wang
---
drivers/net/mlx5/mlx5_flow.c
> -Original Message-
> From: Slava Ovsiienko [mailto:viachesl...@nvidia.com]
> Sent: Friday, March 26, 2021 9:24 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: Matan Azrad ; Shahaf Shuler ;
> Lilijun (Jerry) ; chenchanghu
>
> Subject: RE: [dpdk-dev] [PATCH] net/mlx
From: Yunjian Wang
Coverity flags that 'ctx->tunnel' variable is used before
it's checked for NULL. This patch fixes this issue.
Coverity issue: 366201
Fixes: 868d2e342cf3 ("net/mlx5: fix tunnel offload hub multi-thread protection")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
Acked-by: Via
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Maxime Coquelin
> Sent: Wednesday, March 24, 2021 5:55 PM
> To: Marvin Liu ; chenbo@intel.com
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] vhost: fix accessing uninitialized variables
>
From: Yunjian Wang
This series include two fixes patches for mlx4/mlx5.
Yunjian Wang (2):
net/mlx4: fix mem leak when a device configured repeatedly
net/mlx5: fix mem leak when a device configured repeatedly
drivers/net/mlx4/mlx4.c | 2 ++
drivers/net/mlx5/mlx5.c | 2 ++
2 files changed, 4
From: Yunjian Wang
Currently, configuring a mlx device, it will allocate its
own process private in mlx5_proc_priv_init() and only frees
it when closing the device. This will lead to a memory leak,
when a device is configured repeatedly.
For example:
for(...)
do
rte_eth_dev_configure
From: Yunjian Wang
Currently, configuring a mlx device, it will allocate its
own process private in mlx5_proc_priv_init() and only frees
it when closing the device. This will lead to a memory leak,
when a device is configured repeatedly.
For example:
for(...)
do
rte_eth_dev_configure
> -Original Message-
> From: Slava Ovsiienko [mailto:viachesl...@nvidia.com]
> Sent: Wednesday, May 12, 2021 10:05 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: Matan Azrad ; Shahaf Shuler ;
> dingxiaoxiong ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 1/2] net/ml
From: Yunjian Wang
This series include two fixes patches for mlx4/mlx5.
---
v2:
* remove redundant empty line
Yunjian Wang (2):
net/mlx4: fix mem leak when a device configured repeatedly
net/mlx5: fix mem leak when a device configured repeatedly
drivers/net/mlx4/mlx4.c | 1 +
drivers/n
From: Yunjian Wang
Currently, configuring a mlx device, it will allocate its
own process private in mlx5_proc_priv_init() and only frees
it when closing the device. This will lead to a memory leak,
when a device is configured repeatedly.
For example:
for(...)
do
rte_eth_dev_configure
rte
From: Yunjian Wang
Currently, configuring a mlx device, it will allocate its
own process private in mlx5_proc_priv_init() and only frees
it when closing the device. This will lead to a memory leak,
when a device is configured repeatedly.
For example:
for(...)
do
rte_eth_dev_configure
rte
From: Yunjian Wang
In kni_allocate_mbufs(), we alloc mbuf for alloc_q as this code.
allocq_free = (kni->alloc_q->read - kni->alloc_q->write - 1) \
& (MAX_MBUF_BURST_NUM - 1);
The value of allocq_free maybe zero (e.g 32 & (32 - 1) = 0), and
it will not fill the alloc_q. When the al
From: Yunjian Wang
The ethdev port id should be 16 bits now. This patch fixes the data
type of the variable for 'pid', changing from uint32_t to uint16_t.
Fixes: 5b7ba31148a8 ("ethdev: add port ownership")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
lib/librte_ethdev/rte_ethdev.c | 2
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Monday, October 26, 2020 8:34 PM
> To: Andrew Rybchenko
> Cc: wangyunjian ; dev@dpdk.org;
> ferruh.yi...@intel.com; Lilijun (Jerry) ; xudingke
> ; ma...@nvidia.com
> Subject: Re: [
From: Yunjian Wang
Coverity flags that 'h' variable is used before
it's checked for NULL. This patch fixes this issue.
Coverity issue: 363625
Fixes: 769b2de7fb52 ("hash: implement RCU resources reclamation")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
lib/librte_hash/rte_cuckoo_hash.c
From: Yunjian Wang
The ethdev port id should be 16 bits now. This patch fixes the data
type of the variable for 'pid', changing from uint32_t to uint16_t.
We also need use RTE_BUILD_BUG_ON() to ensure that RTE_MAX_ETHPORTS
is less or equal to UINT16_MAX.
Fixes: 5b7ba31148a8 ("ethdev: add port o
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Tuesday, October 27, 2020 10:29 PM
> To: wangyunjian
> Cc: dev@dpdk.org; ferruh.yi...@intel.com; andrew.rybche...@oktetlabs.ru;
> Lilijun (Jerry) ; xudingke ;
> wangyunjian ; sta...@d
> -Original Message-
> From: wangyunjian
> Sent: Tuesday, September 22, 2020 8:06 PM
> To: 'Harman Kalra'
> Cc: dev@dpdk.org; david.march...@redhat.com; ferruh.yi...@intel.com;
> Thomas Monjalon ; Lilijun (Jerry)
> ; xudingke ;
> sta...@dpdk.org
> Sub
From: Yunjian Wang
The ethdev port id is 16 bits now. This patch fixes the data type
of the variable for 'pid', which changing from uint32_t to uint16_t.
RTE_MAX_ETHPORTS is the maximum number of ports, which customized by
the user. To avoid 16-bit unsigned integer overflow, the valid value
of R
From: Yunjian Wang
The function rte_zmalloc() could return NULL, the return value
need to be checked.
Fixes: dc49e6aa4879 ("compress/isal: add ISA-L compression functionality")
Fixes: 7bf4f0630af6 ("compress/isal: add ISA-L decomp functionality")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
In function fill_vec_buf, it will happen uint32_t cast to uint16_t, when the
*desc_chain_len is assigned by the len.
This maybe result in data truncation.
static inline int __attribute__((always_inline))
fill_vec_buf(struct virtio_net *dev, struct vhost_virtqueue *vq,
The commit 414b202343ce8ad (bonding: fix initial link status of slave) invokes
lsc callback,
the lsc callback may be executed at same time when slave_configure() and
bond_ethdev_slave_link_status_change_monitor ()
competing for calling the lsc callback. The panic will be triggered when bond
ethd
From: Yunjian Wang
This patch fixes the variable 'phy_word' may be used uninitialized.
Fixes: 5b6439cf03a4ca3 ("e1000/base: support different EEARBC for i210")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
drivers/net/e1000/base/e1000_i210.c | 1 +
1 file changed, 1 insertion(+)
diff -
From: Yunjian Wang
We assume VLAN ethtertype is 0x8100 in get_vlan_offset() function,
but it could be 0x88A8 if QinQ is supported.
Signed-off-by: Yunjian Wang
---
drivers/net/bonding/rte_eth_bond_pmd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/rt
From: Yunjian Wang
Now sending 0 packet it doesn't consider for LACPDUs,
but the LACPDUs should be checked and sended.
Fixes: 09150784a776 ("net/bonding: burst mode hash calculation")
Cc: sta...@dpdk.org
Reported-by: Hui Zhao
Signed-off-by: Yunjian Wang
---
drivers/net/bonding/rte_eth_bond_p
I agree with you. Can you fix it?
Thanks
Yunjian
> -Original Message-
> From: Chas Williams [mailto:3ch...@gmail.com]
> Sent: Monday, February 11, 2019 11:35 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: ch...@att.com; xudingke ; sta...@dpdk.org
> Subject: Re: [dpd
From: Yunjian Wang
The nic's interrupt source has some active handler, when the
port remove. We should cancel the delay handler before remove
dev to prevent executing the delay handler.
Call Trace:
#0 ixgbe_disable_intr (hw=0x0, hw=0x0)
at /usr/src/debug/dpdk-18.11/drivers/net/ixgbe/ixg
I think the flow list may be accessed in the same time by two
different threads and may cause some errors. Do it need a lock
to protect the flow list?
Thanks
Yunjian
(gdb) bt
#0 0x7f54c9641237 in raise () from /usr/lib64/libc.so.6
#1 0x7f54c9642928 in abort () from /usr/lib64/li
> -Original Message-
> From: Zhang, Qi Z [mailto:qi.z.zh...@intel.com]
> Sent: Tuesday, February 26, 2019 1:35 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: xudingke ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: fix crash when on remove
>
> Hi:
>
From: Yunjian Wang
The nic's interrupt source has some active callbacks, when
the port hotplug. Add a retry to give more port's a chance
to uninit before returning an error.
Fixes: d42aaf30008b ("i40e: support port hotplug")
Signed-off-by: Yunjian Wang
---
drivers/net/i40e/i40e_ethdev.c | 16
eal_intr_thread_main (arg=)at
/usr/src/debug/dpdk-16.11/lib/librte_eal/linuxapp/eal/eal_interrupts.c:975
#8 start_thread () from /usr/lib64/libpthread.so.0
#9 clone () from /usr/lib64/libc.so.6
> -Original Message-
> From: wangyunjian
> Sent: Saturday, March 10, 2018 2:51 PM
> To:
From: Yunjian Wang
The nic's interrupt source has some active callbacks, when
the port hotplug. Add a retry to give more port's a chance
to uninit before returning an error.
Fixes: d42aaf30008b ("i40e: support port hotplug")
Signed-off-by: Yunjian Wang
---
v2:
* Fix return value check
---
dri
> -Original Message-
> From: wangyunjian
> Sent: Saturday, March 10, 2018 2:51 PM
> To: dev@dpdk.org
> Cc: caihe ; wangyunjian
> Subject: [dpdk-dev] net/i40e: fix intr callback unregister by adding retry
>
> From: Yunjian Wang
>
> The nic's interru
> -Original Message-
> From: Rybalchenko, Kirill [mailto:kirill.rybalche...@intel.com]
> Sent: Wednesday, March 14, 2018 7:04 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: caihe
> Subject: RE: [dpdk-dev] [PATCH v2] net/i40e: fix intr callback unregister by
> adding
From: Yunjian Wang
The nic's interrupt source has some active callbacks, when
the port hotplug. Add a retry to give more port's a chance
to uninit before returning an error.
Fixes: d42aaf30008b ("i40e: support port hotplug")
Signed-off-by: Yunjian Wang
---
v2:
* Fix return value check
---
v3:
Original Message-
> From: Zhang, Qi Z [mailto:qi.z.zh...@intel.com]
> Sent: Wednesday, March 14, 2018 9:42 PM
> To: Rybalchenko, Kirill ; wangyunjian
> ; dev@dpdk.org
> Cc: caihe
> Subject: RE: [dpdk-dev] [PATCH v3] net/i40e: fix intr callback unregister by
> adding ret
Hi Zhang Qi:
> -Original Message-
> From: Zhang, Qi Z [mailto:qi.z.zh...@intel.com]
> Sent: Tuesday, March 20, 2018 11:27 AM
> To: wangyunjian ; Rybalchenko, Kirill
> ; dev@dpdk.org
> Cc: caihe
> Subject: RE: [dpdk-dev] [PATCH v3] net/i40e: fix intr callback unregis
From: Yunjian Wang
The nic's interrupt source has some active callbacks, when
the port hotplug. Add a retry to give more port's a chance
to uninit before returning an error.
Fixes: d42aaf30008b ("i40e: support port hotplug")
Signed-off-by: Yunjian Wang
Reviewed-by: Kirill Rybalchenko
Acked-by
From: Yunjian Wang
The nic's interrupt source has some active callbacks, when
the port hotplug. Add a retry to give more port's a chance
to uninit before returning an error.
Fixes: 2866c5f1b87e ("ixgbe: support port hotplug")
Signed-off-by: Yunjian Wang
---
drivers/net/ixgbe/ixgbe_ethdev.c |
> -Original Message-
> From: Tiwei Bie [mailto:tiwei@intel.com]
> Sent: Monday, December 16, 2019 1:33 PM
> To: wangyunjian
> Cc: dev@dpdk.org; maxime.coque...@redhat.com; zhihong.w...@intel.com;
> xudingke ; sta...@dpdk.org
> Subject: Re: [PATCH] net/vhost
Thanks, I will fix it in v3.
Yunjian
> -Original Message-
> From: Tiwei Bie [mailto:tiwei@intel.com]
> Sent: Tuesday, January 7, 2020 10:32 AM
> To: wangyunjian
> Cc: dev@dpdk.org; maxime.coque...@redhat.com; zhihong.w...@intel.com;
> xudingke ; sta...@dpdk.org
>
> -Original Message-
> From: Tiwei Bie [mailto:tiwei@intel.com]
> Sent: Monday, January 13, 2020 10:16 AM
> To: wangyunjian
> Cc: dev@dpdk.org; maxime.coque...@redhat.com; zhihong.w...@intel.com;
> xudingke ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2]
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Monday, January 20, 2020 8:43 PM
> To: wangyunjian ; dev@dpdk.org;
> keith.wi...@intel.com
> Cc: xudingke ; sta...@dpdk.org
> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] net/tap:
> -Original Message-
> From: Jeff Guo [mailto:jia@intel.com]
> Sent: Friday, June 12, 2020 1:56 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: Lilijun (Jerry) ; xudingke
> ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 2/3] eal: fix remove incorrect event_cb
>
From: Yunjian Wang
The event_cb->dev_name is not freed when freeing event_cb,
and this causes a memory leak.
Fixes: a753e53d517b ("eal: add device event monitor framework")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
lib/librte_eal/common/eal_common_dev.c | 2 ++
1 file changed, 2 ins
> -Original Message-
> From: Jeff Guo [mailto:jia@intel.com]
> Sent: Thursday, July 2, 2020 5:19 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: Lilijun (Jerry) ; xudingke
> ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 3/3] eal: return error code when failure
>
Hi, Jeff
> -Original Message-
> From: Jeff Guo [mailto:jia@intel.com]
> Sent: Thursday, July 2, 2020 5:28 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: Lilijun (Jerry) ; xudingke
> ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] eal: fix memory leak when removi
From: Yunjian Wang
v3: modified the format.
This series include two fixes patches for device event.
Yunjian Wang (2):
eal: fix memory leak when removing event_cb
eal: return error code when failure
lib/librte_eal/common/eal_common_dev.c | 10 +-
1 file changed, 9 insertions(+), 1
From: Yunjian Wang
Fix return value, using -EAGAIN instead of 0 when the callback is busy
and using -ENOENT instead of 0 when the callback is not found.
Fixes: a753e53d517b ("eal: add device event monitor framework")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
Acked-by: Jeff Guo
---
lib/
From: Yunjian Wang
The event_cb->dev_name is not freed when freeing event_cb,
and this causes a memory leak.
Fixes: a753e53d517b ("eal: add device event monitor framework")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
lib/librte_eal/common/eal_common_dev.c | 2 ++
1 file changed, 2 ins
Hi, Jeff
> -Original Message-
> From: Jeff Guo [mailto:jia@intel.com]
> Sent: Friday, July 3, 2020 2:05 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: Lilijun (Jerry) ; xudingke
> ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/2] eal: fix memory leak whe
> -Original Message-
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Friday, July 3, 2020 3:23 PM
> To: wangyunjian
> Cc: dev ; Jeff Guo ; Lilijun (Jerry)
> ; xudingke ; dpdk stable
>
> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3 1/2] e
From: Yunjian Wang
This series include three fixes patches for device event.
---
v4:
* add fix a wrong returned value
* remove redundant check suggested by David Marchand
v3:
* modified the format.
Yunjian Wang (3):
eal: fix memory leak when removing event_cb
eal: return error code when
From: Yunjian Wang
The event_cb->dev_name is not freed when freeing event_cb,
and this causes a memory leak.
Fixes: a753e53d517b ("eal: add device event monitor framework")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
lib/librte_eal/common/eal_common_dev.c | 1 +
1 file changed, 1 inse
From: Yunjian Wang
Fix return value, using -EAGAIN instead of 0 when the callback is busy
and using -ENOENT instead of 0 when the callback is not found.
Fixes: a753e53d517b ("eal: add device event monitor framework")
Cc: sta...@dpdk.org
Acked-by: Jeff Guo
Signed-off-by: Yunjian Wang
---
lib/
From: Yunjian Wang
We should return an error value, when the callback is already exist.
Fixes: a753e53d517b ("eal: add device event monitor framework")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
lib/librte_eal/common/eal_common_dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 delet
From: Yunjian Wang
This series include three fixes patches for af_packet driver.
Yunjian Wang (3):
net/af_packet: fix check of file descriptors
net/af_packet: fix mem leak on init failure
net/af_packet: fix wrong munmap on init failure
drivers/net/af_packet/rte_eth_af_packet.c | 26 +
From: Yunjian Wang
Zero is a valid fd. It will fail to check the fd if the fd is zero.
Fixes: 527740ccfaec ("af_packet: fix some leaks")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
drivers/net/af_packet/rte_eth_af_packet.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
From: Yunjian Wang
Add a missing available check and fix the wrong address passed
to munmap on init failure.
Fixes: dd6590fe2fd7 ("af_packet: fix possible memory leak")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
drivers/net/af_packet/rte_eth_af_packet.c | 5 +++--
1 file changed, 3 i
From: Yunjian Wang
Add missing code to free memory when the device initialization fails.
Fixes: ccd37d341e8d ("net/af_packet: remove queue number limitation")
Fixes: 5f19dee604ed ("drivers/net: do not use private ethdev data")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
drivers/net/af
From: Yunjian Wang
In fslmc_process_mcp(), we allocate memory for 'dev_name' but not released
before return in secondary process.
Coverity issue: 268327
Fixes: e55d0494ab98 ("bus/fslmc: support secondary process")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
drivers/bus/fslmc/fslmc_vfi
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Wednesday, April 15, 2020 11:15 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: keith.wi...@intel.com; Lilijun (Jerry) ;
> xudingke
> ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 5
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Wednesday, April 15, 2020 11:13 PM
> To: wangyunjian ; dev@dpdk.org
> Cc: keith.wi...@intel.com; Lilijun (Jerry) ;
> xudingke
> ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4
From: Yunjian Wang
This series include five fixes patches for tap PMD driver.
--
v5:
* fix check fd error
v4:
* Update some code suggested by Ferruh Yigit and Stephen Hemminger
* Update commit log
* Add fix leak of fds on failure
v3:
* Add fix close a vaild fd and netlink socket file descriptor
From: Yunjian Wang
When the tap_write_mbufs() function return with break, mbuf was freed
without increasing num_packets, which could cause applications to free
the mbuf again. And the pmd_tx_burst() function should returns the
number of original packets it actually sent excluding tso mbufs.
Fixe
From: Yunjian Wang
For the tap PMD, we should release mbufs and iovecs from the Rx queue when
closing device. In order to remove duplicated code, rte_pmd_tap_remove()
calls tap_dev_close().
Fixes: 0781f5762cfe ("net/tap: support segmented mbufs")
CC: sta...@dpdk.org
Reviewed-by: Ferruh Yigit
S
From: Yunjian Wang
Now the rxq->pool is mbuf concatenation, but its nb_segs is 1. When
conducting some sanity checks on the mbuf with debug enabled, it fails.
Fixes: 0781f5762cfe ("net/tap: support segmented mbufs")
CC: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
drivers/net/tap/rte_eth_t
From: Yunjian Wang
The internal structure is freed and set to NULL in the
rte_eth_dev_release_port() and zero is a valid fd. Ultimately
leads to a valid fd was closed by mistake.
Fixes: 3101191c63ab ("net/tap: fix device removal when no queue exist")
CC: sta...@dpdk.org
Reviewed-by: Ferruh Yigi
From: Yunjian Wang
When eth_dev_tap_create() is failed, nlsk_fd and ka_fd won't be closed
thus leading fds leak. Zero is a valid fd. Ultimately leads to a valid
fd was closed by mistake.
Fixes: bf7b7f437b49 ("net/tap: create netdevice during probing")
Fixes: cb7e68da630a ("net/tap: fix cleanup o
From: Yunjian Wang
The nic's interrupt source has some active handler, which maybe call
tap_dev_intr_handler() to set link handler. We should cancel the link
handler before close fd to prevent executing the link handler. It
triggers segfault.
Call Trace:
0x7f15e08dad99 in __rte_panic (Err
From: Yunjian Wang
The fd is possibly a negative value while it is passed as an
argument to function "close". Fix the check to the fd.
Fixes: ed8132e7c912 ("net/tap: move fds of queues to be in process private")
CC: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
drivers/net/tap/rte_eth_tap.c
From: Yunjian Wang
Zero is a valid fd. When ccp_probe_device() is failed, the uio_fd won't be
closed thus leading fd leak.
Fixes: ef4b04f87fa6 ("crypto/ccp: support device init")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
drivers/crypto/ccp/ccp_dev.c | 2 +-
1 file changed, 1 inserti
From: Yunjian Wang
Zero is a valid fd. It will fail to check the fd if the fd is zero.
Fixes: e7a45f3cc245 ("crypto/caam_jr: add UIO specific operations")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
drivers/crypto/caam_jr/caam_jr_uio.c | 6 +++---
1 file changed, 3 insertions(+), 3 de
From: Yunjian Wang
Zero is a valid fd. The fd won't be closed thus leading fd leak,
when it is zero.
Fixes: f234e5bd996d ("net/failsafe: register slaves Rx interrupts")
Fixes: 9e0360aebf23 ("net/failsafe: register as Rx interrupt mode")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
driv
> -Original Message-
> From: Gagandeep Singh [mailto:g.si...@nxp.com]
> Sent: Sunday, May 10, 2020 1:54 PM
> To: wangyunjian ; dev@dpdk.org; Akhil Goyal
>
> Cc: Hemant Agrawal ; Lilijun (Jerry)
> ; xudingke ;
> sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH
1 - 100 of 279 matches
Mail list logo
