Re: [PATCH v5 1/3] ring: fix unmatched type definition and usage
On 2023/5/9 14:23, Ruifeng Wang wrote:
-Original Message-
From: Jie Hai
Sent: Tuesday, May 9, 2023 9:29 AM
To: Honnappa Nagarahalli ; Konstantin Ananyev
; Ruifeng Wang ; Gavin Hu
; Olivier Matz ; Dharmik Jayesh
Thakkar
Cc: dev@dpdk.org; liudongdo...@huawei.com
Subject: [PATCH v5 1/3] ring: fix unmatched type definition and usage
Field 'flags' of struct rte_ring is defined as int type. However, it is used as
unsigned
int. To ensure consistency, change the type of flags to unsigned int. Since
these two
types has the same byte size, this change is not an ABI change.
Fixes: cc4b218790f6 ("ring: support configurable element size")
The change looks good.
However, I think the fix line is not accurate.
I suppose it fixes af75078fece3 ("first public release").
Thanks for your review. Sorry for quoting the wrong commit.
This issue was indeed introduced by commit af75078fece3 ("first public
release").
I will fix this in the next version.
Signed-off-by: Jie Hai
Acked-by: Konstantin Ananyev
Acked-by: Chengwen Feng
---
lib/ring/rte_ring_core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/ring/rte_ring_core.h b/lib/ring/rte_ring_core.h index
82b237091b71..1c809abeb531 100644
--- a/lib/ring/rte_ring_core.h
+++ b/lib/ring/rte_ring_core.h
@@ -120,7 +120,7 @@ struct rte_ring_hts_headtail { struct rte_ring {
char name[RTE_RING_NAMESIZE] __rte_cache_aligned;
/**< Name of the ring. */
- int flags; /**< Flags supplied at creation. */
+ uint32_t flags; /**< Flags supplied at creation. */
const struct rte_memzone *memzone;
/**< Memzone, if any, containing the rte_ring */
uint32_t size; /**< Size of ring. */
--
2.33.0
.
RE: DPDK 22.11 Troubleshooting
-Original Message- From: Bruce Richardson Sent: Wednesday, May 3, 2023 11:18 AM To: Gilbert Carrillo Cc: dev@dpdk.org Subject: Re: DPDK 22.11 Troubleshooting On Wed, May 03, 2023 at 04:53:20PM +, Gilbert Carrillo wrote: > Make static returns an error (see attached). > > v/R, > Gilbert > To help investigate this issue, can you perhaps include the text of the full build output when you run "make static". On my system I see libelf listed on the linker flags when I run "make static", and things link properly. I'm wondering how my setup may differ from yours. /Bruce > -Original Message- > From: Bruce Richardson > Sent: Wednesday, May 3, 2023 10:35 AM > To: Gilbert Carrillo > Cc: dev@dpdk.org > Subject: Re: DPDK 22.11 Troubleshooting > > On Wed, May 03, 2023 at 04:22:05PM +, Gilbert Carrillo wrote: > > Hi Bruce, > > > > Thank you for the response. > > > > There is no errors when I run the makefile, however I do see a difference > > in the programs. I don't believe the makefile is linking all the libraries > > together as intended. > > > > For example, when I run the ethtool sample program and compile it using > > meson, it works fine and rte_eth_dev_count_avail() returns the correct > > amount. However, when I compile ethtool with the makefile and run it > > rte_eth_dev_count_avail() returns 0. > > > > Note that by default the meson build will statically link the examples, while > the makefile will dynamically load the drivers at runtime. That may explain > the difference. Can you try building and running using "make static" rather > than just "make". > > /Bruce Bruce, I had multiple versions of DPDK installed and I was linking the wrong one. I was able to compile my application with CMAKE successfully. I had one last quick question. I am trying to achieve zero copy DMA from my FPGA to my external buffer. Is this possible? I saw methods such as attaching an mbuf to the external buffer? But I wasn't sure if this was truly zero copy. -Gilbert
RE: [EXT] [PATCH v2 4/4] app: add testgraph application
> -Original Message- > From: Vamsi Krishna Attunuru > Sent: Tuesday, May 9, 2023 9:10 AM > To: Sunil Kumar Kori ; dev@dpdk.org; > tho...@monjalon.net; Jerin Jacob Kollanukkaran > Cc: Nithin Kumar Dabilpuram > Subject: RE: [EXT] [PATCH v2 4/4] app: add testgraph application > > > > > -Original Message- > > From: Sunil Kumar Kori > > Sent: Tuesday, May 9, 2023 8:04 AM > > To: Vamsi Krishna Attunuru ; dev@dpdk.org; > > tho...@monjalon.net; Jerin Jacob Kollanukkaran > > Cc: Vamsi Krishna Attunuru ; Nithin Kumar > > Dabilpuram > > Subject: RE: [EXT] [PATCH v2 4/4] app: add testgraph application > > > > Is there any user guide similar to testpmd ? > > >Please refer doc/guides/tools/testgraph.rst for details. > Thanks. > > > -Original Message- > > > From: Vamsi Attunuru > > > Sent: Tuesday, April 25, 2023 6:45 PM > > > To: dev@dpdk.org; tho...@monjalon.net; Jerin Jacob Kollanukkaran > > > > > > Cc: Vamsi Krishna Attunuru ; Nithin Kumar > > > Dabilpuram > > > Subject: [EXT] [PATCH v2 4/4] app: add testgraph application > > > > > > External Email > > > > > > -- > > > Patch adds test-graph application to validate graph > > > and node libraries. > > > > > > Signed-off-by: Vamsi Attunuru > > > --- > > > app/meson.build|1 + > > > app/test-graph/cmdline.c | 211 + > > > app/test-graph/cmdline_graph.c | 294 +++ > > > app/test-graph/cmdline_graph.h | 19 + > > > app/test-graph/meson.build | 14 + > > > app/test-graph/parameters.c| 157 > > > app/test-graph/testgraph.c | 1426 > > > > > app/test-graph/testgraph.h | 91 ++ > > > doc/guides/tools/index.rst |1 + > > > doc/guides/tools/testgraph.rst | 131 +++ > > > 10 files changed, 2345 insertions(+) > > > [Code Snipped] > > > +++ b/doc/guides/tools/testgraph.rst > > > @@ -0,0 +1,131 @@ > > > +.. SPDX-License-Identifier: BSD-3-Clause > > > +Copyright(C) 2023 Marvell International Ltd. > > > + > > > +dpdk-test-graph Application > > > +=== > > > + > > > +The ``dpdk-test-graph`` tool is a Data Plane Development Kit (DPDK) > > > application that allows > > > +exercising various graph library features. This application has a generic > > > framework to add > > > +new test configurations and expand test coverage to verify the > > functionality > > > of graph nodes > > > +and observe the graph cluster statistics. > > > + > > > +Running the Application > > > +--- > > > + > > > +The application has a number of command line options: > > > + > > > +.. code-block:: console > > > + > > > + dpdk-test-eventdev [EAL Options] -- [application options] > > > + > > > +EAL Options > > > +~~~ > > > + > > > +The following are the EAL command-line options that can be used in > > > conjunction > > > +with the ``dpdk-test-graph`` application. > > > +See the DPDK Getting Started Guides for more information on these > > > options. > > > + > > > +* ``-c `` or ``-l `` > > > + > > > +Set the hexadecimal bitmask of the cores to run on. The corelist > > > is a > > > +list of cores to use. > > > + > > > +Application Options > > > +~~~ > > > + > > > +The following are the application command-line options: > > > + > > > +* ``-p `` > > > + > > > +Set the ethdev port mask. > > > + > > > +* ``-P`` > > > + > > > +Set the ethdev ports in promiscuous mode. > > > + > > > +* ``--config `` > > > + > > > +Set the Rxq configuration. > > > +(i.e. ``--config > > > (port_id,rxq,lcore_id)[,(port_id,rxq,lcore_id)]``). > > > + > > > +* ``--node-pattern `` > > > + > > > +Set the node patterns to use in graph creation. > > > +(i.e. ``--node-pattern (node_name0,node_name1[,node_nameX])``). It looks like this option is used to create a chain of nodes. Is my understanding correct ? If yes, then how can we create a node having two or more edges. Like in l3fwd-graph application, cls_node is further connected to pkt-drop and ip4_lookup. Packet can move to respective nodes based on runtime decision. If not, then how above option should be used for the same ? > > > + > > > +* ``--per-port-pool`` > > > + > > > +Use separate buffer pool per port. > > > + > > > +* ``--no-numa`` > > > + > > > +Disable numa awareness. > > > + > > > +* ``--interactive`` > > > + > > > +Switch to interactive mode. > > > + > > > +Running the Tool > > > + > > > + > > > +Here is the sample command line to run simple iofwd test:: > > > + > > > + ./dpdk-test-graph -a 0002:03:00.0 -a 0002:04:00.0 -c 0xF -- -p > > > 0x3 -P > \ > > > + --config "(0,0,2),(1,0,2)" --node-pattern "(ethdev_rx,ethdev_tx)" > > > + > > > +Below is a sample command line to punt rx packets to kernel:: > > > + > > > + ./dpdk-test-graph -a 0002:03:00.0 -a 0002:04:00.0 -c 0
Re: [RFC PATCH v2 3/4] dts: add doc generation
On Fri, May 5, 2023 at 3:29 PM Bruce Richardson
wrote:
>
> On Fri, May 05, 2023 at 01:13:34PM +0200, Juraj Linkeš wrote:
> > On Fri, May 5, 2023 at 12:57 PM Bruce Richardson
> > wrote:
> > >
> > > On Thu, May 04, 2023 at 02:37:48PM +0200, Juraj Linkeš wrote:
> > > > The tool used to generate developer docs is sphinx, which is already
> > > > used in DPDK. The configuration is kept the same to preserve the style.
> > > >
> > > > Sphinx generates the documentation from Python docstrings. The docstring
> > > > format most suitable for DTS seems to be the Google format [0] which
> > > > requires the sphinx.ext.napoleon extension.
> > > >
> > > > There are two requirements for building DTS docs:
> > > > * The same Python version as DTS or higher, because Sphinx import the
> > > > code.
> > > > * Also the same Python packages as DTS, for the same reason.
> > > >
> > > > [0]
> > > > https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings
> > > >
> > > > Signed-off-by: Juraj Linkeš
> > > > ---
> > > > doc/api/meson.build | 1 +
> > > > doc/guides/conf.py | 22 ++
> > > > doc/guides/meson.build | 1 +
> > > > doc/guides/tools/dts.rst | 29 +++
> > > > dts/doc/doc-index.rst| 20
> > > > dts/doc/meson.build | 50
> > > > dts/meson.build | 16 +
> > > > meson.build | 1 +
> > > > meson_options.txt| 2 ++
> > > > 9 files changed, 137 insertions(+), 5 deletions(-)
> > > > create mode 100644 dts/doc/doc-index.rst
> > > > create mode 100644 dts/doc/meson.build
> > > > create mode 100644 dts/meson.build
> > > >
> > >
> > >
> > > > diff --git a/dts/doc/meson.build b/dts/doc/meson.build
> > > > new file mode 100644
> > > > index 00..db2bb0bed9
> > > > --- /dev/null
> > > > +++ b/dts/doc/meson.build
> > > > @@ -0,0 +1,50 @@
> > > > +# SPDX-License-Identifier: BSD-3-Clause
> > > > +# Copyright(c) 2023 PANTHEON.tech s.r.o.
> > > > +
> > > > +sphinx = find_program('sphinx-build', required:
> > > > get_option('enable_dts_docs'))
> > > > +sphinx_apidoc = find_program('sphinx-apidoc', required:
> > > > get_option('enable_dts_docs'))
> > > > +
> > > > +if sphinx.found() and sphinx_apidoc.found()
> > > > +endif
> > > > +
> > > > +dts_api_framework_dir = join_paths(dts_dir, 'framework')
> > > > +dts_api_build_dir = join_paths(doc_api_build_dir, 'dts')
> > > > +dts_api_src = custom_target('dts_api_src',
> > > > +output: 'modules.rst',
> > > > +command: ['SPHINX_APIDOC_OPTIONS=members,show-inheritance',
> > >
> > > This gives errors when I try to configure a build, even without docs
> > > enabled.
> > >
> > > ~/dpdk.org$ meson setup build-test
> > > The Meson build system
> > > Version: 1.0.1
> > > Source dir: /home/bruce/dpdk.org
> > > ...
> > > Program sphinx-build found: YES (/usr/bin/sphinx-build)
> > > Program sphinx-build found: YES (/usr/bin/sphinx-build)
> > > Program sphinx-apidoc found: YES (/usr/bin/sphinx-apidoc)
> > >
> > > dts/doc/meson.build:12:0: ERROR: Program
> > > 'SPHINX_APIDOC_OPTIONS=members,show-inheritance' not found or not
> > > executable
> > >
> > > A full log can be found at
> > > /home/bruce/dpdk.org/build-test/meson-logs/meson-log.txt
> > >
> > > Assuming these need to be set in the environment, I think you can use the
> > > "env" parameter to custom target instead.
> > >
> >
> > I used meson 0.53.2 as that seemed to be the version I should target
> > (it's used in .ci/linux-setup.sh) which doesn't support the argument
> > (I originally wanted to use it, but they added it in 0.57.0). I didn't
> > see the error with 0.53.2.
> >
> > Which version should I target? 1.0.1?
> >
> > > > +sphinx_apidoc, '--append-syspath', '--force',
> > > > +'--module-first', '--separate',
> > > > +'--doc-project', 'DTS', '-V', meson.project_version(),
> > > > +'-o', dts_api_build_dir,
> > > > +dts_api_framework_dir],
> > > > +build_by_default: get_option('enable_dts_docs'))
> > > > +doc_targets += dts_api_src
> > > > +doc_target_names += 'DTS_API_sphinx_sources'
> > > > +
>
> I didn't try with 0.53.2 - let me test that, see if the error goes away. We
> may need different calls based on the meson version.
>
> Is there no other way to pass this data rather than via the environment?
>
Certainly. For background, I wanted to do the same thing we do for
DPDK_VERSION, but that would require adding an additional parameter to
call-sphinx-build.py, which wouldn't be used by the other call of
call-sphinx-build.py (the one that builds doc guides), so I skipped
the parameter and set the env var before the call.
There are a few options that come to mind:
1. Use the parameter. There are two sub-options here, either make the
parameter positional and mandatory and then we'd have an
[PATCH v6 0/3] add telemetry cmds for ring
This patch set supports telemetry cmd to list rings and dump information of a ring by its name. v1->v2: 1. Add space after "switch". 2. Fix wrong strlen parameter. v2->v3: 1. Remove prefix "rte_" for static function. 2. Add Acked-by Konstantin Ananyev for PATCH 1. 3. Introduce functions to return strings instead copy strings. 4. Check pointer to memzone of ring. 5. Remove redundant variable. 6. Hold lock when access ring data. v3->v4: 1. Update changelog according to reviews of Honnappa Nagarahalli. 2. Add Reviewed-by Honnappa Nagarahalli. 3. Correct grammar in help information. 4. Correct spell warning on "te" reported by checkpatch.pl. 5. Use ring_walk() to query ring info instead of rte_ring_lookup(). 6. Fix that type definition the flag field of rte_ring does not match the usage. 7. Use rte_tel_data_add_dict_uint_hex instead of rte_tel_data_add_dict_u64 for mask and flags. v4->v5: 1. Add Acked-by Konstantin Ananyev and Chengwen Feng. 2. Add ABI change explanation for commit message of patch 1/3. v5->v6: 1. Add Acked-by Morten Brørup. 2. Fix incorrect reference of commit. Jie Hai (3): ring: fix unmatched type definition and usage ring: add telemetry cmd to list rings ring: add telemetry cmd for ring info lib/ring/meson.build | 1 + lib/ring/rte_ring.c | 139 +++ lib/ring/rte_ring_core.h | 2 +- 3 files changed, 141 insertions(+), 1 deletion(-) -- 2.33.0
[PATCH v6 1/3] ring: fix unmatched type definition and usage
Field 'flags' of struct rte_ring is defined as int type. However,
it is used as unsigned int. To ensure consistency, change the
type of flags to unsigned int. Since these two types has the
same byte size, this change is not an ABI change.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Jie Hai
Acked-by: Konstantin Ananyev
Acked-by: Chengwen Feng
Acked-by: Morten Brørup
---
lib/ring/rte_ring_core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/ring/rte_ring_core.h b/lib/ring/rte_ring_core.h
index 82b237091b71..1c809abeb531 100644
--- a/lib/ring/rte_ring_core.h
+++ b/lib/ring/rte_ring_core.h
@@ -120,7 +120,7 @@ struct rte_ring_hts_headtail {
struct rte_ring {
char name[RTE_RING_NAMESIZE] __rte_cache_aligned;
/**< Name of the ring. */
- int flags; /**< Flags supplied at creation. */
+ uint32_t flags; /**< Flags supplied at creation. */
const struct rte_memzone *memzone;
/**< Memzone, if any, containing the rte_ring */
uint32_t size; /**< Size of ring. */
--
2.33.0
[PATCH v6 3/3] ring: add telemetry cmd for ring info
This patch supports dump of ring information by its name.
An example using this command is shown below:
--> /ring/info,MP_mb_pool_0
{
"/ring/info": {
"name": "MP_mb_pool_0",
"socket": 0,
"flags": "0x0",
"producer_type": "MP",
"consumer_type": "MC",
"size": 262144,
"mask": "0x3",
"capacity": 262143,
"used_count": 153197,
"consumer_tail": 2259,
"consumer_head": 2259,
"producer_tail": 155456,
"producer_head": 155456,
"mz_name": "RG_MP_mb_pool_0",
"mz_len": 2097536,
"mz_hugepage_sz": 1073741824,
"mz_socket_id": 0,
"mz_flags": "0x0"
}
}
Signed-off-by: Jie Hai
Reviewed-by: Honnappa Nagarahalli
Acked-by: Konstantin Ananyev
Acked-by: Huisong Li
Acked-by: Chengwen Feng
Acked-by: Morten Brørup
---
lib/ring/rte_ring.c | 99 +
1 file changed, 99 insertions(+)
diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c
index 0e83d0099363..26c8f2a2e6a2 100644
--- a/lib/ring/rte_ring.c
+++ b/lib/ring/rte_ring.c
@@ -455,8 +455,107 @@ ring_handle_list(const char *cmd __rte_unused,
return 0;
}
+static const char *
+ring_prod_sync_type_to_name(struct rte_ring *r)
+{
+ switch (r->prod.sync_type) {
+ case RTE_RING_SYNC_MT:
+ return "MP";
+ case RTE_RING_SYNC_ST:
+ return "SP";
+ case RTE_RING_SYNC_MT_RTS:
+ return "MP_RTS";
+ case RTE_RING_SYNC_MT_HTS:
+ return "MP_HTS";
+ default:
+ return "Unknown";
+ }
+}
+
+static const char *
+ring_cons_sync_type_to_name(struct rte_ring *r)
+{
+ switch (r->cons.sync_type) {
+ case RTE_RING_SYNC_MT:
+ return "MC";
+ case RTE_RING_SYNC_ST:
+ return "SC";
+ case RTE_RING_SYNC_MT_RTS:
+ return "MC_RTS";
+ case RTE_RING_SYNC_MT_HTS:
+ return "MC_HTS";
+ default:
+ return "Unknown";
+ }
+}
+
+struct ring_info_cb_arg {
+ char *ring_name;
+ struct rte_tel_data *d;
+};
+
+static void
+ring_info_cb(struct rte_ring *r, void *arg)
+{
+ struct ring_info_cb_arg *ring_arg = (struct ring_info_cb_arg *)arg;
+ struct rte_tel_data *d = ring_arg->d;
+ const struct rte_memzone *mz;
+
+ if (strncmp(r->name, ring_arg->ring_name, RTE_RING_NAMESIZE))
+ return;
+
+ rte_tel_data_add_dict_string(d, "name", r->name);
+ rte_tel_data_add_dict_int(d, "socket", r->memzone->socket_id);
+ rte_tel_data_add_dict_uint_hex(d, "flags", r->flags, 0);
+ rte_tel_data_add_dict_string(d, "producer_type",
+ ring_prod_sync_type_to_name(r));
+ rte_tel_data_add_dict_string(d, "consumer_type",
+ ring_cons_sync_type_to_name(r));
+ rte_tel_data_add_dict_uint(d, "size", r->size);
+ rte_tel_data_add_dict_uint_hex(d, "mask", r->mask, 0);
+ rte_tel_data_add_dict_uint(d, "capacity", r->capacity);
+ rte_tel_data_add_dict_uint(d, "used_count", rte_ring_count(r));
+ rte_tel_data_add_dict_uint(d, "consumer_tail", r->cons.tail);
+ rte_tel_data_add_dict_uint(d, "consumer_head", r->cons.head);
+ rte_tel_data_add_dict_uint(d, "producer_tail", r->prod.tail);
+ rte_tel_data_add_dict_uint(d, "producer_head", r->prod.head);
+
+ mz = r->memzone;
+ if (mz == NULL)
+ return;
+ rte_tel_data_add_dict_string(d, "mz_name", mz->name);
+ rte_tel_data_add_dict_uint(d, "mz_len", mz->len);
+ rte_tel_data_add_dict_uint(d, "mz_hugepage_sz", mz->hugepage_sz);
+ rte_tel_data_add_dict_int(d, "mz_socket_id", mz->socket_id);
+ rte_tel_data_add_dict_uint_hex(d, "mz_flags", mz->flags, 0);
+}
+
+static int
+ring_handle_info(const char *cmd __rte_unused, const char *params,
+ struct rte_tel_data *d)
+{
+ char name[RTE_RING_NAMESIZE] = {0};
+ struct ring_info_cb_arg ring_arg;
+
+ if (params == NULL || strlen(params) == 0 ||
+ strlen(params) >= RTE_RING_NAMESIZE)
+ return -EINVAL;
+
+ rte_strlcpy(name, params, RTE_RING_NAMESIZE);
+
+ ring_arg.ring_name = name;
+ ring_arg.d = d;
+
+ rte_tel_data_start_dict(d);
+ ring_walk(ring_info_cb, &ring_arg);
+
+ return 0;
+}
+
RTE_INIT(ring_init_telemetry)
{
rte_telemetry_register_cmd("/ring/list", ring_handle_list,
"Returns list of available rings. Takes no parameters");
+ rte_telemetry_register_cmd("/ring/info", ring_handle_info,
+ "Returns ring info. Parameters: ring_name.");
}
--
2.33.0
[PATCH v6 2/3] ring: add telemetry cmd to list rings
Add a telemetry command to list the rings used in the system.
An example using this command is shown below:
--> /ring/list
{
"/ring/list": [
"HT_:7d:00.2",
"MP_mb_pool_0"
]
}
Signed-off-by: Jie Hai
Acked-by: Konstantin Ananyev
Reviewed-by: Honnappa Nagarahalli
Acked-by: Huisong Li
Acked-by: Chengwen Feng
Acked-by: Morten Brørup
---
lib/ring/meson.build | 1 +
lib/ring/rte_ring.c | 40
2 files changed, 41 insertions(+)
diff --git a/lib/ring/meson.build b/lib/ring/meson.build
index c20685c689ac..7fca958ed7fa 100644
--- a/lib/ring/meson.build
+++ b/lib/ring/meson.build
@@ -18,3 +18,4 @@ indirect_headers += files (
'rte_ring_rts.h',
'rte_ring_rts_elem_pvt.h',
)
+deps += ['telemetry']
diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c
index 8ed455043dee..0e83d0099363 100644
--- a/lib/ring/rte_ring.c
+++ b/lib/ring/rte_ring.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "rte_ring.h"
#include "rte_ring_elem.h"
@@ -420,3 +421,42 @@ rte_ring_lookup(const char *name)
return r;
}
+
+static void
+ring_walk(void (*func)(struct rte_ring *, void *), void *arg)
+{
+ struct rte_ring_list *ring_list;
+ struct rte_tailq_entry *tailq_entry;
+
+ ring_list = RTE_TAILQ_CAST(rte_ring_tailq.head, rte_ring_list);
+ rte_mcfg_tailq_read_lock();
+
+ TAILQ_FOREACH(tailq_entry, ring_list, next) {
+ (*func)((struct rte_ring *) tailq_entry->data, arg);
+ }
+
+ rte_mcfg_tailq_read_unlock();
+}
+
+static void
+ring_list_cb(struct rte_ring *r, void *arg)
+{
+ struct rte_tel_data *d = (struct rte_tel_data *)arg;
+
+ rte_tel_data_add_array_string(d, r->name);
+}
+
+static int
+ring_handle_list(const char *cmd __rte_unused,
+ const char *params __rte_unused, struct rte_tel_data *d)
+{
+ rte_tel_data_start_array(d, RTE_TEL_STRING_VAL);
+ ring_walk(ring_list_cb, d);
+ return 0;
+}
+
+RTE_INIT(ring_init_telemetry)
+{
+ rte_telemetry_register_cmd("/ring/list", ring_handle_list,
+ "Returns list of available rings. Takes no parameters");
+}
--
2.33.0
Re: [RFC PATCH v2 3/4] dts: add doc generation
On Tue, May 09, 2023 at 11:23:50AM +0200, Juraj Linkeš wrote:
> On Fri, May 5, 2023 at 3:29 PM Bruce Richardson
> wrote:
> >
> > On Fri, May 05, 2023 at 01:13:34PM +0200, Juraj Linkeš wrote:
> > > On Fri, May 5, 2023 at 12:57 PM Bruce Richardson
> > > wrote:
> > > >
> > > > On Thu, May 04, 2023 at 02:37:48PM +0200, Juraj Linkeš wrote:
> > > > > The tool used to generate developer docs is sphinx, which is already
> > > > > used in DPDK. The configuration is kept the same to preserve the
> > > > > style.
> > > > >
> > > > > Sphinx generates the documentation from Python docstrings. The
> > > > > docstring
> > > > > format most suitable for DTS seems to be the Google format [0] which
> > > > > requires the sphinx.ext.napoleon extension.
> > > > >
> > > > > There are two requirements for building DTS docs:
> > > > > * The same Python version as DTS or higher, because Sphinx import the
> > > > > code.
> > > > > * Also the same Python packages as DTS, for the same reason.
> > > > >
> > > > > [0]
> > > > > https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings
> > > > >
> > > > > Signed-off-by: Juraj Linkeš
> > > > > ---
> > > > > doc/api/meson.build | 1 +
> > > > > doc/guides/conf.py | 22 ++
> > > > > doc/guides/meson.build | 1 +
> > > > > doc/guides/tools/dts.rst | 29 +++
> > > > > dts/doc/doc-index.rst| 20
> > > > > dts/doc/meson.build | 50
> > > > >
> > > > > dts/meson.build | 16 +
> > > > > meson.build | 1 +
> > > > > meson_options.txt| 2 ++
> > > > > 9 files changed, 137 insertions(+), 5 deletions(-)
> > > > > create mode 100644 dts/doc/doc-index.rst
> > > > > create mode 100644 dts/doc/meson.build
> > > > > create mode 100644 dts/meson.build
> > > > >
> > > >
> > > >
> > > > > diff --git a/dts/doc/meson.build b/dts/doc/meson.build
> > > > > new file mode 100644
> > > > > index 00..db2bb0bed9
> > > > > --- /dev/null
> > > > > +++ b/dts/doc/meson.build
> > > > > @@ -0,0 +1,50 @@
> > > > > +# SPDX-License-Identifier: BSD-3-Clause
> > > > > +# Copyright(c) 2023 PANTHEON.tech s.r.o.
> > > > > +
> > > > > +sphinx = find_program('sphinx-build', required:
> > > > > get_option('enable_dts_docs'))
> > > > > +sphinx_apidoc = find_program('sphinx-apidoc', required:
> > > > > get_option('enable_dts_docs'))
> > > > > +
> > > > > +if sphinx.found() and sphinx_apidoc.found()
> > > > > +endif
> > > > > +
> > > > > +dts_api_framework_dir = join_paths(dts_dir, 'framework')
> > > > > +dts_api_build_dir = join_paths(doc_api_build_dir, 'dts')
> > > > > +dts_api_src = custom_target('dts_api_src',
> > > > > +output: 'modules.rst',
> > > > > +command: ['SPHINX_APIDOC_OPTIONS=members,show-inheritance',
> > > >
> > > > This gives errors when I try to configure a build, even without docs
> > > > enabled.
> > > >
> > > > ~/dpdk.org$ meson setup build-test
> > > > The Meson build system
> > > > Version: 1.0.1
> > > > Source dir: /home/bruce/dpdk.org
> > > > ...
> > > > Program sphinx-build found: YES (/usr/bin/sphinx-build)
> > > > Program sphinx-build found: YES (/usr/bin/sphinx-build)
> > > > Program sphinx-apidoc found: YES (/usr/bin/sphinx-apidoc)
> > > >
> > > > dts/doc/meson.build:12:0: ERROR: Program
> > > > 'SPHINX_APIDOC_OPTIONS=members,show-inheritance' not found or not
> > > > executable
> > > >
> > > > A full log can be found at
> > > > /home/bruce/dpdk.org/build-test/meson-logs/meson-log.txt
> > > >
> > > > Assuming these need to be set in the environment, I think you can use
> > > > the
> > > > "env" parameter to custom target instead.
> > > >
> > >
> > > I used meson 0.53.2 as that seemed to be the version I should target
> > > (it's used in .ci/linux-setup.sh) which doesn't support the argument
> > > (I originally wanted to use it, but they added it in 0.57.0). I didn't
> > > see the error with 0.53.2.
> > >
> > > Which version should I target? 1.0.1?
> > >
> > > > > +sphinx_apidoc, '--append-syspath', '--force',
> > > > > +'--module-first', '--separate',
> > > > > +'--doc-project', 'DTS', '-V', meson.project_version(),
> > > > > +'-o', dts_api_build_dir,
> > > > > +dts_api_framework_dir],
> > > > > +build_by_default: get_option('enable_dts_docs'))
> > > > > +doc_targets += dts_api_src
> > > > > +doc_target_names += 'DTS_API_sphinx_sources'
> > > > > +
> >
> > I didn't try with 0.53.2 - let me test that, see if the error goes away. We
> > may need different calls based on the meson version.
> >
> > Is there no other way to pass this data rather than via the environment?
> >
>
> Certainly. For background, I wanted to do the same thing we do for
> DPDK_VERSION, but that would require adding an additional parameter to
> call-sphinx-build.py, whi
Re: DPDK 22.11 Troubleshooting
On Mon, May 08, 2023 at 11:26:59PM +, Gilbert Carrillo wrote: > > > -Original Message- > From: Bruce Richardson > Sent: Wednesday, May 3, 2023 11:18 AM > To: Gilbert Carrillo > Cc: dev@dpdk.org > Subject: Re: DPDK 22.11 Troubleshooting > > On Wed, May 03, 2023 at 04:53:20PM +, Gilbert Carrillo wrote: > > Make static returns an error (see attached). > > > > v/R, > > Gilbert > > > > To help investigate this issue, can you perhaps include the text of the full > build output when you run "make static". On my system I see libelf listed on > the linker flags when I run "make static", and things link properly. I'm > wondering how my setup may differ from yours. > > /Bruce > > > -Original Message- > > From: Bruce Richardson > > Sent: Wednesday, May 3, 2023 10:35 AM > > To: Gilbert Carrillo > > Cc: dev@dpdk.org > > Subject: Re: DPDK 22.11 Troubleshooting > > > > On Wed, May 03, 2023 at 04:22:05PM +, Gilbert Carrillo wrote: > > > Hi Bruce, > > > > > > Thank you for the response. > > > > > > There is no errors when I run the makefile, however I do see a difference > > > in the programs. I don't believe the makefile is linking all the > > > libraries together as intended. > > > > > > For example, when I run the ethtool sample program and compile it using > > > meson, it works fine and rte_eth_dev_count_avail() returns the correct > > > amount. However, when I compile ethtool with the makefile and run it > > > rte_eth_dev_count_avail() returns 0. > > > > > > > Note that by default the meson build will statically link the examples, > > while the makefile will dynamically load the drivers at runtime. That may > > explain the difference. Can you try building and running using "make > > static" rather than just "make". > > > > /Bruce > > Bruce, > > I had multiple versions of DPDK installed and I was linking the wrong one. I > was able to compile my application with CMAKE successfully. > > I had one last quick question. I am trying to achieve zero copy DMA from my > FPGA to my external buffer. Is this possible? I saw methods such as attaching > an mbuf to the external buffer? But I wasn't sure if this was truly zero copy. > Attaching an mbuf to an external buffer would not involve any copy of the data itself, so should be zero-copy. Each mbuf header contains a buffer pointer, which normally points just to the end of the header structure, but which can point to any other location in memory. /Bruce
RE: [PATCH v4 1/4] bus/cdx: introduce cdx bus
[AMD Official Use Only - General] > -Original Message- > From: Xia, Chenbo > Sent: Tuesday, May 9, 2023 12:25 PM > To: Gupta, Nipun ; dev@dpdk.org; > tho...@monjalon.net; david.march...@redhat.com > Cc: Yigit, Ferruh ; Anand, Harpreet > ; Agarwal, Nikhil > Subject: RE: [PATCH v4 1/4] bus/cdx: introduce cdx bus > > Caution: This message originated from an External Source. Use proper > caution when opening attachments, clicking links, or responding. > > > > -Original Message- > > From: Nipun Gupta > > Sent: Monday, May 8, 2023 7:18 PM > > To: dev@dpdk.org; tho...@monjalon.net; david.march...@redhat.com > > Cc: ferruh.yi...@amd.com; harpreet.an...@amd.com; > nikhil.agar...@amd.com; > > Nipun Gupta > > Subject: [PATCH v4 1/4] bus/cdx: introduce cdx bus > > > > CDX bus supports multiple type of devices, which can be > > exposed to user-space via vfio-cdx. > > > > vfio-cdx provides the MMIO IO_MEMORY regions as well as the > > DMA interface for the device (IOMMU). > > > > This support aims to enable the DPDK to support the cdx > > devices in user-space using VFIO interface. > > > > Signed-off-by: Nipun Gupta > > --- > > MAINTAINERS| 5 + > > doc/guides/rel_notes/release_23_07.rst | 6 + > > drivers/bus/cdx/bus_cdx_driver.h | 201 ++ > > drivers/bus/cdx/cdx.c | 520 + > > drivers/bus/cdx/cdx_logs.h | 37 ++ > > drivers/bus/cdx/cdx_vfio.c | 437 + > > drivers/bus/cdx/meson.build| 13 + > > drivers/bus/cdx/private.h | 49 +++ > > drivers/bus/cdx/version.map| 11 + > > drivers/bus/meson.build| 1 + > > 10 files changed, 1280 insertions(+) > > create mode 100644 drivers/bus/cdx/bus_cdx_driver.h > > create mode 100644 drivers/bus/cdx/cdx.c > > create mode 100644 drivers/bus/cdx/cdx_logs.h > > create mode 100644 drivers/bus/cdx/cdx_vfio.c > > create mode 100644 drivers/bus/cdx/meson.build > > create mode 100644 drivers/bus/cdx/private.h > > create mode 100644 drivers/bus/cdx/version.map > > > > ... > > > --- /dev/null > > +++ b/drivers/bus/cdx/cdx.c > > @@ -0,0 +1,520 @@ > > +/* SPDX-License-Identifier: BSD-3-Clause > > + * Copyright (C) 2022-2023, Advanced Micro Devices, Inc. > > + */ > > + > > +/* > > + * Architecture Overview > > + * = > > + * CDX is a Hardware Architecture designed for AMD FPGA devices. It > > + * consists of sophisticated mechanism for interaction between FPGA, > > + * Firmware and the APUs (Application CPUs). > > + * > > + * Firmware resides on RPU (Realtime CPUs) which interacts with > > + * the FPGA program manager and the APUs. The RPU provides memory- > mapped > > + * interface (RPU if) which is used to communicate with APUs. > > + * > > + * The diagram below shows an overview of the CDX architecture: > > + * > > + * +--+ > > + * | DPDK | > > + * |DPDK CDX drivers | > > + * | || > > + * | DPDK CDX bus| > > + * | || > > + * +-|+ > > + *| > > + * +-|+ > > + * |Application CPUs (APU) || > > + * | || > > + * | VFIO CDX driver | > > + * | Linux OS|| > > + * | Linux CDX bus | > > + * | || > > + * +-|+ > > + *| > > + *| > > + * +| RPU if |+ > > + * | || > > + * | V| > > + * | Realtime CPUs (RPU) | > > + * | | > > + * +--+ > > + *| > > + * +-|+ > > + * | FPGA || > > + * | +---+ | > > + * | | | | | > > + * | +---++---+ +---+ | > > + * | | dev 1 || dev 2 | | dev 3 | | > > + * | +---++---+ +---+ | > > + * +--+ > > + * > > + * The RPU firmware extracts the device information from the loaded > FPGA > > + * image and implements a mechanism that allows the APU drivers to > > + * enumerate such devices (device personality
Re: [PATCH v4 1/4] bus/cdx: introduce cdx bus
On 5/9/2023 12:09 PM, Gupta, Nipun wrote: > [AMD Official Use Only - General] > > > >> -Original Message- >> From: Xia, Chenbo >> Sent: Tuesday, May 9, 2023 12:25 PM >> To: Gupta, Nipun ; dev@dpdk.org; >> tho...@monjalon.net; david.march...@redhat.com >> Cc: Yigit, Ferruh ; Anand, Harpreet >> ; Agarwal, Nikhil >> Subject: RE: [PATCH v4 1/4] bus/cdx: introduce cdx bus >> >> Caution: This message originated from an External Source. Use proper >> caution when opening attachments, clicking links, or responding. >> >> >>> -Original Message- >>> From: Nipun Gupta >>> Sent: Monday, May 8, 2023 7:18 PM >>> To: dev@dpdk.org; tho...@monjalon.net; david.march...@redhat.com >>> Cc: ferruh.yi...@amd.com; harpreet.an...@amd.com; >> nikhil.agar...@amd.com; >>> Nipun Gupta >>> Subject: [PATCH v4 1/4] bus/cdx: introduce cdx bus >>> >>> CDX bus supports multiple type of devices, which can be >>> exposed to user-space via vfio-cdx. >>> >>> vfio-cdx provides the MMIO IO_MEMORY regions as well as the >>> DMA interface for the device (IOMMU). >>> >>> This support aims to enable the DPDK to support the cdx >>> devices in user-space using VFIO interface. >>> >>> Signed-off-by: Nipun Gupta >>> --- >>> MAINTAINERS| 5 + >>> doc/guides/rel_notes/release_23_07.rst | 6 + >>> drivers/bus/cdx/bus_cdx_driver.h | 201 ++ >>> drivers/bus/cdx/cdx.c | 520 + >>> drivers/bus/cdx/cdx_logs.h | 37 ++ >>> drivers/bus/cdx/cdx_vfio.c | 437 + >>> drivers/bus/cdx/meson.build| 13 + >>> drivers/bus/cdx/private.h | 49 +++ >>> drivers/bus/cdx/version.map| 11 + >>> drivers/bus/meson.build| 1 + >>> 10 files changed, 1280 insertions(+) >>> create mode 100644 drivers/bus/cdx/bus_cdx_driver.h >>> create mode 100644 drivers/bus/cdx/cdx.c >>> create mode 100644 drivers/bus/cdx/cdx_logs.h >>> create mode 100644 drivers/bus/cdx/cdx_vfio.c >>> create mode 100644 drivers/bus/cdx/meson.build >>> create mode 100644 drivers/bus/cdx/private.h >>> create mode 100644 drivers/bus/cdx/version.map >>> >> >> ... >> >>> --- /dev/null >>> +++ b/drivers/bus/cdx/cdx.c >>> @@ -0,0 +1,520 @@ >>> +/* SPDX-License-Identifier: BSD-3-Clause >>> + * Copyright (C) 2022-2023, Advanced Micro Devices, Inc. >>> + */ >>> + >>> +/* >>> + * Architecture Overview >>> + * = >>> + * CDX is a Hardware Architecture designed for AMD FPGA devices. It >>> + * consists of sophisticated mechanism for interaction between FPGA, >>> + * Firmware and the APUs (Application CPUs). >>> + * >>> + * Firmware resides on RPU (Realtime CPUs) which interacts with >>> + * the FPGA program manager and the APUs. The RPU provides memory- >> mapped >>> + * interface (RPU if) which is used to communicate with APUs. >>> + * >>> + * The diagram below shows an overview of the CDX architecture: >>> + * >>> + * +--+ >>> + * | DPDK | >>> + * |DPDK CDX drivers | >>> + * | || >>> + * | DPDK CDX bus| >>> + * | || >>> + * +-|+ >>> + *| >>> + * +-|+ >>> + * |Application CPUs (APU) || >>> + * | || >>> + * | VFIO CDX driver | >>> + * | Linux OS|| >>> + * | Linux CDX bus | >>> + * | || >>> + * +-|+ >>> + *| >>> + *| >>> + * +| RPU if |+ >>> + * | || >>> + * | V| >>> + * | Realtime CPUs (RPU) | >>> + * | | >>> + * +--+ >>> + *| >>> + * +-|+ >>> + * | FPGA || >>> + * | +---+ | >>> + * | | | | | >>> + * | +---++---+ +---+ | >>> + * | | dev 1 || dev 2 | | dev 3 | | >>> + * | +---++---+ +---+ | >>> + * +--+ >>> + * >>> + * The RPU firmware extracts the device information from the loaded >> FPGA >>> + * image and implements a mechanism that allows the AP
RE: [PATCH 12/14] crypto/caam_jr: use rte_pktmbuf_mtod_offset
Acked-by: Hemant Agrawal
min_mbuf_head/tailroom_req in rte_cryptodev_info
Hi Guys, Sorry for disturbing you. I have one small question regarding the min_mbuf_head/tailroom_req in rte_cryptodev_info. I saw you were the people who discussed, reviewed and added that two fields. IIUC, the two fields provided a hint to the PMD that HW can use(modify) the headroom and tailroom space to improve the performance. But regarding the space(e.g. headroom) user reserved, should the data offset(sym_op->aead.data.offset) in struct rte_crypto_op also be taken into account? e.g. if the mbuf in the operation is something like below: |---headroom--|op offset---|---payload to process---|---tailroom---| In that case, what is the headroom mean to HW? Start from real mbuf headroom before op offset or the offset before payload? Thanks, Suanming Mou
RE: min_mbuf_head/tailroom_req in rte_cryptodev_info
Hi Suanming, Please see inline. Thanks, Anoob > From: Suanming Mou > Sent: Tuesday, May 9, 2023 5:23 PM > To: Anoob Joseph ; Doherty, Declan > > Cc: Akhil Goyal ; dev@dpdk.org > Subject: [EXT] min_mbuf_head/tailroom_req in rte_cryptodev_info > > External Email > > Hi Guys, > > Sorry for disturbing you. I have one small question regarding the > min_mbuf_head/tailroom_req in rte_cryptodev_info. > I saw you were the people who discussed, reviewed and added that two fields. > IIUC, the two fields provided a hint to the PMD that HW can use(modify) the > headroom and tailroom space to improve the performance. [Anoob] That's right. > But regarding the space(e.g. headroom) user reserved, should the data > offset(sym_op->aead.data.offset) in struct rte_crypto_op also be taken into > account? > e.g. if the mbuf in the operation is something like below: > |---headroom--|op offset---|---payload to process---|---tailroom---| [Anoob] Above layout is correct. Headroom that can be used by cryptodev is the headroom of the mbuf. > In that case, what is the headroom mean to HW? Start from real mbuf headroom > before op offset or the offset before payload? [Anoob] May be let me explain how we use it in CNXK PMDs. We have to pass fields such as IV & offsets to the hardware for performing crypto operation. To maximize performance, we pass it as single buffer and hence the requirement on this headroom. In our enqueue path, we use headroom for storing some of these transient data. |---headroom--|-- packet_len -|---tailroom---| |---headroom--|op offset---|---payload to process---|---tailroom---| || < Space used by cryptodev for internal purpose ^ = rte_pktmbuf_mtod(mbuf, void *); All offsets mentioned in rte_crypto_op would be calculated from the packet start [rte_pktmbuf_mtod()]. In other words, the packet data from the start of the packet till offset would be untouched by the cryptodev in all circumstances. It is the space that is before start of the packet(ie headroom of mbuf) which would be used for this purpose. Hope it is clear now.
Re: [PATCH] usertools: add tool to generate balanced rss traffic flows
Hi all, Apart from me, is there any interest in this patch? :) Cheers
RE: [EXT] [PATCH v2 4/4] app: add testgraph application
> -Original Message- > From: Sunil Kumar Kori > Sent: Tuesday, May 9, 2023 2:24 PM > To: Vamsi Krishna Attunuru ; dev@dpdk.org; > tho...@monjalon.net; Jerin Jacob Kollanukkaran > Cc: Nithin Kumar Dabilpuram > Subject: RE: [EXT] [PATCH v2 4/4] app: add testgraph application > > > -Original Message- > > From: Vamsi Krishna Attunuru > > Sent: Tuesday, May 9, 2023 9:10 AM > > To: Sunil Kumar Kori ; dev@dpdk.org; > > tho...@monjalon.net; Jerin Jacob Kollanukkaran > > Cc: Nithin Kumar Dabilpuram > > Subject: RE: [EXT] [PATCH v2 4/4] app: add testgraph application > > > > > > > > > -Original Message- > > > From: Sunil Kumar Kori > > > Sent: Tuesday, May 9, 2023 8:04 AM > > > To: Vamsi Krishna Attunuru ; dev@dpdk.org; > > > tho...@monjalon.net; Jerin Jacob Kollanukkaran > > > Cc: Vamsi Krishna Attunuru ; Nithin Kumar > > > Dabilpuram > > > Subject: RE: [EXT] [PATCH v2 4/4] app: add testgraph application > > > > > > Is there any user guide similar to testpmd ? > > > > >Please refer doc/guides/tools/testgraph.rst for details. > > > Thanks. > > > > -Original Message- > > > > From: Vamsi Attunuru > > > > Sent: Tuesday, April 25, 2023 6:45 PM > > > > To: dev@dpdk.org; tho...@monjalon.net; Jerin Jacob Kollanukkaran > > > > > > > > Cc: Vamsi Krishna Attunuru ; Nithin Kumar > > > > Dabilpuram > > > > Subject: [EXT] [PATCH v2 4/4] app: add testgraph application > > > > > > > > External Email > > > > > > > > -- > > > > Patch adds test-graph application to validate graph and node > > > > libraries. > > > > > > > > Signed-off-by: Vamsi Attunuru > > > > --- > > > > app/meson.build|1 + > > > > app/test-graph/cmdline.c | 211 + > > > > app/test-graph/cmdline_graph.c | 294 +++ > > > > app/test-graph/cmdline_graph.h | 19 + > > > > app/test-graph/meson.build | 14 + > > > > app/test-graph/parameters.c| 157 > > > > app/test-graph/testgraph.c | 1426 > > > > > > > app/test-graph/testgraph.h | 91 ++ > > > > doc/guides/tools/index.rst |1 + > > > > doc/guides/tools/testgraph.rst | 131 +++ > > > > 10 files changed, 2345 insertions(+) > > > > > > [Code Snipped] > > > > > +++ b/doc/guides/tools/testgraph.rst > > > > @@ -0,0 +1,131 @@ > > > > +.. SPDX-License-Identifier: BSD-3-Clause > > > > +Copyright(C) 2023 Marvell International Ltd. > > > > + > > > > +dpdk-test-graph Application > > > > +=== > > > > + > > > > +The ``dpdk-test-graph`` tool is a Data Plane Development Kit > > > > +(DPDK) > > > > application that allows > > > > +exercising various graph library features. This application has a > > > > +generic > > > > framework to add > > > > +new test configurations and expand test coverage to verify the > > > functionality > > > > of graph nodes > > > > +and observe the graph cluster statistics. > > > > + > > > > +Running the Application > > > > +--- > > > > + > > > > +The application has a number of command line options: > > > > + > > > > +.. code-block:: console > > > > + > > > > + dpdk-test-eventdev [EAL Options] -- [application options] > > > > + > > > > +EAL Options > > > > +~~~ > > > > + > > > > +The following are the EAL command-line options that can be used > > > > +in > > > > conjunction > > > > +with the ``dpdk-test-graph`` application. > > > > +See the DPDK Getting Started Guides for more information on these > > > > options. > > > > + > > > > +* ``-c `` or ``-l `` > > > > + > > > > +Set the hexadecimal bitmask of the cores to run on. The > > > > corelist is > a > > > > +list of cores to use. > > > > + > > > > +Application Options > > > > +~~~ > > > > + > > > > +The following are the application command-line options: > > > > + > > > > +* ``-p `` > > > > + > > > > +Set the ethdev port mask. > > > > + > > > > +* ``-P`` > > > > + > > > > +Set the ethdev ports in promiscuous mode. > > > > + > > > > +* ``--config `` > > > > + > > > > +Set the Rxq configuration. > > > > +(i.e. ``--config > > > > (port_id,rxq,lcore_id)[,(port_id,rxq,lcore_id)]``). > > > > + > > > > +* ``--node-pattern `` > > > > + > > > > +Set the node patterns to use in graph creation. > > > > +(i.e. ``--node-pattern > (node_name0,node_name1[,node_nameX])``). > > It looks like this option is used to create a chain of nodes. Is my > understanding correct ? > Yes > If yes, then how can we create a node having two or more edges. > Like in l3fwd-graph application, cls_node is further connected to pkt-drop > and ip4_lookup. > Packet can move to respective nodes based on runtime decision. > > If not, then how above option should be used for the same ? --node-pattern option mainly provides the next node details(which test can configure in node_next details). To link other next nodes to th
RE: min_mbuf_head/tailroom_req in rte_cryptodev_info
Hi Anoob, Thanks for the quick response. Nice answering. I think I have fully understood the fields meaning. Many thanks again, Suanming > -Original Message- > From: Anoob Joseph > Sent: Tuesday, May 9, 2023 8:13 PM > To: Suanming Mou > Cc: Akhil Goyal ; dev@dpdk.org; Doherty, Declan > > Subject: RE: min_mbuf_head/tailroom_req in rte_cryptodev_info > > Hi Suanming, > > Please see inline. > > Thanks, > Anoob > > > From: Suanming Mou > > Sent: Tuesday, May 9, 2023 5:23 PM > > To: Anoob Joseph ; Doherty, Declan > > > Cc: Akhil Goyal ; dev@dpdk.org > > Subject: [EXT] min_mbuf_head/tailroom_req in rte_cryptodev_info > > > > External Email > > > > Hi Guys, > > > > Sorry for disturbing you. I have one small question regarding the > min_mbuf_head/tailroom_req in rte_cryptodev_info. > > I saw you were the people who discussed, reviewed and added that two fields. > > IIUC, the two fields provided a hint to the PMD that HW can use(modify) the > headroom and tailroom space to improve the performance. > [Anoob] That's right. > > > But regarding the space(e.g. headroom) user reserved, should the data > offset(sym_op->aead.data.offset) in struct rte_crypto_op also be taken into > account? > > e.g. if the mbuf in the operation is something like below: > > |---headroom--|op offset---|---payload to process---|---tailroom---| > > [Anoob] Above layout is correct. Headroom that can be used by cryptodev is the > headroom of the mbuf. > > > In that case, what is the headroom mean to HW? Start from real mbuf > headroom before op offset or the offset before payload? > > [Anoob] May be let me explain how we use it in CNXK PMDs. We have to pass > fields such as IV & offsets to the hardware for performing crypto operation. > To > maximize performance, we pass it as single buffer and hence the requirement on > this headroom. > > In our enqueue path, we use headroom for storing some of these transient data. > > |---headroom--|-- packet_len -|---tailroom---| > |---headroom--|op offset---|---payload to process---|---tailroom---| >|| < Space used by cryptodev for internal purpose > ^ = rte_pktmbuf_mtod(mbuf, void *); > > All offsets mentioned in rte_crypto_op would be calculated from the packet > start [rte_pktmbuf_mtod()]. In other words, the packet data from the start of > the packet till offset would be untouched by the cryptodev in all > circumstances. > It is the space that is before start of the packet(ie headroom of mbuf) which > would be used for this purpose. > > Hope it is clear now.
Re: [PATCH v2 07/14] net/nfp: use rte_pktmbuf_mtod_offset
Hi Stephen,
Thanks for your work.
On 2023-05-06 09:03:56 -0700, Stephen Hemminger wrote:
> Automatically generated by cocci/mtod-offset.cocci.
>
> Signed-off-by: Stephen Hemminger
Reviewed-by: Niklas Söderlund
> ---
> drivers/net/nfp/flower/nfp_flower_cmsg.h | 3 ++-
> drivers/net/nfp/flower/nfp_flower_ctrl.c | 4 ++--
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/nfp/flower/nfp_flower_cmsg.h
> b/drivers/net/nfp/flower/nfp_flower_cmsg.h
> index 96e080a8e956..5ae0e8be1d67 100644
> --- a/drivers/net/nfp/flower/nfp_flower_cmsg.h
> +++ b/drivers/net/nfp/flower/nfp_flower_cmsg.h
> @@ -380,7 +380,8 @@ enum nfp_flower_cmsg_port_vnic_type {
> static inline char*
> nfp_flower_cmsg_get_data(struct rte_mbuf *m)
> {
> - return rte_pktmbuf_mtod(m, char *) + 4 + 4 + NFP_FLOWER_CMSG_HLEN;
> + return rte_pktmbuf_mtod_offset(m, char *,
> +4 + 4 + NFP_FLOWER_CMSG_HLEN);
> }
>
> /*
> diff --git a/drivers/net/nfp/flower/nfp_flower_ctrl.c
> b/drivers/net/nfp/flower/nfp_flower_ctrl.c
> index 3e083d948edf..9a8e464a1d18 100644
> --- a/drivers/net/nfp/flower/nfp_flower_ctrl.c
> +++ b/drivers/net/nfp/flower/nfp_flower_ctrl.c
> @@ -234,7 +234,7 @@ nfp_flower_cmsg_rx_stats(struct nfp_flow_priv *flow_priv,
> uint32_t ctx_id;
> struct nfp_flower_stats_frame *stats;
>
> - msg = rte_pktmbuf_mtod(mbuf, char *) + NFP_FLOWER_CMSG_HLEN;
> + msg = rte_pktmbuf_mtod_offset(mbuf, char *, NFP_FLOWER_CMSG_HLEN);
> msg_len = mbuf->data_len - NFP_FLOWER_CMSG_HLEN;
> count = msg_len / sizeof(struct nfp_flower_stats_frame);
>
> @@ -257,7 +257,7 @@ nfp_flower_cmsg_rx_qos_stats(struct nfp_mtr_priv
> *mtr_priv,
> struct nfp_mtr *mtr;
> struct nfp_mtr_stats_reply *mtr_stats;
>
> - msg = rte_pktmbuf_mtod(mbuf, char *) + NFP_FLOWER_CMSG_HLEN;
> + msg = rte_pktmbuf_mtod_offset(mbuf, char *, NFP_FLOWER_CMSG_HLEN);
>
> mtr_stats = (struct nfp_mtr_stats_reply *)msg;
> profile_id = rte_be_to_cpu_32(mtr_stats->head.profile_id);
> --
> 2.39.2
>
--
Kind Regards,
Niklas Söderlund
[Bug 1227] KNI : memory-leaks, each time kni_rx_burst it is allocates new mbufs even if no needs.
https://bugs.dpdk.org/show_bug.cgi?id=1227 Bug ID: 1227 Summary: KNI : memory-leaks, each time kni_rx_burst it is allocates new mbufs even if no needs. Product: DPDK Version: 22.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: yasinnca...@gmail.com Target Milestone: --- Created attachment 251 --> https://bugs.dpdk.org/attachment.cgi?id=251&action=edit flow_kni_rx_burst Hello I tried to explain memory-leak via graph https://pastebin.ubuntu.com/p/s4h5psqtgZ/ scenario : 1. kni_alloc allocates 32 units (kni->alloc_q) then completes initialization 2. rte_kni_rx_burst receive 1 packet from kernel. 1 of 31 units is filled by message, 31 units is empty but it is allocated in kni->alloc_q. 3. rte_kni_rx_burst then allocates another 32 units i dont know why but there is a comment like this."If buffers removed, allocate mbufs and then put them into alloc_q" ( How to tests buffers are removed or not? there is not any query in code) 4. 1 message mbuf is transmited via rte_eth_tx_burst . 5. 1 message mbuf never back to freed and back to original memory pool. 31+32 units memory act like in use but they are not. never back to original memory pool 6. this cycle goes on to 2 . ? Why there is newer allocation in rte_kni_rx_burst i dont know. ? I tried to free 1 packet via rte_pktmbuf_free but sometimes corrupt to pool like below. sometimes 1 packet/unit back to original memory pool [UseCount_mpool:65][avail_mpool:10334] [UseCount_mpool:4294967135][avail_mpool:10560] ? In my view, after transmiting message to mbufs should be in to kni->free_q. ? in my view, there is missing query in func kni_allocate_mbufs to test alloc_q is empty or not. Best regards. -- You are receiving this mail because: You are the assignee for the bug.
Re: DPDK 22.11 Troubleshooting
On Tue, May 09, 2023 at 02:16:39PM +, Gilbert Carrillo wrote: > > > -Original Message- > From: Bruce Richardson > Sent: Tuesday, May 9, 2023 3:43 AM > To: Gilbert Carrillo > Cc: dev@dpdk.org > Subject: Re: DPDK 22.11 Troubleshooting > > On Mon, May 08, 2023 at 11:26:59PM +, Gilbert Carrillo wrote: > > > > > > -Original Message- > > From: Bruce Richardson > > Sent: Wednesday, May 3, 2023 11:18 AM > > To: Gilbert Carrillo > > Cc: dev@dpdk.org > > Subject: Re: DPDK 22.11 Troubleshooting > > > > On Wed, May 03, 2023 at 04:53:20PM +, Gilbert Carrillo wrote: > > > Make static returns an error (see attached). > > > > > > v/R, > > > Gilbert > > > > > > > To help investigate this issue, can you perhaps include the text of the > > full build output when you run "make static". On my system I see libelf > > listed on the linker flags when I run "make static", and things link > > properly. I'm wondering how my setup may differ from yours. > > > > /Bruce > > > > > -Original Message- > > > From: Bruce Richardson > > > Sent: Wednesday, May 3, 2023 10:35 AM > > > To: Gilbert Carrillo > > > Cc: dev@dpdk.org > > > Subject: Re: DPDK 22.11 Troubleshooting > > > > > > On Wed, May 03, 2023 at 04:22:05PM +, Gilbert Carrillo wrote: > > > > Hi Bruce, > > > > > > > > Thank you for the response. > > > > > > > > There is no errors when I run the makefile, however I do see a > > > > difference in the programs. I don't believe the makefile is linking all > > > > the libraries together as intended. > > > > > > > > For example, when I run the ethtool sample program and compile it using > > > > meson, it works fine and rte_eth_dev_count_avail() returns the correct > > > > amount. However, when I compile ethtool with the makefile and run it > > > > rte_eth_dev_count_avail() returns 0. > > > > > > > > > > Note that by default the meson build will statically link the examples, > > > while the makefile will dynamically load the drivers at runtime. That may > > > explain the difference. Can you try building and running using "make > > > static" rather than just "make". > > > > > > /Bruce > > > > Bruce, > > > > I had multiple versions of DPDK installed and I was linking the wrong one. > > I was able to compile my application with CMAKE successfully. > > > > I had one last quick question. I am trying to achieve zero copy DMA from my > > FPGA to my external buffer. Is this possible? I saw methods such as > > attaching an mbuf to the external buffer? But I wasn't sure if this was > > truly zero copy. > > > Attaching an mbuf to an external buffer would not involve any copy of the > data itself, so should be zero-copy. Each mbuf header contains a buffer > pointer, which normally points just to the end of the header structure, but > which can point to any other location in memory. > > /Bruce > > > Thank you, Bruce. Is attaching an mbuf to my external buffer the only way to > achieve this zero copy DMA? I also read that there is a function > rte_pktmbuf_read() that can read the data from my FPGA directly to my > external buffer, but I don't think this method is zero copy since it requires > the CPU to copy the data. > Can you set up your FPGA to DMA directly to a DPDK buffer? This is the method used by all DPDK devices: NICS, crypto accelerators, DMA accelerators, etc. /Bruce
Re: [RFC PATCH v2 0/4] dts: add dts api docs
On Fri, May 5, 2023 at 4:07 PM Bruce Richardson
wrote:
>
> On Thu, May 04, 2023 at 02:37:45PM +0200, Juraj Linkeš wrote:
> > Augment the meson build system with dts api generation. The api docs are
> > generated from Python docstrings in DTS using Sphinx. The format of
> > choice is the Google format [0].
> >
> > The guide html sphinx configuration is used to preserve the same style.
> >
> > The build requires the same Python version and dependencies as DTS,
> > because Sphinx imports the Python modules. Dependencies are installed
> > using Poetry from the dts directory:
> >
> > poetry install --with docs
> >
> > After installing, enter the Poetry shell:
> >
> > poetry shell
> >
> > And then run the build:
> > ninja -C dts/doc
> >
> > There's only one properly documented module that serves as a
> > demonstration of the style - framework.testbed_model.node.
> >
> > [0]
> > https://google.github.io/styleguide/pyguide.html#s3.8.4-comments-in-classes
> >
> > Juraj Linkeš (4):
> > dts: code adjustments for sphinx
> > dts: add doc generation dependencies
> > dts: add doc generation
> > dts: format docstrigs to google format
> >
>
> I find the requirement to use poetry to build the docs, and the need to run
> specific commands in specific directories quite awkward. With this patchset
> there is no ability to just turn on the build option for the DTS doc and
> have the docs built on the next rebuild. [Also, with every build I've tried
> I can't get it to build without warnings about missing "warlock" module.]
>
> From what I understand from the patchset, the doc building here using
> sphinx is primarily concerned with building the API docs. The rest of DPDK
> uses doxygen for this, and since doxygen supports python can the same
> tooling be used for the DTS docs?
>
I don't think any tool for python API docs would be able to do it
without the dependencies. The standard way to document python code is
in Python docstrings which are accessible during runtime (which is why
the dependencies are needed). Doxygen says that as well:
For Python there is a standard way of documenting the code using so
called documentation strings ("""). Such strings are stored in __doc__
and can be retrieved at runtime. Doxygen will extract such comments
and assume they have to be represented in a preformatted way.
There may be a tool that doesn't use the __doc__ attribute accessible
during runtime (I don't think anyone would implement something like
that though), but that would likely be much worse than Sphinx.
Juraj
> /Bruce
RE: [PATCH v4 1/4] bus/cdx: introduce cdx bus
> -Original Message- > From: Ferruh Yigit > Sent: Tuesday, May 9, 2023 7:26 PM > To: Gupta, Nipun ; Xia, Chenbo ; > dev@dpdk.org; tho...@monjalon.net; david.march...@redhat.com > Cc: Anand, Harpreet ; Agarwal, Nikhil > > Subject: Re: [PATCH v4 1/4] bus/cdx: introduce cdx bus > > On 5/9/2023 12:09 PM, Gupta, Nipun wrote: > > [AMD Official Use Only - General] > > > > > > > >> -Original Message- > >> From: Xia, Chenbo > >> Sent: Tuesday, May 9, 2023 12:25 PM > >> To: Gupta, Nipun ; dev@dpdk.org; > >> tho...@monjalon.net; david.march...@redhat.com > >> Cc: Yigit, Ferruh ; Anand, Harpreet > >> ; Agarwal, Nikhil > >> Subject: RE: [PATCH v4 1/4] bus/cdx: introduce cdx bus > >> > >> Caution: This message originated from an External Source. Use proper > >> caution when opening attachments, clicking links, or responding. > >> > >> > >>> -Original Message- > >>> From: Nipun Gupta > >>> Sent: Monday, May 8, 2023 7:18 PM > >>> To: dev@dpdk.org; tho...@monjalon.net; david.march...@redhat.com > >>> Cc: ferruh.yi...@amd.com; harpreet.an...@amd.com; > >> nikhil.agar...@amd.com; > >>> Nipun Gupta > >>> Subject: [PATCH v4 1/4] bus/cdx: introduce cdx bus > >>> > >>> CDX bus supports multiple type of devices, which can be > >>> exposed to user-space via vfio-cdx. > >>> > >>> vfio-cdx provides the MMIO IO_MEMORY regions as well as the > >>> DMA interface for the device (IOMMU). > >>> > >>> This support aims to enable the DPDK to support the cdx > >>> devices in user-space using VFIO interface. > >>> > >>> Signed-off-by: Nipun Gupta > >>> --- > >>> MAINTAINERS| 5 + > >>> doc/guides/rel_notes/release_23_07.rst | 6 + > >>> drivers/bus/cdx/bus_cdx_driver.h | 201 ++ > >>> drivers/bus/cdx/cdx.c | 520 > + > >>> drivers/bus/cdx/cdx_logs.h | 37 ++ > >>> drivers/bus/cdx/cdx_vfio.c | 437 + > >>> drivers/bus/cdx/meson.build| 13 + > >>> drivers/bus/cdx/private.h | 49 +++ > >>> drivers/bus/cdx/version.map| 11 + > >>> drivers/bus/meson.build| 1 + > >>> 10 files changed, 1280 insertions(+) > >>> create mode 100644 drivers/bus/cdx/bus_cdx_driver.h > >>> create mode 100644 drivers/bus/cdx/cdx.c > >>> create mode 100644 drivers/bus/cdx/cdx_logs.h > >>> create mode 100644 drivers/bus/cdx/cdx_vfio.c > >>> create mode 100644 drivers/bus/cdx/meson.build > >>> create mode 100644 drivers/bus/cdx/private.h > >>> create mode 100644 drivers/bus/cdx/version.map > >>> > >> > >> ... > >> > >>> --- /dev/null > >>> +++ b/drivers/bus/cdx/cdx.c > >>> @@ -0,0 +1,520 @@ > >>> +/* SPDX-License-Identifier: BSD-3-Clause > >>> + * Copyright (C) 2022-2023, Advanced Micro Devices, Inc. > >>> + */ > >>> + > >>> +/* > >>> + * Architecture Overview > >>> + * = > >>> + * CDX is a Hardware Architecture designed for AMD FPGA devices. It > >>> + * consists of sophisticated mechanism for interaction between FPGA, > >>> + * Firmware and the APUs (Application CPUs). > >>> + * > >>> + * Firmware resides on RPU (Realtime CPUs) which interacts with > >>> + * the FPGA program manager and the APUs. The RPU provides memory- > >> mapped > >>> + * interface (RPU if) which is used to communicate with APUs. > >>> + * > >>> + * The diagram below shows an overview of the CDX architecture: > >>> + * > >>> + * +--+ > >>> + * | DPDK | > >>> + * |DPDK CDX drivers | > >>> + * | || > >>> + * | DPDK CDX bus| > >>> + * | || > >>> + * +-|+ > >>> + *| > >>> + * +-|+ > >>> + * |Application CPUs (APU) || > >>> + * | || > >>> + * | VFIO CDX driver | > >>> + * | Linux OS|| > >>> + * | Linux CDX bus | > >>> + * | || > >>> + * +-|+ > >>> + *| > >>> + *| > >>> + * +| RPU if |+ > >>> + * | || > >>> + * | V| > >>> + * | Realtime CPUs (RPU) | > >>> + * | | > >>> + * +--+ > >>> + *| > >>> + * +-|+ > >>> + * | FPGA |
Re: [PATCH] net/dpaa2: set check sum good flags
On 5/8/2023 4:27 PM, Tianli Lai wrote:
Caution: This is an external email. Please take care when clicking links or
opening attachments. When in doubt, report the message using the 'Report this
email' button
set check sum good flags when dpaa2 hardware set check result.
Signed-off-by: Tianli Lai
---
drivers/net/dpaa2/dpaa2_rxtx.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_rxtx.c b/drivers/net/dpaa2/dpaa2_rxtx.c
index f60e78e1fd..85910bbd8f 100644
--- a/drivers/net/dpaa2/dpaa2_rxtx.c
+++ b/drivers/net/dpaa2/dpaa2_rxtx.c
@@ -198,8 +198,12 @@ dpaa2_dev_rx_parse_slow(struct rte_mbuf *mbuf,
if (BIT_ISSET_AT_POS(annotation->word8, DPAA2_ETH_FAS_L3CE))
mbuf->ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_BAD;
- else if (BIT_ISSET_AT_POS(annotation->word8, DPAA2_ETH_FAS_L4CE))
+ else
+ mbuf->ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_GOOD;
+ if (BIT_ISSET_AT_POS(annotation->word8, DPAA2_ETH_FAS_L4CE))
mbuf->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_BAD;
+ else
+ mbuf->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_GOOD;
if (BIT_ISSET_AT_POS(annotation->word4, L3_IP_1_FIRST_FRAGMENT |
L3_IP_1_MORE_FRAGMENT |
@@ -241,8 +245,12 @@ dpaa2_dev_rx_parse(struct rte_mbuf *mbuf, void
*hw_annot_addr)
if (BIT_ISSET_AT_POS(annotation->word8, DPAA2_ETH_FAS_L3CE))
mbuf->ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_BAD;
- else if (BIT_ISSET_AT_POS(annotation->word8, DPAA2_ETH_FAS_L4CE))
+ else
+ mbuf->ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_GOOD;
+ if (BIT_ISSET_AT_POS(annotation->word8, DPAA2_ETH_FAS_L4CE))
mbuf->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_BAD;
+ else
+ mbuf->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_GOOD;
if (dpaa2_enable_ts[mbuf->port]) {
*dpaa2_timestamp_dynfield(mbuf) = annotation->word2;
--
2.27.0
Acked-by: Sachin Saxena
--
Thanks,
Sachin Saxena
(NXP)
Re: [PATCH] net/dpaa2: set check sum good flags
On 5/8/2023 4:27 PM, Tianli Lai wrote:
Caution: This is an external email. Please take care when clicking links or
opening attachments. When in doubt, report the message using the 'Report this
email' button
set check sum good flags when dpaa2 hardware set check result.
Signed-off-by: Tianli Lai
---
drivers/net/dpaa2/dpaa2_rxtx.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_rxtx.c b/drivers/net/dpaa2/dpaa2_rxtx.c
index f60e78e1fd..85910bbd8f 100644
--- a/drivers/net/dpaa2/dpaa2_rxtx.c
+++ b/drivers/net/dpaa2/dpaa2_rxtx.c
@@ -198,8 +198,12 @@ dpaa2_dev_rx_parse_slow(struct rte_mbuf *mbuf,
if (BIT_ISSET_AT_POS(annotation->word8, DPAA2_ETH_FAS_L3CE))
mbuf->ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_BAD;
- else if (BIT_ISSET_AT_POS(annotation->word8, DPAA2_ETH_FAS_L4CE))
+ else
+ mbuf->ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_GOOD;
+ if (BIT_ISSET_AT_POS(annotation->word8, DPAA2_ETH_FAS_L4CE))
mbuf->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_BAD;
+ else
+ mbuf->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_GOOD;
if (BIT_ISSET_AT_POS(annotation->word4, L3_IP_1_FIRST_FRAGMENT |
L3_IP_1_MORE_FRAGMENT |
@@ -241,8 +245,12 @@ dpaa2_dev_rx_parse(struct rte_mbuf *mbuf, void
*hw_annot_addr)
if (BIT_ISSET_AT_POS(annotation->word8, DPAA2_ETH_FAS_L3CE))
mbuf->ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_BAD;
- else if (BIT_ISSET_AT_POS(annotation->word8, DPAA2_ETH_FAS_L4CE))
+ else
+ mbuf->ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_GOOD;
+ if (BIT_ISSET_AT_POS(annotation->word8, DPAA2_ETH_FAS_L4CE))
mbuf->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_BAD;
+ else
+ mbuf->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_GOOD;
if (dpaa2_enable_ts[mbuf->port]) {
*dpaa2_timestamp_dynfield(mbuf) = annotation->word2;
--
2.27.0
Acked-by: Sachin Saxena
--
Thanks,
Sachin Saxena
(NXP)
