Re: [PATCH v3 0/5] add feature arc in rte_graph
On Wed, 9 Oct 2024 18:59:57 +0530 Nitin Saxena wrote: > Feature arc represents an ordered list of features/protocols at a given > networking layer. It is a high level abstraction to connect various > rte_graph nodes, as feature nodes, and allow packets steering across > these nodes in a generic manner. > > Features (or feature nodes) are nodes which handles partial or complete > handling of a protocol in fast path. Like ipv4-rewrite node, which adds > rewrite data to an outgoing IPv4 packet. > > However in above example, outgoing interface(say "eth0") may have > outbound IPsec policy enabled, hence packets must be steered from > ipv4-rewrite node to ipsec-outbound-policy node for outbound IPsec > policy lookup. On the other hand, packets routed to another interface > (eth1) will not be sent to ipsec-outbound-policy node as IPsec feature > is disabled on eth1. Feature-arc allows rte_graph applications to manage > such constraints easily > > Feature arc abstraction allows rte_graph based application to > > 1. Seamlessly steer packets across feature nodes based on whether > feature is enabled or disabled on an interface. Features enabled on one > interface may not be enabled on another interface with in a same feature > arc. > > 2. Allow enabling/disabling of features on an interface at runtime, > so that if a feature is disabled, packets associated with that interface > won't be steered to corresponding feature node. > > 3. Provides mechanism to hook custom/user-defined nodes to a feature > node and allow packet steering from feature node to custom node without > changing former's fast path function > > 4. Allow expressing features in a particular sequential order so that > packets are steered in an ordered way across nodes in fast path. For > eg: if IPsec and IPv4 features are enabled on an ingress interface, > packets must be sent to IPsec inbound policy node first and then to ipv4 > lookup node. > > This patch series adds feature arc library in rte_graph and also adds > "ipv4-output" feature arc handling in "ipv4-rewrite" node. > > Changes in v3: > - rte_graph_feature_arc_t typedef from uint64_t to uintptr_t to fix > compilation on 32-bit machine > - Updated images in .png format > - Added ABI change section in release notes > - Fixed DPDK CI failures > > Changes in v2: > - Added unit tests for feature arc > - Fixed issues found in testing > - Added new public APIs rte_graph_feature_arc_feature_to_node(), > rte_graph_feature_arc_feature_to_name(), > rte_graph_feature_arc_num_features() > - Added programming guide for feature arc > - Added release notes for feature arc > > Nitin Saxena (5): > graph: add feature arc support > graph: add feature arc option in graph create > graph: add IPv4 output feature arc > test/graph_feature_arc: add functional tests > docs: add programming guide for feature arc > > app/test/meson.build|1 + > app/test/test_graph_feature_arc.c | 1410 +++ > doc/guides/prog_guide/graph_lib.rst | 288 > doc/guides/prog_guide/img/feature_arc-1.png | Bin 0 -> 61532 bytes > doc/guides/prog_guide/img/feature_arc-2.png | Bin 0 -> 155806 bytes > doc/guides/prog_guide/img/feature_arc-3.png | Bin 0 -> 143697 bytes > doc/guides/rel_notes/release_24_11.rst | 13 + > lib/graph/graph.c |1 + > lib/graph/graph_feature_arc.c | 1223 > lib/graph/graph_populate.c |7 +- > lib/graph/graph_private.h |3 + > lib/graph/meson.build |2 + > lib/graph/node.c|2 + > lib/graph/rte_graph.h |3 + > lib/graph/rte_graph_feature_arc.h | 431 ++ > lib/graph/rte_graph_feature_arc_worker.h| 674 + > lib/graph/version.map | 20 + > lib/node/ip4_rewrite.c | 476 +-- > lib/node/ip4_rewrite_priv.h | 15 +- > lib/node/node_private.h | 20 +- > lib/node/rte_node_ip4_api.h |3 + > 21 files changed, 4494 insertions(+), 98 deletions(-) > create mode 100644 app/test/test_graph_feature_arc.c > create mode 100644 doc/guides/prog_guide/img/feature_arc-1.png > create mode 100644 doc/guides/prog_guide/img/feature_arc-2.png > create mode 100644 doc/guides/prog_guide/img/feature_arc-3.png > create mode 100644 lib/graph/graph_feature_arc.c > create mode 100644 lib/graph/rte_graph_feature_arc.h > create mode 100644 lib/graph/rte_graph_feature_arc_worker.h > Looks good, but likely missing an RTE_ATOMIC() around the feature enable bitmask. Build fails: [Begin job log] "ubuntu-22.04-clang-stdatomic" at step Build and test r
Re: [PATCH 0/4] net/mlx5: series to fix and improve tx trace capabilities
On Wed, 9 Oct 2024 14:40:24 +0300 Viacheslav Ovsiienko wrote: > There is a series of weakly dependent patches related to the tx trace > in mlx5 PMD: > - fix issue in the trace dump Python script > - update the real-time clock reading routine, make it atomic >and move its initialization to the driver startup > - advance the tx tracing in mlx5 PMD, provide real time parameter, >read from the NIC to synchronize trace records with HW descriptors > - update the trace dump script to see raw records and incomplete bursts > > Signed-off-by: Viacheslav Ovsiienko > > Tim Martin (2): > net/mlx5: fix real time counter reading from PCI BAR > net/mlx5: fix Tx tracing to use single clock source > > Viacheslav Ovsiienko (2): > net/mlx5/tools: fix trace dump multiple burst completions > net/mlx5: update dump script to show incomplete records > > .mailmap | 1 + > doc/guides/nics/mlx5.rst | 6 ++ > drivers/net/mlx5/mlx5.c | 4 ++ > drivers/net/mlx5/mlx5_trace.h| 9 ++- > drivers/net/mlx5/mlx5_tx.h | 53 ++-- > drivers/net/mlx5/mlx5_txpp.c | 11 +--- > drivers/net/mlx5/tools/mlx5_trace.py | 90 > 7 files changed, 133 insertions(+), 41 deletions(-) Series-Acked-by: Stephen Hemminger
Re: [PATCH v6 1/7] event/dlb2: include headers for vector and memory copy APIs
On Fri, 20 Sep 2024 12:27:10 +0200 Mattias Rönnblom wrote: > The DLB2 PMD depended on being included as a side-effect > of being included. > > In addition, DLB2 used rte_memcpy() but did not include , > but rather depended on other include files to do so. > > This patch addresses both of those issues. > > Signed-off-by: Mattias Rönnblom > Acked-by: Bruce Richardson Have to ask, why is it using rte_memcpy when it could just assignment. Assignment is better since it keeps type safety. diff --git a/drivers/event/dlb2/dlb2.c b/drivers/event/dlb2/dlb2.c index c43ab864ca..51870486ed 100644 --- a/drivers/event/dlb2/dlb2.c +++ b/drivers/event/dlb2/dlb2.c @@ -1668,7 +1668,7 @@ dlb2_hw_create_ldb_port(struct dlb2_eventdev *dlb2, qm_port->issued_releases = 0; /* Save config message too. */ - rte_memcpy(&qm_port->cfg.ldb, &cfg, sizeof(qm_port->cfg.ldb)); + qm_port->cfg.ldb = cfg; /* update state */ qm_port->state = PORT_STARTED; /* enabled at create time */ @@ -1869,7 +1869,7 @@ dlb2_hw_create_dir_port(struct dlb2_eventdev *dlb2, qm_port->issued_releases = 0; /* Save config message too. */ - rte_memcpy(&qm_port->cfg.dir, &cfg, sizeof(qm_port->cfg.dir)); + qm_port->cfg.dir = cfg; /* update state */ qm_port->state = PORT_STARTED; /* enabled at create time */
Re: [PATCH] doc: update TAP device features
On Sun, 6 Oct 2024 21:36:31 +0100 Ferruh Yigit wrote: > On 10/4/2024 9:48 PM, Stephen Hemminger wrote: > > On Fri, 4 Oct 2024 02:48:21 +0100 > > Ferruh Yigit wrote: > > > >>> +Stats per queue = Y > >>> > >> > >> This feature name is misleading, > >> it is for 'rte_eth_dev_set_[rt]x_queue_stats_mapping()' API, which is > >> indeed for covering limitation for some drivers. > >> Tap does support getting stats per queue, but doesn't support above > >> documented feature. > > > > Just looked and the current state of the feature matrix is not correct > > for this part of the table. Although the feature intro says it is > > stats per queue mapping, that is not what other drivers are doing. > > > > Only these drivers have queue_stats_mapping_set: > > cnxk, enic, igc, ixgbe, txgbe, virtio > > > > These drivers claim to have 'Stats per queue' but do not have stats mapping: > > af_xdp, ark, atlantic, avp, bnxt, cxgbe, failsafe, fm10, hinic, hns3, > > ionic, mlx4, mlx5, netvsc, nfb, nfp, ngbe, qede, thunderx, vmxnet3 > > > > So the overwhelming practice is that the features.rst description is wrong! > > > > You are right. > > What about update the 'features.rst', and extend the definition of > 'Stats per queue' mapping + queue stats in basic stats or extended stats. > This will be make name of the feature more intuitive. Like this? diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst index cd0115ffb3..a351d7b3b5 100644 --- a/doc/guides/nics/features.rst +++ b/doc/guides/nics/features.rst @@ -727,8 +727,6 @@ Basic stats Support basic statistics such as: ipackets, opackets, ibytes, obytes, imissed, ierrors, oerrors, rx_nombuf. -And per queue stats: q_ipackets, q_opackets, q_ibytes, q_obytes, q_errors. - These apply to all drivers. * **[implements] eth_dev_ops**: ``stats_get``, ``stats_reset``. @@ -754,7 +752,8 @@ Supports Extended Statistics, changes from driver to driver. Stats per queue --- -Supports configuring per-queue stat counter mapping. +Supports per queue stats: q_ipackets, q_opackets, q_ibytes, q_obytes, q_errors. +May also support configuring per-queue stat counter mapping. * **[implements] eth_dev_ops**: ``queue_stats_mapping_set``. * **[related]API**: ``rte_eth_dev_set_rx_queue_stats_mapping()``,
Re: [PATCH v2] fib: network byte order IPv4 lookup
On Tue, 8 Oct 2024 17:16:05 + Vladimir Medvedkin wrote: > Previously when running rte_fib_lookup IPv4 addresses must have been in > host byte order. > > This patch adds a new flag RTE_FIB_FLAG_LOOKUP_BE that can be passed on > fib create, which will allow to have IPv4 in network byte order on > lookup. > > Signed-off-by: Vladimir Medvedkin Need to address David's comment see the build failures. Build URL: https://github.com/ovsrobot/dpdk/actions/runs/11240928255 Build Logs: ---Summary of failed steps--- "ubuntu-22.04-gcc-static-i386" failed at step Build and test "ubuntu-22.04-gcc-shared-aarch64" failed at step Build and test "ubuntu-22.04-gcc-ppc64le" failed at step Build and test "ubuntu-22.04-gcc-riscv64" failed at step Build and test --End summary of failed steps ---BEGIN LOGS [Begin job log] "ubuntu-22.04-gcc-static-i386" at step Build and test [423/3186] Compiling C object 'lib/76b5a35@@rte_fib at sta/fib_rte_fib.c.o'. [424/3186] Compiling C object 'lib/76b5a35@@rte_pdcp at sta/pdcp_pdcp_ctrl_pdu.c.o'. [425/3186] Compiling C object 'lib/76b5a35@@rte_pdcp at sta/pdcp_pdcp_reorder.c.o'. [426/3186] Generating ipsec.sym_chk with a meson_exe.py custom command. [427/3186] Linking target lib/librte_ipsec.so.25.0. [428/3186] Compiling C object 'lib/76b5a35@@rte_pdcp at sta/pdcp_rte_pdcp.c.o'. [429/3186] Generating symbol file 'lib/76b5a35@@rte_ipsec at sha/librte_ipsec.so.25.0.symbols'. [430/3186] Compiling C object 'lib/76b5a35@@rte_fib at sta/fib_rte_fib6.c.o'. [431/3186] Compiling C object 'lib/76b5a35@@rte_port at sta/port_port_log.c.o'. [432/3186] Compiling C object 'lib/76b5a35@@rte_fib at sta/fib_trie.c.o'. [433/3186] Compiling C object 'lib/76b5a35@@rte_fib at sta/fib_dir24_8.c.o'. FAILED: lib/76b5a35@@rte_fib at sta/fib_dir24_8.c.o ccache gcc -Ilib/76b5a35@@rte_fib at sta -Ilib -I../lib -Ilib/fib -I../lib/fib -I. -I../ -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include -I../lib/eal/x86/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/log -I../lib/log -Ilib/telemetry/../metrics -I../lib/telemetry/../metrics -Ilib/telemetry -I../lib/telemetry -Ilib/rib -I../lib/rib -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11 -O2 -g -include rte_config.h -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned -Wno-missing-field-initializers -Wno-zero-length-bounds -Wno-pointer-to-int-cast -D_GNU_SOURCE -m32 -fPIC -march=corei7 -mrtm -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation -DRTE_LOG_DEFAULT_LOGTYPE=lib.fib -MD -MQ 'lib/76b5a35@@rte_fib at sta/fib_dir24_8.c.o' -MF 'lib/76b5a35@@rte_fib at sta/fib_dir24_8.c.o.d' -o 'lib/76b5a35@@rte_fib at sta/fib_dir24_8.c.o' -c ../lib/fib/dir24_8.c ../lib/fib/dir24_8.c: In function ‘get_vector_fn’: ../lib/fib/dir24_8.c:71:54: error: unused parameter ‘be_addr’ [-Werror=unused-parameter] 71 | get_vector_fn(enum rte_fib_dir24_8_nh_sz nh_sz, bool be_addr) | ^ cc1: all warnings being treated as errors [434/3186] Compiling C object 'lib/76b5a35@@rte_port at sta/port_rte_port_ethdev.c.o'. [435/3186] Compiling C object 'lib/76b5a35@@rte_port at sta/port_rte_port_fd.c.o'. [436/3186] Compiling C object 'lib/76b5a35@@rte_pdcp at sta/pdcp_pdcp_process.c.o'. [437/3186] Compiling C object 'lib/76b5a35@@rte_vhost at sta/vhost_vhost_crypto.c.o'. [438/3186] Compiling C object 'lib/76b5a35@@rte_vhost at sta/vhost_virtio_net.c.o'. ninja: build stopped: subcommand failed. ##[error]Process completed with exit code 1. [End job log] "ubuntu-22.04-gcc-static-i386" at step Build and test
Re: [PATCH v4 2/2] ip_frag: updated name for IP frag define
On Mon, 8 Jan 2024 11:36:14 + Euan Bourke wrote: > diff --git a/config/rte_config.h b/config/rte_config.h > index da265d7dd2..e2fa2a58fa 100644 > --- a/config/rte_config.h > +++ b/config/rte_config.h > @@ -85,7 +85,7 @@ > #define RTE_RAWDEV_MAX_DEVS 64 > > /* ip_fragmentation defines */ > -#define RTE_LIBRTE_IP_FRAG_MAX_FRAG 8 > +#define RTE_IP_FRAG_MAX_FRAG 8 > // RTE_LIBRTE_IP_FRAG_TBL_STAT is not set > Any change to a visible define should be documented as an API change in the release notes. Also if changing the name for MAX_FRAG shouldn't the name for the statistics be changed as well as in: RTE_IP_FRAG_TBL_STAT?
RE: [PATCH v7 1/7] eal: add static per-lcore memory allocation facility
> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > Sent: Wednesday, 18 September 2024 10.26 > > Introduce DPDK per-lcore id variables, or lcore variables for short. > > An lcore variable has one value for every current and future lcore > id-equipped thread. > > The primary use case is for statically allocating > small, frequently-accessed data structures, for which one instance > should exist for each lcore. > > Lcore variables are similar to thread-local storage (TLS, e.g., C11 > _Thread_local), but decoupling the values' life time with that of the > threads. > > Lcore variables are also similar in terms of functionality provided by > FreeBSD kernel's DPCPU_*() family of macros and the associated > build-time machinery. DPCPU uses linker scripts, which effectively > prevents the reuse of its, otherwise seemingly viable, approach. > > The currently-prevailing way to solve the same problem as lcore > variables is to keep a module's per-lcore data as RTE_MAX_LCORE-sized > array of cache-aligned, RTE_CACHE_GUARDed structs. The benefit of > lcore variables over this approach is that data related to the same > lcore now is close (spatially, in memory), rather than data used by > the same module, which in turn avoid excessive use of padding, > polluting caches with unused data. > > Signed-off-by: Mattias Rönnblom > Acked-by: Morten Brørup > --- /dev/null > +++ b/lib/eal/common/eal_common_lcore_var.c > @@ -0,0 +1,79 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright(c) 2024 Ericsson AB > + */ > + > +#include > +#include > + > +#ifdef RTE_EXEC_ENV_WINDOWS > +#include > +#endif From what I can read on the internet, max_align_t is missing in stddef.h in MSVC [1], so try adding this to fix the Windows CI compilation failure: #ifdef RTE_TOOLCHAIN_MSVC #include #endif [1]: https://learn.microsoft.com/en-ie/answers/questions/1726147/why-max-align-t-not-defined-in-stddef-h-in-windows
Re: [RFC] app/testpmd: use RSS conf from software when configuring DCB
On Wed, 12 Apr 2023 17:52:39 +0800
Min Zhou wrote:
> In the testpmd command, we have to stop the port firstly before configuring
> the DCB. However, some PMDs may execute a hardware reset during the port
> stop, such as ixgbe. Some kind of reset operations of PMD could clear the
> configurations of RSS in the hardware register. This would cause the loss
> of RSS configurations that were set during the testpmd initialization. As
> a result, I find that I cannot enable RSS and DCB at the same time in the
> testpmd command when using Intel 82599 NIC.
>
> Although this patch can solve the problem I encountered, is there any risk
> of using rss conf from software instead of reading from the hardware
> register when configuring DCB?
>
> Signed-off-by: Min Zhou
> ---
> app/test-pmd/testpmd.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 5cb6f92523..3c382267b8 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -4247,14 +4247,12 @@ const uint16_t vlan_tags[] = {
> };
>
> static int
> -get_eth_dcb_conf(portid_t pid, struct rte_eth_conf *eth_conf,
> +get_eth_dcb_conf(portid_t pid __rte_unused, struct rte_eth_conf *eth_conf,
>enum dcb_mode_enable dcb_mode,
>enum rte_eth_nb_tcs num_tcs,
>uint8_t pfc_en)
> {
> uint8_t i;
> - int32_t rc;
> - struct rte_eth_rss_conf rss_conf;
>
Sorry for the late review, but almost uses DCB and fewer still with DPDK;
so not surprised that there would be issues like this.
If you change an internal function like get_eth_dcb_conf to remove parameters
then do not mark those parameters as unused, instead remove them from the
function
and the caller. Plus the function now always returns 0 so it can be reset as
void.
first place.
Suggest the following (untested):
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index b1401136e4..5eaac752c6 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -4291,15 +4291,11 @@ const uint16_t vlan_tags[] = {
24, 25, 26, 27, 28, 29, 30, 31
};
-static int
-get_eth_dcb_conf(portid_t pid, struct rte_eth_conf *eth_conf,
-enum dcb_mode_enable dcb_mode,
-enum rte_eth_nb_tcs num_tcs,
-uint8_t pfc_en)
+static void
+get_eth_dcb_conf(struct rte_eth_conf *eth_conf, enum dcb_mode_enable dcb_mode,
+enum rte_eth_nb_tcs num_tcs, uint8_t pfc_en)
{
uint8_t i;
- int32_t rc;
- struct rte_eth_rss_conf rss_conf;
/*
* Builds up the correct configuration for dcb+vt based on the vlan
tags array
@@ -4341,12 +4337,6 @@ get_eth_dcb_conf(portid_t pid, struct rte_eth_conf
*eth_conf,
struct rte_eth_dcb_tx_conf *tx_conf =
ð_conf->tx_adv_conf.dcb_tx_conf;
- memset(&rss_conf, 0, sizeof(struct rte_eth_rss_conf));
-
- rc = rte_eth_dev_rss_hash_conf_get(pid, &rss_conf);
- if (rc != 0)
- return rc;
-
rx_conf->nb_tcs = num_tcs;
tx_conf->nb_tcs = num_tcs;
@@ -4358,7 +4348,6 @@ get_eth_dcb_conf(portid_t pid, struct rte_eth_conf
*eth_conf,
eth_conf->rxmode.mq_mode =
(enum rte_eth_rx_mq_mode)
(rx_mq_mode & RTE_ETH_MQ_RX_DCB_RSS);
- eth_conf->rx_adv_conf.rss_conf = rss_conf;
eth_conf->txmode.mq_mode = RTE_ETH_MQ_TX_DCB;
}
@@ -4367,8 +4356,6 @@ get_eth_dcb_conf(portid_t pid, struct rte_eth_conf
*eth_conf,
RTE_ETH_DCB_PG_SUPPORT |
RTE_ETH_DCB_PFC_SUPPORT;
else
eth_conf->dcb_capability_en = RTE_ETH_DCB_PG_SUPPORT;
-
- return 0;
}
int
@@ -4391,10 +4378,9 @@ init_port_dcb_config(portid_t pid,
/* retain the original device configuration. */
memcpy(&port_conf, &rte_port->dev_conf, sizeof(struct rte_eth_conf));
- /*set configuration of DCB in vt mode and DCB in non-vt mode*/
- retval = get_eth_dcb_conf(pid, &port_conf, dcb_mode, num_tcs, pfc_en);
- if (retval < 0)
- return retval;
+ /* set configuration of DCB in vt mode and DCB in non-vt mode */
+ get_eth_dcb_conf(&port_conf, dcb_mode, num_tcs, pfc_en);
+
port_conf.rxmode.offloads |= RTE_ETH_RX_OFFLOAD_VLAN_FILTER;
/* remove RSS HASH offload for DCB in vt mode */
if (port_conf.rxmode.mq_mode == RTE_ETH_MQ_RX_VMDQ_DCB) {
Re: [PATCH v6 2/2] dts: mac filter test suite refactored for new dts
Thanks Nick this looks (almost) ready to be applied to next-dts. Other than
a little disconnect between your series and Dean's Patch-145500 ("dts: add
VLAN methods to testpmd shell") series which I will flag below, I think
this looks good.
On Tue, Oct 8, 2024 at 4:45 PM Nicholas Pratte wrote:
> The mac address filter test suite, whose test cases are based on old
> DTS's test cases, has been refactored to interface with the new DTS
> framework.
>
> In porting over this test suite into the new framework, some
> adjustments were made, namely in the EAL and TestPMD parameter provided
> before executing the application. While the original test plan was
> referenced, by and large, only for the individual test cases, I'll leave
> the parameters the original test plan was asking for below for the sake
> of discussion:
>
> --burst=1 --rxpt=0 --rxht=0 --rxwt=0 --txpt=36 --txht=0 --txwt=0
> --txfreet=32 --rxfreet=64 --mbcache=250 --portmask=0x3
>
I think including the params was good for discussion, but should be dropped
for the final commit message which should be clean, and explain what the
commit is adding.
> +@func_test
> +def test_add_remove_mac_addresses(self) -> None:
> +"""Assess basic mac addressing filtering functionalities.
> +
> +This test case validates for proper behavior of mac address
> filtering with both
> +a port's default, burned-in mac address, as well as additional
> mac addresses
> +added to the PMD. Packets should either be received or not
> received depending on
> +the properties applied to the PMD at any given time.
> +
> +Test:
> +Start TestPMD with promiscuous mode.
>
Should this be "without?"
> +Send a packet with the port's default mac address. (Should
> receive)
> +Send a packet with fake mac address. (Should not receive)
> +Add fake mac address to the PMD's address pool.
> +Send a packet with the fake mac address to the PMD. (Should
> receive)
> +Remove the fake mac address from the PMD's address pool.
> +Send a packet with the fake mac address to the PMD. (Should
> not receive)
> +"""
> +with TestPmdShell(self.sut_node) as testpmd:
> +testpmd.set_promisc(0, on=False)
>
The parameter is no longer named "on," it is named "enable" in Dean's vlan
methods series which you listed a dependency on. So unless I'm
misunderstanding, there is a disconnect between your series. I changed the
param to enable and then the testsuite runs.
Please make sure you do a test run before you submit a new version, even if
the changes seem trivial. :)
>
> +Test:
> +Start TestPMD with promiscuous mode.
>
same as above
> +Add a fake multicast address to the PMD's multicast address
> pool.
> +Send a packet with the fake multicast address to the PMD.
> (Should receive)
> +Set vlan filtering on the PMD, and add vlan ID to the PMD.
> +Send a packet with the fake multicast address and vlan ID to
> the PMD. (Should receive)
> +Send a packet with the fake multicast address and a different
> vlan ID to the PMD.
> +(Should not receive)
> +Remove the vlan tag from the PMD, and turn vlan filtering off
> on the PMD.
> +Send a packet with the fake multicast address and no vlan tag
> to the PMD.
> +(Should receive)
> +Remove the fake multicast address from the PMDs multicast
> address filter.
> +Send a packet with the fake multicast address to the PMD.
> (Should not receive)
> +"""
> +with TestPmdShell(self.sut_node) as testpmd:
> +testpmd.start()
> +testpmd.set_promisc(0, on=False)
>
same as above.
>
> --
> 2.44.0
>
>
Thanks looks good overall.
Reviewed-by: Patrick Robb
RE: [PATCH] examples/l2fwd-macsec: enable extended packet number
> -Original Message- > From: Akhil Goyal > Sent: Monday, September 16, 2024 4:57 PM > To: dev@dpdk.org > Cc: tho...@monjalon.net; david.march...@redhat.com; Vamsi Krishna > Attunuru ; Akhil Goyal > Subject: [PATCH] examples/l2fwd-macsec: enable extended packet number > > Enabled the extended packet number(XPN) case so that > traffic runs for longer duration without raising interrupt > for PN threshold as the application currently does not handle > rekeying. > > Signed-off-by: Akhil Goyal Applied to dpdk-next-crypto
RE: [PATCH v2] examples/ipsec-secgw: fix dequeue count from cryptodev
> > Subject: [PATCH v2] examples/ipsec-secgw: fix dequeue count from cryptodev
> >
> > Setting dequeue packet count to max of MAX_PKT_BURST
> > size instead of MAX_PKTS.
> >
> > Dequeue from cryptodev is called with MAX_PKTS but
> > routing functions allocate hop/dst_ip arrays of
> > size MAX_PKT_BURST. This can corrupt stack causing
> > stack smashing error when more than MAX_PKT_BURST
> > packets are returned from cryptodev.
> >
> > Fixes: a2b445b810ac ("examples/ipsec-secgw: allow larger burst size for
> > vectors")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Tejasree Kondoj
> Acked-by: Akhil Goyal
Applied to dpdk-next-crypto
Thanks.
RE: [PATCH v2 06/10] baseband/acc: remove soft output bypass
Hi Maxime,
There is no formal support for VRB2 yet, this is ongoing and we will formally
enable this only in DPDK 24.11.
So we don’t believe this commit below is truly a `fix` required to be applied
on stable branch.
Ie. DPDK 23.11 will not support VRB2 anyway.
Still Hernan will put the fix tag that you requested in the v3 for now, but
feel free to remove that tag if you agree this is actually not required.
Up to you, best probably best to only apply true fixes on LTS release.
Thanks
Nic
> -Original Message-
> From: Maxime Coquelin
> Sent: Tuesday, October 8, 2024 1:00 AM
> To: Vargas, Hernan ; dev@dpdk.org;
> gak...@marvell.com; t...@redhat.com
> Cc: Chautru, Nicolas ; Zhang, Qi Z
>
> Subject: Re: [PATCH v2 06/10] baseband/acc: remove soft output bypass
>
>
>
> On 10/3/24 22:49, Hernan Vargas wrote:
> > Removing soft output bypass capability due to device limitations.
>
> It should be specified this is for VRB2 device variant.
>
> And this should be backported, so pass Fixes tag and cc stable as it was
> introduced in v23.11 LTS.
>
> Fixes: b49fe052f9cd ("baseband/acc: add FEC capabilities for VRB2 variant")
> Cc: sta...@dpdk.org
>
> Thanks,
> Maxime
>
> >
> > Signed-off-by: Hernan Vargas
> > ---
> > drivers/baseband/acc/rte_vrb_pmd.c | 7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
> > b/drivers/baseband/acc/rte_vrb_pmd.c
> > index 26335d55ba3b..88201d11de88 100644
> > --- a/drivers/baseband/acc/rte_vrb_pmd.c
> > +++ b/drivers/baseband/acc/rte_vrb_pmd.c
> > @@ -1359,7 +1359,6 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct
> rte_bbdev_driver_info *dev_info)
> >
> RTE_BBDEV_LDPC_HARQ_4BIT_COMPRESSION |
> > RTE_BBDEV_LDPC_LLR_COMPRESSION |
> > RTE_BBDEV_LDPC_SOFT_OUT_ENABLE |
> > - RTE_BBDEV_LDPC_SOFT_OUT_RM_BYPASS |
> >
> RTE_BBDEV_LDPC_SOFT_OUT_DEINTERLEAVER_BYPASS |
> > RTE_BBDEV_LDPC_DEC_INTERRUPTS,
> > .llr_size = 8,
> > @@ -1736,18 +1735,18 @@ vrb_fcw_ld_fill(struct rte_bbdev_dec_op *op,
> struct acc_fcw_ld *fcw,
> > fcw->so_en = check_bit(op->ldpc_dec.op_flags,
> RTE_BBDEV_LDPC_SOFT_OUT_ENABLE);
> > fcw->so_bypass_intlv = check_bit(op->ldpc_dec.op_flags,
> >
> RTE_BBDEV_LDPC_SOFT_OUT_DEINTERLEAVER_BYPASS);
> > - fcw->so_bypass_rm = check_bit(op->ldpc_dec.op_flags,
> > - RTE_BBDEV_LDPC_SOFT_OUT_RM_BYPASS);
> > + fcw->so_bypass_rm = 0;
> > fcw->minsum_offset = 1;
> > fcw->dec_llrclip = 2;
> > }
> >
> > /*
> > -* These are all implicitly set
> > +* These are all implicitly set:
> > * fcw->synd_post = 0;
> > * fcw->dec_convllr = 0;
> > * fcw->hcout_convllr = 0;
> > * fcw->hcout_size1 = 0;
> > +* fcw->so_it = 0;
> > * fcw->hcout_offset = 0;
> > * fcw->negstop_th = 0;
> > * fcw->negstop_it = 0;
Re: [RFC PATCH] build: automatically report minimum meson version
On Wed, 9 Oct 2024 16:24:01 +0100 Bruce Richardson wrote: > Add a script to buildtools to report the minimum meson version given in > our meson.build file. Then use this script in two ways: > > 1. in the .ci/linux-setup.sh script, use the auto-determined minimum >version to set up the CI, rather than hard-coding it. > 2. in meson.build call the script to report the version. This serves as >a sanity check to ensure that any changes to meson.build file do not >break the script. > > Signed-off-by: Bruce Richardson Make sense, kind of annoying that it requires so many lines to do this but very understandable. Acked-by: Stephen Hemminger
RE: [PATCH v2 1/2] fib: implement RCU rule reclamation
The check for NULL is not necessary before calling rte_rcu_qsbr_dq_delete.
Similar to other free routines, an error will not occur when the dq pointer is
NULL.
However, it will give a debug log statement to indicate an invalid parameter
and return 0 to indicate success.
-Original Message-
From: Stephen Hemminger
Sent: Tuesday, October 8, 2024 1:18 PM
To: Vladimir Medvedkin
Cc: dev@dpdk.org; rja...@redhat.com; Ruifeng Wang ;
Honnappa Nagarahalli ; david.march...@redhat.com
Subject: Re: [PATCH v2 1/2] fib: implement RCU rule reclamation
On Tue, 8 Oct 2024 17:55:23 +
Vladimir Medvedkin wrote:
> @@ -569,7 +600,60 @@ dir24_8_free(void *p) {
> struct dir24_8_tbl *dp = (struct dir24_8_tbl *)p;
>
> + if (dp->dq != NULL)
> + rte_rcu_qsbr_dq_delete(dp->dq);
> +
Side note:
rte_rcu_qsbr_dq_delete should be changed to accept NULL as nop.
Like all the other free routines
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
Re: [PATCH v2] doc: reword sample app guides
On Sun, 6 Oct 2024 16:45:17 -0700 Nandini Persad wrote: > I have reviewed these sections for grammar/clarity > and made small modifications to the formatting of sections > to adhere to a template which will create uniformality > in the sample application user guides overall. > > Signed-off-by: Nandini Persad A recent patch reorganized many of these files therefore the patch needs to be redone. For example switch_representation.rst has moved to doc/guides/prog_guide/ethdev/switch_representation.rst
RE: [PATCH v2 2/2] cryptodev: move RSA padding information into xform
Acked-by: Arek Kusztal > -Original Message- > From: Akhil Goyal > Sent: Wednesday, October 9, 2024 5:23 PM > To: Gowrishankar Muthukrishnan ; > dev@dpdk.org; Kusztal, ArkadiuszX ; Fan Zhang > ; Anoob Joseph ; Ankur > Dwivedi ; Tejasree Kondoj ; > Ji, Kai ; Dooley, Brian > Cc: Richardson, Bruce ; Jerin Jacob > ; jack.bond-pres...@foss.arm.com; Marchand, David > ; hemant.agra...@nxp.com; De Lara Guarch, > Pablo ; Trahe, Fiona > ; Doherty, Declan ; > ma...@nvidia.com; ruifeng.w...@arm.com; Gujjar, Abhinandan S > ; maxime.coque...@redhat.com; > chen...@nvidia.com; sunilprakashrao.uttar...@amd.com; > andrew.bo...@amd.com; ajit.khapa...@broadcom.com; > raveendra.padasal...@broadcom.com; vikas.gu...@broadcom.com; > zhangfei@linaro.org; g.si...@nxp.com; jianjay.z...@huawei.com; Daly, > Lee > Subject: RE: [PATCH v2 2/2] cryptodev: move RSA padding information into > xform > > Hi Arek > Any objections on this patch? > > > Subject: [PATCH v2 2/2] cryptodev: move RSA padding information into > > xform > > > > RSA padding information could be a xform entity rather than part of > > crypto op, as it seems associated with hashing algorithm used for the > > entire crypto session, where this algorithm is used in message digest > > itself. Even in virtIO standard spec, this info is associated in the > > asymmetric session creation. Hence, moving this info from crypto op > > into xform structure. > > > > Signed-off-by: Gowrishankar Muthukrishnan
Re: [PATCH 0/5] Increase minimum meson version
Hi Min Zhou, I think it makes sense for you to set your meson version to the minimum version supported for DPDK (so, .57 now I suppose) instead of .63. The principle that David described above regarding LTS is also true for main. So, for the main and next-* branch testing that Loongson lab does, we want our CI testing to verify that no change relying on post .57 meson features get merged into main. On Tue, Oct 8, 2024 at 9:07 PM zhoumin wrote: > Hi David, > > On Tues, Oct 8, 2024 at 8:28AM, David Marchand wrote: > > Hello CI guys, > > > > On Fri, Sep 20, 2024 at 2:57 PM Bruce Richardson > > wrote: > >> This patchset proposed increasing the minimum meson version to 0.57 > >> and makes changes to update our build files appropriately for that > >> change: replacing deprecated functions, removing unnecessary version > >> checks and taking advantage of some new capabilities. > >> > >> Why 0.57? No one particular reason; it's mainly a conservative version > >> bump that doesn't have many impacts, but still gives us the minimum > >> updates we need to replace the deprecated get_cross_properties fn > >> and have a few extra features guaranteed available. > >> > >> Bruce Richardson (5): > >>build: increase minimum meson version to 0.57 > >>build: remove version check on compiler links function > >>build: remove unnecessary version checks > >>build: use version file support from meson > >>build: replace deprecated meson function > >> > >> .ci/linux-setup.sh| 2 +- > >> config/arm/meson.build| 4 ++-- > >> config/meson.build| 8 > >> config/riscv/meson.build | 4 ++-- > >> doc/api/meson.build | 2 +- > >> doc/guides/linux_gsg/sys_reqs.rst | 2 +- > >> doc/guides/prog_guide/build-sdk-meson.rst | 2 +- > >> drivers/common/qat/meson.build| 2 +- > >> drivers/crypto/ipsec_mb/meson.build | 2 +- > >> drivers/event/cnxk/meson.build| 2 +- > >> drivers/meson.build | 7 ++- > >> drivers/net/cnxk/meson.build | 2 +- > >> lib/meson.build | 6 -- > >> meson.build | 7 ++- > >> 14 files changed, 20 insertions(+), 32 deletions(-) > > This series can't be merged until the (UNH and LoongArch) CI are ready > > for such a change. > > > > TL;DR: the meson minimum version is being changed from 0.53.2 to 0.57 > > in the current release. > > > > @UNH @Min Zhou > > How long would it take for all CI to be ready for this change? > It's OK for Loongson lab. The meson version for DPDK CI in Loongson lab > is 0.63.0. > > Important note: if relevant to your CI, testing against LTS branches > > must still be done with the 0.53.2 version, so no change relying on > > post 0.53.2 meson feature gets backported. > > > > > >
[PATCH 2/5] net/ice: improve Tx scheduler graph output
The function to dump the TX scheduler topology only adds to the chart
nodes connected to TX queues or for the flow director VSI. Change the
function to work recursively from the root node and thereby include all
scheduler nodes, whether in use or not, in the dump.
Also, improve the output of the Tx scheduler graphing function:
* Add VSI details to each node in graph
* When number of children is >16, skip middle nodes to reduce size of
the graph, otherwise dot output is unviewable for large hierarchies
* For VSIs other than zero, use dot's clustering method to put those
VSIs into subgraphs with borders
* For leaf nodes, display queue numbers for the any nodes assigned to
ethdev NIC Tx queues
Signed-off-by: Bruce Richardson
---
drivers/net/ice/ice_diagnose.c | 196 -
1 file changed, 69 insertions(+), 127 deletions(-)
diff --git a/drivers/net/ice/ice_diagnose.c b/drivers/net/ice/ice_diagnose.c
index c357554707..623d84e37d 100644
--- a/drivers/net/ice/ice_diagnose.c
+++ b/drivers/net/ice/ice_diagnose.c
@@ -545,29 +545,15 @@ static void print_rl_profile(struct
ice_aqc_rl_profile_elem *prof,
fprintf(stream, "\t\t\t\t\t\n");
}
-static
-void print_elem_type(FILE *stream, u8 type)
+static const char *
+get_elem_type(u8 type)
{
- switch (type) {
- case 1:
- fprintf(stream, "root");
- break;
- case 2:
- fprintf(stream, "tc");
- break;
- case 3:
- fprintf(stream, "se_generic");
- break;
- case 4:
- fprintf(stream, "entry_point");
- break;
- case 5:
- fprintf(stream, "leaf");
- break;
- default:
- fprintf(stream, "%d", type);
- break;
- }
+ static const char * const ice_sched_node_types[] = {
+ "Undefined", "Root", "TC", "SE Generic", "SW Entry",
"Leaf"
+ };
+ if (type < RTE_DIM(ice_sched_node_types))
+ return ice_sched_node_types[type];
+ return "*UNKNOWN*";
}
static
@@ -602,7 +588,9 @@ void print_priority_mode(FILE *stream, bool flag)
}
static
-void print_node(struct ice_aqc_txsched_elem_data *data,
+void print_node(struct ice_sched_node *node,
+ struct rte_eth_dev_data *ethdata,
+ struct ice_aqc_txsched_elem_data *data,
struct ice_aqc_rl_profile_elem *cir_prof,
struct ice_aqc_rl_profile_elem *eir_prof,
struct ice_aqc_rl_profile_elem *shared_prof,
@@ -613,17 +601,19 @@ void print_node(struct ice_aqc_txsched_elem_data *data,
fprintf(stream, "\t\t\t\n");
- fprintf(stream, "\t\t\t\t\n");
- fprintf(stream, "\t\t\t\t\t teid \n");
- fprintf(stream, "\t\t\t\t\t %d \n", data->node_teid);
- fprintf(stream, "\t\t\t\t\n");
-
- fprintf(stream, "\t\t\t\t\n");
- fprintf(stream, "\t\t\t\t\t type \n");
- fprintf(stream, "\t\t\t\t\t");
- print_elem_type(stream, data->data.elem_type);
- fprintf(stream, "\n");
- fprintf(stream, "\t\t\t\t\n");
+ fprintf(stream, "\t\t\t\tteid%d\n",
data->node_teid);
+ fprintf(stream, "\t\t\t\ttype%s\n",
+ get_elem_type(data->data.elem_type));
+ fprintf(stream, "\t\t\t\tVSI%u\n",
node->vsi_handle);
+ if (data->data.elem_type == ICE_AQC_ELEM_TYPE_LEAF) {
+ for (uint16_t i = 0; i < ethdata->nb_tx_queues; i++) {
+ struct ice_tx_queue *q = ethdata->tx_queues[i];
+ if (q->q_teid == data->node_teid) {
+ fprintf(stream,
"\t\t\t\tTXQ%u\n", i);
+ break;
+ }
+ }
+ }
if (!detail)
goto brief;
@@ -705,8 +695,6 @@ void print_node(struct ice_aqc_txsched_elem_data *data,
fprintf(stream, "\t\tshape=plain\n");
fprintf(stream, "\t]\n");
- if (data->parent_teid != 0x)
- fprintf(stream, "\tNODE_%d -> NODE_%d\n", data->parent_teid,
data->node_teid);
}
static
@@ -731,112 +719,92 @@ int query_rl_profile(struct ice_hw *hw,
return 0;
}
-static
-int query_node(struct ice_hw *hw, uint32_t child, uint32_t *parent,
- uint8_t level, bool detail, FILE *stream)
+static int
+query_node(struct ice_hw *hw, struct rte_eth_dev_data *ethdata,
+ struct ice_sched_node *node, bool detail, FILE *stream)
{
- struct ice_aqc_txsched_elem_data data;
+ struct ice_aqc_txsched_elem_data *data = &node->info;
struct ice_aqc_rl_profile_elem cir_prof;
struct ice_aqc_rl_profile_elem eir_prof;
struct ice_aqc_rl_profile_elem shared_prof;
struct ice_aqc_rl_profile_elem *cp = NULL;
struct ice_aqc_rl_profile_elem *ep = NULL;
struct ice_aqc_rl_profile_elem *sp = NULL;
- int status, ret;
-
- stat
[PATCH 5/5] net/ice: limit the number of queues to sched capabilities
Rather than assuming that each VSI can hold up to 256 queue pairs,
or the reported device limit, query the available nodes in the scheduler
tree to check that we are not overflowing the limit for number of
child scheduling nodes at each level. Do this by multiplying
max_children for each level beyond the VSI and using that as an
additional cap on the number of queues.
Signed-off-by: Bruce Richardson
---
drivers/net/ice/ice_ethdev.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index ea1ed4fb68..2d5e8b27d7 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -914,7 +914,7 @@ ice_vsi_config_default_rss(struct ice_aqc_vsi_props *info)
}
static int
-ice_vsi_config_tc_queue_mapping(struct ice_vsi *vsi,
+ice_vsi_config_tc_queue_mapping(struct ice_hw *hw, struct ice_vsi *vsi,
struct ice_aqc_vsi_props *info,
uint8_t enabled_tcmap)
{
@@ -930,13 +930,28 @@ ice_vsi_config_tc_queue_mapping(struct ice_vsi *vsi,
}
/* vector 0 is reserved and 1 vector for ctrl vsi */
- if (vsi->adapter->hw.func_caps.common_cap.num_msix_vectors < 2)
+ if (vsi->adapter->hw.func_caps.common_cap.num_msix_vectors < 2) {
vsi->nb_qps = 0;
- else
+ } else {
vsi->nb_qps = RTE_MIN
((uint16_t)vsi->adapter->hw.func_caps.common_cap.num_msix_vectors - 2,
RTE_MIN(vsi->nb_qps, ICE_MAX_Q_PER_TC));
+ /* cap max QPs to what the HW reports as num-children for each
layer.
+* Multiply num_children for each layer from the entry_point
layer to
+* the qgroup, or second-last layer.
+* Avoid any potential overflow by using uint32_t type and
breaking loop
+* once we have a number greater than the already configured
max.
+*/
+ uint32_t max_sched_vsi_nodes = 1;
+ for (uint8_t i = hw->sw_entry_point_layer; i <
hw->num_tx_sched_layers - 1; i++) {
+ max_sched_vsi_nodes *= hw->max_children[i];
+ if (max_sched_vsi_nodes >= vsi->nb_qps)
+ break;
+ }
+ vsi->nb_qps = RTE_MIN(vsi->nb_qps, max_sched_vsi_nodes);
+ }
+
/* nb_qps(hex) -> fls */
/* -> 0 */
/* 0001 -> 0 */
@@ -1708,7 +1723,7 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
rte_cpu_to_le_16(hw->func_caps.fd_fltr_best_effort);
/* Enable VLAN/UP trip */
- ret = ice_vsi_config_tc_queue_mapping(vsi,
+ ret = ice_vsi_config_tc_queue_mapping(hw, vsi,
&vsi_ctx.info,
ICE_DEFAULT_TCMAP);
if (ret) {
@@ -1732,7 +1747,7 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
vsi_ctx.info.fd_options = rte_cpu_to_le_16(cfg);
vsi_ctx.info.sw_id = hw->port_info->sw_id;
vsi_ctx.info.sw_flags2 = ICE_AQ_VSI_SW_FLAG_LAN_ENA;
- ret = ice_vsi_config_tc_queue_mapping(vsi,
+ ret = ice_vsi_config_tc_queue_mapping(hw, vsi,
&vsi_ctx.info,
ICE_DEFAULT_TCMAP);
if (ret) {
--
2.43.0
[PATCH 1/5] net/ice: detect stopping a flow-director queue twice
If the flow-director queue is stopped at some point during the running
of an application, the shutdown procedure for the port issues an error
as it tries to stop the queue a second time, and fails to do so. We can
eliminate this error by setting the tail-register pointer to NULL on
stop, and checking for that condition in subsequent stop calls. Since
the register pointer is set on start, any restarting of the queue will
allow a stop call to progress as normal.
Signed-off-by: Bruce Richardson
---
drivers/net/ice/ice_rxtx.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index acd7539b5e..267c1b4a79 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -1139,6 +1139,10 @@ ice_fdir_tx_queue_stop(struct rte_eth_dev *dev, uint16_t
tx_queue_id)
tx_queue_id);
return -EINVAL;
}
+ if (txq->qtx_tail == NULL) {
+ PMD_DRV_LOG(INFO, "TX queue %u not started", tx_queue_id);
+ return 0;
+ }
vsi = txq->vsi;
q_ids[0] = txq->reg_idx;
@@ -1153,6 +1157,7 @@ ice_fdir_tx_queue_stop(struct rte_eth_dev *dev, uint16_t
tx_queue_id)
}
txq->tx_rel_mbufs(txq);
+ txq->qtx_tail = NULL;
return 0;
}
--
2.43.0
RE: [EXTERNAL] [PATCH v5 3/4] crypto/qat: add sm2 encryption/decryption function
> This commit adds SM2 elliptic curve based asymmetric
> encryption and decryption to the Intel QuickAssist
> Technology PMD.
>
> Signed-off-by: Arkadiusz Kusztal
> ---
> doc/guides/cryptodevs/features/qat.ini | 1 +
> doc/guides/rel_notes/release_24_11.rst | 4 +
> drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h | 3 +
> drivers/common/qat/qat_adf/qat_pke.h| 20
> drivers/crypto/qat/qat_asym.c | 140
> +++-
> 5 files changed, 162 insertions(+), 6 deletions(-)
>
RTE_CRYPTO_SM2_PARTIAL is not set in the PMD as op_capa.
> diff --git a/doc/guides/cryptodevs/features/qat.ini
> b/doc/guides/cryptodevs/features/qat.ini
> index f41d29158f..219dd1e011 100644
> --- a/doc/guides/cryptodevs/features/qat.ini
> +++ b/doc/guides/cryptodevs/features/qat.ini
> @@ -71,6 +71,7 @@ ZUC EIA3 = Y
> AES CMAC (128) = Y
> SM3 = Y
> SM3 HMAC = Y
> +SM2 = Y
>
> ;
> ; Supported AEAD algorithms of the 'qat' crypto driver.
> diff --git a/doc/guides/rel_notes/release_24_11.rst
> b/doc/guides/rel_notes/release_24_11.rst
> index e0a9aa55a1..e56824310b 100644
> --- a/doc/guides/rel_notes/release_24_11.rst
> +++ b/doc/guides/rel_notes/release_24_11.rst
> @@ -67,6 +67,10 @@ New Features
>
>The new statistics are useful for debugging and profiling.
>
> +* **Updated the QuickAssist Technology (QAT) Crypto PMD.**
> +
> + * Added SM2 encryption and decryption algorithms.
> +
>
> Removed Items
> -
> diff --git a/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
> b/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
> index 630c6e1a9b..aa49612ca1 100644
> --- a/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
> +++ b/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
> @@ -1542,6 +1542,9 @@ icp_qat_fw_mmp_ecdsa_verify_gfp_521_input::in in
> @endlink
> * @li no output parameters
> */
>
> +#define PKE_ECSM2_ENCRYPTION 0x25221720
> +#define PKE_ECSM2_DECRYPTION 0x201716e6
> +
> #define PKE_LIVENESS 0x0001
> /**< Functionality ID for PKE_LIVENESS
> * @li 0 input parameter(s)
> diff --git a/drivers/common/qat/qat_adf/qat_pke.h
> b/drivers/common/qat/qat_adf/qat_pke.h
> index f88932a275..ac051e965d 100644
> --- a/drivers/common/qat/qat_adf/qat_pke.h
> +++ b/drivers/common/qat/qat_adf/qat_pke.h
> @@ -334,4 +334,24 @@ get_sm2_ecdsa_verify_function(void)
> return qat_function;
> }
>
> +static struct qat_asym_function
> +get_sm2_encryption_function(void)
> +{
> + struct qat_asym_function qat_function = {
> + PKE_ECSM2_ENCRYPTION, 32
> + };
> +
> + return qat_function;
> +}
> +
> +static struct qat_asym_function
> +get_sm2_decryption_function(void)
> +{
> + struct qat_asym_function qat_function = {
> + PKE_ECSM2_DECRYPTION, 32
> + };
> +
> + return qat_function;
> +}
> +
> #endif
> diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
> index e43884e69b..3ce48a1486 100644
> --- a/drivers/crypto/qat/qat_asym.c
> +++ b/drivers/crypto/qat/qat_asym.c
> @@ -932,6 +932,15 @@ sm2_ecdsa_sign_set_input(struct
> icp_qat_fw_pke_request *qat_req,
> qat_req->input_param_count = 3;
> qat_req->output_param_count = 2;
>
> + HEXDUMP("SM2 K test", asym_op->sm2.k.data,
> + cookie->alg_bytesize);
> + HEXDUMP("SM2 K", cookie->input_array[0],
> + cookie->alg_bytesize);
> + HEXDUMP("SM2 msg", cookie->input_array[1],
> + cookie->alg_bytesize);
> + HEXDUMP("SM2 pkey", cookie->input_array[2],
> + cookie->alg_bytesize);
> +
> return RTE_CRYPTO_OP_STATUS_SUCCESS;
> }
>
> @@ -983,6 +992,114 @@ sm2_ecdsa_sign_collect(struct rte_crypto_asym_op
> *asym_op,
> }
>
> static int
> +sm2_encryption_set_input(struct icp_qat_fw_pke_request *qat_req,
> + struct qat_asym_op_cookie *cookie,
> + const struct rte_crypto_asym_op *asym_op,
> + const struct rte_crypto_asym_xform *xform)
> +{
> + const struct qat_asym_function qat_function =
> + get_sm2_encryption_function();
> + const uint32_t qat_func_alignsize =
> + qat_function.bytesize;
> +
> + SET_PKE_LN(asym_op->sm2.k, qat_func_alignsize, 0);
> + SET_PKE_LN(xform->ec.q.x, qat_func_alignsize, 1);
> + SET_PKE_LN(xform->ec.q.y, qat_func_alignsize, 2);
> +
> + cookie->alg_bytesize = qat_function.bytesize;
> + cookie->qat_func_alignsize = qat_function.bytesize;
> + qat_req->pke_hdr.cd_pars.func_id = qat_function.func_id;
> + qat_req->input_param_count = 3;
> + qat_req->output_param_count = 4;
> +
> + HEXDUMP("SM2 K", cookie->input_array[0],
> + qat_func_alignsize);
> + HEXDUMP("SM2 Q.x", cookie->input_array[1],
> + qat_func_alignsize);
> + HEXDUMP("SM2 Q.y", cookie->input_array[2],
> + qat_func_alignsize);
> +
> + return RTE_CRYPTO_OP_STATUS_SUCCESS;
> +}
> +
> +static uint8_t
> +sm2_encryption_collect(struct rte_crypto_as
RE: [PATCH v7 3/7] eal: add lcore variable performance test
> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > Sent: Wednesday, 18 September 2024 10.26 A few corrections to a comment. Besides that, Acked-by: Morten Brørup > +/* > + * The potential performance benefit of lcore variables compared to > + * the use of statically sized, lcore id-indexed arrays are not are not -> is not > + * shorter latencies in a scenario with low cache pressure, but rather > + * fewer cache misses in a real-world scenario, with extensive cache > + * usage. These tests are a crude simulation of such, using dummy > + * modules, each wiht a small, per-lcore state. Note however that wiht -> with > + * these tests has very little non-lcore/thread local state, which is has -> have > + * unrealistic. > + */
RE: [EXTERNAL] [PATCH v5 2/4] cryptodev: add ec points to sm2 op
> In the case when PMD cannot support the full process of the SM2,
> but elliptic curve computation only, additional fields
> are needed to handle such a case.
>
> Points C1, kP therefore were added to the SM2 crypto operation struct.
>
> Signed-off-by: Arkadiusz Kusztal
> ---
> lib/cryptodev/rte_crypto_asym.h | 53 ++--
> -
> 1 file changed, 39 insertions(+), 14 deletions(-)
>
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 2af6a307f6..65b1a081b1 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -607,6 +607,8 @@ enum rte_crypto_sm2_op_capa {
> /**< Random number generator supported in SM2 ops. */
> RTE_CRYPTO_SM2_PH,
> /**< Prehash message before crypto op. */
> + RTE_CRYPTO_SM2_PARTIAL,
> + /**< Calculate elliptic curve points only. */
> };
>
> /**
> @@ -634,20 +636,43 @@ struct rte_crypto_sm2_op_param {
>* will be overwritten by the PMD with the decrypted length.
>*/
>
> - rte_crypto_param cipher;
> - /**<
> - * Pointer to input data
> - * - to be decrypted for SM2 private decrypt.
> - *
> - * Pointer to output data
> - * - for SM2 public encrypt.
> - * In this case the underlying array should have been allocated
> - * with enough memory to hold ciphertext output (at least X bytes
> - * for prime field curve of N bytes and for message M bytes,
> - * where X = (C1 || C2 || C3) and computed based on SM2 RFC as
> - * C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
> - * be overwritten by the PMD with the encrypted length.
> - */
> + union {
> + rte_crypto_param cipher;
> + /**<
> + * Pointer to input data
> + * - to be decrypted for SM2 private decrypt.
> + *
> + * Pointer to output data
> + * - for SM2 public encrypt.
> + * In this case the underlying array should have been allocated
> + * with enough memory to hold ciphertext output (at least X
> bytes
> + * for prime field curve of N bytes and for message M bytes,
> + * where X = (C1 || C2 || C3) and computed based on SM2 RFC
> as
> + * C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
> + * be overwritten by the PMD with the encrypted length.
> + */
> + struct {
> + struct rte_crypto_ec_point C1;
> + /**<
> + * This field is used only when PMD does not support the
> full
> + * process of the SM2 encryption/decryption, but the
> elliptic
> + * curve part only.
> + *
> + * In the case of encryption, it is an output - point
> C1 =
> (x1,y1).
> + * In the case of decryption, if is an input - point C1
> =
> (x1,y1)
> + *
> + */
> + struct rte_crypto_ec_point kP;
> + /**<
> + * This field is used only when PMD does not support the
> full
> + * process of the SM2 encryption/decryption, but the
> elliptic
> + * curve part only.
> + *
> + * It is an output in the encryption case, it is a point
> + * [k]P = (x2,y2)
> + */
Please add reference to RTE_CRYPTO_SM2_PARTIAL in the comments.
> + };
> + };
>
> rte_crypto_uint id;
> /**< The SM2 id used by signer and verifier. */
> --
> 2.13.6
RE: [PATCH v6 1/7] event/dlb2: include headers for vector and memory copy APIs
Acked-by: Morten Brørup
RE: [PATCH v6 2/7] net/octeon_ep: add missing vector API header include
Acked-by: Morten Brørup
RE: [PATCH v6 4/7] fib: add missing vector API header include
Acked-by: Morten Brørup
RE: [PATCH v6 3/7] distributor: add missing vector API header include
Acked-by: Morten Brørup
RE: [EXTERNAL] [v2] crypto/dpaa2_sec: rework debug code
Hi Gagan,
> Output debug information according to various modes.
>
> Signed-off-by: Jun Yang
> Signed-off-by: Gagandeep Singh
It seems the base patch was merged in main branch.
Can you rebase this patch on current top of tree?
> ---
> drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 72 +
> 1 file changed, 46 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
> b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
> index 2cdf9308f8..0c96ca0023 100644
> --- a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
> +++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
> @@ -65,6 +65,47 @@ enum dpaa2_sec_dump_levels {
> uint8_t cryptodev_driver_id;
> uint8_t dpaa2_sec_dp_dump = DPAA2_SEC_DP_ERR_DUMP;
>
> +static inline void
> +dpaa2_sec_dp_fd_dump(const struct qbman_fd *fd, uint16_t bpid,
> + struct rte_mbuf *mbuf, bool tx)
> +{
> +#if (RTE_LOG_DEBUG <= RTE_LOG_DP_LEVEL)
> + char debug_str[1024];
> + int offset;
> +
> + if (tx) {
> + offset = sprintf(debug_str,
> + "CIPHER SG: fdaddr =%" PRIx64 ", from %s pool ",
> + DPAA2_GET_FD_ADDR(fd),
> + bpid < MAX_BPID ? "SW" : "BMAN");
> + if (bpid < MAX_BPID) {
> + offset += sprintf(&debug_str[offset],
> + "bpid = %d ", bpid);
> + }
> + } else {
> + offset = sprintf(debug_str, "Mbuf %p from %s pool ",
> + mbuf, DPAA2_GET_FD_IVP(fd) ? "SW" :
> "BMAN");
> + if (!DPAA2_GET_FD_IVP(fd)) {
> + offset += sprintf(&debug_str[offset], "bpid = %d ",
> + DPAA2_GET_FD_BPID(fd));
> + }
> + }
> + offset += sprintf(&debug_str[offset],
> + "private size = %d ",
> + mbuf->pool->private_data_size);
> + offset += sprintf(&debug_str[offset],
> + "addr %p, fdaddr =%" PRIx64 ", off =%d, len =%d",
> + mbuf->buf_addr, DPAA2_GET_FD_ADDR(fd),
> + DPAA2_GET_FD_OFFSET(fd), DPAA2_GET_FD_LEN(fd));
> + DPAA2_SEC_DP_DEBUG("%s", debug_str);
> +#else
> + RTE_SET_USED(bpid);
> + RTE_SET_USED(tx);
> + RTE_SET_USED(mbuf);
> + RTE_SET_USED(fd);
> +#endif
> +}
> +
> static inline void
> free_fle(const struct qbman_fd *fd, struct dpaa2_sec_qp *qp)
> {
> @@ -1097,7 +1138,7 @@ build_auth_fd(dpaa2_sec_session *sess, struct
> rte_crypto_op *op,
>
> static int
> build_cipher_sg_fd(dpaa2_sec_session *sess, struct rte_crypto_op *op,
> - struct qbman_fd *fd, __rte_unused uint16_t bpid)
> + struct qbman_fd *fd, uint16_t bpid)
> {
> struct rte_crypto_sym_op *sym_op = op->sym;
> struct qbman_fle *ip_fle, *op_fle, *sge, *fle;
> @@ -1212,14 +1253,8 @@ build_cipher_sg_fd(dpaa2_sec_session *sess, struct
> rte_crypto_op *op,
> DPAA2_SET_FD_COMPOUND_FMT(fd);
> DPAA2_SET_FD_FLC(fd, DPAA2_VADDR_TO_IOVA(flc));
>
> - DPAA2_SEC_DP_DEBUG(
> - "CIPHER SG: fdaddr =%" PRIx64 " bpid =%d meta =%d"
> - " off =%d, len =%d",
> - DPAA2_GET_FD_ADDR(fd),
> - DPAA2_GET_FD_BPID(fd),
> - rte_dpaa2_bpid_info[bpid].meta_data_size,
> - DPAA2_GET_FD_OFFSET(fd),
> - DPAA2_GET_FD_LEN(fd));
> + dpaa2_sec_dp_fd_dump(fd, bpid, mbuf, true);
> +
> return 0;
> }
>
> @@ -1326,14 +1361,7 @@ build_cipher_fd(dpaa2_sec_session *sess, struct
> rte_crypto_op *op,
> DPAA2_SET_FLE_FIN(sge);
> DPAA2_SET_FLE_FIN(fle);
>
> - DPAA2_SEC_DP_DEBUG(
> - "CIPHER: fdaddr =%" PRIx64 " bpid =%d meta =%d"
> - " off =%d, len =%d",
> - DPAA2_GET_FD_ADDR(fd),
> - DPAA2_GET_FD_BPID(fd),
> - rte_dpaa2_bpid_info[bpid].meta_data_size,
> - DPAA2_GET_FD_OFFSET(fd),
> - DPAA2_GET_FD_LEN(fd));
> + dpaa2_sec_dp_fd_dump(fd, bpid, dst, true);
>
> return 0;
> }
> @@ -1604,15 +1632,7 @@ sec_fd_to_mbuf(const struct qbman_fd *fd, struct
> dpaa2_sec_qp *qp)
> dst->data_len = len;
> }
>
> - DPAA2_SEC_DP_DEBUG("mbuf %p BMAN buf addr %p,"
> - " fdaddr =%" PRIx64 " bpid =%d meta =%d off =%d, len =%d",
> - (void *)dst,
> - dst->buf_addr,
> - DPAA2_GET_FD_ADDR(fd),
> - DPAA2_GET_FD_BPID(fd),
> -
> rte_dpaa2_bpid_info[DPAA2_GET_FD_BPID(fd)].meta_data_size,
> - DPAA2_GET_FD_OFFSET(fd),
> - DPAA2_GET_FD_LEN(fd));
> + dpaa2_sec_dp_fd_dump(fd, 0, dst, false);
>
> /* free the fle memory */
> if (likely(rte_pktmbuf_is_contiguous(src))) {
> --
> 2.25.1
RE: [EXTERNAL] [PATCH v5 1/4] cryptodev: reorder structures in asym crypto header
> Asymmetric-crypto header has a simple structure that allows to > keep logically separate blocks together. Therefore, xforms, > ops, and generic structs may be appropriately ordered. > This patch moves sm2-op structs to be placed along other > algorithms-op structs. > > Signed-off-by: Arkadiusz Kusztal > --- Acked-by: Akhil Goyal This patch is applied to dpdk-next-crypto Please send the next version for rest of the patches in the series.
RE: [PATCH v6 6/7] ci: test compiler memcpy
> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > Sent: Friday, 20 September 2024 12.27 > +if [ "$CCMEMCPY" = "true" ]; then > + OPTS="$OPTS -Duse_cc_memcpy=true" > +else > + OPTS="$OPTS -Duse_cc_memcpy=true" > +fi With the bug (only testing true) found by David fixed, Acked-by: Morten Brørup
Re: [v5 15/15] bus/dpaa: add port bmi stats
On Tue, 8 Oct 2024 16:28:10 +0530 Gagandeep Singh wrote: > From: Hemant Agrawal > > Add BMI statistics and fixing the existing extended > statistics > > Signed-off-by: Hemant Agrawal > Signed-off-by: Gagandeep Singh > --- This patch is failing build, Fedora has a more recent Gcc with more checking 20 line log output for Fedora 40 (dpdk_unit_test): | ^~~ In function 'rte_mov15_or_less', inlined from 'rte_memcpy_aligned' at ../lib/eal/x86/include/rte_memcpy.h:706:10, inlined from 'rte_memcpy' at ../lib/eal/x86/include/rte_memcpy.h:755:10, inlined from 'qdma_cntx_idx_ring_eq' at ../drivers/dma/dpaa2/dpaa2_qdma.c:80:3, inlined from 'dpaa2_qdma_dq_fd' at ../drivers/dma/dpaa2/dpaa2_qdma.c:953:9, inlined from 'dpaa2_qdma_dequeue' at ../drivers/dma/dpaa2/dpaa2_qdma.c:1109:9: ../lib/eal/x86/include/rte_memcpy.h:89:63: error: array subscript 'const struct rte_uint32_alias[0]' is partly outside array bounds of 'const void[2]' [-Werror=array-bounds=] 89 | ((const struct rte_uint32_alias *)src)->val; | ~~^ ../drivers/dma/dpaa2/dpaa2_qdma.c: In function 'dpaa2_qdma_dequeue': ../drivers/dma/dpaa2/dpaa2_qdma.c:943:18: note: object 'idx' of size 2 943 | uint16_t idx, att; | ^~~ ../drivers/dma/dpaa2/dpaa2_qdma.c:943:18: note: at offset [8, 10] into object 'idx' of size 2 cc1: all warnings being treated as errors [1029/2944] Compiling C object 'drivers/a715181@@tmp_rte_dma_idxd at sta/dma_idxd_idxd_common.c.o'. [1030/2944] Generating rte_common_sfc_efx.sym_chk with a meson_exe.py custom command. [1031/2944] Generating rte_common_cnxk.sym_chk with a meson_exe.py custom command. ninja: build stopped: subcommand failed. End log output
Re: [PATCH v2] net/mvneta: fix possible out-of-bounds write
On Wed, 9 Oct 2024 06:08:45 +
Chengwen Feng wrote:
> The mvneta_ifnames_get() function will save 'iface' value to ifnames,
> it will out-of-bounds write if passed many iface pairs (e.g.
> 'iface=xxx,iface=xxx,...').
>
> Fixes: 4ccc8d770d3b ("net/mvneta: add PMD skeleton")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Chengwen Feng
> Acked-by: Ferruh Yigit
>
> ---
> v2: add error log which address Stephen's comment.
>
> ---
> drivers/net/mvneta/mvneta_ethdev.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/mvneta/mvneta_ethdev.c
> b/drivers/net/mvneta/mvneta_ethdev.c
> index 3841c1ebe9..e641f19266 100644
> --- a/drivers/net/mvneta/mvneta_ethdev.c
> +++ b/drivers/net/mvneta/mvneta_ethdev.c
> @@ -91,6 +91,11 @@ mvneta_ifnames_get(const char *key __rte_unused, const
> char *value,
> {
> struct mvneta_ifnames *ifnames = extra_args;
>
> + if (ifnames->idx >= NETA_NUM_ETH_PPIO) {
> + MVNETA_LOG(ERROR, "Detect too many ifnames!");
> + return -EINVAL;
> + }
> +
Compile fails due to typo. Need to use "ERR," not "ERROR,"
RE: [PATCH v4 1/2] ipsec: allow stateless IPsec processing
> Introduce stateless packet preparation API for IPsec > processing. The new API would allow preparation of IPsec > packets without altering the internal state of an IPsec > session. > > For outbound IPsec processing, the change enables user to > provide sequence number to be used for the IPsec operation. > > Signed-off-by: Aakash Sasidharan > --- > doc/guides/prog_guide/ipsec_lib.rst| 6 ++ > doc/guides/rel_notes/release_24_11.rst | 6 ++ > lib/ipsec/esp_outb.c | 101 + > lib/ipsec/rte_ipsec.h | 84 > lib/ipsec/sa.c | 4 +- > lib/ipsec/sa.h | 8 ++ > 6 files changed, 176 insertions(+), 33 deletions(-) > > -- Acked-by: Konstantin Ananyev > 2.25.1
Re: [PATCH 2/5] net/ice: improve Tx scheduler graph output
On Wed, 9 Oct 2024 18:08:19 +0100
Bruce Richardson wrote:
> The function to dump the TX scheduler topology only adds to the chart
> nodes connected to TX queues or for the flow director VSI. Change the
> function to work recursively from the root node and thereby include all
> scheduler nodes, whether in use or not, in the dump.
>
> Also, improve the output of the Tx scheduler graphing function:
>
> * Add VSI details to each node in graph
> * When number of children is >16, skip middle nodes to reduce size of
> the graph, otherwise dot output is unviewable for large hierarchies
> * For VSIs other than zero, use dot's clustering method to put those
> VSIs into subgraphs with borders
> * For leaf nodes, display queue numbers for the any nodes assigned to
> ethdev NIC Tx queues
>
> Signed-off-by: Bruce Richardson
Fixes: ab4eaf9a8a31 ("net/ice: dump Tx scheduling tree")
Acked-by: Stephen Hemminger
Re: [PATCH 3/5] net/ice: add option to choose DDP package file
On Wed, 9 Oct 2024 18:08:20 +0100 Bruce Richardson wrote: > The "Dynamic Device Personalization" package is loaded at initialization > time by the driver, but the specific package file loaded depends upon > what package file is found first by searching through a hard-coded list > of firmware paths. To enable greater control over the package loading, > we can add a device option to choose a specific DDP package file to > load. > > Signed-off-by: Bruce Richardson > --- Acked-by: Stephen Hemminger
Re: [PATCH 5/5] net/ice: limit the number of queues to sched capabilities
On Wed, 9 Oct 2024 18:08:22 +0100 Bruce Richardson wrote: > Rather than assuming that each VSI can hold up to 256 queue pairs, > or the reported device limit, query the available nodes in the scheduler > tree to check that we are not overflowing the limit for number of > child scheduling nodes at each level. Do this by multiplying > max_children for each level beyond the VSI and using that as an > additional cap on the number of queues. > > Signed-off-by: Bruce Richardson Acked-by: Stephen Hemminger
Re: [PATCH 4/5] net/ice: add option to download scheduler topology
On Wed, 9 Oct 2024 18:08:21 +0100
Bruce Richardson wrote:
> diff --git a/drivers/net/ice/ice_ethdev.h b/drivers/net/ice/ice_ethdev.h
> index 2781362d04..76310f2c99 100644
> --- a/drivers/net/ice/ice_ethdev.h
> +++ b/drivers/net/ice/ice_ethdev.h
> @@ -564,6 +564,7 @@ struct ice_devargs {
> uint8_t proto_xtr[ICE_MAX_QUEUE_NUM];
> uint8_t pin_idx;
> uint8_t pps_out_ena;
> + int ddp_load_sched;
Since this is a boolean option why is the flag not uint8_t like the other flags
in ice_devargs?
Re: [PATCH 1/5] net/ice: detect stopping a flow-director queue twice
On Wed, 9 Oct 2024 18:08:18 +0100
Bruce Richardson wrote:
> If the flow-director queue is stopped at some point during the running
> of an application, the shutdown procedure for the port issues an error
> as it tries to stop the queue a second time, and fails to do so. We can
> eliminate this error by setting the tail-register pointer to NULL on
> stop, and checking for that condition in subsequent stop calls. Since
> the register pointer is set on start, any restarting of the queue will
> allow a stop call to progress as normal.
>
> Signed-off-by: Bruce Richardson
Fixes: 84dc7a95a2d3 ("net/ice: enable flow director engine")
Acked-by: Stephen Hemminger
Re: [PATCH v13 4/4] eal: add PMU support to tracing library
On Wed, 9 Oct 2024 14:50:02 +0200
Morten Brørup wrote:
> > From: Tomasz Duszynski [mailto:tduszyn...@marvell.com]
> > Sent: Wednesday, 9 October 2024 13.23
> >
> > +PMU tracepoint
> > +--
> > +
> > +Performance monitoring unit (PMU) event values can be read from
> > hardware
> > +registers using predefined ``rte_pmu_read`` tracepoint.
> > +
> > +Tracing is enabled via ``--trace`` EAL option by passing both
> > expression
> > +matching PMU tracepoint name i.e ``lib.eal.pmu.read`` and expression
> > +``e=ev1[,ev2,...]`` matching particular events::
> > +
> > +--trace='.*pmu.read\|e=cpu_cycles,l1d_cache'
> > +
> > +Event names are available under
> > ``/sys/bus/event_source/devices/PMU/events``
> > +directory, where ``PMU`` is a placeholder for either a ``cpu`` or a
> > directory
> > +containing ``cpus``.
> > +
> > +In contrary to other tracepoints this does not need any extra
> > variables
> > +added to source files. Instead, caller passes index which follows the
> > order of
> > +events specified via ``--trace`` parameter. In the following example
> > index ``0``
> > +corresponds to ``cpu_cyclces`` while index ``1`` corresponds to
> > ``l1d_cache``.
> > +
> > +.. code-block:: c
> > +
> > + ...
> > + rte_eal_trace_pmu_read(0);
> > + rte_eal_trace_pmu_read(1);
> > + ...
> > +
> > +PMU tracing support must be explicitly enabled using the
> > ``enable_trace_fp``
> > +option for meson build.
> > +
>
>
> > +int
> > +rte_pmu_add_events_by_pattern(const char *pattern)
> > +{
> > + regmatch_t rmatch;
> > + char buf[BUFSIZ];
> > + unsigned int num;
> > + regex_t reg;
> > + int ret;
> > +
> > + /* events are matched against occurrences of e=ev1[,ev2,..]
> > pattern */
> > + ret = regcomp(®, "e=([_[:alnum:]-],?)+", REG_EXTENDED);
> > + if (ret)
> > + return -EINVAL;
> > +
> > + for (;;) {
> > + if (regexec(®, pattern, 1, &rmatch, 0))
> > + break;
> > +
> > + num = rmatch.rm_eo - rmatch.rm_so;
> > + if (num > sizeof(buf))
> > + num = sizeof(buf);
> > +
> > + /* skip e= pattern prefix */
> > + memcpy(buf, pattern + rmatch.rm_so + 2, num - 2);
> > + buf[num - 2] = '\0';
> > + ret = add_events(buf);
> > + if (ret)
> > + break;
> > +
> > + pattern += rmatch.rm_eo;
> > + }
> > +
> > + regfree(®);
> > +
> > + return ret;
> > +}
>
> This --trace parameter takes a regex, but the --log-level parameter takes a
> globbing pattern (and a regex, for backwards compatibility, I assume).
>
> This --trace parameter should behave like the --log-level parameter, or if
> not able to parse both, use globbing pattern, not regex.
>
> Check the --trace parameter parser here:
> https://elixir.bootlin.com/dpdk/v24.07/source/lib/eal/common/eal_common_options.c#L1409
The log level has two API's one takes regex and one takes file glob pattern.
The original one was the regex, but everybody (including the documentation) got
regex wrong when the log level format had periods
in it. The glob match was more intuitive, and that is what is recommended.
For tracing if you want to use regex then function should be named with _regexp(
For extra bonus points, having both a regex and glob version (with pattern)
would be great.
RE: [EXTERNAL] Re: [PATCH v3 1/9] drivers/raw: introduce cnxk rvu lf device driver
> On Wed, 9 Oct 2024 00:19:07 +0530 > Akhil Goyal wrote: > > > CNXK product families can have a use case to allow PF and VF > > applications to communicate using mailboxes and also get notified > > of any interrupt that may occur on the device. > > Hence, a new raw device driver is added for such RVU LF devices. > > These devices can map to a PF or a VF which can send mailboxes to > > each other. > > > > Signed-off-by: Akhil Goyal > > --- > > MAINTAINERS | 6 ++ > > doc/guides/rawdevs/cnxk_rvu_lf.rst| 40 + > > doc/guides/rawdevs/index.rst | 1 + > > drivers/common/cnxk/meson.build | 1 + > > drivers/common/cnxk/roc_api.h | 3 + > > drivers/common/cnxk/roc_constants.h | 3 + > > This patch set does not apply to main branch, are you targeting another tree > or is there a dependency on a previous patch series. This is targeted for next-net-mrvl and as mentioned in cover-letter it depends on https://patches.dpdk.org/project/dpdk/patch/20241008074000.3745855-1-gak...@marvell.com/ > > $ cat drivers/common/cnxk/roc_constants.h.rej > --- drivers/common/cnxk/roc_constants.h > +++ drivers/common/cnxk/roc_constants.h > @@ -65,6 +67,7 @@ > #define PCI_SUBSYSTEM_DEVID_CNF10KB 0xBC00 > > #define PCI_SUBSYSTEM_DEVID_CN20KA 0xA020 > +#define PCI_SUBSYSTEM_DEVID_CNF20KA 0xA000 > > #define PCI_SUBSYSTEM_DEVID_CN9KA 0x > #define PCI_SUBSYSTEM_DEVID_CN9KB 0xb400
RE: [PATCH v4 1/2] ipsec: allow stateless IPsec processing
> > > > Introduce stateless packet preparation API for IPsec > > processing. The new API would allow preparation of IPsec > > packets without altering the internal state of an IPsec > > session. > > > > For outbound IPsec processing, the change enables user to > > provide sequence number to be used for the IPsec operation. > > > > Signed-off-by: Aakash Sasidharan > > --- > > doc/guides/prog_guide/ipsec_lib.rst| 6 ++ > > doc/guides/rel_notes/release_24_11.rst | 6 ++ > > lib/ipsec/esp_outb.c | 101 + > > lib/ipsec/rte_ipsec.h | 84 > > lib/ipsec/sa.c | 4 +- > > lib/ipsec/sa.h | 8 ++ > > 6 files changed, 176 insertions(+), 33 deletions(-) > > > > -- > > Acked-by: Konstantin Ananyev Series Acked-by: Akhil Goyal Applied to dpdk-next-crypto Thanks. Removed associated deprecation notice.
Re: [PATCH v12 0/7] Improve EAL bit operations API
On Fri, Sep 20, 2024 at 12:57 PM Mattias Rönnblom wrote: > > This patch set represent an attempt to improve and extend the RTE > bitops API, in particular for functions that operate on individual > bits. > > All new functionality is exposed to the user as generic selection > macros, delegating the actual work to private (__-marked) static > inline functions. Public functions (e.g., rte_bit_set32()) would just > be bloating the API. Such generic selection macros will here be > referred to as "functions", although technically they are not. > > The legacy rte_bit_relaxed_*() functions is replaced > with two new families: > > rte_bit_[test|set|clear|assign|flip]() which provides no memory > ordering or atomicity guarantees, but does provide the best > performance. The performance degradation resulting from the use of > volatile (e.g., forcing loads and stores to actually occur and in the > number specified) and atomic (e.g., LOCK-prefixed instructions on x86) > may be significant. rte_bit_[test|set|clear|assign|flip]() may be > used with volatile word pointers, in which case they guarantee > that the program-level accesses actually occur. > > rte_bit_atomic_*() which provides atomic bit-level operations, > including the possibility to specifying memory ordering constraints > (or the lack thereof). > > The atomic functions take non-_Atomic pointers, to be flexible, just > like the GCC builtins and default . The issue with > _Atomic APIs is that it may well be the case that the user wants to > perform both non-atomic and atomic operations on the same word. > > Having _Atomic-marked addresses would complicate supporting atomic > bit-level operations in the bitset API (proposed in a different RFC > patchset), and potentially other APIs depending on RTE bitops for > atomic bit-level ops). Either one needs two bitset variants, one > _Atomic bitset and one non-atomic one, or the bitset code needs to > cast the non-_Atomic pointer to an _Atomic one. Having a separate > _Atomic bitset would be bloat and also prevent the user from both, in > some situations, doing atomic operations against a bit set, while in > other situations (e.g., at times when MT safety is not a concern) > operating on the same objects in a non-atomic manner. > > Unlike rte_bit_relaxed_*(), individual bits are represented by bool, > not uint32_t or uint64_t. The author found the use of such large types > confusing, and also failed to see any performance benefits. > > A set of functions rte_bit_*_assign() are added, to assign a > particular boolean value to a particular bit. > > All new functions have properly documented semantics. > > All new functions operate on both 32 and 64-bit words, with type > checking. > > _Generic allow the user code to be a little more impact. Have a > type-generic atomic test/set/clear/assign bit API also seems > consistent with the "core" (word-size) atomics API, which is generic > (both GCC builtins and are). > > The _Generic versions avoids having explicit unsigned long versions of > all functions. If you have an unsigned long, it's safe to use the > generic version (e.g., rte_set_bit()) and _Generic will pick the right > function, provided long is either 32 or 64 bit on your platform (which > it is on all DPDK-supported ABIs). > > The generic rte_bit_set() is a macro, and not a function, but > nevertheless has been given a lower-case name. That's how C11 does it > (for atomics, and other _Generic), and . Its address > can't be taken, but it does not evaluate its parameters more than > once. > > C++ doesn't support generic selection. In C++ translation units the > _Generic macros are replaced with overloaded functions, implemented by > means of a huge, complicated C macro mess. > > Mattias Rönnblom (7): > buildtools/chkincs: relax C linkage requirement > dpdk: use C linkage only where appropriate > eal: extend bit manipulation functionality > eal: add unit tests for bit operations > eal: add atomic bit operations > eal: add unit tests for atomic bit access functions > eal: extend bitops to handle volatile pointers > > app/test/packet_burst_generator.h | 8 +- > app/test/test_bitops.c| 416 +- > app/test/virtual_pmd.h| 4 +- > buildtools/chkincs/chkextern.py | 88 ++ > buildtools/chkincs/meson.build| 21 +- > doc/guides/rel_notes/release_24_11.rst| 17 + > drivers/bus/auxiliary/bus_auxiliary_driver.h | 8 +- > drivers/bus/cdx/bus_cdx_driver.h | 8 +- > drivers/bus/dpaa/include/fsl_qman.h | 8 +- > drivers/bus/fslmc/bus_fslmc_driver.h | 8 +- > drivers/bus/pci/bus_pci_driver.h | 8 +- > drivers/bus/pci/rte_bus_pci.h | 8 +- > drivers/bus/platform/bus_platform_driver.h| 8 +- > drivers/bus/vdev/bus_vdev_driver.h| 8 +- > drivers/bus/vmbus/bus_vmbus_driver.h | 8 +- > drivers/bus/vmbus/rte_
RE: [RFC 0/4] ethdev: rework config restore
> -Original Message- > From: Ferruh Yigit > Sent: Wednesday, October 9, 2024 03:08 > To: Konstantin Ananyev ; Dariusz Sosnowski > ; NBU-Contact-Thomas Monjalon (EXTERNAL) > ; Andrew Rybchenko > Cc: dev@dpdk.org; Bruce Richardson > Subject: Re: [RFC 0/4] ethdev: rework config restore > > External email: Use caution opening links or attachments > > > On 10/8/2024 6:21 PM, Konstantin Ananyev wrote: > > > > > >> We have been working on optimizing the latency of calls to > >> rte_eth_dev_start(), on ports spawned by mlx5 PMD. Most of the > >> work requires changes in the implementation of > >> .dev_start() PMD callback, but I also wanted to start a > >> discussion regarding configuration restore. > >> > >> rte_eth_dev_start() does a few things on top of calling .dev_start() > callback: > >> > >> - Before calling it: > >> - eth_dev_mac_restore() - if device supports > >> RTE_ETH_DEV_NOLIVE_MAC_ADDR; > >> - After calling it: > >> - eth_dev_mac_restore() - if device does not support > > RTE_ETH_DEV_NOLIVE_MAC_ADDR; > >> - restore promiscuous config > >> - restore all multicast config > >> > >> eth_dev_mac_restore() iterates over all known MAC addresses - > >> stored in rte_eth_dev_data.mac_addrs array - and calls > >> .mac_addr_set() and .mac_addr_add() callbacks to apply these MAC > addresses. > >> > >> Promiscuous config restore checks if promiscuous mode is enabled > >> or not, and calls .promiscuous_enable() or .promiscuous_disable() > callback. > >> > >> All multicast config restore checks if all multicast mode is > >> enabled or not, and calls .allmulticast_enable() or > >> .allmulticast_disable() > callback. > >> > >> Callbacks are called directly in all of these cases, to bypass > >> the checks for applying the same configuration, which exist in relevant > APIs. > >> Checks are bypassed to force drivers to reapply the configuration. > >> > >> Let's consider what happens in the following sequence of API calls. > >> > >> 1. rte_eth_dev_configure() > >> 2. rte_eth_tx_queue_setup() > >> 3. rte_eth_rx_queue_setup() > >> 4. rte_eth_promiscuous_enable() > >> - Call dev->dev_ops->promiscuous_enable() > >> - Stores promiscuous state in dev->data->promiscuous 5. > >> rte_eth_allmulticast_enable() > >> - Call dev->dev_ops->allmulticast_enable() > >> - Stores allmulticast state in dev->data->allmulticast 6. > >> rte_eth_dev_start() > >> - Call dev->dev_ops->dev_start() > >> - Call dev->dev_ops->mac_addr_set() - apply default MAC address > >> - Call dev->dev_ops->promiscuous_enable() > >> - Call dev->dev_ops->allmulticast_enable() > >> > >> Even though all configuration is available in dev->data after > >> step 5, library forces reapplying this configuration in step 6. > >> > >> In mlx5 PMD case all relevant callbacks require communication > >> with the kernel driver, to configure the device (mlx5 PMD must > >> create/destroy new kernel flow rules and/or change netdev config). > >> > >> mlx5 PMD handles applying all configuration in .dev_start(), so > >> the following forced callbacks force additional communication > >> with the kernel. The > > same configuration is applied multiple times. > >> > >> As an optimization, mlx5 PMD could check if a given configuration > >> was applied, but this would duplicate the functionality of the > >> library (for example rte_eth_promiscuous_enable() does not call > >> the driver if > >> dev->data->promiscuous is set). > >> > >> Question: Since all of the configuration is available before > >> .dev_start() callback is called, why ethdev library does not > >> expect .dev_start() to > > take this configuration into account? > >> In other words, why library has to reapply the configuration? > >> > >> I could not find any particular reason why configuration restore > >> exists as part of the process (it was in the initial DPDK commit). > >> > > > > My assumption is .dev_stop() cause these values reset in some > > devices, so > > .dev_start() restores them back. > > @Bruce or @Konstantin may remember the history. > >>> > >>> Yep, as I remember, at least some Intel PMDs calling hw_reset() ad > >>> dec_stop() and even dev_start() to make sure that HW is in a clean (known) > state. > >>> > > > > But I agree this is device specific behavior, and can be managed > > by what device requires. > >>> > >>> Probably yes. > >>> > > > >> The patches included in this RFC, propose a mechanism which would > >> help with managing which drivers rely on forceful configuration > >> restore. > >> Drivers could advertise if forceful configuration restore is > >> needed through `RTE_ETH_DEV_*_FOR
[PATCH v2] maintainers: update for dts
Paul and Patrick have been appointed as the new dts maintainers. Updating the MAINTAINERS file to reflect this. Signed-off-by: Patrick Robb Signed-off-by: Paul Szczepanek --- v2: added updated for Tree section MAINTAINERS | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 812463fe9f..7d171e3d45 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -65,7 +65,8 @@ M: Maxime Coquelin T: git://dpdk.org/next/dpdk-next-baseband Next-dts Tree -M: Juraj Linke?? +M: Paul Szczepanek +M: Patrick Robb T: git://dpdk.org/next/dpdk-next-dts Stable Branches @@ -1889,7 +1890,8 @@ F: app/proc-info/ F: doc/guides/tools/proc_info.rst DTS -M: Juraj Linke?? +M: Paul Szczepanek +M: Patrick Robb T: git://dpdk.org/next/dpdk-next-dts F: dts/ F: devtools/dts-check-format.sh -- 2.46.1
RE: rte_ring move head question for machines with relaxed MO (arm/ppc)
> >
> > > > 1. rte_ring_generic_pvt.h:
> > > > =
> > > >
> > > > pseudo-c-code //related
> > > > armv8 instructions
> > > >
> > > > --
> > > > head.load() //ldr
> > > > [head]
> > > > rte_smp_rmb()//dmb ishld
> > > > opposite_tail.load()//ldr
> > > > [opposite_tail]
> > > > ...
> > > > rte_atomic32_cmpset(head, ...) //ldrex[head];...
> > > > stlex[head]
> > > >
> > > >
> > > > 2. rte_ring_c11_pvt.h
> > > > =
> > > >
> > > > pseudo-c-code //related
> > > > armv8 instructions
> > > >
> > > > --
> > > > head.atomic_load(relaxed) //ldr[head]
> > > > atomic_thread_fence(acquire) //dmb ish
> > > > opposite_tail.atomic_load(acquire) //lda[opposite_tail]
> > > > ...
> > > > head.atomic_cas(..., relaxed) //ldrex[haed]; ...
> > > > strex[head]
> > > >
> > > >
> > > > 3. rte_ring_hts_elem_pvt.h
> > > > ==
> > > >
> > > > pseudo-c-code //related
> > > > armv8 instructions
> > > >
> > > > --
> > > > head.atomic_load(acquire)//lda [head]
> > > > opposite_tail.load() //ldr
> > > > [opposite_tail]
> > > > ...
> > > > head.atomic_cas(..., acquire)// ldaex[head]; ...
> > > > strex[head]
> > > >
> > > > The questions that arose from these observations:
> > > > a) are all 3 approaches equivalent in terms of functionality?
> > > Different, lda (Load with acquire semantics) and ldr (load) are different.
> >
> > I understand that, my question was:
> > lda {head]; ldr[tail]
> > vs
> > ldr [head]; dmb ishld; ldr [tail];
> >
> > Is there any difference in terms of functionality (memory ops
> ordering/observability)?
>
> To be more precise:
>
> lda {head]; ldr[tail]
> vs
> ldr [head]; dmb ishld; ldr [tail];
> vs
> ldr [head]; dmb ishld; lda [tail];
>
> what would be the difference between these 3 cases?
Case A: lda {head]; ldr[tail]
load of the head will be observed by the memory subsystem
before the load of the tail.
Case B: ldr [head]; dmb ishld; ldr [tail];
load of the head will be observed by the memory subsystem
Before the load of the tail.
Case C: ldr [head]; dmb ishld; lda [tail];
load of the head will be observed by the memory subsystem
before the load of the tail. In addition, any load or store program
order after lda[tail] will not be observed by the memory subsystem
before the load of the tail.
Essentially both cases A and B are the same.
They preserve following program orders.
LOAD-LOAD
LOAD-STORE
[PATCH v3 01/12] baseband/acc: fix access to deallocated mem
Prevent op_addr access during queue_stop operation, as this memory may
have been deallocated.
Fixes: e640f6cdfa84 ("baseband/acc200: add LDPC processing")
Cc: sta...@dpdk.org
Signed-off-by: Hernan Vargas
Reviewed-by: Maxime Coquelin
---
drivers/baseband/acc/rte_acc100_pmd.c | 36 --
drivers/baseband/acc/rte_vrb_pmd.c| 44 +--
2 files changed, 1 insertion(+), 79 deletions(-)
diff --git a/drivers/baseband/acc/rte_acc100_pmd.c
b/drivers/baseband/acc/rte_acc100_pmd.c
index 5e6ee85e1321..c690d1492ba3 100644
--- a/drivers/baseband/acc/rte_acc100_pmd.c
+++ b/drivers/baseband/acc/rte_acc100_pmd.c
@@ -838,51 +838,15 @@ acc100_queue_setup(struct rte_bbdev *dev, uint16_t
queue_id,
return ret;
}
-static inline void
-acc100_print_op(struct rte_bbdev_dec_op *op, enum rte_bbdev_op_type op_type,
- uint16_t index)
-{
- if (op == NULL)
- return;
- if (op_type == RTE_BBDEV_OP_LDPC_DEC)
- rte_bbdev_log(DEBUG,
- " Op 5GUL %d %d %d %d %d %d %d %d %d %d %d %d",
- index,
- op->ldpc_dec.basegraph, op->ldpc_dec.z_c,
- op->ldpc_dec.n_cb, op->ldpc_dec.q_m,
- op->ldpc_dec.n_filler, op->ldpc_dec.cb_params.e,
- op->ldpc_dec.op_flags, op->ldpc_dec.rv_index,
- op->ldpc_dec.iter_max, op->ldpc_dec.iter_count,
- op->ldpc_dec.harq_combined_input.length
- );
- else if (op_type == RTE_BBDEV_OP_LDPC_ENC) {
- struct rte_bbdev_enc_op *op_dl = (struct rte_bbdev_enc_op *) op;
- rte_bbdev_log(DEBUG,
- " Op 5GDL %d %d %d %d %d %d %d %d %d",
- index,
- op_dl->ldpc_enc.basegraph, op_dl->ldpc_enc.z_c,
- op_dl->ldpc_enc.n_cb, op_dl->ldpc_enc.q_m,
- op_dl->ldpc_enc.n_filler, op_dl->ldpc_enc.cb_params.e,
- op_dl->ldpc_enc.op_flags, op_dl->ldpc_enc.rv_index
- );
- }
-}
-
static int
acc100_queue_stop(struct rte_bbdev *dev, uint16_t queue_id)
{
struct acc_queue *q;
- struct rte_bbdev_dec_op *op;
- uint16_t i;
q = dev->data->queues[queue_id].queue_private;
rte_bbdev_log(INFO, "Queue Stop %d H/T/D %d %d %x OpType %d",
queue_id, q->sw_ring_head, q->sw_ring_tail,
q->sw_ring_depth, q->op_type);
- for (i = 0; i < q->sw_ring_depth; ++i) {
- op = (q->ring_addr + i)->req.op_addr;
- acc100_print_op(op, q->op_type, i);
- }
/* ignore all operations in flight and clear counters */
q->sw_ring_tail = q->sw_ring_head;
q->aq_enqueued = 0;
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
b/drivers/baseband/acc/rte_vrb_pmd.c
index 646c12ad5cac..e3f98d6e421c 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -1048,58 +1048,16 @@ vrb_queue_setup(struct rte_bbdev *dev, uint16_t
queue_id,
return ret;
}
-static inline void
-vrb_print_op(struct rte_bbdev_dec_op *op, enum rte_bbdev_op_type op_type,
- uint16_t index)
-{
- if (op == NULL)
- return;
- if (op_type == RTE_BBDEV_OP_LDPC_DEC)
- rte_bbdev_log(INFO,
- " Op 5GUL %d %d %d %d %d %d %d %d %d %d %d %d",
- index,
- op->ldpc_dec.basegraph, op->ldpc_dec.z_c,
- op->ldpc_dec.n_cb, op->ldpc_dec.q_m,
- op->ldpc_dec.n_filler, op->ldpc_dec.cb_params.e,
- op->ldpc_dec.op_flags, op->ldpc_dec.rv_index,
- op->ldpc_dec.iter_max, op->ldpc_dec.iter_count,
- op->ldpc_dec.harq_combined_input.length
- );
- else if (op_type == RTE_BBDEV_OP_LDPC_ENC) {
- struct rte_bbdev_enc_op *op_dl = (struct rte_bbdev_enc_op *) op;
- rte_bbdev_log(INFO,
- " Op 5GDL %d %d %d %d %d %d %d %d %d",
- index,
- op_dl->ldpc_enc.basegraph, op_dl->ldpc_enc.z_c,
- op_dl->ldpc_enc.n_cb, op_dl->ldpc_enc.q_m,
- op_dl->ldpc_enc.n_filler, op_dl->ldpc_enc.cb_params.e,
- op_dl->ldpc_enc.op_flags, op_dl->ldpc_enc.rv_index
- );
- } else if (op_type == RTE_BBDEV_OP_MLDTS) {
- struct rte_bbdev_mldts_op *op_mldts = (struct
rte_bbdev_mldts_op *) op;
- rte_bbdev_log(INFO, " Op MLD %d RBs %d NL %d Rp %d %d %x",
- index,
- op_mldts->mldts.num_rbs,
op_mldts->mldts.num_layers,
- op_mldts->mldts.r_rep,
-
[PATCH v3 00/12] acc baseband PMD fix and updates for 24.11
This series targets 24.11. v3: Updated code with community recommendations. Added 2 commits for rte_free refactor and clean up of VRB1 capabilities. v2: Rebased to the latest next-baseband-for-main which includes needed rte_bbdev lib updates. v1: It includes a memory access fix, refactoring of queue allocation and general improvements. Hernan Vargas (12): baseband/acc: fix access to deallocated mem baseband/acc: fix soft output bypass RM baseband/acc: queue allocation refactor baseband/acc: configure max queues per device baseband/acc: future proof structure comparison baseband/acc: enhance SW ring alignment baseband/acc: algorithm tuning for LDPC decoder baseband/acc: remove check on HARQ memory baseband/acc: reset ring data valid bit baseband/acc: cosmetic changes baseband/acc: rte free refactor baseband/acc: clean up of VRB1 capabilities doc/guides/bbdevs/vrb1.rst| 3 - drivers/baseband/acc/acc_common.h | 16 +- drivers/baseband/acc/rte_acc100_pmd.c | 61 ++--- drivers/baseband/acc/rte_vrb_pmd.c| 335 -- 4 files changed, 227 insertions(+), 188 deletions(-) -- 2.37.1
[PATCH v3 03/12] baseband/acc: queue allocation refactor
Refactor to manage queue memory per operation more flexibly for VRB
devices.
Signed-off-by: Hernan Vargas
---
drivers/baseband/acc/acc_common.h | 5 +
drivers/baseband/acc/rte_vrb_pmd.c | 214 -
2 files changed, 157 insertions(+), 62 deletions(-)
diff --git a/drivers/baseband/acc/acc_common.h
b/drivers/baseband/acc/acc_common.h
index 38870c6458c4..70028fb5d235 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -149,6 +149,8 @@
#define VRB2_VF_ID_SHIFT 6
#define ACC_MAX_FFT_WIN 16
+#define ACC_MAX_RING_BUFFER 64
+#define VRB2_MAX_Q_PER_OP 256
extern int acc_common_logtype;
#define RTE_LOGTYPE_ACC_COMMON acc_common_logtype
@@ -581,6 +583,9 @@ struct acc_device {
void *sw_rings_base; /* Base addr of un-aligned memory for sw rings */
void *sw_rings; /* 64MBs of 64MB aligned memory for sw rings */
rte_iova_t sw_rings_iova; /* IOVA address of sw_rings */
+ void *sw_rings_array[ACC_MAX_RING_BUFFER]; /* Array of aligned memory
for sw rings. */
+ rte_iova_t sw_rings_iova_array[ACC_MAX_RING_BUFFER]; /* Array of
sw_rings IOVA. */
+ uint32_t queue_index[ACC_MAX_RING_BUFFER]; /* Tracking queue index per
ring buffer. */
/* Virtual address of the info memory routed to the this function under
* operation, whether it is PF or VF.
* HW may DMA information data at this location asynchronously
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
b/drivers/baseband/acc/rte_vrb_pmd.c
index 52a683e4e49b..7e967ba97ac2 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -282,7 +282,7 @@ fetch_acc_config(struct rte_bbdev *dev)
/* Check the depth of the AQs. */
reg_len0 = acc_reg_read(d, d->reg_addr->depth_log0_offset);
reg_len1 = acc_reg_read(d, d->reg_addr->depth_log1_offset);
- for (acc = 0; acc < NUM_ACC; acc++) {
+ for (acc = 0; acc < VRB1_NUM_ACCS; acc++) {
qtopFromAcc(&q_top, acc, acc_conf);
if (q_top->first_qgroup_index < ACC_NUM_QGRPS_PER_WORD)
q_top->aq_depth_log2 =
@@ -291,7 +291,7 @@ fetch_acc_config(struct rte_bbdev *dev)
q_top->aq_depth_log2 = (reg_len1 >>
((q_top->first_qgroup_index -
ACC_NUM_QGRPS_PER_WORD) * 4)) &
0xF;
}
- } else {
+ } else if (d->device_variant == VRB2_VARIANT) {
reg0 = acc_reg_read(d, d->reg_addr->qman_group_func);
reg1 = acc_reg_read(d, d->reg_addr->qman_group_func + 4);
reg2 = acc_reg_read(d, d->reg_addr->qman_group_func + 8);
@@ -309,7 +309,7 @@ fetch_acc_config(struct rte_bbdev *dev)
idx = (reg2 >> ((qg %
ACC_NUM_QGRPS_PER_WORD) * 4)) & 0x7;
else
idx = (reg3 >> ((qg %
ACC_NUM_QGRPS_PER_WORD) * 4)) & 0x7;
- if (idx < VRB_NUM_ACCS) {
+ if (idx < VRB2_NUM_ACCS) {
acc = qman_func_id[idx];
updateQtop(acc, qg, acc_conf, d);
}
@@ -322,7 +322,7 @@ fetch_acc_config(struct rte_bbdev *dev)
reg_len2 = acc_reg_read(d, d->reg_addr->depth_log0_offset + 8);
reg_len3 = acc_reg_read(d, d->reg_addr->depth_log0_offset + 12);
- for (acc = 0; acc < NUM_ACC; acc++) {
+ for (acc = 0; acc < VRB2_NUM_ACCS; acc++) {
qtopFromAcc(&q_top, acc, acc_conf);
if (q_top->first_qgroup_index / ACC_NUM_QGRPS_PER_WORD
== 0)
q_top->aq_depth_log2 = (reg_len0 >>
((q_top->first_qgroup_index %
@@ -544,6 +544,7 @@ vrb_setup_queues(struct rte_bbdev *dev, uint16_t
num_queues, int socket_id)
{
uint32_t phys_low, phys_high, value;
struct acc_device *d = dev->data->dev_private;
+ uint16_t queues_per_op, i;
int ret;
if (d->pf_device && !d->acc_conf.pf_mode_en) {
@@ -565,27 +566,37 @@ vrb_setup_queues(struct rte_bbdev *dev, uint16_t
num_queues, int socket_id)
return -ENODEV;
}
- alloc_sw_rings_min_mem(dev, d, num_queues, socket_id);
+ if (d->device_variant == VRB1_VARIANT) {
+ alloc_sw_rings_min_mem(dev, d, num_queues, socket_id);
- /* If minimal memory space approach failed, then allocate
-* the 2 * 64MB block for the sw rings.
-*/
- if (d->sw_rings == NULL)
- alloc_2x64mb_sw_rings_mem(dev, d, socket_id);
+ /* If minimal memory space approach failed, then allocate
+* the 2 * 64MB block for the sw rings.
+*/
+ if (d->sw
[PATCH v3 04/12] baseband/acc: configure max queues per device
Configure max_queues based on the number of queue groups and numbers of
AQS per device variant.
Signed-off-by: Hernan Vargas
Reviewed-by: Maxime Coquelin
---
drivers/baseband/acc/rte_vrb_pmd.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
b/drivers/baseband/acc/rte_vrb_pmd.c
index 7e967ba97ac2..519385e82ed3 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -545,7 +545,7 @@ vrb_setup_queues(struct rte_bbdev *dev, uint16_t
num_queues, int socket_id)
uint32_t phys_low, phys_high, value;
struct acc_device *d = dev->data->dev_private;
uint16_t queues_per_op, i;
- int ret;
+ int ret, max_queues = 0;
if (d->pf_device && !d->acc_conf.pf_mode_en) {
rte_bbdev_log(NOTICE,
@@ -672,10 +672,15 @@ vrb_setup_queues(struct rte_bbdev *dev, uint16_t
num_queues, int socket_id)
value = log2_basic(d->sw_ring_size / ACC_RING_SIZE_GRANULARITY);
acc_reg_write(d, d->reg_addr->ring_size, value);
+ if (d->device_variant == VRB1_VARIANT)
+ max_queues = VRB1_NUM_QGRPS * VRB1_NUM_AQS;
+ else if (d->device_variant == VRB2_VARIANT)
+ max_queues = VRB2_NUM_QGRPS * VRB2_NUM_AQS;
+
/* Configure tail pointer for use when SDONE enabled. */
if (d->tail_ptrs == NULL)
d->tail_ptrs = rte_zmalloc_socket(dev->device->driver->name,
- VRB_MAX_QGRPS * VRB_MAX_AQS * sizeof(uint32_t),
+ max_queues * sizeof(uint32_t),
RTE_CACHE_LINE_SIZE, socket_id);
if (d->tail_ptrs == NULL) {
rte_bbdev_log(ERR, "Failed to allocate tail ptr for %s:%u",
--
2.37.1
[PATCH v3 02/12] baseband/acc: fix soft output bypass RM
Removing soft output bypass RM capability due to VRB2 device
limitations.
Fixes: b49fe052f9cd ("baseband/acc: add FEC capabilities for VRB2 variant")
Cc: sta...@dpdk.org
Signed-off-by: Hernan Vargas
---
drivers/baseband/acc/rte_vrb_pmd.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
b/drivers/baseband/acc/rte_vrb_pmd.c
index e3f98d6e421c..52a683e4e49b 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -1272,7 +1272,6 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct
rte_bbdev_driver_info *dev_info)
RTE_BBDEV_LDPC_HARQ_4BIT_COMPRESSION |
RTE_BBDEV_LDPC_LLR_COMPRESSION |
RTE_BBDEV_LDPC_SOFT_OUT_ENABLE |
- RTE_BBDEV_LDPC_SOFT_OUT_RM_BYPASS |
RTE_BBDEV_LDPC_SOFT_OUT_DEINTERLEAVER_BYPASS |
RTE_BBDEV_LDPC_DEC_INTERRUPTS,
.llr_size = 8,
@@ -1643,18 +1642,18 @@ vrb_fcw_ld_fill(struct rte_bbdev_dec_op *op, struct
acc_fcw_ld *fcw,
fcw->so_en = check_bit(op->ldpc_dec.op_flags,
RTE_BBDEV_LDPC_SOFT_OUT_ENABLE);
fcw->so_bypass_intlv = check_bit(op->ldpc_dec.op_flags,
RTE_BBDEV_LDPC_SOFT_OUT_DEINTERLEAVER_BYPASS);
- fcw->so_bypass_rm = check_bit(op->ldpc_dec.op_flags,
- RTE_BBDEV_LDPC_SOFT_OUT_RM_BYPASS);
+ fcw->so_bypass_rm = 0;
fcw->minsum_offset = 1;
fcw->dec_llrclip = 2;
}
/*
-* These are all implicitly set
+* These are all implicitly set:
* fcw->synd_post = 0;
* fcw->dec_convllr = 0;
* fcw->hcout_convllr = 0;
* fcw->hcout_size1 = 0;
+* fcw->so_it = 0;
* fcw->hcout_offset = 0;
* fcw->negstop_th = 0;
* fcw->negstop_it = 0;
--
2.37.1
[PATCH v3 06/12] baseband/acc: enhance SW ring alignment
Calculate the aligned total size required for queue rings, ensuring that
the size is a power of two for proper memory allocation.
Signed-off-by: Hernan Vargas
---
drivers/baseband/acc/acc_common.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/baseband/acc/acc_common.h
b/drivers/baseband/acc/acc_common.h
index 1d8fd24ba008..0c249d5b93fd 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -767,6 +767,7 @@ alloc_sw_rings_min_mem(struct rte_bbdev *dev, struct
acc_device *d,
int i = 0;
uint32_t q_sw_ring_size = ACC_MAX_QUEUE_DEPTH * get_desc_len();
uint32_t dev_sw_ring_size = q_sw_ring_size * num_queues;
+ uint32_t alignment = q_sw_ring_size * rte_align32pow2(num_queues);
/* Free first in case this is a reconfiguration */
rte_free(d->sw_rings_base);
@@ -774,12 +775,12 @@ alloc_sw_rings_min_mem(struct rte_bbdev *dev, struct
acc_device *d,
while (i < ACC_SW_RING_MEM_ALLOC_ATTEMPTS) {
/*
* sw_ring allocated memory is guaranteed to be aligned to
-* q_sw_ring_size at the condition that the requested size is
-* less than the page size
+* the variable 'alignment' at the condition that the requested
+* size is less than the page size
*/
sw_rings_base = rte_zmalloc_socket(
dev->device->driver->name,
- dev_sw_ring_size, q_sw_ring_size, socket);
+ dev_sw_ring_size, alignment, socket);
if (sw_rings_base == NULL) {
rte_acc_log(ERR,
--
2.37.1
[PATCH v3 05/12] baseband/acc: future proof structure comparison
Some implementation in the PMD is based on some size assumption from the bbdev structure, which should use sizeof instead to be more future proof in case these structures change. Signed-off-by: Hernan Vargas Reviewed-by: Maxime Coquelin --- drivers/baseband/acc/acc_common.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/baseband/acc/acc_common.h b/drivers/baseband/acc/acc_common.h index 70028fb5d235..1d8fd24ba008 100644 --- a/drivers/baseband/acc/acc_common.h +++ b/drivers/baseband/acc/acc_common.h @@ -95,8 +95,8 @@ #define ACC_COMPANION_PTRS 8 #define ACC_FCW_VER2 #define ACC_MUX_5GDL_DESC 6 -#define ACC_CMP_ENC_SIZE 20 -#define ACC_CMP_DEC_SIZE 24 +#define ACC_CMP_ENC_SIZE (sizeof(struct rte_bbdev_op_ldpc_enc) - ACC_ENC_OFFSET) +#define ACC_CMP_DEC_SIZE (sizeof(struct rte_bbdev_op_ldpc_dec) - ACC_DEC_OFFSET) #define ACC_ENC_OFFSET(32) #define ACC_DEC_OFFSET(80) #define ACC_LIMIT_DL_MUX_BITS 534 -- 2.37.1
RE: [EXTERNAL] [PATCH v8 6/8] lib/cryptodev: add sm4 xts for crypto
> Title should be cryptodev: add SM4-XTS > > > add support of sm4 xts . > > > > Signed-off-by: Hanxiao Li > > Send this patch (along with test cases) as a separate patchset "not included > in this > series." > > Update documentation doc/guides/cryptodevs/features/defaults.ini > Update release notes for adding new algo. > Please send the next version for the library changes as soon as possible. This need to be merged by 11th October in RC1 or else it will be deferred for next release.
RE: [EXTERNAL] Re: [PATCH v2] rawdev: add API to get device from index
> > > diff --git a/lib/rawdev/rte_rawdev_pmd.h b/lib/rawdev/rte_rawdev_pmd.h
> > > index 22b406444d..8339122348 100644
> > > --- a/lib/rawdev/rte_rawdev_pmd.h
> > > +++ b/lib/rawdev/rte_rawdev_pmd.h
> > > @@ -102,6 +102,30 @@ rte_rawdev_pmd_get_named_dev(const char
> *name)
> > > return NULL;
> > > }
> > >
> > > +/**
> > > + * Get the rte_rawdev structure device pointer for given device ID.
> > > + *
> > > + * @param dev_id
> > > + * raw device index.
> > > + *
> > > + * @return
> > > + * - The rte_rawdev structure pointer for the given device ID.
> > > + */
> > > +static inline struct rte_rawdev *
> > > +rte_rawdev_pmd_get_dev(uint8_t dev_id)
> > > +{
> > > + struct rte_rawdev *dev;
> > > +
> > > + if (dev_id >= RTE_RAWDEV_MAX_DEVS)
> > > + return NULL;
> > > +
> > > + dev = &rte_rawdevs[dev_id];
> > > + if (dev->attached == RTE_RAWDEV_ATTACHED)
> > > + return dev;
> > > +
> > > + return NULL;
> > > +}
> > > +
> >
> > This seems simple enough and we have the same kind of helper in other
> > device class libraries.
> > But I would like to better understand the driver API that requires this.
> >
> This is being used in the new cnxk rvu_lf driver.
> https://patches.dpdk.org/project/dpdk/cover/20241008105415.1026962-1-gak...@marvell.com/
Hi David/Thomas,
Can this patch be merged in RC1, so that PMD patches can be rebased in
next-net-mrvl for RC2?
-Akhil
[PATCH v3 11/12] baseband/acc: rte free refactor
Refactor to explicitly set pointer to NULL after free to avoid double
free.
Signed-off-by: Hernan Vargas
---
drivers/baseband/acc/rte_acc100_pmd.c | 23 +++--
drivers/baseband/acc/rte_vrb_pmd.c| 48 +++
2 files changed, 39 insertions(+), 32 deletions(-)
diff --git a/drivers/baseband/acc/rte_acc100_pmd.c
b/drivers/baseband/acc/rte_acc100_pmd.c
index c82a0b6cc174..d33e42c8070b 100644
--- a/drivers/baseband/acc/rte_acc100_pmd.c
+++ b/drivers/baseband/acc/rte_acc100_pmd.c
@@ -564,6 +564,7 @@ acc100_setup_queues(struct rte_bbdev *dev, uint16_t
num_queues, int socket_id)
d->tail_ptrs = NULL;
free_sw_rings:
rte_free(d->sw_rings_base);
+ d->sw_rings_base = NULL;
d->sw_rings = NULL;
return ret;
@@ -593,6 +594,7 @@ acc100_intr_enable(struct rte_bbdev *dev)
"Couldn't enable interrupts for device:
%s",
dev->data->name);
rte_free(d->info_ring);
+ d->info_ring = NULL;
return ret;
}
ret = rte_intr_callback_register(dev->intr_handle,
@@ -602,6 +604,7 @@ acc100_intr_enable(struct rte_bbdev *dev)
"Couldn't register interrupt callback
for device: %s",
dev->data->name);
rte_free(d->info_ring);
+ d->info_ring = NULL;
return ret;
}
@@ -619,16 +622,15 @@ acc100_dev_close(struct rte_bbdev *dev)
{
struct acc_device *d = dev->data->dev_private;
acc100_check_ir(d);
- if (d->sw_rings_base != NULL) {
- rte_free(d->tail_ptrs);
- rte_free(d->info_ring);
- rte_free(d->sw_rings_base);
- rte_free(d->harq_layout);
- d->sw_rings_base = NULL;
- d->tail_ptrs = NULL;
- d->info_ring = NULL;
- d->harq_layout = NULL;
- }
+ rte_free(d->tail_ptrs);
+ rte_free(d->info_ring);
+ rte_free(d->sw_rings_base);
+ rte_free(d->harq_layout);
+ d->tail_ptrs = NULL;
+ d->info_ring = NULL;
+ d->sw_rings_base = NULL;
+ d->sw_rings = NULL;
+ d->harq_layout = NULL;
/* Ensure all in flight HW transactions are completed */
usleep(ACC_LONG_WAIT);
return 0;
@@ -4235,6 +4237,7 @@ poweron_cleanup(struct rte_bbdev *bbdev, struct
acc_device *d,
rte_bbdev_log(INFO, "Number of 5GUL engines %d", numEngines);
rte_free(d->sw_rings_base);
+ d->sw_rings_base = NULL;
usleep(ACC_LONG_WAIT);
}
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
b/drivers/baseband/acc/rte_vrb_pmd.c
index c0464d20c641..03df270af1cf 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -745,10 +745,13 @@ vrb_setup_queues(struct rte_bbdev *dev, uint16_t
num_queues, int socket_id)
free_sw_rings:
if (d->device_variant == VRB1_VARIANT) {
rte_free(d->sw_rings_base);
+ d->sw_rings_base = NULL;
d->sw_rings = NULL;
} else if (d->device_variant == VRB2_VARIANT) {
- for (i = 0; i <= RTE_BBDEV_OP_MLDTS; i++)
+ for (i = 0; i <= RTE_BBDEV_OP_MLDTS; i++) {
rte_free(d->sw_rings_array[i]);
+ d->sw_rings_array[i] = 0;
+ }
}
return ret;
@@ -786,6 +789,7 @@ vrb_intr_enable(struct rte_bbdev *dev)
"Couldn't enable interrupts for device:
%s",
dev->data->name);
rte_free(d->info_ring);
+ d->info_ring = NULL;
return ret;
}
ret = rte_intr_callback_register(dev->intr_handle,
@@ -795,6 +799,7 @@ vrb_intr_enable(struct rte_bbdev *dev)
"Couldn't register interrupt callback
for device: %s",
dev->data->name);
rte_free(d->info_ring);
+ d->info_ring = NULL;
return ret;
}
@@ -849,6 +854,7 @@ vrb_intr_enable(struct rte_bbdev *dev)
"Couldn't enable interrupts for device:
%s",
dev->data->name);
rte_free(d->info_ring);
+ d->info_ring = NULL;
return ret;
}
ret = rte_intr_callback_register(dev->intr_handle,
@@ -858,6 +864,7 @@ vrb_intr_enable(struct rte_bbdev *dev)
"Couldn't register interrupt callback
for device: %s",
dev->data->name);
r
[PATCH v3 10/12] baseband/acc: cosmetic changes
Cosmetic code changes.
No functional impact.
Signed-off-by: Hernan Vargas
---
drivers/baseband/acc/rte_acc100_pmd.c | 2 +-
drivers/baseband/acc/rte_vrb_pmd.c| 54 +--
2 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/drivers/baseband/acc/rte_acc100_pmd.c
b/drivers/baseband/acc/rte_acc100_pmd.c
index c690d1492ba3..c82a0b6cc174 100644
--- a/drivers/baseband/acc/rte_acc100_pmd.c
+++ b/drivers/baseband/acc/rte_acc100_pmd.c
@@ -4200,7 +4200,7 @@ poweron_cleanup(struct rte_bbdev *bbdev, struct
acc_device *d,
acc_reg_write(d, HWPfQmgrIngressAq + 0x100, enq_req.val);
usleep(ACC_LONG_WAIT * 100);
if (desc->req.word0 != 2)
- rte_bbdev_log(WARNING, "DMA Response %#"PRIx32,
desc->req.word0);
+ rte_bbdev_log(WARNING, "DMA Response %#"PRIx32"",
desc->req.word0);
}
/* Reset LDPC Cores */
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
b/drivers/baseband/acc/rte_vrb_pmd.c
index 42414823541e..c0464d20c641 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -957,6 +957,9 @@ vrb_queue_setup(struct rte_bbdev *dev, uint16_t queue_id,
struct acc_queue *q;
int32_t q_idx;
int ret;
+ union acc_dma_desc *desc = NULL;
+ unsigned int desc_idx, b_idx;
+ int fcw_len;
if (d == NULL) {
rte_bbdev_log(ERR, "Undefined device");
@@ -983,16 +986,33 @@ vrb_queue_setup(struct rte_bbdev *dev, uint16_t queue_id,
}
/* Prepare the Ring with default descriptor format. */
- union acc_dma_desc *desc = NULL;
- unsigned int desc_idx, b_idx;
- int fcw_len = (conf->op_type == RTE_BBDEV_OP_LDPC_ENC ?
- ACC_FCW_LE_BLEN : (conf->op_type ==
RTE_BBDEV_OP_TURBO_DEC ?
- ACC_FCW_TD_BLEN : (conf->op_type ==
RTE_BBDEV_OP_LDPC_DEC ?
- ACC_FCW_LD_BLEN : (conf->op_type == RTE_BBDEV_OP_FFT ?
- ACC_FCW_FFT_BLEN : ACC_FCW_MLDTS_BLEN;
-
- if ((q->d->device_variant == VRB2_VARIANT) && (conf->op_type ==
RTE_BBDEV_OP_FFT))
- fcw_len = ACC_FCW_FFT_BLEN_3;
+ switch (conf->op_type) {
+ case RTE_BBDEV_OP_LDPC_ENC:
+ fcw_len = ACC_FCW_LE_BLEN;
+ break;
+ case RTE_BBDEV_OP_LDPC_DEC:
+ fcw_len = ACC_FCW_LD_BLEN;
+ break;
+ case RTE_BBDEV_OP_TURBO_DEC:
+ fcw_len = ACC_FCW_TD_BLEN;
+ break;
+ case RTE_BBDEV_OP_TURBO_ENC:
+ fcw_len = ACC_FCW_TE_BLEN;
+ break;
+ case RTE_BBDEV_OP_FFT:
+ fcw_len = ACC_FCW_FFT_BLEN;
+ if (q->d->device_variant == VRB2_VARIANT)
+ fcw_len = ACC_FCW_FFT_BLEN_3;
+ break;
+ case RTE_BBDEV_OP_MLDTS:
+ fcw_len = ACC_FCW_MLDTS_BLEN;
+ break;
+ default:
+ /* NOT REACHED. */
+ fcw_len = 0;
+ rte_bbdev_log(ERR, "Unexpected error in %s using type %d",
__func__, conf->op_type);
+ break;
+ }
for (desc_idx = 0; desc_idx < d->sw_ring_max_depth; desc_idx++) {
desc = q->ring_addr + desc_idx;
@@ -1758,8 +1778,7 @@ vrb_fcw_ld_fill(struct rte_bbdev_dec_op *op, struct
acc_fcw_ld *fcw,
if (fcw->hcout_en > 0) {
parity_offset = (op->ldpc_dec.basegraph == 1 ? 20 : 8)
* op->ldpc_dec.z_c - op->ldpc_dec.n_filler;
- k0_p = (fcw->k0 > parity_offset) ?
- fcw->k0 - op->ldpc_dec.n_filler : fcw->k0;
+ k0_p = (fcw->k0 > parity_offset) ? fcw->k0 -
op->ldpc_dec.n_filler : fcw->k0;
ncb_p = fcw->ncb - op->ldpc_dec.n_filler;
l = k0_p + fcw->rm_e;
harq_out_length = (uint16_t) fcw->hcin_size0;
@@ -2001,16 +2020,15 @@ vrb_dma_desc_ld_fill(struct rte_bbdev_dec_op *op,
next_triplet++;
}
- if (check_bit(op->ldpc_dec.op_flags,
- RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE)) {
+ if (check_bit(op->ldpc_dec.op_flags,
RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE)) {
if (op->ldpc_dec.harq_combined_output.data == 0) {
rte_bbdev_log(ERR, "HARQ output is not defined");
return -1;
}
- /* Pruned size of the HARQ */
+ /* Pruned size of the HARQ. */
h_p_size = fcw->hcout_size0 + fcw->hcout_size1;
- /* Non-Pruned size of the HARQ */
+ /* Non-Pruned size of the HARQ. */
h_np_size = fcw->hcout_offset > 0 ?
fcw->hcout_offset + fcw->hcout_size1 :
h_p_size;
@@ -2584,7 +2602,6 @@ vrb_enqueue_ldpc_dec_one_op_cb(struct acc_queue *q
[PATCH v3 09/12] baseband/acc: reset ring data valid bit
Reset only the valid bit to keep info ring data notably for dumping. Signed-off-by: Hernan Vargas Reviewed-by: Maxime Coquelin --- drivers/baseband/acc/rte_vrb_pmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/baseband/acc/rte_vrb_pmd.c b/drivers/baseband/acc/rte_vrb_pmd.c index f7a120688f5a..42414823541e 100644 --- a/drivers/baseband/acc/rte_vrb_pmd.c +++ b/drivers/baseband/acc/rte_vrb_pmd.c @@ -412,7 +412,7 @@ vrb_check_ir(struct acc_device *acc_dev) rte_bbdev_log(WARNING, "InfoRing: ITR:%d Info:0x%x", int_nb, ring_data->detailed_info); /* Initialize Info Ring entry and move forward. */ - ring_data->val = 0; + ring_data->valid = 0; } info_ring_head++; ring_data = acc_dev->info_ring + (info_ring_head & ACC_INFO_RING_MASK); -- 2.37.1
[PATCH v3 12/12] baseband/acc: clean up of VRB1 capabilities
The interrupt support was defeatured on the VRB1 device. Signed-off-by: Hernan Vargas --- doc/guides/bbdevs/vrb1.rst | 3 --- drivers/baseband/acc/rte_vrb_pmd.c | 8 ++-- 2 files changed, 2 insertions(+), 9 deletions(-) diff --git a/doc/guides/bbdevs/vrb1.rst b/doc/guides/bbdevs/vrb1.rst index 36c1ac04b6d3..e450e0061fcb 100644 --- a/doc/guides/bbdevs/vrb1.rst +++ b/doc/guides/bbdevs/vrb1.rst @@ -33,7 +33,6 @@ These hardware blocks provide the following features exposed by the PMD: - FFT processing - Single Root I/O Virtualization (SR-IOV) with 16 Virtual Functions (VFs) per Physical Function (PF) - Maximum of 256 queues per VF -- Message Signaled Interrupts (MSIs) The Intel vRAN Boost v1.0 PMD supports the following bbdev capabilities: @@ -57,14 +56,12 @@ The Intel vRAN Boost v1.0 PMD supports the following bbdev capabilities: * For the turbo encode operation: - ``RTE_BBDEV_TURBO_CRC_24B_ATTACH``: set to attach CRC24B to CB(s). - ``RTE_BBDEV_TURBO_RATE_MATCH``: if set then do not do Rate Match bypass. - - ``RTE_BBDEV_TURBO_ENC_INTERRUPTS``: set for encoder dequeue interrupts. - ``RTE_BBDEV_TURBO_RV_INDEX_BYPASS``: set to bypass RV index. - ``RTE_BBDEV_TURBO_ENC_SCATTER_GATHER``: supports scatter-gather for input/output data. * For the turbo decode operation: - ``RTE_BBDEV_TURBO_CRC_TYPE_24B``: check CRC24B from CB(s). - ``RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE``: perform subblock de-interleave. - - ``RTE_BBDEV_TURBO_DEC_INTERRUPTS``: set for decoder dequeue interrupts. - ``RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN``: set if negative LLR input is supported. - ``RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP``: keep CRC24B bits appended while decoding. - ``RTE_BBDEV_TURBO_DEC_CRC_24B_DROP``: option to drop the code block CRC after decoding. diff --git a/drivers/baseband/acc/rte_vrb_pmd.c b/drivers/baseband/acc/rte_vrb_pmd.c index 03df270af1cf..0455320c2a50 100644 --- a/drivers/baseband/acc/rte_vrb_pmd.c +++ b/drivers/baseband/acc/rte_vrb_pmd.c @@ -1222,7 +1222,6 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct rte_bbdev_driver_info *dev_info) RTE_BBDEV_TURBO_HALF_ITERATION_EVEN | RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH | RTE_BBDEV_TURBO_EARLY_TERMINATION | - RTE_BBDEV_TURBO_DEC_INTERRUPTS | RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN | RTE_BBDEV_TURBO_MAP_DEC | RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP | @@ -1243,7 +1242,6 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct rte_bbdev_driver_info *dev_info) RTE_BBDEV_TURBO_CRC_24B_ATTACH | RTE_BBDEV_TURBO_RV_INDEX_BYPASS | RTE_BBDEV_TURBO_RATE_MATCH | - RTE_BBDEV_TURBO_ENC_INTERRUPTS | RTE_BBDEV_TURBO_ENC_SCATTER_GATHER, .num_buffers_src = RTE_BBDEV_TURBO_MAX_CODE_BLOCKS, @@ -1257,8 +1255,7 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct rte_bbdev_driver_info *dev_info) .capability_flags = RTE_BBDEV_LDPC_RATE_MATCH | RTE_BBDEV_LDPC_CRC_24B_ATTACH | - RTE_BBDEV_LDPC_INTERLEAVER_BYPASS | - RTE_BBDEV_LDPC_ENC_INTERRUPTS, + RTE_BBDEV_LDPC_INTERLEAVER_BYPASS, .num_buffers_src = RTE_BBDEV_LDPC_MAX_CODE_BLOCKS, .num_buffers_dst = @@ -1279,8 +1276,7 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct rte_bbdev_driver_info *dev_info) RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS | RTE_BBDEV_LDPC_DEC_SCATTER_GATHER | RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION | - RTE_BBDEV_LDPC_LLR_COMPRESSION | - RTE_BBDEV_LDPC_DEC_INTERRUPTS, + RTE_BBDEV_LDPC_LLR_COMPRESSION, .llr_size = 8, .llr_decimals = 1, .num_buffers_src = -- 2.37.1
[PATCH v3 08/12] baseband/acc: remove check on HARQ memory
Automatically reset HARQ memory to prevent errors and simplify usage.
In a way we can assume that the HARQ output operation will always
overwrite the buffer, so we can reset this from the driver to prevent
an error being reported when application fails to do this explicitly.
Signed-off-by: Hernan Vargas
Reviewed-by: Maxime Coquelin
---
drivers/baseband/acc/rte_vrb_pmd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
b/drivers/baseband/acc/rte_vrb_pmd.c
index 4d7535e9d99f..f7a120688f5a 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -2596,8 +2596,9 @@ vrb_enqueue_ldpc_dec_one_op_cb(struct acc_queue *q,
struct rte_bbdev_dec_op *op,
/* Hard output. */
mbuf_append(h_output_head, h_output, h_out_length);
if (op->ldpc_dec.harq_combined_output.length > 0) {
- /* Push the HARQ output into host memory. */
+ /* Push the HARQ output into host memory overwriting existing
data. */
struct rte_mbuf *hq_output_head, *hq_output;
+ op->ldpc_dec.harq_combined_output.data->data_len = 0;
hq_output_head = op->ldpc_dec.harq_combined_output.data;
hq_output = op->ldpc_dec.harq_combined_output.data;
hq_len = op->ldpc_dec.harq_combined_output.length;
--
2.37.1
[PATCH v3 07/12] baseband/acc: algorithm tuning for LDPC decoder
Reverting to MS1 version of the algorithm to improve MU1 fading conditions. Signed-off-by: Hernan Vargas Reviewed-by: Maxime Coquelin --- drivers/baseband/acc/rte_vrb_pmd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/baseband/acc/rte_vrb_pmd.c b/drivers/baseband/acc/rte_vrb_pmd.c index 519385e82ed3..4d7535e9d99f 100644 --- a/drivers/baseband/acc/rte_vrb_pmd.c +++ b/drivers/baseband/acc/rte_vrb_pmd.c @@ -1363,7 +1363,7 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct rte_bbdev_driver_info *dev_info) RTE_BBDEV_LDPC_SOFT_OUT_DEINTERLEAVER_BYPASS | RTE_BBDEV_LDPC_DEC_INTERRUPTS, .llr_size = 8, - .llr_decimals = 2, + .llr_decimals = 1, .num_buffers_src = RTE_BBDEV_LDPC_MAX_CODE_BLOCKS, .num_buffers_hard_out = @@ -1737,8 +1737,8 @@ vrb_fcw_ld_fill(struct rte_bbdev_dec_op *op, struct acc_fcw_ld *fcw, fcw->so_bypass_intlv = check_bit(op->ldpc_dec.op_flags, RTE_BBDEV_LDPC_SOFT_OUT_DEINTERLEAVER_BYPASS); fcw->so_bypass_rm = 0; - fcw->minsum_offset = 1; - fcw->dec_llrclip = 2; + fcw->minsum_offset = 0; + fcw->dec_llrclip = 0; } /* -- 2.37.1
RE: [PATCH v6 7/7] vhost: optimize memcpy routines when cc memcpy is used
> +#if defined(RTE_USE_CC_MEMCPY) && defined(RTE_ARCH_X86_64)
> +static __rte_always_inline void
> +pktcpy(void *restrict in_dst, const void *restrict in_src, size_t len)
> +{
A comment describing why batch_copy_elem.dst and src point to 16 byte aligned
data would be nice.
> + void *dst = __builtin_assume_aligned(in_dst, 16);
> + const void *src = __builtin_assume_aligned(in_src, 16);
> +
> + if (len <= 256) {
> + size_t left;
> +
> + for (left = len; left >= 32; left -= 32) {
> + memcpy(dst, src, 32);
> + dst = RTE_PTR_ADD(dst, 32);
> + src = RTE_PTR_ADD(src, 32);
> + }
> +
> + memcpy(dst, src, left);
> + } else
> + memcpy(dst, src, len);
> +}
> +#else
> +static __rte_always_inline void
> +pktcpy(void *dst, const void *src, size_t len)
> +{
> + rte_memcpy(dst, src, len);
> +}
> +#endif
> +
> static inline void
> do_data_copy_enqueue(struct virtio_net *dev, struct vhost_virtqueue
> *vq)
> __rte_shared_locks_required(&vq->iotlb_lock)
> @@ -240,7 +273,7 @@ do_data_copy_enqueue(struct virtio_net *dev, struct
> vhost_virtqueue *vq)
> int i;
>
> for (i = 0; i < count; i++) {
> - rte_memcpy(elem[i].dst, elem[i].src, elem[i].len);
> + pktcpy(elem[i].dst, elem[i].src, elem[i].len);
> vhost_log_cache_write_iova(dev, vq, elem[i].log_addr,
> elem[i].len);
> PRINT_PACKET(dev, (uintptr_t)elem[i].dst, elem[i].len, 0);
> @@ -257,7 +290,7 @@ do_data_copy_dequeue(struct vhost_virtqueue *vq)
> int i;
>
> for (i = 0; i < count; i++)
> - rte_memcpy(elem[i].dst, elem[i].src, elem[i].len);
> + pktcpy(elem[i].dst, elem[i].src, elem[i].len);
>
> vq->batch_copy_nb_elems = 0;
> }
> --
> 2.43.0
Anyway,
Acked-by: Morten Brørup
Re: [EXTERNAL] Re: [PATCH v6 0/2] devtools: add tracepoint check in checkpatch
On Wed, 9 Oct 2024 06:03:58 + Ankur Dwivedi wrote: > >> Please let me know if this patch series can be merged in DPDK or if there > >> are > >any comments. > > > >Not sure why the patch got ignored. > >Perhaps if check-tracepoint was run first against existing code; add to > >check- > >patch later. > > check-tracepoint reads a patch and checks if a newly added function in a > library has the trace in it or not. > For existing code trace can be added manually. Trace was added for existing > functions in 23.03 release. > > > >And the skip list is empty, is that right? > Yes. > If trace is not required for a new library function, the function name can be > added in skiplist. > The checkpatch will ignore trace check for that function. > > is all of existing cryptodev ethdev ... ok > >now? > > No, it's not completely ok. Few functions does not have trace added. > Majority have trace added. I wonder if a coccinelle script might be better for this. Rather than adding more checks to already annoying checkpatch.
[PATCH 4/5] net/ice: add option to download scheduler topology
The DDP package file being loaded at init time may contain an
alternative Tx Scheduler topology in it. Add driver option to load this
topology at init time.
Signed-off-by: Bruce Richardson
---
drivers/net/ice/base/ice_ddp.c | 18 +++---
drivers/net/ice/base/ice_ddp.h | 4 ++--
drivers/net/ice/ice_ethdev.c | 24 +++-
drivers/net/ice/ice_ethdev.h | 1 +
4 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ice/base/ice_ddp.c b/drivers/net/ice/base/ice_ddp.c
index 90aaa6b331..1462c2b7fe 100644
--- a/drivers/net/ice/base/ice_ddp.c
+++ b/drivers/net/ice/base/ice_ddp.c
@@ -1333,7 +1333,7 @@ ice_fill_hw_ptype(struct ice_hw *hw)
* ice_copy_and_init_pkg() instead of directly calling ice_init_pkg() in this
* case.
*/
-enum ice_ddp_state ice_init_pkg(struct ice_hw *hw, u8 *buf, u32 len)
+enum ice_ddp_state ice_init_pkg(struct ice_hw *hw, u8 *buf, u32 len, bool
load_sched)
{
bool already_loaded = false;
enum ice_ddp_state state;
@@ -1351,6 +1351,18 @@ enum ice_ddp_state ice_init_pkg(struct ice_hw *hw, u8
*buf, u32 len)
return state;
}
+ if (load_sched) {
+ enum ice_status res = ice_cfg_tx_topo(hw, buf, len);
+ if (res != ICE_SUCCESS) {
+ ice_debug(hw, ICE_DBG_INIT, "failed to apply sched
topology (err: %d)\n",
+ res);
+ return ICE_DDP_PKG_ERR;
+ }
+ ice_debug(hw, ICE_DBG_INIT, "Topology download successful,
reinitializing device\n");
+ ice_deinit_hw(hw);
+ ice_init_hw(hw);
+ }
+
/* initialize package info */
state = ice_init_pkg_info(hw, pkg);
if (state)
@@ -1423,7 +1435,7 @@ enum ice_ddp_state ice_init_pkg(struct ice_hw *hw, u8
*buf, u32 len)
* related routines.
*/
enum ice_ddp_state
-ice_copy_and_init_pkg(struct ice_hw *hw, const u8 *buf, u32 len)
+ice_copy_and_init_pkg(struct ice_hw *hw, const u8 *buf, u32 len, bool
load_sched)
{
enum ice_ddp_state state;
u8 *buf_copy;
@@ -1433,7 +1445,7 @@ ice_copy_and_init_pkg(struct ice_hw *hw, const u8 *buf,
u32 len)
buf_copy = (u8 *)ice_memdup(hw, buf, len, ICE_NONDMA_TO_NONDMA);
- state = ice_init_pkg(hw, buf_copy, len);
+ state = ice_init_pkg(hw, buf_copy, len, load_sched);
if (!ice_is_init_pkg_successful(state)) {
/* Free the copy, since we failed to initialize the package */
ice_free(hw, buf_copy);
diff --git a/drivers/net/ice/base/ice_ddp.h b/drivers/net/ice/base/ice_ddp.h
index 5512669f44..d79cdee13a 100644
--- a/drivers/net/ice/base/ice_ddp.h
+++ b/drivers/net/ice/base/ice_ddp.h
@@ -454,9 +454,9 @@ ice_pkg_enum_entry(struct ice_seg *ice_seg, struct
ice_pkg_enum *state,
void *
ice_pkg_enum_section(struct ice_seg *ice_seg, struct ice_pkg_enum *state,
u32 sect_type);
-enum ice_ddp_state ice_init_pkg(struct ice_hw *hw, u8 *buff, u32 len);
+enum ice_ddp_state ice_init_pkg(struct ice_hw *hw, u8 *buff, u32 len, bool
load_sched);
enum ice_ddp_state
-ice_copy_and_init_pkg(struct ice_hw *hw, const u8 *buf, u32 len);
+ice_copy_and_init_pkg(struct ice_hw *hw, const u8 *buf, u32 len, bool
load_sched);
bool ice_is_init_pkg_successful(enum ice_ddp_state state);
void ice_free_seg(struct ice_hw *hw);
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index db44f5c4fc..ea1ed4fb68 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -38,6 +38,7 @@
#define ICE_RX_LOW_LATENCY_ARG"rx_low_latency"
#define ICE_MBUF_CHECK_ARG "mbuf_check"
#define ICE_DDP_FILENAME "ddp_pkg_file"
+#define ICE_DDP_LOAD_SCHED"ddp_load_sched_topo"
#define ICE_CYCLECOUNTER_MASK 0xULL
@@ -55,6 +56,7 @@ static const char * const ice_valid_args[] = {
ICE_DEFAULT_MAC_DISABLE,
ICE_MBUF_CHECK_ARG,
ICE_DDP_FILENAME,
+ ICE_DDP_LOAD_SCHED,
NULL
};
@@ -1979,7 +1981,7 @@ int ice_load_pkg(struct ice_adapter *adapter, bool
use_dsn, uint64_t dsn)
load_fw:
PMD_INIT_LOG(DEBUG, "DDP package name: %s", pkg_file);
- err = ice_copy_and_init_pkg(hw, buf, bufsz);
+ err = ice_copy_and_init_pkg(hw, buf, bufsz,
adapter->devargs.ddp_load_sched);
if (!ice_is_init_pkg_successful(err)) {
PMD_INIT_LOG(ERR, "ice_copy_and_init_hw failed: %d", err);
free(buf);
@@ -2012,19 +2014,18 @@ static int
parse_bool(const char *key, const char *value, void *args)
{
int *i = (int *)args;
- char *end;
- int num;
- num = strtoul(value, &end, 10);
-
- if (num != 0 && num != 1) {
- PMD_DRV_LOG(WARNING, "invalid value:\"%s\" for key:\"%s\", "
- "value must be 0 or 1",
+ if (value == NULL || value[0] == '\0') {
+ PMD_DRV_LOG(WARNING, "key:\"%
[PATCH 3/5] net/ice: add option to choose DDP package file
The "Dynamic Device Personalization" package is loaded at initialization
time by the driver, but the specific package file loaded depends upon
what package file is found first by searching through a hard-coded list
of firmware paths. To enable greater control over the package loading,
we can add a device option to choose a specific DDP package file to
load.
Signed-off-by: Bruce Richardson
---
doc/guides/nics/ice.rst | 9 +
drivers/net/ice/ice_ethdev.c | 35 +++
drivers/net/ice/ice_ethdev.h | 1 +
3 files changed, 45 insertions(+)
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 986abb211f..13f4fa1772 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -136,6 +136,15 @@ Runtime Configuration
-a 80:00.0,default-mac-disable=1
+- ``DDP Package File``
+
+ Rather than have the driver search for the DDP package to load,
+ or to override what package is used,
+ the ``ddp_pkg_file`` option can be used to provide the path to a specific
package file.
+ For example::
+
+-a 80:00.0,ddp_pkg_file=/path/to/ice-version.pkg
+
- ``Protocol extraction for per queue``
Configure the RX queues to do protocol extraction into mbuf for protocol
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 61bff016be..db44f5c4fc 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -37,6 +37,7 @@
#define ICE_ONE_PPS_OUT_ARG "pps_out"
#define ICE_RX_LOW_LATENCY_ARG"rx_low_latency"
#define ICE_MBUF_CHECK_ARG "mbuf_check"
+#define ICE_DDP_FILENAME "ddp_pkg_file"
#define ICE_CYCLECOUNTER_MASK 0xULL
@@ -53,6 +54,7 @@ static const char * const ice_valid_args[] = {
ICE_RX_LOW_LATENCY_ARG,
ICE_DEFAULT_MAC_DISABLE,
ICE_MBUF_CHECK_ARG,
+ ICE_DDP_FILENAME,
NULL
};
@@ -693,6 +695,18 @@ handle_field_name_arg(__rte_unused const char *key, const
char *value,
return 0;
}
+static int
+handle_ddp_filename_arg(__rte_unused const char *key, const char *value, void
*name_args)
+{
+ const char **filename = name_args;
+ if (strlen(value) >= ICE_MAX_PKG_FILENAME_SIZE) {
+ PMD_DRV_LOG(ERR, "The DDP package filename is too long : '%s'",
value);
+ return -1;
+ }
+ *filename = strdup(value);
+ return 0;
+}
+
static void
ice_check_proto_xtr_support(struct ice_hw *hw)
{
@@ -1909,6 +1923,17 @@ int ice_load_pkg(struct ice_adapter *adapter, bool
use_dsn, uint64_t dsn)
size_t bufsz;
int err;
+ /* first read any explicitly referenced DDP file*/
+ if (adapter->devargs.ddp_filename != NULL) {
+ strlcpy(pkg_file, adapter->devargs.ddp_filename,
sizeof(pkg_file));
+ if (rte_firmware_read(pkg_file, &buf, &bufsz) == 0) {
+ goto load_fw;
+ } else {
+ PMD_INIT_LOG(ERR, "Cannot load DDP file: %s", pkg_file);
+ return -1;
+ }
+ }
+
memset(opt_ddp_filename, 0, ICE_MAX_PKG_FILENAME_SIZE);
snprintf(opt_ddp_filename, ICE_MAX_PKG_FILENAME_SIZE,
"ice-%016" PRIx64 ".pkg", dsn);
@@ -2256,6 +2281,13 @@ static int ice_parse_devargs(struct rte_eth_dev *dev)
ret = rte_kvargs_process(kvlist, ICE_RX_LOW_LATENCY_ARG,
&parse_bool, &ad->devargs.rx_low_latency);
+ if (ret)
+ goto bail;
+
+ ret = rte_kvargs_process(kvlist, ICE_DDP_FILENAME,
+&handle_ddp_filename_arg,
&ad->devargs.ddp_filename);
+ if (ret)
+ goto bail;
bail:
rte_kvargs_free(kvlist);
@@ -2729,6 +2761,8 @@ ice_dev_close(struct rte_eth_dev *dev)
ice_free_hw_tbls(hw);
rte_free(hw->port_info);
hw->port_info = NULL;
+ free((void *)(uintptr_t)ad->devargs.ddp_filename);
+ ad->devargs.ddp_filename = NULL;
ice_shutdown_all_ctrlq(hw, true);
rte_free(pf->proto_xtr);
pf->proto_xtr = NULL;
@@ -7047,6 +7081,7 @@ RTE_PMD_REGISTER_PARAM_STRING(net_ice,
ICE_PROTO_XTR_ARG
"=[queue:]"
ICE_SAFE_MODE_SUPPORT_ARG "=<0|1>"
ICE_DEFAULT_MAC_DISABLE "=<0|1>"
+ ICE_DDP_FILENAME "="
ICE_RX_LOW_LATENCY_ARG "=<0|1>");
RTE_LOG_REGISTER_SUFFIX(ice_logtype_init, init, NOTICE);
diff --git a/drivers/net/ice/ice_ethdev.h b/drivers/net/ice/ice_ethdev.h
index 8b644ed700..2781362d04 100644
--- a/drivers/net/ice/ice_ethdev.h
+++ b/drivers/net/ice/ice_ethdev.h
@@ -569,6 +569,7 @@ struct ice_devargs {
/* Name of the field. */
char xtr_field_name[RTE_MBUF_DYN_NAMESIZE];
uint64_t mbuf_check;
+ const char *ddp_filename;
};
/**
--
2.43.0
[PATCH 0/5] updates for net/ice driver
This patchset contains a set of updates for the ice driver, a number of which are in the area of the "rte_tm" APIs for Tx scheduling. These patches were previously submitted as part of a larger set[1], but separating them out here for easier review and merge ahead of the more substantial changes for scheduling in the last couple of patches in that set. [1] https://patches.dpdk.org/project/dpdk/list/?series=32758&state=* Bruce Richardson (5): net/ice: detect stopping a flow-director queue twice net/ice: improve Tx scheduler graph output net/ice: add option to choose DDP package file net/ice: add option to download scheduler topology net/ice: limit the number of queues to sched capabilities doc/guides/nics/ice.rst| 9 ++ drivers/net/ice/base/ice_ddp.c | 18 ++- drivers/net/ice/base/ice_ddp.h | 4 +- drivers/net/ice/ice_diagnose.c | 196 - drivers/net/ice/ice_ethdev.c | 84 +++--- drivers/net/ice/ice_ethdev.h | 2 + drivers/net/ice/ice_rxtx.c | 5 + 7 files changed, 172 insertions(+), 146 deletions(-) -- 2.43.0
RE: [PATCH v3 1/3] cryptodev: add asymmetric operational capability
> Subject: [PATCH v3 1/3] cryptodev: add asymmetric operational capability > > Asymmetric crypto algorithms such as SM2, EdDSA would need per op > capability and based on it, the input param to a crypto operation > is chosen wisely. > > Signed-off-by: Gowrishankar Muthukrishnan > --- > v3: > - Removed unused rte_crypto_sm2_op_capa enum value > RTE_CRYPTO_SM2_PKE_KDF. >HW that needs it can add this enum. > - Test and driver changes split from it and follows within same series. Series acked-by: Akhil Goyal Arek's ack taken from v2. Updated release notes Applied to dpdk-next-crypto Thanks.
RE: [PATCH 4/6] eal: add unit tests for atomic bitset operations
> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > Sent: Thursday, 12 September 2024 06.52 > > On Fri, Aug 09, 2024 at 10:14:38PM +0200, Mattias R??nnblom wrote: > > Extend bitset tests to cover the basic operation of the > > rte_bitset_atomic_*() family of functions. > > > > Signed-off-by: Mattias R??nnblom > > --- > > Tyler Retzlaff Fixing this, for the benefit of Patchwork... Acked-by: Tyler Retzlaff
Re: [PATCH v3 5/5] net/cxgbe: use rte macro instead of GCC attribute
On Wed, Mar 6, 2024 at 11:14 PM Tyler Retzlaff wrote: > > Use existing __rte_may_alias macro from rte_common.h instead of > directly using __attribute__((__may_alias__)). > > Signed-off-by: Tyler Retzlaff Reviewed-by: Morten Brørup Reviewed-by: Potnuri Bharat Teja Applied, thanks. -- David Marchand
[DPDK/core Bug 1385] rt_bitops.h fails to give implied atomicity guarantees
https://bugs.dpdk.org/show_bug.cgi?id=1385
David Marchand (david.march...@redhat.com) changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Assignee|dev@dpdk.org|mattias.ronnblom@ericsson.c
||om
Resolution|--- |FIXED
CC||david.march...@redhat.com
--- Comment #1 from David Marchand (david.march...@redhat.com) ---
Fixed with 471de107ae23 ("bitops: add new bit manipulation API").
--
You are receiving this mail because:
You are the assignee for the bug.
RE: [PATCH] cryptodev: remove unnecessary list end
> > From: Akhil Goyal [mailto:gak...@marvell.com]
> > Sent: Wednesday, 9 October 2024 13.25
> >
> > RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END and
> > RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END are not used anywhere and
> > mostly it do not fulfil any objective.
> > Rather it does not allow addition of new algorithms and
> > new padding type as it result in ABI breakage.
> > Hence, these are removed.
> >
> > Signed-off-by: Akhil Goyal
> > ---
> > lib/cryptodev/rte_crypto_asym.h | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h
> > index 39d3da3952..524753e2b2 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -119,8 +119,6 @@ enum rte_crypto_asym_xform_type {
> > * Performs Encrypt, Decrypt, Sign and Verify.
> > * Refer to rte_crypto_asym_op_type.
> > */
> > - RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > - /**< End of list */
> > };
> >
> > /**
> > @@ -168,7 +166,6 @@ enum rte_crypto_rsa_padding_type {
> > /**< RSA PKCS#1 OAEP padding scheme */
> > RTE_CRYPTO_RSA_PADDING_PSS,
> > /**< RSA PKCS#1 PSS padding scheme */
> > - RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
> > };
> >
> > /**
> > --
> > 2.25.1
>
> Acked-by: Morten Brørup
Applied to dpdk-next-crypto
Updated release notes
RE: [PATCH v1] examples/ipsec-secgw: free the actual mbuf pointer
> Subject: [PATCH v1] examples/ipsec-secgw: free the actual mbuf pointer > > In case of crypto event vector, the vector points to crypto op structure > in priv area and not actual mbuf. > Extract the mbuf pointer and pass these to rte_mbuf_free to free the > mbufs. > > Signed-off-by: Vidya Sagar Velumuri Applied to dpdk-next-crypto Thanks.
Re: [PATCH v4 0/6] refine argparse library
On Mon, 18 Mar 2024 11:18:32 + Chengwen Feng wrote: > I found a couple of issues when I revisited the argparse_autotest > output, so got this patchset. > > Chengwen Feng (6): > argparse: refine error message > argparse: remove dead code > argparse: replace flag enum with marco > argparse: fix argument flags operate as uint32 type > test/argparse: refine testcases > argparse: fix doc don't display two hyphens > > --- > v4: address Thomas's comment on 4/6 commit: > - remove unused macros TEST_ARGPARSE_FLAG_HAS_ARG_BITMASK and > TEST_ARGPARSE_FLAG_VAL_TYPE_BITMASK. > v3: > - address Thomas's comment on 4/6 comit. > - add commit: fix doc don't display two hyphens. > v2: address David Marchand's comment: > - replace flag enum with marco. > - replace flag's hardcode with macro in test_argparse.c. > > app/test/test_argparse.c | 65 +++- > doc/guides/prog_guide/argparse_lib.rst | 47 +++--- > lib/argparse/rte_argparse.c| 61 +- > lib/argparse/rte_argparse.h| 85 -- > 4 files changed, 127 insertions(+), 131 deletions(-) The verb refine is not usually used for edits to documents or software that probably is a translation issue. Series-acked-by: Stephen Hemminger
RE: [PATCH v6 1/6] cryptodev: add EDDSA asymmetric crypto algorithm
> > Subject: RE: [PATCH v6 1/6] cryptodev: add EDDSA asymmetric crypto algorithm > > > > > Acked-by: Arkadiusz Kusztal Series Applied to dpdk-next-crypto Thanks. Updated release notes and removed deprecation notices for EDDSA.
RE: [PATCH v2 2/2] cryptodev: move RSA padding information into xform
> Acked-by: Arek Kusztal > Series Acked-by: Akhil Goyal Applied to dpdk-next-crypto Updated release notes and removed associated deprecation notices. Thanks.
RE: [EXTERNAL] Re: [PATCH v1] Revert "doc: extension of crypto event callback announced"
> On Thu, 1 Aug 2024 13:06:07 +0530 > Srujana Challa wrote: > > > The previously planned update to the `rte_cryptodev_cb_fn` function > > prototype is being reverted. The introduction of the > > `rte_cryptodev_queue_pair_event_error_query` API provides a means for > > applications to retrieve the queue pair ID that encountered an error > > interrupt. This makes the addition of the `qp_id` parameter to the > > `rte_cryptodev_cb_fn` function unnecessary, and as such, the proposed > > extension is no longer required. > > > > Signed-off-by: Srujana Challa > > Acked-by: Stephen Hemminger Acked-by: Akhil Goyal Applied to dpdk-next-crypto Thanks.
Re: [PATCH v1 1/3] uapi: introduce kernel uAPI headers import
On Wed, 9 Oct 2024 10:58:03 +0200
Maxime Coquelin wrote:
> +fixup_includes()
> +{
> + local path=$1
> +
> + sed -i -E -e '
> + s/([[:space:](])(__user|__force|__iomem)[[:space:]]/\1/g
> + s/__attribute_const__([[:space:]]|$)/\1/g
> + s@^#include @@
> +
> s/(^|[^a-zA-Z0-9])__packed([^a-zA-Z0-9_]|$)/\1__attribute__((packed))\2/g
> + s/(^|[[:space:](])(inline|asm|volatile)([[:space:](]|$)/\1__\2__\3/g
> + s@#(ifndef|define|endif[[:space:]]*/[*])[[:space:]]*_UAPI@#\1 @
> + ' $path
> +
Rather than copy-pasting headers_install.sh, could you use it directly?
The copy/paste from GPL-2.0 concerns me.
And the potential upstream change as well.
RE: [PATCH v3 1/3] crypto/ipsec_mb: add SM3 algorithm support
> > -Original Message- > > From: Dooley, Brian > > Sent: Thursday, October 3, 2024 6:05 PM > > To: Ji, Kai ; De Lara Guarch, Pablo > > > > Cc: dev@dpdk.org; gak...@marvell.com; Dooley, Brian > > > > Subject: [PATCH v3 1/3] crypto/ipsec_mb: add SM3 algorithm support > > > > This patch introduces SM3 algorithm support to the AESNI_MB PMD. > > > > Signed-off-by: Brian Dooley > > Acked-by: Pablo de Lara Series applied to dpdk-next-crypto Thanks.
RE: [PATCH v2 2/2] cryptodev: move RSA padding information into xform
Hi Arek Any objections on this patch? > Subject: [PATCH v2 2/2] cryptodev: move RSA padding information into xform > > RSA padding information could be a xform entity rather than part of > crypto op, as it seems associated with hashing algorithm used for > the entire crypto session, where this algorithm is used in message > digest itself. Even in virtIO standard spec, this info is associated > in the asymmetric session creation. Hence, moving this info from > crypto op into xform structure. > > Signed-off-by: Gowrishankar Muthukrishnan
[RFC PATCH] build: automatically report minimum meson version
Add a script to buildtools to report the minimum meson version given in
our meson.build file. Then use this script in two ways:
1. in the .ci/linux-setup.sh script, use the auto-determined minimum
version to set up the CI, rather than hard-coding it.
2. in meson.build call the script to report the version. This serves as
a sanity check to ensure that any changes to meson.build file do not
break the script.
Signed-off-by: Bruce Richardson
---
.ci/linux-setup.sh | 6 +-
buildtools/get-min-meson-version.py | 26 ++
buildtools/meson.build | 5 +
3 files changed, 36 insertions(+), 1 deletion(-)
create mode 100755 buildtools/get-min-meson-version.py
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
index 975bf32144..e025ca0243 100755
--- a/.ci/linux-setup.sh
+++ b/.ci/linux-setup.sh
@@ -3,8 +3,12 @@
# Builds are run as root in containers, no need for sudo
[ "$(id -u)" != '0' ] || alias sudo=
+# determine minimum meson version
+ci_dir=$(dirname $(readlink -f $0))
+meson_ver=$(python3 $ci_dir/../buildtools/get-min-meson-version.py)
+
# need to install as 'root' since some of the unit tests won't run without it
-sudo python3 -m pip install --upgrade 'meson==0.53.2'
+sudo python3 -m pip install --upgrade "meson==$meson_ver"
# setup hugepages. error ignored because having hugepage is not mandatory.
cat /proc/meminfo
diff --git a/buildtools/get-min-meson-version.py
b/buildtools/get-min-meson-version.py
new file mode 100755
index 00..f0de8fdf2b
--- /dev/null
+++ b/buildtools/get-min-meson-version.py
@@ -0,0 +1,26 @@
+#! /usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2024 Intel Corporation
+
+import os
+import re
+import sys
+from os.path import dirname, realpath, join
+
+buildtools_path = dirname(realpath(__file__))
+basedir = dirname(buildtools_path)
+
+with open(join(basedir, "meson.build")) as f:
+for ln in f.readlines():
+if "meson_version" not in ln:
+continue
+
+ln = ln.strip()
+ver_match = re.search(r"meson_version:\s*'>=\s*([0-9\.]+)'", ln)
+if not ver_match:
+print(
+f"Meson version specifier not in recognised format: '{ln}'",
+file=sys.stderr,
+)
+sys.exit(1)
+print(ver_match.group(1), end="")
diff --git a/buildtools/meson.build b/buildtools/meson.build
index 3adf34e1a8..8b20ac0dd0 100644
--- a/buildtools/meson.build
+++ b/buildtools/meson.build
@@ -24,6 +24,11 @@ get_numa_count_cmd = py3 + files('get-numa-count.py')
get_test_suites_cmd = py3 + files('get-test-suites.py')
has_hugepages_cmd = py3 + files('has-hugepages.py')
cmdline_gen_cmd = py3 + files('dpdk-cmdline-gen.py')
+get_min_meson_version_cmd = py3 + files('get-min-meson-version.py')
+
+# check that we can correctly report minimum meson version
+min_ver = run_command(get_min_meson_version_cmd, check: true, capture: true)
+message('Minimum meson required version is ' + min_ver.stdout())
# install any build tools that end-users might want also
install_data([
--
2.43.0
RE: [PATCH v4 1/2] ipsec: allow stateless IPsec processing
Hi Konstantin, Can you ack this patch if everything is fine? > Subject: [PATCH v4 1/2] ipsec: allow stateless IPsec processing > > Introduce stateless packet preparation API for IPsec > processing. The new API would allow preparation of IPsec > packets without altering the internal state of an IPsec > session. > > For outbound IPsec processing, the change enables user to > provide sequence number to be used for the IPsec operation. > > Signed-off-by: Aakash Sasidharan <>
RE: [PATCH] test/security: skip IPsec post process for negative tests
> Subject: [PATCH] test/security: skip IPsec post process for negative tests > > Skips calling test_ipsec_post_process for negative inline IPsec tests > as received packet might not be valid for a negative case. > > Signed-off-by: Srujana Challa Acked-by: Akhil Goyal Applied to dpdk-next-crypto Thanks.
Re: [PATCH] bus/pci: don't open uio device in secondary process
On Wed, 9 Oct 2024 12:11:32 +0200
Konrad Sztyber wrote:
> On 10/7/24 19:49, Stephen Hemminger wrote:
> > On Wed, 28 Aug 2024 12:40:02 +0200
> > Konrad Sztyber wrote:
> >
> >> The uio_pci_generic driver clears the bus master bit when the device
> >> file is closed. So, when the secondary process terminates after probing
> >> a device, that device becomes unusable in the primary process.
> >>
> >> To avoid that, the device file is now opened only in the primary
> >> process. The commit that introduced this regression, 847d78fb95
> >> ("bus/pci: fix FD in secondary process"), only mentioned enabling access
> >> to config space from secondary process, which still works, as it doesn't
> >> rely on the device file.
> >>
> >> Fixes: 847d78fb95 ("bus/pci: fix FD in secondary process")
> >>
> >> Signed-off-by: Konrad Sztyber
> >
> > Wouldn't this break use of interrupts in the secondary process?
>
> Yes, it will. But I don't think we can support interrupts in the
> secondary process *and*, at the same time, keep the device usable in the
> primary process when secondary terminates. Maybe we could pass the fd
> via SCM_RIGHTS? But I don't know if that results in the same struct file
> being used by both processes.
That is what tap, and xdp are doing.
Re: [PATCH] doc: enhance the global log level documentation
On Wed, 26 Jun 2024 19:10:48 +0200 Ilya Maximets wrote: > On 6/26/24 17:09, David Marchand wrote: > > The current documentation is non intuitive in that the global log level > > can be understood as being a single knob controlling all components > > logs. > > On the contrary, all the global log level is for is to reduce verbosity > > globally. > > > > Remove examples of setting --log-level=8|debug, which is a noop. > > > > Cc: sta...@dpdk.org > > > > Signed-off-by: David Marchand > > --- Yes, the global log level pre-dates the introduction of component logs. The wording would be better if it was more precise. Something like: By default, all log messages enabled by a particular component are visible. But this may be too verbose. For example, to suppress all logs below warning level: /path/to-app --log-level=warning
Re: [PATCH v2 0/4] cfgfile: enhance error detecting
On Fri, 5 Jul 2024 09:31:11 + Chengwen Feng wrote: > When I was trying to debug a problem introduced by config.ini in > test-dma-perf, I found the cfgfile library should enhance error > detecting, so got this patchset. > > Chengwen Feng (4): > cfgfile: remove dead code > cfgfile: support verify name and value > cfgfile: verify add section and entry result > cfgfile: add strict parse flag > > --- > v2: replace unique name with strict parse flag which address Stephen's > comment. > > lib/cfgfile/rte_cfgfile.c | 70 +-- > lib/cfgfile/rte_cfgfile.h | 7 > 2 files changed, 59 insertions(+), 18 deletions(-) > This patch series is good, but a few things are needed still: - please add a functional test for this. - add a release note, since somebody might get be surprised. Also, would be good to put DPDK cfgfile parser on the Wikipedia page about ini files? This library could really use some work: - support variable length (not fixed size strings) - support multi-line - sub sections - faster access for large ini files (not linked list)
Re: [PATCH v6 0/2] Mac Filter Port to New DTS
Series-reviewed-by: Patrick Robb
Re: [PATCH v6 1/2] dts: add methods for setting mac and multicast addresses
Reviewed-by: Patrick Robb
Re: [PATCH v6 1/2] dts: add methods for setting mac and multicast addresses
Actually, I do have one thought. On Tue, Oct 8, 2024 at 4:45 PM Nicholas Pratte wrote: > +def set_mac_addr(self, port_id: int, mac_address: str, add: bool, > verify: bool = True) -> None: > +"""Add or remove a mac address on a given port's Allowlist. > + > +Args: > +port_id: The port ID the mac address is set on. > +mac_address: The mac address to be added to or removed from > the specified port. > +add: If :data:`True`, add the specified mac address. If > :data:`False`, remove specified > +mac address. > Should we replace "add" with "set" or an equivalent? Add=True means add. Add=false doesn't necessarily mean remove... set=True and set=False reads a little clearer for a function where the boolean is adding/removing something. But, it's just a thought - add is probably fine if you think that that's what reads best.
Re: [PATCH] net/mvpp2: fix build by removing newlines in logs
09/10/2024 11:18, Thomas Monjalon:
> After using RTE_LOG_LINE_PREFIX in MRVL_LOG macro,
> an assert was detecting some newlines in logs.
> After removing these superfluous newlines, the compilation passes.
>
> Fixes: 2b843cac232e ("drivers: use per line logging in helpers")
>
> Signed-off-by: Thomas Monjalon
It can be dropped as it has been already fixed by Jerin.
RE: [EXTERNAL] [PATCH v2] crypto/ipsec_mb: bump minimum IPsec MB version
> AESNI_MB SW PMDs increment Intel IPsec MB version to 1.4. > A minimum IPsec Multi-buffer version of 1.4 or greater is now required > for the 24.11 LTS release. > > Signed-off-by: Brian Dooley > Acked-by: Kai Ji > Acked-by: Pablo de Lara > --- > This patch relates to a deprecation notice sent in the 24.03 release. You should also remove the deprecation notice in this patch. > Intel IPsec MB minimum version being bumped to 1.4 for the 24.11 release. > https://patches.dpdk.org/project/dpdk/patch/20240314103731.3242086-2-brian.doo...@intel.com/ > > v2: > Added release note > Remove more IMB_VERSION checks > --- > doc/guides/cryptodevs/aesni_gcm.rst | 3 +- > doc/guides/cryptodevs/aesni_mb.rst | 3 +- > doc/guides/cryptodevs/chacha20_poly1305.rst | 3 +- > doc/guides/cryptodevs/kasumi.rst| 3 +- > doc/guides/cryptodevs/snow3g.rst| 3 +- > doc/guides/cryptodevs/zuc.rst | 3 +- > doc/guides/rel_notes/release_24_11.rst | 7 + > drivers/crypto/ipsec_mb/ipsec_mb_ops.c | 24 -- > drivers/crypto/ipsec_mb/meson.build | 2 +- > drivers/crypto/ipsec_mb/pmd_aesni_mb.c | 268 +--- > drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h | 9 - > 11 files changed, 23 insertions(+), 305 deletions(-) > > diff --git a/doc/guides/cryptodevs/aesni_gcm.rst > b/doc/guides/cryptodevs/aesni_gcm.rst > index 3af1486553..7592d33da2 100644 > --- a/doc/guides/cryptodevs/aesni_gcm.rst > +++ b/doc/guides/cryptodevs/aesni_gcm.rst > @@ -74,7 +74,8 @@ and the external crypto libraries supported by them: > DPDK version Crypto library version > = > 20.11 - 21.08 Multi-buffer library 0.53 - 1.3 > - 21.11+ Multi-buffer library 1.0 - 1.5 > + 21.11 - 24.07 Multi-buffer library 1.0 - 1.5 > + 24.11+ Multi-buffer library 1.4 - 1.5 > = > > Initialization > diff --git a/doc/guides/cryptodevs/aesni_mb.rst > b/doc/guides/cryptodevs/aesni_mb.rst > index 3c77d0f463..c2f6633ee6 100644 > --- a/doc/guides/cryptodevs/aesni_mb.rst > +++ b/doc/guides/cryptodevs/aesni_mb.rst > @@ -132,7 +132,8 @@ and the Multi-Buffer library version supported by them: > DPDK versionMulti-buffer library version > == > 20.11 - 21.08 0.53 - 1.3 > - 21.11+ 1.0 - 1.5 > + 21.11 - 24.07 1.0 - 1.5 > + 24.11+ 1.4 - 1.5 > == > > Initialization > diff --git a/doc/guides/cryptodevs/chacha20_poly1305.rst > b/doc/guides/cryptodevs/chacha20_poly1305.rst > index 44cff85918..b5a980b247 100644 > --- a/doc/guides/cryptodevs/chacha20_poly1305.rst > +++ b/doc/guides/cryptodevs/chacha20_poly1305.rst > @@ -66,7 +66,8 @@ and the external crypto libraries supported by them: > = > DPDK version Crypto library version > = > - 21.11+ Multi-buffer library 1.0-1.5 > + 21.11 - 24.07 Multi-buffer library 1.0 - 1.5 > + 24.11+ Multi-buffer library 1.4 - 1.5 > = > > Initialization > diff --git a/doc/guides/cryptodevs/kasumi.rst > b/doc/guides/cryptodevs/kasumi.rst > index 4070f025e1..b57f18b56f 100644 > --- a/doc/guides/cryptodevs/kasumi.rst > +++ b/doc/guides/cryptodevs/kasumi.rst > @@ -80,7 +80,8 @@ and the external crypto libraries supported by them: > DPDK version Crypto library version > = > 20.02 - 21.08 Multi-buffer library 0.53 - 1.3 > - 21.11+ Multi-buffer library 1.0 - 1.5 > + 21.11 - 24.07 Multi-buffer library 1.0 - 1.5 > + 24.11+ Multi-buffer library 1.4 - 1.5 > = > > Initialization > diff --git a/doc/guides/cryptodevs/snow3g.rst > b/doc/guides/cryptodevs/snow3g.rst > index 6eb8229fb5..fb4e0448ac 100644 > --- a/doc/guides/cryptodevs/snow3g.rst > +++ b/doc/guides/cryptodevs/snow3g.rst > @@ -89,7 +89,8 @@ and the external crypto libraries supported by them: > DPDK version Crypto library version > = > 20.02 - 21.08 Multi-buffer library 0.53 - 1.3 > - 21.11+ Multi-buffer library 1.0 - 1.5 > + 21.11 - 24.07 Multi-buffer library 1.0 - 1.5 > + 24.11+ Multi-buffer library 1.4 - 1.5 > = > > Initialization > diff --git a/doc/guides/cryptodevs/zuc.rst b/doc/guides/cryptodevs/zuc.rst > index 29fe6279aa..4615562246 100644 > --- a/doc/guides/cryptodevs/zuc.rst > +++ b/doc/guides/cryptodevs/zuc.rst > @@ -88,7 +88,8 @@ and the external crypto libraries supported by them: > DPDK version Crypto library version > = > 2
Re: [PATCH] bus/pci: don't open uio device in secondary process
On 10/7/24 19:49, Stephen Hemminger wrote:
On Wed, 28 Aug 2024 12:40:02 +0200
Konrad Sztyber wrote:
The uio_pci_generic driver clears the bus master bit when the device
file is closed. So, when the secondary process terminates after probing
a device, that device becomes unusable in the primary process.
To avoid that, the device file is now opened only in the primary
process. The commit that introduced this regression, 847d78fb95
("bus/pci: fix FD in secondary process"), only mentioned enabling access
to config space from secondary process, which still works, as it doesn't
rely on the device file.
Fixes: 847d78fb95 ("bus/pci: fix FD in secondary process")
Signed-off-by: Konrad Sztyber
Wouldn't this break use of interrupts in the secondary process?
Yes, it will. But I don't think we can support interrupts in the
secondary process *and*, at the same time, keep the device usable in the
primary process when secondary terminates. Maybe we could pass the fd
via SCM_RIGHTS? But I don't know if that results in the same struct file
being used by both processes.
The patch does need the minor fix of the comment style.
So resubmit
I already did, see:
https://inbox.dpdk.org/dev/20240829085724.270041-1-konrad.szty...@intel.com
RE: [PATCH v2 0/2] cryptodev: add queue pair priority
> Subject: [PATCH v2 0/2] cryptodev: add queue pair priority > > Changes in v2: > - added release notes and removed deprecation notice. > - removed gerrit-id > > Akhil Goyal (2): > cryptodev: add queue pair priority > app/crypto-perf: test queue pair priority > > app/test-crypto-perf/cperf_options.h | 3 +++ > app/test-crypto-perf/cperf_options_parsing.c | 20 ++ > app/test-crypto-perf/main.c | 6 +- > doc/guides/rel_notes/deprecation.rst | 3 --- > doc/guides/rel_notes/release_24_11.rst | 3 +++ > doc/guides/tools/cryptoperf.rst | 5 + > lib/cryptodev/rte_cryptodev.h| 22 > 7 files changed, 58 insertions(+), 4 deletions(-) > Series applied to dpdk-next-crypto
Re: [PATCH] cryptodev: remove unnecessary list end
On 09-10-2024 16:54, Akhil Goyal wrote:
RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END and
RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END are not used anywhere and
mostly it do not fulfil any objective.
Rather it does not allow addition of new algorithms and
new padding type as it result in ABI breakage.
Hence, these are removed.
Signed-off-by: Akhil Goyal
---
lib/cryptodev/rte_crypto_asym.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 39d3da3952..524753e2b2 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -119,8 +119,6 @@ enum rte_crypto_asym_xform_type {
* Performs Encrypt, Decrypt, Sign and Verify.
* Refer to rte_crypto_asym_op_type.
*/
- RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
- /**< End of list */
};
/**
@@ -168,7 +166,6 @@ enum rte_crypto_rsa_padding_type {
/**< RSA PKCS#1 OAEP padding scheme */
RTE_CRYPTO_RSA_PADDING_PSS,
/**< RSA PKCS#1 PSS padding scheme */
- RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
};
/**
Acked-by: Hemant Agrawal
[PATCH v5 4/4] app/test: add test sm2 C1/Kp test cases
This commit adds tests cases to be used when C1 or kP elliptic
curve points need to be computed.
Signed-off-by: Arkadiusz Kusztal
---
app/test/test_cryptodev_asym.c | 138 -
app/test/test_cryptodev_sm2_test_vectors.h | 112 ++-
2 files changed, 246 insertions(+), 4 deletions(-)
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index f0b5d38543..6fc7e87c1f 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -2635,6 +2635,8 @@ test_sm2_sign(void)
asym_op->sm2.k.data = input_params.k.data;
asym_op->sm2.k.length = input_params.k.length;
}
+ asym_op->sm2.k.data = input_params.k.data;
+ asym_op->sm2.k.length = input_params.k.length;
/* Init out buf */
asym_op->sm2.r.data = output_buf_r;
@@ -3184,7 +3186,7 @@ static int send_one(void)
ticks++;
if (ticks >= DEQ_TIMEOUT) {
RTE_LOG(ERR, USER1,
- "line %u FAILED: Cannot dequeue the crypto op
on device %d",
+ "line %u FAILED: Cannot dequeue the crypto op
on device, timeout %d",
__LINE__, params->valid_devs[0]);
return TEST_FAILED;
}
@@ -3489,6 +3491,132 @@ kat_rsa_decrypt_crt(const void *data)
return 0;
}
+static int
+test_sm2_partial_encryption(const void *data)
+{
+ struct rte_crypto_asym_xform xform = { 0 };
+ const uint8_t dev_id = params->valid_devs[0];
+ const struct crypto_testsuite_sm2_params *test_vector = data;
+ uint8_t result_C1_x1[TEST_DATA_SIZE] = { 0 };
+ uint8_t result_C1_y1[TEST_DATA_SIZE] = { 0 };
+ uint8_t result_kP_x1[TEST_DATA_SIZE] = { 0 };
+ uint8_t result_kP_y1[TEST_DATA_SIZE] = { 0 };
+ struct rte_cryptodev_asym_capability_idx idx;
+ const struct rte_cryptodev_asymmetric_xform_capability *capa;
+
+ idx.type = RTE_CRYPTO_ASYM_XFORM_SM2;
+ capa = rte_cryptodev_asym_capability_get(dev_id, &idx);
+ if (capa == NULL)
+ return TEST_SKIPPED;
+ if (!rte_cryptodev_asym_xform_capability_check_opcap(capa,
+ RTE_CRYPTO_ASYM_OP_ENCRYPT, RTE_CRYPTO_SM2_PARTIAL)) {
+ return TEST_SKIPPED;
+ }
+
+ xform.xform_type = RTE_CRYPTO_ASYM_XFORM_SM2;
+ xform.ec.curve_id = RTE_CRYPTO_EC_GROUP_SM2;
+ xform.ec.q = test_vector->pubkey;
+ self->op->asym->sm2.op_type = RTE_CRYPTO_ASYM_OP_ENCRYPT;
+ self->op->asym->sm2.k = test_vector->k;
+ if (rte_cryptodev_asym_session_create(dev_id, &xform,
+ params->session_mpool, &self->sess) < 0) {
+ RTE_LOG(ERR, USER1, "line %u FAILED: Session creation failed",
+ __LINE__);
+ return TEST_FAILED;
+ }
+ rte_crypto_op_attach_asym_session(self->op, self->sess);
+
+ self->op->asym->sm2.C1.x.data = result_C1_x1;
+ self->op->asym->sm2.C1.y.data = result_C1_y1;
+ self->op->asym->sm2.kP.x.data = result_kP_x1;
+ self->op->asym->sm2.kP.y.data = result_kP_y1;
+ TEST_ASSERT_SUCCESS(send_one(),
+ "Failed to process crypto op");
+
+ debug_hexdump(stdout, "C1[x]", self->op->asym->sm2.C1.x.data,
+ self->op->asym->sm2.C1.x.length);
+ debug_hexdump(stdout, "C1[y]", self->op->asym->sm2.C1.y.data,
+ self->op->asym->sm2.C1.y.length);
+ debug_hexdump(stdout, "kP[x]", self->op->asym->sm2.kP.x.data,
+ self->op->asym->sm2.kP.x.length);
+ debug_hexdump(stdout, "kP[y]", self->op->asym->sm2.kP.y.data,
+ self->op->asym->sm2.kP.y.length);
+
+ TEST_ASSERT_BUFFERS_ARE_EQUAL(test_vector->C1.x.data,
+ self->op->asym->sm2.C1.x.data,
+ test_vector->C1.x.length,
+ "Incorrect value of C1[x]\n");
+ TEST_ASSERT_BUFFERS_ARE_EQUAL(test_vector->C1.y.data,
+ self->op->asym->sm2.C1.y.data,
+ test_vector->C1.y.length,
+ "Incorrect value of C1[y]\n");
+ TEST_ASSERT_BUFFERS_ARE_EQUAL(test_vector->kP.x.data,
+ self->op->asym->sm2.kP.x.data,
+ test_vector->kP.x.length,
+ "Incorrect value of kP[x]\n");
+ TEST_ASSERT_BUFFERS_ARE_EQUAL(test_vector->kP.y.data,
+ self->op->asym->sm2.kP.y.data,
+ test_vector->kP.y.length,
+ "Incorrect value of kP[y]\n");
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_sm2_partial_decryption(const void *data)
+{
+ struct rte_crypto_asym_xform xform = {};
+ const uint8_t dev_id = params->valid_devs[0];
+ const struct crypto_testsuite_sm2_params *test_vector = data;
+ uint8_t result_kP_x1[TEST_DATA_SIZE] = { 0 };
+ uint8_t result_kP_y1[TEST_DATA_SIZE] = { 0 };
+ struct rte_
[PATCH v5 2/4] cryptodev: add ec points to sm2 op
In the case when PMD cannot support the full process of the SM2,
but elliptic curve computation only, additional fields
are needed to handle such a case.
Points C1, kP therefore were added to the SM2 crypto operation struct.
Signed-off-by: Arkadiusz Kusztal
---
lib/cryptodev/rte_crypto_asym.h | 53 ++---
1 file changed, 39 insertions(+), 14 deletions(-)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 2af6a307f6..65b1a081b1 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -607,6 +607,8 @@ enum rte_crypto_sm2_op_capa {
/**< Random number generator supported in SM2 ops. */
RTE_CRYPTO_SM2_PH,
/**< Prehash message before crypto op. */
+ RTE_CRYPTO_SM2_PARTIAL,
+ /**< Calculate elliptic curve points only. */
};
/**
@@ -634,20 +636,43 @@ struct rte_crypto_sm2_op_param {
* will be overwritten by the PMD with the decrypted length.
*/
- rte_crypto_param cipher;
- /**<
-* Pointer to input data
-* - to be decrypted for SM2 private decrypt.
-*
-* Pointer to output data
-* - for SM2 public encrypt.
-* In this case the underlying array should have been allocated
-* with enough memory to hold ciphertext output (at least X bytes
-* for prime field curve of N bytes and for message M bytes,
-* where X = (C1 || C2 || C3) and computed based on SM2 RFC as
-* C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
-* be overwritten by the PMD with the encrypted length.
-*/
+ union {
+ rte_crypto_param cipher;
+ /**<
+* Pointer to input data
+* - to be decrypted for SM2 private decrypt.
+*
+* Pointer to output data
+* - for SM2 public encrypt.
+* In this case the underlying array should have been allocated
+* with enough memory to hold ciphertext output (at least X
bytes
+* for prime field curve of N bytes and for message M bytes,
+* where X = (C1 || C2 || C3) and computed based on SM2 RFC as
+* C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
+* be overwritten by the PMD with the encrypted length.
+*/
+ struct {
+ struct rte_crypto_ec_point C1;
+ /**<
+* This field is used only when PMD does not support
the full
+* process of the SM2 encryption/decryption, but the
elliptic
+* curve part only.
+*
+* In the case of encryption, it is an output - point
C1 = (x1,y1).
+* In the case of decryption, if is an input - point C1
= (x1,y1)
+*
+*/
+ struct rte_crypto_ec_point kP;
+ /**<
+* This field is used only when PMD does not support
the full
+* process of the SM2 encryption/decryption, but the
elliptic
+* curve part only.
+*
+* It is an output in the encryption case, it is a point
+* [k]P = (x2,y2)
+*/
+ };
+ };
rte_crypto_uint id;
/**< The SM2 id used by signer and verifier. */
--
2.13.6
[PATCH v5 3/4] crypto/qat: add sm2 encryption/decryption function
This commit adds SM2 elliptic curve based asymmetric
encryption and decryption to the Intel QuickAssist
Technology PMD.
Signed-off-by: Arkadiusz Kusztal
---
doc/guides/cryptodevs/features/qat.ini | 1 +
doc/guides/rel_notes/release_24_11.rst | 4 +
drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h | 3 +
drivers/common/qat/qat_adf/qat_pke.h| 20
drivers/crypto/qat/qat_asym.c | 140 +++-
5 files changed, 162 insertions(+), 6 deletions(-)
diff --git a/doc/guides/cryptodevs/features/qat.ini
b/doc/guides/cryptodevs/features/qat.ini
index f41d29158f..219dd1e011 100644
--- a/doc/guides/cryptodevs/features/qat.ini
+++ b/doc/guides/cryptodevs/features/qat.ini
@@ -71,6 +71,7 @@ ZUC EIA3 = Y
AES CMAC (128) = Y
SM3 = Y
SM3 HMAC = Y
+SM2 = Y
;
; Supported AEAD algorithms of the 'qat' crypto driver.
diff --git a/doc/guides/rel_notes/release_24_11.rst
b/doc/guides/rel_notes/release_24_11.rst
index e0a9aa55a1..e56824310b 100644
--- a/doc/guides/rel_notes/release_24_11.rst
+++ b/doc/guides/rel_notes/release_24_11.rst
@@ -67,6 +67,10 @@ New Features
The new statistics are useful for debugging and profiling.
+* **Updated the QuickAssist Technology (QAT) Crypto PMD.**
+
+ * Added SM2 encryption and decryption algorithms.
+
Removed Items
-
diff --git a/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
b/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
index 630c6e1a9b..aa49612ca1 100644
--- a/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
+++ b/drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
@@ -1542,6 +1542,9 @@ icp_qat_fw_mmp_ecdsa_verify_gfp_521_input::in in @endlink
* @li no output parameters
*/
+#define PKE_ECSM2_ENCRYPTION 0x25221720
+#define PKE_ECSM2_DECRYPTION 0x201716e6
+
#define PKE_LIVENESS 0x0001
/**< Functionality ID for PKE_LIVENESS
* @li 0 input parameter(s)
diff --git a/drivers/common/qat/qat_adf/qat_pke.h
b/drivers/common/qat/qat_adf/qat_pke.h
index f88932a275..ac051e965d 100644
--- a/drivers/common/qat/qat_adf/qat_pke.h
+++ b/drivers/common/qat/qat_adf/qat_pke.h
@@ -334,4 +334,24 @@ get_sm2_ecdsa_verify_function(void)
return qat_function;
}
+static struct qat_asym_function
+get_sm2_encryption_function(void)
+{
+ struct qat_asym_function qat_function = {
+ PKE_ECSM2_ENCRYPTION, 32
+ };
+
+ return qat_function;
+}
+
+static struct qat_asym_function
+get_sm2_decryption_function(void)
+{
+ struct qat_asym_function qat_function = {
+ PKE_ECSM2_DECRYPTION, 32
+ };
+
+ return qat_function;
+}
+
#endif
diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
index e43884e69b..3ce48a1486 100644
--- a/drivers/crypto/qat/qat_asym.c
+++ b/drivers/crypto/qat/qat_asym.c
@@ -932,6 +932,15 @@ sm2_ecdsa_sign_set_input(struct icp_qat_fw_pke_request
*qat_req,
qat_req->input_param_count = 3;
qat_req->output_param_count = 2;
+ HEXDUMP("SM2 K test", asym_op->sm2.k.data,
+ cookie->alg_bytesize);
+ HEXDUMP("SM2 K", cookie->input_array[0],
+ cookie->alg_bytesize);
+ HEXDUMP("SM2 msg", cookie->input_array[1],
+ cookie->alg_bytesize);
+ HEXDUMP("SM2 pkey", cookie->input_array[2],
+ cookie->alg_bytesize);
+
return RTE_CRYPTO_OP_STATUS_SUCCESS;
}
@@ -983,6 +992,114 @@ sm2_ecdsa_sign_collect(struct rte_crypto_asym_op *asym_op,
}
static int
+sm2_encryption_set_input(struct icp_qat_fw_pke_request *qat_req,
+ struct qat_asym_op_cookie *cookie,
+ const struct rte_crypto_asym_op *asym_op,
+ const struct rte_crypto_asym_xform *xform)
+{
+ const struct qat_asym_function qat_function =
+ get_sm2_encryption_function();
+ const uint32_t qat_func_alignsize =
+ qat_function.bytesize;
+
+ SET_PKE_LN(asym_op->sm2.k, qat_func_alignsize, 0);
+ SET_PKE_LN(xform->ec.q.x, qat_func_alignsize, 1);
+ SET_PKE_LN(xform->ec.q.y, qat_func_alignsize, 2);
+
+ cookie->alg_bytesize = qat_function.bytesize;
+ cookie->qat_func_alignsize = qat_function.bytesize;
+ qat_req->pke_hdr.cd_pars.func_id = qat_function.func_id;
+ qat_req->input_param_count = 3;
+ qat_req->output_param_count = 4;
+
+ HEXDUMP("SM2 K", cookie->input_array[0],
+ qat_func_alignsize);
+ HEXDUMP("SM2 Q.x", cookie->input_array[1],
+ qat_func_alignsize);
+ HEXDUMP("SM2 Q.y", cookie->input_array[2],
+ qat_func_alignsize);
+
+ return RTE_CRYPTO_OP_STATUS_SUCCESS;
+}
+
+static uint8_t
+sm2_encryption_collect(struct rte_crypto_asym_op *asym_op,
+ const struct qat_asym_op_cookie *cookie)
+{
+ uint32_t alg_bytesize = cookie->alg_bytesize;
+
+ rte_memcpy(asym_op->sm2.C1.x.data, cookie->output_array[0],
alg_bytesize);
+ rte_memcpy(asym_op->sm2.C1.y.data
RE: [PATCH v2 1/3] net: add thread-safe crc api
> -Original Message-
> From: Ferruh Yigit
> Sent: Wednesday, October 9, 2024 3:03 AM
> To: Kusztal, ArkadiuszX ; Marchand, David
>
> Cc: dev@dpdk.org; Ji, Kai ; Dooley, Brian
>
> Subject: Re: [PATCH v2 1/3] net: add thread-safe crc api
>
> On 10/8/2024 9:51 PM, Kusztal, ArkadiuszX wrote:
> > Hi Ferruh,
> > Thanks for the review, comments inline,
> >
> >> -Original Message-
> >> From: Ferruh Yigit
> >> Sent: Tuesday, October 8, 2024 5:43 AM
> >> To: Kusztal, ArkadiuszX ; Marchand,
> >> David
> >> Cc: dev@dpdk.org; Ji, Kai ; Dooley, Brian
> >>
> >> Subject: Re: [PATCH v2 1/3] net: add thread-safe crc api
> >>
> >> On 10/1/2024 7:11 PM, Arkadiusz Kusztal wrote:
> >>> The current net CRC API is not thread-safe, this patch solves this
> >>> by adding another, thread-safe API functions.
> >>> This API is also safe to use across multiple processes, yet with
> >>> limitations on max-simd-bitwidth, which will be checked only by the
> >>> process that created the CRC context; all other processes will use
> >>> the same CRC function when used with the same CRC context.
> >>> It is an undefined behavior when process binaries are compiled with
> >>> different SIMD capabilities when the same CRC context is used.
> >>>
> >>> Signed-off-by: Arkadiusz Kusztal
> >>
> >> <...>
> >>
> >>> +static struct
> >>> +{
> >>> + uint32_t (*f[RTE_NET_CRC_REQS])
> >>> + (const uint8_t *data, uint32_t data_len);
> >>>
> >>
> >> It increases readability to typedef function pointers.
> >
> > Agree, though this typedef would be used here only, that’s why I left it
> > out.
> > But I can add it then.
> >
> >>
> >>
> >>> +} handlers[RTE_NET_CRC_AVX512 + 1];
> >>>
> >>> -/**
> >>> - * Reflect the bits about the middle
> >>> - *
> >>> - * @param val
> >>> - * value to be reflected
> >>> - *
> >>> - * @return
> >>> - * reflected value
> >>> - */
> >>> -static uint32_t
> >>> +static inline uint32_t
> >>>
> >>
> >> Does changing to 'inline' required, as function is static compiler
> >> can do the same.
> >
> > True, though it may be more readable sometimes.
> > Of course there is no way that in O3 these functions would not be inlined by
> the compiler, regardless if the inline hint is present or not.
> >
> >>
> >>> reflect_32bits(uint32_t val)
> >>> {
> >>> uint32_t i, res = 0;
> >>> @@ -99,26 +43,7 @@ reflect_32bits(uint32_t val)
> >>> return res;
> >>> }
> >>>
> >>> -static void
> >>> -crc32_eth_init_lut(uint32_t poly,
> >>> - uint32_t *lut)
> >>> -{
> >>> - uint32_t i, j;
> >>> -
> >>> - for (i = 0; i < CRC_LUT_SIZE; i++) {
> >>> - uint32_t crc = reflect_32bits(i);
> >>> -
> >>> - for (j = 0; j < 8; j++) {
> >>> - if (crc & 0x8000L)
> >>> - crc = (crc << 1) ^ poly;
> >>> - else
> >>> - crc <<= 1;
> >>> - }
> >>> - lut[i] = reflect_32bits(crc);
> >>> - }
> >>> -}
> >>> -
> >>> -static __rte_always_inline uint32_t
> >>> +static inline uint32_t
> >>>
> >>
> >> Why not forcing inline anymore?
> >> Are these inline changes related to the thread-safety?
> >
> > O3 will inline it anyway, and with always_inline it will be inline even in
> > debug
> mode. I just see no reason forcing it upon the compiler.
> >
> >>
> >>> crc32_eth_calc_lut(const uint8_t *data,
> >>> uint32_t data_len,
> >>> uint32_t crc,
> >>> @@ -130,20 +55,9 @@ crc32_eth_calc_lut(const uint8_t *data,
> >>> return crc;
> >>> }
> >>>
> >>> -static void
> >>> -rte_net_crc_scalar_init(void)
> >>> -{
> >>> - /* 32-bit crc init */
> >>> - crc32_eth_init_lut(CRC32_ETH_POLYNOMIAL, crc32_eth_lut);
> >>> -
> >>> - /* 16-bit CRC init */
> >>> - crc32_eth_init_lut(CRC16_CCITT_POLYNOMIAL << 16, crc16_ccitt_lut);
> >>> -}
> >>> -
> >>> static inline uint32_t
> >>> -rte_crc16_ccitt_handler(const uint8_t *data, uint32_t data_len)
> >>> +crc16_ccitt(const uint8_t *data, uint32_t data_len)
> >>> {
> >>> - /* return 16-bit CRC value */
> >>>
> >>
> >> Why not keep comments? Are they wrong?
> >
> > Functions names are very self-explanatory, that’s why I dropped comments. I
> can add comments if needed.
> >
>
> I am for restricting changes to the target of the patch which is making CRC
> calculation thread safe, unless code changes invalidates the comments, lets
> keep them. Same goes with inline related modifications.
>
> >>
> >> <...>
> >>
> >>> +static void
> >>> +crc_scalar_init(void)
> >>> +{
> >>> + crc32_eth_init_lut(CRC32_ETH_POLYNOMIAL, crc32_eth_lut);
> >>> + crc32_eth_init_lut(CRC16_CCITT_POLYNOMIAL << 16, crc16_ccitt_lut);
> >>> +
> >>> + handlers[RTE_NET_CRC_SCALAR].f[RTE_NET_CRC16_CCITT] =
> >> crc16_ccitt;
> >>> + handlers[RTE_NET_CRC_SCALAR].f[RTE_NET_CRC32_ETH] = crc32_eth;
> >>>
> >>
> >> +1 to remove global handlers pointer and add context,
> >>
> >> But current handlers array content is static, it can be set when
> >> defined, instead of functions.
> >
> > Can do it for scalars, but for SIMD there is this runtime c
Re: [PATCH] Increasing ci meson version to .57
On Wed, Oct 9, 2024 at 5:43 AM Stephen Hemminger wrote: > > On Tue, 8 Oct 2024 15:25:43 -0400 > Patrick Robb wrote: > > > There is a proposed increase in the minimum meson version to .57 > > This patch aligns the linux setup ci script with this change. > > > > Signed-off-by: Patrick Robb > > I wonder if we shouldn't push it to something later. > Debian stable is using 1.0.1 and testing is up to 1.5.2 > > 0.57.0 was released on Feb 14,2021 > 1.0.0 was released on Dec 23, 2022 > > So getting a release that was more recent makes sense. > The users stuck on enterprise distro's are going to have to resort > to pip anyway to get a new version. Tyler reported an issue for Windows with meson > 0.57. https://inbox.dpdk.org/dev/zvuouizqidee6...@bricha3-mobl1.ger.corp.intel.com/ -- David Marchand
[PATCH v3 1/5] graph: add feature arc support
add feature arc to allow dynamic steering of packets across graph nodes
based on protocol features enabled on incoming or outgoing interface
Signed-off-by: Nitin Saxena
---
doc/guides/rel_notes/release_24_11.rst | 10 +
lib/graph/graph_feature_arc.c| 1223 ++
lib/graph/meson.build|2 +
lib/graph/rte_graph_feature_arc.h| 431
lib/graph/rte_graph_feature_arc_worker.h | 674
lib/graph/version.map| 20 +
6 files changed, 2360 insertions(+)
create mode 100644 lib/graph/graph_feature_arc.c
create mode 100644 lib/graph/rte_graph_feature_arc.h
create mode 100644 lib/graph/rte_graph_feature_arc_worker.h
diff --git a/doc/guides/rel_notes/release_24_11.rst
b/doc/guides/rel_notes/release_24_11.rst
index e0a9aa55a1..d6d64518e0 100644
--- a/doc/guides/rel_notes/release_24_11.rst
+++ b/doc/guides/rel_notes/release_24_11.rst
@@ -67,6 +67,16 @@ New Features
The new statistics are useful for debugging and profiling.
+* **Added feature arc abstraction in graph library.**
+
+ Feature arc abstraction helps ``rte_graph`` based applications to steer
+ packets across different node path(s) based on the features (or protocols)
+ enabled on interfaces. Different feature node paths can be enabled/disabled
+ at runtime on some or on all interfaces. This abstraction also help
+ applications to hook their ``custom nodes`` in standard DPDK node paths
+ without any code changes in the later.
+
+ * Added ``ip4-output`` feature arc processing in ``ip4_rewrite`` node.
Removed Items
-
diff --git a/lib/graph/graph_feature_arc.c b/lib/graph/graph_feature_arc.c
new file mode 100644
index 00..ff99f7b26a
--- /dev/null
+++ b/lib/graph/graph_feature_arc.c
@@ -0,0 +1,1223 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2024 Marvell International Ltd.
+ */
+
+#include "graph_private.h"
+#include
+#include
+
+#define ARC_PASSIVE_LIST(arc) (arc->active_feature_list ^ 0x1)
+
+#define rte_graph_uint_cast(x) ((unsigned int)x)
+#define feat_dbg graph_dbg
+
+static rte_graph_feature_arc_main_t *__rte_graph_feature_arc_main;
+
+/* Make sure fast path cache line is compact */
+_Static_assert((offsetof(struct rte_graph_feature_arc, slow_path_variables)
+ - offsetof(struct rte_graph_feature_arc, fast_path_variables))
+ <= RTE_CACHE_LINE_SIZE,
+ "Fast path feature arc variables exceed cache line size");
+
+#define connect_graph_nodes(node1, node2, edge, arc_name) \
+ __connect_graph_nodes(node1, node2, edge, arc_name, __LINE__)
+
+#define FEAT_COND_ERR(cond, fmt, ...) \
+ do { \
+ if (cond) \
+ graph_err(fmt, ##__VA_ARGS__); \
+ } while (0)
+
+/*
+ * lookup feature name and get control path node_list as well as feature index
+ * at which it is inserted
+ */
+static int
+feature_lookup(struct rte_graph_feature_arc *arc, const char *feat_name,
+ struct rte_graph_feature_node_list **ffinfo, uint32_t *slot)
+{
+ struct rte_graph_feature_node_list *finfo = NULL;
+ const char *name;
+ uint32_t fi = 0;
+
+ if (!feat_name)
+ return -1;
+
+ if (slot)
+ *slot = UINT32_MAX;
+
+ STAILQ_FOREACH(finfo, &arc->all_features, next_feature) {
+ RTE_VERIFY(finfo->feature_arc == arc);
+ name = rte_node_id_to_name(finfo->feature_node->id);
+ if (!strncmp(name, feat_name, strlen(name))) {
+ if (ffinfo)
+ *ffinfo = finfo;
+ if (slot)
+ *slot = fi;
+ return 0;
+ }
+ fi++;
+ }
+ return -1;
+}
+
+/* Lookup used only during rte_graph_feature_add() */
+static int
+feature_add_lookup(struct rte_graph_feature_arc *arc, const char *feat_name,
+ struct rte_graph_feature_node_list **ffinfo, uint32_t *slot)
+{
+ struct rte_graph_feature_node_list *finfo = NULL;
+ const char *name;
+ uint32_t fi = 0;
+
+ if (!feat_name)
+ return -1;
+
+ if (slot)
+ *slot = 0;
+
+ STAILQ_FOREACH(finfo, &arc->all_features, next_feature) {
+ RTE_VERIFY(finfo->feature_arc == arc);
+ name = rte_node_id_to_name(finfo->feature_node->id);
+ if (!strncmp(name, feat_name, strlen(name))) {
+ if (ffinfo)
+ *ffinfo = finfo;
+ if (slot)
+ *slot = fi;
+ return 0;
+ }
+ /* Update slot where new feature can be added */
+ if (slot)
+
[PATCH v3 2/5] graph: add feature arc option in graph create
Added option in graph create to call feature-specific process node
functions. This removes extra overhead for checking feature arc status
in nodes where application is not using feature arc processing
Signed-off-by: Pavan Nikhilesh
Signed-off-by: Nitin Saxena
---
doc/guides/rel_notes/release_24_11.rst | 3 +++
lib/graph/graph.c | 1 +
lib/graph/graph_populate.c | 7 ++-
lib/graph/graph_private.h | 3 +++
lib/graph/node.c | 2 ++
lib/graph/rte_graph.h | 3 +++
6 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_24_11.rst
b/doc/guides/rel_notes/release_24_11.rst
index d6d64518e0..5195badf54 100644
--- a/doc/guides/rel_notes/release_24_11.rst
+++ b/doc/guides/rel_notes/release_24_11.rst
@@ -122,6 +122,9 @@ ABI Changes
Also, make sure to start the actual text at the margin.
===
+* graph: Added new `feature_arc_enable` parameter in `struct rte_graph_param`
to
+ allow `rte_graph_walk()` call `feat_arc_proc` node callback function, if it
+ is provided in node registration
Known Issues
diff --git a/lib/graph/graph.c b/lib/graph/graph.c
index d5b8c9f918..b0ad3a83ae 100644
--- a/lib/graph/graph.c
+++ b/lib/graph/graph.c
@@ -455,6 +455,7 @@ rte_graph_create(const char *name, struct rte_graph_param
*prm)
graph->parent_id = RTE_GRAPH_ID_INVALID;
graph->lcore_id = RTE_MAX_LCORE;
graph->num_pkt_to_capture = prm->num_pkt_to_capture;
+ graph->feature_arc_enabled = prm->feature_arc_enable;
if (prm->pcap_filename)
rte_strscpy(graph->pcap_filename, prm->pcap_filename,
RTE_GRAPH_PCAP_FILE_SZ);
diff --git a/lib/graph/graph_populate.c b/lib/graph/graph_populate.c
index ed596a7711..5d8aa7b903 100644
--- a/lib/graph/graph_populate.c
+++ b/lib/graph/graph_populate.c
@@ -79,8 +79,13 @@ graph_nodes_populate(struct graph *_graph)
if (graph_pcap_is_enable()) {
node->process = graph_pcap_dispatch;
node->original_process = graph_node->node->process;
- } else
+ if (_graph->feature_arc_enabled &&
graph_node->node->feat_arc_proc)
+ node->original_process =
graph_node->node->feat_arc_proc;
+ } else {
node->process = graph_node->node->process;
+ if (_graph->feature_arc_enabled &&
graph_node->node->feat_arc_proc)
+ node->process = graph_node->node->feat_arc_proc;
+ }
memcpy(node->name, graph_node->node->name, RTE_GRAPH_NAMESIZE);
pid = graph_node->node->parent_id;
if (pid != RTE_NODE_ID_INVALID) { /* Cloned node */
diff --git a/lib/graph/graph_private.h b/lib/graph/graph_private.h
index d557d55f2d..58ba0abeff 100644
--- a/lib/graph/graph_private.h
+++ b/lib/graph/graph_private.h
@@ -56,6 +56,7 @@ struct node {
unsigned int lcore_id;
/**< Node runs on the Lcore ID used for mcore dispatch model. */
rte_node_process_t process; /**< Node process function. */
+ rte_node_process_t feat_arc_proc; /**< Node feature-arch process
function. */
rte_node_init_t init; /**< Node init function. */
rte_node_fini_t fini; /**< Node fini function. */
rte_node_t id;/**< Allocated identifier for the node. */
@@ -126,6 +127,8 @@ struct graph {
/**< Number of packets to be captured per core. */
char pcap_filename[RTE_GRAPH_PCAP_FILE_SZ];
/**< pcap file name/path. */
+ uint8_t feature_arc_enabled;
+ /**< Graph feature arc. */
STAILQ_HEAD(gnode_list, graph_node) node_list;
/**< Nodes in a graph. */
};
diff --git a/lib/graph/node.c b/lib/graph/node.c
index 99a9622779..d8fd273543 100644
--- a/lib/graph/node.c
+++ b/lib/graph/node.c
@@ -90,6 +90,7 @@ __rte_node_register(const struct rte_node_register *reg)
goto free;
node->flags = reg->flags;
node->process = reg->process;
+ node->feat_arc_proc = reg->feat_arc_proc;
node->init = reg->init;
node->fini = reg->fini;
node->nb_edges = reg->nb_edges;
@@ -137,6 +138,7 @@ node_clone(struct node *node, const char *name)
/* Clone the source node */
reg->flags = node->flags;
reg->process = node->process;
+ reg->feat_arc_proc = node->feat_arc_proc;
reg->init = node->init;
reg->fini = node->fini;
reg->nb_edges = node->nb_edges;
diff --git a/lib/graph/rte_graph.h b/lib/graph/rte_graph.h
index ecfec2068a..1a3bd7e1ba 100644
--- a/lib/graph/rte_graph.h
+++ b/lib/graph/rte_graph.h
@@ -172,6 +172,8 @@ struct rte_graph_param {
uint32_t mp_capacity; /**< Capacity of memory pool for
dispatch model. */
}
[PATCH v3 0/5] add feature arc in rte_graph
Feature arc represents an ordered list of features/protocols at a given networking layer. It is a high level abstraction to connect various rte_graph nodes, as feature nodes, and allow packets steering across these nodes in a generic manner. Features (or feature nodes) are nodes which handles partial or complete handling of a protocol in fast path. Like ipv4-rewrite node, which adds rewrite data to an outgoing IPv4 packet. However in above example, outgoing interface(say "eth0") may have outbound IPsec policy enabled, hence packets must be steered from ipv4-rewrite node to ipsec-outbound-policy node for outbound IPsec policy lookup. On the other hand, packets routed to another interface (eth1) will not be sent to ipsec-outbound-policy node as IPsec feature is disabled on eth1. Feature-arc allows rte_graph applications to manage such constraints easily Feature arc abstraction allows rte_graph based application to 1. Seamlessly steer packets across feature nodes based on whether feature is enabled or disabled on an interface. Features enabled on one interface may not be enabled on another interface with in a same feature arc. 2. Allow enabling/disabling of features on an interface at runtime, so that if a feature is disabled, packets associated with that interface won't be steered to corresponding feature node. 3. Provides mechanism to hook custom/user-defined nodes to a feature node and allow packet steering from feature node to custom node without changing former's fast path function 4. Allow expressing features in a particular sequential order so that packets are steered in an ordered way across nodes in fast path. For eg: if IPsec and IPv4 features are enabled on an ingress interface, packets must be sent to IPsec inbound policy node first and then to ipv4 lookup node. This patch series adds feature arc library in rte_graph and also adds "ipv4-output" feature arc handling in "ipv4-rewrite" node. Changes in v3: - rte_graph_feature_arc_t typedef from uint64_t to uintptr_t to fix compilation on 32-bit machine - Updated images in .png format - Added ABI change section in release notes - Fixed DPDK CI failures Changes in v2: - Added unit tests for feature arc - Fixed issues found in testing - Added new public APIs rte_graph_feature_arc_feature_to_node(), rte_graph_feature_arc_feature_to_name(), rte_graph_feature_arc_num_features() - Added programming guide for feature arc - Added release notes for feature arc Nitin Saxena (5): graph: add feature arc support graph: add feature arc option in graph create graph: add IPv4 output feature arc test/graph_feature_arc: add functional tests docs: add programming guide for feature arc app/test/meson.build|1 + app/test/test_graph_feature_arc.c | 1410 +++ doc/guides/prog_guide/graph_lib.rst | 288 doc/guides/prog_guide/img/feature_arc-1.png | Bin 0 -> 61532 bytes doc/guides/prog_guide/img/feature_arc-2.png | Bin 0 -> 155806 bytes doc/guides/prog_guide/img/feature_arc-3.png | Bin 0 -> 143697 bytes doc/guides/rel_notes/release_24_11.rst | 13 + lib/graph/graph.c |1 + lib/graph/graph_feature_arc.c | 1223 lib/graph/graph_populate.c |7 +- lib/graph/graph_private.h |3 + lib/graph/meson.build |2 + lib/graph/node.c|2 + lib/graph/rte_graph.h |3 + lib/graph/rte_graph_feature_arc.h | 431 ++ lib/graph/rte_graph_feature_arc_worker.h| 674 + lib/graph/version.map | 20 + lib/node/ip4_rewrite.c | 476 +-- lib/node/ip4_rewrite_priv.h | 15 +- lib/node/node_private.h | 20 +- lib/node/rte_node_ip4_api.h |3 + 21 files changed, 4494 insertions(+), 98 deletions(-) create mode 100644 app/test/test_graph_feature_arc.c create mode 100644 doc/guides/prog_guide/img/feature_arc-1.png create mode 100644 doc/guides/prog_guide/img/feature_arc-2.png create mode 100644 doc/guides/prog_guide/img/feature_arc-3.png create mode 100644 lib/graph/graph_feature_arc.c create mode 100644 lib/graph/rte_graph_feature_arc.h create mode 100644 lib/graph/rte_graph_feature_arc_worker.h -- 2.43.0
