We need to differentiate between crypto and ethernet security
context as they belong to different devices.
Fixes: d82d6ac64338 ("app/procinfo: add crypto security context info")
Cc: sta...@dpdk.org
Signed-off-by: Hemant Agrawal
---
app/proc-info/main.c | 13 +
1 file changed, 9 inse
Refactor the vhost sample code. Add ioat ring space count and check
in ioat callback, optimize vhost data path for batch enqueue, replase
rte_atomicNN_xxx to atomic_XXX and refactor vhost async data path.
---
v3:
* added some variable initiation
* cleaned some codes
v2:
* optimized patch struct
Add ioat ring space count and check, if ioat ring space is not enough
for the next async vhost packet enqueue, then just return to prevent
enqueue failure.
Signed-off-by: Cheng Jiang
---
examples/vhost/ioat.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/exa
Change the vm2vm data path to batch enqueue for better performance.
Support latest async vhost API, refactor vhost async data path,
replase rte_atomicNN_xxx to atomic_XXX and clean some codes.
Signed-off-by: Cheng Jiang
---
examples/vhost/main.c | 168 ++
Tested-by: Huang, ZhiminX
Regards,
HuangZhiMin
> -Original Message-
> From: dev On Behalf Of Zhang,Alvin
> Sent: Wednesday, December 23, 2020 1:30 PM
> To: Xing, Beilei ; Xu, Ting
> Cc: dev@dpdk.org; Zhang, AlvinX ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH] net/iavf: fix queue pai
Some fixes and enchancements in the core bnxt PMD
Somnath Kotur (3):
net/bnxt: fix to init/destroy locks only once
net/bnxt: fix error path handling of dev start op
net/bnxt: check for chip reset in dev stop/close ops
drivers/net/bnxt/bnxt.h| 5 +
drivers/net/bnxt/bnxt_cpr.c|
Invoking init/uninit locks in init_resources and uninit_resources
would end up initializing and destroying locks on every port start
stop which is not desired.
Move the 2 routines to dev_init and dev_close respectively as
locks need to be initialized and destroyed only once during the
lifetime of t
While the error recovery thread is running, an application
can invoke dev_stop or dev_close_op thus triggering a race
and unwanted consequences if dev_close is invoked while the
recovery is not yet completed.
Fix by having another lock to synchronize between the 2 threads and
return EGAIN if adapte
Call bnxt_dev_stop in error path of bnxt_dev_start_op() to keep
it simple and consistent
Fixes: c09f57b49c13 ("net/bnxt: add start/stop/link update operations")
Cc: sta...@dpdk.org
Signed-off-by: Somnath Kotur
---
drivers/net/bnxt/bnxt_ethdev.c | 144 -
1 file ch
From: Karra Satwik
Request the driver for number of entries in the FEC caps
array and then dynamically allocate the array.
Signed-off-by: Karra Satwik
Signed-off-by: Rahul Lakkireddy
Acked-by: Xiaoyun Li
---
v3:
- Use unsigned int num, instead of int num
v2:
- Replace if (!speed_fec_capa) wi
snipped
>
> Thanks for your comments.
> I know you kindly provided many valuable comments though I reply the
> following first because I think it is important that my idea/proposal is
> acceptable or not first.
>
> > Sharing an alternate approach, if RX-TX callbacks are enabled in DPDK (which
> i
> -Original Message-
> From: Guo, Jia
> Sent: Thursday, December 24, 2020 3:00 PM
> To: Zhang, Qi Z ; Wu, Jingjing ;
> Yang, Qiming ; Wang, Haiyue
>
> Cc: dev@dpdk.org; Guo, Jia
> Subject: [dpdk-dev v2 0/2] add new UDP tunnel port for ecpri
>
> Add new UDP tunnel type and port params
A couple of bnxt PMD fixes and an enhancement
Somnath Kotur (3):
net/bnxt: fix to init/destroy locks only once
net/bnxt: fix error path handling of dev start op
net/bnxt: check for chip reset in dev stop/close ops
drivers/net/bnxt/bnxt.h| 5 +
drivers/net/bnxt/bnxt_cpr.c| 2
While the error recovery thread is running, an application
can invoke dev_stop or dev_close_op thus triggering a race
and unwanted consequences if dev_close is invoked while the
recovery is not yet completed.
Fix by having another lock to synchronize between the 2 threads and
return EGAIN if adapte
Invoking init/uninit locks in init_resources and uninit_resources
would end up initializing and destroying locks on every port start
stop which is not desired.
Move the 2 routines to dev_init and dev_close respectively as
locks need to be initialized and destroyed only once during the
lifetime of t
Call bnxt_dev_stop in error path of bnxt_dev_start_op() to keep
it simple and consistent
Fixes: c09f57b49c13 ("net/bnxt: add start/stop/link update operations")
Signed-off-by: Somnath Kotur
---
drivers/net/bnxt/bnxt_ethdev.c | 144 -
1 file changed, 70 insertions
A couple of bnxt PMD fixes and an enhancement
Somnath Kotur (3):
net/bnxt: fix to init/destroy locks only once
net/bnxt: fix error path handling of dev start op
net/bnxt: check for chip reset in dev stop/close ops
drivers/net/bnxt/bnxt.h| 5 +
drivers/net/bnxt/bnxt_cpr.c| 2
While the error recovery thread is running, an application
can invoke dev_stop or dev_close_op thus triggering a race
and unwanted consequences if dev_close is invoked while the
recovery is not yet completed.
Fix by having another lock to synchronize between the 2 threads and
return EGAIN if adapte
Invoking init/uninit locks in init_resources and uninit_resources
would end up initializing and destroying locks on every port start
stop which is not desired.
Move the 2 routines to dev_init and dev_close respectively as
locks need to be initialized and destroyed only once during the
lifetime of t
Call bnxt_dev_stop in error path of bnxt_dev_start_op() to keep
it simple and consistent
Fixes: c09f57b49c13 ("net/bnxt: add start/stop/link update operations")
Signed-off-by: Somnath Kotur
---
drivers/net/bnxt/bnxt_ethdev.c | 144 -
1 file changed, 70 insertions
Acked-by: Min Hu (Connor)
在 2020/12/24 19:18, Rahul Lakkireddy 写道:
From: Karra Satwik
Request the driver for number of entries in the FEC caps
array and then dynamically allocate the array.
Signed-off-by: Karra Satwik
Signed-off-by: Rahul Lakkireddy
Acked-by: Xiaoyun Li
---
v3:
- Use unsi
Async enqueue offloads large copies to DMA devices, and small copies
are still performed by the CPU. However, it requires users to get
enqueue completed packets by rte_vhost_poll_enqueue_completed(), even
if they are completed by the CPU when rte_vhost_submit_enqueue_burst()
returns. This design in
This patch removes unnecessary check and function calls, and it changes
appropriate types for internal variables and fixes typos.
Signed-off-by: Jiayu Hu
---
lib/librte_vhost/rte_vhost_async.h | 6 +++---
lib/librte_vhost/virtio_net.c | 16
2 files changed, 11 insertions(+
Async enqueue offloads large copies to DMA devices, and small copies
are still performed by the CPU. However, it requires users to get
enqueue completed packets by rte_vhost_poll_enqueue_completed(), even
if they are completed by the CPU when rte_vhost_submit_enqueue_burst()
returns. This design in
On Thu, 24 Dec 2020 11:57:48 +0800
dapengx...@intel.com wrote:
> From: YU DAPENG
>
> In interactive mode, if testpmd exit by calling rte_exit without cmdline
> resource release, terminal will not echo keyboard input. So add code to
> just show error message, but not exit testpmd when unexpected
Hi Stephen,
Do you mean this solution?
1. support atexit() in librte_eal, other component can use it to register a
function to be called when rte_exit() is called.
2. in librte_cmdline, use atexit() to register a function to release resource
I am looking forward to more comments from other main
> -Original Message-
> From: Yan, Zhirun
> Sent: Monday, December 21, 2020 2:52 PM
> To: dev@dpdk.org; Zhang, Qi Z ; Cao, Yahui
> ; Wang, Xiao W ;
> Guo, Junfeng
> Cc: Su, Simei ; Xu, Ting ; Zhang,
> Yuying ; Yan, Zhirun
>
> Subject: [PATCH v1 2/5] net/ice: refactor flow pattern par
> -Original Message-
> From: Yan, Zhirun
> Sent: Monday, December 21, 2020 2:52 PM
> To: dev@dpdk.org; Zhang, Qi Z ; Cao, Yahui
> ; Wang, Xiao W ;
> Guo, Junfeng
> Cc: Su, Simei ; Xu, Ting ; Zhang,
> Yuying ; Yan, Zhirun
>
> Subject: [PATCH v1 3/5] net/ice: add outer input set mask
I suggest that you can merge this commit into the Patch 3/5, since they are
all about input set mask changes.
> -Original Message-
> From: Yan, Zhirun
> Sent: Monday, December 21, 2020 2:52 PM
> To: dev@dpdk.org; Zhang, Qi Z ; Cao, Yahui
> ; Wang, Xiao W ;
> Guo, Junfeng
> Cc: Su, Sim
The performance of our simple scheme is better than asan. We are trying the
asan solution.
Regards,
Peng,Zhihong
-Original Message-
From: Stephen Hemminger
Sent: Tuesday, December 22, 2020 2:44 AM
To: Peng, ZhihongX
Cc: Wang, Haiyue ; Zhang, Qi Z ;
Xing, Beilei ; dev@dpdk.org; Lin, X
30 matches
Mail list logo
