Re: [PATCH v1 1/1] usertools/devbind: fix missing active marker

[Robin Jarry]

Anatoly Burakov, Nov 27, 2024 at 16:42:

When adding NUMA node printouts, the "*Active*" marker was accidentally
omitted. Add it back in.

Fixes: a7d69cef8f20 ("usertools/devbind: print device NUMA node")

Signed-off-by: Anatoly Burakov 


Acked-by: Robin Jarry 

Re: [PATCH v1 1/1] usertools/devbind: fix NUMA node display

[Robin Jarry]

Anatoly Burakov, Nov 28, 2024 at 17:08:

On some systems, even though NUMA nodes may be present in sysfs, the lspci
command will not have NUMANode keys in them, which will cause an exception.
Fix to check if NUMANode keys are available in lspci output before enabling
NUMA node output.

Fixes: a7d69cef8f20 ("usertools/devbind: print device NUMA node")

Signed-off-by: Anatoly Burakov 


Acked-by: Robin Jarry 

Re: [PATCH v3 1/1] usertools/devbind: allow changing UID/GID for VFIO

[Robin Jarry]

Anatoly Burakov, Nov 27, 2024 at 10:13:

Currently, when binding a device to VFIO, the UID/GID for the device will
always stay as system default (`root`). Yet, when running DPDK as non-root
user, one has to change the UID/GID of the device to match the user's
UID/GID to use the device.

This patch adds an option to `dpdk-devbind.py` to change the UID/GID of
the device when binding it to VFIO.

Signed-off-by: Anatoly Burakov 
---


Reviewed-by: Robin Jarry 

Re: [PATCH v1 1/1] usertools/devbind: fix NUMA node display

[Burakov, Anatoly]

On 11/28/2024 6:20 PM, Stephen Hemminger wrote:

On Thu, 28 Nov 2024 16:08:55 +
Anatoly Burakov  wrote:


+# occasionally, system may report NUMA support but lspci will not, so we
+# want to go through all devices and see if any of them do not have 
NUMANode
+# property - this will mean it is not safe to try to access it
+for device_dict in devices.values():
+if "NUMANode" not in device_dict:
+return False


Any indication as to why this happens, what kernel, what device?


We've had internal validation team report this happenning on VM's, 
particularly ESXi. I did not dig deeper as to what particular 
configurations cause this to happen, I didn't have a chance to reproduce 
this myself.


--
Thanks,
Anatoly

Re: [PATCH v1 1/1] usertools/devbind: fix NUMA node display

[Burakov, Anatoly]

On 11/29/2024 10:12 AM, Burakov, Anatoly wrote:

On 11/28/2024 6:20 PM, Stephen Hemminger wrote:

On Thu, 28 Nov 2024 16:08:55 +
Anatoly Burakov  wrote:

+    # occasionally, system may report NUMA support but lspci will 
not, so we
+    # want to go through all devices and see if any of them do not 
have NUMANode

+    # property - this will mean it is not safe to try to access it
+    for device_dict in devices.values():
+    if "NUMANode" not in device_dict:
+    return False


Any indication as to why this happens, what kernel, what device?


We've had internal validation team report this happenning on VM's, 
particularly ESXi. I did not dig deeper as to what particular 
configurations cause this to happen, I didn't have a chance to reproduce 
this myself.




I just reproduced this on my machine by disabling NUMA support in BIOS. 
I can confirm that /sys/devices/system/node exists in sysfs but lspci 
will not report NUMA node in that case. So, it probably applies to all 
kernels.


--
Thanks,
Anatoly

[PATCH v1 1/1] usertools/devbind: fix NUMA node display

[Anatoly Burakov]

On some systems (particularly ones with NUMA disabled in BIOS), even
though NUMA nodes may be present in sysfs, the lspci command will not
have NUMANode keys in them, which will cause an exception. Fix to check
if NUMANode keys are available in lspci output before enabling NUMA node
output.

Fixes: a7d69cef8f20 ("usertools/devbind: print device NUMA node")

Signed-off-by: Anatoly Burakov 
---

Notes:
This is an alternative fix to patch 34067 [1]

The difference between this and the original patch is that we drop the
check for sysfs node, because it does not give us any useful information,
and instead rely just on lspci dictionary to let us know if it's safe to
enable NUMA node display.

[1] 
https://patches.dpdk.org/project/dpdk/patch/9af1231398c4ba116d3b89164690feace37293a9.1732810125.git.anatoly.bura...@intel.com/

 usertools/dpdk-devbind.py | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index 34f8f3ed3b..283707fc16 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -111,11 +111,6 @@
 args = []
 
 
-# check if this system has NUMA support
-def is_numa():
-return os.path.exists('/sys/devices/system/node')
-
-
 # check if a specific kernel module is loaded
 def module_is_loaded(module):
 global loaded_modules
@@ -595,9 +590,12 @@ def show_device_status(devices_type, device_name, 
if_field=False):
 dpdk_drv = []
 no_drv = []
 
+print_numa = True  # by default, assume we can print NUMA information
+
 # split our list of network devices into the three categories above
 for d in devices.keys():
 if device_type_match(devices[d], devices_type):
+print_numa &= "NUMANode" in devices[d]
 if not has_driver(d):
 no_drv.append(devices[d])
 continue
@@ -616,8 +614,6 @@ def show_device_status(devices_type, device_name, 
if_field=False):
 print("".join('=' * len(msg)))
 return
 
-print_numa = is_numa()
-
 # print each category separately, so we can clearly see what's used by DPDK
 if dpdk_drv:
 extra_param = "drv=%(Driver_str)s unused=%(Module_str)s"
-- 
2.43.5

Re: [PATCH] power/amd_uncore: add e-smi installation instructions

[Thomas Monjalon]

29/11/2024 05:32, Sivaprasad Tummala:
> Added section for installing and building the E-SMI library
> for AMD EPYC Uncore support and version requirements.
> 
> Signed-off-by: Sivaprasad Tummala 
> ---
>  doc/guides/prog_guide/power_man.rst | 32 +
>  1 file changed, 32 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/power_man.rst 
> b/doc/guides/prog_guide/power_man.rst
> index 74039e5786..d367a81596 100644
> --- a/doc/guides/prog_guide/power_man.rst
> +++ b/doc/guides/prog_guide/power_man.rst
> @@ -249,6 +249,38 @@ Additionally, the EPYC System Management Interface 
> In-band Library for Linux
>  offers essential API, enabling user-space software
>  to effectively manage system functions.
>  
> +E-SMI Installation
> +--
> +
> +To build DPDK with AMD EPYC Uncore the user is required to download the e-smi
> +library from `here `_
> +and compile it on their user system before building DPDK.
> +
> +.. code-block:: console
> +
> +cd esmi_ib_library
> +cmake .
> +sudo make install
> +cp /opt/e-sms/e_smi/lib/* /usr/local/lib/*
> +cp /opt/e-sms/e_smi/include/* /usr/local/include/*

Why copying the files?
You can specify the directories in an environment variable.
There is no pkg-config file?

> +
> +Library file, header and tool are installed at /opt/e-sms.
> +
> +Note: Library is dependent on amd_hsmp.h header and without this, 
> compilation will break.

Yes, it does not compile on my machine (with Linux 6.12):

e_smi.c:566:27: error: ‘HSMP_GET_RAPL_UNITS’ undeclared

What should I do?

> +
> +The library requires CMake (v3.5.0) to be built.
> +
> +As a reference, the following table shows a mapping between the DPDK versions
> +and the E-SMI library and kernel version supported by them:
> +
> +.. table:: DPDK and E-SMI library and kernel version compatibility
> +
> +   ==  ==   =
> +   DPDK versionE-SMI versionLinux Kernel version
> +   ==  ==   =
> +24.11+  4.0.06.7+
> +   ==  ==   =

Re: [PATCH v3] dts: remove html dir from nested docs

[Thomas Monjalon]

29/11/2024 00:05, Paul Szczepanek:
> To facilitate deploying docs to the website
> and make paths more consistent remove the html
> directory from docs nested in html directories.
> 
> Signed-off-by: Paul Szczepanek 
> Reviewed-by: Luca Vizzarro 
> ---
>  buildtools/call-sphinx-build.py | 6 --
>  doc/api/meson.build | 2 +-
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/buildtools/call-sphinx-build.py b/buildtools/call-sphinx-build.py
> index 2c7de54285..3e5fc813a2 100755
> --- a/buildtools/call-sphinx-build.py
> +++ b/buildtools/call-sphinx-build.py
> @@ -30,8 +30,10 @@
>  
>  # run sphinx, putting the html output in a "html" directory
>  with open(join(dst, 'sphinx_html.out'), 'w') as out:
> -process = run(sphinx_cmd + ['-b', 'html', src, join(dst, 'html')],
> -  stdout=out)
> +# don't append html dir if dst is already nested in a html dir
> +top_2_dirs = os.path.join(*os.path.normpath(dst).split(os.path.sep)[-2:])
> +html_dst = dst if 'html' in top_2_dirs else join(dst, 'html')
> +process = run(sphinx_cmd + ['-b', 'html', src, html_dst], stdout=out)

There is still a file in the extra html directory:

build/doc/api/html/dts/html/_static/css/custom.css

I suppose that we need to change this line:

dst_css = join(dst, 'html', '_static', 'css', css)

into

dst_css = join(html_dst, '_static', 'css', css)

Then it should become this path:

build/doc/api/html/dts/_static/css/custom.css

Re: When the trace buffers are saved to disk?

[Thomas Monjalon]

28/11/2024 20:17, Adel Belkhiri:
> Hi all,
> 
> Recently, while tracing applications from the apps and examples
> directories, I became confused about when the trace buffer is written to
> disk. Is the trace data saved only when rte_save_trace() is called, or does

It is rte_trace_save()

> it also automatically save when the buffer becomes full?

No, DPDK is not doing such thing without user agreement.

> From my understanding, rte_save_trace() is invoked when the application
> executes rte_eal_cleanup(). Does this mean the target application needs to
> explicitly support tracing by calling rte_save_trace()—perhaps at regular
> intervals—to dump the trace buffer to disk? Otherwise, will we only get a
> fragment of the trace saved during rte_eal_cleanup() execution?

Yes you get it right.

> Thank you for clarifying this point.

Thanks for asking.

If you think the doc below is not clear enough,
do not hesitate to submit a patch to make the doc better:

https://doc.dpdk.org/guides/prog_guide/trace_lib.html

[PATCH v4] dts: remove nested html dir for API doc

[Thomas Monjalon]

From: Paul Szczepanek 

To facilitate deploying docs to the website
and make paths more consistent remove the html
directory from docs nested in API html directory.

Signed-off-by: Paul Szczepanek 
Reviewed-by: Luca Vizzarro 
Signed-off-by: Thomas Monjalon 
---
v4: fix custom.css path and reword a little
---
 buildtools/call-sphinx-build.py | 8 +---
 doc/api/meson.build | 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/buildtools/call-sphinx-build.py b/buildtools/call-sphinx-build.py
index 2c7de54285..c891f68ae4 100755
--- a/buildtools/call-sphinx-build.py
+++ b/buildtools/call-sphinx-build.py
@@ -30,8 +30,10 @@
 
 # run sphinx, putting the html output in a "html" directory
 with open(join(dst, 'sphinx_html.out'), 'w') as out:
-process = run(sphinx_cmd + ['-b', 'html', src, join(dst, 'html')],
-  stdout=out)
+# don't append html dir if dst is already nested in a html dir
+last_two_dirs = 
os.path.join(*os.path.normpath(dst).split(os.path.sep)[-2:])
+html_dst = dst if 'html' in last_two_dirs else join(dst, 'html')
+process = run(sphinx_cmd + ['-b', 'html', src, html_dst], stdout=out)
 
 # create a gcc format .d file giving all the dependencies of this doc build
 with open(join(dst, '.html.d'), 'w') as d:
@@ -40,7 +42,7 @@
 # copy custom CSS file
 css = 'custom.css'
 src_css = join(src, css)
-dst_css = join(dst, 'html', '_static', 'css', css)
+dst_css = join(html_dst, '_static', 'css', css)
 if not os.path.exists(dst_css) or not filecmp.cmp(src_css, dst_css):
 os.makedirs(os.path.dirname(dst_css), exist_ok=True)
 shutil.copyfile(src_css, dst_css)
diff --git a/doc/api/meson.build b/doc/api/meson.build
index f9f1326bbd..ac6eb8236d 100644
--- a/doc/api/meson.build
+++ b/doc/api/meson.build
@@ -37,7 +37,7 @@ cdata.set('OUTPUT', join_paths(dpdk_build_root, 'doc', 'api'))
 cdata.set('TOPDIR', dpdk_source_root)
 cdata.set('STRIP_FROM_PATH', ' '.join([dpdk_source_root, 
join_paths(dpdk_build_root, 'doc', 'api')]))
 cdata.set('WARN_AS_ERROR', 'NO')
-cdata.set('DTS_API_MAIN_PAGE', join_paths('.', 'dts', 'html', 'index.html'))
+cdata.set('DTS_API_MAIN_PAGE', join_paths('.', 'dts', 'index.html'))
 if get_option('werror')
 cdata.set('WARN_AS_ERROR', 'YES')
 endif
-- 
2.47.1

Re: [PATCH v4] dts: remove nested html dir for API doc

[Paul Szczepanek]

On 29/11/2024 11:54, Thomas Monjalon wrote:
> From: Paul Szczepanek 
> 
> To facilitate deploying docs to the website
> and make paths more consistent remove the html
> directory from docs nested in API html directory.
> 
> Signed-off-by: Paul Szczepanek 
> Reviewed-by: Luca Vizzarro 
> Signed-off-by: Thomas Monjalon 
> ---

Makes sense to remove the html from the css, thanks.

Won't the scripts complain about the order of tags? Signed off should
come before reviewed.

Reviewed-by: Paul Szczepanek 

Re: [PATCH v4] dts: remove nested html dir for API doc

[Thomas Monjalon]

29/11/2024 13:15, Paul Szczepanek:
> 
> On 29/11/2024 11:54, Thomas Monjalon wrote:
> > From: Paul Szczepanek 
> > 
> > To facilitate deploying docs to the website
> > and make paths more consistent remove the html
> > directory from docs nested in API html directory.
> > 
> > Signed-off-by: Paul Szczepanek 
> > Reviewed-by: Luca Vizzarro 
> > Signed-off-by: Thomas Monjalon 
> > ---
> 
> Makes sense to remove the html from the css, thanks.
> 
> Won't the scripts complain about the order of tags? Signed off should
> come before reviewed.

Scripts are emitting warnings, and sometimes we can do differently :)

Here I prefer adding my Signoff at the end to show I did only last minute 
change.

Re: [PATCH v1 1/1] usertools/devbind: fix missing active marker

[David Marchand]

On Fri, Nov 29, 2024 at 9:05 AM Robin Jarry  wrote:
> Anatoly Burakov, Nov 27, 2024 at 16:42:
> > When adding NUMA node printouts, the "*Active*" marker was accidentally
> > omitted. Add it back in.
> >
> > Fixes: a7d69cef8f20 ("usertools/devbind: print device NUMA node")
> >
> > Signed-off-by: Anatoly Burakov 
> Acked-by: Robin Jarry 

Applied, thanks.

-- 
David Marchand

Re: [PATCH v1 1/1] usertools/devbind: fix NUMA node display

[David Marchand]

On Fri, Nov 29, 2024 at 10:52 AM Anatoly Burakov
 wrote:
>
> On some systems (particularly ones with NUMA disabled in BIOS), even
> though NUMA nodes may be present in sysfs, the lspci command will not
> have NUMANode keys in them, which will cause an exception. Fix to check
> if NUMANode keys are available in lspci output before enabling NUMA node
> output.
>
> Fixes: a7d69cef8f20 ("usertools/devbind: print device NUMA node")
>
> Signed-off-by: Anatoly Burakov 
Acked-by: Robin Jarry 

Applied, thanks.


-- 
David Marchand

Re: [PATCH v3 1/1] usertools/devbind: allow changing UID/GID for VFIO

[Thomas Monjalon]

27/11/2024 10:13, Anatoly Burakov:
> Currently, when binding a device to VFIO, the UID/GID for the device will
> always stay as system default (`root`). Yet, when running DPDK as non-root
> user, one has to change the UID/GID of the device to match the user's
> UID/GID to use the device.
> 
> This patch adds an option to `dpdk-devbind.py` to change the UID/GID of
> the device when binding it to VFIO.
> 
> Signed-off-by: Anatoly Burakov 
> ---
> 
> Notes:
> v2 -> v3:
> - Replaced error printout back to hard exit
> - Reworked UID/GID validation to be at command line parsing
> - Simplified chown code
> 
> v1 -> v2:
> - Replaced hard exit with an error printout
> 
>  usertools/dpdk-devbind.py | 41 ---

Please could you update the documentation?
doc/guides/tools/devbind.rst

Re: [PATCH v2] doc/multi-process: fix grammar and phrasing

[Thomas Monjalon]

05/10/2024 00:10, Stephen Hemminger:
> Simplify awkward wording in description of the multi process
> application.
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  doc/guides/sample_app_ug/multi_process.rst | 168 -
>  1 file changed, 61 insertions(+), 107 deletions(-)

Applied with a bit more changed line splits, thanks.

[PATCH dpdk] log: fix double free on cleanup

[Robin Jarry]

Fix the following crash when closing a log file after rte_eal_cleanup():

double free or corruption (!prev)

Thread 1 "grout" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
...
#10 _IO_new_fclose (fp=0xb63090) at iofclose.c:74
#11 0x0049c04e in dpdk_fini () at ../main/dpdk.c:204
#12 0x00402ab8 in main (...) at ../main/main.c:217
(gdb) up 11
#11 0x0049c04e in dpdk_fini () at ../main/dpdk.c:204
202 rte_eal_cleanup();
203 if (log_stream != NULL)
204 fclose(log_stream);

When the application has passed a custom file via rte_openlog_stream()
DPDK should not call fclose() on it.

Add an internal is_internal_file field to track whether the file has
been allocated by DPDK (syslog or journald) to determine if it should be
closed or not.

Fixes: 985130369be3 ("log: rework syslog handling")
Signed-off-by: Robin Jarry 
---
 lib/log/log.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/log/log.c b/lib/log/log.c
index eb087d601e8b..e1c18a8e5351 100644
--- a/lib/log/log.c
+++ b/lib/log/log.c
@@ -38,6 +38,7 @@ static struct rte_logs {
uint32_t type;  /**< Bitfield with enabled logs. */
uint32_t level; /**< Log level. */
FILE *file; /**< Output file set by rte_openlog_stream, or NULL. */
+   bool is_internal_file;
log_print_t print_func;
size_t dynamic_types_len;
struct rte_log_dynamic_type *dynamic_types;
@@ -80,8 +81,11 @@ static RTE_DEFINE_PER_LCORE(struct log_cur_msg, log_cur_msg);
 int
 rte_openlog_stream(FILE *f)
 {
+   if (rte_logs.is_internal_file && rte_logs.file != NULL)
+   fclose(rte_logs.file);
rte_logs.file = f;
rte_logs.print_func = vfprintf;
+   rte_logs.is_internal_file = false;
return 0;
 }
 
@@ -520,6 +524,7 @@ eal_log_init(const char *id)
/* if either syslog or journal is used, then no special 
handling */
if (logf) {
rte_openlog_stream(logf);
+   rte_logs.is_internal_file = true;
} else {
bool is_terminal = isatty(fileno(stderr));
bool use_color = log_color_enabled(is_terminal);
@@ -550,11 +555,8 @@ eal_log_init(const char *id)
 void
 rte_eal_log_cleanup(void)
 {
-   FILE *log_stream = rte_logs.file;
-
-   /* don't close stderr on the application */
-   if (log_stream != NULL)
-   fclose(log_stream);
-
+   if (rte_logs.is_internal_file && rte_logs.file != NULL)
+   fclose(rte_logs.file);
rte_logs.file = NULL;
+   rte_logs.is_internal_file = false;
 }
-- 
2.47.1

Re: [PATCH] power/amd_uncore: add e-smi installation instructions

[Stephen Hemminger]

On Fri, 29 Nov 2024 04:32:07 +
Sivaprasad Tummala  wrote:

> Added section for installing and building the E-SMI library
> for AMD EPYC Uncore support and version requirements.
> 
> Signed-off-by: Sivaprasad Tummala 
> ---
>  doc/guides/prog_guide/power_man.rst | 32 +
>  1 file changed, 32 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/power_man.rst 
> b/doc/guides/prog_guide/power_man.rst
> index 74039e5786..d367a81596 100644
> --- a/doc/guides/prog_guide/power_man.rst
> +++ b/doc/guides/prog_guide/power_man.rst
> @@ -249,6 +249,38 @@ Additionally, the EPYC System Management Interface 
> In-band Library for Linux
>  offers essential API, enabling user-space software
>  to effectively manage system functions.
>  
> +E-SMI Installation
> +--
> +
> +To build DPDK with AMD EPYC Uncore the user is required to download the e-smi
> +library from `here `_
> +and compile it on their user system before building DPDK.
> +
> +.. code-block:: console
> +
> +cd esmi_ib_library
> +cmake .
> +sudo make install
> +cp /opt/e-sms/e_smi/lib/* /usr/local/lib/*
> +cp /opt/e-sms/e_smi/include/* /usr/local/include/*
> +
> +Library file, header and tool are installed at /opt/e-sms.

The DPDK should always recommend users use the packages provided by
their distro. This project should work with distros to package this like any
other library.

Build instructions belong in the project, not in DPDK. The project will
change its build instructions and DPDK will get out of date.

> +
> +Note: Library is dependent on amd_hsmp.h header and without this, 
> compilation will break.
> +
> +The library requires CMake (v3.5.0) to be built.
> +
> +As a reference, the following table shows a mapping between the DPDK versions
> +and the E-SMI library and kernel version supported by them:
> +
> +.. table:: DPDK and E-SMI library and kernel version compatibility
> +
> +   ==  ==   =
> +   DPDK versionE-SMI versionLinux Kernel version
> +   ==  ==   =
> +24.11+  4.0.06.7+
> +   ==  ==   =

The library needs to have stable API's and work in any kernel that supports
the system calls it uses. But that is for it to learn.

DPDK should just say (in the programmer's guide) to use E-SMI 4.0 or later.

Re: [PATCH dpdk] log: fix double free on cleanup

[Stephen Hemminger]

On Fri, 29 Nov 2024 17:10:14 +0100
Robin Jarry  wrote:

> @@ -550,11 +555,8 @@ eal_log_init(const char *id)
>  void
>  rte_eal_log_cleanup(void)
>  {
> - FILE *log_stream = rte_logs.file;
> -
> - /* don't close stderr on the application */
> - if (log_stream != NULL)
> - fclose(log_stream);
> -
> + if (rte_logs.is_internal_file && rte_logs.file != NULL)
> + fclose(rte_logs.file);
>   rte_logs.file = NULL;
> + rte_logs.is_internal_file = false;
>  }

The internal flag is ok, but we still don't want to close
stderr in cleanup. Only places where syslog or journal wrapper is used.

Re: [PATCH dpdk] log: fix double free on cleanup

[Stephen Hemminger]

On Fri, 29 Nov 2024 17:10:14 +0100
Robin Jarry  wrote:

> Fix the following crash when closing a log file after rte_eal_cleanup():
> 
> double free or corruption (!prev)
> 
> Thread 1 "grout" received signal SIGABRT, Aborted.
> __pthread_kill_implementation (threadid=,
> signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
> ...
> #10 _IO_new_fclose (fp=0xb63090) at iofclose.c:74
> #11 0x0049c04e in dpdk_fini () at ../main/dpdk.c:204
> #12 0x00402ab8 in main (...) at ../main/main.c:217
> (gdb) up 11
> #11 0x0049c04e in dpdk_fini () at ../main/dpdk.c:204
> 202 rte_eal_cleanup();
> 203 if (log_stream != NULL)
> 204 fclose(log_stream);
> 
> When the application has passed a custom file via rte_openlog_stream()
> DPDK should not call fclose() on it.
> 
> Add an internal is_internal_file field to track whether the file has
> been allocated by DPDK (syslog or journald) to determine if it should be
> closed or not.
> 
> Fixes: 985130369be3 ("log: rework syslog handling")
> Signed-off-by: Robin Jarry 

Looks good, will look into adding more test cases for this in later release.

Reviewed-by: Stephen Hemminger 

Re: [PATCH v3] doc: reword sample app guides

[Thomas Monjalon]

14/10/2024 19:03, Nandini Persad:
> I have reviewed these sections for grammar/clarity
> and made small modifications to the formatting of sections
> to adhere to a template which will create uniformality
> in the sample application user guides overall.
> 
> Signed-off-by: Nandini Persad 
> Acked-by: Chengwen Feng 

Applied with few improvements in links and code formatting, thanks.

[PATCH] crypto/openssl: fix CMAC auth context update

[Wathsala Vithanage]

This patch removes an unnecessary cleanup of the shared CMAC context at
the end of the CMAC authentication function, which causes subsequent
calls to it to fail.

Fixes: 17d5bc6135af ("crypto/openssl: make per-QP auth context clones")
Cc: sta...@dpdk.org

Signed-off-by: Wathsala Vithanage 
Reviewed-by: Jack Bond-Preston 

---
 drivers/crypto/openssl/rte_openssl_pmd.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c 
b/drivers/crypto/openssl/rte_openssl_pmd.c
index d2cf20c059..b090611bd0 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -1595,9 +1595,6 @@ process_openssl_auth_cmac(struct rte_mbuf *mbuf_src, 
uint8_t *dst, int offset,
 process_auth_final:
if (CMAC_Final(ctx, dst, (size_t *)&dstlen) != 1)
goto process_auth_err;
-
-   CMAC_CTX_cleanup(ctx);
-
return 0;

 process_auth_err:
--
2.43.0

[PATCH v2] net/mlx5: fix RSS hash for non-RSS CQE zipping

[Alexander Kozyrev]

Take the RSS hash and flow tag values from the title packet
before they get overwritten by the decompressing routine.
Set the RSS hash flag in the packet mbuf if RSS is enabled
in case of non-RSS CQE zipping format.

Signed-off-by: Alexander Kozyrev 
---
 drivers/net/mlx5/mlx5_rxtx_vec_altivec.h | 23 +--
 drivers/net/mlx5/mlx5_rxtx_vec_neon.h| 15 ---
 drivers/net/mlx5/mlx5_rxtx_vec_sse.h | 15 ---
 3 files changed, 29 insertions(+), 24 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx_vec_altivec.h 
b/drivers/net/mlx5/mlx5_rxtx_vec_altivec.h
index 240987d03d..3b2f33d138 100644
--- a/drivers/net/mlx5/mlx5_rxtx_vec_altivec.h
+++ b/drivers/net/mlx5/mlx5_rxtx_vec_altivec.h
@@ -82,6 +82,8 @@ rxq_cq_decompress_v(struct mlx5_rxq_data *rxq, volatile 
struct mlx5_cqe *cq,
(void *)&(cq + !rxq->cqe_comp_layout)->pkt_info;
/* Title packet is pre-built. */
struct rte_mbuf *t_pkt = rxq->cqe_comp_layout ? &rxq->title_pkt : 
elts[0];
+   const uint32_t hash_rss = t_pkt->hash.rss * rxq->rss_hash;
+   const uint32_t flow_tag = t_pkt->hash.fdir.hi;
const __vector unsigned char zero = (__vector unsigned char){0};
/* Mask to shuffle from extracted mini CQE to mbuf. */
const __vector unsigned char shuf_mask1 = (__vector unsigned char){
@@ -266,8 +268,6 @@ rxq_cq_decompress_v(struct mlx5_rxq_data *rxq, volatile 
struct mlx5_cqe *cq,
if (rxq->mark) {
if (rxq->mcqe_format !=
MLX5_CQE_RESP_FORMAT_FTAG_STRIDX) {
-   const uint32_t flow_tag = t_pkt->hash.fdir.hi;
-
/* E.1 store flow tag (rte_flow mark). */
elts[pos]->hash.fdir.hi = flow_tag;
elts[pos + 1]->hash.fdir.hi = flow_tag;
@@ -442,10 +442,10 @@ rxq_cq_decompress_v(struct mlx5_rxq_data *rxq, volatile 
struct mlx5_cqe *cq,
}
const __vector unsigned char hash_mask =
(__vector unsigned char)(__vector unsigned int) 
{
-   RTE_MBUF_F_RX_RSS_HASH,
-   RTE_MBUF_F_RX_RSS_HASH,
-   RTE_MBUF_F_RX_RSS_HASH,
-   RTE_MBUF_F_RX_RSS_HASH};
+   rxq->rss_hash * RTE_MBUF_F_RX_RSS_HASH,
+   rxq->rss_hash * RTE_MBUF_F_RX_RSS_HASH,
+   rxq->rss_hash * RTE_MBUF_F_RX_RSS_HASH,
+   rxq->rss_hash * RTE_MBUF_F_RX_RSS_HASH};
const __vector unsigned char rearm_flags =
(__vector unsigned char)(__vector unsigned int) 
{
(uint32_t)t_pkt->ol_flags,
@@ -456,6 +456,9 @@ rxq_cq_decompress_v(struct mlx5_rxq_data *rxq, volatile 
struct mlx5_cqe *cq,
ol_flags_mask = (__vector unsigned char)
vec_or((__vector unsigned long)ol_flags_mask,
(__vector unsigned long)hash_mask);
+   ol_flags = (__vector unsigned char)
+   vec_or((__vector unsigned long)ol_flags,
+   (__vector unsigned long)hash_mask);
ol_flags = (__vector unsigned char)
vec_or((__vector unsigned long)ol_flags,
(__vector unsigned long)
@@ -470,10 +473,10 @@ rxq_cq_decompress_v(struct mlx5_rxq_data *rxq, volatile 
struct mlx5_cqe *cq,
((__vector unsigned int)ol_flags)[2];
elts[pos + 3]->ol_flags =
((__vector unsigned int)ol_flags)[3];
-   elts[pos]->hash.rss = 0;
-   elts[pos + 1]->hash.rss = 0;
-   elts[pos + 2]->hash.rss = 0;
-   elts[pos + 3]->hash.rss = 0;
+   elts[pos]->hash.rss = hash_rss;
+   elts[pos + 1]->hash.rss = hash_rss;
+   elts[pos + 2]->hash.rss = hash_rss;
+   elts[pos + 3]->hash.rss = hash_rss;
}
if (rxq->dynf_meta) {
int32_t offs = rxq->flow_meta_offset;
diff --git a/drivers/net/mlx5/mlx5_rxtx_vec_neon.h 
b/drivers/net/mlx5/mlx5_rxtx_vec_neon.h
index dc1d30753d..58e3918ef4 100644
--- a/drivers/net/mlx5/mlx5_rxtx_vec_neon.h
+++ b/drivers/net/mlx5/mlx5_rxtx_vec_neon.h
@@ -78,6 +78,8 @@ rxq_cq_decompress_v(struct mlx5_rxq_data *rxq, volatile 
struct mlx5_cqe *cq,
(void *)&(cq + !rxq->cqe_comp_layout)->pkt_info;
/* Title packet is pre-built. */
struct rte_mbuf *t_pkt = rxq->cqe_comp_layout ? &rxq->title_pkt : 
el

Re: [PATCH] doc: reword sample app guides

[Thomas Monjalon]

22/10/2024 01:42, Nandini Persad:
> I revised these sections mostly for grammar and clarity.
> 
> Signed-off-by: Nandini Persad 

Applied with few improvements in links and code formatting, thanks.

Re: When the trace buffers are saved to disk?

[Adel Belkhiri]

Thank you for the clarification, Thomas. Indeed, the documentation for the
trace library is kind of limited. If you don't mind, I have another
question: Would it be useful to have an API to register a callback (to save
trace data) when the buffer is full?

On Fri, Nov 29, 2024 at 6:44 AM Thomas Monjalon  wrote:

> 28/11/2024 20:17, Adel Belkhiri:
> > Hi all,
> >
> > Recently, while tracing applications from the apps and examples
> > directories, I became confused about when the trace buffer is written to
> > disk. Is the trace data saved only when rte_save_trace() is called, or
> does
>
> It is rte_trace_save()
>
> > it also automatically save when the buffer becomes full?
>
> No, DPDK is not doing such thing without user agreement.
>
> > From my understanding, rte_save_trace() is invoked when the application
> > executes rte_eal_cleanup(). Does this mean the target application needs
> to
> > explicitly support tracing by calling rte_save_trace()—perhaps at regular
> > intervals—to dump the trace buffer to disk? Otherwise, will we only get a
> > fragment of the trace saved during rte_eal_cleanup() execution?
>
> Yes you get it right.
>
> > Thank you for clarifying this point.
>
> Thanks for asking.
>
> If you think the doc below is not clear enough,
> do not hesitate to submit a patch to make the doc better:
>
> https://doc.dpdk.org/guides/prog_guide/trace_lib.html
>
>
>
>

[PATCH v3 1/2] config/arm: strict use of -mcpu for supported CPUs

[Wathsala Vithanage]

Arm recommends using -mcpu over -march and march-extensions when the
compiler supports the target CPU (neoverse-n1 etc.). Arm build so far
has been an amalgam of -mcpu and -march. When march is in use, it has
been the case so far to silently fall back to a downgraded march when
the compiler does not support the requested march. This is unnecessary
and confusing to an end user who could be building DPDK with a
particular ISA version and performance expectations in mind.

This patch aims to rectify both the above issues. For part numbers that
has a corresponding -mcpu, this patch removes all references to march
and march_features from meson.build. For those SOCs that do not have a
corresponding -mcpu, a pseudo cpu name in the format mcpu_ is
introduced and referenced in the mcpu field in the part number
dictionary of the part_number_config dictionary. The definition of the
mcpu_ must be provided in the mcpu_defs dictionary.
Each mcpu_ dictionary in the mcpu_defs have a march field and
a march_extensions field to construct the optimal compiler setting for
an SOC that has no corresponding -mcpu value. This patch alters the
behavior of the build system such that it will no longer silently fall
back to an older ISA version, it will only perform what's specified in
the build dictionaries, if the compiler does not support the specified
configuration it will fail with an error message.

How to add a new SOC to the build system with these changes?
If compiler supports mcpu follow the usual practice but without march
and march_features fields in the part number dictionary. If mcpu is not
available or buggy (misses certain features) for some reason follow the
same process but set mcpu field to a string in the form 'mcpu_foo'
(pseudo mcpu mentioned earlier). Then in the mcpu_defs dictionary add
mcpu_foo dictionary as shown.

'mcpu_foo': {
   'march': 'armv8.2-a',
   'march_extensions': [rcpc]
}

march_extensions is a comma separated list of march extensions supported
by the compiler such as sve, crypto etc. Empty match_extensions allowed
as use of such extensions are optional.

Signed-off-by: Wathsala Vithanage 
Reviewed-by: Dhruv Tripathi 

---
 config/arm/meson.build | 193 +
 1 file changed, 80 insertions(+), 113 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 55be7c8711..9ed36d9907 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -39,14 +39,11 @@ implementer_generic = {
 ],
 'part_number_config': {
 'generic': {
-'march': 'armv8-a',
-'march_features': ['crc'],
+'mcpu': 'mcpu_generic',
 'compiler_options': ['-moutline-atomics']
 },
 'generic_aarch32': {
-'march': 'armv8-a',
-'force_march': true,
-'march_features': ['simd'],
+'mcpu': 'mcpu_generic_aarch32',
 'compiler_options': ['-mfpu=auto'],
 'flags': [
 ['RTE_ARCH_ARM_NEON_MEMCPY', false],
@@ -69,8 +66,6 @@ part_number_config_arm = {
 '0xd0a': {'mcpu': 'cortex-a75'},
 '0xd0b': {'mcpu': 'cortex-a76'},
 '0xd0c': {
-'march': 'armv8.2-a',
-'march_features': ['crypto', 'rcpc'],
 'mcpu': 'neoverse-n1',
 'flags': [
 ['RTE_MACHINE', '"neoverse-n1"'],
@@ -81,8 +76,6 @@ part_number_config_arm = {
 ]
 },
 '0xd40': {
-'march': 'armv8.4-a',
-'march_features': ['sve'],
 'mcpu': 'neoverse-v1',
 'flags': [
 ['RTE_MACHINE', '"neoverse-v1"'],
@@ -94,9 +87,6 @@ part_number_config_arm = {
 'march': 'armv8.4-a',
 },
 '0xd49': {
-'march': 'armv9-a',
-'march_features': ['sve2'],
-'fallback_march': 'armv8.5-a',
 'mcpu': 'neoverse-n2',
 'flags': [
 ['RTE_MACHINE', '"neoverse-n2"'],
@@ -106,10 +96,7 @@ part_number_config_arm = {
 ]
 },
 '0xd4f': {
-'march': 'armv9-a',
-'march_features': ['sve2'],
 'mcpu' : 'neoverse-v2',
-'fallback_march': 'armv8.5-a',
 'flags': [
 ['RTE_MACHINE', '"neoverse-v2"'],
 ['RTE_ARM_FEATURE_ATOMICS', true],
@@ -171,15 +158,11 @@ implementer_cavium = {
 'flags': flags_part_number_thunderx
 },
 '0xa3': {
-'march': 'armv8-a',
-'march_features': ['crc', 'crypto'],
-'mcpu': 'thunderxt83',
+'mcpu': 'mcpu_thunderxt83',
 'flags': flags_part_number_thunderx
 },
 '0xaf': {
-'march': 'armv8.1-a',
-'march_features': ['crc', 'crypto'],
-'mcpu': 'thunderx2t99',
+'mcpu': 'mcpu_thunderx2t99',
 'flags': [
 ['RTE_MACHINE', '"thunderx2"'],
 ['RTE_ARM_FEATURE_ATOMICS', true],
@@ -189,8 +172,6 @@ implementer_cavium = {
 ]
 },
 '0xb2': {
-'

[PATCH v3 2/2] config/arm: sort SOCs alphabetically

[Wathsala Vithanage]

Order SOC configurations and names alphabetically.

Signed-off-by: Wathsala Vithanage 
Reviewed-by: Dhruv Tripathi 

---
 config/arm/meson.build | 86 +-
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 9ed36d9907..7f6a0e1b16 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -394,6 +394,17 @@ soc_bluefield = {
 'numa': false
 }

+soc_bluefield3 = {
+  'description': 'NVIDIA BlueField-3',
+  'implementer': '0x41',
+   'flags': [
+  ['RTE_MAX_LCORE', 32],
+  ['RTE_MAX_NUMA_NODES', 1]
+  ],
+   'part_number': '0xd42',
+   'numa': false
+}
+
 soc_capri = {
 'description': 'AMD Pensando Capri',
 'implementer': '0x75',
@@ -476,13 +487,6 @@ soc_ft2000plus = {
 'numa': true
 }

-soc_tys2500 = {
-'description': 'Phytium TengYun S2500',
-'implementer': '0x70',
-'part_number': '0x663',
-'numa': true
-}
-
 soc_grace = {
 'description': 'NVIDIA Grace',
 'implementer': '0x41',
@@ -593,27 +597,23 @@ soc_thunderx2 = {
 'part_number': '0xaf'
 }

-soc_thunderxt88 = {
-'description': 'Marvell ThunderX T88',
-'implementer': '0x43',
-'part_number': '0xa1'
-}
-
 soc_thunderxt83 = {
 'description': 'Marvell ThunderX T83',
 'implementer': '0x43',
 'part_number': '0xa3'
 }

-soc_bluefield3 = {
-  'description': 'NVIDIA BlueField-3',
-  'implementer': '0x41',
-   'flags': [
-  ['RTE_MAX_LCORE', 32],
-  ['RTE_MAX_NUMA_NODES', 1]
-  ],
-   'part_number': '0xd42',
-   'numa': false
+soc_thunderxt88 = {
+'description': 'Marvell ThunderX T88',
+'implementer': '0x43',
+'part_number': '0xa1'
+}
+
+soc_tys2500 = {
+'description': 'Phytium TengYun S2500',
+'implementer': '0x70',
+'part_number': '0x663',
+'numa': true
 }

 soc_v2 = {
@@ -624,23 +624,31 @@ soc_v2 = {
 }

 mcpu_defs = {
-'mcpu_kunpeng930': {
-'march': 'armv8.2-a',
-'march_extensions': ['crypto', 'sve']
+'mcpu_centriq2400': {
+'march': 'armv8-a',
+'march_extensions': ['crc']
+},
+'mcpu_ft2000plus': {
+'march': 'armv8-a',
+'march_extensions': ['crc']
 },
 'mcpu_hip10': {
 'march': 'armv8.5-a',
 'march_extensions': ['crypto', 'sve']
 },
-'mcpu_ft2000plus': {
-'march': 'armv8-a',
-'march_extensions': ['crc']
+'mcpu_kunpeng930': {
+'march': 'armv8.2-a',
+'march_extensions': ['crypto', 'sve']
 },
-'mcpu_tys2500': {
+'mcpu_thunderxt83': {
 'march': 'armv8-a',
-'march_extensions': ['crc']
+'march_extensions': ['crc', 'crypto']
 },
-'mcpu_centriq2400': {
+'mcpu_thunderx2t99': {
+'march': 'armv8.1-a',
+'march_extensions': ['crc', 'crypto']
+},
+'mcpu_tys2500': {
 'march': 'armv8-a',
 'march_extensions': ['crc']
 },
@@ -652,14 +660,6 @@ mcpu_defs = {
 'march': 'armv8-a',
 'march_extensions': ['simd'],
 }
-'mcpu_thunderx2t99': {
-'march': 'armv8.1-a',
-'march_extensions': ['crc', 'crypto']
-},
-'mcpu_thunderxt83': {
-'march': 'armv8-a',
-'march_extensions': ['crc', 'crypto']
-},
 }

 '''
@@ -681,7 +681,6 @@ dpaa:NXP DPAA
 elba:AMD Pensando Elba
 emag:Ampere eMAG
 ft2000plus:  Phytium FT-2000+
-tys2500: Phytium TengYun S2500
 grace:   NVIDIA Grace
 graviton2:   AWS Graviton2
 graviton3:   AWS Graviton3
@@ -694,8 +693,9 @@ n2:  Arm Neoverse N2
 odyssey: Marvell Odyssey
 stingray:Broadcom Stingray
 thunderx2:   Marvell ThunderX2 T99
-thunderxt88: Marvell ThunderX T88
 thunderxt83: Marvell ThunderX T83
+thunderxt88: Marvell ThunderX T88
+tys2500: Phytium TengYun S2500
 v2:  Arm Neoverse V2
 End of SoCs list
 '''
@@ -719,7 +719,6 @@ socs = {
 'elba': soc_elba,
 'emag': soc_emag,
 'ft2000plus': soc_ft2000plus,
-'tys2500': soc_tys2500,
 'grace': soc_grace,
 'graviton2': soc_graviton2,
 'graviton3': soc_graviton3,
@@ -733,8 +732,9 @@ socs = {
 'odyssey' : soc_odyssey,
 'stingray': soc_stingray,
 'thunderx2': soc_thunderx2,
-'thunderxt88': soc_thunderxt88,
 'thunderxt83': soc_thunderxt83,
+'thunderxt88': soc_thunderxt88,
+'tys2500': soc_tys2500,
 'v2': soc_v2,
 }

--
2.43.0

[PATCH v3] net/mlx5: fix RSS hash for non-RSS CQE zipping

[Alexander Kozyrev]

Take the RSS hash value from the title packet
before it gets overwritten by the decompression routine.
Set the RSS hash flag in the packet mbuf if RSS is enabled
in case of non-RSS CQE zipping format.

Fixes: 54c2d46 ("net/mlx5: support flow tag and packet header miniCQEs")
Cc: sta...@dpdk.org

Signed-off-by: Alexander Kozyrev 
---
 drivers/net/mlx5/mlx5_rxtx_vec_altivec.h | 32 +---
 drivers/net/mlx5/mlx5_rxtx_vec_neon.h| 18 ++---
 drivers/net/mlx5/mlx5_rxtx_vec_sse.h | 18 ++---
 3 files changed, 35 insertions(+), 33 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx_vec_altivec.h 
b/drivers/net/mlx5/mlx5_rxtx_vec_altivec.h
index 240987d03d..0f48298def 100644
--- a/drivers/net/mlx5/mlx5_rxtx_vec_altivec.h
+++ b/drivers/net/mlx5/mlx5_rxtx_vec_altivec.h
@@ -82,6 +82,7 @@ rxq_cq_decompress_v(struct mlx5_rxq_data *rxq, volatile 
struct mlx5_cqe *cq,
(void *)&(cq + !rxq->cqe_comp_layout)->pkt_info;
/* Title packet is pre-built. */
struct rte_mbuf *t_pkt = rxq->cqe_comp_layout ? &rxq->title_pkt : 
elts[0];
+   const uint32_t hash_rss = rxq->rss_hash * t_pkt->hash.rss;
const __vector unsigned char zero = (__vector unsigned char){0};
/* Mask to shuffle from extracted mini CQE to mbuf. */
const __vector unsigned char shuf_mask1 = (__vector unsigned char){
@@ -113,8 +114,18 @@ rxq_cq_decompress_v(struct mlx5_rxq_data *rxq, volatile 
struct mlx5_cqe *cq,
const __vector unsigned short rxdf_sel_mask =
(__vector unsigned short){
0x, 0x, 0, 0, 0, 0x, 0, 0};
-   __vector unsigned char ol_flags = (__vector unsigned char){0};
-   __vector unsigned char ol_flags_mask = (__vector unsigned char){0};
+   __vector unsigned char ol_flags =
+   (__vector unsigned char)(__vector unsigned int) {
+   rxq->rss_hash * RTE_MBUF_F_RX_RSS_HASH,
+   rxq->rss_hash * RTE_MBUF_F_RX_RSS_HASH,
+   rxq->rss_hash * RTE_MBUF_F_RX_RSS_HASH,
+   rxq->rss_hash * RTE_MBUF_F_RX_RSS_HASH};
+   __vector unsigned char ol_flags_mask =
+   (__vector unsigned char)(__vector unsigned int) {
+   rxq->rss_hash * RTE_MBUF_F_RX_RSS_HASH,
+   rxq->rss_hash * RTE_MBUF_F_RX_RSS_HASH,
+   rxq->rss_hash * RTE_MBUF_F_RX_RSS_HASH,
+   rxq->rss_hash * RTE_MBUF_F_RX_RSS_HASH};
unsigned int pos;
unsigned int i;
unsigned int inv = 0;
@@ -440,12 +451,6 @@ rxq_cq_decompress_v(struct mlx5_rxq_data *rxq, volatile 
struct mlx5_cqe *cq,
pkt_info) & (1 << 6));
}
}
-   const __vector unsigned char hash_mask =
-   (__vector unsigned char)(__vector unsigned int) 
{
-   RTE_MBUF_F_RX_RSS_HASH,
-   RTE_MBUF_F_RX_RSS_HASH,
-   RTE_MBUF_F_RX_RSS_HASH,
-   RTE_MBUF_F_RX_RSS_HASH};
const __vector unsigned char rearm_flags =
(__vector unsigned char)(__vector unsigned int) 
{
(uint32_t)t_pkt->ol_flags,
@@ -453,9 +458,6 @@ rxq_cq_decompress_v(struct mlx5_rxq_data *rxq, volatile 
struct mlx5_cqe *cq,
(uint32_t)t_pkt->ol_flags,
(uint32_t)t_pkt->ol_flags};
 
-   ol_flags_mask = (__vector unsigned char)
-   vec_or((__vector unsigned long)ol_flags_mask,
-   (__vector unsigned long)hash_mask);
ol_flags = (__vector unsigned char)
vec_or((__vector unsigned long)ol_flags,
(__vector unsigned long)
@@ -470,10 +472,10 @@ rxq_cq_decompress_v(struct mlx5_rxq_data *rxq, volatile 
struct mlx5_cqe *cq,
((__vector unsigned int)ol_flags)[2];
elts[pos + 3]->ol_flags =
((__vector unsigned int)ol_flags)[3];
-   elts[pos]->hash.rss = 0;
-   elts[pos + 1]->hash.rss = 0;
-   elts[pos + 2]->hash.rss = 0;
-   elts[pos + 3]->hash.rss = 0;
+   elts[pos]->hash.rss = hash_rss;
+   elts[pos + 1]->hash.rss = hash_rss;
+   elts[pos + 2]->hash.rss = hash_rss;
+   elts[pos + 3]->hash.rss = hash_rss;
}
if (rxq->dynf_meta) {
int32_t offs = rxq->flow_meta_offset;
diff --

Re: [PATCH v4] net/hns3: fix Rx packet without CRC data

[huangdengdui]

On 2024/11/30 1:12, Stephen Hemminger wrote:
> On Fri, 29 Nov 2024 09:36:43 +0800
> Jie Hai  wrote:
> 
>>> +
>>> +static inline void
>>> +hns3_recalculate_crc(struct rte_mbuf *m)
>>> +{
>>> +   char *append_data;
>>> +   uint32_t crc;
>>> +
>>> +   crc = rte_net_crc_calc(rte_pktmbuf_mtod(m, void *),
>>> +  m->data_len, RTE_NET_CRC32_ETH);
>>> +
>>> +   /*
>>> +* After CRC is stripped by hardware, pkt_len and data_len do not
>>> +* contain the CRC length. Therefore, after CRC data is appended
>>> +* by PMD again.
>>> +*/
>>> +   append_data = rte_pktmbuf_append(m, RTE_ETHER_CRC_LEN);
>>> +
>>> +   /* CRC data is binary data and does not care about the byte order. */
>>> +   memcpy(append_data, &crc, RTE_ETHER_CRC_LEN);
>>> +}
> 
> As mentioned previously.
> Including CRC in the packet length (pkt_len and data_len) is not the
> current behavior of most drivers. Therefore hns3 should follow the precedent
> of other drivers and put it past the data.

Yes. This patch does not change the original behavior.
In subsequent processing, crc_len is deducted from pkt_len and data_len.

> 
> In the future the KEEP_CRC flag needs more work to be useable. It needs
> documentation and flag in mbuf (similar to hash and checksum) so that 
> application
> can no that it is present and valid.
> 
> Please resend the patch as a bugfix that puts crc after the data.

Re: When the trace buffers are saved to disk?

[Adel Belkhiri]

Thank you for your answer.

On Fri, Nov 29, 2024 at 4:23 PM Thomas Monjalon  wrote:

> 29/11/2024 21:39, Adel Belkhiri:
> > Thank you for the clarification, Thomas. Indeed, the documentation for
> the
> > trace library is kind of limited. If you don't mind, I have another
> > question: Would it be useful to have an API to register a callback (to
> save
> > trace data) when the buffer is full?
>
> I suppose yes, the problem being which thread is running file writing.
>
> I leave it to the maintainers of the trace library.
>
>
> > On Fri, Nov 29, 2024 at 6:44 AM Thomas Monjalon 
> wrote:
> > > 28/11/2024 20:17, Adel Belkhiri:
> > > > Hi all,
> > > >
> > > > Recently, while tracing applications from the apps and examples
> > > > directories, I became confused about when the trace buffer is
> written to
> > > > disk. Is the trace data saved only when rte_save_trace() is called,
> or
> > > does
> > >
> > > It is rte_trace_save()
> > >
> > > > it also automatically save when the buffer becomes full?
> > >
> > > No, DPDK is not doing such thing without user agreement.
> > >
> > > > From my understanding, rte_save_trace() is invoked when the
> application
> > > > executes rte_eal_cleanup(). Does this mean the target application
> needs
> > > to
> > > > explicitly support tracing by calling rte_save_trace()—perhaps at
> regular
> > > > intervals—to dump the trace buffer to disk? Otherwise, will we only
> get a
> > > > fragment of the trace saved during rte_eal_cleanup() execution?
> > >
> > > Yes you get it right.
> > >
> > > > Thank you for clarifying this point.
> > >
> > > Thanks for asking.
> > >
> > > If you think the doc below is not clear enough,
> > > do not hesitate to submit a patch to make the doc better:
> > >
> > > https://doc.dpdk.org/guides/prog_guide/trace_lib.html
>
>
>
>

Re: When the trace buffers are saved to disk?

[Thomas Monjalon]

29/11/2024 21:39, Adel Belkhiri:
> Thank you for the clarification, Thomas. Indeed, the documentation for the
> trace library is kind of limited. If you don't mind, I have another
> question: Would it be useful to have an API to register a callback (to save
> trace data) when the buffer is full?

I suppose yes, the problem being which thread is running file writing.

I leave it to the maintainers of the trace library.


> On Fri, Nov 29, 2024 at 6:44 AM Thomas Monjalon  wrote:
> > 28/11/2024 20:17, Adel Belkhiri:
> > > Hi all,
> > >
> > > Recently, while tracing applications from the apps and examples
> > > directories, I became confused about when the trace buffer is written to
> > > disk. Is the trace data saved only when rte_save_trace() is called, or
> > does
> >
> > It is rte_trace_save()
> >
> > > it also automatically save when the buffer becomes full?
> >
> > No, DPDK is not doing such thing without user agreement.
> >
> > > From my understanding, rte_save_trace() is invoked when the application
> > > executes rte_eal_cleanup(). Does this mean the target application needs
> > to
> > > explicitly support tracing by calling rte_save_trace()—perhaps at regular
> > > intervals—to dump the trace buffer to disk? Otherwise, will we only get a
> > > fragment of the trace saved during rte_eal_cleanup() execution?
> >
> > Yes you get it right.
> >
> > > Thank you for clarifying this point.
> >
> > Thanks for asking.
> >
> > If you think the doc below is not clear enough,
> > do not hesitate to submit a patch to make the doc better:
> >
> > https://doc.dpdk.org/guides/prog_guide/trace_lib.html