* Re: [PATCH 1/1] buildtools: remove absolute paths from pc file
From: Bruce Richardson @ 2026-06-09 8:09 UTC (permalink / raw)
To: Srikanth Yalavarthi; +Cc: dev
In-Reply-To: <aifFFS9gvRn9JYKg@bricha3-mobl1.ger.corp.intel.com>
On Tue, Jun 09, 2026 at 08:47:33AM +0100, Bruce Richardson wrote:
> On Tue, Jun 09, 2026 at 10:02:20AM +0530, Srikanth Yalavarthi wrote:
> > When linking with non-versioned libraries, absolute paths
> > of the libraries are added to libdpdk.pc. This patch replaces
> > the absolute path with correct linker flags, -l<libname>.
> >
>
> Do we need to check if we need a "-L" flag for some of these paths that are
> stripped?
>
> > https://github.com/mesonbuild/meson/issues/7766
> >
The bug report indicates that this issue only occurs for some libs which
are missing an SONAME. Checking the .pc files generated on my own system, I
don't see any libs listed with full paths. Out of interest, what libraries
are causing problems? (Alternative question - how can we reproduce this
issue to check the fix :-) )
Thanks,
/Bruce
^ permalink raw reply
* RE: [PATCH] net/iavf: fix misleading AQ failure logging
From: Loftus, Ciara @ 2026-06-09 8:13 UTC (permalink / raw)
To: Mandal, Anurag, dev@dpdk.org
Cc: Richardson, Bruce, Medvedkin, Vladimir, stable@dpdk.org
In-Reply-To: <20260608171559.355521-1-anurag.mandal@intel.com>
> Subject: [PATCH] net/iavf: fix misleading AQ failure logging
>
> iavf_handle_virtchnl_msg() drains the admin receive queue in a loop
> until iavf_clean_arq_element() reports that no descriptors are
> pending. When the queue becomes empty, the base driver returns
> IAVF_ERR_ADMIN_QUEUE_NO_WORK (-57), which is the documented
> terminator for the drain loop, and is not an error.
>
> The current loop treats every non-IAVF_SUCCESS return as a failure
> and logs it as follows:
>
> "Failed to read msg from AdminQ, ret: -57"
>
> This message floods the logs on every interrupt cycle and misleads
> the triage during VF reset by chasing a real virtchnl problem
> seeing these spurious -57 AQ failure lines in logs and assumes
> the admin queue is broken, when in fact it has just been drained.
>
> This patch fixes the aforesaid issue by treating
> IAVF_ERR_ADMIN_QUEUE_NO_WORK in virtchnl message drain as a normal
> loop exit empty-queue condition and avoid logging it as an misleading
> AQ failure.
>
> Fixes: 02d212ca3125 ("net/iavf: rename remaining avf strings")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anurag Mandal <anurag.mandal@intel.com>
> ---
> drivers/net/intel/iavf/iavf_vchnl.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c
> b/drivers/net/intel/iavf/iavf_vchnl.c
> index 94ccfb5d6e..870d5c1820 100644
> --- a/drivers/net/intel/iavf/iavf_vchnl.c
> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
> @@ -570,7 +570,15 @@ iavf_handle_virtchnl_msg(struct rte_eth_dev *dev)
> while (pending) {
> ret = iavf_clean_arq_element(hw, &info, &pending);
>
> - if (ret != IAVF_SUCCESS) {
> + /*
> + * IAVF_ERR_ADMIN_QUEUE_NO_WORK (-57) means AQ is
> empty
> + * and is a normal way to terminate the drain loop.
> + * Log error only for genuine other failure codes.
> + * Incorrect logging like this during VF resets might
> + * mislead into chasing a non-existent AQ failure.
> + */
> + if (ret != IAVF_SUCCESS &&
> + ret != IAVF_ERR_ADMIN_QUEUE_NO_WORK) {
> PMD_DRV_LOG(INFO, "Failed to read msg from
> AdminQ,"
> "ret: %d", ret);
> break;
> --
I agree we should suppress the log on ret=NO_WORK but I
think we should still break instead of proceeding with the
message handling code. With your changes, in place of the
log:
IAVF_DRIVER: iavf_handle_virtchnl_msg(): Failed to read msg from AdminQ,ret: -57
I now see:
IAVF_DRIVER: iavf_handle_virtchnl_msg(): Request 0 is not supported yet
I think that's because we enter the message handling code
and arrive at the default case in the switch statement.
^ permalink raw reply
* Re: [PATCH v14 00/20] net/sxe2: added Linkdata sxe2 ethernet driver
From: Thomas Monjalon @ 2026-06-09 8:42 UTC (permalink / raw)
To: Jie Liu; +Cc: stephen, dev
In-Reply-To: <20260609013951.3359199-1-liujie5@linkdatatechnology.com>
09/06/2026 03:39, liujie5@linkdatatechnology.com:
> From: Jie Liu <liujie5@linkdatatechnology.com>
>
> This patch set implements core functionality for the SXE2 PMD,
> including basic driver framework, data path setup, and advanced
> offload features (VLAN, RSS,TM, PTP etc.).
>
> V14:
> - Addressed AI comments
Please could you send your new series as a reply of the v1 cover letter?
It would avoid having a large indent in mail clients.
Also I'm still waiting for a reply to my question about the need
for drivers/common/sxe2/.
I'm not going to pull any sxe2 patch into main until you explain.
^ permalink raw reply
* Re: [PATCH v8 2/4] examples/ptp_tap_relay_sw: add PTP software transparent clock relay
From: Thomas Monjalon @ 2026-06-09 8:52 UTC (permalink / raw)
To: Rajesh Kumar; +Cc: dev, bruce.richardson, aman.deep.singh, stephen, mb
In-Reply-To: <20260509232551.2844201-3-rajesh3.kumar@intel.com>
10/05/2026 01:25, Rajesh Kumar:
> Add a new example application demonstrating a software PTP Transparent
> Clock relay between a DPDK-bound physical NIC and a Linux kernel TAP
> virtual interface.
[...]
> doc/guides/sample_app_ug/index.rst | 1 +
> doc/guides/sample_app_ug/ptp_tap_relay_sw.rst | 212 +++++++++
> examples/ptp_tap_relay_sw/Makefile | 41 ++
> examples/ptp_tap_relay_sw/meson.build | 13 +
> examples/ptp_tap_relay_sw/ptp_parse.h | 211 +++++++++
> examples/ptp_tap_relay_sw/ptp_tap_relay_sw.c | 432 ++++++++++++++++++
> 6 files changed, 910 insertions(+)
You didn't update the file MAINTAINERS.
I assume you will be the maintainer for this new example?
I will update when merging.
^ permalink raw reply
* Re: [PATCH] Windows: fix core count on NUMA with more than 64 cores per node
From: David Marchand @ 2026-06-09 8:52 UTC (permalink / raw)
To: Andre Muezerie; +Cc: Dmitry Kozlyuk, dev, Gena Tertychnyi
In-Reply-To: <20260513235518.408895-1-andremue@linux.microsoft.com>
On Thu, 14 May 2026 at 01:56, Andre Muezerie
<andremue@linux.microsoft.com> wrote:
>
> From: Gena Tertychnyi <genter@microsoft.com>
>
> Fix specific to Windows NUMA machines with more than 64 cores per node
> (e.g. 2 NUMAs with 128 cores each):
>
> - NumaNode.GroupMasks[] array is used instead of NumaNode.GroupMask.
> - RelationAll is used instead of RelationNumaNode when calling
> GetLogicalProcessorInformationEx because RelationAll returns the full
> multi-group NUMA affinity as RelationNumaNode returns only the NUMA
> node's primary group.
>
> Signed-off-by: Gena Tertychnyi <genter@microsoft.com>
> Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
Applied with Dmitry suggestion on the Fixes: tag.
Thanks.
--
David Marchand
^ permalink raw reply
* Re: [PATCH] Remove redundant simpler equivalent section
From: David Marchand @ 2026-06-09 8:53 UTC (permalink / raw)
To: Arin Kharkar; +Cc: dev
In-Reply-To: <20260512191651.126274-1-arinkharkar@gmail.com>
On Wed, 13 May 2026 at 14:35, Arin Kharkar <arinkharkar@gmail.com> wrote:
>
> Fixed outdated documentation on the hello world doc, which incorrectly stated an easier way to launch the lcore_hello function. The example program uses the simpler version and the documentation stating it as an "equivalent and simpler" alternative is moot. It is now the default.
>
> Signed-off-by: Arin Kharkar <arinkharkar@gmail.com>
> ---
> doc/guides/sample_app_ug/hello_world.rst | 8 --------
> examples/helloworld/main.c | 4 +---
> 2 files changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/doc/guides/sample_app_ug/hello_world.rst b/doc/guides/sample_app_ug/hello_world.rst
> index 5bfd4b3fda..b7167aa345 100644
> --- a/doc/guides/sample_app_ug/hello_world.rst
> +++ b/doc/guides/sample_app_ug/hello_world.rst
> @@ -70,12 +70,4 @@ The code that launches the function on each lcore is as follows:
> :end-before: >8 End of launching the function on each lcore.
> :dedent: 1
>
> -The following code is equivalent and simpler:
> -
> -.. literalinclude:: ../../../examples/helloworld/main.c
> - :language: c
> - :start-after: Simpler equivalent. 8<
> - :end-before: >8 End of simpler equivalent.
> - :dedent: 2
> -
> Refer to the *DPDK API Reference* for detailed information on the rte_eal_mp_remote_launch() function.
> diff --git a/examples/helloworld/main.c b/examples/helloworld/main.c
> index af509138da..8d1a959c58 100644
> --- a/examples/helloworld/main.c
> +++ b/examples/helloworld/main.c
> @@ -40,13 +40,11 @@ main(int argc, char **argv)
>
> /* Launches the function on each lcore. 8< */
> RTE_LCORE_FOREACH_WORKER(lcore_id) {
> - /* Simpler equivalent. 8< */
> rte_eal_remote_launch(lcore_hello, NULL, lcore_id);
> - /* >8 End of simpler equivalent. */
> }
>
> /* call it on main lcore too */
> - lcore_hello(NULL);
> + lcore_hello(NULL);
Unneeded change, which I dropped when applying.
> /* >8 End of launching the function on each lcore. */
>
> rte_eal_mp_wait_lcore();
Applied, thanks.
--
David Marchand
^ permalink raw reply
* Re: [PATCH] eal: update comment for eal_get_virtual_area()
From: David Marchand @ 2026-06-09 9:02 UTC (permalink / raw)
To: Marcel Telka; +Cc: dev, Anatoly Burakov
In-Reply-To: <20251219191554.939982-1-marcel@telka.sk>
On Fri, 19 Dec 2025 at 20:16, Marcel Telka <marcel@telka.sk> wrote:
>
> Bugzilla ID: 1853
>
> Signed-off-by: Marcel Telka <marcel@telka.sk>
I added some commitlog based on your description in the bugzilla.
Applied, thanks.
--
David Marchand
^ permalink raw reply
* Re: [PATCH v3] raw/ifpga: replace printf calls with logging
From: David Marchand @ 2026-06-09 9:05 UTC (permalink / raw)
To: Weijun Pan; +Cc: Rosen Xu, dev, Weijun Pan, Bruce Richardson
In-Reply-To: <20260410162826.15485-1-wpan36@wisc.edu>
On Sat, 11 Apr 2026 at 15:58, Weijun Pan <wpan3636@gmail.com> wrote:
>
> The ifpga rawdev driver uses printf() directly for runtime messages.
> DPDK drivers should use the logging framework instead of printing
> to standard output.
>
> Replace the remaining direct printf() calls in ifpga_rawdev.c with
> the driver logging macros.
>
> Signed-off-by: Weijun Pan <wpan36@wisc.edu>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied, thanks.
--
David Marchand
^ permalink raw reply
* Re: [PATCH v8 2/4] examples/ptp_tap_relay_sw: add PTP software transparent clock relay
From: Thomas Monjalon @ 2026-06-09 9:15 UTC (permalink / raw)
To: Rajesh Kumar; +Cc: dev, bruce.richardson, aman.deep.singh, stephen, mb
In-Reply-To: <FtOw8lUNTi2iReVfgCFy-Q@monjalon.net>
09/06/2026 10:52, Thomas Monjalon:
> 10/05/2026 01:25, Rajesh Kumar:
> > Add a new example application demonstrating a software PTP Transparent
> > Clock relay between a DPDK-bound physical NIC and a Linux kernel TAP
> > virtual interface.
> [...]
> > doc/guides/sample_app_ug/index.rst | 1 +
> > doc/guides/sample_app_ug/ptp_tap_relay_sw.rst | 212 +++++++++
> > examples/ptp_tap_relay_sw/Makefile | 41 ++
> > examples/ptp_tap_relay_sw/meson.build | 13 +
> > examples/ptp_tap_relay_sw/ptp_parse.h | 211 +++++++++
> > examples/ptp_tap_relay_sw/ptp_tap_relay_sw.c | 432 ++++++++++++++++++
> > 6 files changed, 910 insertions(+)
>
> You didn't update the file MAINTAINERS.
> I assume you will be the maintainer for this new example?
> I will update when merging.
Sorry I see you did the update in the lib patch.
^ permalink raw reply
* Re: [PATCH] eal: add destructor to unregister tailq on unload
From: David Marchand @ 2026-06-09 9:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, stable, Neil Horman
In-Reply-To: <20260607150418.30885-1-stephen@networkplumber.org>
On Sun, 7 Jun 2026 at 17:04, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> Libraries that use EAL_REGISTER_TAILQ insert a pointer to a static
> struct rte_tailq_elem into the process-local tailq list via a
> constructor, but have no matching destructor. When such a library
> is loaded as a dependency of a plugin via dlopen() and later
> unloaded via dlclose(), the list retains a dangling pointer to the
> now-unmapped static. Reloading the plugin crashes in
> rte_eal_tailq_local_register() when it traverses the stale entry.
>
> Add rte_eal_tailq_unregister() and extend the EAL_REGISTER_TAILQ
> macro to emit an RTE_FINI destructor alongside the existing
> RTE_INIT constructor. Every library that uses the macro
> automatically gets both sides; no per-library changes are needed.
>
> Bugzilla ID: 1081
> Fixes: 873a61c7526b ("tailq: introduce dynamic register system")
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> lib/eal/common/eal_common_tailqs.c | 8 ++++++++
> lib/eal/include/rte_tailq.h | 17 +++++++++++++++++
> 2 files changed, 25 insertions(+)
>
> diff --git a/lib/eal/common/eal_common_tailqs.c b/lib/eal/common/eal_common_tailqs.c
> index c581f43b6f..714f91d0ec 100644
> --- a/lib/eal/common/eal_common_tailqs.c
> +++ b/lib/eal/common/eal_common_tailqs.c
> @@ -148,6 +148,14 @@ rte_eal_tailq_register(struct rte_tailq_elem *t)
> return -1;
> }
>
> +RTE_EXPORT_SYMBOL(rte_eal_tailq_unregister)
> +void
> +rte_eal_tailq_unregister(struct rte_tailq_elem *t)
> +{
> + TAILQ_REMOVE(&rte_tailq_elem_head, t, next);
> + t->head = NULL;
> +}
This cleans up the local storage which is good, but it leaves an entry
reserved in the mcfg->tailq_head[] array.
--
David Marchand
^ permalink raw reply
* Re: [PATCH v2] net/mlx5: fix counter TAILQ race between free and query callback
From: Dariusz Sosnowski @ 2026-06-09 9:22 UTC (permalink / raw)
To: Linhu Li; +Cc: dev, stable, rasland
In-Reply-To: <20260608132555.31439-1-lilinhu618@gmail.com>
On Mon, Jun 08, 2026 at 09:25:55PM +0800, Linhu Li wrote:
> flow_dv_counter_free() inserts counters into
> pool->counters[pool->query_gen] under pool->csl. Meanwhile,
> mlx5_flow_async_pool_query_handle() moves counters from
> pool->counters[query_gen ^ 1] to the global free list via
> TAILQ_CONCAT while holding only cmng->csl, not pool->csl.
>
> The comment in flow_dv_counter_free() claims the lock is not needed
> because the query callback and the release function operate on
> different lists. That holds only if the free path always observes
> the up-to-date query_gen. It can be violated:
>
> 1. A counter free thread (non-PMD, e.g. OVS offload thread) reads
> pool->query_gen == 0 and is about to insert into counters[0].
> 2. The free thread is preempted by the OS scheduler; it is a regular
> pthread, not pinned to a core.
> 3. The eal-intr-thread alarm fires: query_gen++ (now 1) and the async
> query is sent.
> 4. Hardware completes the query and the callback runs TAILQ_CONCAT on
> counters[0] (= query_gen ^ 1).
> 5. The free thread resumes and runs TAILQ_INSERT_TAIL on counters[0]
> concurrently with step 4 on another core.
>
> Because the two paths take different locks, TAILQ_INSERT_TAIL and
> TAILQ_CONCAT run concurrently on the same list with no
> synchronization and corrupt it: the pool-local list ends up with a
> NULL head but a dangling tqh_last, and the global free list tail no
> longer points to the real tail. The just-freed counter and every
> counter inserted afterwards become unreachable and are leaked.
>
> Non-PMD threads can be preempted for hundreds of microseconds under
> CPU pressure, which is well within the async query round-trip time,
> so the window is reachable in practice.
>
> Fix it by taking pool->csl in the query completion callback before
> operating on pool->counters[query_gen], serializing the CONCAT with
> any concurrent INSERT. The lock is taken once per pool per query
> completion in the eal-intr-thread context, not on the datapath, so
> the cost is negligible. Lock order is pool->csl then cmng->csl,
> matching all other sites.
>
> Also handle the error path: previously the counters accumulated in
> pool->counters[query_gen] were abandoned when a query failed. Move
> them back to the global free list to avoid a leak on persistent
> query failures.
>
> Fixes: ac79183dc6f7 ("net/mlx5: optimize free counter lookup")
> Cc: stable@dpdk.org
>
> Signed-off-by: Linhu Li <lilinhu618@gmail.com>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
^ permalink raw reply
* Re: [PATCH] eal: fix function versioning with LTO
From: David Marchand @ 2026-06-09 9:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, stable, Thomas Monjalon
In-Reply-To: <20260605111233.725bb792@phoenix.local>
On Fri, 5 Jun 2026 at 20:12, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> >
> > Looking at bugzilla, we had various fixes for LTO over the years.
> > We still have one open bz btw: https://bugs.dpdk.org/show_bug.cgi?id=1709
>
> That bug was fixed a while back. It required addition of hints (__rte_assume)
I have trouble identifying the changes.
Please close the 1709 bugzilla with a mention of those changes.
> > > > LTO is kind of experimental, so it seems good enough to reply "not
> > > > expected to work in older LTS" if someone reported an issue.
> > > >
> > > > And in practice, no LTS release call the versioning macros, since a
> > > > LTS drops all compatibility.
> >
> > Just to be clear, we don't need fixing the macros in LTS: every time
> > we prepare a LTS rc0, we drop any kind of symbol compat.
>
> Agree, this is not LTS related
>
> > > >
> > > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > >
> > > > I would like to reproduce, but I can't build main with LTO.
> > > > What patches did you apply locally to avoid warnings on the hash library?
> > > I use Debian testing and GCC 15 but shows up on older versions as well
> > > I get no warnings building main
> >
> > Building from scratch, I do avoid the warnings I hit yesterday.
> >
> > The fix looks correct, my problem is with the form.
> > Fixes: tags accuracy is important.
> > And I prefer we stick to "It is not broken, don't fix it".
>
> Could argue it is a GCC bug, and applying their desired workaround :-)
Indeed, but the end results is the same for me :-)
Can you send a v2?
Thanks.
--
David Marchand
^ permalink raw reply
* Re: [PATCH 1/2] eal: return error on devargs truncation in hotplug MP messages
From: David Marchand @ 2026-06-09 9:30 UTC (permalink / raw)
To: Long Li; +Cc: dev, bruce.richardson, stephen, Burakov, Anatoly
In-Reply-To: <20260325014506.1866374-1-longli@microsoft.com>
On Wed, 25 Mar 2026 at 02:45, Long Li <longli@microsoft.com> wrote:
>
> The EAL hotplug multi-process messaging uses a fixed-size buffer
> (EAL_DEV_MP_DEV_ARGS_MAX_LEN, 128 bytes) for device arguments.
> When devargs exceeds this limit, strlcpy silently truncates the
> string. This causes secondary processes to receive incomplete
> devargs during hotplug re-add, leading to failed port
> re-initialization.
>
> For example, a MANA PCI device with 6 mac= arguments:
>
> mac=AA:BB:CC:DD:EE:01,mac=AA:BB:CC:DD:EE:02,
> mac=AA:BB:CC:DD:EE:03,mac=AA:BB:CC:DD:EE:04,
> mac=AA:BB:CC:DD:EE:05,mac=AA:BB:CC:DD:EE:06
>
> produces a 131-byte devargs string that gets silently truncated
> to 127 bytes, losing the last MAC address.
>
> Return -E2BIG from rte_dev_probe() and rte_dev_remove() when
> devargs would be truncated, instead of silently corrupting data.
>
> Signed-off-by: Long Li <longli@microsoft.com>
Worth a Fixes: tag and Cc: stable.
> ---
> lib/eal/common/eal_common_dev.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/lib/eal/common/eal_common_dev.c b/lib/eal/common/eal_common_dev.c
> index 7185de0cb9..de24d14d28 100644
> --- a/lib/eal/common/eal_common_dev.c
> +++ b/lib/eal/common/eal_common_dev.c
> @@ -250,6 +250,11 @@ rte_dev_probe(const char *devargs)
>
> memset(&req, 0, sizeof(req));
> req.t = EAL_DEV_REQ_TYPE_ATTACH;
> + if (strlen(devargs) >= EAL_DEV_MP_DEV_ARGS_MAX_LEN) {
> + EAL_LOG(ERR, "devargs truncated (len %zu, max %d)",
> + strlen(devargs), EAL_DEV_MP_DEV_ARGS_MAX_LEN);
> + return -E2BIG;
> + }
> strlcpy(req.devargs, devargs, EAL_DEV_MP_DEV_ARGS_MAX_LEN);
Please move the check before the memset().
>
> if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> @@ -397,6 +402,12 @@ rte_dev_remove(struct rte_device *dev)
>
> memset(&req, 0, sizeof(req));
> req.t = EAL_DEV_REQ_TYPE_DETACH;
> + if (strlen(devargs) >= EAL_DEV_MP_DEV_ARGS_MAX_LEN) {
> + EAL_LOG(ERR, "devargs truncated (len %zu, max %d)",
> + strlen(devargs), EAL_DEV_MP_DEV_ARGS_MAX_LEN);
> + free(devargs);
> + return -E2BIG;
> + }
> strlcpy(req.devargs, devargs, EAL_DEV_MP_DEV_ARGS_MAX_LEN);
> free(devargs);
>
Why do we need to validate devargs on cleanup?
Its length should have been validated during probe.
--
David Marchand
^ permalink raw reply
* Re: Re: [PATCH v14 00/20] net/sxe2: added Linkdata sxe2 ethernet driver
From: liujie5 @ 2026-06-09 9:36 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: stephen, dev
In-Reply-To: <20260609013951.3359199-1-liujie5@linkdatatechnology.com>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
09/06/2026 03:39, liujie5@linkdatatechnology.com:
> From: Jie Liu <liujie5@linkdatatechnology.com>
>
> This patch set implements core functionality for the SXE2 PMD,
> including basic driver framework, data path setup, and advanced
> offload features (VLAN, RSS,TM, PTP etc.).
>
> V14:
> - Addressed AI comments
Please could you send your new series as a reply of the v1 cover letter?
It would avoid having a large indent in mail clients.
Also I'm still waiting for a reply to my question about the need
for drivers/common/sxe2/.
I'm not going to pull any sxe2 patch into main until you explain.
[-- Attachment #2: Type: text/html, Size: 4094 bytes --]
^ permalink raw reply
* Re: Re: [PATCH v14 00/20] net/sxe2: added Linkdata sxe2 ethernet driver
From: liujie5 @ 2026-06-09 9:48 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: stephen, dev
In-Reply-To: <T4eYjXumTvWFDg9HUrMwEA@monjalon.net>
[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]
Hi Thomas Monjalon,
Thank you for your review and for guiding me on the mailing list workflow.
> Please could you send your new series as a reply of the v1 cover letter?
> It would avoid having a large indent in mail clients.
Got it. I will configure git send-email with "--in-reply-to" bound to the
v1 cover letter Message-ID for the next version of this patch set.
Apologies for the inconvenience caused by the deep threading.
> Also I'm still waiting for a reply to my question about the need
> for drivers/common/sxe2/.
> I'm not going to pull any sxe2 patch into main until you explain.
Regarding the necessity of the "drivers/common/sxe2/" directory, the sxe2
hardware architecture is designed to support both standard NIC and vDPA
(vHost Data Path Acceleration) functionalities.
The code currently placed in "drivers/common/sxe2/" contains the foundational
Hardware Abstraction Layer (HAL), firmware interfaces (AdminQ), and common
register definitions.
Apart from the "net/sxe2" PMD in this series, we are actively implementing the
"vdpa/sxe2" driver, which will be submitted in a subsequent patch set. Both the
"net/sxe2" and "vdpa/sxe2" drivers strictly depend on this shared common HAL
layer to manage the same hardware core. Separating this code into "drivers/common/"
is essential to prevent massive code duplication between the net and vdpa
subsystems in the near future.
Please let me know if this clarifies your concern. Once confirmed, I will
send out the updated v15 series as a reply to the v1 cover letter immediately.
Best regards,
Jie Liu (liujie5@linkdatatechnology.com)
liujie5@linkdatatechnology.com
From: Thomas Monjalon
Date: 2026-06-09 16:42
To: Jie Liu
CC: stephen; dev
Subject: Re: [PATCH v14 00/20] net/sxe2: added Linkdata sxe2 ethernet driver
09/06/2026 03:39, liujie5@linkdatatechnology.com:
> From: Jie Liu <liujie5@linkdatatechnology.com>
>
> This patch set implements core functionality for the SXE2 PMD,
> including basic driver framework, data path setup, and advanced
> offload features (VLAN, RSS,TM, PTP etc.).
>
> V14:
> - Addressed AI comments
Please could you send your new series as a reply of the v1 cover letter?
It would avoid having a large indent in mail clients.
Also I'm still waiting for a reply to my question about the need
for drivers/common/sxe2/.
I'm not going to pull any sxe2 patch into main until you explain.
[-- Attachment #2: Type: text/html, Size: 4440 bytes --]
^ permalink raw reply
* Re: [PATCH v5] doc: improve e1000 driver documentation
From: Bruce Richardson @ 2026-06-09 9:50 UTC (permalink / raw)
To: Talluri Chaitanyababu; +Cc: dev, stephen, aman.deep.singh, shaiq.wani
In-Reply-To: <20260324230343.1050223-1-chaitanyababux.talluri@intel.com>
On Tue, Mar 24, 2026 at 11:03:37PM +0000, Talluri Chaitanyababu wrote:
> Add an overview of the e1000 driver for Intel 1G devices.
>
> Signed-off-by: Talluri Chaitanyababu <chaitanyababux.talluri@intel.com>
> ---
>
> v5:
> * Aligned PMD names with code.
> * Fixed wording for clarity.
>
> v4:
> * Fixed RST structure, single top-level title.
> * Used ASCII "PCIe".
> * Adjusted commit message to match content.
>
> v3: Resolved apply patch failure.
>
> v2: Addressed review comments.
> ---
This doc still needs a lot of rework, and possibly merging with the igb and
igc driver docs.
However, this small patch is an improvement, so I think I'll take it into
next-net-intel for this release. One small change I'd suggest below, let me
know if I'm ok to take this on apply.
/Bruce
> doc/guides/nics/e1000em.rst | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/nics/e1000em.rst b/doc/guides/nics/e1000em.rst
> index ed4f57e9c6..a101b54020 100644
> --- a/doc/guides/nics/e1000em.rst
> +++ b/doc/guides/nics/e1000em.rst
> @@ -4,7 +4,20 @@
> Driver for VM Emulated Devices
> ==============================
>
> -The DPDK EM poll mode driver supports the following emulated devices:
> +E1000 Poll Mode Driver
> +----------------------
> +
> +DPDK provides several poll mode drivers (PMDs) supporting Intel 1 Gigabit ethernet controller families.
> +These include:
> +
> +* e1000_em – Intel 8254x family devices, including QEMU ``e1000`` emulation.
> +* e1000_igb – Intel PRO/1000 PCIe family.
> +
> +.. note::
> +
> + The ``igb`` and ``igc`` PMDs are built from the same driver binary but are documented in separate sections for clarity.
The reference to igc here is strange when it is not mentioned above
alongside igc. Would it be better to put it in brackets with a mention that
it's 2.5G (no not part of the 1G driver list). If you want I can rephrase
this on apply as:
"The ``igb`` (and ``igc`` for 2.5G) PMDs are built from the same e1000 driver binary but are
documented in separate sections for clarity"
> +
> +The e1000_em poll mode driver supports the following emulated devices:
>
> * qemu-kvm emulated Intel® 82540EM Gigabit Ethernet Controller (qemu e1000 device)
>
> --
> 2.43.0
>
^ permalink raw reply
* RE: [PATCH] net/iavf: fix to consolidate link change event handling
From: Loftus, Ciara @ 2026-06-09 10:02 UTC (permalink / raw)
To: Mandal, Anurag, dev@dpdk.org
Cc: Richardson, Bruce, Medvedkin, Vladimir, stable@dpdk.org
In-Reply-To: <20260609001022.357509-1-anurag.mandal@intel.com>
> Subject: [PATCH] net/iavf: fix to consolidate link change event handling
>
> Handled link-change events through a common static function that
> reads the correct advanced & legacy link fields properly and
> updates no-poll/watchdog/LSC state consistently.
>
> Fixes: 5e03e316c753 ("net/iavf: handle virtchnl event message without
> interrupt")
> Fixes: 48de41ca11f0 ("net/avf: enable link status update")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anurag Mandal <anurag.mandal@intel.com>
> ---
> drivers/net/intel/iavf/iavf_vchnl.c | 133 +++++++++++++++++-----------
> 1 file changed, 81 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c
> b/drivers/net/intel/iavf/iavf_vchnl.c
> index 94ccfb5d6e..6454632541 100644
> --- a/drivers/net/intel/iavf/iavf_vchnl.c
> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
> @@ -216,6 +216,75 @@ iavf_convert_link_speed(enum virtchnl_link_speed
> virt_link_speed)
> return speed;
> }
>
> +/*
> + * iavf_handle_link_change_event: common handler for VIRTCHNL link
> change events
> + *
> + * @dev: pointer to rte_eth_dev for this VF
> + * @vpe: pointer to the virtchnl_pf_event payload received from the PF
> + *
> + * Handle PF link-change event: decode adv/legacy link info, update VF
> + * link state, sync no-poll/watchdog behavior & notify app via LSC event.
> + */
> +static void
> +iavf_handle_link_change_event(struct rte_eth_dev *dev,
> + struct virtchnl_pf_event *vpe)
> +{
> + struct iavf_adapter *adapter;
> + struct iavf_info *vf;
> + bool adv_link_speed;
> +
> + if (dev == NULL || dev->data == NULL ||
> + dev->data->dev_private == NULL || vpe == NULL) {
> + PMD_DRV_LOG(ERR, "Invalid device pointer in link change
> handler");
> + return;
> + }
Thanks for splitting this out into a standalone patch.
I'm not sure if all of the above NULL checking is necessary. Especially
vpe == NULL considering you've checked that for NULL in both
iavf_read_msg_from_pf and iavf_handle_pf_event_msg before entering this
function. It's recommended to avoid overly defensive checks that can
never trigger so I suggest taking a look at this again. Other than that
the changes looks good to me.
> +
> + adapter = IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data-
> >dev_private);
> + vf = &adapter->vf;
> +
> + adv_link_speed = (vf->vf_res != NULL) &&
> + ((vf->vf_res->vf_cap_flags &
> VIRTCHNL_VF_CAP_ADV_LINK_SPEED) != 0);
> +
^ permalink raw reply
* Re: [PATCH] net/ice: use configured outer TPID for VLAN filter in DVM
From: Bruce Richardson @ 2026-06-09 10:03 UTC (permalink / raw)
To: KAVYA AV; +Cc: dev, aman.deep.singh, shaiq.wani, stable
In-Reply-To: <20260527161442.394593-1-kavyax.a.v@intel.com>
On Wed, May 27, 2026 at 04:14:42PM +0000, KAVYA AV wrote:
> In Double VLAN Mode (DVM), the hardware switch recipe
> ICE_SW_LKUP_VLAN matches on both the VLAN ID and the TPID.
> Previously, ice_vlan_filter_set() always initialized the VLAN
> filter with the hardcoded RTE_ETHER_TYPE_VLAN (0x8100), regardless
> of the outer TPID configured by the user via vlan_tpid_set().
>
> This caused a mismatch when a non-standard outer TPID such as
> 0x88a8 (IEEE 802.1ad) was configured: the hardware filter was
> programmed with TPID 0x8100 while incoming packets carried TPID
> 0x88a8, resulting in all such packets being dropped by the VLAN
> pruning logic.
>
> Fix this by replacing the hardcoded RTE_ETHER_TYPE_VLAN with
> pf->outer_ethertype in the ICE_VLAN() macro call. This field is
> already updated by ice_vlan_tpid_set() when the user configures
> the outer TPID, and defaults to RTE_ETHER_TYPE_VLAN at
> initialization, so the change is safe for standard 802.1q traffic.
>
> In SVM, the TPID is not part of the hardware lookup key, so this
> change has no functional impact in that mode.
>
> Fixes: 295b34f55b00 ("net/ice: fix VLAN 0 adding based on VLAN mode")
> Cc: stable@dpdk.org
>
> Signed-off-by: KAVYA AV <kavyax.a.v@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied to dpdk-next-net-intel.
Thanks,
/Bruce
^ permalink raw reply
* Re: [PATCH] net/iavf: remove unreachable hash action case
From: Bruce Richardson @ 2026-06-09 10:12 UTC (permalink / raw)
To: Artem Novikov; +Cc: Vladimir Medvedkin, Qi Zhang, Jeff Guo, dev, stable
In-Reply-To: <20260604161354.95602-1-naa@amicon.ru>
On Thu, Jun 04, 2026 at 07:13:53PM +0300, Artem Novikov wrote:
> The hash action parser stops iterating when it reaches
> RTE_FLOW_ACTION_TYPE_END. The switch below uses action_type copied
> directly from action->type inside that loop, so the END case cannot be
> selected.
>
> Remove the unreachable case. No functional change.
>
> Fixes: 7be10c3004be ("net/iavf: add RSS configuration for VF")
> Cc: stable@dpdk.org
> Cc: jia.guo@intel.com
>
> Signed-off-by: Artem Novikov <naa@amicon.ru>
> ---
> drivers/net/intel/iavf/iavf_hash.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/intel/iavf/iavf_hash.c b/drivers/net/intel/iavf/iavf_hash.c
> index 217f0500ab..7ce7b86d8e 100644
> --- a/drivers/net/intel/iavf/iavf_hash.c
> +++ b/drivers/net/intel/iavf/iavf_hash.c
> @@ -1490,8 +1490,6 @@ iavf_hash_parse_action(struct iavf_pattern_match_item *match_item,
> rss_type, pattern_hint);
> break;
>
> - case RTE_FLOW_ACTION_TYPE_END:
> - break;
>
> default:
> rte_flow_error_set(error, EINVAL,
This code is no longer present, following the recent rework of Intel driver
flow parsing, done by Anatoly. Therefore marking this as "not applicable"
in patchwork.
Thanks,
/Bruce
^ permalink raw reply
* Re: [PATCH v14 00/20] net/sxe2: added Linkdata sxe2 ethernet driver
From: Thomas Monjalon @ 2026-06-09 10:19 UTC (permalink / raw)
To: liujie5@linkdatatechnology.com; +Cc: stephen, dev
In-Reply-To: <202606091748234877352@linkdatatechnology.com>
09/06/2026 11:48, liujie5@linkdatatechnology.com:
> Hi Thomas Monjalon,
>
> Thank you for your review and for guiding me on the mailing list workflow.
>
> > Please could you send your new series as a reply of the v1 cover letter?
> > It would avoid having a large indent in mail clients.
>
> Got it. I will configure git send-email with "--in-reply-to" bound to the
> v1 cover letter Message-ID for the next version of this patch set.
> Apologies for the inconvenience caused by the deep threading.
>
> > Also I'm still waiting for a reply to my question about the need
> > for drivers/common/sxe2/.
> > I'm not going to pull any sxe2 patch into main until you explain.
>
> Regarding the necessity of the "drivers/common/sxe2/" directory, the sxe2
> hardware architecture is designed to support both standard NIC and vDPA
> (vHost Data Path Acceleration) functionalities.
>
> The code currently placed in "drivers/common/sxe2/" contains the foundational
> Hardware Abstraction Layer (HAL), firmware interfaces (AdminQ), and common
> register definitions.
>
> Apart from the "net/sxe2" PMD in this series, we are actively implementing the
> "vdpa/sxe2" driver, which will be submitted in a subsequent patch set. Both the
> "net/sxe2" and "vdpa/sxe2" drivers strictly depend on this shared common HAL
> layer to manage the same hardware core. Separating this code into "drivers/common/"
> is essential to prevent massive code duplication between the net and vdpa
> subsystems in the near future.
>
> Please let me know if this clarifies your concern. Once confirmed, I will
> send out the updated v15 series as a reply to the v1 cover letter immediately.
OK thank you, it's clear.
^ permalink raw reply
* Re: [PATCH 1/2] net/ice: revert fix link up when starting device
From: Bruce Richardson @ 2026-06-09 10:20 UTC (permalink / raw)
To: Ciara Loftus; +Cc: dev
In-Reply-To: <20260603143407.1108527-2-ciara.loftus@intel.com>
On Wed, Jun 03, 2026 at 02:34:06PM +0000, Ciara Loftus wrote:
> This reverts commit 6c76b76dc64183eb2f24a52b90d4ff9feb4872f4.
>
> The reverted commit worked around a potential timing issue where the
> link could be reported down immediately after the link was enabled
> during device start. The commit introduced a blocking wait which gave
> the driver a better chance to read the correct link state before
> returning from device start. However, since the auto link update flag is
> set when setting the link up in device start, an adminq notification
> should arrive once the link is up, which will be handled and correctly
> set the link status. This means we can remove the delay from device
> start as it does not need to guarantee link up before returning.
>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> ---
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* 回复：[PATCH] gpu/metax: add new driver for Metax GPU
From: 许玲燕 @ 2026-06-09 10:22 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, eagostini
In-Reply-To: <CsAn75rzSb2jiQLRSeXkmQ@monjalon.net>
[-- Attachment #1: Type: text/plain, Size: 4124 bytes --]
Hi,
Thank you for the detailed feedback and for reviewing the proposal for the Metax GPU driver.
Based on the questions raised and the analysis of the code implementation, here are the clarifications and my action plan:
1. Regarding GPU Access Method
The driver interfaces with the Metax GPU hardware through a combination of the vendor-provided MC Runtime (Metax Compute Runtime) library and GDRCopy (GPU Direct RDMA) technology.
*
User-space Library: As seen in the maca.c code, the driver dynamically loads (dlopen) the libmcruntime.so library. It uses mc_runtime_api.h to manage GPU contexts, memory allocation, and device attributes.
*
Kernel Module: The driver relies on the underlying Metax kernel driver (for PCI probing and basic device access) and the gdrapi (GDRCopy) kernel module to facilitate zero-copy data transfer between CPU and GPU memory.
*
Dependency: The build log confirms the detection of headers like mc_runtime_api.h and gdrapi.h, which are essential for this integration.
2. Clarification on "Rendering" Functionality
I apologize for the confusion caused by the term "Rendering" in the initial description. Upon reviewing the code and your feedback, I realize this was an inaccurate choice of words.
*
Correction: The intended functionality is purely "Compute/Data Processing" and "Memory Management".
*
Explanation: The driver's core logic (as shown in the patch) focuses on memory registration, allocation, and CPU/GPU data synchronization (via maca_mem_cpu_map and gdrcopy_pin), which are essential for network data processing acceleration rather than graphical rendering. I will correct this terminology in the documentation to avoid further confusion.
3. Action Plan: Following the Contribution Guide
I have reviewed the <"Adding a New Driver"> guide you linked.
*
Patch Splitting: I understand that the current monolithic patch is not suitable. I will rework the submission and split it into a logical patch series:
*
Patch 1: Add the basic infrastructure (Meson files, maintainers, configuration).
*
Patch 2: Implement core device functionality (PCI probing, initialization, context management).
*
Patch 3: Add memory management and data path features (allocation, registration, and CPU mapping).
Thank you again for your guidance. I will resubmit the revised patch series shortly.
Best regards,
Lingyan Xu
------------------------------------------------------------------
发件人：Thomas Monjalon <thomas@monjalon.net>
发送时间：2026年6月2日(周二) 18:01
收件人："许玲燕"<lingyan.xu@metax-tech.com>
抄 送：dev<dev@dpdk.org>; eagostini<eagostini@nvidia.com>
主 题：Re: [PATCH] gpu/metax: add new driver for Metax GPU
Hello,
01/06/2026 07:47, 许玲燕:
> I am writing to propose a new driver for the Metax GPU,
How do you access the GPU?
Are you using a specific library or kernel module?
> which I believe will significantly enhance our support
> and performance for this hardware.
> The patch attached includes the initial implementation of the driver,
> with key features such as:
>
> * Basic initialization and configuration
> * Memory management and allocation
> * Core functionality for rendering and compute tasks
I am familiar with connecting compute tasks of a GPU
with DPDK networking, but I'm surprised by the rendering functionality.
Do you mean graphical rendering of data coming from the network?
> Please review the code and let me know if you have any feedback or suggestions.
> I am more than happy to make any necessary adjustments and improvements.
Thank you for working on this.
I recommend following this guide to introduce a new driver:
https://doc.dpdk.org/guides/contributing/new_driver.html <https://doc.dpdk.org/guides/contributing/new_driver.html >
超大附件列表 dpdk-build-test-log.txt [48KB]
进入下载页面 https://qiye.aliyun.com/alimail/openLinks/downloadMimeMetaDiskBigAttach?id=netdiskid%3Av001%3Afile%3ADzzzzzzNqZx%3BJYiJwCficINAoHh55iyjKdydQzW5hDE%2FGjddF2Xp4ghl2ujmlGlWdfhgNCLOb5s3BZAHvDXTdZhtzGA3q8HJ%2Fv%2FPGnrPJfO1Xc%2BWnHr%2FKRwIkHzWFe5Iwm1IZrurr9hW
[-- Attachment #2: Type: text/html, Size: 132113 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] net/i40e: fix blocking link wait on device start
From: Bruce Richardson @ 2026-06-09 10:22 UTC (permalink / raw)
To: Ciara Loftus; +Cc: dev, stable
In-Reply-To: <20260603143407.1108527-3-ciara.loftus@intel.com>
On Wed, Jun 03, 2026 at 02:34:07PM +0000, Ciara Loftus wrote:
> Currently, device start performs a synchronous link status update,
> blocking for up to one second if the link is not yet up. This causes
> unnecessary startup delay in scenarios where the link partner is slow to
> come up or unavailable.
>
> The wait was introduced alongside the maximum frame size MAC config
> command. Some devices require the link to be up before issuing that
> command, so the solution was to block at device start until link was
> established.
>
> To address the issue, remove the unconditional blocking wait. Take note
> if the link was down at the time of the MAC config command during device
> start and if it was, re-issue the command upon notification of the first
> link-up event.
>
> In the case where all interrupt vectors are consumed by Rx queues, no
> interrupt or alarm handler is available to process link-up events. The
> blocking wait is retained for this narrow case to preserve correctness.
>
> Fixes: 82fcf20d039c ("net/i40e: fix maximum frame size configuration")
> Cc: stable@dpdk.org
>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* Re: [PATCH v8 0/4] IEEE 1588 PTP v2 protocol support in lib/net
From: Thomas Monjalon @ 2026-06-09 10:32 UTC (permalink / raw)
To: Rajesh Kumar; +Cc: dev, bruce.richardson, aman.deep.singh, stephen, mb
In-Reply-To: <20260509232551.2844201-1-rajesh3.kumar@intel.com>
> Rajesh Kumar (4):
> lib/net: add IEEE 1588 PTP v2 protocol header definitions
> examples/ptp_tap_relay_sw: add PTP software transparent clock relay
> doc: update release notes for PTP protocol library
> examples/ptpclient: use shared PTP library definitions
Squashed in 2 atomic commits (lib and new example), thanks.
^ permalink raw reply
* Re: 回复：[PATCH] gpu/metax: add new driver for Metax GPU
From: Thomas Monjalon @ 2026-06-09 10:43 UTC (permalink / raw)
To: 许玲燕; +Cc: dev, eagostini
In-Reply-To: <fbe7f8ce-f680-411a-a7a6-82eda60300de.lingyan.xu@metax-tech.com>
Thank you for the detailed answer and your understanding.
One more question: are the lib and module upstreamed already?
09/06/2026 12:22, 许玲燕:
> Hi,
> Thank you for the detailed feedback and for reviewing the proposal for the Metax GPU driver.
> Based on the questions raised and the analysis of the code implementation, here are the clarifications and my action plan:
> 1. Regarding GPU Access Method
> The driver interfaces with the Metax GPU hardware through a combination of the vendor-provided MC Runtime (Metax Compute Runtime) library and GDRCopy (GPU Direct RDMA) technology.
>
> *
> User-space Library: As seen in the maca.c code, the driver dynamically loads (dlopen) the libmcruntime.so library. It uses mc_runtime_api.h to manage GPU contexts, memory allocation, and device attributes.
>
> *
> Kernel Module: The driver relies on the underlying Metax kernel driver (for PCI probing and basic device access) and the gdrapi (GDRCopy) kernel module to facilitate zero-copy data transfer between CPU and GPU memory.
>
> *
> Dependency: The build log confirms the detection of headers like mc_runtime_api.h and gdrapi.h, which are essential for this integration.
> 2. Clarification on "Rendering" Functionality
> I apologize for the confusion caused by the term "Rendering" in the initial description. Upon reviewing the code and your feedback, I realize this was an inaccurate choice of words.
>
> *
> Correction: The intended functionality is purely "Compute/Data Processing" and "Memory Management".
>
> *
> Explanation: The driver's core logic (as shown in the patch) focuses on memory registration, allocation, and CPU/GPU data synchronization (via maca_mem_cpu_map and gdrcopy_pin), which are essential for network data processing acceleration rather than graphical rendering. I will correct this terminology in the documentation to avoid further confusion.
> 3. Action Plan: Following the Contribution Guide
> I have reviewed the <"Adding a New Driver"> guide you linked.
>
> *
> Patch Splitting: I understand that the current monolithic patch is not suitable. I will rework the submission and split it into a logical patch series:
> *
> Patch 1: Add the basic infrastructure (Meson files, maintainers, configuration).
>
> *
> Patch 2: Implement core device functionality (PCI probing, initialization, context management).
>
> *
> Patch 3: Add memory management and data path features (allocation, registration, and CPU mapping).
> Thank you again for your guidance. I will resubmit the revised patch series shortly.
> Best regards,
> Lingyan Xu
> ------------------------------------------------------------------
> 发件人：Thomas Monjalon <thomas@monjalon.net>
> 发送时间：2026年6月2日(周二) 18:01
> 收件人："许玲燕"<lingyan.xu@metax-tech.com>
> 抄 送：dev<dev@dpdk.org>; eagostini<eagostini@nvidia.com>
> 主 题：Re: [PATCH] gpu/metax: add new driver for Metax GPU
> Hello,
> 01/06/2026 07:47, 许玲燕:
> > I am writing to propose a new driver for the Metax GPU,
> How do you access the GPU?
> Are you using a specific library or kernel module?
> > which I believe will significantly enhance our support
> > and performance for this hardware.
> > The patch attached includes the initial implementation of the driver,
> > with key features such as:
> >
> > * Basic initialization and configuration
> > * Memory management and allocation
> > * Core functionality for rendering and compute tasks
> I am familiar with connecting compute tasks of a GPU
> with DPDK networking, but I'm surprised by the rendering functionality.
> Do you mean graphical rendering of data coming from the network?
> > Please review the code and let me know if you have any feedback or suggestions.
> > I am more than happy to make any necessary adjustments and improvements.
> Thank you for working on this.
> I recommend following this guide to introduce a new driver:
> https://doc.dpdk.org/guides/contributing/new_driver.html <https://doc.dpdk.org/guides/contributing/new_driver.html >
>
>
> 超大附件列表 dpdk-build-test-log.txt [48KB]
> 进入下载页面 https://qiye.aliyun.com/alimail/openLinks/downloadMimeMetaDiskBigAttach?id=netdiskid%3Av001%3Afile%3ADzzzzzzNqZx%3BJYiJwCficINAoHh55iyjKdydQzW5hDE%2FGjddF2Xp4ghl2ujmlGlWdfhgNCLOb5s3BZAHvDXTdZhtzGA3q8HJ%2Fv%2FPGnrPJfO1Xc%2BWnHr%2FKRwIkHzWFe5Iwm1IZrurr9hW
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox