[PATCH v2] net/cpfl: fix cpfl parser issue

[Praveen Shetty]

CPFL parser was incorrectly parsing the mask value of the
next_proto_id field from recipe.json file as a string
instead of unsigned integer.

Fixes: 41f20298ee8c ("net/cpfl: parse flow offloading hint from JSON")
Cc: sta...@dpdk.org

Signed-off-by: Praveen Shetty 

---
v2:
* Fixed CI issues.
---
 drivers/net/cpfl/cpfl_flow_parser.c | 34 +++--
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/drivers/net/cpfl/cpfl_flow_parser.c 
b/drivers/net/cpfl/cpfl_flow_parser.c
index 40569ddc6f..7800ad97ea 100644
--- a/drivers/net/cpfl/cpfl_flow_parser.c
+++ b/drivers/net/cpfl/cpfl_flow_parser.c
@@ -198,6 +198,8 @@ cpfl_flow_js_pattern_key_proto_field(json_t *ob_fields,
for (i = 0; i < len; i++) {
json_t *object;
const char *name, *mask;
+   uint32_t mask_32b = 0;
+   int ret;
 
object = json_array_get(ob_fields, i);
name = cpfl_json_t_to_string(object, "name");
@@ -213,20 +215,28 @@ cpfl_flow_js_pattern_key_proto_field(json_t *ob_fields,
 
if (js_field->type == RTE_FLOW_ITEM_TYPE_ETH ||
js_field->type == RTE_FLOW_ITEM_TYPE_IPV4) {
-   mask = cpfl_json_t_to_string(object, "mask");
-   if (!mask) {
-   PMD_DRV_LOG(ERR, "Can not parse string 
'mask'.");
-   goto err;
-   }
-   if (strlen(mask) > CPFL_JS_STR_SIZE - 1) {
-   PMD_DRV_LOG(ERR, "The 'mask' is too long.");
-   goto err;
+   /* Added a check for parsing mask value of the 
next_proto_id field. */
+   if (strcmp(name, "next_proto_id") == 0) {
+   ret = cpfl_json_t_to_uint32(object, "mask", 
&mask_32b);
+   if (ret < 0) {
+   PMD_DRV_LOG(ERR, "Cannot parse uint32 
'mask'.");
+   goto err;
+   }
+   js_field->fields[i].mask_32b = mask_32b;
+   } else {
+   mask = cpfl_json_t_to_string(object, "mask");
+   if (!mask) {
+   PMD_DRV_LOG(ERR, "Can not parse string 
'mask'.");
+   goto err;
+   }
+   if (strlen(mask) > CPFL_JS_STR_SIZE - 1) {
+   PMD_DRV_LOG(ERR, "The 'mask' is too 
long.");
+   goto err;
+   }
+   rte_strscpy(js_field->fields[i].mask, mask, 
CPFL_JS_STR_SIZE - 1);
}
-   strncpy(js_field->fields[i].mask, mask, 
CPFL_JS_STR_SIZE - 1);
-   } else {
-   uint32_t mask_32b;
-   int ret;
 
+   } else {
ret = cpfl_json_t_to_uint32(object, "mask", &mask_32b);
if (ret < 0) {
PMD_DRV_LOG(ERR, "Can not parse uint32 
'mask'.");
-- 
2.34.1

Re: [PATCH v2 2/2] doc: remove use of -n 4 option in documentation

[Thomas Monjalon]

31/07/2024 06:38, Stephen Hemminger:
> --- a/doc/guides/linux_gsg/build_sample_apps.rst
> +++ b/doc/guides/linux_gsg/build_sample_apps.rst
> @@ -114,7 +114,7 @@ Copy the DPDK application binary to your target, then run 
> the application as fol
>  (assuming the platform has four memory channels per processor socket,
>  and that cores 0-3 are present and are to be used for running the 
> application)::
>  
> -./dpdk-helloworld -l 0-3 -n 4
> +./dpdk-helloworld -l 0-3
> 

There were some comments from Jack about updating the sentences above in 
several locations
to skip the memory channels considerations.

[PATCH v2 0/2] custom doc styling

[Thomas Monjalon]

The file custom.css allows to change the theme from "Read the Docs".
The first patch makes it available without "ninja install".
The second patch allows the NIC overview tables to be "fullscreen".

Thomas Monjalon (2):
  doc: copy custom CSS on guides build
  doc: give full width to NIC overview page

 buildtools/call-sphinx-build.py | 10 ++
 doc/guides/custom.css   |  8 
 doc/guides/meson.build  |  2 --
 doc/guides/nics/overview.rst|  2 ++
 4 files changed, 20 insertions(+), 2 deletions(-)

-- 
2.45.0

[PATCH v2 1/2] doc: copy custom CSS on guides build

[Thomas Monjalon]

The custom CSS file for Sphinx guides was copied during install,
but not during build time.
Before switching to Meson, the Makefile was copying this file
in the build steps, so the doc was complete and viewable
from the build directory.

It is especially useful to get full documentation in the build directory
when building only documentation with "ninja -C build doc".
The command "ninja install" was required to get the CSS file installed,
but it requires to build the libraries as well.

The CSS file is now copied as part of the Sphinx build script,
and it will be installed as part of the whole html directory.

Signed-off-by: Thomas Monjalon 
---
v2: create destination directory in case RtD theme is unavailable
---
 buildtools/call-sphinx-build.py | 10 ++
 doc/guides/meson.build  |  2 --
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/buildtools/call-sphinx-build.py b/buildtools/call-sphinx-build.py
index da19e950c9..623e7363ee 100755
--- a/buildtools/call-sphinx-build.py
+++ b/buildtools/call-sphinx-build.py
@@ -3,6 +3,8 @@
 # Copyright(c) 2019 Intel Corporation
 #
 
+import filecmp
+import shutil
 import sys
 import os
 from os.path import join
@@ -30,4 +32,12 @@
 with open(join(dst, '.html.d'), 'w') as d:
 d.write('html: ' + ' '.join(srcfiles) + '\n')
 
+# copy custom CSS file
+css = 'custom.css'
+src_css = join(src, css)
+dst_css = join(dst, 'html', '_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)
+
 sys.exit(process.returncode)
diff --git a/doc/guides/meson.build b/doc/guides/meson.build
index 51f81da2e3..f8bbfba9f5 100644
--- a/doc/guides/meson.build
+++ b/doc/guides/meson.build
@@ -24,7 +24,5 @@ html_guides = custom_target('html_guides',
 install: get_option('enable_docs'),
 install_dir: htmldir)
 
-install_data(files('custom.css'), install_dir: join_paths(htmldir,'_static', 
'css'))
-
 doc_targets += html_guides
 doc_target_names += 'HTML_Guides'
-- 
2.45.0

[PATCH v2 2/2] doc: give full width to NIC overview page

[Thomas Monjalon]

The wide tables in the NIC overview exceed the normal page width
because of the large number of drivers.

A CSS trick is added to allow displaying this page in the full width
of the browser window.

Signed-off-by: Thomas Monjalon 
---
v2: no change
---
 doc/guides/custom.css| 8 
 doc/guides/nics/overview.rst | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/doc/guides/custom.css b/doc/guides/custom.css
index 221024655c..df1a52f1d4 100644
--- a/doc/guides/custom.css
+++ b/doc/guides/custom.css
@@ -4,6 +4,14 @@
 
 /* Override readthedocs theme */
 
+/* Set full width on a page.
+ * Usage: insert the following line in the doc.
+ *.. rst-class:: widepage
+ */
+.wy-nav-content:has(.widepage) {
+max-width: none !important;
+}
+
 /* Spacing before a list item must be bigger than spacing inside the item.
  * Complex list items start with a p.first element. */
 .section li > .first {
diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index 67575c699c..4553076481 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -24,6 +24,8 @@ Most of these differences are summarized below.
 
 More details about features can be found in :doc:`features`.
 
+.. rst-class:: widepage
+
 .. _table_net_pmd_features:
 
 .. include:: overview_table.txt
-- 
2.45.0

Re: Regarding port numbers assigned by DPDK for PCI devices

[Ferruh Yigit]

On 7/30/2024 6:36 AM, Prashant Upadhyaya wrote:
> 
> 
> 
> On Mon, 29 Jul 2024 at 23:13, Dmitry Kozlyuk  > wrote:
> 
> 2024-07-29 22:18 (UTC+0530), Prashant Upadhyaya:
> > Hi,
> >
> > I have 4 ethernet interfaces available as PCI devices.
> > The PCI addresses are known.
> > When I start my DPDK application, it starts up properly and
> assigns the
> > port numbers to them as 0, 1, 2, 3 expectedly.
> >
> > However, is there a way I can force that a particular PCI address
> should be
> > identified as port 0 by DPDK, another one as port 1 and so forth ?
> > Does passing the arguments like -a  -a  to
> rte_eal_init
> > ensure that, or is there any other way, or is there no way ?
> >
> > I am on 24.03
> >
> > Regards
> > -Prashant
> 
> Hi,
> 
> Why do you need specific port numbers assigned to devices?
> 
> If you're going to use devices for different purposes,
> you'd better have an application-level configuration
> to specify PCI addresses to use for each purpose.
> Iterate devices to match the address and find the port number.
> 
> It is also possible to disable automatic probing with "-a 0:0.0",
> then to use rte_dev_probe() + rte_dev_event_callback_register()
> to add devices and to get their port numbers.
> However, this API, strictly speaking, does not guarantee
> that the numbers will be assigned sequentially.
> One advantage of using hot-plug is that you can build devargs
> from within the application (or from configuration).
> 
> Refer to "rte_dev.h" in any case.
> Multiple "-a" don't work the way you've described.
> 
> 
> 
> Thanks Dmitry. Ok, so if I have the port number with me, and I know it
> corresponds to a PCI device, how do I find out the PCI address of this
> device corresponding to this port number. I believe I can
> do rte_eth_dev_info_get to get the struct rte_eth_dev_info and from
> there the rte_device, but what after that ? I saw some references
> to RTE_DEV_TO_PCI but that macro isn't available for compilation after
> DPDK is installed as it is an internal header file and thus not a macro
> for application usage and wouldn't compile at application level.
> 
> 

Hi Prashant,

For PCI bus, most of the times ethdev device name is PCI ID, so you can
use 'rte_eth_dev_get_name_by_port(port_id, name)' API to get PCI ID for
port.

But there are cases this is not true, like single PCI ID creates
multiple ethdev etc... for this case, PCI ID can be get from device name:
rte_eth_dev_info_get(port_id, *dev_info)
name = rte_dev_name(dev_info->device)

RE: [PATCH] build: output a dependency log in build directory

[Konstantin Ananyev]

> As meson processes our DPDK source tree it manages dependencies
> specified by each individual driver. To enable future analysis of the
> dependency links between components, log the dependencies of each DPDK
> component as it gets processed. This could potentially allow other tools
> to automatically enable or disable components based on the desired end
> components to be built, e.g. if the user requests net/ice, ensure that
> common/iavf is also enabled in the drivers.
> 
> The output file produced is in "dot" or "graphviz" format, which allows
> producing a graphical representation of the DPDK dependency tree if so
> desired. For example: "dot -Tpng -O build/deps.dot" to produce the
> image file "build/deps.dot.png".
> 
> Signed-off-by: Bruce Richardson 

I think it is a great idea.
Acked-by: Konstantin Ananyev 

> ---
>  app/meson.build|  1 +
>  buildtools/log-deps.py | 43 ++
>  buildtools/meson.build |  2 ++
>  drivers/meson.build|  1 +
>  lib/meson.build|  1 +
>  5 files changed, 48 insertions(+)
>  create mode 100644 buildtools/log-deps.py
> 
> diff --git a/app/meson.build b/app/meson.build
> index 5b2c80c7a1..6afa457f4c 100644
> --- a/app/meson.build
> +++ b/app/meson.build
> @@ -76,6 +76,7 @@ foreach app:apps
> 
>  if build
>  subdir(name)
> +run_command([log_deps_cmd, name, deps])
>  if not build and require_apps
>  error('Cannot build explicitly requested app 
> "@0@".\n'.format(name)
>+ '\tReason: ' + reason)
> diff --git a/buildtools/log-deps.py b/buildtools/log-deps.py
> new file mode 100644
> index 00..a4331fa15b
> --- /dev/null
> +++ b/buildtools/log-deps.py
> @@ -0,0 +1,43 @@
> +#! /usr/bin/env python3
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(c) 2024 Intel Corporation
> +
> +"""Utility script to build up a list of dependencies from meson."""
> +
> +import os
> +import sys
> +
> +
> +def file_to_list(filename):
> +"""Read file into a list of strings."""
> +with open(filename) as f:
> +return f.readlines()
> +
> +
> +def list_to_file(filename, lines):
> +"""Write a list of strings out to a file."""
> +with open(filename, 'w') as f:
> +f.writelines(lines)
> +
> +
> +depsfile = f'{os.environ["MESON_BUILD_ROOT"]}/deps.dot'
> +
> +# to reset the deps file on each build, the script is called without any 
> params
> +if len(sys.argv) == 1:
> +os.remove(depsfile)
> +sys.exit(0)
> +
> +try:
> +contents = file_to_list(depsfile)
> +except FileNotFoundError:
> +contents = ['digraph {\n', '}\n']
> +
> +component = sys.argv[1]
> +if len(sys.argv) > 2:
> +contents[-1] = f'"{component}" -> {{ "{"\", \"".join(sys.argv[2:])}" 
> }}\n'
> +else:
> +contents[-1] = f'"{component}"\n'
> +
> +contents.append('}\n')
> +
> +list_to_file(depsfile, contents)
> diff --git a/buildtools/meson.build b/buildtools/meson.build
> index 3adf34e1a8..332f0f3d38 100644
> --- a/buildtools/meson.build
> +++ b/buildtools/meson.build
> @@ -24,6 +24,8 @@ get_numa_count_cmd = py3 + files('get-numa-count.py')
>  get_test_suites_cmd = py3 + files('get-test-suites.py')
>  has_hugepages_cmd = py3 + files('has-hugepages.py')
>  cmdline_gen_cmd = py3 + files('dpdk-cmdline-gen.py')
> +log_deps_cmd = py3 + files('log-deps.py')
> +run_command(log_deps_cmd)  # call with no parameters to reset the file
> 
>  # install any build tools that end-users might want also
>  install_data([
> diff --git a/drivers/meson.build b/drivers/meson.build
> index 66931d4241..44935e067c 100644
> --- a/drivers/meson.build
> +++ b/drivers/meson.build
> @@ -154,6 +154,7 @@ foreach subpath:subdirs
>  if build
>  # pull in driver directory which should update all the local 
> variables
>  subdir(drv_path)
> +run_command([log_deps_cmd, drv_path.underscorify(), deps])
> 
>  if dpdk_conf.get('RTE_IOVA_IN_MBUF') == 0 and 
> require_iova_in_mbuf
>  build = false
> diff --git a/lib/meson.build b/lib/meson.build
> index 162287753f..da2815465f 100644
> --- a/lib/meson.build
> +++ b/lib/meson.build
> @@ -160,6 +160,7 @@ foreach l:libraries
> 
>  if build
>  subdir(l)
> +run_command([log_deps_cmd, l, deps])
>  if not build and require_libs
>  error('Cannot build explicitly requested lib 
> "@0@".\n'.format(name)
>  +'\tReason: ' + reason)
> --
> 2.43.0

Re: Regarding port numbers assigned by DPDK for PCI devices

[Prashant Upadhyaya]

On Wed, 31 Jul 2024 at 14:35, Ferruh Yigit  wrote:

> On 7/30/2024 6:36 AM, Prashant Upadhyaya wrote:
> >
> >
> >
> > On Mon, 29 Jul 2024 at 23:13, Dmitry Kozlyuk  > > wrote:
> >
> > 2024-07-29 22:18 (UTC+0530), Prashant Upadhyaya:
> > > Hi,
> > >
> > > I have 4 ethernet interfaces available as PCI devices.
> > > The PCI addresses are known.
> > > When I start my DPDK application, it starts up properly and
> > assigns the
> > > port numbers to them as 0, 1, 2, 3 expectedly.
> > >
> > > However, is there a way I can force that a particular PCI address
> > should be
> > > identified as port 0 by DPDK, another one as port 1 and so forth ?
> > > Does passing the arguments like -a  -a  to
> > rte_eal_init
> > > ensure that, or is there any other way, or is there no way ?
> > >
> > > I am on 24.03
> > >
> > > Regards
> > > -Prashant
> >
> > Hi,
> >
> > Why do you need specific port numbers assigned to devices?
> >
> > If you're going to use devices for different purposes,
> > you'd better have an application-level configuration
> > to specify PCI addresses to use for each purpose.
> > Iterate devices to match the address and find the port number.
> >
> > It is also possible to disable automatic probing with "-a 0:0.0",
> > then to use rte_dev_probe() + rte_dev_event_callback_register()
> > to add devices and to get their port numbers.
> > However, this API, strictly speaking, does not guarantee
> > that the numbers will be assigned sequentially.
> > One advantage of using hot-plug is that you can build devargs
> > from within the application (or from configuration).
> >
> > Refer to "rte_dev.h" in any case.
> > Multiple "-a" don't work the way you've described.
> >
> >
> >
> > Thanks Dmitry. Ok, so if I have the port number with me, and I know it
> > corresponds to a PCI device, how do I find out the PCI address of this
> > device corresponding to this port number. I believe I can
> > do rte_eth_dev_info_get to get the struct rte_eth_dev_info and from
> > there the rte_device, but what after that ? I saw some references
> > to RTE_DEV_TO_PCI but that macro isn't available for compilation after
> > DPDK is installed as it is an internal header file and thus not a macro
> > for application usage and wouldn't compile at application level.
> >
> >
>
> Hi Prashant,
>
> For PCI bus, most of the times ethdev device name is PCI ID, so you can
> use 'rte_eth_dev_get_name_by_port(port_id, name)' API to get PCI ID for
> port.
>
> But there are cases this is not true, like single PCI ID creates
> multiple ethdev etc... for this case, PCI ID can be get from device name:
> rte_eth_dev_info_get(port_id, *dev_info)
> name = rte_dev_name(dev_info->device)
>
>
>
Thanks Ferruh, this was helpful.

Regards
-Prashant

Re: Regarding port numbers assigned by DPDK for PCI devices

[Prashant Upadhyaya]

On Tue, 30 Jul 2024 at 13:45, Bruce Richardson 
wrote:

> On Tue, Jul 30, 2024 at 11:06:56AM +0530, Prashant Upadhyaya wrote:
> >On Mon, 29 Jul 2024 at 23:13, Dmitry Kozlyuk
> ><[1]dmitry.kozl...@gmail.com> wrote:
> >
> >  2024-07-29 22:18 (UTC+0530), Prashant Upadhyaya:
> >  > Hi,
> >  >
> >  > I have 4 ethernet interfaces available as PCI devices.
> >  > The PCI addresses are known.
> >  > When I start my DPDK application, it starts up properly and
> >  assigns the
> >  > port numbers to them as 0, 1, 2, 3 expectedly.
> >  >
> >  > However, is there a way I can force that a particular PCI address
> >  should be
> >  > identified as port 0 by DPDK, another one as port 1 and so forth ?
> >  > Does passing the arguments like -a  -a  to
> >  rte_eal_init
> >  > ensure that, or is there any other way, or is there no way ?
> >  >
> >  > I am on 24.03
> >  >
> >  > Regards
> >  > -Prashant
> >  Hi,
> >  Why do you need specific port numbers assigned to devices?
> >  If you're going to use devices for different purposes,
> >  you'd better have an application-level configuration
> >  to specify PCI addresses to use for each purpose.
> >  Iterate devices to match the address and find the port number.
> >  It is also possible to disable automatic probing with "-a 0:0.0",
> >  then to use rte_dev_probe() + rte_dev_event_callback_register()
> >  to add devices and to get their port numbers.
> >  However, this API, strictly speaking, does not guarantee
> >  that the numbers will be assigned sequentially.
> >  One advantage of using hot-plug is that you can build devargs
> >  from within the application (or from configuration).
> >  Refer to "rte_dev.h" in any case.
> >  Multiple "-a" don't work the way you've described.
> >
> >Thanks Dmitry. Ok, so if I have the port number with me, and I know it
> >corresponds to a PCI device, how do I find out the PCI address of this
> >device corresponding to this port number. I believe I can
> >do rte_eth_dev_info_get to get the struct rte_eth_dev_info and from
> >there the rte_device, but what after that ? I saw some references
> >to RTE_DEV_TO_PCI but that macro isn't available for compilation after
> >DPDK is installed as it is an internal header file and thus not a
> macro
> >for application usage and wouldn't compile at application level.
> >Regards
> >-Prashant
> >
> The PCI device id is used as the device name in that case so rte_dev_name
> should get you what you want.
>
> I'd also +1 the suggestion of having your app hotplug in the devices
> post-init, if you want specific devices to have specific ids. Although it
> is not guaranteed, DPDK does currently assign the ids sequentially. I've
> used this approach myself in the past in some test apps where I wanted
> ports in a particular sequence.
>
> /Bruce
>

Thanks Bruce, makes sense.

Regards
-Prashant

Re: [PATCH] build: output a dependency log in build directory

[Ferruh Yigit]

On 7/30/2024 3:55 PM, Bruce Richardson wrote:
> As meson processes our DPDK source tree it manages dependencies
> specified by each individual driver. To enable future analysis of the
> dependency links between components, log the dependencies of each DPDK
> component as it gets processed. This could potentially allow other tools
> to automatically enable or disable components based on the desired end
> components to be built, e.g. if the user requests net/ice, ensure that
> common/iavf is also enabled in the drivers.
> 
> The output file produced is in "dot" or "graphviz" format, which allows
> producing a graphical representation of the DPDK dependency tree if so
> desired. For example: "dot -Tpng -O build/deps.dot" to produce the
> image file "build/deps.dot.png".
> 
> Signed-off-by: Bruce Richardson 
>

I tested it quickly, good to have this dependency list, at least it
makes some duplicated dependencies obvious from .dot file.

But generated dependency graph is too large to be useful, does it make
sense to have a new meson option that control this dependency generation:
-Dgenerate_deps=apps
-Dgenerate_deps=libs
-Dgenerate_deps=drivers
-Dgenerate_deps=all

Not sure about what should be the default option,
as this is not always required/used, disabling this option by default
saves unnecessary work,
but disabling it by default may cause not noticing when it is broken,
perhaps this can be addressed by adding this option to
'devtools/test-meson-builds.sh'.

btw, it generates following warning:

WARNING: You should add the boolean check kwarg to the run_command call.


 It currently defaults to false,


 but it will default to true in future releases of meson.


 See also: https://github.com/mesonbuild/meson/issues/9300


> ---
>  app/meson.build|  1 +
>  buildtools/log-deps.py | 43 ++
>  buildtools/meson.build |  2 ++
>  drivers/meson.build|  1 +
>  lib/meson.build|  1 +
>  5 files changed, 48 insertions(+)
>  create mode 100644 buildtools/log-deps.py
> 
> diff --git a/app/meson.build b/app/meson.build
> index 5b2c80c7a1..6afa457f4c 100644
> --- a/app/meson.build
> +++ b/app/meson.build
> @@ -76,6 +76,7 @@ foreach app:apps
>  
>  if build
>  subdir(name)
> +run_command([log_deps_cmd, name, deps])
>  if not build and require_apps
>  error('Cannot build explicitly requested app 
> "@0@".\n'.format(name)
>+ '\tReason: ' + reason)
> diff --git a/buildtools/log-deps.py b/buildtools/log-deps.py
> new file mode 100644
> index 00..a4331fa15b
> --- /dev/null
> +++ b/buildtools/log-deps.py
> @@ -0,0 +1,43 @@
> +#! /usr/bin/env python3
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(c) 2024 Intel Corporation
> +
> +"""Utility script to build up a list of dependencies from meson."""
> +
> +import os
> +import sys
> +
> +
> +def file_to_list(filename):
> +"""Read file into a list of strings."""
> +with open(filename) as f:
> +return f.readlines()
> +
> +
> +def list_to_file(filename, lines):
> +"""Write a list of strings out to a file."""
> +with open(filename, 'w') as f:
> +f.writelines(lines)
> +
> +
> +depsfile = f'{os.environ["MESON_BUILD_ROOT"]}/deps.dot'
> +
> +# to reset the deps file on each build, the script is called without any 
> params
> +if len(sys.argv) == 1:
> +os.remove(depsfile)
> +sys.exit(0)
> +
> +try:
> +contents = file_to_list(depsfile)
> +except FileNotFoundError:
> +contents = ['digraph {\n', '}\n']
> +
> +component = sys.argv[1]
> +if len(sys.argv) > 2:
> +contents[-1] = f'"{component}" -> {{ "{"\", \"".join(sys.argv[2:])}" 
> }}\n'
> +else:
> +contents[-1] = f'"{component}"\n'
> +
> +contents.append('}\n')
> +
> +list_to_file(depsfile, contents)
> diff --git a/buildtools/meson.build b/buildtools/meson.build
> index 3adf34e1a8..332f0f3d38 100644
> --- a/buildtools/meson.build
> +++ b/buildtools/meson.build
> @@ -24,6 +24,8 @@ get_numa_count_cmd = py3 + files('get-numa-count.py')
>  get_test_suites_cmd = py3 + files('get-test-suites.py')
>  has_hugepages_cmd = py3 + files('has-hugepages.py')
>  cmdline_gen_cmd = py3 + files('dpdk-cmdline-gen.py')
> +log_deps_cmd = py3 + files('log-deps.py')
> +run_command(log_deps_cmd)  # call with no parameters to reset the file
>  
>  # install any build tools that end-users might want also
>  install_data([
> diff --git a/drivers/meson.build b/drivers/meson.build
> index 66931d4241..44935e067c 100644
> --- a/drivers/meson.build
> +++ b/drivers/meson.build
> @@ -154,6 +154,7 @@ foreach subpath:subdirs
>  if build
>  # pull in driver directory which should update all the local 
> variables
>  subdir(drv_path)
> +run_command([log_deps_cmd, drv_path.underscorify(), deps])
>  
>  if dpdk_conf.get('RTE_IOVA_IN_MBUF') == 0 and 
> require_iova_in_mbuf
>  build = false
> diff --git 

Re: [PATCH] doc: announce dmadev new capability addition

[Thomas Monjalon]

29/07/2024 17:20, Jerin Jacob:
> On Mon, Jul 29, 2024 at 6:19 PM Vamsi Attunuru  wrote:
> >
> > Announce addition of new capability flag and fields in
> 
> The new capability flag won't break ABI. We can mention only fields
> update rte_dma_info and rte_dma_conf structures.
> 
> Another option is new set APIs for priority enablement.  The downside
> is more code. All, opinions?
> 
> > rte_dma_info and rte_dma_conf structures.

I'm fine with just updating these structs.

> > Signed-off-by: Vamsi Attunuru 

Acked-by: Thomas Monjalon 

Any other opinions?

Re: [PATCH] build: output a dependency log in build directory

[Bruce Richardson]

On Wed, Jul 31, 2024 at 11:17:54AM +0100, Ferruh Yigit wrote:
> On 7/30/2024 3:55 PM, Bruce Richardson wrote:
> > As meson processes our DPDK source tree it manages dependencies
> > specified by each individual driver. To enable future analysis of the
> > dependency links between components, log the dependencies of each DPDK
> > component as it gets processed. This could potentially allow other tools
> > to automatically enable or disable components based on the desired end
> > components to be built, e.g. if the user requests net/ice, ensure that
> > common/iavf is also enabled in the drivers.
> > 
> > The output file produced is in "dot" or "graphviz" format, which allows
> > producing a graphical representation of the DPDK dependency tree if so
> > desired. For example: "dot -Tpng -O build/deps.dot" to produce the
> > image file "build/deps.dot.png".
> > 
> > Signed-off-by: Bruce Richardson 
> >
> 
> I tested it quickly, good to have this dependency list, at least it
> makes some duplicated dependencies obvious from .dot file.
> 
> But generated dependency graph is too large to be useful, does it make
> sense to have a new meson option that control this dependency generation:
> -Dgenerate_deps=apps
> -Dgenerate_deps=libs
> -Dgenerate_deps=drivers
> -Dgenerate_deps=all
> 

I had indeed noticed that. Right now I'm focused on cutting down our
dependency lists to make things more manageable - I have a script to
automate the identification of excess dependencies and I already have a
patch for cleaning up the libraries to a minimal dependency set.

I also think having separate drivers and libraries charts could be useful I
wouldn't want to add a build option for it though - it's not something that
should be necessary. Instead, I will look at other options, perhaps even
doing multiple dependency files - they don't seem to slow meson down, so
why not always do them all.

> Not sure about what should be the default option,
> as this is not always required/used, disabling this option by default
> saves unnecessary work,
> but disabling it by default may cause not noticing when it is broken,
> perhaps this can be addressed by adding this option to
> 'devtools/test-meson-builds.sh'.
> 
> btw, it generates following warning:

Oops - will look to fix in V2.

/Bruce

Re: [V1] doc: announce deprecation of flow item VXLAN-GPE

[Thomas Monjalon]

29/07/2024 15:47, Ajit Khaparde:
> On Mon, Jul 29, 2024 at 1:48 AM Thomas Monjalon  wrote:
> >
> > 26/07/2024 13:31, Ferruh Yigit:
> > > On 7/26/2024 9:51 AM, Gavin Li wrote:
> > > > Adding the deprecation notice as reminder for removing
> > > > RTE_FLOW_ITEM_TYPE_VXLAN_GPE and its related structures,
> > > > eg. rte_vxlan_gpe_hdr, rte_flow_item_vxlan_gpe, etc.
> > > >
> > > > The proposed time of the removal is DPDK release 25.11.
> > > >
> > > > Signed-off-by: Gavin Li 
> > > > ---
> > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > + * ethdev,net: The flow item ``RTE_FLOW_ITEM_TYPE_VXLAN_GPE`` is 
> > > > replaced with ``RTE_FLOW_ITEM_TYPE_VXLAN``.
> > > > +   The struct ``rte_flow_item_vxlan_gpe``, its mask 
> > > > ``rte_flow_item_vxlan_gpe_mask`` are replaced with
> > > > +   ``rte_flow_item_vxlan and its mask`` and its mask 
> > > > ``rte_flow_item_vxlan_mask``.
> > > > +   The item ``RTE_FLOW_ITEM_TYPE_VXLAN_GPE``, the struct 
> > > > ``rte_flow_item_vxlan_gpe``, its mask ``rte_flow_item_vxlan_gpe_mask``,
> > > > +   and the header struct ``rte_vxlan_gpe_hdr`` with the macro 
> > > > ``RTE_ETHER_VXLAN_GPE_HLEN``
> > > > +   will be removed in DPDK 25.11.
> > >
> > > Acked-by: Ferruh Yigit 
> >
> > Acked-by: Thomas Monjalon 
> Acked-by: Ajit Khaparde 

Applied with indent fixed, thanks.

Re: ipsec on dpdk

[Thomas Monjalon]

Hello,

Adding Cc some experts.

About the IPsec support, we are writing a document, it is in progress.


28/07/2024 14:51, Yaron Illouz:
> Hi
> 
> I am interested to do ipsec encoding and decoding in my dpdk application
> From my readings, i understand ipsec can be done one time in the nic (inline 
> ipsec) or with multiple calls (rte_cryptodev_enqueue_burst, 
> rte_cryptodev_dequeue_burst)
> 
> 
>   1.  If ipsec is done by nic I only need to call rte_ipsec_pkt_process(...) 
> without other functions?
> 
> I use  rte_eth_rx_burst to read from nic.
> 
>   1.  Where do I see list of nic that support nic inline ipsec? I believe not 
> all dpdk nic support it.
>   2.  How much does it impact performance ? is there a table of performance 
> per nic?
>   3.  My application is multi process, I can see in documentation :
> 
> “Currently, the security library does not support the case of multi-process. 
> It will be updated in the future releases.” From 
> https://doc.dpdk.org/guides/prog_guide/rte_security.html
> 
> So ipsec also is not supported for multi process application?
> 
> Even if done inline by the nic?
> 
> And what about non inline ipsec for multi process applications?
> 
> 
> 
>   1.  Is ip sec also supported in multi queue with rte flow in the inline 
> ipsec ?
> 

Re: [PATCH dpdk v2] rel_notes: announce 24.11 ipv6 api breakage

[Thomas Monjalon]

23/07/2024 10:27, Robin Jarry:
> In 24.11, all IPv6 public APIs will be modified to use a structure
> instead of fixed size arrays.
> 
> Signed-off-by: Robin Jarry 
> Acked-by: Morten Brørup 
Acked-by: Bruce Richardson 
Acked-by: Konstantin Ananyev 
Acked-by: Vladimir Medvedkin 

Applied, thanks.

Re: [PATCH v4] doc: announce changes to dma device structures

[Thomas Monjalon]

30/07/2024 19:27, Jerin Jacob:
> On Tue, Jul 30, 2024 at 8:25 PM Amit Prakash Shukla
>  wrote:
> >
> > A new flag RTE_DMA_CAPA_QOS will be introduced to advertise dma
> > device's QoS capability. In order to support the parameters for this
> > flag, new fields will be added in rte_dma_info and rte_dma_conf
> > structures to get device supported priority levels and to configure the
> > required priority level.
> >
> > Signed-off-by: Vamsi Attunuru 
> > Signed-off-by: Amit Prakash Shukla 
> 
> 
> Acked-by: Jerin Jacob 

Acked-by: Thomas Monjalon 

Re: [PATCH] doc: announce fib configuration structure changes

[Thomas Monjalon]

26/07/2024 18:36, Robin Jarry:
> Vladimir Medvedkin, Jul 26, 2024 at 18:13:
> > Announce addition of the flags field into rte_fib_conf structure.
> >
> > Signed-off-by: Vladimir Medvedkin 
> 
> Acked-by: Robin Jarry 

Any other opinions?

Re: [PATCH] doc: announce fib configuration structure changes

[Bruce Richardson]

On Wed, Jul 31, 2024 at 01:03:11PM +0200, Thomas Monjalon wrote:
> 26/07/2024 18:36, Robin Jarry:
> > Vladimir Medvedkin, Jul 26, 2024 at 18:13:
> > > Announce addition of the flags field into rte_fib_conf structure.
> > >
> > > Signed-off-by: Vladimir Medvedkin 
> > 
> > Acked-by: Robin Jarry 
> 
Acked-by: Bruce Richardson 

[PATCH] doc: add tested platforms with NVIDIA NICs

[Raslan Darawsheh]

Add tested platforms with NVIDIA NICs to the 24.07 release notes.

Signed-off-by: Raslan Darawsheh 
---
 doc/guides/rel_notes/release_24_07.rst | 107 +
 1 file changed, 107 insertions(+)

diff --git a/doc/guides/rel_notes/release_24_07.rst 
b/doc/guides/rel_notes/release_24_07.rst
index eb2ed1a55f..30b8f97a90 100644
--- a/doc/guides/rel_notes/release_24_07.rst
+++ b/doc/guides/rel_notes/release_24_07.rst
@@ -286,3 +286,110 @@ Tested Platforms
This section is a comment. Do not overwrite or remove it.
Also, make sure to start the actual text at the margin.
===
+
+* Intel\ |reg| platforms with NVIDIA\ |reg| NICs combinations
+
+  * CPU:
+
+* Intel\ |reg| Xeon\ |reg| Gold 6154 CPU @ 3.00GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2697A v4 @ 2.60GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2697 v3 @ 2.60GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2680 v2 @ 2.80GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2670 0 @ 2.60GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2650 v4 @ 2.20GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2650 v3 @ 2.30GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2640 @ 2.50GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2650 0 @ 2.00GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2620 v4 @ 2.10GHz
+
+  * OS:
+
+* Red Hat Enterprise Linux release 9.1 (Plow)
+* Red Hat Enterprise Linux release 8.6 (Ootpa)
+* Red Hat Enterprise Linux release 8.4 (Ootpa)
+* Red Hat Enterprise Linux Server release 7.9 (Maipo)
+* Red Hat Enterprise Linux Server release 7.6 (Maipo)
+* Ubuntu 22.04
+* Ubuntu 20.04
+* SUSE Enterprise Linux 15 SP2
+
+  * OFED:
+
+* MLNX_OFED 24.04-0.6.6.0 and above
+
+  * upstream kernel:
+
+* Linux 6.10.0 and above
+
+  * rdma-core:
+
+* rdma-core-52.0 and above
+
+  * NICs
+
+* NVIDIA\ |reg| ConnectX\ |reg|-6 Dx EN 100G MCX623106AN-CDAT (2x100G)
+
+  * Host interface: PCI Express 4.0 x16
+  * Device ID: 15b3:101d
+  * Firmware version: 22.41.1000 and above
+
+* NVIDIA\ |reg| ConnectX\ |reg|-6 Lx EN 25G MCX631102AN-ADAT (2x25G)
+
+  * Host interface: PCI Express 4.0 x8
+  * Device ID: 15b3:101f
+  * Firmware version: 26.41.1000 and above
+
+* NVIDIA\ |reg| ConnectX\ |reg|-7 200G CX713106AE-HEA_QP1_Ax (2x200G)
+
+  * Host interface: PCI Express 5.0 x16
+  * Device ID: 15b3:1021
+  * Firmware version: 28.41.1000 and above
+
+* NVIDIA\ |reg| BlueField\ |reg| SmartNIC
+
+  * NVIDIA\ |reg| BlueField\ |reg|-2 SmartNIC MT41686 - MBF2H332A-AEEOT_A1 
(2x25G)
+
+* Host interface: PCI Express 3.0 x16
+* Device ID: 15b3:a2d6
+* Firmware version: 24.41.1000 and above
+
+  * NVIDIA\ |reg| BlueField\ |reg|-3 P-Series DPU MT41692 - 900-9D3B6-00CV-AAB 
(2x200G)
+
+* Host interface: PCI Express 5.0 x16
+* Device ID: 15b3:a2dc
+* Firmware version: 32.41.1000 and above
+
+  * Embedded software:
+
+* Ubuntu 22.04
+* MLNX_OFED 24.04-0.6.6.0 and above
+* bf-bundle-2.7.0-33_24.04_ubuntu-22.04
+* DPDK application running on ARM cores
+
+* IBM Power 9 platforms with NVIDIA\ |reg| NICs combinations
+
+  * CPU:
+
+* POWER9 2.2 (pvr 004e 1202)
+
+  * OS:
+
+* Ubuntu 20.04
+
+  * NICs:
+
+* NVIDIA\ |reg| ConnectX\ |reg|-6 Dx 100G MCX623106AN-CDAT (2x100G)
+
+  * Host interface: PCI Express 4.0 x16
+  * Device ID: 15b3:101d
+  * Firmware version: 22.41.1000 and above
+
+* NVIDIA\ |reg| ConnectX\ |reg|-7 200G CX713106AE-HEA_QP1_Ax (2x200G)
+
+  * Host interface: PCI Express 5.0 x16
+  * Device ID: 15b3:1021
+  * Firmware version: 28.41.1000 and above
+
+  * OFED:
+
+* MLNX_OFED 24.04-0.6.6.0
-- 
2.39.3 (Apple Git-146)

[PATCH] doc: add tested platforms with NVIDIA NICs

[Raslan Darawsheh]

Add tested platforms with NVIDIA NICs to the 24.07 release notes.

Signed-off-by: Raslan Darawsheh 
---
 doc/guides/rel_notes/release_24_07.rst | 107 +
 1 file changed, 107 insertions(+)

diff --git a/doc/guides/rel_notes/release_24_07.rst 
b/doc/guides/rel_notes/release_24_07.rst
index eb2ed1a55f..30b8f97a90 100644
--- a/doc/guides/rel_notes/release_24_07.rst
+++ b/doc/guides/rel_notes/release_24_07.rst
@@ -286,3 +286,110 @@ Tested Platforms
This section is a comment. Do not overwrite or remove it.
Also, make sure to start the actual text at the margin.
===
+
+* Intel\ |reg| platforms with NVIDIA\ |reg| NICs combinations
+
+  * CPU:
+
+* Intel\ |reg| Xeon\ |reg| Gold 6154 CPU @ 3.00GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2697A v4 @ 2.60GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2697 v3 @ 2.60GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2680 v2 @ 2.80GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2670 0 @ 2.60GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2650 v4 @ 2.20GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2650 v3 @ 2.30GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2640 @ 2.50GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2650 0 @ 2.00GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2620 v4 @ 2.10GHz
+
+  * OS:
+
+* Red Hat Enterprise Linux release 9.1 (Plow)
+* Red Hat Enterprise Linux release 8.6 (Ootpa)
+* Red Hat Enterprise Linux release 8.4 (Ootpa)
+* Red Hat Enterprise Linux Server release 7.9 (Maipo)
+* Red Hat Enterprise Linux Server release 7.6 (Maipo)
+* Ubuntu 22.04
+* Ubuntu 20.04
+* SUSE Enterprise Linux 15 SP2
+
+  * OFED:
+
+* MLNX_OFED 24.04-0.6.6.0 and above
+
+  * upstream kernel:
+
+* Linux 6.10.0 and above
+
+  * rdma-core:
+
+* rdma-core-52.0 and above
+
+  * NICs
+
+* NVIDIA\ |reg| ConnectX\ |reg|-6 Dx EN 100G MCX623106AN-CDAT (2x100G)
+
+  * Host interface: PCI Express 4.0 x16
+  * Device ID: 15b3:101d
+  * Firmware version: 22.41.1000 and above
+
+* NVIDIA\ |reg| ConnectX\ |reg|-6 Lx EN 25G MCX631102AN-ADAT (2x25G)
+
+  * Host interface: PCI Express 4.0 x8
+  * Device ID: 15b3:101f
+  * Firmware version: 26.41.1000 and above
+
+* NVIDIA\ |reg| ConnectX\ |reg|-7 200G CX713106AE-HEA_QP1_Ax (2x200G)
+
+  * Host interface: PCI Express 5.0 x16
+  * Device ID: 15b3:1021
+  * Firmware version: 28.41.1000 and above
+
+* NVIDIA\ |reg| BlueField\ |reg| SmartNIC
+
+  * NVIDIA\ |reg| BlueField\ |reg|-2 SmartNIC MT41686 - MBF2H332A-AEEOT_A1 
(2x25G)
+
+* Host interface: PCI Express 3.0 x16
+* Device ID: 15b3:a2d6
+* Firmware version: 24.41.1000 and above
+
+  * NVIDIA\ |reg| BlueField\ |reg|-3 P-Series DPU MT41692 - 900-9D3B6-00CV-AAB 
(2x200G)
+
+* Host interface: PCI Express 5.0 x16
+* Device ID: 15b3:a2dc
+* Firmware version: 32.41.1000 and above
+
+  * Embedded software:
+
+* Ubuntu 22.04
+* MLNX_OFED 24.04-0.6.6.0 and above
+* bf-bundle-2.7.0-33_24.04_ubuntu-22.04
+* DPDK application running on ARM cores
+
+* IBM Power 9 platforms with NVIDIA\ |reg| NICs combinations
+
+  * CPU:
+
+* POWER9 2.2 (pvr 004e 1202)
+
+  * OS:
+
+* Ubuntu 20.04
+
+  * NICs:
+
+* NVIDIA\ |reg| ConnectX\ |reg|-6 Dx 100G MCX623106AN-CDAT (2x100G)
+
+  * Host interface: PCI Express 4.0 x16
+  * Device ID: 15b3:101d
+  * Firmware version: 22.41.1000 and above
+
+* NVIDIA\ |reg| ConnectX\ |reg|-7 200G CX713106AE-HEA_QP1_Ax (2x200G)
+
+  * Host interface: PCI Express 5.0 x16
+  * Device ID: 15b3:1021
+  * Firmware version: 28.41.1000 and above
+
+  * OFED:
+
+* MLNX_OFED 24.04-0.6.6.0
-- 
2.39.3 (Apple Git-146)

[PATCH] doc: announce change in crypto queue setup

[Akhil Goyal]

Certain hardware crypto PMDs may support setting up
of priority to a queue pair.
Hence a new parameter for priority will be added in
struct rte_cryptodev_qp_conf.

Signed-off-by: Akhil Goyal 
---
 doc/guides/rel_notes/deprecation.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 6948641ff6..4d114cec3e 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -125,6 +125,9 @@ Deprecation Notices
   This will effect the KASUMI, SNOW3G, ZUC, AESNI GCM, AESNI MB and CHACHAPOLY
   SW PMDs.
 
+* cryptodev: The structure ``rte_cryptodev_qp_conf`` will be updated to have
+  a new parameter to set priority of that particular queue pair.
+
 * eventdev: The single-event (non-burst) enqueue and dequeue operations,
   used by static inline burst enqueue and dequeue functions in 
``rte_eventdev.h``,
   will be removed in DPDK 23.11.
-- 
2.25.1

Re: [PATCH v2 1/2] doc: copy custom CSS on guides build

[Ferruh Yigit]

On 7/31/2024 9:31 AM, Thomas Monjalon wrote:
> The custom CSS file for Sphinx guides was copied during install,
> but not during build time.
> Before switching to Meson, the Makefile was copying this file
> in the build steps, so the doc was complete and viewable
> from the build directory.
> 
> It is especially useful to get full documentation in the build directory
> when building only documentation with "ninja -C build doc".
> The command "ninja install" was required to get the CSS file installed,
> but it requires to build the libraries as well.
> 
> The CSS file is now copied as part of the Sphinx build script,
> and it will be installed as part of the whole html directory.
> 
> Signed-off-by: Thomas Monjalon 
>

Acked-by: Ferruh Yigit 
Tested-by: Ferruh Yigit 

RE: [PATCH] doc: announce change in crypto queue setup

[Anoob Joseph]

> 
> Certain hardware crypto PMDs may support setting up of priority to a queue
> pair.
> Hence a new parameter for priority will be added in struct
> rte_cryptodev_qp_conf.
> 
> Signed-off-by: Akhil Goyal 

Acked-by: Anoob Joseph 

RE: [PATCH] doc: announce change in crypto queue setup

[Hemant Agrawal]

> -Original Message-
> From: Akhil Goyal 
> Sent: Wednesday, July 31, 2024 4:51 PM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; david.march...@redhat.com; Hemant Agrawal
> ; ano...@marvell.com;
> pablo.de.lara.gua...@intel.com; fiona.tr...@intel.com;
> declan.dohe...@intel.com; ma...@nvidia.com; Gagandeep Singh
> ; fanzhang@gmail.com; jianjay.z...@huawei.com;
> asoma...@amd.com; ruifeng.w...@arm.com;
> konstantin.v.anan...@yandex.ru; radu.nico...@intel.com;
> ajit.khapa...@broadcom.com; rnagadhee...@marvell.com;
> adwiv...@marvell.com; ciara.po...@intel.com; Akhil Goyal
> 
> Subject: [PATCH] doc: announce change in crypto queue setup
> Importance: High
> 
> Certain hardware crypto PMDs may support setting up of priority to a queue
> pair.
> Hence a new parameter for priority will be added in struct
> rte_cryptodev_qp_conf.
> 
> Signed-off-by: Akhil Goyal 

Acked-by: Hemant Agrawal 

> ---
>  doc/guides/rel_notes/deprecation.rst | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 6948641ff6..4d114cec3e 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -125,6 +125,9 @@ Deprecation Notices
>This will effect the KASUMI, SNOW3G, ZUC, AESNI GCM, AESNI MB and
> CHACHAPOLY
>SW PMDs.
> 
> +* cryptodev: The structure ``rte_cryptodev_qp_conf`` will be updated to
> +have
> +  a new parameter to set priority of that particular queue pair.
> +
>  * eventdev: The single-event (non-burst) enqueue and dequeue operations,
>used by static inline burst enqueue and dequeue functions in
> ``rte_eventdev.h``,
>will be removed in DPDK 23.11.
> --
> 2.25.1

Re: [PATCH v2 2/2] doc: give full width to NIC overview page

[Ferruh Yigit]

On 7/31/2024 9:31 AM, Thomas Monjalon wrote:
> The wide tables in the NIC overview exceed the normal page width
> because of the large number of drivers.
> 
> A CSS trick is added to allow displaying this page in the full width
> of the browser window.
> 
> Signed-off-by: Thomas Monjalon 
>

This makes the feature table wider, so all table can fit, and scroll bar
below the table is gone, this is good.

But also it makes all paragraphs and 'Note' boxes in that page fill all
the screen, and with a wide screen this becomes a long box through end
of the screen and personally I think doesn't look nice.

Instead of making it full screen, is there are way to make it fixed
size, but larger than previous so that table still can expand fully?

[PATCH 1/2] cryptodev: add queue pair priority

[Akhil Goyal]

Added a new field priority in `rte_cryptodev_qp_conf`,
to set the queue pair priority while setting up.
The priorities can be set between
`RTE_CRYPTODEV_QP_PRIORITY_HIGHEST` and
`RTE_CRYPTODEV_QP_PRIORITY_LOWEST`.
The underlying implementation may normalize the value
as per the supported priority levels.
If the implementation does not support setting up
priority, all queue pairs will be on same priority level
and this field will be ignored.

Signed-off-by: Akhil Goyal 
Change-Id: Ida87d0f354901013f3321cfa9ada443f39b00e0f
---
 lib/cryptodev/rte_cryptodev.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index bec947f6d5..0a9cd718ea 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -608,12 +608,34 @@ enum rte_cryptodev_event_type {
RTE_CRYPTODEV_EVENT_MAX /**< max value of this enum */
 };
 
+/* Crypto queue pair priority levels */
+#define RTE_CRYPTODEV_QP_PRIORITY_HIGHEST   0
+/**< Highest priority of a cryptodev queue pair
+ * @see rte_cryptodev_queue_pair_setup(), rte_cryptodev_enqueue_burst()
+ */
+#define RTE_CRYPTODEV_QP_PRIORITY_NORMAL128
+/**< Normal priority of a cryptodev queue pair
+ * @see rte_cryptodev_queue_pair_setup(), rte_cryptodev_enqueue_burst()
+ */
+#define RTE_CRYPTODEV_QP_PRIORITY_LOWEST255
+/**< Lowest priority of a cryptodev queue pair
+ * @see rte_cryptodev_queue_pair_setup(), rte_cryptodev_enqueue_burst()
+ */
+
 /** Crypto device queue pair configuration structure. */
 /* Structure rte_cryptodev_qp_conf 8<*/
 struct rte_cryptodev_qp_conf {
uint32_t nb_descriptors; /**< Number of descriptors per queue pair */
struct rte_mempool *mp_session;
/**< The mempool for creating session in sessionless mode */
+   uint8_t priority;
+   /**< Priority for this queue pair relative to other queue pairs.
+*
+* The requested priority should in the range of
+* [@ref RTE_CRYPTODEV_QP_PRIORITY_HIGHEST, @ref 
RTE_CRYPTODEV_QP_PRIORITY_LOWEST].
+* The implementation may normalize the requested priority to
+* device supported priority value.
+*/
 };
 /* >8 End of structure rte_cryptodev_qp_conf. */
 
-- 
2.25.1

[PATCH 2/2] app/crypto-perf: test queue pair priority

[Akhil Goyal]

Updated the application to test variable queue pair priority.
A mask `--low-prio-qp-mask mask` can be set to lower the priority
of queues which are set in the mask.
This would result in lower performance for those queues.
By default the priority is set as highest.
This option is added just to verify the performance drop
of queues which have lower priority set.

Signed-off-by: Akhil Goyal 
Change-Id: I88c3877f86e92a18bdb49c4421957b1c85dd10c8
---
 app/test-crypto-perf/cperf_options.h |  3 +++
 app/test-crypto-perf/cperf_options_parsing.c | 20 
 app/test-crypto-perf/main.c  |  6 +-
 doc/guides/tools/cryptoperf.rst  |  5 +
 4 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/app/test-crypto-perf/cperf_options.h 
b/app/test-crypto-perf/cperf_options.h
index 131ecfdffb..48f409c3ba 100644
--- a/app/test-crypto-perf/cperf_options.h
+++ b/app/test-crypto-perf/cperf_options.h
@@ -32,6 +32,8 @@
 #define CPERF_TEST_FILE("test-file")
 #define CPERF_TEST_NAME("test-name")
 
+#define CPERF_LOW_PRIO_QP_MASK ("low-prio-qp-mask")
+
 #define CPERF_CIPHER_ALGO  ("cipher-algo")
 #define CPERF_CIPHER_OP("cipher-op")
 #define CPERF_CIPHER_KEY_SZ("cipher-key-sz")
@@ -107,6 +109,7 @@ struct cperf_options {
uint32_t *imix_buffer_sizes;
uint32_t nb_descriptors;
uint16_t nb_qps;
+   uint64_t low_prio_qp_mask;
 
uint32_t sessionless:1;
uint32_t shared_session:1;
diff --git a/app/test-crypto-perf/cperf_options_parsing.c 
b/app/test-crypto-perf/cperf_options_parsing.c
index c91fcf0479..8c15cd813f 100644
--- a/app/test-crypto-perf/cperf_options_parsing.c
+++ b/app/test-crypto-perf/cperf_options_parsing.c
@@ -37,6 +37,7 @@ usage(char *progname)
" --segment-sz N: set the size of the segment to use\n"
" --desc-nb N: set number of descriptors for each crypto 
device\n"
" --devtype TYPE: set crypto device type to use\n"
+   " --low-prio-qp-mask mask: set low priority for queues set in 
mask(hex)\n"
" --optype cipher-only / auth-only / cipher-then-auth / 
auth-then-cipher /\n"
"aead / pdcp / docsis / ipsec / modex / secp256r1 / sm2 
/ tls-record : set operation type\n"
" --sessionless: enable session-less crypto operations\n"
@@ -941,6 +942,22 @@ parse_pmd_cyclecount_delay_ms(struct cperf_options *opts,
return 0;
 }
 
+static int
+parse_low_prio_qp_mask(struct cperf_options *opts, const char *arg)
+{
+   char *end = NULL;
+   unsigned long n;
+
+   /* parse hexadecimal string */
+   n = strtoul(arg, &end, 16);
+   if ((optarg[0] == '\0') || (end == NULL) || (*end != '\0'))
+   return -1;
+
+   opts->low_prio_qp_mask = n;
+
+   return 0;
+}
+
 typedef int (*option_parser_t)(struct cperf_options *opts,
const char *arg);
 
@@ -962,6 +979,8 @@ static struct option lgopts[] = {
{ CPERF_SEGMENT_SIZE, required_argument, 0, 0 },
{ CPERF_DESC_NB, required_argument, 0, 0 },
 
+   { CPERF_LOW_PRIO_QP_MASK, required_argument, 0, 0 },
+
{ CPERF_IMIX, required_argument, 0, 0 },
{ CPERF_DEVTYPE, required_argument, 0, 0 },
{ CPERF_OPTYPE, required_argument, 0, 0 },
@@ -1097,6 +1116,7 @@ cperf_opts_parse_long(int opt_idx, struct cperf_options 
*opts)
{ CPERF_BUFFER_SIZE,parse_buffer_sz },
{ CPERF_SEGMENT_SIZE,   parse_segment_sz },
{ CPERF_DESC_NB,parse_desc_nb },
+   { CPERF_LOW_PRIO_QP_MASK,   parse_low_prio_qp_mask },
{ CPERF_DEVTYPE,parse_device_type },
{ CPERF_OPTYPE, parse_op_type },
{ CPERF_SESSIONLESS,parse_sessionless },
diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
index 75810dbf0b..eac87091a1 100644
--- a/app/test-crypto-perf/main.c
+++ b/app/test-crypto-perf/main.c
@@ -249,7 +249,8 @@ cperf_initialize_cryptodev(struct cperf_options *opts, 
uint8_t *enabled_cdevs)
}
 
struct rte_cryptodev_qp_conf qp_conf = {
-   .nb_descriptors = opts->nb_descriptors
+   .nb_descriptors = opts->nb_descriptors,
+   .priority = RTE_CRYPTODEV_QP_PRIORITY_HIGHEST
};
 
/**
@@ -315,6 +316,9 @@ cperf_initialize_cryptodev(struct cperf_options *opts, 
uint8_t *enabled_cdevs)
}
 
for (j = 0; j < opts->nb_qps; j++) {
+   if ((1 << j) & opts->low_prio_qp_mask)
+   qp_conf.priority = 
RTE_CRYPTODEV_QP_PRIORITY_LOWEST;
+
ret = rte_cryptodev_queue_pair_setup(cdev_id, j,
&qp_conf, socket_id);
if (ret < 0) {
diff --git a/doc/guides/tools/cryptoper

Re: [PATCH] doc: deprecate graph data structures

[Thomas Monjalon]

21/02/2024 17:13, pbhagavat...@marvell.com:
> From: Pavan Nikhilesh 
> 
> Deprecate rte_node, rte_node_register and rte_graph_cluster_node_stats
> structures as will be extended to include node specific error counters
> and error description.
> 
> Signed-off-by: Pavan Nikhilesh 

Acked-by: Jerin Jacob 
Acked-by: Nithin Dabilpuram 
Acked-by: Zhirun Yan 

Applied, thanks.

Re: [PATCH v2 2/2] doc: give full width to NIC overview page

[Thomas Monjalon]

31/07/2024 13:29, Ferruh Yigit:
> On 7/31/2024 9:31 AM, Thomas Monjalon wrote:
> > The wide tables in the NIC overview exceed the normal page width
> > because of the large number of drivers.
> > 
> > A CSS trick is added to allow displaying this page in the full width
> > of the browser window.
> > 
> > Signed-off-by: Thomas Monjalon 
> >
> 
> This makes the feature table wider, so all table can fit, and scroll bar
> below the table is gone, this is good.
> 
> But also it makes all paragraphs and 'Note' boxes in that page fill all
> the screen, and with a wide screen this becomes a long box through end
> of the screen and personally I think doesn't look nice.
> 
> Instead of making it full screen, is there are way to make it fixed
> size, but larger than previous so that table still can expand fully?

We may try to restrict non-table containers, but then it will be less generic.
I mean this solution could apply to any large page today.

We may try to force the width of  and .

Re: [PATCH] doc: announce cryptodev changes to offload RSA in VirtIO

[Thomas Monjalon]

30/07/2024 16:39, Gowrishankar Muthukrishnan:
> Hi,
> We need to fix padding info in DPDK as per VirtIO specification in order to 
> support RSA in virtio devices. VirtIO-crypto specification and DPDK 
> specification differs in the way padding is handled.
> With current DPDK & virtio specification, it is impossible to support RSA in 
> virtio-crypto. If you think DPDK spec should not be modified, we will try to 
> amend the virtIO spec to match DPDK, but since we do not know if the virtIO 
> community would accept, can we merge the deprecation notice?

There is a long list of Cc but I see no support outside of Marvell.



> >>> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from
> >>> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,
> >>> +  breaking ABI. The new location is recommended to comply with
> >>> +  virtio-crypto specification. Applications and drivers using
> >>> +  this struct will be updated.
> >>> +
> 
> 
> >> The problem here, I see is that there is one private key but multiple 
> >> combinations of padding.
> >> Therefore, for every padding variation, we need to copy the same private 
> >> key anew, duplicating it in memory.
> >> The only reason for me to keep a session-like struct in asymmetric crypto 
> >> was exactly this.
> > 
> > Each padding scheme in RSA has its own pros and cons (in terms of 
> > implementations as well).
> > When we share the same private key for Sign (and its public key in case of 
> > Encryption) between
> > multiple crypto ops (varying by padding schemes among cops), a vulnerable 
> > attack against one scheme
> > could potentially open door to used private key in the session and hence 
> > take advantage
> > on other crypto operations.
> > 
> > I think, this could be one reason for why VirtIO spec mandates padding info 
> > as session parameter.
> > Hence, more than duplicating in memory, private and public keys are secured 
> > and in catastrophe,
> > only that session could be destroyed.
> 
> 
> >>> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key
> >>> +  in either exponent or quintuple format is changed from union to
> >>> +struct
> >>> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix 
> >>> A.1.2).
> >>> +  This change will not break existing applications.
> > >
> > > This one I agree. RFC 8017 obsoletes RFC 3447.

Re: [PATCH] doc: announce change in crypto queue setup

[Ji, Kai]

Acked-by: Kai Ji 

From: Akhil Goyal 
Sent: 31 July 2024 12:20
To: dev@dpdk.org 
Cc: tho...@monjalon.net ; Marchand, David 
; hemant.agra...@nxp.com ; 
ano...@marvell.com ; De Lara Guarch, Pablo 
; Trahe, Fiona ; 
Doherty, Declan ; ma...@nvidia.com 
; g.si...@nxp.com ; fanzhang@gmail.com 
; jianjay.z...@huawei.com ; 
asoma...@amd.com ; ruifeng.w...@arm.com 
; konstantin.v.anan...@yandex.ru 
; Nicolau, Radu ; 
ajit.khapa...@broadcom.com ; 
rnagadhee...@marvell.com ; adwiv...@marvell.com 
; ciara.po...@intel.com ; Akhil 
Goyal 
Subject: [PATCH] doc: announce change in crypto queue setup

Certain hardware crypto PMDs may support setting up
of priority to a queue pair.
Hence a new parameter for priority will be added in
struct rte_cryptodev_qp_conf.

Signed-off-by: Akhil Goyal 
---
 doc/guides/rel_notes/deprecation.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 6948641ff6..4d114cec3e 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -125,6 +125,9 @@ Deprecation Notices
   This will effect the KASUMI, SNOW3G, ZUC, AESNI GCM, AESNI MB and CHACHAPOLY
   SW PMDs.

+* cryptodev: The structure ``rte_cryptodev_qp_conf`` will be updated to have
+  a new parameter to set priority of that particular queue pair.
+
 * eventdev: The single-event (non-burst) enqueue and dequeue operations,
   used by static inline burst enqueue and dequeue functions in 
``rte_eventdev.h``,
   will be removed in DPDK 23.11.
--
2.25.1

Issue in testpmd when using RSS Flows with Mellanox NICs

[Alex Chapman]

Hello maintainers,

I am currently facing issues when creating RSS flows using testpmd.
When using the following flow on an intel NIC, it works as expected,
using the reta table to redirect ipv4-udp packets to the correct queue.

   flow create 0 ingress pattern eth / ipv4 / udp / end actions rss types
ipv4-udp end queues end func toeplitz / end

However when executing the same command on a Mellanox NIC, the following
error occurs.

Caught PMD error type 15 (action configuration): No queues
configured: Invalid argument

This error can be resolved by manually specifying the queues used:

flow create 0 ingress pattern eth / ipv4 / udp / end actions rss
types ipv4-udp end queues 0 1 2 3 4 5 6 7 8 end func toeplitz / end

However the packets are not placed into their expected queues using the
reta table.

When looking through the Generic flow API guide under RSS
(https://doc.dpdk.org/guides/prog_guide/rte_flow.html), the attribute
queues does not exist.
From my understanding this seems to be a mistake, as the attribute
"queue" does exist with the definition "queue indices to use"
However when attempting to use this attribute I get the error "Bad
arguments"

If anyone is able to shed some light on the use of RSS in flows, that
would be greatly appreciated.

Thanks,
Alex
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH] doc: announce cryptodev change to support EDDSA

[Thomas Monjalon]

25/07/2024 17:01, Kusztal, ArkadiuszX:
> > Announce the additions in cryptodev ABI to support EDDSA algorithm.
> > 
> > Signed-off-by: Gowrishankar Muthukrishnan 
> 
> Acked-by: Arkadiusz Kusztal 

Acked-by: Anoob Joseph 
Acked-by: Akhil Goyal 

Applied, thanks.

It means we are not able to add an algo without breaking ABI.
Is it something we can improve?

Re: Issue in testpmd when using RSS Flows with Mellanox NICs

[Thomas Monjalon]

Hello,

31/07/2024 14:55, Alex Chapman:
> Hello maintainers,

Do not hesitate to read the file MAINTAINERS to place the appropriate Cc list.
Adding mlx5 maintainers.


> I am currently facing issues when creating RSS flows using testpmd.
> When using the following flow on an intel NIC, it works as expected,
> using the reta table to redirect ipv4-udp packets to the correct queue.
> 
> flow create 0 ingress pattern eth / ipv4 / udp / end actions rss types
> ipv4-udp end queues end func toeplitz / end
> 
> However when executing the same command on a Mellanox NIC, the following
> error occurs.
> 
>  Caught PMD error type 15 (action configuration): No queues
> configured: Invalid argument
> 
> This error can be resolved by manually specifying the queues used:
> 
>  flow create 0 ingress pattern eth / ipv4 / udp / end actions rss
> types ipv4-udp end queues 0 1 2 3 4 5 6 7 8 end func toeplitz / end
> 
> However the packets are not placed into their expected queues using the
> reta table.
> 
> When looking through the Generic flow API guide under RSS
> (https://doc.dpdk.org/guides/prog_guide/rte_flow.html), the attribute
> queues does not exist.
>  From my understanding this seems to be a mistake, as the attribute
> "queue" does exist with the definition "queue indices to use"
> However when attempting to use this attribute I get the error "Bad
> arguments"
> 
> If anyone is able to shed some light on the use of RSS in flows, that
> would be greatly appreciated.
> 
> Thanks,
> Alex

Re: [PATCH v2] net/gve: Fix TX/RX queue setup and stop

[Ferruh Yigit]

On 7/31/2024 6:26 AM, Tathagat Priyadarshi wrote:
> The PR aims to update the TX/RQ queue setup/stop routines that are
> unique to DQO, so that they may be called for instances that use the
> DQO RDA format during dev start/stop
> 
> Fixes: b044845 ("net/gve: support queue start/stop")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Tathagat Priyadarshi 
>

Moving Joshua's ack from other thread:

Acked-by: Joshua Washington 

Applied to dpdk-next-net/main, thanks.


Please note, although I applied the fix to the next-net, probably it
won't able to make the v23.07 release, as we are already post -rc4
phase. In that case patch will be merged to main repo for next release.


And a few other operational notes:
- I have updated patch title and commit log slightly, please check the
updates. For next contribution, please run the
'./devtools/check-git-log.sh' tool

- Sending a new version of the patch, with same version tag is
confusing, also it will be confusing when tracing back from commit to
the mail list / patchwork later. So please increase version tag when a
new version sent.


Thanks,
ferruh

Re: [PATCH] doc: announce change in crypto queue setup

[Thomas Monjalon]

31/07/2024 13:25, Anoob Joseph:
> > 
> > Certain hardware crypto PMDs may support setting up of priority to a queue
> > pair.
> > Hence a new parameter for priority will be added in struct
> > rte_cryptodev_qp_conf.
> > 
> > Signed-off-by: Akhil Goyal 
> 
> Acked-by: Anoob Joseph 

Acked-by: Hemant Agrawal 
Acked-by: Kai Ji 

Applied, thanks.

[PATCH] virtio: optimize stats counters performance

[Morten Brørup]

Optimized the performance of updating the virtio statistics counters by
reducing the number of branches and inlining the function.

Ordered the packet size comparisons according to the probability with
typical internet traffic mix.

Signed-off-by: Morten Brørup 
---
 drivers/net/virtio/virtio_rxtx.c | 34 
 drivers/net/virtio/virtio_rxtx.h | 26 ++--
 2 files changed, 24 insertions(+), 36 deletions(-)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index f69b9453a2..bb04fd7d43 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -81,40 +81,6 @@ vq_ring_free_chain(struct virtqueue *vq, uint16_t desc_idx)
dp->next = VQ_RING_DESC_CHAIN_END;
 }
 
-void
-virtio_update_packet_stats(struct virtnet_stats *stats, struct rte_mbuf *mbuf)
-{
-   uint32_t s = mbuf->pkt_len;
-   struct rte_ether_addr *ea;
-
-   stats->bytes += s;
-
-   if (s == 64) {
-   stats->size_bins[1]++;
-   } else if (s > 64 && s < 1024) {
-   uint32_t bin;
-
-   /* count zeros, and offset into correct bin */
-   bin = (sizeof(s) * 8) - rte_clz32(s) - 5;
-   stats->size_bins[bin]++;
-   } else {
-   if (s < 64)
-   stats->size_bins[0]++;
-   else if (s < 1519)
-   stats->size_bins[6]++;
-   else
-   stats->size_bins[7]++;
-   }
-
-   ea = rte_pktmbuf_mtod(mbuf, struct rte_ether_addr *);
-   if (rte_is_multicast_ether_addr(ea)) {
-   if (rte_is_broadcast_ether_addr(ea))
-   stats->broadcast++;
-   else
-   stats->multicast++;
-   }
-}
-
 static inline void
 virtio_rx_stats_updated(struct virtnet_rx *rxvq, struct rte_mbuf *m)
 {
diff --git a/drivers/net/virtio/virtio_rxtx.h b/drivers/net/virtio/virtio_rxtx.h
index afc4b74534..6f048199d3 100644
--- a/drivers/net/virtio/virtio_rxtx.h
+++ b/drivers/net/virtio/virtio_rxtx.h
@@ -35,7 +35,29 @@ struct virtnet_tx {
 };
 
 int virtio_rxq_vec_setup(struct virtnet_rx *rxvq);
-void virtio_update_packet_stats(struct virtnet_stats *stats,
-   struct rte_mbuf *mbuf);
+
+static inline void
+virtio_update_packet_stats(struct virtnet_stats *const stats, const struct 
rte_mbuf *const mbuf)
+{
+   uint32_t s = mbuf->pkt_len;
+   const struct rte_ether_addr *const ea = rte_pktmbuf_mtod(mbuf, const 
struct rte_ether_addr *);
+
+   stats->bytes += s;
+
+   if (s >= 1024) {
+   stats->size_bins[6 + (s > 1518)]++;
+   } else if (s <= 64) {
+   stats->size_bins[s >> 6]++;
+   } else {
+   /* count zeros, and offset into correct bin */
+   uint32_t bin = (sizeof(s) * 8) - rte_clz32(s) - 5;
+   stats->size_bins[bin]++;
+   }
+
+   RTE_BUILD_BUG_ON(offsetof(struct virtnet_stats, broadcast) !=
+   offsetof(struct virtnet_stats, multicast) + 
sizeof(uint64_t));
+   if (rte_is_multicast_ether_addr(ea))
+   (&stats->multicast)[rte_is_broadcast_ether_addr(ea)]++;
+}
 
 #endif /* _VIRTIO_RXTX_H_ */
-- 
2.43.0

Re: [PATCH v3] doc: announce rte_ipsec API changes

[Thomas Monjalon]

29/07/2024 13:53, Akhil Goyal:
> > Subject: [PATCH v3] doc: announce rte_ipsec API changes
> > 
> > In case of event mode operations where event device can help in atomic
> > sequence number increment across cores, sequence number need to be
> > provided by the application instead of being updated in rte_ipsec or the
> > PMD.
> > 
> > To support this, two new APIs rte_ipsec_pkt_crypto_sqn_assign and
> > rte_ipsec_pkt_crypto_xprepare are introduced decoupling the seq no update
> > functionality from the existing rte_ipsec_pkt_crypto_prepare API.
> > Additionally, a new flag ``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE`` will be
> > added to allow disabling of internal sequence number update inside IPsec
> > library.
> > 
> > Signed-off-by: Aakash Sasidharan 
> Acked-by: Akhil Goyal 

Acked-by: Konstantin Ananyev 
Acked-by: Radu Nicolau 

Applied, thanks.

[RFC PATCH v3 0/1] Add Visual Studio Code configuration script

[Anatoly Burakov]

Lots of developers (myself included) uses Visual Studio Code as their primary
IDE for DPDK development. I have been successfully using various incarnations of
this script internally to quickly set up my development trees whenever I need a
new configuration, so this script is being shared in hopes that it will be
useful both to new developers starting with DPDK, and to seasoned DPDK
developers who are already using Visual Studio Code. It makes starting working
on DPDK in Visual Studio Code so much easier!

** NOTE: Currently, only x86 configuration is generated as I have no way to test
   the code analysis configuration on any other platforms.

** NOTE 2: this is not for *Visual Studio* the Windows IDE, this is for *Visual
   Studio Code* the cross-platform code editor. Specifically, main target
   audience for this script is people who either run DPDK directly on their
   Linux machine, or who use Remote SSH functionality to connect to a remote
   Linux machine and set up VSCode build there. No other OS's are currently
   supported by the script.

(if you're unaware of what is Remote SSH, I highly suggest checking it out [1])

Philosophy behind this script is as follows:

- Any build directory created will automatically add itself to VSCode
  configuration (ignore mechanism for e.g. test-meson-build.sh is WIP)

- Launch configuration is created using `which gdb`, so by default non-root
  users will have to do additional system configuration for things to work

- All of the interactive stuff has now been taken out and is planned to be
  included in a separate set of scripts, so this script now concerns itself only
  with adding build/launch targets to user's configuration and not much else

Please feel free to make any suggestions!

[1] https://code.visualstudio.com/docs/remote/ssh

Anatoly Burakov (1):
  buildtools: add vscode configuration generator

 app/meson.build   |  12 +-
 buildtools/gen-vscode-conf.py | 442 ++
 buildtools/meson.build|   5 +
 examples/meson.build  |  13 +-
 meson.build   |  11 +
 5 files changed, 481 insertions(+), 2 deletions(-)
 create mode 100755 buildtools/gen-vscode-conf.py

-- 
2.43.5

[RFC PATCH v3 1/1] buildtools: add vscode configuration generator

[Anatoly Burakov]

A lot of developers use Visual Studio Code as their primary IDE. This
script will be called from within meson build process, and will generate
a configuration file for VSCode that sets up basic build tasks, launch
tasks, as well as C/C++ code analysis settings that will take into
account compile_commands.json that is automatically generated by meson.

Files generated by script:
 - .vscode/settings.json: stores variables needed by other files
 - .vscode/tasks.json: defines build tasks
 - .vscode/launch.json: defines launch tasks
 - .vscode/c_cpp_properties.json: defines code analysis settings

Multiple, as well as out-of-source-tree, build directories are supported,
and the script will generate separate configuration items for each build
directory created by user, tagging them for convenience.

Signed-off-by: Anatoly Burakov 
---

Notes:
RFCv3 -> RFCv2:
- Following feedback from Bruce, reworked to be minimal script run from 
meson
- Moved to buildtools
- Support for multiple build directories is now the default
- All targets are automatically added to all configuration files

RFCv1 -> RFCv2:

- No longer disable apps and drivers if nothing was specified via command 
line
  or TUI, and warn user about things being built by default
- Generate app launch configuration by default for when no apps are selected
- Added paramters:
  - --force to avoid overwriting existing config
  - --common-conf to specify global meson flags applicable to all configs
  - --gdbsudo/--no-gdbsudo to specify gdbsudo behavior
- Autodetect gdbsudo/gdb from UID
- Updated comments, error messages, fixed issues with user interaction
- Improved handling of wildcards and driver dependencies
- Fixed a few bugs in dependency detection due to incorrect parsing
- [Stephen] flake8 is happy

 app/meson.build   |  12 +-
 buildtools/gen-vscode-conf.py | 442 ++
 buildtools/meson.build|   5 +
 examples/meson.build  |  13 +-
 meson.build   |  11 +
 5 files changed, 481 insertions(+), 2 deletions(-)
 create mode 100755 buildtools/gen-vscode-conf.py

diff --git a/app/meson.build b/app/meson.build
index 5b2c80c7a1..cf0eda3d5f 100644
--- a/app/meson.build
+++ b/app/meson.build
@@ -114,7 +114,17 @@ foreach app:apps
 link_libs = dpdk_static_libraries + dpdk_drivers
 endif
 
-exec = executable('dpdk-' + name,
+# add to Visual Studio Code launch configuration
+exe_name = 'dpdk-' + name
+launch_path = join_paths(meson.current_build_dir(), exe_name)
+# we don't want to block the build if this command fails
+result = run_command(vscode_conf_gen_cmd + ['--launch', launch_path], 
check: false)
+if result.returncode() != 0
+warning('Failed to generate Visual Studio Code launch configuration 
for "' + name + '"')
+message(result.stderr())
+endif
+
+exec = executable(exe_name,
 sources,
 c_args: cflags,
 link_args: ldflags,
diff --git a/buildtools/gen-vscode-conf.py b/buildtools/gen-vscode-conf.py
new file mode 100755
index 00..fcc6469065
--- /dev/null
+++ b/buildtools/gen-vscode-conf.py
@@ -0,0 +1,442 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2024 Intel Corporation
+#
+
+"""Visual Studio Code configuration generator script."""
+
+# This script is meant to be run by meson build system to generate build and
+# launch commands for a specific build directory for Visual Studio Code IDE.
+#
+# Even though this script will generate settings/tasks/launch/code analysis
+# configuration for VSCode, we can't actually just regenerate the files,
+# because we want to support multiple build directories, as well as not
+# destroy any configuration user has created between runs of this script.
+# Therefore, we need some config file handling infrastructure. Luckily, VSCode
+# configs are all JSON, so we can just use json module to handle them. Of
+# course, we will lose any user comments in the files, but that's a small price
+# to pay for this sort of automation.
+#
+# Since this script will be run by meson, we can forego any parsing or anything
+# to do with the build system, and just rely on the fact that we get all of our
+# configuration from command-line.
+
+import argparse
+import ast
+import json
+import os
+import shutil
+from collections import OrderedDict
+from sys import stderr, exit as _exit
+from typing import List, Dict, Any
+
+
+class ConfigCtx:
+"""POD class to keep data associated with config."""
+def __init__(self, build_dir: str, source_dir: str, launch: List[str]):
+self.build_dir = build_dir
+self.source_dir = source_dir
+self.config_dir = os.path.join(source_dir, '.vscode')
+# we don't have any mechanism to label things, so we're just going to
+# use build dir basename as the label, and hope user doesn't create
+

Re: [PATCH v1 2/3] dts: add dual_vlan testing suite

[Jeremy Spewock]

On Thu, Jul 25, 2024 at 9:56 AM Jeremy Spewock  wrote:
>
> On Mon, Jul 22, 2024 at 1:38 PM Dean Marx  wrote:
> >>
> >> 
> >> +recv = self.send_packet_and_capture(pakt)
> >> +self.verify(len(recv) > 0, "Did not receive and packets when 
> >> testing VLAN priority.")
> >
> >
> > I'm assuming this should say "any" instead of "and." Other than that, 
> > everything looks good to me.
> >
>
> Good catch, I'll fix this in the next version.

Circling back on this, it looks like this is fixed in the current version.

>
> > Reviewed-by: Dean Marx 

[PATCH v2] virtio: optimize stats counters performance

[Morten Brørup]

Optimized the performance of updating the virtio statistics counters by
reducing the number of branches and inlining the function.

Ordered the packet size comparisons according to the probability with
typical internet traffic mix.

Signed-off-by: Morten Brørup 
---
v2:
* Fixed checkpatch warning about line length.
---
 drivers/net/virtio/virtio_rxtx.c | 34 
 drivers/net/virtio/virtio_rxtx.h | 26 ++--
 2 files changed, 24 insertions(+), 36 deletions(-)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index f69b9453a2..bb04fd7d43 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -81,40 +81,6 @@ vq_ring_free_chain(struct virtqueue *vq, uint16_t desc_idx)
dp->next = VQ_RING_DESC_CHAIN_END;
 }
 
-void
-virtio_update_packet_stats(struct virtnet_stats *stats, struct rte_mbuf *mbuf)
-{
-   uint32_t s = mbuf->pkt_len;
-   struct rte_ether_addr *ea;
-
-   stats->bytes += s;
-
-   if (s == 64) {
-   stats->size_bins[1]++;
-   } else if (s > 64 && s < 1024) {
-   uint32_t bin;
-
-   /* count zeros, and offset into correct bin */
-   bin = (sizeof(s) * 8) - rte_clz32(s) - 5;
-   stats->size_bins[bin]++;
-   } else {
-   if (s < 64)
-   stats->size_bins[0]++;
-   else if (s < 1519)
-   stats->size_bins[6]++;
-   else
-   stats->size_bins[7]++;
-   }
-
-   ea = rte_pktmbuf_mtod(mbuf, struct rte_ether_addr *);
-   if (rte_is_multicast_ether_addr(ea)) {
-   if (rte_is_broadcast_ether_addr(ea))
-   stats->broadcast++;
-   else
-   stats->multicast++;
-   }
-}
-
 static inline void
 virtio_rx_stats_updated(struct virtnet_rx *rxvq, struct rte_mbuf *m)
 {
diff --git a/drivers/net/virtio/virtio_rxtx.h b/drivers/net/virtio/virtio_rxtx.h
index afc4b74534..81325ed842 100644
--- a/drivers/net/virtio/virtio_rxtx.h
+++ b/drivers/net/virtio/virtio_rxtx.h
@@ -35,7 +35,29 @@ struct virtnet_tx {
 };
 
 int virtio_rxq_vec_setup(struct virtnet_rx *rxvq);
-void virtio_update_packet_stats(struct virtnet_stats *stats,
-   struct rte_mbuf *mbuf);
+
+static inline void
+virtio_update_packet_stats(struct virtnet_stats *const stats, const struct 
rte_mbuf *const mbuf)
+{
+   uint32_t s = mbuf->pkt_len;
+   const struct rte_ether_addr *ea = rte_pktmbuf_mtod(mbuf, const struct 
rte_ether_addr *);
+
+   stats->bytes += s;
+
+   if (s >= 1024) {
+   stats->size_bins[6 + (s > 1518)]++;
+   } else if (s <= 64) {
+   stats->size_bins[s >> 6]++;
+   } else {
+   /* count zeros, and offset into correct bin */
+   uint32_t bin = (sizeof(s) * 8) - rte_clz32(s) - 5;
+   stats->size_bins[bin]++;
+   }
+
+   RTE_BUILD_BUG_ON(offsetof(struct virtnet_stats, broadcast) !=
+   offsetof(struct virtnet_stats, multicast) + 
sizeof(uint64_t));
+   if (rte_is_multicast_ether_addr(ea))
+   (&stats->multicast)[rte_is_broadcast_ether_addr(ea)]++;
+}
 
 #endif /* _VIRTIO_RXTX_H_ */
-- 
2.43.0

Re: [PATCH] doc: announce cryptodev changes to offload RSA in VirtIO

[Thomas Monjalon]

I'm not sure why we don't have a consensus on an idea proposed as RFC in 
September 2023.

Because there is not enough involvement outside of the Marvell team,
I will keep a vague announce for the first item:

cryptodev: Some changes may happen to manage RSA padding for virtio-crypto.

The second item is applied verbatim, thanks.


31/07/2024 14:51, Thomas Monjalon:
> 30/07/2024 16:39, Gowrishankar Muthukrishnan:
> > Hi,
> > We need to fix padding info in DPDK as per VirtIO specification in order to 
> > support RSA in virtio devices. VirtIO-crypto specification and DPDK 
> > specification differs in the way padding is handled.
> > With current DPDK & virtio specification, it is impossible to support RSA 
> > in virtio-crypto. If you think DPDK spec should not be modified, we will 
> > try to amend the virtIO spec to match DPDK, but since we do not know if the 
> > virtIO community would accept, can we merge the deprecation notice?
> 
> There is a long list of Cc but I see no support outside of Marvell.
> 
> 
> 
> > >>> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from
> > >>> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,
> > >>> +  breaking ABI. The new location is recommended to comply with
> > >>> +  virtio-crypto specification. Applications and drivers using
> > >>> +  this struct will be updated.
> > >>> +
> > 
> > 
> > >> The problem here, I see is that there is one private key but multiple 
> > >> combinations of padding.
> > >> Therefore, for every padding variation, we need to copy the same private 
> > >> key anew, duplicating it in memory.
> > >> The only reason for me to keep a session-like struct in asymmetric 
> > >> crypto was exactly this.
> > > 
> > > Each padding scheme in RSA has its own pros and cons (in terms of 
> > > implementations as well).
> > > When we share the same private key for Sign (and its public key in case 
> > > of Encryption) between
> > > multiple crypto ops (varying by padding schemes among cops), a vulnerable 
> > > attack against one scheme
> > > could potentially open door to used private key in the session and hence 
> > > take advantage
> > > on other crypto operations.
> > > 
> > > I think, this could be one reason for why VirtIO spec mandates padding 
> > > info as session parameter.
> > > Hence, more than duplicating in memory, private and public keys are 
> > > secured and in catastrophe,
> > > only that session could be destroyed.
> > 
> > 
> > >>> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key
> > >>> +  in either exponent or quintuple format is changed from union to
> > >>> +struct
> > >>> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix 
> > >>> A.1.2).
> > >>> +  This change will not break existing applications.
> > > >
> > > > This one I agree. RFC 8017 obsoletes RFC 3447.

Re: [PATCH] doc: announce fib configuration structure changes

[Thomas Monjalon]

31/07/2024 13:08, Bruce Richardson:
> On Wed, Jul 31, 2024 at 01:03:11PM +0200, Thomas Monjalon wrote:
> > 26/07/2024 18:36, Robin Jarry:
> > > Vladimir Medvedkin, Jul 26, 2024 at 18:13:
> > > > Announce addition of the flags field into rte_fib_conf structure.
> > > >
> > > > Signed-off-by: Vladimir Medvedkin 
> > > 
> > > Acked-by: Robin Jarry 
> > 
> Acked-by: Bruce Richardson 

Acked-by: Thomas Monjalon 

Applied, thanks.

fib/rib: allow storing void * instead of nexthop index

[Robin Jarry]

Hi Vladimir,

I noticed that the fib/rib APIs (both IPv4 and IPv6) require the next 
hops to be represented as integer indexes. Reading the code, I noticed 
that they are stored as uint64_t with the MSB used for internal 
purposes.


This require either having a contiguous array of nexthop objects and 
choose an index in that array, or store pointer offsets as nexthop 
indexes and do pointer arithmetics to reconstruct the real pointers. 
Both are not very practical and/or hacky.


Would it be possible to store arbitrary pointers? That would mean 
moving that 64th bit information elsewhere.


I'd love to hear what you think on the matter.

Cheers,
Robin

[PATCH v3] virtio: optimize stats counters performance

[Morten Brørup]

Optimized the performance of updating the virtio statistics counters by
reducing the number of branches and inlining the function.

Ordered the packet size comparisons according to the probability with
typical internet traffic mix.

Signed-off-by: Morten Brørup 
---
v3:
* Eliminated a local variable.
* Note: Substituted sizeof(uint32_t)*4 by 32UL, using unsigned long type
  to keep optimal offsetting in generated assembler output.
* Removed unnecessary curly braces.
v2:
* Fixed checkpatch warning about line length.
---
 drivers/net/virtio/virtio_rxtx.c | 34 
 drivers/net/virtio/virtio_rxtx.h | 23 +++--
 2 files changed, 21 insertions(+), 36 deletions(-)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index f69b9453a2..bb04fd7d43 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -81,40 +81,6 @@ vq_ring_free_chain(struct virtqueue *vq, uint16_t desc_idx)
dp->next = VQ_RING_DESC_CHAIN_END;
 }
 
-void
-virtio_update_packet_stats(struct virtnet_stats *stats, struct rte_mbuf *mbuf)
-{
-   uint32_t s = mbuf->pkt_len;
-   struct rte_ether_addr *ea;
-
-   stats->bytes += s;
-
-   if (s == 64) {
-   stats->size_bins[1]++;
-   } else if (s > 64 && s < 1024) {
-   uint32_t bin;
-
-   /* count zeros, and offset into correct bin */
-   bin = (sizeof(s) * 8) - rte_clz32(s) - 5;
-   stats->size_bins[bin]++;
-   } else {
-   if (s < 64)
-   stats->size_bins[0]++;
-   else if (s < 1519)
-   stats->size_bins[6]++;
-   else
-   stats->size_bins[7]++;
-   }
-
-   ea = rte_pktmbuf_mtod(mbuf, struct rte_ether_addr *);
-   if (rte_is_multicast_ether_addr(ea)) {
-   if (rte_is_broadcast_ether_addr(ea))
-   stats->broadcast++;
-   else
-   stats->multicast++;
-   }
-}
-
 static inline void
 virtio_rx_stats_updated(struct virtnet_rx *rxvq, struct rte_mbuf *m)
 {
diff --git a/drivers/net/virtio/virtio_rxtx.h b/drivers/net/virtio/virtio_rxtx.h
index afc4b74534..bcd552b907 100644
--- a/drivers/net/virtio/virtio_rxtx.h
+++ b/drivers/net/virtio/virtio_rxtx.h
@@ -35,7 +35,26 @@ struct virtnet_tx {
 };
 
 int virtio_rxq_vec_setup(struct virtnet_rx *rxvq);
-void virtio_update_packet_stats(struct virtnet_stats *stats,
-   struct rte_mbuf *mbuf);
+
+static inline void
+virtio_update_packet_stats(struct virtnet_stats *const stats, const struct 
rte_mbuf *const mbuf)
+{
+   uint32_t s = mbuf->pkt_len;
+   const struct rte_ether_addr *ea = rte_pktmbuf_mtod(mbuf, const struct 
rte_ether_addr *);
+
+   stats->bytes += s;
+
+   if (s >= 1024)
+   stats->size_bins[6 + (s > 1518)]++;
+   else if (s <= 64)
+   stats->size_bins[s >> 6]++;
+   else
+   stats->size_bins[32UL - rte_clz32(s) - 5]++;
+
+   RTE_BUILD_BUG_ON(offsetof(struct virtnet_stats, broadcast) !=
+   offsetof(struct virtnet_stats, multicast) + 
sizeof(uint64_t));
+   if (rte_is_multicast_ether_addr(ea))
+   (&stats->multicast)[rte_is_broadcast_ether_addr(ea)]++;
+}
 
 #endif /* _VIRTIO_RXTX_H_ */
-- 
2.43.0

Re: fib/rib: allow storing void * instead of nexthop index

[Medvedkin, Vladimir]

Hi Robin,


On 31/07/2024 16:04, Robin Jarry wrote:

Hi Vladimir,

I noticed that the fib/rib APIs (both IPv4 and IPv6) require the next 
hops to be represented as integer indexes. Reading the code, I noticed 
that they are stored as uint64_t with the MSB used for internal purposes.


I believe you are asking about FIB, not RIB. In current FIB 
implementation 1 LSB is used for internal purposes.





This require either having a contiguous array of nexthop objects and 
choose an index in that array,


As far as I know that's what most of "l3 forward" applications (aka 
routers) are doing, if they are interested in performance. Not only DPDK 
powered.



or store pointer offsets as nexthop indexes and do pointer arithmetics 
to reconstruct the real pointers. Both are not very practical and/or 
hacky.


Would it be possible to store arbitrary pointers? That would mean 
moving that 64th bit information elsewhere.


For arbitrary pointer - no, since it needs to store 1 more bit for 
internal purpose. However, if you have 2 byte aligned pointer you can 
store the pointer shifted right by 1 bit, and after lookup just shift 
the result back.





I'd love to hear what you think on the matter.

Cheers,
Robin


--
Regards,
Vladimir

Re: [PATCH v2 2/2] doc: give full width to NIC overview page

[Thomas Monjalon]

31/07/2024 14:43, Thomas Monjalon:
> 31/07/2024 13:29, Ferruh Yigit:
> > On 7/31/2024 9:31 AM, Thomas Monjalon wrote:
> > > The wide tables in the NIC overview exceed the normal page width
> > > because of the large number of drivers.
> > > 
> > > A CSS trick is added to allow displaying this page in the full width
> > > of the browser window.
> > > 
> > > Signed-off-by: Thomas Monjalon 
> > >
> > 
> > This makes the feature table wider, so all table can fit, and scroll bar
> > below the table is gone, this is good.
> > 
> > But also it makes all paragraphs and 'Note' boxes in that page fill all
> > the screen, and with a wide screen this becomes a long box through end
> > of the screen and personally I think doesn't look nice.
> > 
> > Instead of making it full screen, is there are way to make it fixed
> > size, but larger than previous so that table still can expand fully?
> 
> We may try to restrict non-table containers, but then it will be less generic.
> I mean this solution could apply to any large page today.
> 
> We may try to force the width of  and .

I've found another trick to let only tables overflow.
I'll send a v3 and will apply quickly.

[PATCH v3 0/2] custom doc styling

[Thomas Monjalon]

The file custom.css allows to change the theme from "Read the Docs".
The first patch makes it available without "ninja install".
The second patch allows the NIC overview tables to be "fullscreen".

Thomas Monjalon (2):
  doc: copy custom CSS on guides build
  doc: give full width to NIC overview page

 buildtools/call-sphinx-build.py | 10 ++
 doc/guides/custom.css   | 13 +
 doc/guides/meson.build  |  2 --
 doc/guides/nics/overview.rst|  2 ++
 4 files changed, 25 insertions(+), 2 deletions(-)

-- 
2.45.0

[PATCH v3 1/2] doc: copy custom CSS on guides build

[Thomas Monjalon]

The custom CSS file for Sphinx guides was copied during install,
but not during build time.
Before switching to Meson, the Makefile was copying this file
in the build steps, so the doc was complete and viewable
from the build directory.

It is especially useful to get full documentation in the build directory
when building only documentation with "ninja -C build doc".
The command "ninja install" was required to get the CSS file installed,
but it requires to build the libraries as well.

The CSS file is now copied as part of the Sphinx build script,
and it will be installed as part of the whole html directory.

Signed-off-by: Thomas Monjalon 
Acked-by: Ferruh Yigit 
---
v2: create destination directory in case RtD theme is unavailable
v3: no change
---
 buildtools/call-sphinx-build.py | 10 ++
 doc/guides/meson.build  |  2 --
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/buildtools/call-sphinx-build.py b/buildtools/call-sphinx-build.py
index da19e950c9..623e7363ee 100755
--- a/buildtools/call-sphinx-build.py
+++ b/buildtools/call-sphinx-build.py
@@ -3,6 +3,8 @@
 # Copyright(c) 2019 Intel Corporation
 #
 
+import filecmp
+import shutil
 import sys
 import os
 from os.path import join
@@ -30,4 +32,12 @@
 with open(join(dst, '.html.d'), 'w') as d:
 d.write('html: ' + ' '.join(srcfiles) + '\n')
 
+# copy custom CSS file
+css = 'custom.css'
+src_css = join(src, css)
+dst_css = join(dst, 'html', '_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)
+
 sys.exit(process.returncode)
diff --git a/doc/guides/meson.build b/doc/guides/meson.build
index 51f81da2e3..f8bbfba9f5 100644
--- a/doc/guides/meson.build
+++ b/doc/guides/meson.build
@@ -24,7 +24,5 @@ html_guides = custom_target('html_guides',
 install: get_option('enable_docs'),
 install_dir: htmldir)
 
-install_data(files('custom.css'), install_dir: join_paths(htmldir,'_static', 
'css'))
-
 doc_targets += html_guides
 doc_target_names += 'HTML_Guides'
-- 
2.45.0

[PATCH v3 2/2] doc: give full width to NIC overview page

[Thomas Monjalon]

The wide tables in the NIC overview exceed the normal page width
because of the large number of drivers.

A CSS trick is added to allow displaying the tables in the full width
of the browser window.

Signed-off-by: Thomas Monjalon 
---
v2: no change
v3: let only tables to overflow on wide screen
---
 doc/guides/custom.css| 13 +
 doc/guides/nics/overview.rst |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/doc/guides/custom.css b/doc/guides/custom.css
index 221024655c..a8ee6bed2c 100644
--- a/doc/guides/custom.css
+++ b/doc/guides/custom.css
@@ -4,6 +4,19 @@
 
 /* Override readthedocs theme */
 
+/* Set full width for all responsive tables of a page.
+ * Usage: insert the following line in the doc.
+ *.. rst-class:: widepage
+ */
+@media screen and (min-width: 1100px) {
+.wy-nav-content-wrap:has(.widepage) {
+background: white !important;
+}
+.wy-nav-content:has(.widepage) .wy-table-responsive {
+overflow: visible !important;
+}
+}
+
 /* Spacing before a list item must be bigger than spacing inside the item.
  * Complex list items start with a p.first element. */
 .section li > .first {
diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index 67575c699c..4553076481 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -24,6 +24,8 @@ Most of these differences are summarized below.
 
 More details about features can be found in :doc:`features`.
 
+.. rst-class:: widepage
+
 .. _table_net_pmd_features:
 
 .. include:: overview_table.txt
-- 
2.45.0

Re: [PATCH v4] doc: announce changes to dma device structures

[Thomas Monjalon]

31/07/2024 13:01, Thomas Monjalon:
> 30/07/2024 19:27, Jerin Jacob:
> > On Tue, Jul 30, 2024 at 8:25 PM Amit Prakash Shukla
> >  wrote:
> > >
> > > A new flag RTE_DMA_CAPA_QOS will be introduced to advertise dma
> > > device's QoS capability. In order to support the parameters for this
> > > flag, new fields will be added in rte_dma_info and rte_dma_conf
> > > structures to get device supported priority levels and to configure the
> > > required priority level.
> > >
> > > Signed-off-by: Vamsi Attunuru 
> > > Signed-off-by: Amit Prakash Shukla 
> > 
> > 
> > Acked-by: Jerin Jacob 
> 
> Acked-by: Thomas Monjalon 

The RFC and the deprecation notices are sent a bit late.
We cannot conclude there is consensus.

I propose to raise it to the techboard if an ABI breakage is still required for 
24.11.
As dmadev is quite new, I don't think it is big issue.

Re: [PATCH v3 2/2] doc: give full width to NIC overview page

[Ferruh Yigit]

On 7/31/2024 4:57 PM, Thomas Monjalon wrote:
> The wide tables in the NIC overview exceed the normal page width
> because of the large number of drivers.
> 
> A CSS trick is added to allow displaying the tables in the full width
> of the browser window.
> 
> Signed-off-by: Thomas Monjalon 
> ---
> v2: no change
> v3: let only tables to overflow on wide screen
>

It is better, thanks. Now page boundaries are kept but table extended to
fit all columns.

You are improving front-end skills :)

Only color of the overview page is not white as it is in other pages,
but slight gray, is this intentional?

Re: [PATCH v3 2/2] doc: give full width to NIC overview page

[Thomas Monjalon]

31/07/2024 18:17, Ferruh Yigit:
> On 7/31/2024 4:57 PM, Thomas Monjalon wrote:
> > The wide tables in the NIC overview exceed the normal page width
> > because of the large number of drivers.
> > 
> > A CSS trick is added to allow displaying the tables in the full width
> > of the browser window.
> > 
> > Signed-off-by: Thomas Monjalon 
> > ---
> > v2: no change
> > v3: let only tables to overflow on wide screen
> >
> 
> It is better, thanks. Now page boundaries are kept but table extended to
> fit all columns.
> 
> You are improving front-end skills :)

Thanks, that's a fun skill to work on :)

> Only color of the overview page is not white as it is in other pages,
> but slight gray, is this intentional?

It seems all pages are not really white, but #fcfcfc.
I'll apply the same color for the whole background of the tables.

Re: [PATCH v3 0/2] custom doc styling

[Thomas Monjalon]

31/07/2024 17:57, Thomas Monjalon:
> The file custom.css allows to change the theme from "Read the Docs".
> The first patch makes it available without "ninja install".
> The second patch allows the NIC overview tables to be "fullscreen".
> 
> Thomas Monjalon (2):
>   doc: copy custom CSS on guides build
>   doc: give full width to NIC overview page

Applied with background color fixed.

Re: [PATCH v2] devtools: add acronyms in dictionary for commit checks

[Thomas Monjalon]

05/06/2024 18:59, Ferruh Yigit:
> ELF  -> Executable and Linkable Format
> Ethernet -> with an uppercase “E”
> mark -> 'mark' flow action, no need to capitalise
> max  -> maximum
> MDIO -> Management Data Input/Output
> MII  -> Media-Independent Interface
> XSK  -> XDP Socket. XDP (eXpress Data Path)
> 
> Signed-off-by: Ferruh Yigit 

Applied, thanks.

Re: [PATCH V2] doc: add tested Intel platforms with Intel NICs

[Thomas Monjalon]

30/07/2024 21:16, Mcnamara, John:
> 
> > -Original Message-
> > Subject: [PATCH V2] doc: add tested Intel platforms with Intel NICs
> 
> Acked-by: John McNamara 

Applied, thanks.

Re: [PATCH] doc: add tested platforms with NVIDIA NICs

[Thomas Monjalon]

31/07/2024 13:19, Raslan Darawsheh:
> Add tested platforms with NVIDIA NICs to the 24.07 release notes.
> 
> Signed-off-by: Raslan Darawsheh 

Applied, thanks.

[PATCH] net/gve : Update EOP bit in txd rte_mbuf chain

[Tathagat Priyadarshi]

The EOP bit was not set for all the packets in mbuf chain
causing packet transmission stalls for packets split across
mbuf in chain.

Signed-off-by: Tathagat Priyadarshi 
Signed-off-by: Varun Lakkur Ambaji Rao 

Fixes: 4022f99 ("net/gve: support basic Tx data path for DQO")
---
 drivers/net/gve/gve_tx_dqo.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/gve/gve_tx_dqo.c b/drivers/net/gve/gve_tx_dqo.c
index a65e6aa..579b8d6 100644
--- a/drivers/net/gve/gve_tx_dqo.c
+++ b/drivers/net/gve/gve_tx_dqo.c
@@ -126,6 +126,7 @@
txd->pkt.dtype = GVE_TX_PKT_DESC_DTYPE_DQO;
txd->pkt.compl_tag = rte_cpu_to_le_16(first_sw_id);
txd->pkt.buf_size = RTE_MIN(tx_pkt->data_len, 
GVE_TX_MAX_BUF_SIZE_DQO);
+   txd->pkt.end_of_packet = 0;
 
/* size of desc_ring and sw_ring could be different */
tx_id = (tx_id + 1) & mask;
-- 
1.8.3.1

Re: [PATCH v3 0/2] custom doc styling

[Ferruh Yigit]

On 7/31/2024 5:22 PM, Thomas Monjalon wrote:
> 31/07/2024 17:57, Thomas Monjalon:
>> The file custom.css allows to change the theme from "Read the Docs".
>> The first patch makes it available without "ninja install".
>> The second patch allows the NIC overview tables to be "fullscreen".
>>
>> Thomas Monjalon (2):
>>   doc: copy custom CSS on guides build
>>   doc: give full width to NIC overview page
> 
> Applied with background color fixed.
> 

You already applied, but let me give my explicit ack for record:

Acked-by: Ferruh Yigit 

Re: [PATCH v5 00/32] Introduce sssnic PMD for 3SNIC's 9x0 serials Ethernet adapters

[Thomas Monjalon]

29/03/2024 12:32, Ferruh Yigit:
> On 9/26/2023 2:13 PM, Ferruh Yigit wrote:
> > On 9/4/2023 5:56 AM, wa...@3snic.com wrote:
> >> From: Renyong Wan 
> >>
> >> The sssnic PMD (**librte_pmd_sssnic**) provides poll mode driver support
> >> for 3SNIC 9x0 serials family of Ethernet adapters.
> >>
> >> Supported NICs are:
> >>
> >> - 3S910 Dual Port SFP28 10/25GbE Ethernet adapter
> >> - 3S920 Quad Port SFP28 10/25GbE Ethernet adapter
> >> - 3S920 Quad Port QSFP28 100GbE Ethernet adapter
> >
> > Hi Renyong,
> > 
> > Driver mostly looks good, I did put some minor comments, I guess driver
> > can be merged soon with those issues addressed.
> > 
> > Also agree on Stephen's comments, if you apply them in next version,
> > please feel free to keep Stephen's ack in next version.
> 
> Hi Renyong,
> 
> v5 was almost there, will there be a new version for the v24.07?

I still expect some news for integration in 24.11.

[PATCH v3 1/3] buildtools: add helper to convert text file to header

[Stephen Hemminger]

Simple script to read a file and make it into a initialized
C string in a header file.

Signed-off-by: Stephen Hemminger 
---
 buildtools/gen-header.py | 36 
 buildtools/meson.build   |  2 +-
 2 files changed, 37 insertions(+), 1 deletion(-)
 create mode 100644 buildtools/gen-header.py

diff --git a/buildtools/gen-header.py b/buildtools/gen-header.py
new file mode 100644
index 00..06e645863c
--- /dev/null
+++ b/buildtools/gen-header.py
@@ -0,0 +1,36 @@
+#! /usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright (c) 2023 Stephen Hemminger 
+
+"""
+Script to read a text file and convert it into a header file.
+"""
+import sys
+import os
+
+
+def main():
+'''program main function'''
+print(f'/* File autogenerated by {sys.argv[0]} */')
+for path in sys.argv[1:]:
+name = os.path.basename(path)
+print()
+print(f'/* generated from {name} */')
+with open(path, "r") as f:
+array = name.replace(".", "_")
+print(f'static const char {array}[] = ' + '{')
+line = f.readline()
+
+# make sure empty string is null terminated
+if not line:
+print('""')
+
+while line:
+s = repr(line)
+print('{}'.format(s.replace("'", '"')))
+line = f.readline()
+print('};')
+
+
+if __name__ == "__main__":
+main()
diff --git a/buildtools/meson.build b/buildtools/meson.build
index 3adf34e1a8..bc818a71d5 100644
--- a/buildtools/meson.build
+++ b/buildtools/meson.build
@@ -24,6 +24,7 @@ get_numa_count_cmd = py3 + files('get-numa-count.py')
 get_test_suites_cmd = py3 + files('get-test-suites.py')
 has_hugepages_cmd = py3 + files('has-hugepages.py')
 cmdline_gen_cmd = py3 + files('dpdk-cmdline-gen.py')
+header_gen_cmd = py3 + files('gen-header.py')
 
 # install any build tools that end-users might want also
 install_data([
@@ -48,4 +49,3 @@ else
 pmdinfo += 'ar'
 pmdinfogen += 'elf'
 endif
-
-- 
2.43.0

[PATCH v3 0/3] restore lost tests for rte_cfgfile

[Stephen Hemminger]

The cfgfile tests did not get built since conversion to meson
and they used an awkward way to manage the test data.

This patchset converts the tests to use a helper to take
text file and make it into a C header. Then use the C header
to generate temporary files as needed.

v3 - change creation of temp file to support Windows

Stephen Hemminger (3):
  buildtools: add helper to convert text file to header
  test: remove unused resource API
  test: restore cfgfile tests

 app/meson.build|   3 +-
 app/test/meson.build   |   8 +-
 app/test/resource.c| 276 -
 app/test/resource.h| 106 ---
 app/test/test_cfgfile.c| 153 ++--
 app/test/test_cfgfiles/meson.build |  19 ++
 app/test/test_resource.c   | 104 ---
 buildtools/gen-header.py   |  36 
 buildtools/meson.build |   2 +-
 9 files changed, 166 insertions(+), 541 deletions(-)
 delete mode 100644 app/test/resource.c
 delete mode 100644 app/test/resource.h
 create mode 100644 app/test/test_cfgfiles/meson.build
 delete mode 100644 app/test/test_resource.c
 create mode 100644 buildtools/gen-header.py

-- 
2.43.0

[PATCH v3 2/3] test: remove unused resource API

[Stephen Hemminger]

This API was used only for cfgfile tests and was never built
after the conversion to meson. Will be replaced by simpler
method of doing cfgfile tests.

Signed-off-by: Stephen Hemminger 
---
 app/test/meson.build |   2 -
 app/test/resource.c  | 276 ---
 app/test/resource.h  | 106 ---
 app/test/test_resource.c | 104 ---
 4 files changed, 488 deletions(-)
 delete mode 100644 app/test/resource.c
 delete mode 100644 app/test/resource.h
 delete mode 100644 app/test/test_resource.c

diff --git a/app/test/meson.build b/app/test/meson.build
index e29258e6ec..62478c0bb6 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -20,7 +20,6 @@ test_cryptodev_deps = ['bus_vdev', 'net', 'cryptodev', 
'security']
 source_file_deps = {
 # The C files providing functionality to other test cases
 'packet_burst_generator.c': packet_burst_generator_deps,
-#'resource.c': [],  # unused currently.
 'sample_packet_forward.c': sample_packet_forward_deps,
 'virtual_pmd.c': virtual_pmd_deps,
 
@@ -154,7 +153,6 @@ source_file_deps = {
 'test_reciprocal_division_perf.c': [],
 'test_red.c': ['sched'],
 'test_reorder.c': ['reorder'],
-#'test_resource.c': [],
 'test_rib.c': ['net', 'rib'],
 'test_rib6.c': ['net', 'rib'],
 'test_ring.c': ['ptr_compress'],
diff --git a/app/test/resource.c b/app/test/resource.c
deleted file mode 100644
index 34465f1668..00
--- a/app/test/resource.c
+++ /dev/null
@@ -1,276 +0,0 @@
-/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2016 RehiveTech. All rights reserved.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#include "resource.h"
-
-struct resource_list resource_list = TAILQ_HEAD_INITIALIZER(resource_list);
-
-size_t resource_size(const struct resource *r)
-{
-   return r->end - r->begin;
-}
-
-const struct resource *resource_find(const char *name)
-{
-   struct resource *r;
-
-   TAILQ_FOREACH(r, &resource_list, next) {
-   RTE_VERIFY(r->name);
-
-   if (!strcmp(r->name, name))
-   return r;
-   }
-
-   return NULL;
-}
-
-int resource_fwrite(const struct resource *r, FILE *f)
-{
-   const size_t goal = resource_size(r);
-   size_t total = 0;
-
-   while (total < goal) {
-   size_t wlen = fwrite(r->begin + total, 1, goal - total, f);
-   if (wlen == 0) {
-   perror(__func__);
-   return -1;
-   }
-
-   total += wlen;
-   }
-
-   return 0;
-}
-
-int resource_fwrite_file(const struct resource *r, const char *fname)
-{
-   FILE *f;
-   int ret;
-
-   f = fopen(fname, "w");
-   if (f == NULL) {
-   perror(__func__);
-   return -1;
-   }
-
-   ret = resource_fwrite(r, f);
-   fclose(f);
-   return ret;
-}
-
-#ifdef RTE_APP_TEST_RESOURCE_TAR
-#include 
-#include 
-
-static int do_copy(struct archive *r, struct archive *w)
-{
-   const void *buf;
-   size_t len;
-#if ARCHIVE_VERSION_NUMBER >= 300
-   int64_t off;
-#else
-   off_t off;
-#endif
-   int ret;
-
-   while (1) {
-   ret = archive_read_data_block(r, &buf, &len, &off);
-   if (ret == ARCHIVE_RETRY)
-   continue;
-
-   if (ret == ARCHIVE_EOF)
-   return 0;
-
-   if (ret != ARCHIVE_OK)
-   return ret;
-
-   do {
-   ret = archive_write_data_block(w, buf, len, off);
-   if (ret != ARCHIVE_OK && ret != ARCHIVE_RETRY)
-   return ret;
-   } while (ret != ARCHIVE_OK);
-   }
-}
-
-int resource_untar(const struct resource *res)
-{
-   struct archive *r;
-   struct archive *w;
-   struct archive_entry *e;
-   void *p;
-   int flags = 0;
-   int ret;
-
-   p = malloc(resource_size(res));
-   if (p == NULL)
-   rte_panic("Failed to malloc %zu B\n", resource_size(res));
-
-   memcpy(p, res->begin, resource_size(res));
-
-   r = archive_read_new();
-   if (r == NULL) {
-   free(p);
-   return -1;
-   }
-
-   archive_read_support_format_all(r);
-   archive_read_support_filter_all(r);
-
-   w = archive_write_disk_new();
-   if (w == NULL) {
-   archive_read_free(r);
-   free(p);
-   return -1;
-   }
-
-   flags |= ARCHIVE_EXTRACT_PERM;
-   flags |= ARCHIVE_EXTRACT_FFLAGS;
-   archive_write_disk_set_options(w, flags);
-   archive_write_disk_set_standard_lookup(w);
-
-   ret = archive_read_open_memory(r, p, resource_size(res));
-   if (ret != ARCHIVE_OK)
-   goto fail;
-
-   while (1) {
-   ret = archive_read_next_header(r, &e);
-   if (ret == ARCHIV

[PATCH v3 3/3] test: restore cfgfile tests

[Stephen Hemminger]

These tests were not built since the conversion to meson.
Instead of using embedded resource functions, put data in include
file and generate temporary file before the test.

Signed-off-by: Stephen Hemminger 
---
 app/meson.build|   3 +-
 app/test/meson.build   |   6 +-
 app/test/test_cfgfile.c| 153 +++--
 app/test/test_cfgfiles/meson.build |  19 
 4 files changed, 129 insertions(+), 52 deletions(-)
 create mode 100644 app/test/test_cfgfiles/meson.build

diff --git a/app/meson.build b/app/meson.build
index 5b2c80c7a1..e2db888ae1 100644
--- a/app/meson.build
+++ b/app/meson.build
@@ -55,6 +55,7 @@ foreach app:apps
 build = true
 reason = '' # set if build == false to explain
 sources = []
+resources = []
 includes = []
 cflags = default_cflags
 ldflags = default_ldflags
@@ -115,7 +116,7 @@ foreach app:apps
 endif
 
 exec = executable('dpdk-' + name,
-sources,
+[ sources, resources ],
 c_args: cflags,
 link_args: ldflags,
 link_whole: link_libs,
diff --git a/app/test/meson.build b/app/test/meson.build
index 62478c0bb6..b2bb7c36f6 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -35,7 +35,7 @@ source_file_deps = {
 'test_bitratestats.c': ['metrics', 'bitratestats', 'ethdev'] + 
sample_packet_forward_deps,
 'test_bpf.c': ['bpf', 'net'],
 'test_byteorder.c': [],
-#'test_cfgfile.c': ['cfgfile'],
+'test_cfgfile.c': ['cfgfile'],
 'test_cksum.c': ['net'],
 'test_cksum_perf.c': ['net'],
 'test_cmdline.c': [],
@@ -261,3 +261,7 @@ if not is_windows
 build_by_default: true,
 install: false)
 endif
+
+subdir('test_cfgfiles')
+
+resources += test_cfgfile_h
diff --git a/app/test/test_cfgfile.c b/app/test/test_cfgfile.c
index a5e3d8699c..7cfcaf348a 100644
--- a/app/test/test_cfgfile.c
+++ b/app/test/test_cfgfile.c
@@ -5,48 +5,54 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+
+#ifdef RTE_EXEC_ENV_WINDOWS
+#include 
+#endif
 
 #include 
 
 #include "test.h"
-#include "resource.h"
-
-
-#define CFG_FILES_ETC "test_cfgfiles/etc"
 
-REGISTER_LINKED_RESOURCE(test_cfgfiles);
+#include "test_cfgfiles.h"
 
 static int
-test_cfgfile_setup(void)
+make_tmp_file(char *filename, const char *prefix, const char *data)
 {
-   const struct resource *r;
-   int ret;
+   size_t len = strlen(data);
+   size_t count;
+   FILE *f;
 
-   r = resource_find("test_cfgfiles");
-   TEST_ASSERT_NOT_NULL(r, "missing resource test_cfgfiles");
+#ifdef RTE_EXEC_ENV_WINDOWS
+   char tempDirName[MAX_PATH - 14];
 
-   ret = resource_untar(r);
-   TEST_ASSERT_SUCCESS(ret, "failed to untar %s", r->name);
+   if (GetTempPathA(sizeof(tempDirName), tempDirName) == 0)
+   return -1;
 
-   return 0;
-}
+   if (GetTempFileNameA(tempDirName, prefix, 0, filename) == 0)
+   return -1;
 
-static int
-test_cfgfile_cleanup(void)
-{
-   const struct resource *r;
-   int ret;
+   f = fopen(filename, "wt");
+#else
+   snprintf(filename, PATH_MAX, "/tmp/%s_XXX", prefix);
 
-   r = resource_find("test_cfgfiles");
-   TEST_ASSERT_NOT_NULL(r, "missing resource test_cfgfiles");
+   int fd = mkstemp(filename);
+   if (fd < 0)
+   return -1;
 
-   ret = resource_rm_by_tar(r);
-   TEST_ASSERT_SUCCESS(ret, "Failed to delete resource %s", r->name);
+   f = fdopen(fd, "w");
+#endif
+   if (f == NULL)
+   return -1;
 
-   return 0;
+   count = fwrite(data, sizeof(char), len, f);
+   fclose(f);
+
+   return (count == len) ? 0 : -1;
 }
 
+
 static int
 _test_cfgfile_sample(struct rte_cfgfile *cfgfile)
 {
@@ -87,9 +93,13 @@ static int
 test_cfgfile_sample1(void)
 {
struct rte_cfgfile *cfgfile;
+   char filename[PATH_MAX];
int ret;
 
-   cfgfile = rte_cfgfile_load(CFG_FILES_ETC "/sample1.ini", 0);
+   ret = make_tmp_file(filename, "sample1", sample1_ini);
+   TEST_ASSERT_SUCCESS(ret, "Failed to setup temp file");
+
+   cfgfile = rte_cfgfile_load(filename, 0);
TEST_ASSERT_NOT_NULL(cfgfile, "Failed to load config file");
 
ret = _test_cfgfile_sample(cfgfile);
@@ -98,6 +108,8 @@ test_cfgfile_sample1(void)
ret = rte_cfgfile_close(cfgfile);
TEST_ASSERT_SUCCESS(ret, "Failed to close cfgfile");
 
+   remove(filename);
+
return 0;
 }
 
@@ -106,15 +118,18 @@ test_cfgfile_sample2(void)
 {
struct rte_cfgfile_parameters params;
struct rte_cfgfile *cfgfile;
+   char filename[PATH_MAX];
int ret;
 
+   ret = make_tmp_file(filename, "sample2", sample2_ini);
+   TEST_ASSERT_SUCCESS(ret, "Failed to setup temp file");
+
/* override comment character */
memset(¶ms, 0, sizeof(params));
params.comment_character = '#';
 
-   cfgfile = rte_cfgfile_load_with_param

RE: [EXTERNAL] Re: ipsec on dpdk

[Akhil Goyal]

Hi Yaron,

Please see the inline replies.

> Hello,
> 
> Adding Cc some experts.
> 
> About the IPsec support, we are writing a document, it is in progress.
> 
> 
> 28/07/2024 14:51, Yaron Illouz:
> > Hi
> >
> > I am interested to do ipsec encoding and decoding in my dpdk application
> > From my readings, i understand ipsec can be done one time in the nic (inline
> ipsec) or with multiple calls (rte_cryptodev_enqueue_burst,
> rte_cryptodev_dequeue_burst)
> >
> >
> >   1.  If ipsec is done by nic I only need to call 
> > rte_ipsec_pkt_process(...) without
> other functions?

This API is for inline crypto mode and is not the only API to be called.
Please check the documentation and refer to examples/ipsec-secgw.
It has support for all 3 modes - inline crypto, inline protocol and lookaside 
protocol.
It also supports legacy lookaside crypto mode which does not use rte_security.

> >
> > I use  rte_eth_rx_burst to read from nic.
> >
> >   1.  Where do I see list of nic that support nic inline ipsec? I believe 
> > not all dpdk
> nic support it.

The NICs which support RTE_ETH_TX_OFFLOAD_SECURITY are the ones which can 
support inline IPSec
These are ixgbe, txgbe, cnxk, iavf and nfp.

> >   2.  How much does it impact performance ? is there a table of performance
> per nic?

Performance numbers are specific to PMDs and are not published in dpdk 
documentation.
You may check with individual PMD owners.

> >   3.  My application is multi process, I can see in documentation :
> >
> > “Currently, the security library does not support the case of 
> > multi-process. It will
> be updated in the future releases.” From
> https://doc.dpdk.org/guides/prog_guide/rte_security.html

With this note, it means rte_security library and the PMDs are not taking care 
of
Multi-process related synchronization for sessions. It will be application 
responsibility to handle that.

> >
> > So ipsec also is not supported for multi process application?
It can be supported.
Application need to take care of how sessions are configured for multiple 
processes.
Library or the PMD are not handling it.

> >
> > Even if done inline by the nic?
> >
> > And what about non inline ipsec for multi process applications?

It is not about inline or non-inline.
The security library has 3 modes - inline protocol offload, inline crypto 
offload and lookaside protocol offload.
The security lib is not handling multi-process scenarios so it is applicable 
for all the above modes.

> >   1.  Is ip sec also supported in multi queue with rte flow in the inline 
> > ipsec ?
Yes it can be configured that way.

-Akhil

DPDK 24.07 released

[Thomas Monjalon]

A new major release is available:
https://fast.dpdk.org/rel/dpdk-24.07.tar.xz

This is the work achieved during the last months:
954 commits from 191 authors
1631 files changed, 80005 insertions(+), 25069 deletions(-)


It is not planned to start a maintenance branch for 24.07.
This version is ABI-compatible with 23.11 and 24.03.

Below are some new features:
- pointer compression library
- SVE support in the hash library
- FEC support in Intel i40e and ice
- Intel E830 support in ice driver
- Napatech ntnic driver initialization
- AMD Pensando ionic crypto driver
- UADK compress driver
- Marvell Odyssey ODM DMA driver
- log cleanups in drivers
- more cleanups to prepare MSVC build

More details in the release notes:
https://doc.dpdk.org/guides/rel_notes/release_24_07.html


There are 49 new contributors (including authors, reviewers and testers).
Welcome to Adrian Pielech, Alessio Igor Bogani, Alex Chapman,
Alexander Skorichenko, Anthony Harivel, Aviraj CJ, Barbara Skobiej,
Chenming Chang, Daniel Gregory, Daniil Ushkov, Dean Marx, Eryk Rybak,
Francis Racicot, Haoqian He, Harjot Singh, Hongbo Li, Igor Gutorov,
Jan Sokolowski, Jedrzej Jagielski, Jiang Yu, Joel Kavanagh, Jun Wang,
Kiran Vedere, Mahmoud Maatuq, Marcin Jurczak, Marek Mical,
Marek Zalfresso-jundzillo, Michael Theodore Stolarchuk, Pabitra Dalai,
Pawel Sobczyk, Piotr Raczynski, Potnuri Bharat Teja,
Prathisna Padmasanan, Przemek Kitszel, Radoslaw Tyl, Remigiusz Konca,
Serhii Iliushyk, Shaiq Wani, Shreesh Adiga, Shuo Li, Soumyadeep Hore,
Sriram Yagnaraman, Tathagat Priyadarshi, Tomasz Wakula, Varun Sethi,
Vipin Padmam Ramesh, Waldemar Dworakowski, Yoan Picchi, Yochai Hagvi, 
and Yuan Zhiyuan.


Below is the number of commits per employer (with authors count):
247 Intel (77)
135 NVIDIA (23)
111 Corigine (5)
 91 Marvell (18)
 54 Red Hat (5)
 46 AMD (5)
 40 Arm (5)
 39 networkplumber.org (1)
 36 Microsoft (3)
 23 NXP (7)
 22 Napatech (2)
 21 Trustnet (1)
 18 Huawei (5)
 15 Amazon (1)
...

A big thank to all courageous people who took on the non rewarding task
of reviewing other's job.
Based on Reviewed-by and Acked-by tags, the top non-PMD reviewers are:
 35 Morten Brørup 
 27 Juraj Linkeš 
 25 Ferruh Yigit 
 24 Jeremy Spewock 
 24 Akhil Goyal 
 22 Paul Szczepanek 
 19 Bruce Richardson 
 18 Stephen Hemminger 


The next version will be 24.11 in November.
The new features for 24.11 can be submitted during the next 5 weeks:
http://core.dpdk.org/roadmap#dates
Please share your roadmap.


Don't forget to register for the DPDK Summit in September:
https://events.linuxfoundation.org/dpdk-summit/

Thanks everyone, see you in Montreal

22.11.6 patches review and test

[luca . boccassi]

Hi all,

Here is a list of patches targeted for stable release 22.11.6.

The planned date for the final release is August 20th.

Please help with testing and validation of your use cases and report
any issues/results with reply-all to this mail. For the final release
the fixes and reported validations will be added to the release notes.

A release candidate tarball can be found at:

https://dpdk.org/browse/dpdk-stable/tag/?id=v22.11.6-rc1

These patches are located at branch 22.11 of dpdk-stable repo:
https://dpdk.org/browse/dpdk-stable/

Thanks.

Luca Boccassi

---
Abdullah Ömer Yamaç (1):
  hash: fix RCU reclamation size

Akhil Goyal (1):
  test/crypto: fix enqueue/dequeue callback case

Alex Vesker (1):
  net/mlx5/hws: fix port ID on root item convert

Alexander Kozyrev (2):
  net/mlx5: break flow resource release loop
  app/testpmd: add postpone option to async flow destroy

Anatoly Burakov (7):
  net/e1000/base: fix link power down
  fbarray: fix incorrect lookahead behavior
  fbarray: fix incorrect lookbehind behavior
  fbarray: fix lookahead ignore mask handling
  fbarray: fix lookbehind ignore mask handling
  fbarray: fix finding for unaligned length
  malloc: fix multi-process wait condition handling

Andrew Boyer (1):
  net/ionic: fix mbuf double-free when emptying array

Apeksha Gupta (2):
  bus/dpaa: fix memory leak in bus scan
  common/dpaax: fix node array overrun

Arkadiusz Kusztal (1):
  crypto/qat: fix placement of OOP offset

Bing Zhao (3):
  net/mlx5: fix end condition of reading xstats
  net/mlx5: fix uplink port probing in bonding mode
  common/mlx5: remove unneeded field when modify RQ table

Brian Dooley (1):
  crypto/qat: fix GEN4 write

Bruce Richardson (2):
  net/ice: fix sizing of filter hash table
  ethdev: fix device init without socket-local memory

Chaoyong He (5):
  app/testpmd: fix help string of BPF load command
  net/nfp: fix IPv6 TTL and DSCP flow action
  net/nfp: fix allocation of switch domain
  net/nfp: forbid offload flow rules with empty action list
  net/nfp: remove redundant function call

Chengwen Feng (2):
  net/hns3: check Rx DMA address alignmnent
  dma/hisilicon: remove support for HIP09 platform

Chenming Chang (1):
  hash: fix return code description in Doxygen

Chinh Cao (1):
  net/ice/base: fix return type of bitmap hamming weight

Christian Ehrhardt (1):
  test: force IOVA mode on PPC64 without huge pages

Ciara Loftus (4):
  net/af_xdp: fix port ID in Rx mbuf
  net/af_xdp: count mbuf allocation failures
  net/af_xdp: fix stats reset
  net/af_xdp: remove unused local statistic

Ciara Power (1):
  test/crypto: fix vector global buffer overflow

Conor Fogarty (1):
  hash: check name when creating a hash

Dariusz Sosnowski (2):
  net/mlx5: fix MTU configuration
  net/mlx5: fix disabling E-Switch default flow rules

David Marchand (14):
  bus/pci: fix build with musl 1.2.4 / Alpine 3.19
  eal/unix: support ZSTD compression for firmware
  net/ice: fix check for outer UDP checksum offload
  app/testpmd: fix outer IP checksum offload
  net: fix outer UDP checksum in Intel prepare helper
  net/i40e: fix outer UDP checksum offload for X710
  net/iavf: remove outer UDP checksum offload for X710 VF
  telemetry: lower log level on socket error
  doc: fix link to hugepage mapping from Linux guide
  config: fix warning for cross build with meson >= 1.3.0
  vdpa/sfc: remove dead code
  eal/linux: lower log level on allocation attempt failure
  buildtools: fix build with clang 17 and ASan
  net/vmxnet3: fix init logs

Dengdui Huang (5):
  net/hns3: fix offload flag of IEEE 1588
  net/hns3: fix Rx timestamp flag
  net/hns3: fix double free for Rx/Tx queue
  net/hns3: fix variable overflow
  app/testpmd: handle IEEE1588 init failure

Ed Czeck (1):
  net/ark: fix index arithmetic

Edwin Brossette (1):
  net/ixgbe: do not create delayed interrupt handler twice

Erez Shitrit (3):
  net/mlx5/hws: decrease log level for creation failure
  net/mlx5/hws: fix deletion of action vport
  net/mlx5/hws: remove unused variable

Eric Joyner (2):
  net/ice/base: fix memory leak in firmware version check
  net/ice/base: fix GCS descriptor field offsets

Ferruh Yigit (1):
  app/testpmd: fix build on signed comparison

Gagandeep Singh (4):
  common/dpaax/caamflib: fix PDCP-SDAP watchdog error
  crypto/dpaa_sec: fix IPsec descriptor
  bus/dpaa: fix bus scan for DMA devices
  common/dpaax: fix IOVA table cleanup

Ganapati Kundapura (3):
  eventdev/crypto: fix opaque field handling
  cryptodev: fix build without crypto callbacks
  cryptodev: validate crypto callbacks from next node

Gaoxiang Liu (1):
  net/bonding: fix failover time of LACP with mode 4

Gowrishankar Muthukrishnan (6):

Re: [PATCH] net/gve : Update EOP bit in txd rte_mbuf chain

[Joshua Washington]

On Wed, Jul 31, 2024, 09:37 Tathagat Priyadarshi
 wrote:
>
> The EOP bit was not set for all the packets in mbuf chain
> causing packet transmission stalls for packets split across
> mbuf in chain.
>
> Signed-off-by: Tathagat Priyadarshi 
> Signed-off-by: Varun Lakkur Ambaji Rao 
>
> Fixes: 4022f99 ("net/gve: support basic Tx data path for DQO")
> ---
>  drivers/net/gve/gve_tx_dqo.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/gve/gve_tx_dqo.c b/drivers/net/gve/gve_tx_dqo.c
> index a65e6aa..579b8d6 100644
> --- a/drivers/net/gve/gve_tx_dqo.c
> +++ b/drivers/net/gve/gve_tx_dqo.c
> @@ -126,6 +126,7 @@
> txd->pkt.dtype = GVE_TX_PKT_DESC_DTYPE_DQO;
> txd->pkt.compl_tag = rte_cpu_to_le_16(first_sw_id);
> txd->pkt.buf_size = RTE_MIN(tx_pkt->data_len, 
> GVE_TX_MAX_BUF_SIZE_DQO);
> +   txd->pkt.end_of_packet = 0;

Please also update checksum offload for each mbuf.
>
>
> /* size of desc_ring and sw_ring could be different */
> tx_id = (tx_id + 1) & mask;
> --
> 1.8.3.1
>

Thanks for all of the contributions! Let's try to get this applied to
stable release as well.

[PATCH] doc: update Arm IPsec-MB dependency version

[Wathsala Vithanage]

Updates the tag of Arm IPsec-MB library to SECLIB-IPSEC-2024.07.08
in snow3g and zuc documentation.

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

---
 .mailmap | 1 +
 doc/guides/cryptodevs/snow3g.rst | 2 +-
 doc/guides/cryptodevs/zuc.rst| 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/.mailmap b/.mailmap
index 4a508bafad..b924fad56b 100644
--- a/.mailmap
+++ b/.mailmap
@@ -343,6 +343,7 @@ Dexia Li 
 Dexuan Cui 
 Dharmik Thakkar  
 Dheemanth Mallikarjun 
+Dhruv Tripathi 
 Diana Wang 
 Didier Pallard 
 Dilshod Urazov 
diff --git a/doc/guides/cryptodevs/snow3g.rst b/doc/guides/cryptodevs/snow3g.rst
index 923b3fa0ac..6eb8229fb5 100644
--- a/doc/guides/cryptodevs/snow3g.rst
+++ b/doc/guides/cryptodevs/snow3g.rst
@@ -54,7 +54,7 @@ can be downloaded from 
``_. The
-latest version of the library supported by this PMD is tagged as 
SECLIB-IPSEC-2024.03.12.
+latest version of the library supported by this PMD is tagged as 
SECLIB-IPSEC-2024.07.08.
 
 After downloading the library, the user needs to unpack and compile it
 on their system before building DPDK:
diff --git a/doc/guides/cryptodevs/zuc.rst b/doc/guides/cryptodevs/zuc.rst
index f51980e1fc..29fe6279aa 100644
--- a/doc/guides/cryptodevs/zuc.rst
+++ b/doc/guides/cryptodevs/zuc.rst
@@ -53,7 +53,7 @@ can be downloaded from 
``_. The
-latest version of the library supported by this PMD is tagged as 
SECLIB-IPSEC-2024.03.12.
+latest version of the library supported by this PMD is tagged as 
SECLIB-IPSEC-2024.07.08.
 
 After downloading the library, the user needs to unpack and compile it
 on their system before building DPDK:
-- 
2.34.1

[PATCH v4] virtio: optimize stats counters performance

[Morten Brørup]

Optimized the performance of updating the virtio statistics counters by
reducing the number of branches and inlining the function.

Ordered the packet size comparisons according to the probability with
typical internet traffic mix.

Signed-off-by: Morten Brørup 
---
v4:
* Consider multicast/broadcast packets unlikely.
v3:
* Eliminated a local variable.
* Note: Substituted sizeof(uint32_t)*4 by 32UL, using unsigned long type
  to keep optimal offsetting in generated assembler output.
* Removed unnecessary curly braces.
v2:
* Fixed checkpatch warning about line length.
---
 drivers/net/virtio/virtio_rxtx.c | 34 
 drivers/net/virtio/virtio_rxtx.h | 23 +++--
 2 files changed, 21 insertions(+), 36 deletions(-)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index f69b9453a2..bb04fd7d43 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -81,40 +81,6 @@ vq_ring_free_chain(struct virtqueue *vq, uint16_t desc_idx)
dp->next = VQ_RING_DESC_CHAIN_END;
 }
 
-void
-virtio_update_packet_stats(struct virtnet_stats *stats, struct rte_mbuf *mbuf)
-{
-   uint32_t s = mbuf->pkt_len;
-   struct rte_ether_addr *ea;
-
-   stats->bytes += s;
-
-   if (s == 64) {
-   stats->size_bins[1]++;
-   } else if (s > 64 && s < 1024) {
-   uint32_t bin;
-
-   /* count zeros, and offset into correct bin */
-   bin = (sizeof(s) * 8) - rte_clz32(s) - 5;
-   stats->size_bins[bin]++;
-   } else {
-   if (s < 64)
-   stats->size_bins[0]++;
-   else if (s < 1519)
-   stats->size_bins[6]++;
-   else
-   stats->size_bins[7]++;
-   }
-
-   ea = rte_pktmbuf_mtod(mbuf, struct rte_ether_addr *);
-   if (rte_is_multicast_ether_addr(ea)) {
-   if (rte_is_broadcast_ether_addr(ea))
-   stats->broadcast++;
-   else
-   stats->multicast++;
-   }
-}
-
 static inline void
 virtio_rx_stats_updated(struct virtnet_rx *rxvq, struct rte_mbuf *m)
 {
diff --git a/drivers/net/virtio/virtio_rxtx.h b/drivers/net/virtio/virtio_rxtx.h
index afc4b74534..0f938ab145 100644
--- a/drivers/net/virtio/virtio_rxtx.h
+++ b/drivers/net/virtio/virtio_rxtx.h
@@ -35,7 +35,26 @@ struct virtnet_tx {
 };
 
 int virtio_rxq_vec_setup(struct virtnet_rx *rxvq);
-void virtio_update_packet_stats(struct virtnet_stats *stats,
-   struct rte_mbuf *mbuf);
+
+static inline void
+virtio_update_packet_stats(struct virtnet_stats *const stats, const struct 
rte_mbuf *const mbuf)
+{
+   uint32_t s = mbuf->pkt_len;
+   const struct rte_ether_addr *ea = rte_pktmbuf_mtod(mbuf, const struct 
rte_ether_addr *);
+
+   stats->bytes += s;
+
+   if (s >= 1024)
+   stats->size_bins[6 + (s > 1518)]++;
+   else if (s <= 64)
+   stats->size_bins[s >> 6]++;
+   else
+   stats->size_bins[32UL - rte_clz32(s) - 5]++;
+
+   RTE_BUILD_BUG_ON(offsetof(struct virtnet_stats, broadcast) !=
+   offsetof(struct virtnet_stats, multicast) + 
sizeof(uint64_t));
+   if (unlikely(rte_is_multicast_ether_addr(ea)))
+   (&stats->multicast)[rte_is_broadcast_ether_addr(ea)]++;
+}
 
 #endif /* _VIRTIO_RXTX_H_ */
-- 
2.43.0

RE: [PATCH v4] virtio: optimize stats counters performance

[Morten Brørup]

> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Thursday, 1 August 2024 01.46
> 
> On Wed, 31 Jul 2024 22:58:16 +
> Morten Brørup  wrote:
> 
> > +
> > +static inline void
> > +virtio_update_packet_stats(struct virtnet_stats *const stats, const
> struct rte_mbuf *const mbuf)
> > +{
> > +   uint32_t s = mbuf->pkt_len;
> > +   const struct rte_ether_addr *ea = rte_pktmbuf_mtod(mbuf, const
> struct rte_ether_addr *);
> > +
> > +   stats->bytes += s;
> > +
> > +   if (s >= 1024)
> > +   stats->size_bins[6 + (s > 1518)]++;
> > +   else if (s <= 64)
> > +   stats->size_bins[s >> 6]++;
> > +   else
> > +   stats->size_bins[32UL - rte_clz32(s) - 5]++;
> > +
> > +   RTE_BUILD_BUG_ON(offsetof(struct virtnet_stats, broadcast) !=
> > +   offsetof(struct virtnet_stats, multicast) +
> sizeof(uint64_t));
> > +   if (unlikely(rte_is_multicast_ether_addr(ea)))
> > +   (&stats->multicast)[rte_is_broadcast_ether_addr(ea)]++;
> > +}
> >
> 
> Why move it to virtio_rxtx.h it was fine where it was.

Because it is also called from the vector implementations [1], where it was not 
inlined before.

[1]: https://elixir.bootlin.com/dpdk/v24.07/A/ident/virtio_update_packet_stats

[PATCH v1] net/ice: fix ice Rx timestamp for E822 NICs

[Soumyadeep Hore]

E822 PHY does not support switching from bypass to Vernier mode.
Remove ice_phy_exit_bypass_e822() and program fixed offsets for bypass
mode.

Fixes: ce9ad8c5bc6d ("net/ice/base: remove PHY port timer bypass mode")
Cc: sta...@dpdk.org

Signed-off-by: Soumyadeep Hore 
---
 drivers/net/ice/base/ice_ptp_hw.c | 117 --
 drivers/net/ice/base/ice_ptp_hw.h |   2 +-
 drivers/net/ice/ice_ethdev.c  |   2 +-
 3 files changed, 113 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ice/base/ice_ptp_hw.c 
b/drivers/net/ice/base/ice_ptp_hw.c
index 004f659eae..7041b54d7b 100644
--- a/drivers/net/ice/base/ice_ptp_hw.c
+++ b/drivers/net/ice/base/ice_ptp_hw.c
@@ -4465,18 +4465,103 @@ ice_stop_phy_timer_e822(struct ice_hw *hw, u8 port, 
bool soft_reset)
return 0;
 }
 
+/**
+ * ice_phy_cfg_fixed_tx_offset_e822 - Configure Tx offset for bypass mode
+ * @hw: pointer to the HW struct
+ * @port: the PHY port to configure
+ *
+ * Calculate and program the fixed Tx offset, and indicate that the offset is
+ * ready. This can be used when operating in bypass mode.
+ */
+static int ice_phy_cfg_fixed_tx_offset_e822(struct ice_hw *hw, u8 port)
+{
+   enum ice_ptp_link_spd link_spd;
+   enum ice_ptp_fec_mode fec_mode;
+   u64 total_offset;
+   int err;
+
+   err = ice_phy_get_speed_and_fec_e822(hw, port, &link_spd, &fec_mode);
+   if (err)
+   return err;
+
+   total_offset = ice_calc_fixed_tx_offset_e822(hw, link_spd);
+
+   /* Program the fixed Tx offset into the P_REG_TOTAL_TX_OFFSET_L
+* register, then indicate that the Tx offset is ready. After this,
+* timestamps will be enabled.
+*
+* Note that this skips including the more precise offsets generated
+* by the Vernier calibration.
+*/
+
+   err = ice_write_64b_phy_reg_e822(hw, port, P_REG_TOTAL_TX_OFFSET_L,
+total_offset);
+   if (err)
+   return err;
+
+   err = ice_write_phy_reg_e822(hw, port, P_REG_TX_OR, 1);
+   if (err)
+   return err;
+
+   return ICE_SUCCESS;
+}
+
+/**
+ * ice_phy_cfg_rx_offset_e822 - Configure fixed Rx offset for bypass mode
+ * @hw: pointer to the HW struct
+ * @port: the PHY port to configure
+ *
+ * Calculate and program the fixed Rx offset, and indicate that the offset is
+ * ready. This can be used when operating in bypass mode.
+ */
+static int ice_phy_cfg_fixed_rx_offset_e822(struct ice_hw *hw, u8 port)
+{
+   enum ice_ptp_link_spd link_spd;
+   enum ice_ptp_fec_mode fec_mode;
+   u64 total_offset;
+   int err;
+
+   err = ice_phy_get_speed_and_fec_e822(hw, port, &link_spd, &fec_mode);
+   if (err)
+   return err;
+
+   total_offset = ice_calc_fixed_rx_offset_e822(hw, link_spd);
+
+   /* Program the fixed Rx offset into the P_REG_TOTAL_RX_OFFSET_L
+* register, then indicate that the Rx offset is ready. After this,
+* timestamps will be enabled.
+*
+* Note that this skips including the more precise offsets generated
+* by Vernier calibration.
+*/
+   err = ice_write_64b_phy_reg_e822(hw, port, P_REG_TOTAL_RX_OFFSET_L,
+total_offset);
+   if (err)
+   return err;
+
+   err = ice_write_phy_reg_e822(hw, port, P_REG_RX_OR, 1);
+   if (err)
+   return err;
+
+   return ICE_SUCCESS;
+}
+
 /**
  * ice_start_phy_timer_e822 - Start the PHY clock timer
  * @hw: pointer to the HW struct
  * @port: the PHY port to start
+ * @bypass: if true, start the PHY in bypass mode
  *
  * Start the clock of a PHY port. This must be done as part of the flow to
  * re-calibrate Tx and Rx timestamping offsets whenever the clock time is
  * initialized or when link speed changes.
  *
- * Hardware will take Vernier measurements on Tx or Rx of packets.
+ * Bypass mode enables timestamps immediately without waiting for Vernier
+ * calibration to complete. Hardware will still continue taking Vernier
+ * measurements on Tx or Rx of packets, but they will not be applied to
+ * timestamps.
  */
-int ice_start_phy_timer_e822(struct ice_hw *hw, u8 port)
+int ice_start_phy_timer_e822(struct ice_hw *hw, u8 port, bool bypass)
 {
u32 lo, hi, val;
u64 incval;
@@ -4541,15 +4626,35 @@ int ice_start_phy_timer_e822(struct ice_hw *hw, u8 port)
 
ice_ptp_exec_tmr_cmd(hw);
 
+   if (bypass) {
+   /* Enter BYPASS mode, enabling timestamps immediately. */
+   val |= P_REG_PS_BYPASS_MODE_M;
+   err = ice_write_phy_reg_e822(hw, port, P_REG_PS, val);
+   if (err)
+   return err;
+   }
+
val |= P_REG_PS_ENA_CLK_M;
err = ice_write_phy_reg_e822(hw, port, P_REG_PS, val);
if (err)
return err;
 
-   val |= P_REG_PS_LOAD_OFFSET_M;
-   err = ice_write_phy_reg_e822(hw, port, P_REG