RE: [PATCH] raw/ntb: add check for DB intr handler registering
> -Original Message-
> From: Thomas Monjalon
> Sent: Tuesday, March 8, 2022 01:07
> To: Wu, Jingjing ; Guo, Junfeng
>
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [PATCH] raw/ntb: add check for DB intr handler registering
>
> 10/02/2022 11:43, Guo, Junfeng:
> >
> > > -Original Message-
> > > From: Guo, Junfeng
> > > Sent: Thursday, February 10, 2022 15:18
> > > To: Wu, Jingjing
> > > Cc: dev@dpdk.org; sta...@dpdk.org
> > > Subject: RE: [PATCH] raw/ntb: add check for DB intr handler
> registering
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Wu, Jingjing
> > > > Sent: Thursday, February 10, 2022 15:05
> > > > To: Guo, Junfeng
> > > > Cc: dev@dpdk.org; sta...@dpdk.org
> > > > Subject: RE: [PATCH] raw/ntb: add check for DB intr handler
> registering
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Guo, Junfeng
> > > > > Sent: Thursday, February 10, 2022 2:29 PM
> > > > > To: Wu, Jingjing
> > > > > Cc: dev@dpdk.org; sta...@dpdk.org; Guo, Junfeng
> > > >
> > > > > Subject: [PATCH] raw/ntb: add check for DB intr handler
> registering
> > > > >
> > > > > The callback registering of doorbell interrupt handler should be
> > > > > finished before enabling the interrupt event fd. Thus add the return
> > > > > value check for this callback registering.
> > > > >
> > > > > Fixes: 62012a76811e ("raw/ntb: add handshake process")
> > > > > Cc: sta...@dpdk.org
> > > > >
> > > > > Signed-off-by: Junfeng Guo
> > > > > ---
> > > > > drivers/raw/ntb/ntb.c | 8 ++--
> > > > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/raw/ntb/ntb.c b/drivers/raw/ntb/ntb.c
> > > > > index cc611dfbb9..0801e6d1ae 100644
> > > > > --- a/drivers/raw/ntb/ntb.c
> > > > > +++ b/drivers/raw/ntb/ntb.c
> > > > > @@ -1403,8 +1403,12 @@ ntb_init_hw(struct rte_rawdev *dev,
> > > struct
> > > > rte_pci_device
> > > > > *pci_dev)
> > > > >
> > > > > intr_handle = pci_dev->intr_handle;
> > > > > /* Register callback func to eal lib */
> > > > > - rte_intr_callback_register(intr_handle,
> > > > > -ntb_dev_intr_handler, dev);
> > > > > + ret = rte_intr_callback_register(intr_handle,
> > > > > + ntb_dev_intr_handler,
> dev);
> > > > > + if (ret) {
> > > > > + NTB_LOG(ERR, "Unable to register doorbell intr
> > > > handler.");
> > > > > + return ret;
> > > > > + }
> > > > When will this register failure happen? Have you checked what is the
> > > root
> > > > cause?
> > >
> > > When bind with vfio-pci, the DB interrupt callback function often
> cannot
> > > work as expected.
> > > I think this is due to that, the intr callback registering not finished
> before
> > > event fd enabled.
> > > Add the check of the return value here can make sure about correct
> > > processing sequence.
> >
> > I think some compiler optimization would lead to this condition.
> > So add return value check can prevent this (i.e., registering not finished).
>
> There is no formal ack. What is the status of this patch?
>
Thanks for the reminding!
Currently, we agreed that this fix is not for the root cause of no response of
doorbell
interrupt when building the connection between two NTB ports. So we decided to
change the status to be superseded and do further investigation for NTB.
Thanks for the reviewing!
>
>
Re: [PATCH] raw/ntb: add check for DB intr handler registering
08/03/2022 09:08, Guo, Junfeng: > From: Thomas Monjalon > > There is no formal ack. What is the status of this patch? > > > > Thanks for the reminding! > Currently, we agreed that this fix is not for the root cause of no response > of doorbell > interrupt when building the connection between two NTB ports. So we decided to > change the status to be superseded and do further investigation for NTB. > Thanks for the reviewing! In this case, it should not be superseded but rejected.
RE: [PATCH] raw/ntb: add check for DB intr handler registering
> -Original Message- > From: Thomas Monjalon > Sent: Tuesday, March 8, 2022 16:10 > To: Wu, Jingjing ; Guo, Junfeng > > Cc: dev@dpdk.org; sta...@dpdk.org > Subject: Re: [PATCH] raw/ntb: add check for DB intr handler registering > > 08/03/2022 09:08, Guo, Junfeng: > > From: Thomas Monjalon > > > There is no formal ack. What is the status of this patch? > > > > > > > Thanks for the reminding! > > Currently, we agreed that this fix is not for the root cause of no > response of doorbell > > interrupt when building the connection between two NTB ports. So we > decided to > > change the status to be superseded and do further investigation for NTB. > > Thanks for the reviewing! > > In this case, it should not be superseded but rejected. > Sure, thanks for your comment! >
[Bug 955] build failure in qos_sched example app
https://bugs.dpdk.org/show_bug.cgi?id=955
Bug ID: 955
Summary: build failure in qos_sched example app
Product: DPDK
Version: 20.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: examples
Assignee: dev@dpdk.org
Reporter: alia...@nvidia.com
Target Milestone: ---
"""
$ meson --werror -Dexamples=all build && ninja -C build
[..]
examples/qos_sched/args.c: In function 'app_parse_args':
examples/qos_sched/args.c:413:28: error: implicit declaration of function
'RTE_BIT64'; did you mean 'RTE_BE64'? [-Werror=implicit-function-declaration]
413 | if (app_used_core_mask & RTE_BIT64(app_main_core)) {
|^
|RTE_BE64
examples/qos_sched/args.c:413:28: error: nested extern declaration of
'RTE_BIT64' [-Werror=nested-externs]
cc1: all warnings being treated as errors
"""
Also reproduces with clang:
"""
$ meson --werror --buildtype=debugoptimized -Dexamples=all build && ninja -C
build
[..]
examples/qos_sched/args.c:413:28: error: implicit declaration of function
'RTE_BIT64' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (app_used_core_mask & RTE_BIT64(app_main_core)) {
^
examples/qos_sched/args.c:419:24: error: implicit declaration of function
'RTE_BIT64' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
app_used_core_mask |= RTE_BIT64(app_main_core);
^
2 errors generated.
"""
OS: Ubuntu 20.04.4
gcc: 9.3.0
clang: 10.0.0
--
You are receiving this mail because:
You are the assignee for the bug.
Re: [DPDK/bnxt] Issues starting bnxt on an Arm server
Hello,
After upgrading the firmware on the bnxt NIC, the NIC is correctly
detected by a DPDK application with both DPDK-v20.11 and DPDK-v21.11.
Regards
Thierry
On 3/4/22 01:56, Honnappa Nagarahalli wrote:
+ Ruifeng
On Wed, Mar 2, 2022 at 9:28 AM Thierry Herbelot
wrote:
On 3/2/22 18:26, Ajit Khaparde wrote:
On Wed, Mar 2, 2022 at 9:16 AM Thierry Herbelot
wrote:
Hello Ajit
The card is not correctly probed by the kernel, and so the FW version is
not visible.
Thanks Thierry.
I thought it was just the PMD running into trouble.
Can you give details of the ARM server?
Make, Vendor, etc..?
This a Huawei server:
TaiShan 200 Server (Model 2180) aarch64, 48 cores, 2.6GHz, 64GB RAM
Ok. I tried this on a HUAWEI Kunpeng 920 running 4.18.0-
348.2.1.el8_5.aarch64.
I can load the bnxt_en kernel driver and the DPDK PMD without issues.
And I did load vfio with enable_unsafe_noiommu_mode=1 .
While we are pursuing this further internally,
I have added Honnappa to see if he can provide any insight.
There is not much information on the error.
Just wondering if it is possible to move the card to x86 machine and check the
firmware version and upgrade the firmware version there.
Ajit
Thierry
I see this in the kernel dmesg:
bnxt_en :03:00.0 (unnamed net_device) (uninitialized): Error
(timeout: 500015) msg {0x0 0x0} len:0
bnxt_en :03:00.0 (unnamed net_device) (uninitialized): Firmware not
responding, status: 0x8
And then there are no bnxt_en netdevices.
Best regards
Thierry
On 3/2/22 18:13, Ajit Khaparde wrote:
On Wed, Mar 2, 2022 at 7:13 AM Thierry Herbelot
wrote:
Hello Ajit
Thanks for the quick response.
Please keep me posted when you check on your side.
Can you tell what is the firmware version on the card?
Best regards
Thierry
On 3/2/22 16:08, Ajit Khaparde wrote:
Is this a know issue ?
No.
We have tried the Broadcom PMD on ARM server(s) and have been
able to use it without any issues.
But we can try it again and get back to you.
Thanks
Thierry Herbelot
PS: a similar error is seen for the Ethernet ports, when handled by the
kernel:
dmesg|grep bnxt
[ 57.823746] bnxt_en :03:00.0 (unnamed net_device)
(uninitialized): Error (timeout: 500015) msg {0x0 0x0} len:0
[ 59.202255] bnxt_en: probe of :03:00.0 failed with error -16
[ 60.641519] bnxt_en :03:00.1 (unnamed net_device)
(uninitialized): Error (timeout: 500015) msg {0x0 0x0} len:0
[ 61.502237] bnxt_en: probe of :03:00.1 failed with error -16
--
Thierry Herbelot
Senior Software Engineer
Tel: +33 1 39 30 92 61
http://www.6wind.com/
Follow us:
https://www.linkedin.com/company/6wind/
https://twitter.com/6WINDsoftware
https://www.youtube.com/user/6windsoftware
Re: [PATCH 0/3] small fixes suggested by Coverity scan
11/02/2022 00:09, Stephen Hemminger: > Fix some simple bugs. > > Stephen Hemminger (3): > pcapng: handle rte_ethlink_get failing > app/test_bpf: don't print eBPF program if NULL > app/dumpcap: check for failure to set promiscious Improved titles and applied, thanks.
Re: [PATCH] app/dumpcap: allow help/version without primary process
22/02/2022 11:03, Thomas Monjalon: > 25/01/2022 04:25, Ben Magistro: > > Currently dumpcap tries to initialize dpdk before parsing command line > > arguments, this makes it impossible to check version or help without > > having the primary process running already. > > > > Signed-off-by: Ben Magistro > > --- > > --- a/app/dumpcap/main.c > > +++ b/app/dumpcap/main.c > > @@ -781,8 +781,8 @@ int main(int argc, char **argv) > > > > progname = argv[0]; > > > > - dpdk_init(); > > parse_opts(argc, argv); > > + dpdk_init(); > > Stephen, Reshma, any comment? Applied, thanks.
Re: [PATCH] vhost: fix external message handlers
Hi,
On 3/7/22 19:11, David Marchand wrote:
Following a rework, external message handlers were receiving a pointer
to a vhost_user message (as stated in the API), but lost the ability to
interact with fds attached to the message.
Restore the original layout and put a build check and reminders.
Bugzilla ID: 953
Fixes: 5e0099dc709e ("vhost: remove payload size limitation")
Signed-off-by: David Marchand
---
This patch is untested, but sending quickly to get feedback from the
reporter and comments from author and maintainers.
---
lib/vhost/vhost_user.c | 8
lib/vhost/vhost_user.h | 7 +--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 723c6890c3..589b950458 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -3023,8 +3023,8 @@ vhost_user_msg_handler(int vid, int fd)
handled = false;
if (dev->extern_ops.pre_msg_handle) {
- ret = (*dev->extern_ops.pre_msg_handle)(dev->vid,
- (void *)&ctx.msg);
+ RTE_BUILD_BUG_ON(offsetof(struct vhu_msg_context, msg) != 0);
+ ret = (*dev->extern_ops.pre_msg_handle)(dev->vid, &ctx);
switch (ret) {
case RTE_VHOST_MSG_RESULT_REPLY:
send_vhost_reply(dev, fd, &ctx);
@@ -3069,8 +3069,8 @@ vhost_user_msg_handler(int vid, int fd)
skip_to_post_handle:
if (ret != RTE_VHOST_MSG_RESULT_ERR &&
dev->extern_ops.post_msg_handle) {
- ret = (*dev->extern_ops.post_msg_handle)(dev->vid,
- (void *)&ctx.msg);
+ RTE_BUILD_BUG_ON(offsetof(struct vhu_msg_context, msg) != 0);
+ ret = (*dev->extern_ops.post_msg_handle)(dev->vid, &ctx);
switch (ret) {
case RTE_VHOST_MSG_RESULT_REPLY:
send_vhost_reply(dev, fd, &ctx);
diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h
index be53669f3b..555f89c97a 100644
--- a/lib/vhost/vhost_user.h
+++ b/lib/vhost/vhost_user.h
@@ -152,10 +152,13 @@ typedef struct VhostUserMsg {
/* Nothing should be added after the payload */
} __rte_packed VhostUserMsg;
-struct vhu_msg_context {
+/* Note: this structure and VhostUserMsg can't be changed carelessly as
+ * external message handlers rely on them.
+ */
+__rte_packed struct vhu_msg_context {
+ VhostUserMsg msg;
int fds[VHOST_MEMORY_MAX_NREGIONS];
int fd_num;
- VhostUserMsg msg;
};
#define VHOST_USER_HDR_SIZE offsetof(VhostUserMsg, payload.u64)
We should revisit the callbacks prototype when we'll be allowed to break
API, passing the message pointer as void * is definitely not a good
idea.
In the mean time, I agree with your fix:
Reviewed-by: Maxime Coquelin
We may also add Reported-by tag when applying.
Thanks!
Maxime
Re: [PATCH] vhost: fix external message handlers
On Tue, Mar 8, 2022 at 9:34 AM Maxime Coquelin
wrote:
> On 3/7/22 19:11, David Marchand wrote:
> > Following a rework, external message handlers were receiving a pointer
> > to a vhost_user message (as stated in the API), but lost the ability to
> > interact with fds attached to the message.
> > Restore the original layout and put a build check and reminders.
> >
> > Bugzilla ID: 953
> > Fixes: 5e0099dc709e ("vhost: remove payload size limitation")
> >
> > Signed-off-by: David Marchand
> > ---
> > This patch is untested, but sending quickly to get feedback from the
> > reporter and comments from author and maintainers.
> >
> >
> > ---
> > lib/vhost/vhost_user.c | 8
> > lib/vhost/vhost_user.h | 7 +--
> > 2 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
> > index 723c6890c3..589b950458 100644
> > --- a/lib/vhost/vhost_user.c
> > +++ b/lib/vhost/vhost_user.c
> > @@ -3023,8 +3023,8 @@ vhost_user_msg_handler(int vid, int fd)
> >
> > handled = false;
> > if (dev->extern_ops.pre_msg_handle) {
> > - ret = (*dev->extern_ops.pre_msg_handle)(dev->vid,
> > - (void *)&ctx.msg);
> > + RTE_BUILD_BUG_ON(offsetof(struct vhu_msg_context, msg) != 0);
> > + ret = (*dev->extern_ops.pre_msg_handle)(dev->vid, &ctx);
> > switch (ret) {
> > case RTE_VHOST_MSG_RESULT_REPLY:
> > send_vhost_reply(dev, fd, &ctx);
> > @@ -3069,8 +3069,8 @@ vhost_user_msg_handler(int vid, int fd)
> > skip_to_post_handle:
> > if (ret != RTE_VHOST_MSG_RESULT_ERR &&
> > dev->extern_ops.post_msg_handle) {
> > - ret = (*dev->extern_ops.post_msg_handle)(dev->vid,
> > - (void *)&ctx.msg);
> > + RTE_BUILD_BUG_ON(offsetof(struct vhu_msg_context, msg) != 0);
> > + ret = (*dev->extern_ops.post_msg_handle)(dev->vid, &ctx);
> > switch (ret) {
> > case RTE_VHOST_MSG_RESULT_REPLY:
> > send_vhost_reply(dev, fd, &ctx);
> > diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h
> > index be53669f3b..555f89c97a 100644
> > --- a/lib/vhost/vhost_user.h
> > +++ b/lib/vhost/vhost_user.h
> > @@ -152,10 +152,13 @@ typedef struct VhostUserMsg {
> > /* Nothing should be added after the payload */
> > } __rte_packed VhostUserMsg;
> >
> > -struct vhu_msg_context {
> > +/* Note: this structure and VhostUserMsg can't be changed carelessly as
> > + * external message handlers rely on them.
> > + */
> > +__rte_packed struct vhu_msg_context {
> > + VhostUserMsg msg;
> > int fds[VHOST_MEMORY_MAX_NREGIONS];
> > int fd_num;
> > - VhostUserMsg msg;
> > };
> >
> > #define VHOST_USER_HDR_SIZE offsetof(VhostUserMsg, payload.u64)
>
> We should revisit the callbacks prototype when we'll be allowed to break
> API, passing the message pointer as void * is definitely not a good
> idea.
Indeed.
>
> In the mean time, I agree with your fix:
>
> Reviewed-by: Maxime Coquelin
>
> We may also add Reported-by tag when applying.
There is an issue with clang, I'll send a v2.
--
David Marchand
Re: [PATCH] vhost: fix external message handlers
On 3/8/22 09:37, David Marchand wrote:
On Tue, Mar 8, 2022 at 9:34 AM Maxime Coquelin
wrote:
On 3/7/22 19:11, David Marchand wrote:
Following a rework, external message handlers were receiving a pointer
to a vhost_user message (as stated in the API), but lost the ability to
interact with fds attached to the message.
Restore the original layout and put a build check and reminders.
Bugzilla ID: 953
Fixes: 5e0099dc709e ("vhost: remove payload size limitation")
Signed-off-by: David Marchand
---
This patch is untested, but sending quickly to get feedback from the
reporter and comments from author and maintainers.
---
lib/vhost/vhost_user.c | 8
lib/vhost/vhost_user.h | 7 +--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 723c6890c3..589b950458 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -3023,8 +3023,8 @@ vhost_user_msg_handler(int vid, int fd)
handled = false;
if (dev->extern_ops.pre_msg_handle) {
- ret = (*dev->extern_ops.pre_msg_handle)(dev->vid,
- (void *)&ctx.msg);
+ RTE_BUILD_BUG_ON(offsetof(struct vhu_msg_context, msg) != 0);
+ ret = (*dev->extern_ops.pre_msg_handle)(dev->vid, &ctx);
switch (ret) {
case RTE_VHOST_MSG_RESULT_REPLY:
send_vhost_reply(dev, fd, &ctx);
@@ -3069,8 +3069,8 @@ vhost_user_msg_handler(int vid, int fd)
skip_to_post_handle:
if (ret != RTE_VHOST_MSG_RESULT_ERR &&
dev->extern_ops.post_msg_handle) {
- ret = (*dev->extern_ops.post_msg_handle)(dev->vid,
- (void *)&ctx.msg);
+ RTE_BUILD_BUG_ON(offsetof(struct vhu_msg_context, msg) != 0);
+ ret = (*dev->extern_ops.post_msg_handle)(dev->vid, &ctx);
switch (ret) {
case RTE_VHOST_MSG_RESULT_REPLY:
send_vhost_reply(dev, fd, &ctx);
diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h
index be53669f3b..555f89c97a 100644
--- a/lib/vhost/vhost_user.h
+++ b/lib/vhost/vhost_user.h
@@ -152,10 +152,13 @@ typedef struct VhostUserMsg {
/* Nothing should be added after the payload */
} __rte_packed VhostUserMsg;
-struct vhu_msg_context {
+/* Note: this structure and VhostUserMsg can't be changed carelessly as
+ * external message handlers rely on them.
+ */
+__rte_packed struct vhu_msg_context {
+ VhostUserMsg msg;
int fds[VHOST_MEMORY_MAX_NREGIONS];
int fd_num;
- VhostUserMsg msg;
};
#define VHOST_USER_HDR_SIZE offsetof(VhostUserMsg, payload.u64)
We should revisit the callbacks prototype when we'll be allowed to break
API, passing the message pointer as void * is definitely not a good
idea.
Indeed.
In the mean time, I agree with your fix:
Reviewed-by: Maxime Coquelin
We may also add Reported-by tag when applying.
There is an issue with clang, I'll send a v2.
Ok.
Fan, can you have a try and confirm it fixes the issue on your side?
Thanks,
Maxime
Re: [PATCH v6 0/2] Add config file support for l3fwd
01/03/2022 15:49, Sean Morrissey: > This patchset introduces config file support for l3fwd > and its lookup methods LPM, FIB, and EM, similar to > that of l3fwd-acl. This allows for route rules to be > defined in configuration files and edited there instead > of in each of the lookup methods hardcoded route tables. > > V6: > * Move config file parsing functions to separate files > as to not bloat l3fwd code. Applied with parsing inside separate files of l3fwd.
RE: [PATCH] net/mlx5: fix IPv6 flow item validation for VERB API
Hi,
> -Original Message-
> From: Gregory Etelson
> Sent: Monday, March 7, 2022 7:18 PM
> To: dev@dpdk.org
> Cc: Gregory Etelson ; Matan Azrad
> ; Raslan Darawsheh ;
> sta...@dpdk.org; Slava Ovsiienko ; Dekel Peled
> ; Ori Kam
> Subject: [PATCH] net/mlx5: fix IPv6 flow item validation for VERB API
>
> In case the PMD was activated over VERB API, limit IPv6 flow item next
> protocol mask value to 0 or 0xFF.
> The limitation is required for RSS flow action TCP and UDP types.
>
> Cc: sta...@dpdk.org
>
> Fixes: 491757372f98 ("net/mlx5: enforce limitation on IPv6 next protocol")
> Signed-off-by: Gregory Etelson
> Acked-by: Matan Azrad
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
Re: [PATCH v3 1/2] examples/l3fwd: use single set of variables throughout the code
> nb_rxd and nb_txd are used in polling mode and event mode of operation. > nb_rxd and nb_txd are already global in polling mode but are not visible to > event mode code. Make them visible to all parts of the application. > > Signed-off-by: Honnappa Nagarahalli > Reviewed-by: Kathleen Capella > Reviewed-by: Ruifeng Wang > Acked-by: Bruce Richardson > > Tested-by: Yingya Han < yingyax@intel.com> Applied, thanks.
Re: [PATCH 1/2] app/testpmd: add test for remote PD and CTX
07/03/2022 17:07, Michael Baum: > On 3/3/2022 2:57 PM, Ferruh Yigit wrote: > > Hi Michael, > > > > This is too much mlx5 specific addition, and I don't think it is good to > > extend > > testpmd with PMD specific code. > > If we enable it, sure there will be other vendors willing to do the same, > > making testpmd even messier. > > Hi Ferruh, > > It is mlx5 PMD specific API, which enables to import device from remote > process. > This extension is the way to test this API, you can see a lot of PMD specific > APIs along testpmd files. > > If one day, other vendors want to import devargs from remote process, they > will remove the mlx5 build time dependency and use it. > > > I don't know what those ``cmd_fd`` and ``pd_handle`` (that read from > > provided socket), but can they be read from some other script and feed to > > testpmd, like a python wrapper etc... I agree with Ferruh that it's a lot of code only for mlx5. Yes we are already calling other PMD-specific API in testpmd but we should try to keep it as small as possible. I propose to try a rework to make it easier to digest. As a consequence, we won't have this testpmd feature in 22.03, and we can work together for the next release.
[PATCH] eal/linux: enable the hugepage mem dump
These hugepages include important structures. We should dump these hugepages into a coredump file for debugging when generating a coredump. Signed-off-by: Li Feng --- lib/eal/linux/eal_memalloc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c index f8b1588cae..d7c2eb14a1 100644 --- a/lib/eal/linux/eal_memalloc.c +++ b/lib/eal/linux/eal_memalloc.c @@ -623,6 +623,8 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, goto resized; } + eal_mem_set_dump(va, alloc_sz, true); + /* In linux, hugetlb limitations, like cgroup, are * enforced at fault time instead of mmap(), even * with the option of MAP_POPULATE. Kernel will send -- 2.35.1
[PATCH v2] vhost: fix external message handlers
Following a rework, external message handlers were receiving a pointer
to a vhost_user message (as stated in the API), but lost the ability to
interact with fds attached to the message.
Restore the original layout and put a build check and reminders.
Bugzilla ID: 953
Fixes: 5e0099dc709e ("vhost: remove payload size limitation")
Reported-by: Fan Zhang
Signed-off-by: David Marchand
---
Changes since v1:
- fixed build with clang,
---
lib/vhost/vhost_user.c | 8
lib/vhost/vhost_user.h | 7 +--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 723c6890c3..589b950458 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -3023,8 +3023,8 @@ vhost_user_msg_handler(int vid, int fd)
handled = false;
if (dev->extern_ops.pre_msg_handle) {
- ret = (*dev->extern_ops.pre_msg_handle)(dev->vid,
- (void *)&ctx.msg);
+ RTE_BUILD_BUG_ON(offsetof(struct vhu_msg_context, msg) != 0);
+ ret = (*dev->extern_ops.pre_msg_handle)(dev->vid, &ctx);
switch (ret) {
case RTE_VHOST_MSG_RESULT_REPLY:
send_vhost_reply(dev, fd, &ctx);
@@ -3069,8 +3069,8 @@ vhost_user_msg_handler(int vid, int fd)
skip_to_post_handle:
if (ret != RTE_VHOST_MSG_RESULT_ERR &&
dev->extern_ops.post_msg_handle) {
- ret = (*dev->extern_ops.post_msg_handle)(dev->vid,
- (void *)&ctx.msg);
+ RTE_BUILD_BUG_ON(offsetof(struct vhu_msg_context, msg) != 0);
+ ret = (*dev->extern_ops.post_msg_handle)(dev->vid, &ctx);
switch (ret) {
case RTE_VHOST_MSG_RESULT_REPLY:
send_vhost_reply(dev, fd, &ctx);
diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h
index be53669f3b..c946cc2ef4 100644
--- a/lib/vhost/vhost_user.h
+++ b/lib/vhost/vhost_user.h
@@ -152,10 +152,13 @@ typedef struct VhostUserMsg {
/* Nothing should be added after the payload */
} __rte_packed VhostUserMsg;
-struct vhu_msg_context {
+/* Note: this structure and VhostUserMsg can't be changed carelessly as
+ * external message handlers rely on them.
+ */
+struct __rte_packed vhu_msg_context {
+ VhostUserMsg msg;
int fds[VHOST_MEMORY_MAX_NREGIONS];
int fd_num;
- VhostUserMsg msg;
};
#define VHOST_USER_HDR_SIZE offsetof(VhostUserMsg, payload.u64)
--
2.23.0
[PATCH] ethdev: fix doxygen comment for device info struct
API documentation for "struct rte_eth_dev_info" was missing some fields
'device' & 'max_hash_mac_addrs',
because of syntax error in doxygen comment, fixing it.
Bugzilla ID: 954
Fixes: 88ac4396ad29 ("ethdev: add VMDq support")
Fixes: cd8c7c7ce241 ("ethdev: replace bus specific struct with generic dev")
Cc: sta...@dpdk.org
Reported-by: Bruce Merry
Signed-off-by: Ferruh Yigit
---
lib/ethdev/rte_ethdev.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index c2d1f9a97239..04cff8ee103b 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1855,7 +1855,7 @@ enum rte_eth_representor_type {
* device, etc...
*/
struct rte_eth_dev_info {
- struct rte_device *device; /** Generic device information */
+ struct rte_device *device; /**< Generic device information */
const char *driver_name; /**< Device Driver name. */
unsigned int if_index; /**< Index to bound host interface, or 0 if none.
Use if_indextoname() to translate into an interface name. */
@@ -1869,8 +1869,8 @@ struct rte_eth_dev_info {
uint16_t max_rx_queues; /**< Maximum number of Rx queues. */
uint16_t max_tx_queues; /**< Maximum number of Tx queues. */
uint32_t max_mac_addrs; /**< Maximum number of MAC addresses. */
- uint32_t max_hash_mac_addrs;
/** Maximum number of hash MAC addresses for MTA and UTA. */
+ uint32_t max_hash_mac_addrs;
uint16_t max_vfs; /**< Maximum number of VFs. */
uint16_t max_vmdq_pools; /**< Maximum number of VMDq pools. */
struct rte_eth_rxseg_capa rx_seg_capa; /**< Segmentation capability.*/
--
2.35.1
Re: [PATCH] examples/distributor: one Tx queue is enough
On Mon, Mar 07, 2022 at 10:39:46PM +, Honnappa Nagarahalli wrote:
> Distributor application creates one Tx queue per core. However
> the transmit is done only from a single core. Hence creating
> one Tx queue is enough.
>
> Fixes: 07db4a975094 ("examples/distributor: new sample app")
> Cc: bruce.richard...@intel.com
> Cc: reshma.pat...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Honnappa Nagarahalli
> Reviewed-by: Ruifeng Wang
> ---
> DTS test cases make this change to DPDK. However, I find that, one
> queue is enough. Hence we could make this change in DPDK.
>
Acked-by: Bruce Richardson
Do we know why DTS is making this change? Does having more TX queues than
necessary cause problems?
RE: [PATCH] maintainers: Update MAINTAINERS for FIPS validation
> -Original Message- > From: Dooley, Brian > Sent: Monday, March 7, 2022 3:14 PM > To: dev@dpdk.org > Cc: sta...@dpdk.org; Dooley, Brian ; Kovacevic, > Marko ; Zhang, Roy Fan > ; Akhil Goyal ; Thomas > Monjalon > Subject: [PATCH] maintainers: Update MAINTAINERS for FIPS validation > > Replace Marko Kovacevic with Brian Dooley and Fan Zhang > > Signed-off-by: Brian Dooley > Cc: Marko Kovacevic > Cc: Fan Zhang > Cc: Akhil Goyal > --- > MAINTAINERS | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 75778343a5..c9c1cf7285 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1707,7 +1707,8 @@ F: examples/ethtool/ > F: doc/guides/sample_app_ug/ethtool.rst > > FIPS validation example > -M: Marko Kovacevic > +M: Fan Zhang > +M: Brian Dooley > F: examples/fips_validation/ > F: doc/guides/sample_app_ug/fips_validation.rst > > -- > 2.25.1 Acked-by: Fan Zhang
RE: [PATCH] net/mlx5: set correct CPU socket ID for mlx5_rxq_ctrl
From: Thinh Tran > I hit a failure during ports drop queue RQ creation when my adapters are on > CPU > socket ID 1 instead of socket ID 0: > > EAL: Probe PCI driver: mlx5_pci (15b3:1019) device: 0020:01:00.0 (socket 1) > EAL: set_mempolicy failed: Invalid argument > mlx5_common: Failed to allocate memory for RQ. > mlx5_net: Port 0 drop queue RQ creation failed. > mlx5_net: Cannot create drop RX queue > mlx5_net: probe of PCI device 0020:01:00.0 aborted after encountering an > error: Success > EAL: Probe PCI driver: mlx5_pci (15b3:1019) device: 0020:01:00.1 (socket 1) > EAL: set_mempolicy failed: Invalid argument > mlx5_common: Failed to allocate memory for RQ. > mlx5_net: Port 0 drop queue RQ creation failed. > mlx5_net: Cannot create drop RX queue > mlx5_net: probe of PCI device 0020:01:00.1 aborted after encountering an > error: Success > TELEMETRY: No legacy callbacks, legacy socket not created > testpmd: No probed ethernet devices > ... > > The patch sets the correct CPU socket ID for the mlx5_rxq_ctrl before calling > the > mlx5_rxq_create_devx_rq_resources() which eventually calls > mlx5_devx_rq_create() with correct CPU socket ID. > Result with this patch: > .. > EAL: Probe PCI driver: mlx5_pci (15b3:1019) device: 0020:01:00.0 (socket 1) > EAL: Probe PCI driver: mlx5_pci (15b3:1019) device: 0020:01:00.1 (socket 1) > TELEMETRY: No legacy callbacks, legacy socket not created Interactive-mode > selected .. > Configuring Port 0 (socket 1) > Port 0: 0C:42:A1:ED:C1:20 > Configuring Port 1 (socket 1) > Port 1: 0C:42:A1:ED:C1:21 > Checking link statuses... > Done > > > Signed-off-by: Thinh Tran > Reviewed-by: David Christensen Acked-by: Matan Azrad
Re: [PATCH v2] vhost: fix external message handlers
On 3/8/22 10:44, David Marchand wrote:
Following a rework, external message handlers were receiving a pointer
to a vhost_user message (as stated in the API), but lost the ability to
interact with fds attached to the message.
Restore the original layout and put a build check and reminders.
Bugzilla ID: 953
Fixes: 5e0099dc709e ("vhost: remove payload size limitation")
Reported-by: Fan Zhang
Signed-off-by: David Marchand
---
Changes since v1:
- fixed build with clang,
---
lib/vhost/vhost_user.c | 8
lib/vhost/vhost_user.h | 7 +--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 723c6890c3..589b950458 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -3023,8 +3023,8 @@ vhost_user_msg_handler(int vid, int fd)
handled = false;
if (dev->extern_ops.pre_msg_handle) {
- ret = (*dev->extern_ops.pre_msg_handle)(dev->vid,
- (void *)&ctx.msg);
+ RTE_BUILD_BUG_ON(offsetof(struct vhu_msg_context, msg) != 0);
+ ret = (*dev->extern_ops.pre_msg_handle)(dev->vid, &ctx);
switch (ret) {
case RTE_VHOST_MSG_RESULT_REPLY:
send_vhost_reply(dev, fd, &ctx);
@@ -3069,8 +3069,8 @@ vhost_user_msg_handler(int vid, int fd)
skip_to_post_handle:
if (ret != RTE_VHOST_MSG_RESULT_ERR &&
dev->extern_ops.post_msg_handle) {
- ret = (*dev->extern_ops.post_msg_handle)(dev->vid,
- (void *)&ctx.msg);
+ RTE_BUILD_BUG_ON(offsetof(struct vhu_msg_context, msg) != 0);
+ ret = (*dev->extern_ops.post_msg_handle)(dev->vid, &ctx);
switch (ret) {
case RTE_VHOST_MSG_RESULT_REPLY:
send_vhost_reply(dev, fd, &ctx);
diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h
index be53669f3b..c946cc2ef4 100644
--- a/lib/vhost/vhost_user.h
+++ b/lib/vhost/vhost_user.h
@@ -152,10 +152,13 @@ typedef struct VhostUserMsg {
/* Nothing should be added after the payload */
} __rte_packed VhostUserMsg;
-struct vhu_msg_context {
+/* Note: this structure and VhostUserMsg can't be changed carelessly as
+ * external message handlers rely on them.
+ */
+struct __rte_packed vhu_msg_context {
+ VhostUserMsg msg;
int fds[VHOST_MEMORY_MAX_NREGIONS];
int fd_num;
- VhostUserMsg msg;
};
#define VHOST_USER_HDR_SIZE offsetof(VhostUserMsg, payload.u64)
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
RE: [PATCH] crypto/qat: fix structurally dead code
> -Original Message-
> From: Kusztal, ArkadiuszX
> Sent: Monday, February 28, 2022 4:06 PM
> To: dev@dpdk.org
> Cc: gak...@marvell.com; Zhang, Roy Fan ; Kusztal,
> ArkadiuszX
> Subject: [PATCH] crypto/qat: fix structurally dead code
>
> This patch fixes structurally dead code in QAT
> asym pmd.
>
> Coverity issue: 376563
> Fixes: ef2f4238a04d ("crypto/qat: refactor asymmetric session")
>
> Signed-off-by: Arek Kusztal
> ---
> drivers/crypto/qat/qat_asym.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
> index badf018f13..1e4304a3c0 100644
> --- a/drivers/crypto/qat/qat_asym.c
> +++ b/drivers/crypto/qat/qat_asym.c
> @@ -1183,7 +1183,6 @@ session_clear_modinv(struct
> rte_crypto_modinv_xform *modinv)
> static void
> session_clear_rsa(struct rte_crypto_rsa_xform *rsa)
> {
> - return;
> memset(rsa->n.data, 0, rsa->n.length);
> rte_free(rsa->n.data);
> memset(rsa->e.data, 0, rsa->e.length);
> --
> 2.13.6
Acked-by: Fan Zhang
Re: [PATCH] net/hinic: fix Tx mbuf length problem
On 3/7/2022 4:06 PM, Stephen Hemminger wrote:
On Mon, 7 Mar 2022 22:12:20 +0800
Junjie Lin <277600...@qq.com> wrote:
From: Junjie Lin
The Tx mbuf needs to be ignored if the pkt_len member is zero.
Fixes: 54faba2295bd ("net/hinic:adds Tx queue xstats members")
Cc: sta...@dpdk.org
Signed-off-by: Junjie Lin
Not all drivers do this. It looks like you have a buggy application
if it tries to send 0 length packets.
Agree, not sure if invalid packet check should be done in driver level.
Junjie, in which use case you are observing this problem?
Or in the past, I remember some PMD FW was crashing for similar
case, and check was added to protect device, do you have similar
problem?
Re: [PATCH] examples/l3fwd: resolve stack buffer overflow issue
11/01/2022 13:50, Rahul Bhansali:
> This patch fixes the stack buffer overflow error reported
> from AddressSanitizer.
> Function send_packetsx4() tries to access out of bound data
> from rte_mbuf and fill it into TX buffer even in the case
> where no pending packets (len = 0).
> Performance impact:- No
>
> ASAN error report:-
> ==819==ERROR: AddressSanitizer: stack-buffer-overflow on address
> 0xe2c0dcf0 at pc 0x005e791c bp 0xe2c0d7e0 sp 0xe2c0d800
> READ of size 8 at 0xe2c0dcf0 thread T0
> #0 0x5e7918 in send_packetsx4 ../examples/l3fwd/l3fwd_common.h:251
> #1 0x5e7918 in send_packets_multi ../examples/l3fwd/l3fwd_neon.h:226
This code comes from below commit, so these tags are missing:
Fixes: 96ff445371e0 ("examples/l3fwd: reorganise and optimize LPM code path")
Cc: sta...@dpdk.org
> Signed-off-by: Rahul Bhansali
> ---
> examples/l3fwd/l3fwd_common.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/examples/l3fwd/l3fwd_common.h b/examples/l3fwd/l3fwd_common.h
> index 7d83ff641a..de77711f88 100644
> --- a/examples/l3fwd/l3fwd_common.h
> +++ b/examples/l3fwd/l3fwd_common.h
> @@ -236,6 +236,9 @@ send_packetsx4(struct lcore_conf *qconf, uint16_t port,
> struct rte_mbuf *m[],
>
> /* copy rest of the packets into the TX buffer. */
> len = num - n;
> + if (len == 0)
> + goto exit;
> +
I don't understand how it can fix something.
There is already "while (j < len)" with j and len being 0,
the loop should not be effective in this case.
> j = 0;
> switch (len % FWDSTEP) {
> while (j < len) {
> @@ -258,6 +261,7 @@ send_packetsx4(struct lcore_conf *qconf, uint16_t port,
> struct rte_mbuf *m[],
> }
> }
>
> +exit:
> qconf->tx_mbufs[port].len = len;
> }
Re: [PATCH] examples/distributor: one Tx queue is enough
08/03/2022 11:00, Bruce Richardson:
> On Mon, Mar 07, 2022 at 10:39:46PM +, Honnappa Nagarahalli wrote:
> > Distributor application creates one Tx queue per core. However
> > the transmit is done only from a single core. Hence creating
> > one Tx queue is enough.
> >
> > Fixes: 07db4a975094 ("examples/distributor: new sample app")
> > Cc: bruce.richard...@intel.com
> > Cc: reshma.pat...@intel.com
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Honnappa Nagarahalli
> > Reviewed-by: Ruifeng Wang
> > ---
> > DTS test cases make this change to DPDK. However, I find that, one
> > queue is enough. Hence we could make this change in DPDK.
> >
> Acked-by: Bruce Richardson
Applied, thanks.
Re: [PATCH] examples/flow_classify: fix spelling when log error
23/02/2022 17:05, Iremonger, Bernard:
> Hi Chuanshe,
>
> From: Chuanshe Zhang
> >
> > Signed-off-by: Chuanshe Zhang
> > ---
> > - flow_classify_log("failed to read source address/mask:
> > %s\n",
> > + flow_classify_log("failed to read destination address/mask:
> > %s\n",
>
> ### [PATCH] examples/flow_classify: fix spelling when log error
> WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
>
> /dpdk_22_03/devtools# ./check-git-log.sh -1
> Missing 'Fixes' tag:
> examples/flow_classify: fix spelling when log error
>
> Otherwise, the fix looks good.
Applied, thanks.
RE: [PATCH] examples/flow_classify: fix spelling when log error
Hi Thomas,
> -Original Message-
> From: Thomas Monjalon
> Sent: Tuesday, March 8, 2022 11:44 AM
> To: Chuanshe Zhang
> Cc: dev@dpdk.org; Iremonger, Bernard
> Subject: Re: [PATCH] examples/flow_classify: fix spelling when log error
>
> 23/02/2022 17:05, Iremonger, Bernard:
> > Hi Chuanshe,
> >
> > From: Chuanshe Zhang
> > >
> > > Signed-off-by: Chuanshe Zhang
> > > ---
> > > - flow_classify_log("failed to read source address/mask:
> > > %s\n",
> > > + flow_classify_log("failed to read destination address/mask:
> > > %s\n",
> >
> > ### [PATCH] examples/flow_classify: fix spelling when log error
> > WARNING:COMMIT_MESSAGE: Missing commit description - Add an
> > appropriate one
> >
> > /dpdk_22_03/devtools# ./check-git-log.sh -1 Missing 'Fixes' tag:
> > examples/flow_classify: fix spelling when log error
> >
> > Otherwise, the fix looks good.
>
> Applied, thanks.
>
You can add my ack to this patch
RE: [PATCH] net/mlx5: set correct CPU socket ID for mlx5_rxq_ctrl
Hi Thinh,
> -Original Message-
> From: Thinh Tran
> Sent: Tuesday, March 8, 2022 12:53 AM
> To: dev@dpdk.org
> Cc: d...@linux.vnet.ibm.com; Thinh Tran
> Subject: [PATCH] net/mlx5: set correct CPU socket ID for mlx5_rxq_ctrl
>
This is a fix, so it's better to start commit title with a fix:
Something like this maybe:
"net/mlx5: fix CPU socket ID for mlx5_rxq_ctrl"
> I hit a failure during ports drop queue RQ creation when my adapters
> are on CPU socket ID 1 instead of socket ID 0:
>
> EAL: Probe PCI driver: mlx5_pci (15b3:1019) device: 0020:01:00.0 (socket 1)
> EAL: set_mempolicy failed: Invalid argument
> mlx5_common: Failed to allocate memory for RQ.
> mlx5_net: Port 0 drop queue RQ creation failed.
> mlx5_net: Cannot create drop RX queue
> mlx5_net: probe of PCI device 0020:01:00.0 aborted after encountering an
> error: Success
> EAL: Probe PCI driver: mlx5_pci (15b3:1019) device: 0020:01:00.1 (socket 1)
> EAL: set_mempolicy failed: Invalid argument
> mlx5_common: Failed to allocate memory for RQ.
> mlx5_net: Port 0 drop queue RQ creation failed.
> mlx5_net: Cannot create drop RX queue
> mlx5_net: probe of PCI device 0020:01:00.1 aborted after encountering an
> error: Success
> TELEMETRY: No legacy callbacks, legacy socket not created
> testpmd: No probed ethernet devices
> ...
It's better to describe the issue rather than showing an example alone,
Maybe something like this:
The socket ID is used to determine the socket where to allocate memory for
mlx5_rxq_ctrl, currently it's set to 0 by default which mistakenly leads to
allocating the memory on socket 0 always.
>
> The patch sets the correct CPU socket ID for the mlx5_rxq_ctrl before
> calling the mlx5_rxq_create_devx_rq_resources() which eventually calls
> mlx5_devx_rq_create() with correct CPU socket ID.
> Result with this patch:
This sets the correct CPU socket ID before memory allocation to use the correct
socket ID.
> ..
> EAL: Probe PCI driver: mlx5_pci (15b3:1019) device: 0020:01:00.0 (socket 1)
> EAL: Probe PCI driver: mlx5_pci (15b3:1019) device: 0020:01:00.1 (socket 1)
> TELEMETRY: No legacy callbacks, legacy socket not created
> Interactive-mode selected
> ..
> Configuring Port 0 (socket 1)
> Port 0: 0C:42:A1:ED:C1:20
> Configuring Port 1 (socket 1)
> Port 1: 0C:42:A1:ED:C1:21
> Checking link statuses...
> Done
>
Missing:
Fixes tag:
Fixes: 5ceb3a02b000 ("net/mlx5: move Rx queue DevX resource")
Cc: xuemi...@nvidia.com
Missing Cc stable for backport.
Cc: sta...@dpdk.org
>
> Signed-off-by: Thinh Tran
> Reviewed-by: David Christensen
> ---
Kindest regards,
Raslan Darawsheh
Re: [PATCH] net/sfc: do not spam logs on tunnel restore info errors
On 3/6/2022 4:12 PM, Ivan Malov wrote:
OvS might invoke this API on its data path, out of sync
with its control plane. If the control path has already
deactivated the tunnel context entry, these invocations
will produce quite a few error printouts. Suppress that.
Fixes: 7e5b479803c3 ("net/sfc: implement control path operations in tunnel
offload")
Cc: sta...@dpdk.org
Signed-off-by: Ivan Malov
Reviewed-by: Andrew Rybchenko
Applied to dpdk-next-net/main, thanks.
Re: [PATCH] net/mlx5: set correct CPU socket ID for mlx5_rxq_ctrl
Hi Raslan,
> Missing:
> Fixes tag:
>
> Fixes: 5ceb3a02b000 ("net/mlx5: move Rx queue DevX resource")
> Cc: xuemi...@nvidia.com
I believe the bug originates from my earlier commit, not Xueming's one:
Fixes: bc5bee028ebc ("net/mlx5: create drop queue using DevX")
RE: [PATCH] net/mlx5: set correct CPU socket ID for mlx5_rxq_ctrl
> -Original Message-
> From: Dmitry Kozlyuk
> Sent: Tuesday, March 8, 2022 2:23 PM
> To: Raslan Darawsheh
> Cc: Thinh Tran ; dev@dpdk.org;
> d...@linux.vnet.ibm.com
> Subject: Re: [PATCH] net/mlx5: set correct CPU socket ID for mlx5_rxq_ctrl
>
> Hi Raslan,
>
> > Missing:
> > Fixes tag:
> >
> > Fixes: 5ceb3a02b000 ("net/mlx5: move Rx queue DevX resource")
> > Cc: xuemi...@nvidia.com
>
> I believe the bug originates from my earlier commit, not Xueming's one:
>
> Fixes: bc5bee028ebc ("net/mlx5: create drop queue using DevX")
Yes I think you are correct, my mistake 😊
Kindest regards,
Raslan Darawsheh
[PATCH] usertools: add check for IOMMU support in dpdk-devbind
binding with vfio driver, when IOMMU is disabled, causes program to crash.
this patch checks for IOMMU support, if it is disabled, changes vfio
into unsafe noiommu mode and prints a warning message.
Signed-off-by: Fidaullah Noonari
---
usertools/dpdk-devbind.py | 25 +
1 file changed, 25 insertions(+)
diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index ace4627218..f42eead0c4 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -466,6 +466,26 @@ def unbind_all(dev_list, force=False):
unbind_one(d, force)
+def check_iommu():
+"""Check if IOMMU is enabled on system"""
+if len(os.listdir("/sys/class/iommu")) != 0:
+return True
+print("Warning: IOMMU support disabled")
+return False
+
+
+def enable_noiommu_mode():
+"""Enables the noiommu mode for vfio drivers"""
+filename = "/sys/module/vfio/parameters/enable_unsafe_noiommu_mode"
+try:
+f = open(filename, "w")
+except:
+sys.exit("Error: unable to enable noiommu mode, could not open '%s'" %
filename)
+f.write("1")
+f.close()
+print("Warning: enabling unsafe no IOMMU mode for vfio drivers")
+
+
def bind_all(dev_list, driver, force=False):
"""Bind method, takes a list of device locations"""
global devices
@@ -492,6 +512,11 @@ def bind_all(dev_list, driver, force=False):
except ValueError as ex:
sys.exit(ex)
+# check for IOMMU support
+if not check_iommu():
+if driver == "vfio-pci":
+enable_noiommu_mode()
+
for d in dev_list:
bind_one(d, driver, force)
--
2.25.1
Re: [PATCH] usertools: add check for IOMMU support in dpdk-devbind
On Tue, Mar 08, 2022 at 05:49:01PM +0500, Fidaullah Noonari wrote:
> binding with vfio driver, when IOMMU is disabled, causes program to crash.
> this patch checks for IOMMU support, if it is disabled, changes vfio
> into unsafe noiommu mode and prints a warning message.
>
> Signed-off-by: Fidaullah Noonari
> ---
> usertools/dpdk-devbind.py | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
> index ace4627218..f42eead0c4 100755
> --- a/usertools/dpdk-devbind.py
> +++ b/usertools/dpdk-devbind.py
> @@ -466,6 +466,26 @@ def unbind_all(dev_list, force=False):
> unbind_one(d, force)
>
>
> +def check_iommu():
> +"""Check if IOMMU is enabled on system"""
> +if len(os.listdir("/sys/class/iommu")) != 0:
> +return True
> +print("Warning: IOMMU support disabled")
> +return False
> +
> +
> +def enable_noiommu_mode():
> +"""Enables the noiommu mode for vfio drivers"""
> +filename = "/sys/module/vfio/parameters/enable_unsafe_noiommu_mode"
> +try:
> +f = open(filename, "w")
> +except:
> +sys.exit("Error: unable to enable noiommu mode, could not open '%s'"
> % filename)
> +f.write("1")
> +f.close()
> +print("Warning: enabling unsafe no IOMMU mode for vfio drivers")
> +
> +
> def bind_all(dev_list, driver, force=False):
> """Bind method, takes a list of device locations"""
> global devices
> @@ -492,6 +512,11 @@ def bind_all(dev_list, driver, force=False):
> except ValueError as ex:
> sys.exit(ex)
>
> +# check for IOMMU support
> +if not check_iommu():
> +if driver == "vfio-pci":
> +enable_noiommu_mode()
> +
> for d in dev_list:
> bind_one(d, driver, force)
>
I like the idea of doing this from the script, but I would rather it not
happen by default, since no-iommu reduces the security of the system. In
the normal case, I think it would be best if the script printed an error
message asking the user to enable iommu. We can also then add a flag to
allow the user to explicitly ask for no-iommu mode and take the risk.
/Bruce
Re: [PATCH v3] examples/multi_process: reconfigure port when rss or csum isn't supported
28/02/2022 08:55, Ling, WeiX: > From: Bruce Richardson > > On Tue, Feb 22, 2022 at 10:51:27AM +, Wenwu Ma wrote: > > > The default values of rx mq_mode and rx offloads for port will cause > > > symmetric_mp startup failure if the port do not support rss or csum. > > > This Patch make the app to reconfigure the NIC without them. Only quit > > > the app if the second reconfiguration fails. > > > > > > Signed-off-by: Wenwu Ma > > > --- > > > > While I am surprised to see different error codes for different essentially > > the > > same issue - lack of HW support, that is a separate problem to the one this > > is > > addressing. Given this is just a sample app, I think this approach is fine > > for > > configuring things - keeping things simple for the user. > > > > Acked-by: Bruce Richardson > > > Tested-by: Wei Ling Applied with title "examples/multi_process: make RSS and checksum optional"
Re: [PATCH] examples/vm_power: replace list foreach with while loop
01/03/2022 15:53, Shibin Koikkara Reeny:
> Linux header files don't support LIST_FOREACH_SAFE so replacing
> LIST_FOREACH with while loop.
What is the original issue you are trying to solve?
> - struct virtual_machine_info *vm_info;
> -
> - LIST_FOREACH(vm_info, &vm_list_head, vms_info) {
> + struct virtual_machine_info *vm_info = LIST_FIRST(&vm_list_head);
>
> + /* No LIST_FOREACH_SAFE, using while instead. */
> + while (vm_info) {
> rte_spinlock_lock(&(vm_info->config_spinlock));
>
> memcpy(mask, (char *)vm_info->channel_mask, RTE_MAX_LCORE);
> @@ -1024,6 +1024,8 @@ channel_manager_exit(void)
>
> LIST_REMOVE(vm_info, vms_info);
> rte_free(vm_info);
> +
> + vm_info = LIST_NEXT((vm_info), vms_info);
> }
Re: [PATCH] examples/kni: add CR character at print log
07/03/2022 15:52, Ferruh Yigit:
> On 3/7/2022 9:05 AM, Tianli Lai wrote:
> > add CR character at print link state information
> >
> > Signed-off-by: Tianli Lai
> > ---
> > examples/kni/main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/examples/kni/main.c b/examples/kni/main.c
> > index f5b20a7b62..e99ef5c38a 100644
> > --- a/examples/kni/main.c
> > +++ b/examples/kni/main.c
> > @@ -719,7 +719,7 @@ log_link_state(struct rte_kni *kni, int prev, struct
> > rte_eth_link *link)
> >
> > rte_eth_link_to_str(link_status_text, sizeof(link_status_text), link);
> > if (prev != link->link_status)
> > - RTE_LOG(INFO, APP, "%s NIC %s",
> > + RTE_LOG(INFO, APP, "%s NIC %s\n",
> > rte_kni_get_name(kni),
> > link_status_text);
> > }
>
> Fixes: db4e81351fb8 ("examples: use new link status print format")
> Cc: sta...@dpdk.org
>
> Reviewed-by: Ferruh Yigit
Applied with title "examples/kni: add missing trailing newline in log"
Re: [PATCH v3] devtools/cocci: update cocci for ethdev namespace
07/03/2022 15:27, Aman Singh: > Changed the filter from ETH_SPEED to ETH_SPEED_NUM to make the match > more specific. Added check for ETH_TUNNEL_FILTER and ETH_RSS_RETA > as these were missed before. > > Signed-off-by: Aman Singh Applied, thanks.
RE: [PATCH v4] app/pdump: check lcore is not the maximum core
Thomas, could you include this in RC3 if possible.
> -Original Message-
> From: Reshma Pattan
> Sent: Monday, February 28, 2022 9:59 AM
> To: dev@dpdk.org
> Cc: step...@networkplumber.org; Yigit, Ferruh ;
> Pattan, Reshma ; vipin.vargh...@intel.com;
> sta...@dpdk.org
> Subject: [PATCH v4] app/pdump: check lcore is not the maximum core
>
> Check lcore id value is not the maximum core supported.
> Using lcore id without this check might cause out of bound access inside
> the rte_eal_wait_lcore.
>
> Coverity issue: 375841
> Fixes: b2854d5317e8 ("app/pdump: support multi-core capture")
> Cc: vipin.vargh...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Reshma Pattan
> ---
> v4: Remove inline of new function
> Change lcore type as unsigned int
> return lcore from the function
> ---
> app/pdump/main.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/app/pdump/main.c b/app/pdump/main.c index
> 04a38e8911..96fa76f8da 100644
> --- a/app/pdump/main.c
> +++ b/app/pdump/main.c
> @@ -900,11 +900,21 @@ dump_packets_core(void *arg)
> return 0;
> }
>
> +static unsigned int
> +get_next_core(unsigned int lcore)
> +{
> + lcore = rte_get_next_lcore(lcore, 1, 0);
> + if (lcore == RTE_MAX_LCORE)
> + rte_exit(EXIT_FAILURE,
> + "Max core limit %u reached for packet capture",
> lcore);
> + return lcore;
> +}
> +
> static inline void
> dump_packets(void)
> {
> int i;
> - uint32_t lcore_id = 0;
> + unsigned int lcore_id = 0;
>
> if (!multiple_core_capture) {
> printf(" core (%u), capture for (%d) tuples\n", @@ -930,12
> +940,12 @@ dump_packets(void)
> return;
> }
>
> - lcore_id = rte_get_next_lcore(lcore_id, 1, 0);
> + lcore_id = get_next_core(lcore_id);
>
> for (i = 0; i < num_tuples; i++) {
> rte_eal_remote_launch(dump_packets_core,
> &pdump_t[i], lcore_id);
> - lcore_id = rte_get_next_lcore(lcore_id, 1, 0);
> + lcore_id = get_next_core(lcore_id);
>
> if (rte_eal_wait_lcore(lcore_id) < 0)
> rte_exit(EXIT_FAILURE, "failed to wait\n");
> --
> 2.25.1
Re: [PATCH v2 1/3] common/mlx5: add Netlink event helpers
On 02/03/2022 15:56, Dmitry Kozlyuk wrote: Hi Ferruh, -Original Message- From: Ferruh Yigit [...] Hi Dmitry, For clarification, this patch is not fix, but it is requested to be backported to be able to backport fixes in this patchset, right? Yes. The updated API is internal so that should be ok. I'm ok to take this on 21.11 as long as you can confirm it's not breaking any user compatibility with external sw versions/ABI/API etc from 21.11.0 ? Assuming that's ok, please send a rebased series for 21.11. I'm not comfortable rebasing the series with the amount of changes on dpdk main branch to same functions in mlx5_os.c. P.S. Better to rebase on patch queue [0] to avoid conflicts with other backports not pushed to dpdk.org yet. thanks, Kevin. [0] https://github.com/kevintraynor/dpdk-stable.git
Question about commit 44dddd14059 in DPDK e1000 driver
I have a question about some changes to the e1000 driver that where
committed in 2020 (commit 4414059f151f39f7e075b887decfc9a10f11).
I see that e1000_power_down_phy_copper_82575 has been replaced by
e1000_power_down_phy_copper_base, but the two functions are not the same.
more specifically in the old function we had this code:
-STATIC void e1000_power_down_phy_copper_82575(struct e1000_hw *hw)
-{
-Â Â struct e1000_phy_info *phy = &hw->phy;
-
-Â Â if (!(phy->ops.check_reset_block))
-Â Â return;
-
-Â Â /* If the management interface is not enabled, then power down */
-Â Â if (!(e1000_enable_mng_pass_thru(hw) ||
phy->ops.check_reset_block(hw)))
-Â Â e1000_power_down_phy_copper(hw);
-
-Â Â return;
-}
And the new looks like this:
+void e1000_power_down_phy_copper_base(struct e1000_hw *hw)
+{
+Â Â struct e1000_phy_info *phy = &hw->phy;
+
+Â Â if (!(phy->ops.check_reset_block))
+Â Â return;
+
+Â Â /* If the management interface is not enabled, then power down */
+Â Â if (phy->ops.check_reset_block(hw))
+Â Â e1000_power_down_phy_copper(hw);
+}
The 'if' condition is different, and almost opposite.
Is this intentional?
In my usecase I do not manage to put the link down with the most recent
DPDK (21.11), but it worked fine with 19.11. Should a configure
something differently?
Best regards,
Francesco Mancino
Re: [PATCH 2/2] devtools: use libabigail rule for mlx glue drivers
02/03/2022 11:16, Ray Kinsella: > > David Marchand writes: > > > Convert the existing exception in the ABI script into a libabigail > > suppression rule. > > > > Note: file_name_regexp could be used to achive the same with versions of > > libabigail < 1.7 but soname_regexp has been preferred here since it is > > already used with a recent change on common/mlx5. > > > > While at it, fix indent from a recent change. > > > > Signed-off-by: David Marchand > > --- > > devtools/check-abi.sh| 7 --- > > devtools/libabigail.abignore | 8 ++-- > > 2 files changed, 6 insertions(+), 9 deletions(-) > > > > Minor niggle that changes to the check-abi.sh script should have been in > the first patch? No, first patch is about DLB, second is mlx. > Acked-by: Ray Kinsella Series applied, thanks.
RE: [PATCH v2] vhost: fix external message handlers
Hi everyone,
> Following a rework, external message handlers were receiving a pointer
> to a vhost_user message (as stated in the API), but lost the ability
> to interact with fds attached to the message.
> Restore the original layout and put a build check and reminders.
>
> Bugzilla ID: 953
> Fixes: 5e0099dc709e ("vhost: remove payload size limitation")
>
> Reported-by: Fan Zhang
> Signed-off-by: David Marchand
> ---
> Changes since v1:
> - fixed build with clang,
>
> ---
Tested-by: Jakub Poczatek
Acked-by: Jakub Poczatek
Re: [PATCH] gpu/cuda: missing slash in libcuda.so path
Hi Elena, On 07/03/2022 21:47, Thomas Monjalon wrote: 01/03/2022 20:42, eagost...@nvidia.com: From: Elena Agostini Signed-off-by: Elena Agostini Applied with this title and commit log: gpu/cuda: fix dependency loading path A slash was missing in libcuda.so path for dlopen. This seems like a good candidate for backport to LTS, so I added it to the queue for 21.11.1. Please let me know if you do *not* want it backported 21.11.1. thanks, Kevin.
[PATCH v2 0/2] add missing local symbols catch-all
The libraries (and driver) regexdev, gpudev and auxiliary bus were missing "local:*" in their version.map linker script which catch all non-listed functions to be hidden in shared libraries. v2: add a devtools check Thomas Monjalon (2): regexdev: fix section attribute of symbols build: hide local symbols in shared libraries devtools/check-symbol-maps.sh | 7 +++ devtools/libabigail.abignore | 12 drivers/bus/auxiliary/version.map | 2 ++ lib/gpudev/version.map | 2 ++ lib/regexdev/rte_regexdev.h| 4 lib/regexdev/rte_regexdev_driver.h | 3 +++ lib/regexdev/version.map | 11 +++ 7 files changed, 41 insertions(+) -- 2.34.1
[PATCH v2 1/2] regexdev: fix section attribute of symbols
The functions used by the drivers must be internal,
while the function and variables used in inline functions
must be experimental.
These are the changes done in the shared library:
- DF .text Base rte_regexdev_get_device_by_name
+ DF .text INTERNAL rte_regexdev_get_device_by_name
- DF .text Base rte_regexdev_register
+ DF .text INTERNAL rte_regexdev_register
- DF .text Base rte_regexdev_unregister
+ DF .text INTERNAL rte_regexdev_unregister
- DF .text Base rte_regexdev_is_valid_dev
+ DF .text EXPERIMENTAL rte_regexdev_is_valid_dev
- DO .bss Base rte_regex_devices
+ DO .bss EXPERIMENTAL rte_regex_devices
- DO .bss Base rte_regexdev_logtype
+ DO .bss EXPERIMENTAL rte_regexdev_logtype
Because these symbols were exported in the default section in DPDK 21.11,
any change in these functions would be seen as incompatible
by the ABI compatibility check.
An exception rule is added for this experimental library,
so the ABI check will skip it until the next ABI version.
Fixes: bab9497ef78b ("regexdev: introduce API")
Cc: sta...@dpdk.org
Signed-off-by: Thomas Monjalon
Acked-by: Ori Kam
---
devtools/libabigail.abignore | 4
lib/regexdev/rte_regexdev.h| 4
lib/regexdev/rte_regexdev_driver.h | 3 +++
lib/regexdev/version.map | 9 +
4 files changed, 20 insertions(+)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 9c921c47d4..18c11c80c6 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -25,6 +25,10 @@
[suppress_type]
name = rte_crypto_asym_op
+; Ignore section attribute fixes in experimental regexdev library
+[suppress_file]
+soname_regexp = ^librte_regexdev\.
+
; Ignore changes in common mlx5 driver, should be all internal
[suppress_file]
soname_regexp = ^librte_common_mlx5\.
diff --git a/lib/regexdev/rte_regexdev.h b/lib/regexdev/rte_regexdev.h
index 4ba67b0c25..3bce8090f6 100644
--- a/lib/regexdev/rte_regexdev.h
+++ b/lib/regexdev/rte_regexdev.h
@@ -225,6 +225,9 @@ extern int rte_regexdev_logtype;
} while (0)
/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
* Check if dev_id is ready.
*
* @param dev_id
@@ -234,6 +237,7 @@ extern int rte_regexdev_logtype;
* - 0 if device state is not in ready state.
* - 1 if device state is ready state.
*/
+__rte_experimental
int rte_regexdev_is_valid_dev(uint16_t dev_id);
/**
diff --git a/lib/regexdev/rte_regexdev_driver.h
b/lib/regexdev/rte_regexdev_driver.h
index 64742016c0..6246b144a6 100644
--- a/lib/regexdev/rte_regexdev_driver.h
+++ b/lib/regexdev/rte_regexdev_driver.h
@@ -32,6 +32,7 @@ extern "C" {
* A pointer to the RegEx device slot case of success,
* NULL otherwise.
*/
+__rte_internal
struct rte_regexdev *rte_regexdev_register(const char *name);
/**
@@ -41,6 +42,7 @@ struct rte_regexdev *rte_regexdev_register(const char *name);
* @param dev
* Device to be released.
*/
+__rte_internal
void rte_regexdev_unregister(struct rte_regexdev *dev);
/**
@@ -50,6 +52,7 @@ void rte_regexdev_unregister(struct rte_regexdev *dev);
* @param name
* The device name.
*/
+__rte_internal
struct rte_regexdev *rte_regexdev_get_device_by_name(const char *name);
#ifdef __cplusplus
diff --git a/lib/regexdev/version.map b/lib/regexdev/version.map
index 8db9b17018..988b909638 100644
--- a/lib/regexdev/version.map
+++ b/lib/regexdev/version.map
@@ -1,6 +1,7 @@
EXPERIMENTAL {
global:
+ rte_regex_devices;
rte_regexdev_attr_get;
rte_regexdev_attr_set;
rte_regexdev_close;
@@ -11,6 +12,8 @@ EXPERIMENTAL {
rte_regexdev_enqueue_burst;
rte_regexdev_get_dev_id;
rte_regexdev_info_get;
+ rte_regexdev_is_valid_dev;
+ rte_regexdev_logtype;
rte_regexdev_queue_pair_setup;
rte_regexdev_rule_db_compile_activate;
rte_regexdev_rule_db_export;
@@ -24,3 +27,9 @@ EXPERIMENTAL {
rte_regexdev_xstats_names_get;
rte_regexdev_xstats_reset;
};
+
+INTERNAL {
+ rte_regexdev_get_device_by_name;
+ rte_regexdev_register;
+ rte_regexdev_unregister;
+};
--
2.34.1
[PATCH v2 2/2] build: hide local symbols in shared libraries
The symbols which are not listed in the version script
are exported by default.
Adding a local section with a wildcard make non-listed functions
and variables as hidden, as it should be in all version.map files.
These are the changes done in the shared libraries:
- DF .text Base auxiliary_add_device
- DF .text Base auxiliary_dev_exists
- DF .text Base auxiliary_dev_iterate
- DF .text Base auxiliary_insert_device
- DF .text Base auxiliary_is_ignored_device
- DF .text Base auxiliary_match
- DF .text Base auxiliary_on_scan
- DF .text Base auxiliary_scan
- DO .bss Base auxiliary_bus_logtype
- DO .data Base auxiliary_bus
- DO .bss Base gpu_logtype
There is no impact on regexdev library.
Because these local symbols were exported as non-internal
in DPDK 21.11, any change in these functions would break the ABI.
Exception rules are added for these experimental libraries,
so the ABI check will skip them until the next ABI version.
A check is added to avoid such miss in future.
Fixes: 1afce3086cf4 ("bus/auxiliary: introduce auxiliary bus")
Fixes: 8b8036a66e3d ("gpudev: introduce GPU device class library")
Cc: sta...@dpdk.org
Signed-off-by: Thomas Monjalon
---
devtools/check-symbol-maps.sh | 7 +++
devtools/libabigail.abignore | 8
drivers/bus/auxiliary/version.map | 2 ++
lib/gpudev/version.map| 2 ++
lib/regexdev/version.map | 2 ++
5 files changed, 21 insertions(+)
diff --git a/devtools/check-symbol-maps.sh b/devtools/check-symbol-maps.sh
index 5bd290ac97..8266fdf9ea 100755
--- a/devtools/check-symbol-maps.sh
+++ b/devtools/check-symbol-maps.sh
@@ -53,4 +53,11 @@ if [ -n "$duplicate_symbols" ] ; then
ret=1
fi
+local_miss_maps=$(grep -L 'local: \*;' $@)
+if [ -n "$local_miss_maps" ] ; then
+echo "Found maps without local catch-all:"
+echo "$local_miss_maps"
+ret=1
+fi
+
exit $ret
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 18c11c80c6..c618f20032 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -32,3 +32,11 @@
; Ignore changes in common mlx5 driver, should be all internal
[suppress_file]
soname_regexp = ^librte_common_mlx5\.
+
+; Ignore visibility fix of local functions in experimental auxiliary driver
+[suppress_file]
+soname_regexp = ^librte_bus_auxiliary\.
+
+; Ignore visibility fix of local functions in experimental gpudev library
+[suppress_file]
+soname_regexp = ^librte_gpudev\.
diff --git a/drivers/bus/auxiliary/version.map
b/drivers/bus/auxiliary/version.map
index a52260657c..dc993e84ff 100644
--- a/drivers/bus/auxiliary/version.map
+++ b/drivers/bus/auxiliary/version.map
@@ -4,4 +4,6 @@ EXPERIMENTAL {
# added in 21.08
rte_auxiliary_register;
rte_auxiliary_unregister;
+
+ local: *;
};
diff --git a/lib/gpudev/version.map b/lib/gpudev/version.map
index b23e3fd6eb..a2c8ce5759 100644
--- a/lib/gpudev/version.map
+++ b/lib/gpudev/version.map
@@ -39,4 +39,6 @@ INTERNAL {
rte_gpu_get_by_name;
rte_gpu_notify;
rte_gpu_release;
+
+ local: *;
};
diff --git a/lib/regexdev/version.map b/lib/regexdev/version.map
index 988b909638..3c6e9fffa1 100644
--- a/lib/regexdev/version.map
+++ b/lib/regexdev/version.map
@@ -26,6 +26,8 @@ EXPERIMENTAL {
rte_regexdev_xstats_get;
rte_regexdev_xstats_names_get;
rte_regexdev_xstats_reset;
+
+ local: *;
};
INTERNAL {
--
2.34.1
[PATCH v4] net/bonding: another fix to LACP mempool size
The following log message may appear after a slave is idle(or nearly
idle)
for a few minutes:"PMD: Failed to allocate LACP packet from pool".
And bond mode 4 negotiation may fail.
Problem:When bond mode 4 has been chosed and delicated queue has
not been enable, all mbufs from a slave' private pool(used
exclusively for transmitting LACPDUs) have been allocated in
interrupt thread, and are still sitting in the device's tx
descriptor ring and other cores' mempool caches in fwd thread.
Thus the interrupt thread can not alloc LACP packet from pool.
Solution: Ensure that each slave'tx (LACPDU) mempool owns more than
n-tx-queues * n-tx-descriptor + fwd_core_num *
per-core-mmempool-flush-threshold mbufs.
Note that the LACP tx machine fuction is the only code that allocates
from a slave's private pool. It runs in the context of the interrupt
thread, and thus it has no mempool cache of its own.
Signed-off-by: Gaoxiang Liu
---
v2:
* Fixed compile issues.
v3:
* delete duplicate code.
v4;
* Fixed some issues.
1. total_tx_desc should use +=
2. add detailed logs
---
drivers/net/bonding/rte_eth_bond_8023ad.c | 8 +---
lib/mempool/rte_mempool.h | 2 ++
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c
b/drivers/net/bonding/rte_eth_bond_8023ad.c
index ca50583d62..d2168073cc 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.c
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
@@ -1050,6 +1050,7 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev
*bond_dev,
uint32_t total_tx_desc;
struct bond_tx_queue *bd_tx_q;
uint16_t q_id;
+ uint32_t cache_size;
/* Given slave mus not be in active list */
RTE_ASSERT(find_slave_by_id(internals->active_slaves,
@@ -1100,11 +1101,12 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev
*bond_dev,
total_tx_desc += bd_tx_q->nb_tx_desc;
}
+ cache_size = RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ?
+ 32 : RTE_MEMPOOL_CACHE_MAX_SIZE;
+ total_tx_desc += rte_lcore_count() * cache_size *
RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER;
snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", slave_id);
port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, total_tx_desc,
- RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ?
- 32 : RTE_MEMPOOL_CACHE_MAX_SIZE,
- 0, element_size, socket_id);
+ cache_size, 0, element_size, socket_id);
/* Any memory allocation failure in initialization is critical because
* resources can't be free, so reinitialization is impossible. */
diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
index 1e7a3c1527..fa15ed710f 100644
--- a/lib/mempool/rte_mempool.h
+++ b/lib/mempool/rte_mempool.h
@@ -56,6 +56,8 @@
extern "C" {
#endif
+#define RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER 1.5
+
#define RTE_MEMPOOL_HEADER_COOKIE1 0xbadbadbadadd2e55ULL /**< Header cookie.
*/
#define RTE_MEMPOOL_HEADER_COOKIE2 0xf2eef2eedadd2e55ULL /**< Header cookie.
*/
#define RTE_MEMPOOL_TRAILER_COOKIE 0xadd2e55badbadbadULL /**< Trailer
cookie.*/
--
2.32.0
Re: [PATCH] gpu/cuda: missing slash in libcuda.so path
Yes please Thanks EA From: Kevin Traynor Date: Tuesday, 8 March 2022 at 15:24 To: Elena Agostini Cc: dev@dpdk.org , NBU-Contact-Thomas Monjalon (EXTERNAL) Subject: Re: [PATCH] gpu/cuda: missing slash in libcuda.so path External email: Use caution opening links or attachments Hi Elena, On 07/03/2022 21:47, Thomas Monjalon wrote: > 01/03/2022 20:42, eagost...@nvidia.com: >> From: Elena Agostini >> >> Signed-off-by: Elena Agostini > > Applied with this title and commit log: > > gpu/cuda: fix dependency loading path > > A slash was missing in libcuda.so path for dlopen. > > > This seems like a good candidate for backport to LTS, so I added it to the queue for 21.11.1. Please let me know if you do *not* want it backported 21.11.1. thanks, Kevin.
Re: [PATCH v4] app/pdump: check lcore is not the maximum core
08/03/2022 14:47, Mcnamara, John: > Thomas, could you include this in RC3 if possible. I did already yesterday: https://git.dpdk.org/dpdk/commit/?id=3ee04ebc91 Looks like I forgot to send an email. Applied, thanks :)
Re: [PATCH] gpu/cuda: missing slash in libcuda.so path
08/03/2022 15:24, Elena Agostini: > Yes please > > Thanks > EA > > From: Kevin Traynor > > Hi Elena, > > On 07/03/2022 21:47, Thomas Monjalon wrote: > > 01/03/2022 20:42, eagost...@nvidia.com: > >> From: Elena Agostini > >> > >> Signed-off-by: Elena Agostini > > > > Applied with this title and commit log: > > > > gpu/cuda: fix dependency loading path > > > > A slash was missing in libcuda.so path for dlopen. > > > > > > > > This seems like a good candidate for backport to LTS, so I added it to > the queue for 21.11.1. > > Please let me know if you do *not* want it backported 21.11.1. > > thanks, > Kevin. I forgot the Fixes: line and Cc: sta...@dpdk.org Elena, please remind to add such lines next time, it makes the process more automatic.
Re: [PATCH v2 0/2] add missing local symbols catch-all
08/03/2022 15:24, Thomas Monjalon: > The libraries (and driver) regexdev, gpudev and auxiliary bus > were missing "local:*" in their version.map linker script > which catch all non-listed functions to be hidden in shared libraries. > > v2: add a devtools check > > Thomas Monjalon (2): > regexdev: fix section attribute of symbols > build: hide local symbols in shared libraries Applied
Re: [PATCH] net/tap: do not include l2 header in gso size when compared with mtu
On Mon, Feb 28, 2022 at 4:27 PM Harold Huang wrote:
>
> The gso size is calculated with all of the headers and payload. As a
> result, the l2 header should not be included when comparing gso size
> with mtu.
>
> Fixes: 050316a88313 ("net/tap: support TSO (TCP Segment Offload)")
> Cc: sta...@dpdk.org
> Signed-off-by: Harold Huang
> ---
> drivers/net/tap/rte_eth_tap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index f1b48cae82..2b561d232c 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -731,7 +731,7 @@ pmd_tx_burst(void *queue, struct rte_mbuf **bufs,
> uint16_t nb_pkts)
> mbuf_in->l4_len;
> tso_segsz = mbuf_in->tso_segsz + hdrs_len;
> if (unlikely(tso_segsz == hdrs_len) ||
> - tso_segsz > *txq->mtu) {
> + tso_segsz > *txq->mtu + mbuf_in->l2_len) {
> txq->stats.errs++;
> break;
> }
> --
> 2.27.0
>
Hi, Jiayu,
This is the only example in the driver to use GSO. I think it is
important for us to calculate a correct GSO size. I see you are the
GSO lib maintainer, could you please help review this patch?
Re: [PATCH] build: fix build on FreeBSD with Meson 0.61.1
15/02/2022 16:31, Bruce Richardson: > On Mon, Feb 14, 2022 at 12:43:13PM +0100, Karl Bonde Torp wrote: > > When building with Meson 0.61.1 on FreeBSD some archives become > > corrupted. This can be avoided by using 'llvm-ar' instead of 'ar'. > > > > Signed-off-by: Karl Bonde Torp > > --- > > buildtools/meson.build | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/buildtools/meson.build b/buildtools/meson.build > > index 400b88f251..e1c600e40f 100644 > > --- a/buildtools/meson.build > > +++ b/buildtools/meson.build > > @@ -31,6 +31,9 @@ if host_machine.system() == 'windows' > > pmdinfo += 'llvm-ar' > > endif > > pmdinfogen += 'coff' > > +elif host_machine.system() == 'freebsd' > > +pmdinfo += 'llvm-ar' > > +pmdinfogen += 'elf' > > else > > pmdinfo += 'ar' > > pmdinfogen += 'elf' > > Based off the instructions you posted later in the thread, I've reproduced > the issue - and then done a little extra investigation. Here is my > understanding: > > * By default on FreeBSD the linking is being done by llvm-ar > * The resulting libraries are being linked as thin archives and "ar" binary > does not seem to be able to process them. > * When building with CC=gcc on FreeBSD, "ar" is used as a linker, and the > resulting archives are regular .a files. > * On Linux, whether building with clang or gcc, "ar" seems to be used as > linker. > > The ideal situation here would be if we could use meson to report itself > what the static linker in use is, but unfortunately while we can query the > dynamic linker using "meson.compiler().get_linker_id()", there doesn't seem > to be an equivalent for the static linker. Therefore, the only option seems > to be a fix as here. Only question remains as to whether we want to only > use llvm-ar for clang builds on FreeBSD or use if for all builds on FreeBSD. > I'm not sure it makes much difference either way, but I'd tend towards > limiting the use of llvm-ar to only clang builds. > > With or without this suggested change, > > Acked-by: Bruce Richardson Applied, thanks.
Re: [PATCH v2] vhost: fix external message handlers
On Tue, Mar 8, 2022 at 10:44 AM David Marchand
wrote:
>
> Following a rework, external message handlers were receiving a pointer
> to a vhost_user message (as stated in the API), but lost the ability to
> interact with fds attached to the message.
> Restore the original layout and put a build check and reminders.
>
> Bugzilla ID: 953
> Fixes: 5e0099dc709e ("vhost: remove payload size limitation")
>
> Reported-by: Fan Zhang
> Signed-off-by: David Marchand
> ---
> Changes since v1:
> - fixed build with clang,
>
> ---
> lib/vhost/vhost_user.c | 8
> lib/vhost/vhost_user.h | 7 +--
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
> index 723c6890c3..589b950458 100644
> --- a/lib/vhost/vhost_user.c
> +++ b/lib/vhost/vhost_user.c
> @@ -3023,8 +3023,8 @@ vhost_user_msg_handler(int vid, int fd)
>
> handled = false;
> if (dev->extern_ops.pre_msg_handle) {
> - ret = (*dev->extern_ops.pre_msg_handle)(dev->vid,
> - (void *)&ctx.msg);
> + RTE_BUILD_BUG_ON(offsetof(struct vhu_msg_context, msg) != 0);
> + ret = (*dev->extern_ops.pre_msg_handle)(dev->vid, &ctx);
> switch (ret) {
> case RTE_VHOST_MSG_RESULT_REPLY:
> send_vhost_reply(dev, fd, &ctx);
> @@ -3069,8 +3069,8 @@ vhost_user_msg_handler(int vid, int fd)
> skip_to_post_handle:
> if (ret != RTE_VHOST_MSG_RESULT_ERR &&
> dev->extern_ops.post_msg_handle) {
> - ret = (*dev->extern_ops.post_msg_handle)(dev->vid,
> - (void *)&ctx.msg);
> + RTE_BUILD_BUG_ON(offsetof(struct vhu_msg_context, msg) != 0);
> + ret = (*dev->extern_ops.post_msg_handle)(dev->vid, &ctx);
> switch (ret) {
> case RTE_VHOST_MSG_RESULT_REPLY:
> send_vhost_reply(dev, fd, &ctx);
> diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h
> index be53669f3b..c946cc2ef4 100644
> --- a/lib/vhost/vhost_user.h
> +++ b/lib/vhost/vhost_user.h
> @@ -152,10 +152,13 @@ typedef struct VhostUserMsg {
> /* Nothing should be added after the payload */
> } __rte_packed VhostUserMsg;
>
> -struct vhu_msg_context {
> +/* Note: this structure and VhostUserMsg can't be changed carelessly as
> + * external message handlers rely on them.
> + */
> +struct __rte_packed vhu_msg_context {
> + VhostUserMsg msg;
> int fds[VHOST_MEMORY_MAX_NREGIONS];
> int fd_num;
> - VhostUserMsg msg;
> };
>
> #define VHOST_USER_HDR_SIZE offsetof(VhostUserMsg, payload.u64)
> --
> 2.23.0
>
Sorry to have missed that test with virtio-crypto ; I'll create
another thread to talk about the VhostUserMsg extension.
Reviewed-by: Christophe Fontaine
Thanks,
Christophe
[PATCH 0/5] Small Doc improvements for Linux GSG
This patchset contains a number of small documentation improvements for the linux GSG, spread across a few sections. Bruce Richardson (5): doc/linux_gsg: add driver guides to document list doc/linux_gsg: drop note about old chipset doc/linux_gsg: remove duplicated note doc/linux_gsg: merge requirements section for app building doc/linux_gsg: expand list of directories doc/guides/linux_gsg/build_dpdk.rst | 13 +- doc/guides/linux_gsg/intro.rst | 25 +++ doc/guides/linux_gsg/sys_reqs.rst | 38 - 3 files changed, 47 insertions(+), 29 deletions(-) -- 2.32.0
[PATCH 1/5] doc/linux_gsg: add driver guides to document list
The document roadmap section was missing any mention of the individual drivers guides which are important for users. Add them to list. Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/intro.rst | 25 + 1 file changed, 25 insertions(+) diff --git a/doc/guides/linux_gsg/intro.rst b/doc/guides/linux_gsg/intro.rst index 890169e97f..ea98ac7425 100644 --- a/doc/guides/linux_gsg/intro.rst +++ b/doc/guides/linux_gsg/intro.rst @@ -34,3 +34,28 @@ The following is a list of DPDK documents in the suggested reading order: * Sample Applications User Guide: Describes a set of sample applications. Each chapter describes a sample application that showcases specific functionality and provides instructions on how to compile, run and use the sample application. + +* Driver Reference Guides: Provides details on each driver inside a particular category. +Separate guides exist for each of: + +* Baseband devices + +* Compression devices + +* Cryptographic accelerator devices + +* DMA devices + +* Event-based scheduling devices + +* General purpose GPU devices + +* Mempool drivers + +* Network (NIC) devices + +* "Raw" devices i.e. those not fitting into any other category + +* Regular expression devices + +* vDPA (vhost data path acceleration) devices \ No newline at end of file -- 2.32.0
[PATCH 2/5] doc/linux_gsg: drop note about old chipset
The chipsets referenced in the note[1] were all launched in 2012 and are now discontinued, so we can drop the note about them at this stage. [1] https://ark.intel.com/content/www/us/en/ark/products/codename/44946/products-formerly-cave-creek.html Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/sys_reqs.rst | 5 - 1 file changed, 5 deletions(-) diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst index 9dccd54d9c..6f8799504a 100644 --- a/doc/guides/linux_gsg/sys_reqs.rst +++ b/doc/guides/linux_gsg/sys_reqs.rst @@ -8,11 +8,6 @@ System Requirements This chapter describes the packages required to compile the DPDK. -.. note:: - -If the DPDK is being used on an Intel\ |reg| Communications Chipset 89xx Series platform, -please consult the *Intel\ |reg| Communications Chipset 89xx Series Software for Linux Getting Started Guide*. - BIOS Setting Prerequisite on x86 -- 2.32.0
[PATCH 3/5] doc/linux_gsg: remove duplicated note
A note about secure boot not allowing uio is present in both the system requirements section and the driver binding section. This fits better in the driver binding section, so the copy in system requirements can be removed. The document in general now also emphasises vfio over uio more than when this note was first added, reducing the need for this warning to be repeated. Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/sys_reqs.rst | 7 --- 1 file changed, 7 deletions(-) diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst index 6f8799504a..df367742cc 100644 --- a/doc/guides/linux_gsg/sys_reqs.rst +++ b/doc/guides/linux_gsg/sys_reqs.rst @@ -17,13 +17,6 @@ and high performance of small packets, BIOS setting changes may be needed. Consult the section on :ref:`Enabling Additional Functionality ` for more information on the required changes. -.. note:: - - If UEFI secure boot is enabled, the Linux kernel may disallow the use of - UIO on the system. Therefore, devices for use by DPDK should be bound to the - ``vfio-pci`` kernel module rather than ``igb_uio`` or ``uio_pci_generic``. - For more details see :ref:`linux_gsg_binding_kernel`. - Compilation of the DPDK --- -- 2.32.0
[PATCH 4/5] doc/linux_gsg: merge requirements section for app building
When building end-applications linked with DPDK, the only additional tool needed is pkg-config/pkgconf. However, the standard development tools meta-packages on most distro's include this as standard, meaning it does not really require its own section. The one outlier in the existing text is "alpine" where it is not present when using "libc-dev" target. However, changing "gcc" and "libc-dev" to "alpine-sdk" metapackage aligns alpine with the other distros in this regard. Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/sys_reqs.rst | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst index df367742cc..08d45898f0 100644 --- a/doc/guides/linux_gsg/sys_reqs.rst +++ b/doc/guides/linux_gsg/sys_reqs.rst @@ -27,11 +27,19 @@ Compilation of the DPDK The setup commands and installed packages needed on various systems may be different. For details on Linux distributions and the versions tested, please consult the DPDK Release Notes. -* General development tools including a supported C compiler such as gcc (version 4.9+) or clang (version 3.4+). +* General development tools including a supported C compiler such as gcc (version 4.9+) or clang (version 3.4+), +and ``pkg-config`` or ``pkgconf`` to be used when building end-user binaries against DPDK. * For RHEL/Fedora systems these can be installed using ``dnf groupinstall "Development Tools"`` * For Ubuntu/Debian systems these can be installed using ``apt install build-essential`` -* For Alpine Linux, ``apk add gcc libc-dev bsd-compat-headers libexecinfo-dev`` +* For Alpine Linux, ``apk add alpine-sdk bsd-compat-headers libexecinfo-dev`` + +.. note:: + + pkg-config 0.27, supplied with RHEL-7, + does not process the Libs.private section correctly, + resulting in statically linked applications not being linked properly. + Use an updated version of ``pkg-config`` or ``pkgconf`` instead when building applications * Python 3.5 or later. @@ -87,20 +95,6 @@ For poll-mode drivers, the additional dependencies for each driver can be found in that driver's documentation in the relevant DPDK guide document, e.g. :doc:`../nics/index` - -Building DPDK Applications --- - -The tool pkg-config or pkgconf, integrated in most build systems, -must be used to parse options and dependencies from libdpdk.pc. - -.. note:: - - pkg-config 0.27, supplied with RHEL-7, - does not process the Libs.private section correctly, - resulting in statically linked applications not being linked properly. - - Running DPDK Applications - -- 2.32.0
[PATCH 5/5] doc/linux_gsg: expand list of directories
Not all directories were given in the GSG document, but many of those omitted would be of interest to users, e.g. "doc", "license" and "usertools" directories. Adding these leaves only "devtools", and "kernel" as the only undocumented directories, so add them in too for completeness. When updating the section, add "including" to the line leading up to the directory list, indicating that, while the list is currently complete, it is not guaranteed to always be. Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/build_dpdk.rst | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/doc/guides/linux_gsg/build_dpdk.rst b/doc/guides/linux_gsg/build_dpdk.rst index 0b08492ca2..4f2def15ed 100644 --- a/doc/guides/linux_gsg/build_dpdk.rst +++ b/doc/guides/linux_gsg/build_dpdk.rst @@ -16,7 +16,11 @@ First, uncompress the archive and move to the uncompressed DPDK source directory tar xJf dpdk-.tar.xz cd dpdk- -The DPDK is composed of several directories: +The DPDK is composed of several directories, including: + +* doc: DPDK Documentation + +* license: DPDK license information * lib: Source code of DPDK libraries @@ -28,6 +32,13 @@ The DPDK is composed of several directories: * config, buildtools: Framework-related scripts and configuration +* usertools: Utility scripts for end-users of DPDK applications + +* devtools: Scripts for use by DPDK developers + +* kernel: Kernel modules needed for some operating systems + + Compiling and Installing DPDK System-wide - -- 2.32.0
RE: [PATCH] examples/distributor: one Tx queue is enough
> Do we know why DTS is making this change? Does having more TX queues than > necessary cause problems? DTS is to reduce tx queues to enable many workers for performance testing. Distributor application creates one Tx queue per core, and total (lcore-1) queues, Which make it only 1 worker, but it only use a single queue to transmit. That's not make sense, so we request to fix it.
RE: [PATCH v4 1/3] net/ixgbe: Fix ixgbe_is_sfp() to return valid result for X550EM_a devs
> -Original Message-
> From: Thomas Monjalon
> Sent: Sunday, March 6, 2022 12:56 PM
> To: Wang, Haiyue ; Zhang, Qi Z
> ; ferruh.yi...@intel.com
> Cc: Jeff Daly ; dev@dpdk.org; sta...@dpdk.org;
> Stephen Douthit ; Lu, Wenzhuo
>
> Subject: Re: [PATCH v4 1/3] net/ixgbe: Fix ixgbe_is_sfp() to return valid
> result for
> X550EM_a devs
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments.
>
>
> 01/03/2022 12:18, Zhang, Qi Z:
> > From: Wang, Haiyue
> > > From: Jeff Daly
> > > > From: Stephen Douthit
> > > >
> > > > Currently all X500EM* MAC types fallthrough to the default case
> > > > and get reported as non-SFP regardless of media type, which isn't
> > > > correct.
> > > >
> > > > Fixes: 0790adeb567 ("ixgbe/base: support X550em_a device")
> > > > Cc: sta...@dpdk.org
> > > >
> > > > Signed-off-by: Stephen Douthit
> > > > Signed-off-by: Jeff Daly
> > >
> > > Acked-by: Haiyue Wang
> >
> > Applied to dpdk-next-net-intel after renaming the title to "fix FSP check
> > for
> X550EM devices" to fix check-git-log error.
>
> It seems you have applied only the first patch of the series. Why?
> Is there a good reason to split a series without any justification?
> What about the two other patches?
>
I should explain the [PATCH v4 x/y] and why it changed from 7 patches to 3
initially. In Stephen's initial v1 of the patch series there were 7
patches and during the discussion of the v2 version before Stephen left he
intended to break it into 3 separate submissions. After speaking with
Ekinops/Swisscom regarding the best way to move these forward it was decided to
move some functionality back to ethdev.c. So currently: [PATCH v4 1/3] is
basically [PATCH v2 1/7], [PATCH v2 2/7] and [PATCH v2 5/7] were reworked and
included in [PATCH v4 3/3] . [PATCH v2 4/7] became [PATCH v4 2/3]. I
submitted 2 separate patches yesterday for what was [PATCH v2 6/7] and [PATCH
v2 7/7] since they were small patches to base/ rather than ethdev. Finally,
[PATCH v2 3/7] i'm working out whether it can be reworked into something that
only touches ethdev (could be more kludgey) or really kinda just fits into base
as originally submitted, like the last 2 patches I submitted for special
handling of some SFPs.
I discovered the ixgbe_api functionality the other day while looking into this,
and was thinking perhaps it could be somehow done there. Still under base, but
not touching the main driver files. Is there any documentation that describes
the ixgbe_api usage or process to get a wrapper call added to it?
RE: [PATCH v4] app/pdump: check lcore is not the maximum core
> -Original Message- > From: Thomas Monjalon > Subject: Re: [PATCH v4] app/pdump: check lcore is not the maximum core > > 08/03/2022 14:47, Mcnamara, John: > > Thomas, could you include this in RC3 if possible. > > I did already yesterday: > https://git.dpdk.org/dpdk/commit/?id=3ee04ebc91 > > Looks like I forgot to send an email. > > Applied, thanks :) Thank you. :-)
Re: [PATCH v2] vhost: fix external message handlers
On Tue, Mar 8, 2022 at 10:45 AM David Marchand
wrote:
>
> Following a rework, external message handlers were receiving a pointer
> to a vhost_user message (as stated in the API), but lost the ability to
> interact with fds attached to the message.
> Restore the original layout and put a build check and reminders.
>
> Bugzilla ID: 953
> Fixes: 5e0099dc709e ("vhost: remove payload size limitation")
>
> Reported-by: Fan Zhang
> Signed-off-by: David Marchand
Reviewed-by: Maxime Coquelin
Tested-by: Jakub Poczatek
Acked-by: Jakub Poczatek
Reviewed-by: Christophe Fontaine
Applied, thanks.
--
David Marchand
Re: [PATCH] net/iavf: fix potential out of bounds access
On 3/8/2022 5:56 AM, Leyi Rong wrote:
Fix potential out-out-bounds access as overrunning callee's array of
size 26 by passing argument rxq->rxdid(which evaluates to 63) in call
to iavf_rx_scan_hw_ring_flex_rxd.
Coverity issue: 376616
Fixes: 7b1ba38904a0 ("net/iavf: fix function pointer in multi-process")
Cc: sta...@dpdk.org
Signed-off-by: Leyi Rong
Reviewed-by: Ferruh Yigit
Applied to dpdk-next-net/main, thanks.
RE: [PATCH v2 1/3] common/mlx5: add Netlink event helpers
Hi Kevin, > -Original Message- > From: Kevin Traynor [...] > The updated API is internal so that should be ok. I'm ok to take this > on > 21.11 as long as you can confirm it's not breaking any user > compatibility with external sw versions/ABI/API etc from 21.11.0 ? > > Assuming that's ok, please send a rebased series for 21.11. I'm not > comfortable rebasing the series with the amount of changes on dpdk > main branch to same functions in mlx5_os.c. Changes are not breaking any external SW. Backport sent: http://inbox.dpdk.org/stable/20220308151044.1012413-1-dkozl...@nvidia.com
[Bug 953] Virtio Crypto Test failed
https://bugs.dpdk.org/show_bug.cgi?id=953 Fan Zhang (roy.fan.zh...@intel.com) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Fan Zhang (roy.fan.zh...@intel.com) --- Resolved by https://patchwork.dpdk.org/project/dpdk/patch/20220308094422.25685-1-david.march...@redhat.com/ -- You are receiving this mail because: You are the assignee for the bug.
Re: [PATCH] ethdev: fix doxygen comment for device info struct
08/03/2022 10:47, Ferruh Yigit:
> API documentation for "struct rte_eth_dev_info" was missing some fields
> 'device' & 'max_hash_mac_addrs',
> because of syntax error in doxygen comment, fixing it.
>
> Bugzilla ID: 954
> Fixes: 88ac4396ad29 ("ethdev: add VMDq support")
> Fixes: cd8c7c7ce241 ("ethdev: replace bus specific struct with generic dev")
> Cc: sta...@dpdk.org
>
> Reported-by: Bruce Merry
> Signed-off-by: Ferruh Yigit
Applied, thanks.
Re: [PATCH v2] build: try to get kernel version from kernel source
On 3/3/2022 1:15 PM, Ferdinand Thiessen wrote: When building the kernel modules, try to get the kernel version from the kernel sources first. This fixes the kernel modules installation directory if the target kernel version differs from the host kernel version, like for CI build or when packaging for linux distributions. Signed-off-by: Ferdinand Thiessen lgtm Tested-by: Ferruh Yigit
[PATCH v1] doc: fix telemetry example for cryptodev
Blank line added to the final telemetry example for the
cryptography device library as to fix the example
rendering.
Signed-off-by: Sean Morrissey
---
doc/guides/prog_guide/cryptodev_lib.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst
b/doc/guides/prog_guide/cryptodev_lib.rst
index ba4c592b84..edd11059bc 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -1211,6 +1211,7 @@ are shown below.
"enqueue_err_count": 0, "dequeue_err_count": 0}}
#. Get the capabilities of a particular Crypto device::
+
--> /cryptodev/caps,0
{"/cryptodev/caps": {"crypto_caps": [], "crypto_caps_n": }}
--
2.25.1
[PATCH v2 1/2] gpudev: add GPU page_size to info
From: Elena Agostini
Page alignment on the GPU can be different from
the CPU page alignment.
Fixes: 9b8cae4d991e ("gpudev: use CPU mapping in communication list")
Signed-off-by: Elena Agostini
---
drivers/gpu/cuda/cuda.c | 4
lib/gpudev/rte_gpudev.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/cuda/cuda.c b/drivers/gpu/cuda/cuda.c
index cf9e59535c..8505d39d64 100644
--- a/drivers/gpu/cuda/cuda.c
+++ b/drivers/gpu/cuda/cuda.c
@@ -523,6 +523,8 @@ cuda_dev_info_get(struct rte_gpu *dev, struct rte_gpu_info
*info)
}
dev->mpshared->info.total_memory = parent_info.total_memory;
+ dev->mpshared->info.page_size = parent_info.page_size;
+
/*
* GPU Device private info
*/
@@ -1173,6 +1175,8 @@ cuda_gpu_probe(__rte_unused struct rte_pci_driver
*pci_drv, struct rte_pci_devic
return -rte_errno;
}
+ dev->mpshared->info.page_size = (size_t)GPU_PAGE_SIZE;
+
/*
* GPU Device private info
*/
diff --git a/lib/gpudev/rte_gpudev.h b/lib/gpudev/rte_gpudev.h
index 7e2401a4b7..971aeacfff 100644
--- a/lib/gpudev/rte_gpudev.h
+++ b/lib/gpudev/rte_gpudev.h
@@ -61,6 +61,8 @@ struct rte_gpu_info {
size_t total_memory;
/* Local NUMA memory ID. -1 if unknown. */
int16_t numa_node;
+ /* Get GPU memory page size. */
+ size_t page_size;
};
/** Flags passed in notification callback. */
--
2.17.1
[PATCH v2 2/2] gpudev: use page_size in comm_list creation
From: Elena Agostini
Memory allocated for CPU mapping the status flag
in the communication list should be aligned to the
GPU page size.
Fixes: 9b8cae4d991e ("gpudev: use CPU mapping in communication list")
Signed-off-by: Elena Agostini
---
lib/gpudev/gpudev.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lib/gpudev/gpudev.c b/lib/gpudev/gpudev.c
index fb1bee344c..56033f4a5f 100644
--- a/lib/gpudev/gpudev.c
+++ b/lib/gpudev/gpudev.c
@@ -820,6 +820,7 @@ rte_gpu_comm_create_list(uint16_t dev_id,
uint32_t idx_l;
int ret;
struct rte_gpu *dev;
+ struct rte_gpu_info info;
if (num_comm_items == 0) {
rte_errno = EINVAL;
@@ -833,6 +834,12 @@ rte_gpu_comm_create_list(uint16_t dev_id,
return NULL;
}
+ ret = rte_gpu_info_get(dev_id, &info);
+ if (ret < 0) {
+ rte_errno = ENODEV;
+ return NULL;
+ }
+
comm_list = rte_zmalloc(NULL,
sizeof(struct rte_gpu_comm_list) * num_comm_items, 0);
if (comm_list == NULL) {
@@ -855,7 +862,7 @@ rte_gpu_comm_create_list(uint16_t dev_id,
*/
comm_list[0].status_d = rte_gpu_mem_alloc(dev_id,
sizeof(enum rte_gpu_comm_list_status) * num_comm_items,
- rte_mem_page_size());
+ info.page_size);
if (ret < 0) {
rte_errno = ENOMEM;
return NULL;
--
2.17.1
RE: [PATCH] net/mlx5: fix IPv6 flow item validation for VERB API
Hi,
> -Original Message-
> From: Raslan Darawsheh
> Sent: Tuesday, March 8, 2022 11:10 AM
> To: Gregory Etelson ; dev@dpdk.org
> Cc: Matan Azrad ; sta...@dpdk.org; Slava Ovsiienko
> ; Dekel Peled ; Ori Kam
>
> Subject: RE: [PATCH] net/mlx5: fix IPv6 flow item validation for VERB API
>
> Hi,
>
> > -Original Message-
> > From: Gregory Etelson
> > Sent: Monday, March 7, 2022 7:18 PM
> > To: dev@dpdk.org
> > Cc: Gregory Etelson ; Matan Azrad
> > ; Raslan Darawsheh ;
> > sta...@dpdk.org; Slava Ovsiienko ; Dekel Peled
> > ; Ori Kam
> > Subject: [PATCH] net/mlx5: fix IPv6 flow item validation for VERB API
> >
> > In case the PMD was activated over VERB API, limit IPv6 flow item next
> > protocol mask value to 0 or 0xFF.
> > The limitation is required for RSS flow action TCP and UDP types.
> >
> > Cc: sta...@dpdk.org
> >
> > Fixes: 491757372f98 ("net/mlx5: enforce limitation on IPv6 next
> > protocol")
> > Signed-off-by: Gregory Etelson
> > Acked-by: Matan Azrad
>
> Patch applied to next-net-mlx,
>
> Kindest regards,
> Raslan Darawsheh
Dropping this patch from next-net-mlx as it introduces a new bug with
dv_flow_en,
Kindest regards,
Raslan Darawsheh
Re: [DPDK/bnxt] Issues starting bnxt on an Arm server
On Tue, Mar 8, 2022 at 12:19 AM Thierry Herbelot
wrote:
>
> Hello,
>
> After upgrading the firmware on the bnxt NIC, the NIC is correctly
> detected by a DPDK application with both DPDK-v20.11 and DPDK-v21.11.
Great. Thanks for the update Thierry.
>
> Regards
>
> Thierry
>
> On 3/4/22 01:56, Honnappa Nagarahalli wrote:
> > + Ruifeng
> >
> >
> >
> >>
> >> On Wed, Mar 2, 2022 at 9:28 AM Thierry Herbelot
> >> wrote:
> >>>
> >>> On 3/2/22 18:26, Ajit Khaparde wrote:
> On Wed, Mar 2, 2022 at 9:16 AM Thierry Herbelot
> wrote:
> >
> > Hello Ajit
> >
> > The card is not correctly probed by the kernel, and so the FW version is
> > not visible.
> Thanks Thierry.
> I thought it was just the PMD running into trouble.
>
> Can you give details of the ARM server?
> Make, Vendor, etc..?
> >>>
> >>> This a Huawei server:
> >>> TaiShan 200 Server (Model 2180) aarch64, 48 cores, 2.6GHz, 64GB RAM
> >>
> >> Ok. I tried this on a HUAWEI Kunpeng 920 running 4.18.0-
> >> 348.2.1.el8_5.aarch64.
> >> I can load the bnxt_en kernel driver and the DPDK PMD without issues.
> >> And I did load vfio with enable_unsafe_noiommu_mode=1 .
> >>
> >> While we are pursuing this further internally,
> >> I have added Honnappa to see if he can provide any insight.
> > There is not much information on the error.
> > Just wondering if it is possible to move the card to x86 machine and check
> > the firmware version and upgrade the firmware version there.
> >
> >>
> >> Ajit
> >>
> >>>
> >>> Thierry
> >>>
>
>
> >
> > I see this in the kernel dmesg:
> > bnxt_en :03:00.0 (unnamed net_device) (uninitialized): Error
> > (timeout: 500015) msg {0x0 0x0} len:0
> > bnxt_en :03:00.0 (unnamed net_device) (uninitialized): Firmware not
> > responding, status: 0x8
> >
> > And then there are no bnxt_en netdevices.
> >
> > Best regards
> >
> > Thierry
> >
> >
> > On 3/2/22 18:13, Ajit Khaparde wrote:
> >> On Wed, Mar 2, 2022 at 7:13 AM Thierry Herbelot
> >> wrote:
> >>>
> >>> Hello Ajit
> >>>
> >>> Thanks for the quick response.
> >>>
> >>> Please keep me posted when you check on your side.
> >> Can you tell what is the firmware version on the card?
> >>
> >>>
> >>>Best regards
> >>>
> >>>Thierry
> >>>
> >>> On 3/2/22 16:08, Ajit Khaparde wrote:
> >
> > Is this a know issue ?
> No.
> We have tried the Broadcom PMD on ARM server(s) and have been
> able to use it without any issues.
> But we can try it again and get back to you.
>
>
> >
> > Thanks
> >
> > Thierry Herbelot
> >
> > PS: a similar error is seen for the Ethernet ports, when handled by
> > the
> > kernel:
> > dmesg|grep bnxt
> > [ 57.823746] bnxt_en :03:00.0 (unnamed net_device)
> > (uninitialized): Error (timeout: 500015) msg {0x0 0x0} len:0
> > [ 59.202255] bnxt_en: probe of :03:00.0 failed with error -16
> > [ 60.641519] bnxt_en :03:00.1 (unnamed net_device)
> > (uninitialized): Error (timeout: 500015) msg {0x0 0x0} len:0
> > [ 61.502237] bnxt_en: probe of :03:00.1 failed with error -16
> >
> >
> --
> Thierry Herbelot
> Senior Software Engineer
> Tel: +33 1 39 30 92 61
> http://www.6wind.com/
>
> Follow us:
> https://www.linkedin.com/company/6wind/
> https://twitter.com/6WINDsoftware
> https://www.youtube.com/user/6windsoftware
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH] build: encapsulate grep for local_miss_maps in a function
check-symbols-maps.sh runs with the -e option to exit as soon as
there is an error. Currently the build is failing as the search of
grep -L is empty (which is the case for all version.map files as
they have the local symbol) which causes the script to return
with an error.
This patch encapsulates the grep call in a function, so that only the function
errors out and the build is successful.
Fixes: b403498e14 ("build: hide local symbols in shared libraries")
Cc: sta...@dpdk.org
Signed-off-by: Usama Arif
---
devtools/check-symbol-maps.sh | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/devtools/check-symbol-maps.sh b/devtools/check-symbol-maps.sh
index 8266fdf9ea..96c479138f 100755
--- a/devtools/check-symbol-maps.sh
+++ b/devtools/check-symbol-maps.sh
@@ -53,7 +53,14 @@ if [ -n "$duplicate_symbols" ] ; then
ret=1
fi
-local_miss_maps=$(grep -L 'local: \*;' $@)
+find_local_miss_maps ()
+{
+local local_miss_maps=$(grep -L 'local: \*;' $@)
+echo "$local_miss_maps"
+
+}
+
+local_miss_maps=$(find_local_miss_maps $@)
if [ -n "$local_miss_maps" ] ; then
echo "Found maps without local catch-all:"
echo "$local_miss_maps"
--
2.25.1
Re: [PATCH] build: encapsulate grep for local_miss_maps in a function
08/03/2022 19:52, Usama Arif:
> check-symbols-maps.sh runs with the -e option to exit as soon as
> there is an error. Currently the build is failing as the search of
> grep -L is empty (which is the case for all version.map files as
> they have the local symbol) which causes the script to return
> with an error.
It depends on the shell I guess because most machines run well.
> This patch encapsulates the grep call in a function, so that only the function
> errors out and the build is successful.
That's a strange workaround. I don't understand why it works.
I am submitting a simpler fix adding " || true"
> -local_miss_maps=$(grep -L 'local: \*;' $@)
> +find_local_miss_maps ()
> +{
> +local local_miss_maps=$(grep -L 'local: \*;' $@)
> +echo "$local_miss_maps"
> +
> +}
> +
> +local_miss_maps=$(find_local_miss_maps $@)
Thanks for raising the issue and proposing a solution.
[PATCH] devtools: fix symbols check
In some environments, the check of local symbols catch-all
was failing. Note: this script is called during the build.
The reason is that grep returns an error if nothing is found.
The option -e of the shell script makes this error fatal.
It is not always fatal because the grep is in a command substitution.
Fixes: b403498e1422 ("build: hide local symbols in shared libraries")
Reported-by: Usama Arif
Signed-off-by: Thomas Monjalon
---
devtools/check-symbol-maps.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/check-symbol-maps.sh b/devtools/check-symbol-maps.sh
index 8266fdf9ea..32e1fa5c8f 100755
--- a/devtools/check-symbol-maps.sh
+++ b/devtools/check-symbol-maps.sh
@@ -53,7 +53,7 @@ if [ -n "$duplicate_symbols" ] ; then
ret=1
fi
-local_miss_maps=$(grep -L 'local: \*;' $@)
+local_miss_maps=$(grep -L 'local: \*;' $@ || true)
if [ -n "$local_miss_maps" ] ; then
echo "Found maps without local catch-all:"
echo "$local_miss_maps"
--
2.34.1
Re: [PATCH] devtools: fix symbols check
08/03/2022 22:18, Thomas Monjalon:
> In some environments, the check of local symbols catch-all
> was failing. Note: this script is called during the build.
>
> The reason is that grep returns an error if nothing is found.
> The option -e of the shell script makes this error fatal.
> It is not always fatal because the grep is in a command substitution.
>
> Fixes: b403498e1422 ("build: hide local symbols in shared libraries")
>
> Reported-by: Usama Arif
> Signed-off-by: Thomas Monjalon
Applied quickly to fix the build in some environments.
Re: [PATCH] devtools: fix symbols check
On Tue, Mar 08, 2022 at 10:18:59PM +0100, Thomas Monjalon wrote:
> In some environments, the check of local symbols catch-all
> was failing. Note: this script is called during the build.
>
> The reason is that grep returns an error if nothing is found.
> The option -e of the shell script makes this error fatal.
> It is not always fatal because the grep is in a command substitution.
>
> Fixes: b403498e1422 ("build: hide local symbols in shared libraries")
>
> Reported-by: Usama Arif
> Signed-off-by: Thomas Monjalon
> ---
> devtools/check-symbol-maps.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/devtools/check-symbol-maps.sh b/devtools/check-symbol-maps.sh
> index 8266fdf9ea..32e1fa5c8f 100755
> --- a/devtools/check-symbol-maps.sh
> +++ b/devtools/check-symbol-maps.sh
> @@ -53,7 +53,7 @@ if [ -n "$duplicate_symbols" ] ; then
> ret=1
> fi
>
> -local_miss_maps=$(grep -L 'local: \*;' $@)
> +local_miss_maps=$(grep -L 'local: \*;' $@ || true)
reviewed-by Liang Ma
I'm curious to know how can the CI passed with original patch.
> if [ -n "$local_miss_maps" ] ; then
> echo "Found maps without local catch-all:"
> echo "$local_miss_maps"
> --
> 2.34.1
>
Re: [PATCH v18 8/8] eal: implement functions for mutex management
Hi Konstantin, 2022-02-24 17:29 (UTC+), Ananyev, Konstantin: [...] > > However, DmitryM suggested using Slim Reader-Writer lock (SRW): > > https://docs.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks > > instead of CRITICAL_SECTION. > > It seems to be a much better option: > > > > * sizeof(SRWLOCK) == 8 (technically "size of a pointer"), > > same as sizeof(pthread_mutex_t) on a typical Linux. > > Layout of data structures containing rte_thread_mutex_t > > can be the same on Windows and Unix, > > which simplifies design and promises similar less performance differences. > > > > * Can be taken by multiple readers and one writer, > > which is semantically similar to pthread_mutex_t > > Not sure I understand you here: > pthread_mutex provides only mutually-exclusive lock semantics. > For RW lock there exists: pthread_rwlock_t. > Off-course you can use rwlock fo exclusive locking too - > if all callers will use only writer locks, but usually that's no point to do > that - > mutexes are simpler and faster. > That's for posix-like systems, don't know much about Windows environment :) It is different on Windows. Multiple sources claim SRW lock is faster than CRITICAL_SECTION even when used only for exclusive locking. SRW locks do not support recursive locking, while CRITICAL_SECTION is always recursive. I see PTHREAD_MUTEX_RECURSIVE used in net/failsafe and raw/ifpga. CRITICAL_SECTION also keeps debug information to analyze deadlocks (can't say much here, never used this feature). > > Technically it can be a "typedef uintptr_t" or a structure wrapping it. > > Again can't say much about Windows, but pthread_mutex_t > can (and is) bigger then then 8 bytes. My bad, I measured incorrectly: sizeof(pthread_mutex_t) is 40 on my system.
Re: [PATCH v18 8/8] eal: implement functions for mutex management
Hi Stephen, 2022-02-24 09:44 (UTC-0800), Stephen Hemminger: > There seems to be some confusion here: >pthread_mutex put thread to sleep if contended and on linux are built on > the futex system call. >pthread_rwlock are the reader/writer versions of these. > > The DPDK has primitives for multiple types of locks: spinlock, rwlock, > ticketlock, pflock, etc >these are build using atomic primitives (no syscall). >these are platform independent >these spin if contended > > Not sure about Windows, but it looks like slim rwlocks came from Windows NT > and are an implementation > of the same kind of spinning lock DPDK already has. Both CRITICAL_SECTION and SRW lock spin shortly before going into kernel, but both do this eventually---SRW lock is not a purely user space primitive.
Re: [PATCH] devtools: fix symbols check
08/03/2022 22:27, Liang Ma:
> On Tue, Mar 08, 2022 at 10:18:59PM +0100, Thomas Monjalon wrote:
> > In some environments, the check of local symbols catch-all
> > was failing. Note: this script is called during the build.
> >
> > The reason is that grep returns an error if nothing is found.
> > The option -e of the shell script makes this error fatal.
> > It is not always fatal because the grep is in a command substitution.
> >
> > Fixes: b403498e1422 ("build: hide local symbols in shared libraries")
> >
> > Reported-by: Usama Arif
> > Signed-off-by: Thomas Monjalon
> > ---
> > devtools/check-symbol-maps.sh | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/devtools/check-symbol-maps.sh b/devtools/check-symbol-maps.sh
> > index 8266fdf9ea..32e1fa5c8f 100755
> > --- a/devtools/check-symbol-maps.sh
> > +++ b/devtools/check-symbol-maps.sh
> > @@ -53,7 +53,7 @@ if [ -n "$duplicate_symbols" ] ; then
> > ret=1
> > fi
> >
> > -local_miss_maps=$(grep -L 'local: \*;' $@)
> > +local_miss_maps=$(grep -L 'local: \*;' $@ || true)
> reviewed-by Liang Ma
>
> I'm curious to know how can the CI passed with original patch.
You are suggesting I did not check the CI.
The Intel check failed because of an apply issue,
so I was not able to see the compilation result:
http://mails.dpdk.org/archives/test-report/2022-March/267685.html
Later in the day, the UNH CI failed for the good reason
but it was too late, the patch was applied:
http://mails.dpdk.org/archives/test-report/2022-March/267723.html
That's what happens when I want to introduce a little additional check
at the last minute before a release candidate.
Re: [PATCH v2 2/2] gpudev: use page_size in comm_list creation
09/03/2022 00:59, eagost...@nvidia.com:
> From: Elena Agostini
>
> Memory allocated for CPU mapping the status flag
> in the communication list should be aligned to the
> GPU page size.
>
> Fixes: 9b8cae4d991e ("gpudev: use CPU mapping in communication list")
> Signed-off-by: Elena Agostini
Patches squashed and applied, thanks.
Re: [PATCH v1] doc: fix telemetry example for cryptodev
08/03/2022 16:56, Sean Morrissey: > Blank line added to the final telemetry example for the > cryptography device library as to fix the example > rendering. Even for a simple fix like that, you need to add a Fixes: line so we know where to backport (or not). > > Signed-off-by: Sean Morrissey > --- > #. Get the capabilities of a particular Crypto device:: > + > --> /cryptodev/caps,0
Re: [PATCH v3] maintainers: update for testpmd
24/02/2022 14:15, Dumitrescu, Cristian: > > > -Original Message- > > From: Zhang, Yuying > > Sent: Thursday, February 10, 2022 2:51 PM > > To: dev@dpdk.org; Li, Xiaoyun ; Yigit, Ferruh > > ; tho...@monjalon.net; Dumitrescu, Cristian > > > > Cc: Zhang, Yuying > > Subject: [PATCH v3] maintainers: update for testpmd > > > > Move 'test-pmd/cmdline_tm.*' files under > > "Traffic Management API" component. > > Move 'test-pmd/cmdline_mtr.*' files under > > "Traffic Metering and Policing API" component. > > > > Signed-off-by: Yuying Zhang > > --- > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -407,11 +407,13 @@ Traffic Management API - EXPERIMENTAL > > M: Cristian Dumitrescu > > T: git://dpdk.org/next/dpdk-next-net > > F: lib/ethdev/rte_tm* > > +F: app/test-pmd/cmdline_tm.* > > > > Traffic Metering and Policing API - EXPERIMENTAL > > M: Cristian Dumitrescu > > T: git://dpdk.org/next/dpdk-next-net > > F: lib/ethdev/rte_mtr* > > +F: app/test-pmd/cmdline_mtr.* > > Acked-by: Cristian Dumitrescu Applied, thanks.
Re: [PATCH v2] maintainers: update for testpmd
10/02/2022 16:03, Yuying Zhang: > Move 'test-pmd/bpf_cmd.*' files under BPF component. > > Signed-off-by: Yuying Zhang > Acked-by: Ferruh Yigit Assuming Konstantin is OK. Applied, thanks.
Re: [PATCH] devtools: fix symbols check
On Tue, Mar 08, 2022 at 11:05:49PM +0100, Thomas Monjalon wrote:
> 08/03/2022 22:27, Liang Ma:
> > On Tue, Mar 08, 2022 at 10:18:59PM +0100, Thomas Monjalon wrote:
> > > In some environments, the check of local symbols catch-all
> > > was failing. Note: this script is called during the build.
> > >
> > > The reason is that grep returns an error if nothing is found.
> > > The option -e of the shell script makes this error fatal.
> > > It is not always fatal because the grep is in a command substitution.
> > >
> > > Fixes: b403498e1422 ("build: hide local symbols in shared libraries")
> > >
> > > Reported-by: Usama Arif
> > > Signed-off-by: Thomas Monjalon
> > > ---
> > > devtools/check-symbol-maps.sh | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/devtools/check-symbol-maps.sh b/devtools/check-symbol-maps.sh
> > > index 8266fdf9ea..32e1fa5c8f 100755
> > > --- a/devtools/check-symbol-maps.sh
> > > +++ b/devtools/check-symbol-maps.sh
> > > @@ -53,7 +53,7 @@ if [ -n "$duplicate_symbols" ] ; then
> > > ret=1
> > > fi
> > >
> > > -local_miss_maps=$(grep -L 'local: \*;' $@)
> > > +local_miss_maps=$(grep -L 'local: \*;' $@ || true)
> > reviewed-by Liang Ma
> >
> > I'm curious to know how can the CI passed with original patch.
>
> You are suggesting I did not check the CI.
>
> The Intel check failed because of an apply issue,
> so I was not able to see the compilation result:
> http://mails.dpdk.org/archives/test-report/2022-March/267685.html
>
> Later in the day, the UNH CI failed for the good reason
> but it was too late, the patch was applied:
> http://mails.dpdk.org/archives/test-report/2022-March/267723.html
>
> That's what happens when I want to introduce a little additional check
> at the last minute before a release candidate.
No worry, I thought the CI has a bug.
>
>
Re: [PATCH] maintainers: Update MAINTAINERS for FIPS validation
> > Replace Marko Kovacevic with Brian Dooley and Fan Zhang > > > > FIPS validation example > > -M: Marko Kovacevic > > +M: Fan Zhang > > +M: Brian Dooley > > F: examples/fips_validation/ > > F: doc/guides/sample_app_ug/fips_validation.rst > > > Acked-by: Fan Zhang Applied, thanks.
Re: [PATCH v1] maintainers: add explicit maintainer for some bbdev PMDs
03/03/2022 19:51, Nicolas Chautru: > These were implicit from DPDK script but adding > separate reference to make it explicit > > Signed-off-by: Nicolas Chautru > --- > MAINTAINERS | 4 > 1 file changed, 4 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7577834..004ec91 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -421,6 +421,10 @@ T: git://dpdk.org/next/dpdk-next-crypto > F: lib/bbdev/ > F: doc/guides/prog_guide/bbdev.rst > F: drivers/baseband/ I think you can remove the above catch-all. > +F: drivers/baseband/turbo_sw/ > +F: drivers/baseband/fpga_lte_fec/ > +F: drivers/baseband/fpga_5gnr_fec/ > +F: drivers/baseband/acc100/ I would prefer a separate section for Intel baseband drivers. > F: doc/guides/bbdevs/ > F: app/test-bbdev/ > F: doc/guides/tools/testbbdev.rst
RE: [PATCH v1] net/i40e: fix build issue with 16B descriptor on Arm
> -Original Message-
> From: Joyce Kong
> Sent: Friday, March 4, 2022 3:35 PM
> To: Ruifeng Wang ; Xing, Beilei
> ; Joyce Kong
> Cc: dev@dpdk.org; n...@arm.com
> Subject: [PATCH v1] net/i40e: fix build issue with 16B descriptor on Arm
>
> For NEON vector path, there is an issue when building with 16B descriptor:
> incompatible types when assigning to type ‘uint64x2_t’
> from type ‘uint32x4_t’
> 180 | descs[3] = vbslq_u32(v_desc3_mask, v_zeros,
> vreinterpretq_u32_u64(descs[3]));
> | ^
>
> The fix is to add interpretation between type 'uint64x2_t'
> and type 'uint32x4_t'.
>
> Fixes: dba9e3bcd9bb ("net/i40e: add flow mark capability to NEON Rx")
>
> Signed-off-by: Joyce Kong
> Reviewed-by: Ruifeng Wang
Reviewed-by: Qi Zhang
Applied to dpdk-next-net-intel.
Thanks
Qi
Re: [PATCH v2 6/8] remove self from timers maintainers
21/12/2021 20:57, Robert Sanford: > Remove self from Timers maintainers. > > Signed-off-by: Robert Sanford Applied
release candidate 22.03-rc3
A new DPDK release candidate is ready for testing: https://git.dpdk.org/dpdk/tag/?id=v22.03-rc3 There are 102 new patches in this snapshot. Release notes: https://doc.dpdk.org/guides/rel_notes/release_22_03.html This should be the last release candidate. Only documentation and critical bug fixes are accepted until the release. Please test and report issues on bugs.dpdk.org. You may share some release validation results by replying to this message at dev@dpdk.org. Please think about sharing your roadmap now for DPDK 22.07. Thank you everyone
[PATCH v1 0/2] bbdev: add device info on queue topology
Addressing an historical concern that the device info struct only imperfectly captured what queues are available on the device (number of operation and priority). This ended up being an iterative process for application to find each queue could be configured. ie. the gap was captured as technical debt previously in comments /* This isn't ideal because it reports the maximum number of queues but * does not provide info on how many can be uplink/downlink or different * priorities */ This is now being exposed explictly based on the what the device actually supports using the existing info_get api Note: did not update the release yet notes since it will go in next release Nicolas Chautru (2): bbdev: add device info on queue topology drivers/baseband: update PMDs to expose queue per operation drivers/baseband/acc100/rte_acc100_pmd.c | 29 +- drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 8 ++ drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 8 ++ drivers/baseband/la12xx/bbdev_la12xx.c | 8 +- lib/bbdev/rte_bbdev.h | 4 +++ 5 files changed, 44 insertions(+), 13 deletions(-) -- 1.8.3.1
[PATCH v1 1/2] bbdev: add device info on queue topology
Adding more options in the API to expose the number
of queues exposed and related priority.
Signed-off-by: Nicolas Chautru
---
lib/bbdev/rte_bbdev.h | 4
1 file changed, 4 insertions(+)
diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
index b88c881..10c06b6 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -274,6 +274,10 @@ struct rte_bbdev_driver_info {
/** Maximum number of queues supported by the device */
unsigned int max_num_queues;
+ /** Maximum number of queues supported per operation type */
+ unsigned int num_queues[RTE_BBDEV_OP_TYPE_COUNT];
+ /** Priority level supported per operation type */
+ unsigned int queue_priority[RTE_BBDEV_OP_TYPE_COUNT];
/** Queue size limit (queue size must also be power of 2) */
uint32_t queue_size_lim;
/** Set if device off-loads operation to hardware */
--
1.8.3.1
[PATCH v1 2/2] drivers/baseband: update PMDs to expose queue per operation
Add support in existing bbdev PMDs for the explicit number of queue
and priority for each operation type configured on the device.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc100/rte_acc100_pmd.c | 29 +-
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 8 ++
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 8 ++
drivers/baseband/la12xx/bbdev_la12xx.c | 8 +-
4 files changed, 40 insertions(+), 13 deletions(-)
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
b/drivers/baseband/acc100/rte_acc100_pmd.c
index de7e4bc..49cc9d2 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -966,6 +966,7 @@
struct rte_bbdev_driver_info *dev_info)
{
struct acc100_device *d = dev->data->dev_private;
+ int i;
static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
{
@@ -1061,19 +1062,23 @@
/* Read and save the populated config from ACC100 registers */
fetch_acc100_config(dev);
- /* This isn't ideal because it reports the maximum number of queues but
-* does not provide info on how many can be uplink/downlink or different
-* priorities
-*/
- dev_info->max_num_queues =
- d->acc100_conf.q_dl_5g.num_aqs_per_groups *
- d->acc100_conf.q_dl_5g.num_qgroups +
- d->acc100_conf.q_ul_5g.num_aqs_per_groups *
- d->acc100_conf.q_ul_5g.num_qgroups +
- d->acc100_conf.q_dl_4g.num_aqs_per_groups *
- d->acc100_conf.q_dl_4g.num_qgroups +
- d->acc100_conf.q_ul_4g.num_aqs_per_groups *
+ /* Expose number of queues */
+ dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_DEC] =
d->acc100_conf.q_ul_4g.num_aqs_per_groups *
d->acc100_conf.q_ul_4g.num_qgroups;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_ENC] =
d->acc100_conf.q_dl_4g.num_aqs_per_groups *
+ d->acc100_conf.q_dl_4g.num_qgroups;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_DEC] =
d->acc100_conf.q_ul_5g.num_aqs_per_groups *
+ d->acc100_conf.q_ul_5g.num_qgroups;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_ENC] =
d->acc100_conf.q_dl_5g.num_aqs_per_groups *
+ d->acc100_conf.q_dl_5g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_TURBO_DEC] =
d->acc100_conf.q_ul_4g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_TURBO_ENC] =
d->acc100_conf.q_dl_4g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_DEC] =
d->acc100_conf.q_ul_5g.num_qgroups;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_ENC] =
d->acc100_conf.q_dl_5g.num_qgroups;
+ dev_info->max_num_queues = 0;
+ for (i = RTE_BBDEV_OP_NONE; i < RTE_BBDEV_OP_TYPE_COUNT; i++)
+ dev_info->max_num_queues += dev_info->num_queues[i];
dev_info->queue_size_lim = ACC100_MAX_QUEUE_DEPTH;
dev_info->hardware_accelerated = true;
dev_info->max_dl_queue_priority =
diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 15d23d6..f92b59a 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -382,6 +382,14 @@
if (hw_q_id != FPGA_INVALID_HW_QUEUE_ID)
dev_info->max_num_queues++;
}
+ /* Expose number of queue per operation type */
+ dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_DEC] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_ENC] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_DEC] = dev_info->max_num_queues
/ 2;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_ENC] = dev_info->max_num_queues
/ 2;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_DEC] = 1;
+ dev_info->queue_priority[RTE_BBDEV_OP_LDPC_ENC] = 1;
}
/**
diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
index 21d3529..56d1baf 100644
--- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
+++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
@@ -654,6 +654,14 @@ struct __rte_cache_aligned fpga_queue {
if (hw_q_id != FPGA_INVALID_HW_QUEUE_ID)
dev_info->max_num_queues++;
}
+ /* Expose number of queue per operation type */
+ dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_DEC] = dev_info->max_num_queues
/ 2;
+ dev_info->num_queues[RTE_BBDEV_OP_TURBO_ENC] = dev_info->max_num_queues
/ 2;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_DEC] = 0;
+ dev_info->num_queues[RTE_BBDEV_OP_LDPC_ENC] = 0;
+ dev_info->queue_priority[RTE_BBDEV_OP_TU
Re: [PATCH v4] net/bonding: another fix to LACP mempool size
On Tue, 8 Mar 2022 22:24:02 +0800
Gaoxiang Liu wrote:
> diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
> index 1e7a3c1527..fa15ed710f 100644
> --- a/lib/mempool/rte_mempool.h
> +++ b/lib/mempool/rte_mempool.h
> @@ -56,6 +56,8 @@
> extern "C" {
> #endif
>
> +#define RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER 1.5
Why is a magic number from bonding ending up in the user API for mempool?
Re: [PATCH v4] net/bonding: another fix to LACP mempool size
On Tue, 8 Mar 2022 22:24:02 +0800 Gaoxiang Liu wrote: > + cache_size = RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? > + 32 : RTE_MEMPOOL_CACHE_MAX_SIZE; No need to open code a min(). cache_size = RTE_MIN(RTE_MEMPOOL_CACHE_SIZE, 32);
Re: [PATCH v1 1/2] bbdev: add device info on queue topology
On Tue, 8 Mar 2022 16:22:34 -0800
Nicolas Chautru wrote:
> diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
> index b88c881..10c06b6 100644
> --- a/lib/bbdev/rte_bbdev.h
> +++ b/lib/bbdev/rte_bbdev.h
> @@ -274,6 +274,10 @@ struct rte_bbdev_driver_info {
>
> /** Maximum number of queues supported by the device */
> unsigned int max_num_queues;
> + /** Maximum number of queues supported per operation type */
> + unsigned int num_queues[RTE_BBDEV_OP_TYPE_COUNT];
> + /** Priority level supported per operation type */
> + unsigned int queue_priority[RTE_BBDEV_OP_TYPE_COUNT];
> /** Queue size limit (queue size must also be power of 2) */
> uint32_t queue_size_lim;
> /** Set if device off-loads operation to hardware */
This breaks ABI of rte_bbdev_info_get.
RE: [PATCH v2 2/2] app/testpmd:fix testpmd quit failure
> -Original Message-
> From: Yigit, Ferruh
> Sent: 2022年3月5日 0:16
> To: Wu, WenxuanX ; Li, Xiaoyun
> ; dev@dpdk.org
> Cc: sta...@dpdk.org
> Subject: Re: [PATCH v2 2/2] app/testpmd:fix testpmd quit failure
>
> On 3/3/2022 1:22 PM, Wu, WenxuanX wrote:
>
> moved down, please don't top post
>
> >> -Original Message-
> >> From: Wu, WenxuanX
> >> Sent: 2022年2月23日 19:33
> >> To: Li, Xiaoyun ; Yigit, Ferruh
> >> ; dev@dpdk.org
> >> Cc: Wu, WenxuanX ; sta...@dpdk.org
> >> Subject: [PATCH v2 2/2] app/testpmd:fix testpmd quit failure
> >>
> >> From: wenxuan wu
> >>
> >> When testpmd start ed with 1 pf and 2 vfs, testpmd quited while vfs
> >> were still alive would result in failure. Root cause is that pf had
> >> been released already but vfs were still accessing by func
> >> rte_eth_dev_info_get, which would result in heap-free-after-use error.
> >>
> >> By quitting our ports in reverse order to avoid this.And the order is
> >> guaranteed that vf are created after pfs.
> >>
> >> Fixes: d3a274ce9dee ("app/testpmd: handle SIGINT and SIGTERM")
> >> Cc: sta...@dpdk.org
> >>
> >> Signed-off-by: wenxuan wu
> >> ---
> >> app/test-pmd/testpmd.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> >> e1da961311..698b6d8cc4 100644
> >> --- a/app/test-pmd/testpmd.c
> >> +++ b/app/test-pmd/testpmd.c
> >> @@ -3384,12 +3384,12 @@ pmd_test_exit(void) #endif
> >>if (ports != NULL) {
> >>no_link_check = 1;
> >> - RTE_ETH_FOREACH_DEV(pt_id) {
> >> + RTE_ETH_FOREACH_DEV_REVERSE(pt_id) {
> >>printf("\nStopping port %d...\n", pt_id);
> >>fflush(stdout);
> >>stop_port(pt_id);
> >>}
> >> - RTE_ETH_FOREACH_DEV(pt_id) {
> >> + RTE_ETH_FOREACH_DEV_REVERSE(pt_id) {
> >>printf("\nShutting down port %d...\n", pt_id);
> >>fflush(stdout);
> >>close_port(pt_id);
> >> --
> >> 2.25.1
> >
> >
> > I found this meaning in DPDK testplan.
> > Note that currently hot-plugging of representor ports is not supported so
> > all
> the required representors must be specified on the creation of the PF or the
> trusted VF.
> > When testpmd is started with pf and vf representors, the order of
> representor is determined on creation. So it is guaranteed that ,pf is beneath
> the vf representors, we implemented in a reverse way is acceptable just at
> present, depends on when the hot-plugging of representor is supported.
> >
>
> The patch mentions from PF and VFs, and now you are referring to port
> representor.
> Is the problem related to VF or port representor.
>
> For both, VF and port reporesentor should be closed before PF, that part is
> OK. My comment is if reversing port id traverse will fix the issue or do we
> need more complex solution.
> Like have APIs to get VF and representor ports from a given port id, and free
> them first.
This patch did fix the issue ,and was verified.But it was rejected.
[Bug 956] [dpdk-22.03][asan] dpdk-pdump: detected memory leaks when quit dpdk-pdump
https://bugs.dpdk.org/show_bug.cgi?id=956 Bug ID: 956 Summary: [dpdk-22.03][asan] dpdk-pdump: detected memory leaks when quit dpdk-pdump Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: weix.l...@intel.com Target Milestone: --- [Environmen] DPDK version: Use make showversion or for a non-released version: git remote -v && git show-ref --heads DPDK-22.03-rc1: ee05a93e1e6633d0fdec409faf09f12a2e05b991 Other software versions: N/A OS: Ubuntu 20.04.3 LTS/Linux 5.8.0-48-generic Compiler: gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) Hardware platform: Intel(R) Xeon(R) Platinum 8280M CPU @ 2.70GHz NIC hardware: Intel Ethernet Controller XL710 for 40GbE QSFP+ 1583 NIC firmware: i40e-2.17.15/8.30 0x8000a4ae 1.2926.0 [Test Setup] Steps to reproduce List the steps to reproduce the issue. 1. Bind 2 NIC port to vfio-pci: dpdk-devbind.py --force --bind=vfio-pci :af:00.0 :af:00.1 2. Build DPDK enable ASAN: CC=gcc meson -Denable_kmods=True -Dlibdir=lib -Dbuildtype=debug -Db_lundef=false -Db_sanitize=address --default-library=static x86_64-native-linuxapp-gcc ninja -C x86_64-native-linuxapp-gcc 3. Start vhost-user dpdk-testpmd: x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 28,29,30,31,32,33,34,35,36 -n 4 -a :af:00.0 -a :af:00.1 --file-prefix=vhost --vdev 'eth_vhost0,iface=vhost-net0,queues=8,client=1' -- -i --nb-cores=5 --txq=8 --rxq=8 --txd=1024 --rxd=1024 4. Start virtio-user dpdk-testpmd: x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 38,39 -n 4 --file-prefix=virtio --no-pci --vdev=net_virtio_user0,mac=00:01:02:03:04:05,path=vhost-net0,server=1,queues=8,mrg_rxbuf=1,in_order=1 -- -i --txd=1024 --rxd=1024 --nb-cores=1 --rxq=8 --txq=8 5. Start dpdk-pdump to capture the virtio-user side packets: x86_64-native-linuxapp-gcc/app/dpdk-pdump -v --file-prefix=virtio -- --pdump 'device_id=net_virtio_user0,queue=*,rx-dev=/root/pdump-rx.pcap,mbuf-size=8000' 6. Execute `CTRL + C` to quit dpdk-pdump. Show the output from the previous commands. root@dut220:/home/lingwei/dpdk# x86_64-native-linuxapp-gcc/app/dpdk-pdump -v --file-prefix=virtio -- --pdump 'device_id=net_virtio_user0,queue=*,rx-dev=/root/pdump-rx.pcap,mbuf-size=8000' EAL: Detected CPU lcores: 112 EAL: Detected NUMA nodes: 2 EAL: RTE Version: 'DPDK 22.03.0-rc1' EAL: Detected static linkage of DPDK EAL: Multi-process socket /var/run/dpdk/virtio/mp_socket_2823035_b689b255c3584 EAL: Selected IOVA mode 'VA' EAL: VFIO support initialized EAL: :80:04.0 cannot find TAILQ entry for PCI device! EAL: Requested device :80:04.0 cannot be used EAL: :80:04.1 cannot find TAILQ entry for PCI device! EAL: Requested device :80:04.1 cannot be used EAL: :80:04.2 cannot find TAILQ entry for PCI device! EAL: Requested device :80:04.2 cannot be used Port 1 MAC: 02 70 63 61 70 00 core (0), capture for (1) tuples - port 0 device (net_virtio_user0) queue 65535 Signal 2 received, preparing to exit... # PDUMP DEBUG STATS # -packets dequeued: 0 -packets transmitted to vdev: 0 -packets freed:0 = ==2823035==ERROR: LeakSanitizer: detected memory leaks Direct leak of 136 byte(s) in 1 object(s) allocated from: #0 0x7fca5ba77dc6 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6) #1 0x564d8f98b8ba in alloc_devargs ../drivers/bus/vdev/vdev.c:243 #2 0x564d8f98bb1a in insert_vdev ../drivers/bus/vdev/vdev.c:276 #3 0x564d8f98cb15 in vdev_action ../drivers/bus/vdev/vdev.c:449 #4 0x564d8f88e743 in process_msg ../lib/eal/common/eal_common_proc.c:383 #5 0x564d8f88e92b in mp_handle ../lib/eal/common/eal_common_proc.c:401 #6 0x564d8f871ba0 in ctrl_thread_init ../lib/eal/common/eal_common_thread.c:203 #7 0x7fca5b749608 in start_thread /build/glibc-eX1tMB/glibc-2.31/nptl/pthread_create.c:477 Indirect leak of 1 byte(s) in 1 object(s) allocated from: #0 0x7fca5ba003dd in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x963dd) #1 0x564d8f98b95b in alloc_devargs ../drivers/bus/vdev/vdev.c:251 #2 0x564d8f98bb1a in insert_vdev ../drivers/bus/vdev/vdev.c:276 #3 0x564d8f98cb15 in vdev_action ../drivers/bus/vdev/vdev.c:449 #4 0x564d8f88e743 in process_msg ../lib/eal/common/eal_common_proc.c:383 #5 0x564d8f88e92b in mp_handle ../lib/eal/common/eal_common_proc.c:401 #6 0x564d8f871ba0 in ctrl_thread_init ../lib/eal/common/eal_common_thread.c:203 #7 0x7fca5b749608 in start_thread /build/glibc-eX1tMB/glibc-2.31/nptl/pthread_create.c:477 SUMMARY: AddressSanitizer: 137 byte(s) leaked in 2 allocation(s). [Expected Result] Explain what is the expected result in text or as an example output: Can quit dpdk-
