RE: [EXTERNAL] graph: dispatch mode with libevent for control plane
> -Original Message-
> From: Robin Jarry
> Sent: Monday, December 9, 2024 2:58 PM
> To: Nitin Saxena ; dev@dpdk.org; gr...@dpdk.org
> Cc: Jerin Jacob ; David Marchand
> ; Christophe Fontaine ;
> Nitin Saxena
> Subject: [EXTERNAL] graph: dispatch mode with libevent for control plane
>
> Hi folks, I had a look at the graph dispatch mode and wondered if it could be
> adapted to be used with event loops for "slow path" processing. The use case I
> have in mind is having lcores dedicated for control plane operations which are
> not latency
> Hi folks,
>
> I had a look at the graph dispatch mode and wondered if it could be adapted to
> be used with event loops for "slow path" processing.
>
> The use case I have in mind is having lcores dedicated for control plane
> operations which are not latency sensitive. It would be nice to allow data
> plane
> workers to send packets to these lcores while keeping the packets in the
> graph.
>
> The problem I have with this solution for now, is that all CPUs processing the
> graph with rte_graph_walk_mcore_dispatch() are supposed to do busy polling.
> This is not compatible with select/epoll based event loops.
>
> Would it be possible to have a way for busy-polling threads to signal
> non-busy-
> polling threads that there are packets waiting for them in the graph ring? In
> grout, we implemented something outside of the graph using
> pthread_cond_signal().
Sorry for delay, I was on business travel.
Adding yanzhirun_...@163.com(mcore model maintainer).
If I understand it correctly, we need three operations.
a)wait object creation.
b)wait object waiting instead of polling.
c)signal wait object from fastpath to wake up (b)
I see two options.
Option A:
In application (without graph change)
1)call (a)
2)
while(1)
{
Call (b)
rte_graph_walk_mcore_dispatch()
}
3)Call (c) from fp nodes(Assuming it is out of tree nodes)
Option B
1)Call (a) in model create or so
2)Add an option in rte_graph_walk_mcore_dispatch() to call (b)
3)Update rte_.._enqueue() to call (c) after ring enqueue
Option B is need if we need inbuilt fp nodes.
>
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_DPDK_grout_blob_main_modules_infra_datapath_control-
> 5Foutput.c&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1DGob4H4rxz6H8uIT
> ozGOCa0s5f4wCNtTa4UUKvcsvI&m=sctQnRalWyQEGrI4o2UpcCXD8n8qveibIe4C
> clcMOUmS7Oi0S7MoVryikpo_ZDh1&s=Zm-
> i7a_D6MFxZO362gYHHe9PtKO_Kr6JeFNlmEHpMCg&e=
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_DPDK_grout_blob_main_modules_infra_control_control-
> 5Foutput.c&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1DGob4H4rxz6H8uIT
> ozGOCa0s5f4wCNtTa4UUKvcsvI&m=sctQnRalWyQEGrI4o2UpcCXD8n8qveibIe4C
> clcMOUmS7Oi0S7MoVryikpo_ZDh1&s=09ea7Sa47B5SPe7SjP5zBNMzqem0XzI3
> HnlU-k73N2w&e=
>
> Unless I am mistaken, this does not perform any syscall and does not require
> acquiring any lock. Only the "slow" thread needs to acquire locks and wait for
> the data path threads to call pthread_cond_signal().
>
> This solution can only be used for busy-polling -> epoll-based communication,
> for the other direction epoll-based -> busy-polling there would not need any
> specific signaling required. Only posting the packets to the graph ring would
> be
> enough.
>
> What do you think? How would you integrate this into rte_graph? What would
> the API look like in your opinion?
>
> Thanks!
>
> --
> Robin
Re: [PATCH v2 4/6] drivers: fix exported headers
On Fri, Dec 13, 2024 at 2:46 PM David Marchand
wrote:
> > > diff --git a/drivers/raw/cnxk_bphy/rte_pmd_bphy.h
> > > b/drivers/raw/cnxk_bphy/rte_pmd_bphy.h
> > > index f668e6ea82..c200c935ff 100644
> > > --- a/drivers/raw/cnxk_bphy/rte_pmd_bphy.h
> > > +++ b/drivers/raw/cnxk_bphy/rte_pmd_bphy.h
> > > @@ -391,6 +391,7 @@ rte_pmd_bphy_intr_init(uint16_t dev_id)
> > > {
> > > struct cnxk_bphy_irq_msg msg = {
> > > .type = CNXK_BPHY_IRQ_MSG_TYPE_INIT,
> > > + .data = NULL,
> > > };
> > >
> >
> > Why is this addition necessary? Is it for C++ compile?
>
> IIRC, this is because DPDK meson passes
> -Wno-missing-field-initializers globally, and the Makefile I wrote
> does not.
> I'll double check.
Yep, confirmed.
...
In file included from
/home/dmarchan/builds/main/build-x86-generic/buildtools/chkincs/rte_pmd_cnxk_gpio.c:1:
/home/dmarchan/builds/main/build-x86-generic/install/usr/local/include/rte_pmd_cnxk_gpio.h:
In function ‘int rte_pmd_gpio_get_pin_value(uint16_t, int, int*)’:
/home/dmarchan/builds/main/build-x86-generic/install/usr/local/include/rte_pmd_cnxk_gpio.h:264:9:
error: missing initializer for member ‘cnxk_gpio_msg::data’
[-Werror=missing-field-initializers]
264 | };
| ^
...
On the other hand, -Wmissing-field-initializers comes from -Wextra and
it is explicitly disabled in meson.
If we want to stick with -Wmissing-field-initializers "internally", I
will drop those changes (and disable missing-field-initializers,
trying to keep -Wextra in the "external" check)
--
David Marchand
Re: [PATCH 1/3] random: defer seeding to EAL init
On 12/5/2024 6:57 PM, David Marchand wrote:
The RNG is documented as being seeded as part of EAL init.
/**
* Seed the pseudo-random generator.
*
* The generator is automatically seeded by the EAL init with a timer
* value. It may need to be re-seeded by the user with a real random
* value.
*
...
Move the initialisation (seeding) helper out of a constructor and
call it explicitly from rte_eal_init() as it was done before commit
3f002f069612 ("eal: replace libc-based random generation with LFSR").
This also moves the unconditional lcore variable allocation out of a
constructor.
While at it, mark local symbol rand_state as static.
Fixes: 29c39cd3d54d ("random: keep PRNG state in lcore variable")
Cc: sta...@dpdk.org
Signed-off-by: David Marchand
---
Acked-by: Anatoly Burakov
--
Thanks,
Anatoly
Re: [PATCH 0/3] Defer lcore variables allocation
On 12/5/2024 6:57 PM, David Marchand wrote: As I had reported in rc2, the lcore variables allocation have a noticeable impact on applications consuming DPDK, even when such applications does not use DPDK, or use features associated to some lcore variables. While the amount has been reduced in a rush before rc2, there are still cases when the increased memory footprint is noticed like in scaling tests. See https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2090931 lcore variable allocations in constructor is a bad idea, as the application consuming DPDK has no control over such allocation: linking some code does not mean that all of it will be used at runtime. The general question on whether lcore variables in constructor should be forbidden, is left to a later discussion. For now, this series only focus on fixing subsystems using lcore variables so that those allocations are deferred either in rte_eal_init() or in the path that does require such lcore variables. An idle question: would this have any consequences in use case of eal init -> eal cleanup -> eal init with different arguments? -- Thanks, Anatoly
Re: [PATCH 0/3] Defer lcore variables allocation
On Mon, Dec 16, 2024 at 10:42 AM Burakov, Anatoly wrote: > > On 12/5/2024 6:57 PM, David Marchand wrote: > > As I had reported in rc2, the lcore variables allocation have a > > noticeable impact on applications consuming DPDK, even when such > > applications does not use DPDK, or use features associated to > > some lcore variables. > > > > While the amount has been reduced in a rush before rc2, > > there are still cases when the increased memory footprint is noticed > > like in scaling tests. > > See https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2090931 > > > > > > lcore variable allocations in constructor is a bad idea, as the > > application consuming DPDK has no control over such allocation: > > linking some code does not mean that all of it will be used at runtime. > > > > The general question on whether lcore variables in constructor should > > be forbidden, is left to a later discussion. > > > > For now, this series only focus on fixing subsystems using lcore > > variables so that those allocations are deferred either in rte_eal_init() > > or in the path that does require such lcore variables. > > > > > > An idle question: would this have any consequences in use case of eal > init -> eal cleanup -> eal init with different arguments? Hum, interesting question. I would say that initialising lcore variables in constructors means that this usecase is broken, since lcore variables are freed in eal_lcore_var_cleanup(). -- David Marchand
Re: [PATCH] net/af_packet: allow disabling packet fanout
> Controlling fanout more is a good idea but not sure what this patch
> is trying to do with it.
I am maintaining a DPDK application which should run on a large number
of setups.
Unfortunately, I do not have a lot of control over the environment the
application runs on (e.g kernel).
The problem I was trying to solve is that the Af_Packet PMD seems to
fail to initialize properly on some setups.
I managed to reproduce the issue with testpmd.
sudo ./x86_64-native-linuxapp-gcc/app/dpdk-testpmd \
-l 0-3 \
-m 1024 \
--no-huge \
--no-shconf \
--no-pci \
--vdev=net_af_packet0,iface=eth1,blocksz=4096,framesz=2048,framecnt=512,qpairs=1,qdisc_bypass=0
\
--vdev=net_af_packet1,iface=eth2,blocksz=4096,framesz=2048,framecnt=512,qpairs=1,qdisc_bypass=0
\
-- \
-i
Error: Unknown device type.
EAL: Detected CPU lcores: 8
EAL: Detected NUMA nodes: 1
EAL: Detected static linkage of DPDK
EAL: Selected IOVA mode 'VA'
AFPACKET: rte_pmd_init_internals(): net_af_packet0: could not set
PACKET_FANOUT on AF_PACKET socket for eth1:Invalid argument
VDEV_BUS: vdev_probe(): failed to initialize net_af_packet0 device
AFPACKET: rte_pmd_init_internals(): net_af_packet1: could not set
PACKET_FANOUT on AF_PACKET socket for eth1:Invalid argument
VDEV_BUS: vdev_probe(): failed to initialize net_af_packet1 device
EAL: Bus (vdev) probe failed.
testpmd: No probed ethernet devices
It seems that the call to PACKET_FANOUT setsockopt failed with EINVAL.
I debugged the issue further. It seems that the root cause is that
when the interface is down (e.g eth1), after the bind operation
succeeds, the PACKET_FANOUT setsockopt will fail.
This is a behavior of AF_Packet in Linux which I'm not sure is that
well documented.
It seems to be fixed in a recent Linux Kernel commit. I re-compiled
the kernel with the change, and did not see the issue afterwards.
Commit 2cee3e6e2e4b74bec96694169f01cd3feec1f264
af_packet: allow fanout_add when socket is not RUNNING
[1]
https://github.com/torvalds/linux/commit/2cee3e6e2e4b74bec96694169f01cd3feec1f264
I was trying to find a solution for my application to run on setups
which don't have the kernel patch.
Introducing a devarg to control when packet_fanout is enabled seemed
like a possible way around the issue.
As a second solution around the issue, I was also thinking of using
the PACKET_FANOUT setsockopt only when nb_queues > 1.
Conceptually, I think it would make some sense, because fanout doesn't
really help when having a single socket.
We would need more sockets in order to load balance incoming packets.
And this would still allow me to control the behavior from the
existing 'qpairs' devarg.
The idea would be something along these lines
if (nb_queues > 1) {
rc = setsockopt(qsockfd, SOL_PACKET, PACKET_FANOUT, &fanout_arg,
sizeof(fanout_arg));
/* ... */
}
Would a patch using this idea be considered more suitable ?
> - DPDK minimum kernel version is now 4.19 so no point in worrying about
>backward compatibility. According to man page for packet, fanout
>was added in 3.1 kernel.
>
> - It would be useful to allow application to control fanout in more detail.
This is a great idea. Would introducing a new devarg, (e.g
'fanout_mode') be the proper way to allow the application to customize
fanout in more detail ?
--vdev=net_af_packet0,iface=eth1,blocksz=4096,framesz=2048,framecnt=512,qpairs=1,fanout_mode=[fanout_hash|fanout_cpu|fanout_rnd|fanout_qm]
Re: [PATCH 2/3] power: defer lcore variable allocation
On Fri, Dec 13, 2024 at 7:58 AM Mattias Rönnblom wrote:
> On 2024-12-12 08:57, David Marchand wrote:
> > clb_multiwait, clb_pause and clb_scale_freq callbacks can only be
> > reached after a successful call to
> > rte_power_ethdev_pmgmt_queue_enable.
> > Triggering an allocation in them means we are hiding a (internal)
> > programatic error as allocation and use of a lcore variable are
> > clearly separated atm.
> > If we keep the lcore var api as is, I would add an assert() (maybe
> > under a debug build option) in RTE_LCORE_VAR macros themselves, as
> > calling with a NULL handle means the initialisation path in some
> > code/RTE_LCORE_VAR API use was incorrect.
> >
>
> Sure, that would make sense. RTE_ASSERT(), that is. RTE_VERIFY() would
> be too expensive.
Yes, I'll send in next revision.
>
> >
> > Or because you propose to add the same type of helpers in both this
> > patch and the next, I am considering the other way: hide the
> > allocation in the RTE_LCORE_VAR* macros.
> > Checking for already allocated var in RTE_LCORE_VAR_ALLOC seems fine.
> > But the "fast path" RTE_LCORE_VAR would have an unwanted branch in most
> > cases.
> >
>
> I would prefer to have the ALLOC() macro with semantics most people
> expect from a macro (or function) with that name, which is, I would
> argue, an unconditional allocation.
> It would make sense to have another macro, which performs an allocation
> only if the handle is NULL.
>
> RTE_LCORE_VAR_ASSURE_ALLOCATED(), or just RTE_LCORE_VAR_ASSURE()
> (although the latter sounds a little like an assertion, and not an
> allocation).
>
> RTE_LCORE_VAR_LAZY_ALLOC()
>
> I don't know. Something like that.
- In the power libary case, allocating the lcore variable is followed
by the initialisation of the lcore variable internals (per lcore
tailqs).
For this patch, I will rename the alloc_lcore_cfgs helper I had in v1 as:
static void
+init_lcore_cfgs(void)
+{
+struct pmd_core_cfg *lcore_cfg;
+unsigned int lcore_id;
+
+if (lcore_cfgs != NULL)
+return;
+
+RTE_LCORE_VAR_ALLOC(lcore_cfgs);
+
+/* initialize all tailqs */
+RTE_LCORE_VAR_FOREACH(lcore_id, lcore_cfg, lcore_cfgs)
+TAILQ_INIT(&lcore_cfg->head);
+}
and only keep those checks in the public symbols.
- About more macros, I am wondering if this is needed in the end.
Adding assertions in the lcore var accessor should catch incorrect
initialisation path.
> >
> >> A somewhat unrelated question: why is pmd_core_cfg cache-line aligned? I
> >> don't think it should be.
> >
> > Before the conversion to per lcore variable, it was probably useful
> > (avoiding false sharing).
> > With the conversion, indeed, it looks like a waste of space.
> > It seems worth a separate fix.
> >
> >
>
> You will include it, or should I submit a separate patch?
I'll send it in next revision.
--
David Marchand
Re: [PATCH 0/3] Defer lcore variables allocation
On 12/10/2024 10:41 AM, Mattias Rönnblom wrote: Maybe the DAG is available on the build (meson) level, and thus the code can be generated out of that? There is in fact a patchset that produces just that kind of graph: https://patches.dpdk.org/project/dpdk/list/?series=34055 It's currently not very consumable by DPDK and it'd be a difficult task to integrate it into DPDK in such a way as to allow arbitrary libraries to use it, but building such a graph from build system is doable. However, IMO it would be easier to build such a graph at init time, where a component would register its dependencies with EAL, and EAL would handle the rest. That way, the bulk of the work lands in EAL, while component developers only have to specify the things they depend on. It could be a little tricky in that some components may depend on e.g. IPC which isn't a "component" as much as it's an init stage, but depending on IPC could just as well be depending on EAL having done init, while for internal components we can come up with some sort of internal init order mechanism. -- Thanks, Anatoly
Re: [PATCH v5 6/8] build: reduce driver dependencies
On Wed, Nov 27, 2024 at 5:20 PM Burakov, Anatoly wrote: > > On 11/27/2024 3:56 PM, Anatoly Burakov wrote: > > From: Bruce Richardson > > > > Remove any unnecessary dependencies from the driver dependency lists. > > This will give each driver a near-minimum set of required dependencies. > > > > Signed-off-by: Bruce Richardson > > Reviewed-by: Rosen Xu > > --- > > > > diff --git a/drivers/common/qat/meson.build b/drivers/common/qat/meson.build > > index 5a8de16fe0..5ffb56fc93 100644 > > --- a/drivers/common/qat/meson.build > > +++ b/drivers/common/qat/meson.build > > @@ -71,7 +71,7 @@ else > > endif > > endif > > > > -deps += ['bus_pci', 'cryptodev', 'net', 'compressdev'] > > +deps += ['bus_pci'] > > sources += files( > > 'qat_common.c', > > 'qat_qp.c', > > @@ -101,6 +101,7 @@ if qat_compress > > ] > > sources += files(join_paths(qat_compress_relpath, f)) > > endforeach > > +deps += ['compressdev'] > > endif > > > > if qat_crypto > > Seems that these changes were overly aggressive and cause build > failures. Will fix in v6. Indeed, some crypto-related headers still get included in "common" code. -- David Marchand
[PATCH v2] eventdev: add port attribute for independent enqueue
From: Pravin Pathak
Independent Enqueue support is added to DPDK 24.11.
Adding support for RTE_EVENT_PORT_ATTR_INDEPENDENT_ENQ attribute
to rte_event_port_attr_get() which was missing
Signed-off-by: Pravin Pathak
---
lib/eventdev/rte_eventdev.c | 8
lib/eventdev/rte_eventdev.h | 4
2 files changed, 12 insertions(+)
diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index ca295c87c4..61cff87b63 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -880,6 +880,14 @@ rte_event_port_attr_get(uint8_t dev_id, uint8_t port_id,
uint32_t attr_id,
*attr_value = !!(config & RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL);
break;
}
+ case RTE_EVENT_PORT_ATTR_INDEPENDENT_ENQ:
+ {
+ uint32_t config;
+
+ config = dev->data->ports_cfg[port_id].event_port_cfg;
+ *attr_value = !!(config & RTE_EVENT_PORT_CFG_INDEPENDENT_ENQ);
+ break;
+ }
default:
return -EINVAL;
};
diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
index fabd1490db..6400d6109f 100644
--- a/lib/eventdev/rte_eventdev.h
+++ b/lib/eventdev/rte_eventdev.h
@@ -1318,6 +1318,10 @@ rte_event_port_quiesce(uint8_t dev_id, uint8_t port_id,
* Port attribute id for the implicit release disable attribute of the port.
*/
#define RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE 3
+/**
+ * Port attribute id for the Independent Enqueue feature.
+ */
+#define RTE_EVENT_PORT_ATTR_INDEPENDENT_ENQ 4
/**
* Get an attribute from a port.
--
2.26.2
Re: [PATCH v2 2/6] drivers: drop export of driver headers
On 12/13/24 14:03, Bruce Richardson wrote: On Fri, Dec 13, 2024 at 11:50:06AM +0100, David Marchand wrote: Many classes are exposing driver only headers as public headers. Move them to the driver_sdk_headers list. Signed-off-by: David Marchand --- LGTM. The names of most of the headers are pretty clear that they should be sdk-only headers. Acked-by: Bruce Richardson Acked-by: Andrew Rybchenko
Re: [RFC] eventdev: add atomic queue to test-eventdev app
Thank you for the feedback. I will re-implement the test by not checking
port-flow-queue combination and generally clean-up the code based on your
comments.
On Tue, 2024-12-10 at 11:37 +0100, Mattias Rönnblom wrote:
>
> > +{
> > + struct rte_event_dev_info dev_info;
> > +
> > + rte_event_dev_info_get(dev_id, &dev_info);
> > + return (dev_info.event_dev_cap &
> > RTE_EVENT_DEV_CAP_MAINTENANCE_FREE) ?
> > + true : false;
>
> return dev_info.event_dev_cap & RTE_EVENT_DEV_CAP_MAINTENANCE_FREE;
>
> will work fine.
>
>
I decided against it in order to maintain consistent styling with similar
functions in the file.
>
> > +static int
> > +worker_wrapper(void *arg)
>
> Delete "wrapper".
All other eventdev-tests name their equivalent functions "worker_wrapper", so I
picked it to be consistent with the other tests.
>
> > +
> > + /* setup one port per worker, linking to all queues */
> > + ret = order_event_dev_port_setup(test, opt, nb_workers, NB_QUEUES);
>
> "order"?
This function is declared in test_order_common.h and is used in all tests. It
is not specific for "ordered" ports, so I thought it was OK to use.
> > +
> > +static void
> > +atomic_queue_opt_dump(struct evt_options *opt)
> > +{
> > + order_opt_dump(opt);
>
> "order"?
Same thing here.
Re: [PATCH v6] graph: mcore: optimize graph search
Salut Dodji,
On Mon, Dec 16, 2024 at 2:44 AM Huichao Cai wrote:
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 21b8cd6113..a92ee29512 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -33,3 +33,8 @@
>
> ; Temporary exceptions till next major ABI version ;
>
> +[suppress_type]
> + name = rte_node
> + has_size_change = no
> + has_data_member_inserted_between =
> +{offset_of(total_sched_fail), offset_of(xstat_off)}
Here is a suppression rule I suggested but does not have the intended effect.
For the context:
Before the change (that you can find below with the next hunk), we
made sure to zero the whole rte_node object at runtime in the library
allocator.
And the offset of the field next to 'dispatch' is fixed with an
explicit alignas() statement.
/** Fast schedule area for mcore dispatch model. */
union {
alignas(RTE_CACHE_LINE_MIN_SIZE) struct {
unsigned int lcore_id; /**< Node running
lcore. */
uint64_t total_sched_objs; /**< Number of
objects scheduled. */
uint64_t total_sched_fail; /**< Number of
scheduled failure. */
} dispatch;
};
/** Fast path area cache line 1. */
alignas(RTE_CACHE_LINE_MIN_SIZE)
rte_graph_off_t xstat_off; /**< Offset to xstat counters. */
If you want the whole definition, you can have a look at:
https://git.dpdk.org/dpdk/tree/lib/graph/rte_graph_worker_common.h#n87
[...]
> diff --git a/lib/graph/rte_graph_worker_common.h
> b/lib/graph/rte_graph_worker_common.h
> index d3ec88519d..aef0f65673 100644
> --- a/lib/graph/rte_graph_worker_common.h
> +++ b/lib/graph/rte_graph_worker_common.h
> @@ -110,6 +110,7 @@ struct __rte_cache_aligned rte_node {
> unsigned int lcore_id; /**< Node running lcore. */
> uint64_t total_sched_objs; /**< Number of objects
> scheduled. */
> uint64_t total_sched_fail; /**< Number of scheduled
> failure. */
> + struct rte_graph *graph; /**< Graph corresponding to
> lcore_id. */
> } dispatch;
> };
Now, the patch adds a new field in the struct {} dispatch field.
Here is what abidiff reports:
$ abidiff --version
abidiff: 2.6.0
$ abidiff --suppr
/home/dmarchan/git/pub/dpdk.org/main/devtools/libabigail.abignore
--no-added-syms --headers-dir1
/home/dmarchan/abi/v24.11/build-gcc-shared/usr/local/include
--headers-dir2
/home/dmarchan/builds/main/build-gcc-shared/install/usr/local/include
/home/dmarchan/abi/v24.11/build-gcc-shared/usr/local/lib64/librte_graph.so.25.0
/home/dmarchan/builds/main/build-gcc-shared/install/usr/local/lib64/librte_graph.so.25.1
Functions changes summary: 0 Removed, 1 Changed (9 filtered out), 0
Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
1 function with some indirect sub-type change:
[C] 'function bool
__rte_graph_mcore_dispatch_sched_node_enqueue(rte_node*,
rte_graph_rq_head*)' at rte_graph_model_mcore_dispatch.c:117:1 has
some indirect sub-type changes:
parameter 1 of type 'rte_node*' has sub-type changes:
in pointed to type 'struct rte_node' at rte_graph_worker_common.h:92:1:
type size hasn't changed
1 data member changes (2 filtered):
anonymous data member at offset 1536 (in bits) changed from:
union {struct {unsigned int lcore_id; uint64_t
total_sched_objs; uint64_t total_sched_fail;} dispatch;}
to:
union {struct {unsigned int lcore_id; uint64_t
total_sched_objs; uint64_t total_sched_fail; rte_graph* graph;}
dispatch;}
What would be the best way to suppress this warning?
I tried the following which seems to work, but I prefer to ask for your advice.
[suppress_type]
name = rte_node
has_data_member_at = offset_of(total_sched_fail)
Thanks.
--
David Marchand
Re: [PATCH 13/21] drivers/net: use portable variadic macros
On 12/11/24 05:05, Andre Muezerie wrote:
1) Use portable variadic macros
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a standard part of the C language with C99.
GCC, Clang and MSVC handle them properly.
The fix is to remove the prefix name (args... becomes ...) and use
__VA_ARGS__.
2) Add "do { } while (0)" to macros used to remove logging calls, to
ensure there's no code structure change when enabling/disabling
logging.
Signed-off-by: Andre Muezerie
For sfc,
Acked-by: Andrew Rybchenko
[PATCH] net/sfc: avoid duplicate configuration restore
MAC address, promiscuous and all-multicast modes are restored correctly
upon device start by the PMD itself. ethdev layer should not duplicate it.
Signed-off-by: Andrew Rybchenko
---
drivers/net/sfc/sfc_ethdev.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/sfc/sfc_ethdev.c b/drivers/net/sfc/sfc_ethdev.c
index 89444f0b4a..82fbdbae9c 100644
--- a/drivers/net/sfc/sfc_ethdev.c
+++ b/drivers/net/sfc/sfc_ethdev.c
@@ -2722,6 +2722,14 @@ sfc_fec_set(struct rte_eth_dev *dev, uint32_t fec_capa)
return -rc;
}
+static uint64_t
+sfc_get_restore_flags(__rte_unused struct rte_eth_dev *dev,
+ __rte_unused enum rte_eth_dev_operation op)
+{
+ /* sfc PMD does not require any configuration restore */
+ return 0;
+}
+
static const struct eth_dev_ops sfc_eth_dev_ops = {
.dev_configure = sfc_dev_configure,
.dev_start = sfc_dev_start,
@@ -2774,6 +2782,7 @@ static const struct eth_dev_ops sfc_eth_dev_ops = {
.fec_get_capability = sfc_fec_get_capability,
.fec_get= sfc_fec_get,
.fec_set= sfc_fec_set,
+ .get_restore_flags = sfc_get_restore_flags,
};
struct sfc_ethdev_init_data {
--
2.39.5
RE: 21.11.9 patches review and test
> -Original Message- > From: Kevin Traynor > Sent: Wednesday, December 4, 2024 5:59 PM > To: sta...@dpdk.org > Cc: dev@dpdk.org; Abhishek Marathe ; Ali > Alnubani ; David Christensen ; > Hemant Agrawal ; Ian Stokes > ; Jerin Jacob ; John McNamara > ; Ju-Hyoung Lee ; Kevin > Traynor ; Luca Boccassi ; Pei Zhang > ; Raslan Darawsheh ; NBU- > Contact-Thomas Monjalon (EXTERNAL) ; > yangh...@redhat.com > Subject: 21.11.9 patches review and test > > Hi all, > > Here is a list of patches targeted for stable release 21.11.9. > > The planned date for the final release is 17th December 2024. > > Please help with testing and validation of your use cases and report > any issues/results with reply-all to this mail. For the final release > the fixes and reported validations will be added to the release notes. > > A release candidate tarball can be found at: > > https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.9-rc1 > > These patches are located at branch 21.11 of dpdk-stable repo: > https://dpdk.org/browse/dpdk-stable/ > > Thanks. > > Kevin > > --- Hello, We ran the following functional tests with Nvidia hardware on 21.11.9-rc1, and we don't see new issues caused by the changes in this release.: - Basic functionality: Send and receive multiple types of traffic. - testpmd xstats counter test. - testpmd timestamp test. - Changing/checking link status through testpmd. - rte_flow tests (https://doc.dpdk.org/guides/nics/mlx5.html#supported-hardware-offloads) - RSS tests. - VLAN filtering, stripping, and insertion tests. - Checksum and TSO tests. - ptype tests. - link_status_interrupt example application tests. - l3fwd-power example application tests. - Multi-process example applications tests. - Hardware LRO tests. - Buffer Split tests. - Tx scheduling tests. Functional tests ran on: - NIC: ConnectX-6 Dx / OS: Ubuntu 22.04 / Driver: MLNX_OFED_LINUX-24.10-1.1.4.0 / Firmware: 22.43.2026 - NIC: ConnectX-7 / OS: Ubuntu 22.04 / Driver: MLNX_OFED_LINUX-24.10-1.1.4.0 / Firmware: 28.43.2026 - DPU: BlueField-2 / DOCA SW version: 2.9.1 / Firmware: 24.43.2026 Additionally, we ran build tests with multiple configurations on the following OS/driver combinations (all passed): - Debian 12 with MLNX_OFED_LINUX-24.10-1.1.4.0. - Ubuntu 22.04 with MLNX_OFED_LINUX-24.10-1.1.4.0. - Ubuntu 24.04 with MLNX_OFED_LINUX-24.10-1.1.4.0. - Ubuntu 24.04 with rdma-core v50.0. - Fedora 40 with rdma-core v48.0. - Fedora 42 (Rawhide) with rdma-core v51.0. - OpenSUSE Leap 15.6 with rdma-core v49.1. Thanks, Ali
Re: [PATCH v2 1/5] ethdev: check that device supports deferred start
On Sun, 15 Dec 2024 11:56:55 +0300 Andrew Rybchenko wrote: > On 12/14/24 21:07, Stephen Hemminger wrote: > > The check for supporting deferred start should be handled at > > the ethdev level for all devices. > > It is a good idea to check it on ethdev level. > > Strictly speaking presence of queue start/stop callback does not mean > support for deferred start right now. It is possible to use stop/start > without deferred start feature. Right, there are drivers that define the callback but have no logic in place to do deferred start. They just ignore the flag. Drivers with this odditiy are: ark, atlantic, cxgbe, enic, hinic, ipn3ke, nfb, nfp, ntnic This patch set won't change that. There are also some drivers which claim to support queue start/stop in the documentation, but there is no functions: virtio, mana, netvsc, mlx4, vmxnet3 Will fix that in next version of this series. > > However, such check is much better than nothing since deferred start > definitely requires queue start callback. > > It would be good to clarify it in the documentation. > doc/guides/nics/features.rst does not mention deferred start at all. > In fact, I don't mind to couple deferred start to queue start/stop > features. It is a bug that the drivers that do queue start/stop and don't implement deferred start. There is no hardware reason to not support it, just missing feature during driver development. > > One nit below. > > Anyway: > Acked-by: Andrew Rybchenko
[PATCH v3 3/6] net/dpaa: remove unnecessary deferred start check
This check is now done in ethdev layer.
Signed-off-by: Stephen Hemminger
---
drivers/net/dpaa/dpaa_ethdev.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index e8d34e5898..ce48f0 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -1089,11 +1089,6 @@ int dpaa_eth_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
return -rte_errno;
}
- /* Rx deferred start is not supported */
- if (rx_conf->rx_deferred_start) {
- DPAA_PMD_ERR("%p:Rx deferred start not supported", (void *)dev);
- return -EINVAL;
- }
rxq->nb_desc = UINT16_MAX;
rxq->offloads = rx_conf->offloads;
@@ -1399,11 +1394,6 @@ int dpaa_eth_tx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
PMD_INIT_FUNC_TRACE();
- /* Tx deferred start is not supported */
- if (tx_conf->tx_deferred_start) {
- DPAA_PMD_ERR("%p:Tx deferred start not supported", (void *)dev);
- return -EINVAL;
- }
txq->nb_desc = UINT16_MAX;
txq->offloads = tx_conf->offloads;
--
2.45.2
[PATCH v3 2/6] doc: fix feature flags for queue start/stop
Several drivers have mismatch between the ethdev ops for queue start/stop and the documentation. The gve driver does implement queue start/stop support. The mana, netvsc, virtio and vmxnet3 drivers do not implement the rx_queue_start callback. Signed-off-by: Stephen Hemminger --- doc/guides/nics/features/gve.ini | 1 + doc/guides/nics/features/mana.ini| 1 - doc/guides/nics/features/netvsc.ini | 1 - doc/guides/nics/features/virtio.ini | 1 - doc/guides/nics/features/vmxnet3.ini | 1 - 5 files changed, 1 insertion(+), 4 deletions(-) diff --git a/doc/guides/nics/features/gve.ini b/doc/guides/nics/features/gve.ini index 8dfa229bb0..f18b829eda 100644 --- a/doc/guides/nics/features/gve.ini +++ b/doc/guides/nics/features/gve.ini @@ -6,6 +6,7 @@ [Features] Speed capabilities = Y Link status = Y +Queue start/stop = Y MTU update = Y TSO = Y RSS hash = Y diff --git a/doc/guides/nics/features/mana.ini b/doc/guides/nics/features/mana.ini index 42fd3327d2..db555ffe27 100644 --- a/doc/guides/nics/features/mana.ini +++ b/doc/guides/nics/features/mana.ini @@ -8,7 +8,6 @@ Speed capabilities = P Link status = P Removal event= Y Rx interrupt = Y -Queue start/stop = Y RSS hash = Y L3 checksum offload = Y L4 checksum offload = Y diff --git a/doc/guides/nics/features/netvsc.ini b/doc/guides/nics/features/netvsc.ini index de8c698184..32df77a03e 100644 --- a/doc/guides/nics/features/netvsc.ini +++ b/doc/guides/nics/features/netvsc.ini @@ -7,7 +7,6 @@ Speed capabilities = P Link status = Y Free Tx mbuf on demand = Y -Queue start/stop = Y Scattered Rx = Y Promiscuous mode = Y Allmulticast mode= Y diff --git a/doc/guides/nics/features/virtio.ini b/doc/guides/nics/features/virtio.ini index a5eab4932f..f0a1a564f9 100644 --- a/doc/guides/nics/features/virtio.ini +++ b/doc/guides/nics/features/virtio.ini @@ -8,7 +8,6 @@ Speed capabilities = P Link status = Y Link status event= Y Rx interrupt = Y -Queue start/stop = Y Scattered Rx = P Promiscuous mode = Y Allmulticast mode= Y diff --git a/doc/guides/nics/features/vmxnet3.ini b/doc/guides/nics/features/vmxnet3.ini index 971695fc4a..749887d642 100644 --- a/doc/guides/nics/features/vmxnet3.ini +++ b/doc/guides/nics/features/vmxnet3.ini @@ -7,7 +7,6 @@ Speed capabilities = P Link status = Y Link status event= Y -Queue start/stop = Y MTU update = Y LRO = Y TSO = Y -- 2.45.2
[PATCH v3 5/6] net/enetfec: remove unneeded deferred start check
Already checked in ethdev now.
Signed-off-by: Stephen Hemminger
---
drivers/net/enetfec/enet_ethdev.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/net/enetfec/enet_ethdev.c
b/drivers/net/enetfec/enet_ethdev.c
index 91c0f60490..9835532595 100644
--- a/drivers/net/enetfec/enet_ethdev.c
+++ b/drivers/net/enetfec/enet_ethdev.c
@@ -366,7 +366,7 @@ enetfec_tx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
uint16_t nb_desc,
unsigned int socket_id __rte_unused,
- const struct rte_eth_txconf *tx_conf)
+ const struct rte_eth_txconf *tx_conf __rte_unused)
{
struct enetfec_private *fep = dev->data->dev_private;
unsigned int i;
@@ -377,12 +377,6 @@ enetfec_tx_queue_setup(struct rte_eth_dev *dev,
sizeof(struct bufdesc);
unsigned int dsize_log2 = rte_fls_u64(dsize) - 1;
- /* Tx deferred start is not supported */
- if (tx_conf->tx_deferred_start) {
- ENETFEC_PMD_ERR("Tx deferred start not supported");
- return -EINVAL;
- }
-
/* allocate transmit queue */
txq = rte_zmalloc(NULL, sizeof(*txq), RTE_CACHE_LINE_SIZE);
if (txq == NULL) {
@@ -443,7 +437,7 @@ enetfec_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
uint16_t nb_rx_desc,
unsigned int socket_id __rte_unused,
- const struct rte_eth_rxconf *rx_conf,
+ const struct rte_eth_rxconf *rx_conf __rte_unused,
struct rte_mempool *mb_pool)
{
struct enetfec_private *fep = dev->data->dev_private;
@@ -456,12 +450,6 @@ enetfec_rx_queue_setup(struct rte_eth_dev *dev,
sizeof(struct bufdesc);
unsigned int dsize_log2 = rte_fls_u64(dsize) - 1;
- /* Rx deferred start is not supported */
- if (rx_conf->rx_deferred_start) {
- ENETFEC_PMD_ERR("Rx deferred start not supported");
- return -EINVAL;
- }
-
if (queue_idx >= ENETFEC_MAX_Q) {
ENETFEC_PMD_ERR("Invalid queue id %" PRIu16 ", max %d",
queue_idx, ENETFEC_MAX_Q);
--
2.45.2
[PATCH v3 1/6] ethdev: check that device supports deferred start
The check for supporting deferred start should be handled at
the ethdev level for all devices.
Signed-off-by: Stephen Hemminger
Acked-by: Andrew Rybchenko
---
lib/ethdev/rte_ethdev.c | 16
1 file changed, 16 insertions(+)
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 6413c54e3b..7678fa47b6 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -2264,6 +2264,14 @@ rte_eth_rx_queue_setup(uint16_t port_id, uint16_t
rx_queue_id,
if (rx_conf != NULL)
rx_offloads |= rx_conf->offloads;
+ /* Deferred start requires that device supports queue start */
+ if (rx_conf != NULL && rx_conf->rx_deferred_start &&
+ *dev->dev_ops->rx_queue_start == NULL) {
+ RTE_ETHDEV_LOG_LINE(ERR,
+ "Deferred start requested, but driver does not
support queue start");
+ return -ENOTSUP;
+ }
+
/* Ensure that we have one and only one source of Rx buffers */
if ((mp != NULL) +
(rx_conf != NULL && rx_conf->rx_nseg > 0) +
@@ -2575,6 +2583,14 @@ rte_eth_tx_queue_setup(uint16_t port_id, uint16_t
tx_queue_id,
return -EINVAL;
}
+ /* Deferred start requires that device supports queue start */
+ if (tx_conf != NULL && tx_conf->tx_deferred_start &&
+ *dev->dev_ops->tx_queue_start == NULL) {
+ RTE_ETHDEV_LOG_LINE(ERR,
+ "Deferred start requested, but driver does not
support queue start");
+ return -ENOTSUP;
+ }
+
ret = rte_eth_dev_info_get(port_id, &dev_info);
if (ret != 0)
return ret;
--
2.45.2
[PATCH v3 0/6] queue start/stop and deferred checks
Recent zxdh driver review raised the question of why should drivers have to check rx_conf for deferred start support. This can be better handled across all drivers at ethdev level. Also found some drivers were incorrect in feature flags about handling of queue start/stop. v3 - fix doc about queue start/stop for some drivers Stephen Hemminger (6): ethdev: check that device supports deferred start doc: fix feature flags for queue start/stop net/dpaa: remove unnecessary deferred start check net/dpaa2: remove unneeded deferred start check net/enetfec: remove unneeded deferred start check net/virtio: remove unneeded deferred start check doc/guides/nics/features/gve.ini | 1 + doc/guides/nics/features/mana.ini| 1 - doc/guides/nics/features/netvsc.ini | 1 - doc/guides/nics/features/virtio.ini | 1 - doc/guides/nics/features/vmxnet3.ini | 1 - drivers/net/dpaa/dpaa_ethdev.c | 10 -- drivers/net/dpaa2/dpaa2_ethdev.c | 14 -- drivers/net/enetfec/enet_ethdev.c| 16 ++-- drivers/net/virtio/virtio_rxtx.c | 10 -- lib/ethdev/rte_ethdev.c | 16 10 files changed, 19 insertions(+), 52 deletions(-) -- 2.45.2
[PATCH v3 6/6] net/virtio: remove unneeded deferred start check
Already checked in ethdev now.
Signed-off-by: Stephen Hemminger
---
drivers/net/virtio/virtio_rxtx.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index b67f063b31..6ae3a6eb12 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -654,11 +654,6 @@ virtio_dev_rx_queue_setup(struct rte_eth_dev *dev,
PMD_INIT_FUNC_TRACE();
- if (rx_conf->rx_deferred_start) {
- PMD_INIT_LOG(ERR, "Rx deferred start is not supported");
- return -EINVAL;
- }
-
buf_size = virtio_rx_mem_pool_buf_size(mp);
if (!virtio_rx_check_scatter(hw->max_rx_pkt_len, buf_size,
hw->rx_ol_scatter, &error)) {
@@ -819,11 +814,6 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
PMD_INIT_FUNC_TRACE();
- if (tx_conf->tx_deferred_start) {
- PMD_INIT_LOG(ERR, "Tx deferred start is not supported");
- return -EINVAL;
- }
-
if (nb_desc == 0 || nb_desc > vq->vq_nentries)
nb_desc = vq->vq_nentries;
vq->vq_free_cnt = RTE_MIN(vq->vq_free_cnt, nb_desc);
--
2.45.2
[PATCH v3 4/6] net/dpaa2: remove unneeded deferred start check
Already checked in ethdev now.
Signed-off-by: Stephen Hemminger
---
drivers/net/dpaa2/dpaa2_ethdev.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index a9bce854c3..8624bba0ce 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -726,13 +726,6 @@ dpaa2_dev_rx_queue_setup(struct rte_eth_dev *dev,
DPAA2_PMD_WARN("To use Normal buffers, run 'export
DPNI_NORMAL_BUF=1' before running dynamic_dpl.sh script");
}
- /* Rx deferred start is not supported */
- if (rx_conf->rx_deferred_start) {
- DPAA2_PMD_ERR("%s:Rx deferred start not supported",
- dev->data->name);
- return -EINVAL;
- }
-
if (!priv->bp_list || priv->bp_list->mp != mb_pool) {
if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
ret = rte_dpaa2_bpid_info_init(mb_pool);
@@ -889,13 +882,6 @@ dpaa2_dev_tx_queue_setup(struct rte_eth_dev *dev,
PMD_INIT_FUNC_TRACE();
- /* Tx deferred start is not supported */
- if (tx_conf->tx_deferred_start) {
- DPAA2_PMD_ERR("%s:Tx deferred start not supported",
- dev->data->name);
- return -EINVAL;
- }
-
dpaa2_q->nb_desc = UINT16_MAX;
dpaa2_q->offloads = tx_conf->offloads;
--
2.45.2
Re: [PATCH v2 1/5] ethdev: check that device supports deferred start
On 12/16/24 21:58, Stephen Hemminger wrote: On Sun, 15 Dec 2024 11:56:55 +0300 Andrew Rybchenko wrote: On 12/14/24 21:07, Stephen Hemminger wrote: The check for supporting deferred start should be handled at the ethdev level for all devices. It is a good idea to check it on ethdev level. Strictly speaking presence of queue start/stop callback does not mean support for deferred start right now. It is possible to use stop/start without deferred start feature. Right, there are drivers that define the callback but have no logic in place to do deferred start. They just ignore the flag. Drivers with this odditiy are: ark, atlantic, cxgbe, enic, hinic, ipn3ke, nfb, nfp, ntnic This patch set won't change that. There are also some drivers which claim to support queue start/stop in the documentation, but there is no functions: virtio, mana, netvsc, mlx4, vmxnet3 Will fix that in next version of this series. However, such check is much better than nothing since deferred start definitely requires queue start callback. It would be good to clarify it in the documentation. doc/guides/nics/features.rst does not mention deferred start at all. In fact, I don't mind to couple deferred start to queue start/stop features. It is a bug that the drivers that do queue start/stop and don't implement deferred start. There is no hardware reason to not support it, just missing feature during driver development. I agree. Please, don't forget to add rx_deferred_start and tx_deferred_start to queue start/stop features in doc/guides/nics/features.rst. One nit below. Anyway: Acked-by: Andrew Rybchenko
RE: 23.11.3 patches review and test
> -Original Message- > From: Xueming Li > Sent: Tuesday, December 10, 2024 10:49 PM > To: sta...@dpdk.org > Cc: dev@dpdk.org; Abhishek Marathe ; > Ali Alnubani ; David Christensen > ; Hemant Agrawal ; > Stokes, Ian ; Jerin Jacob ; > Mcnamara, John ; Ju-Hyoung Lee > ; Kevin Traynor ; Luca > Boccassi ; Pei Zhang ; Raslan > Darawsheh ; Thomas Monjalon > ; Yanghang Liu ; > benjamin.wal...@intel.com; qian.q...@intel.com; yuan.p...@intel.com; > zhaoyan.c...@intel.com > Subject: 23.11.3 patches review and test > > Hi all, > > Here is a list of patches targeted for stable release 23.11.3. > > The planned date for the final release is 17th December. > > Please help with testing and validation of your use cases and report any > issues/results with reply-all to this mail. For the final release the fixes > and > reported validations will be added to the release notes. > > A release candidate tarball can be found at: > > https://dpdk.org/browse/dpdk-stable/tag/?id=v23.11.3-rc1 > > These patches are located at branch 23.11 of dpdk-stable repo: > https://dpdk.org/browse/dpdk-stable/ > > Thanks. > > Xueming Li > > --- Update the test status for Intel part. dpdk23.11.3-rc1 all validation test done. no new issue is found. known issues: Failed to add vdev when launch dpdk-pdump with vdev secondary process start dpdk-pdump in VM with virtio-0.95 protocol failed Note: fix patch has been merged into main, but they not merged 23.11.3, so this issue still exists in 23.11.3-rc1 Patch link: https://patchwork.dpdk.org/project/dpdk/patch/20240314093630.1066948-2-mingjinx...@intel.com/ https://patchwork.dpdk.org/project/dpdk/list/?series=30356&archive=both&state=* # Basic Intel(R) NIC testing * Build & CFLAG compile: cover the build test combination with latest GCC/Clang version and the popular OS revision such as Ubuntu24.10, Ubuntu24.04, Fedora40, RHEL8.10, RHEL9.4, FreeBSD14.1, SUSE15, openEuler22.03-SP2, OpenAnolis8.9 etc. - All test done. No new dpdk issue is found. * PF(i40e, ixgbe): test scenarios including RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - All test done. No new dpdk issue is found. * VF(i40e, ixgbe): test scenarios including VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - All test done. No new dpdk issue is found. * PF/VF(ice): test scenarios including Switch features/Package Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible Descriptor, etc. - All test done. No new dpdk issue is found. * Intel NIC single core/NIC performance: test scenarios including PF/VF single core performance test, etc. - All test done. No new dpdk issue is found. * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - QAT&SW/FIB library, etc. - All test done. No new dpdk issue is found. # Basic cryptodev and virtio testing * Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing/VMAWARE ESXI 8.0, etc. - All test done. No new dpdk issue is found. * Cryptodev: *Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. - All test done. No new dpdk issue is found. *Performance test: test scenarios including Thoughput Performance/Cryptodev Latency, etc. - All test done. No new dpdk issue is found. Regards, Xu, Hailin
