[PATCH] net/vmxnet3: Don't enable rx queue interrupts on FreeBSD
Commit 29a1c9107bb disabled interrupts on FreeBSD for the vmxnet3 driver
as they are not supported. Rx queue interrupts were missed by this
change, don't attempt to enable them on FreeBSD.
Without this change applications enabling interrupts encounter an
immediate abort on FreeBSD.
Signed-off-by: Tom Jones
---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 2707b25148..8b12967fa2 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -1938,9 +1938,11 @@ vmxnet3_dev_rx_queue_intr_enable(struct rte_eth_dev
*dev, uint16_t queue_id)
{
struct vmxnet3_hw *hw = dev->data->dev_private;
+#ifndef RTE_EXEC_ENV_FREEBSD
vmxnet3_enable_intr(hw,
rte_intr_vec_list_index_get(dev->intr_handle,
queue_id));
+#endif
return 0;
}
--
2.43.0
Re: [PATCH] graph: expose node context as pointers
On Wed, Mar 20, 2024 at 11:02 PM Robin Jarry wrote:
>
> In some cases, the node context data is used to store two pointers
> because the data is larger than the reserved 16 bytes. Having to define
> intermediate structures just to be able to cast is tedious. Add two
> pointers that take the same space than ctx.
>
> Signed-off-by: Robin Jarry
> ---
> lib/graph/rte_graph_worker_common.h | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/lib/graph/rte_graph_worker_common.h
> b/lib/graph/rte_graph_worker_common.h
> index 36d864e2c14e..a7fcdf4893ea 100644
> --- a/lib/graph/rte_graph_worker_common.h
> +++ b/lib/graph/rte_graph_worker_common.h
> @@ -112,7 +112,14 @@ struct __rte_cache_aligned rte_node {
> };
> /* Fast path area */
> #define RTE_NODE_CTX_SZ 16
> - alignas(RTE_CACHE_LINE_SIZE) uint8_t ctx[RTE_NODE_CTX_SZ]; /**< Node
> Context. */
> + alignas(RTE_CACHE_LINE_SIZE) union {
> + uint8_t ctx[RTE_NODE_CTX_SZ];
> + /* Convenience aliases to store pointers without complex
> casting. */
1) Use _extension_ to not break this on windows build. See rte_mbuf.
2) Also add static assert to make sure the following struct is not
greater than RTE_NODE_CTX_SZ. To avoid accidentally adding something
in the future.
> + struct {
> + void *ctx_ptr;
> + void *ctx_ptr2;
> + };
> + }; /**< Node Context. */
> uint16_t size; /**< Total number of objects available. */
> uint16_t idx; /**< Number of objects used. */
> rte_graph_off_t off;/**< Offset of node in the graph reel. */
> --
> 2.44.0
>
Re: [PATCH 0/3] support setting lanes
21/03/2024 03:02, huangdengdui: > > On 2024/3/20 20:31, Ferruh Yigit wrote: > > On 3/18/2024 9:26 PM, Damodharam Ammepalli wrote: > >> On Mon, Mar 18, 2024 at 7:56 AM Thomas Monjalon > >> wrote: > >>> > >>> 12/03/2024 08:52, Dengdui Huang: > Some speeds can be achieved with different number of lanes. For example, > 100Gbps can be achieved using two lanes of 50Gbps or four lanes of > 25Gbps. > When use different lanes, the port cannot be up. > >>> > >>> I'm not sure what you are referring to. > >>> I suppose it is not PCI lanes. > >>> Please could you link to an explanation of how a port is split in lanes? > >>> Which hardware does this? > >>> > >> This is a snapshot of 100Gb that the latest BCM576xx supports. > >> 100Gb (NRZ: 25G per lane, 4 lanes) link speed > >> 100Gb (PAM4-56: 50G per lane, 2 lanes) link speed > >> 100Gb (PAM4-112: 100G per lane, 1 lane) link speed > >> > >> Let the user feed in lanes=< integer value> and the NIC driver decides > >> the matching combination speed x lanes that works. In future if a new speed > >> is implemented with more than 8 lanes, there wouldn't be a need > >> to touch this speed command. Using separate lane command would > >> be a better alternative to support already shipped products and only new > >> drivers would consider this lanes configuration, if applicable. > >> > > > > As far as I understand, lane is related to the physical layer of the > > NIC, there are multiple copies of transmitter, receiver, modulator HW > > block and each set called as a 'lane' and multiple lanes work together > > to achieve desired speed. (please correct me if this is wrong). > > > > Why not just configuring the speed is not enough? Why user needs to know > > the detail and configuration of the lanes? > > Will it work if driver/device configure the "speed x lane" internally > > for the requested speed? > > > > Is there a benefit to force specific lane count for a specific speed > > (like power optimization, just a wild guess)? > > > > > > And +1 for auto-negotiation if possible. > > As you said above,，multiple lanes work together to achieve desired speed. > For example, the following solutions can be used to implement 100G: > 1、Combines four 25G lanes > 2、Combines two 50G lanes > 3、A single 100G lane > > It is assumed that two ports are interconnected and the two ports support > the foregoing three solutions. But, we just configured the speed to 100G and > one port uses four 25G lanes by default and the other port uses two 50G lanes > by default, the port cannot be up. In this case, we need to configure the > two ports to use the same solutions (for example, uses two 50G lanes) > so that the ports can be up. Why this config is not OK? How do we know? Really I have a very bad feeling about this feature.
Re: [PATCH v3] dmadev: fix structure alignment
21/03/2024 02:25, Ma, WenwuX:
> Hi, Thomas
>
> From: Thomas Monjalon
> > 20/03/2024 08:23, Wenwu Ma:
> > > The structure rte_dma_dev needs to be aligned to the cache line, but
> > > the return value of malloc may not be aligned to the cache line. When
> > > we use memset to clear the rte_dma_dev object, it may cause a
> > > segmentation fault in clang-x86-platform.
> > >
> > > This is because clang uses the "vmovaps" assembly instruction for
> > > memset, which requires that the operands (rte_dma_dev objects) must
> > > aligned on a 16-byte boundary or a general-protection exception (#GP)
> > > is generated.
> > >
> > > Therefore, either additional memory is applied for re-alignment, or
> > > the rte_dma_dev object does not require cache line alignment. The
> > > patch chooses the former option to fix the issue.
> > >
> > > Fixes: b36970f2e13e ("dmadev: introduce DMA device library")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Wenwu Ma
> > [..]
> > > - size = dma_devices_max * sizeof(struct rte_dma_dev);
> > > - rte_dma_devices = malloc(size);
> > > - if (rte_dma_devices == NULL)
> > > + /* The dma device object is expected to align cacheline, but
> > > + * the return value of malloc may not be aligned to the cache line.
> > > + * Therefore, extra memory is applied for realignment.
> > > + * note: We do not call posix_memalign/aligned_alloc because it is
> > > + * version dependent on libc.
> > > + */
> > > + size = dma_devices_max * sizeof(struct rte_dma_dev) +
> > > + RTE_CACHE_LINE_SIZE;
> > > + ptr = malloc(size);
> > > + if (ptr == NULL)
> > > return -ENOMEM;
> > > - memset(rte_dma_devices, 0, size);
> > > + memset(ptr, 0, size);
> > > +
> > > + rte_dma_devices = RTE_PTR_ALIGN(ptr, RTE_CACHE_LINE_SIZE);
> >
> > Why not using aligned_alloc()?
> > https://en.cppreference.com/w/c/memory/aligned_alloc
> >
> >
> because it is version dependent on libc.
Which libc is required?
[PATCH v3] app/test: fix rsa tests in qat suite
This commit fixes following issues in the QAT testsuite for
the RSA algorithm:
1) Incorrectly set keys in the internal functions are now
set in the calling function.
2) Camel case functions were changed to the snake case.
Fixes: 9b5465867fb8 ("test/crypto: add RSA none padding cases")
Cc: sta...@dpdk.org
Signed-off-by: Arkadiusz Kusztal
---
v2:
- removed camel case
v3:
- changed commit description
app/test/test_cryptodev_asym.c | 102 ++---
app/test/test_cryptodev_rsa_test_vectors.h | 2 +-
2 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 17daf734e8..2c745a7f7c 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -3292,11 +3292,8 @@ modular_multiplicative_inverse(const void *test_data)
arg.qt.coef.data = coef; \
arg.qt.coef.length = vector->coef.len
-typedef void (*rsa_key_init_t)(struct rte_crypto_asym_xform *,
- const struct rsa_test_data_2 *);
-
static int
-RSA_Encrypt(const struct rsa_test_data_2 *vector, uint8_t *cipher_buf)
+rsa_encrypt(const struct rsa_test_data_2 *vector, uint8_t *cipher_buf)
{
self->result_op = NULL;
/* Compute encryption on the test vector */
@@ -3314,7 +3311,7 @@ RSA_Encrypt(const struct rsa_test_data_2 *vector, uint8_t
*cipher_buf)
}
static int
-RSA_Decrypt(const struct rsa_test_data_2 *vector, uint8_t *plaintext,
+rsa_decrypt(const struct rsa_test_data_2 *vector, uint8_t *plaintext,
const int use_op)
{
uint8_t cipher[TEST_DATA_SIZE] = { 0 };
@@ -3335,41 +3332,14 @@ RSA_Decrypt(const struct rsa_test_data_2 *vector,
uint8_t *plaintext,
return 0;
}
-static void
-RSA_key_init_Exp(struct rte_crypto_asym_xform *xform,
- const struct rsa_test_data_2 *vector)
-{
- SET_RSA_PARAM(xform->rsa, vector, n);
- SET_RSA_PARAM(xform->rsa, vector, e);
- SET_RSA_PARAM(xform->rsa, vector, d);
- xform->rsa.key_type = RTE_RSA_KEY_TYPE_EXP;
-}
-
-static void
-RSA_key_init_CRT(struct rte_crypto_asym_xform *xform,
- const struct rsa_test_data_2 *vector)
-{
- SET_RSA_PARAM(xform->rsa, vector, n);
- SET_RSA_PARAM(xform->rsa, vector, e);
- SET_RSA_PARAM_QT(xform->rsa, vector, p);
- SET_RSA_PARAM_QT(xform->rsa, vector, q);
- SET_RSA_PARAM_QT(xform->rsa, vector, dP);
- SET_RSA_PARAM_QT(xform->rsa, vector, dQ);
- SET_RSA_PARAM_QT(xform->rsa, vector, qInv);
- xform->rsa.key_type = RTE_RSA_KEY_TYPE_QT;
-}
-
static int
-RSA_Init_Session(const struct rsa_test_data_2 *vector,
- rsa_key_init_t key_init)
+rsa_init_session(struct rte_crypto_asym_xform *xform)
{
const uint8_t dev_id = params->valid_devs[0];
struct rte_cryptodev_info dev_info;
- struct rte_crypto_asym_xform xform = { };
int ret = 0;
- key_init(&xform, vector);
- xform.xform_type = RTE_CRYPTO_ASYM_XFORM_RSA;
+ xform->xform_type = RTE_CRYPTO_ASYM_XFORM_RSA;
rte_cryptodev_info_get(dev_id, &dev_info);
if (!(dev_info.feature_flags & RTE_CRYPTODEV_FF_RSA_PRIV_OP_KEY_QT)) {
@@ -3377,7 +3347,7 @@ RSA_Init_Session(const struct rsa_test_data_2 *vector,
"Device doesn't support decrypt op with quintuple key
type. Test skipped\n");
return TEST_SKIPPED;
}
- ret = rte_cryptodev_asym_session_create(dev_id, &xform,
+ ret = rte_cryptodev_asym_session_create(dev_id, xform,
params->session_mpool, &self->sess);
if (ret < 0) {
RTE_LOG(ERR, USER1,
@@ -3388,17 +3358,23 @@ RSA_Init_Session(const struct rsa_test_data_2 *vector,
}
static int
-KAT_RSA_Encrypt(const void *data)
+kat_rsa_encrypt(const void *data)
{
uint8_t cipher_buf[TEST_DATA_SIZE] = {0};
const struct rsa_test_data_2 *vector = data;
- int ret = RSA_Init_Session(vector, RSA_key_init_Exp);
+ struct rte_crypto_asym_xform xform = { };
+
+ SET_RSA_PARAM(xform.rsa, vector, n);
+ SET_RSA_PARAM(xform.rsa, vector, e);
+ SET_RSA_PARAM(xform.rsa, vector, d);
+ xform.rsa.key_type = RTE_RSA_KEY_TYPE_EXP;
+ int ret = rsa_init_session(&xform);
if (ret) {
RTE_LOG(ERR, USER1, "Failed to init session for RSA\n");
return ret;
}
- TEST_ASSERT_SUCCESS(RSA_Encrypt(vector, cipher_buf),
+ TEST_ASSERT_SUCCESS(rsa_encrypt(vector, cipher_buf),
"RSA: Failed to encrypt");
TEST_ASSERT_BUFFERS_ARE_EQUAL(vector->cipher.data,
self->result_op->asym->rsa.cipher.data,
@@ -3408,17 +3384,26 @@ KAT_RSA_Encrypt(const void *data)
}
static int
-KAT_RSA_Encrypt_CRT(const void *data)
+kat_rsa_encrypt_crt(const void *data)
{
uint8_t cipher_buf[TEST_DATA_SIZE] = {0};
const struct rsa_test_data_2 *vector = data;
- int ret = RSA_Init_Session(vector, RSA_key_in
RE: [PATCH v3] app/test: fix rsa tests in qat suite
> -Original Message-
> From: Kusztal, ArkadiuszX
> Sent: Thursday, March 21, 2024 8:35 AM
> To: dev@dpdk.org
> Cc: gak...@marvell.com; Power, Ciara ; Kusztal,
> ArkadiuszX ; sta...@dpdk.org
> Subject: [PATCH v3] app/test: fix rsa tests in qat suite
>
> This commit fixes following issues in the QAT testsuite for the RSA algorithm:
>
> 1) Incorrectly set keys in the internal functions are now set in the calling
> function.
> 2) Camel case functions were changed to the snake case.
>
> Fixes: 9b5465867fb8 ("test/crypto: add RSA none padding cases")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Arkadiusz Kusztal
> ---
> v2:
> - removed camel case
> v3:
> - changed commit description
Acked-by: Ciara Power
[PATCH V1] doc: add tested Intel platforms with Intel NICs
Add tested Intel platforms with Intel NICs to v24.03 release note. Signed-off-by: Yu Jiang --- doc/guides/rel_notes/release_24_03.rst | 133 + 1 file changed, 133 insertions(+) diff --git a/doc/guides/rel_notes/release_24_03.rst b/doc/guides/rel_notes/release_24_03.rst index 14826ea08f..9b92c81d06 100644 --- a/doc/guides/rel_notes/release_24_03.rst +++ b/doc/guides/rel_notes/release_24_03.rst @@ -297,3 +297,136 @@ Tested Platforms This section is a comment. Do not overwrite or remove it. Also, make sure to start the actual text at the margin. === + +* Intel\ |reg| platforms with Intel\ |reg| NICs combinations + + * CPU + +* Intel Atom\ |reg| P5342 processor +* Intel\ |reg| Atom\ |trade| CPU C3758 @ 2.20GHz +* Intel\ |reg| Xeon\ |reg| CPU D-1553N @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2699 v4 @ 2.20GHz +* Intel\ |reg| Xeon\ |reg| D-1747NTE CPU @ 2.50GHz +* Intel\ |reg| Xeon\ |reg| D-2796NT CPU @ 2.00GHz +* Intel\ |reg| Xeon\ |reg| Gold 6139 CPU @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| Gold 6140M CPU @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| Gold 6252N CPU @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| Gold 6348 CPU @ 2.60GHz +* Intel\ |reg| Xeon\ |reg| Platinum 8180 CPU @ 2.50GHz +* Intel\ |reg| Xeon\ |reg| Platinum 8280M CPU @ 2.70GHz +* Intel\ |reg| Xeon\ |reg| Platinum 8380 CPU @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| Platinum 8490H + + * OS: + +* CBL Mariner 2.0 +* Fedora 39 +* FreeBSD 14.0 +* OpenAnolis OS 8.8 +* openEuler 22.03 (LTS-SP2) +* Red Hat Enterprise Linux Server release 8.7 +* Red Hat Enterprise Linux Server release 9.0 +* Red Hat Enterprise Linux Server release 9.2 +* Ubuntu 22.04.3 + + * NICs: + +* Intel\ |reg| Ethernet Controller E810-C for SFP (4x25G) + + * Firmware version: 4.40 0x8001c982 1.3534.0 + * Device id (pf/vf): 8086:1593 / 8086:1889 + * Driver version(out-tree): 1.13.7 (ice) + * Driver version(in-tree): 5.15.0-82-generic (Ubuntu22.04.3)/ 5.14.0-284.11.1.rt14.296.el9_2.x86_64 (RHEL9.2) (ice) + * OS Default DDP: 1.3.35.0 + * COMMS DDP: 1.3.45.0 + * Wireless Edge DDP: 1.3.13.0 + +* Intel\ |reg| Ethernet Controller E810-C for QSFP (2x100G) + + * Firmware version: 4.40 0x8001c967 1.3534.0 + * Device id (pf/vf): 8086:1592 / 8086:1889 + * Driver version(out-tree): 1.13.7 (ice) + * Driver version(in-tree): 5.15.55.1-1.cm2-5464b22cac7+ (CBL Mariner 2.0) (ice) + * OS Default DDP: 1.3.35.0 + * COMMS DDP: 1.3.45.0 + * Wireless Edge DDP: 1.3.13.0 + +* Intel\ |reg| Ethernet Controller E810-XXV for SFP (2x25G) + + * Firmware version: 4.40 0x8001af86 1.3444.0 + * Device id (pf/vf): 8086:159b / 8086:1889 + * Driver version: 1.13.7 (ice) + * OS Default DDP: 1.3.35.0 + * COMMS DDP: 1.3.45.0 + +* Intel\ |reg| Ethernet Connection E823-C for QSFP + + * Firmware version: 3.33 0x8001b295 1.3443.0 + * Device id (pf/vf): 8086:188b / 8086:1889 + * Driver version: 1.13.7 (ice) + * OS Default DDP: 1.3.35.0 + * COMMS DDP: 1.3.45.0 + * Wireless Edge DDP: 1.3.13.0 + +* Intel\ |reg| Ethernet Connection E823-L for QSFP + + * Firmware version: 3.33 0x8001b4b0 1.3429.0 + * Device id (pf/vf): 8086:124c / 8086:1889 + * Driver version: 1.13.7 (ice) + * OS Default DDP: 1.3.35.0 + * COMMS DDP: 1.3.45.0 + * Wireless Edge DDP: 1.3.13.0 + +* Intel\ |reg| Ethernet Connection E822-L for backplane + + * Firmware version: 3.33 0x8001b4b6 1.3429.0 + * Device id (pf/vf): 8086:1897 / 8086:1889 + * Driver version: 1.13.7 (ice) + * OS Default DDP: 1.3.35.0 + * COMMS DDP: 1.3.45.0 + * Wireless Edge DDP: 1.3.13.0 + +* Intel\ |reg| 82599ES 10 Gigabit Ethernet Controller + + * Firmware version: 0x000161bf + * Device id (pf/vf): 8086:10fb / 8086:10ed + * Driver version(out-tree): 5.19.9 (ixgbe) + * Driver version(in-tree): 5.15.0-82-generic (Ubuntu22.04.3)/ 5.14.0-284.11.1.el9_2.x86_64 (RHEL9.2)(ixgbe) + +* Intel\ |reg| Ethernet Converged Network Adapter X710-DA4 (4x10G) + + * Firmware version: 9.40 0x8000eca2 1.3429.0 + * Device id (pf/vf): 8086:1572 / 8086:154c + * Driver version(out-tree): 2.24.6 (i40e) + +* Intel\ |reg| Corporation Ethernet Connection X722 for 10GbE SFP+ (2x10G) + + * Firmware version: 6.20 0x80003d82 1.3353.0 + * Device id (pf/vf): 8086:37d0 / 8086:37cd + * Driver version(out-tree): 2.24.6 (i40e) + * Driver version(in-tree): 5.14.0-284.11.1.el9_2.x86_64 (RHEL9.2)(i40e) + +* Intel\ |reg| Ethernet Converged Network Adapter XXV710-DA2 (2x25G) + + * Firmware version: 9.40 0x8000ed12 1.3429.0 + * Device id (pf/vf): 8086:158b / 8086:154c + * Driver version(out-tree): 2.24.6 (i40e) + * Driver version(in-tree): 5.15.0-82-generic (Ubuntu22.04.3)/5.14.
RE: [PATCH v3] dmadev: fix structure alignment
Hi, Thomas
> -Original Message-
> From: Thomas Monjalon
> Sent: Thursday, March 21, 2024 4:31 PM
> To: fengcheng...@huawei.com; Ma, WenwuX
> Cc: dev@dpdk.org; Jiale, SongX ; sta...@dpdk.org
> Subject: Re: [PATCH v3] dmadev: fix structure alignment
>
> 21/03/2024 02:25, Ma, WenwuX:
> > Hi, Thomas
> >
> > From: Thomas Monjalon
> > > 20/03/2024 08:23, Wenwu Ma:
> > > > The structure rte_dma_dev needs to be aligned to the cache line,
> > > > but the return value of malloc may not be aligned to the cache
> > > > line. When we use memset to clear the rte_dma_dev object, it may
> > > > cause a segmentation fault in clang-x86-platform.
> > > >
> > > > This is because clang uses the "vmovaps" assembly instruction for
> > > > memset, which requires that the operands (rte_dma_dev objects)
> > > > must aligned on a 16-byte boundary or a general-protection
> > > > exception (#GP) is generated.
> > > >
> > > > Therefore, either additional memory is applied for re-alignment,
> > > > or the rte_dma_dev object does not require cache line alignment.
> > > > The patch chooses the former option to fix the issue.
> > > >
> > > > Fixes: b36970f2e13e ("dmadev: introduce DMA device library")
> > > > Cc: sta...@dpdk.org
> > > >
> > > > Signed-off-by: Wenwu Ma
> > > [..]
> > > > - size = dma_devices_max * sizeof(struct rte_dma_dev);
> > > > - rte_dma_devices = malloc(size);
> > > > - if (rte_dma_devices == NULL)
> > > > + /* The dma device object is expected to align cacheline, but
> > > > +* the return value of malloc may not be aligned to the cache
> > > > line.
> > > > +* Therefore, extra memory is applied for realignment.
> > > > +* note: We do not call posix_memalign/aligned_alloc because it
> > > > is
> > > > +* version dependent on libc.
> > > > +*/
> > > > + size = dma_devices_max * sizeof(struct rte_dma_dev) +
> > > > + RTE_CACHE_LINE_SIZE;
> > > > + ptr = malloc(size);
> > > > + if (ptr == NULL)
> > > > return -ENOMEM;
> > > > - memset(rte_dma_devices, 0, size);
> > > > + memset(ptr, 0, size);
> > > > +
> > > > + rte_dma_devices = RTE_PTR_ALIGN(ptr, RTE_CACHE_LINE_SIZE);
> > >
> > > Why not using aligned_alloc()?
> > > https://en.cppreference.com/w/c/memory/aligned_alloc
> > >
> > >
> > because it is version dependent on libc.
>
> Which libc is required?
>
In the NOTE section of the link you gave there is this quote：
This function is not supported in Microsoft C Runtime library because its
implementation of std::free is unable to handle aligned allocations of any
kind. Instead, MS CRT provides _aligned_malloc (to be freed with _aligned_free).
RE: [PATCH v3] dmadev: fix structure alignment
Hi, Thomas
> -Original Message-
> From: Thomas Monjalon
> Sent: Thursday, March 21, 2024 4:31 PM
> To: fengcheng...@huawei.com; Ma, WenwuX
> Cc: dev@dpdk.org; Jiale, SongX ; sta...@dpdk.org
> Subject: Re: [PATCH v3] dmadev: fix structure alignment
>
> 21/03/2024 02:25, Ma, WenwuX:
> > Hi, Thomas
> >
> > From: Thomas Monjalon
> > > 20/03/2024 08:23, Wenwu Ma:
> > > > The structure rte_dma_dev needs to be aligned to the cache line,
> > > > but the return value of malloc may not be aligned to the cache
> > > > line. When we use memset to clear the rte_dma_dev object, it may
> > > > cause a segmentation fault in clang-x86-platform.
> > > >
> > > > This is because clang uses the "vmovaps" assembly instruction for
> > > > memset, which requires that the operands (rte_dma_dev objects)
> > > > must aligned on a 16-byte boundary or a general-protection
> > > > exception (#GP) is generated.
> > > >
> > > > Therefore, either additional memory is applied for re-alignment,
> > > > or the rte_dma_dev object does not require cache line alignment.
> > > > The patch chooses the former option to fix the issue.
> > > >
> > > > Fixes: b36970f2e13e ("dmadev: introduce DMA device library")
> > > > Cc: sta...@dpdk.org
> > > >
> > > > Signed-off-by: Wenwu Ma
> > > [..]
> > > > - size = dma_devices_max * sizeof(struct rte_dma_dev);
> > > > - rte_dma_devices = malloc(size);
> > > > - if (rte_dma_devices == NULL)
> > > > + /* The dma device object is expected to align cacheline, but
> > > > +* the return value of malloc may not be aligned to the cache
> > > > line.
> > > > +* Therefore, extra memory is applied for realignment.
> > > > +* note: We do not call posix_memalign/aligned_alloc because it
> > > > is
> > > > +* version dependent on libc.
> > > > +*/
> > > > + size = dma_devices_max * sizeof(struct rte_dma_dev) +
> > > > + RTE_CACHE_LINE_SIZE;
> > > > + ptr = malloc(size);
> > > > + if (ptr == NULL)
> > > > return -ENOMEM;
> > > > - memset(rte_dma_devices, 0, size);
> > > > + memset(ptr, 0, size);
> > > > +
> > > > + rte_dma_devices = RTE_PTR_ALIGN(ptr, RTE_CACHE_LINE_SIZE);
> > >
> > > Why not using aligned_alloc()?
> > > https://en.cppreference.com/w/c/memory/aligned_alloc
> > >
> > >
> > because it is version dependent on libc.
>
> Which libc is required?
>
using the 'man aligned_alloc' command, we has the following description:
VERSIONS
The functions memalign(), valloc(), and pvalloc() have been available in
all Linux libc libraries.
The function aligned_alloc() was added to glibc in version 2.16.
The function posix_memalign() is available since glibc 2.1.91.
Re: [PATCH v5 1/6] examples/l3fwd: fix lcore ID restriction
19/03/2024 08:24, Morten Brørup:
> > From: Sivaprasad Tummala [mailto:sivaprasad.tumm...@amd.com]
> > Sent: Monday, 18 March 2024 18.32
> >
> > Currently the config option allows lcore IDs up to 255,
> > irrespective of RTE_MAX_LCORES and needs to be fixed.
> >
> > The patch allows config options based on DPDK config.
> >
> > Fixes: af75078fece3 ("first public release")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Sivaprasad Tummala
> > Acked-by: Konstantin Ananyev
> > ---
>
> I suggest you update the description of the individual patches too, like you
> did for patch 0/6.
>
> E.g. this patch not only fixes the lcore_id, but also the queue_id type size.
>
>
> For the series,
> Acked-by: Morten Brørup
I would recommend a separate patch for queue id as it is a separate issue.
However, there is no need to split per directory.
You can have patches changing all examples at once.
[PATCH] net/vmxnet3: Don't enable rx queue interrupts on FreeBSD
Commit 29a1c9107bb disabled interrupts on FreeBSD for the vmxnet3 driver
as they are not supported. Rx queue interrupts were missed by this
change, don't attempt to enable them on FreeBSD.
Without this change applications enabling interrupts encounter an
immediate abort on FreeBSD.
Signed-off-by: Tom Jones
---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 2707b25148..ce7c347254 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -1936,11 +1936,13 @@ vmxnet3_interrupt_handler(void *param)
static int
vmxnet3_dev_rx_queue_intr_enable(struct rte_eth_dev *dev, uint16_t queue_id)
{
+#ifndef RTE_EXEC_ENV_FREEBSD
struct vmxnet3_hw *hw = dev->data->dev_private;
vmxnet3_enable_intr(hw,
rte_intr_vec_list_index_get(dev->intr_handle,
queue_id));
+#endif
return 0;
}
--
2.43.0
Re: [PATCH v3] dmadev: fix structure alignment
21/03/2024 10:18, Ma, WenwuX:
> From: Thomas Monjalon
> > 21/03/2024 02:25, Ma, WenwuX:
> > > From: Thomas Monjalon
> > > > 20/03/2024 08:23, Wenwu Ma:
> > > > > The structure rte_dma_dev needs to be aligned to the cache line,
> > > > > but the return value of malloc may not be aligned to the cache
> > > > > line. When we use memset to clear the rte_dma_dev object, it may
> > > > > cause a segmentation fault in clang-x86-platform.
> > > > >
> > > > > This is because clang uses the "vmovaps" assembly instruction for
> > > > > memset, which requires that the operands (rte_dma_dev objects)
> > > > > must aligned on a 16-byte boundary or a general-protection
> > > > > exception (#GP) is generated.
> > > > >
> > > > > Therefore, either additional memory is applied for re-alignment,
> > > > > or the rte_dma_dev object does not require cache line alignment.
> > > > > The patch chooses the former option to fix the issue.
> > > > >
> > > > > Fixes: b36970f2e13e ("dmadev: introduce DMA device library")
> > > > > Cc: sta...@dpdk.org
> > > > >
> > > > > Signed-off-by: Wenwu Ma
> > > > [..]
> > > > > - size = dma_devices_max * sizeof(struct rte_dma_dev);
> > > > > - rte_dma_devices = malloc(size);
> > > > > - if (rte_dma_devices == NULL)
> > > > > + /* The dma device object is expected to align cacheline, but
> > > > > + * the return value of malloc may not be aligned to the cache
> > > > > line.
> > > > > + * Therefore, extra memory is applied for realignment.
> > > > > + * note: We do not call posix_memalign/aligned_alloc because it
> > > > > is
> > > > > + * version dependent on libc.
> > > > > + */
> > > > > + size = dma_devices_max * sizeof(struct rte_dma_dev) +
> > > > > + RTE_CACHE_LINE_SIZE;
> > > > > + ptr = malloc(size);
> > > > > + if (ptr == NULL)
> > > > > return -ENOMEM;
> > > > > - memset(rte_dma_devices, 0, size);
> > > > > + memset(ptr, 0, size);
> > > > > +
> > > > > + rte_dma_devices = RTE_PTR_ALIGN(ptr, RTE_CACHE_LINE_SIZE);
> > > >
> > > > Why not using aligned_alloc()?
> > > > https://en.cppreference.com/w/c/memory/aligned_alloc
> > > >
> > > >
> > > because it is version dependent on libc.
> >
> > Which libc is required?
> >
>
> using the 'man aligned_alloc' command, we has the following description:
>
> VERSIONS
>The functions memalign(), valloc(), and pvalloc() have been available
> in all Linux libc libraries.
>
>The function aligned_alloc() was added to glibc in version 2.16.
released in 2012-06-30
>The function posix_memalign() is available since glibc 2.1.91.
I think we could bump our libc requirements for these functions.
I understand there is also a concern on Windows,
but an alternative exists there.
We may need a wrapper like "rte_alloc_align".
[PATCH] vhost: cleanup vq resubmit info when set_inflight_fd
We should cleanup vq resubmit info when set_inflight_fd
before set_vring_kick which will check if there is any
inflight io waiting for resubmission.
Otherwise, when the vm is rebooting immediately after
reconnecting to the vhost target (inflight io has not
been resubmitted yet), the vhost backend still use the
old resubmit info set when reconnection.
Signed-off-by: Haoqian He
---
lib/vhost/vhost_user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 414192500e..7c54afc5fb 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -1871,6 +1871,7 @@ vhost_user_set_inflight_fd(struct virtio_net **pdev,
if (!vq)
continue;
+ cleanup_vq_inflight(dev, vq);
if (vq_is_packed(dev)) {
vq->inflight_packed = addr;
vq->inflight_packed->desc_num = queue_size;
--
2.41.0
Re: [PATCH] net/vmxnet3: Don't enable rx queue interrupts on FreeBSD
Hello Tom,
On Thu, Mar 21, 2024 at 11:00 AM Tom Jones wrote:
>
> Commit 29a1c9107bb disabled interrupts on FreeBSD for the vmxnet3 driver
> as they are not supported. Rx queue interrupts were missed by this
> change, don't attempt to enable them on FreeBSD.
>
> Without this change applications enabling interrupts encounter an
> immediate abort on FreeBSD.
Thanks for the patch, you will probably want this fix backported in
LTS versions.
If so, please add a Fixes: tag and Cc: sta...@dpdk.org.
I guess here, it is:
Fixes: 40d5676ff1ea ("net/vmxnet3: fix initialization on FreeBSD")
Cc: Bruce
Reading again the commitlog, I wonder if we should error out in
vmxnet3_configure_msix() if rx (and/or lsc) interrupts are requested
for FreeBSD.
Did you consider this approach?
--
David Marchand
Re: [PATCH v7 2/4] mbuf: remove rte marker fields
On Wed, Mar 20, 2024 at 03:01:36PM -0700, Tyler Retzlaff wrote:
> RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Remove
> RTE_MARKER fields from rte_mbuf struct.
>
> Maintain alignment of fields after removed cacheline1 marker by placing
> C11 alignas(RTE_CACHE_LINE_MIN_SIZE).
>
> Provide new rearm_data and rx_descriptor_fields1 fields in anonymous
> unions as single element arrays of with types matching the original
> markers to maintain API compatibility.
>
> Signed-off-by: Tyler Retzlaff
> ---
> doc/guides/rel_notes/release_24_03.rst | 2 +
> lib/mbuf/rte_mbuf.h| 4 +-
> lib/mbuf/rte_mbuf_core.h | 188
> ++---
> 3 files changed, 104 insertions(+), 90 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_24_03.rst
> b/doc/guides/rel_notes/release_24_03.rst
> index 14826ea..4f18cca 100644
> --- a/doc/guides/rel_notes/release_24_03.rst
> +++ b/doc/guides/rel_notes/release_24_03.rst
> @@ -216,6 +216,8 @@ Removed Items
>
> * acc101: Removed obsolete code for non productized HW variant.
>
> +* mbuf: ``RTE_MARKER`` fields ``cacheline0`` and ``cacheline1``
> + have been removed from ``struct rte_mbuf``.
>
> API Changes
> ---
> diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
> index 286b32b..4c4722e 100644
> --- a/lib/mbuf/rte_mbuf.h
> +++ b/lib/mbuf/rte_mbuf.h
> @@ -108,7 +108,7 @@
> static inline void
> rte_mbuf_prefetch_part1(struct rte_mbuf *m)
> {
> - rte_prefetch0(&m->cacheline0);
> + rte_prefetch0(m);
> }
>
> /**
> @@ -126,7 +126,7 @@
> rte_mbuf_prefetch_part2(struct rte_mbuf *m)
> {
> #if RTE_CACHE_LINE_SIZE == 64
> - rte_prefetch0(&m->cacheline1);
> + rte_prefetch0(RTE_PTR_ADD(m, RTE_CACHE_LINE_MIN_SIZE));
> #else
> RTE_SET_USED(m);
> #endif
> diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
> index 9f58076..665213c 100644
> --- a/lib/mbuf/rte_mbuf_core.h
> +++ b/lib/mbuf/rte_mbuf_core.h
> @@ -465,8 +465,6 @@ enum {
> * The generic rte_mbuf, containing a packet mbuf.
> */
> struct __rte_cache_aligned rte_mbuf {
> - RTE_MARKER cacheline0;
> -
> void *buf_addr; /**< Virtual address of segment buffer. */
> #if RTE_IOVA_IN_MBUF
> /**
> @@ -488,116 +486,130 @@ struct __rte_cache_aligned rte_mbuf {
> #endif
>
> /* next 8 bytes are initialised on RX descriptor rearm */
> - RTE_MARKER64 rearm_data;
> - uint16_t data_off;
> -
> - /**
> - * Reference counter. Its size should at least equal to the size
> - * of port field (16 bits), to support zero-copy broadcast.
> - * It should only be accessed using the following functions:
> - * rte_mbuf_refcnt_update(), rte_mbuf_refcnt_read(), and
> - * rte_mbuf_refcnt_set(). The functionality of these functions (atomic,
> - * or non-atomic) is controlled by the RTE_MBUF_REFCNT_ATOMIC flag.
> - */
> - RTE_ATOMIC(uint16_t) refcnt;
> + union {
> + uint64_t rearm_data[1];
> + __extension__
> + struct {
> + uint16_t data_off;
> +
> + /**
> + * Reference counter. Its size should at least equal to
> the size
> + * of port field (16 bits), to support zero-copy
> broadcast.
> + * It should only be accessed using the following
> functions:
> + * rte_mbuf_refcnt_update(), rte_mbuf_refcnt_read(), and
> + * rte_mbuf_refcnt_set(). The functionality of these
> functions (atomic,
> + * or non-atomic) is controlled by the
> RTE_MBUF_REFCNT_ATOMIC flag.
> + */
> + RTE_ATOMIC(uint16_t) refcnt;
>
> - /**
> - * Number of segments. Only valid for the first segment of an mbuf
> - * chain.
> - */
> - uint16_t nb_segs;
> + /**
> + * Number of segments. Only valid for the first segment
> of an mbuf
> + * chain.
> + */
> + uint16_t nb_segs;
>
> - /** Input port (16 bits to support more than 256 virtual ports).
> - * The event eth Tx adapter uses this field to specify the output port.
> - */
> - uint16_t port;
> + /** Input port (16 bits to support more than 256
> virtual ports).
> + * The event eth Tx adapter uses this field to specify
> the output port.
> + */
> + uint16_t port;
> + };
> + };
>
> uint64_t ol_flags;/**< Offload features. */
>
> /* remaining bytes are set on RX when pulling packet from descriptor */
> - RTE_MARKER rx_descriptor_fields1;
> -
> - /*
> - * The packet type, which is the combination of outer/inner L2, L3, L4
> - * and tunnel types. The packet_type is about data really present in the
> -
[PATCH] net/vmxnet3: Don't enable rx queue interrupts on FreeBSD
Commit 29a1c9107bb disabled interrupts on FreeBSD for the vmxnet3 driver
as they are not supported. Rx queue interrupts were missed by this
change, don't attempt to enable them on FreeBSD.
Without this change applications enabling interrupts encounter an
immediate abort on FreeBSD.
Fixes: 40d5676ff1ea ("net/vmxnet3: fix initialization on FreeBSD")
Cc: sta...@dpdk.org
Signed-off-by: Tom Jones
---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 2707b25148..ce7c347254 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -1936,11 +1936,13 @@ vmxnet3_interrupt_handler(void *param)
static int
vmxnet3_dev_rx_queue_intr_enable(struct rte_eth_dev *dev, uint16_t queue_id)
{
+#ifndef RTE_EXEC_ENV_FREEBSD
struct vmxnet3_hw *hw = dev->data->dev_private;
vmxnet3_enable_intr(hw,
rte_intr_vec_list_index_get(dev->intr_handle,
queue_id));
+#endif
return 0;
}
--
2.43.0
Re: [PATCH] net/vmxnet3: Don't enable rx queue interrupts on FreeBSD
On Thu, Mar 21, 2024, at 10:15, David Marchand wrote:
> Hello Tom,
>
> On Thu, Mar 21, 2024 at 11:00 AM Tom Jones wrote:
>>
>> Commit 29a1c9107bb disabled interrupts on FreeBSD for the vmxnet3 driver
>> as they are not supported. Rx queue interrupts were missed by this
>> change, don't attempt to enable them on FreeBSD.
>>
>> Without this change applications enabling interrupts encounter an
>> immediate abort on FreeBSD.
>
> Thanks for the patch, you will probably want this fix backported in
> LTS versions.
> If so, please add a Fixes: tag and Cc: sta...@dpdk.org.
> I guess here, it is:
> Fixes: 40d5676ff1ea ("net/vmxnet3: fix initialization on FreeBSD")
Thanks! updated
>
> Reading again the commitlog, I wonder if we should error out in
> vmxnet3_configure_msix() if rx (and/or lsc) interrupts are requested
> for FreeBSD.
> Did you consider this approach?
>
I haven't dug much futher into this. I also changed the application side (vpp)
to not request interrupts. I think there are probably some other FreeBSD
specific cases to explore in vmxnet3, but I don't have a great environment for
testing yet.
- Tom
Re: [PATCH] net/nfp: fix receive packets failed
On 3/21/2024 6:56 AM, Chaoyong He wrote:
> From: Long Wu
>
> Meta data parsing should be controlled by meta data flag. So use
> flag to determine if receive function can use 'port_id' meta data.
>
> Fixes: 580ea0b09a7c ("net/nfp: fix Rx descriptor")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Long Wu
> Reviewed-by: Chaoyong He
> Reviewed-by: Peng Zhang
>
Applied to dpdk-next-net/main, thanks.
RE: [PATCH v5 1/6] examples/l3fwd: fix lcore ID restriction
[AMD Official Use Only - General]
Hi Morten,
> -Original Message-
> From: Morten Brørup
> Sent: Tuesday, March 19, 2024 12:54 PM
> To: Tummala, Sivaprasad ;
> david.h...@intel.com; anatoly.bura...@intel.com; jer...@marvell.com;
> radu.nico...@intel.com; gak...@marvell.com; cristian.dumitre...@intel.com;
> Yigit,
> Ferruh ; konstantin.anan...@huawei.com;
> step...@networkplumber.org; david.march...@redhat.com
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH v5 1/6] examples/l3fwd: fix lcore ID restriction
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> > From: Sivaprasad Tummala [mailto:sivaprasad.tumm...@amd.com]
> > Sent: Monday, 18 March 2024 18.32
> >
> > Currently the config option allows lcore IDs up to 255, irrespective
> > of RTE_MAX_LCORES and needs to be fixed.
> >
> > The patch allows config options based on DPDK config.
> >
> > Fixes: af75078fece3 ("first public release")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Sivaprasad Tummala
> > Acked-by: Konstantin Ananyev
> > ---
>
> I suggest you update the description of the individual patches too, like you
> did for
> patch 0/6.
Sure, will fix this in next series.
>
> E.g. this patch not only fixes the lcore_id, but also the queue_id type size.
>
>
> For the series,
> Acked-by: Morten Brørup
RE: [PATCH v5 1/6] examples/l3fwd: fix lcore ID restriction
[AMD Official Use Only - General]
Hi Thomas,
> -Original Message-
> From: Thomas Monjalon
> Sent: Thursday, March 21, 2024 3:25 PM
> To: Tummala, Sivaprasad
> Cc: david.h...@intel.com; anatoly.bura...@intel.com; jer...@marvell.com;
> radu.nico...@intel.com; gak...@marvell.com; cristian.dumitre...@intel.com;
> Yigit,
> Ferruh ; konstantin.anan...@huawei.com;
> step...@networkplumber.org; david.march...@redhat.com; dev@dpdk.org;
> sta...@dpdk.org; Morten Brørup
> Subject: Re: [PATCH v5 1/6] examples/l3fwd: fix lcore ID restriction
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> 19/03/2024 08:24, Morten Brørup:
> > > From: Sivaprasad Tummala [mailto:sivaprasad.tumm...@amd.com]
> > > Sent: Monday, 18 March 2024 18.32
> > >
> > > Currently the config option allows lcore IDs up to 255, irrespective
> > > of RTE_MAX_LCORES and needs to be fixed.
> > >
> > > The patch allows config options based on DPDK config.
> > >
> > > Fixes: af75078fece3 ("first public release")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Sivaprasad Tummala
> > > Acked-by: Konstantin Ananyev
> > > ---
> >
> > I suggest you update the description of the individual patches too, like
> > you did
> for patch 0/6.
> >
> > E.g. this patch not only fixes the lcore_id, but also the queue_id type
> > size.
> >
> >
> > For the series,
> > Acked-by: Morten Brørup
>
> I would recommend a separate patch for queue id as it is a separate issue.
> However, there is no need to split per directory.
> You can have patches changing all examples at once.
>
There's a functional dependency and queue id change is required to support
higher lcore IDs and hence it makes sense to add in the same patch.
I had split the examples to help the maintainers review the patches
individually.
Please feel free to squash the git commits while merging.
Re: [PATCH v5 1/6] examples/l3fwd: fix lcore ID restriction
21/03/2024 12:05, Tummala, Sivaprasad:
> From: Thomas Monjalon
> > 19/03/2024 08:24, Morten Brørup:
> > > > From: Sivaprasad Tummala [mailto:sivaprasad.tumm...@amd.com]
> > > > Sent: Monday, 18 March 2024 18.32
> > > >
> > > > Currently the config option allows lcore IDs up to 255, irrespective
> > > > of RTE_MAX_LCORES and needs to be fixed.
> > > >
> > > > The patch allows config options based on DPDK config.
> > > >
> > > > Fixes: af75078fece3 ("first public release")
> > > > Cc: sta...@dpdk.org
> > > >
> > > > Signed-off-by: Sivaprasad Tummala
> > > > Acked-by: Konstantin Ananyev
> > > > ---
> > >
> > > I suggest you update the description of the individual patches too, like
> > > you did
> > for patch 0/6.
> > >
> > > E.g. this patch not only fixes the lcore_id, but also the queue_id type
> > > size.
> > >
> > >
> > > For the series,
> > > Acked-by: Morten Brørup
> >
> > I would recommend a separate patch for queue id as it is a separate issue.
> > However, there is no need to split per directory.
> > You can have patches changing all examples at once.
> >
> There's a functional dependency and queue id change is required to support
> higher lcore IDs and hence it makes sense to add in the same patch.
> I had split the examples to help the maintainers review the patches
> individually.
> Please feel free to squash the git commits while merging.
Then if there is a dependency, please make queue id the first patch.
RE: [PATCH 0/2] introduce PM QoS interface
> From: lihuisong (C) [mailto:lihuis...@huawei.com] > Sent: Thursday, 21 March 2024 04.04 > > Hi Moren, > > Thanks for your revew. > > 在 2024/3/20 22:05, Morten Brørup 写道: > >> From: Huisong Li [mailto:lihuis...@huawei.com] > >> Sent: Wednesday, 20 March 2024 11.55 > >> > >> The system-wide CPU latency QoS limit has a positive impact on the idle > >> state selection in cpuidle governor. > >> > >> Linux creates a cpu_dma_latency device under '/dev' directory to obtain the > >> CPU latency QoS limit on system and send the QoS request for userspace. > >> Please see the PM QoS framework in the following link: > >> https://docs.kernel.org/power/pm_qos_interface.html?highlight=qos > >> This feature is supported by kernel-v2.6.25. > >> > >> The deeper the idle state, the lower the power consumption, but the longer > >> the resume time. Some service are delay sensitive and very except the low > >> resume time, like interrupt packet receiving mode. > >> > >> So this series introduce PM QoS interface. > > This looks like a 1:1 wrapper for a Linux kernel feature. > right > > Does Windows or BSD offer something similar? > How do we know Windows or BSD support this similar feature? Ask Windows experts or research using Google. > The DPDK power lib just work on Linux according to the meson.build under > lib/power. > If they support this features, they can open it. The DPDK power lib currently only works on Linux, yes. But its API should still be designed to be platform agnostic, so the functions can be implemented on other platforms in the future. DPDK is on track to work across multiple platforms, including Windows. We must always consider other platforms, and not design DPDK APIs as if they are for Linux/BSD only. > > > > Furthermore, any high-res timing should use nanoseconds, not microseconds or > milliseconds. > > I realize that the Linux kernel only uses microseconds for these APIs, but > the DPDK API should use nanoseconds. > Nanoseconds is more precise, it's good. > But DPDK API how use nanoseconds as you said the the Linux kernel only > uses microseconds for these APIs. > Kernel interface just know an integer value with microseconds unit. One solution is to expose nanoseconds in the DPDK API, and in the Linux specific implementation convert from/to microseconds. You might also want to add a note to the in-line documentation of the relevant functions that the Linux implementation only uses microsecond resolution.
[PATCH 1/2] net/mlx5/hws: fix rule resize status check
The check to detect if a rule is in resize was done incorrectly,
this can lead to an incorrect function call upon completion for
rules which are not in resize (move).
Since the resize_info is in a union we cannot rely only on the
pointer value but also need to make sure the matcher is in resize
process, this assures us the resize info is valid.
Fixes: 762feceb8294 ("net/mlx5/hws: support resizable matchers")
Signed-off-by: Yevgeny Kliteynik
Signed-off-by: Alex Vesker
Acked-by: Matan Azrad
---
drivers/net/mlx5/hws/mlx5dr_rule.c | 7 +++
drivers/net/mlx5/hws/mlx5dr_rule.h | 6 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/mlx5/hws/mlx5dr_rule.c
b/drivers/net/mlx5/hws/mlx5dr_rule.c
index f14e1e6ecd..784f614d87 100644
--- a/drivers/net/mlx5/hws/mlx5dr_rule.c
+++ b/drivers/net/mlx5/hws/mlx5dr_rule.c
@@ -350,6 +350,13 @@ static void mlx5dr_rule_move_init(struct mlx5dr_rule *rule,
rule->resize_info->state = MLX5DR_RULE_RESIZE_STATE_WRITING;
}
+bool mlx5dr_rule_move_in_progress(struct mlx5dr_rule *rule)
+{
+ return mlx5dr_matcher_is_in_resize(rule->matcher) &&
+ rule->resize_info &&
+ rule->resize_info->state != MLX5DR_RULE_RESIZE_STATE_IDLE;
+}
+
static int mlx5dr_rule_create_hws_fw_wqe(struct mlx5dr_rule *rule,
struct mlx5dr_rule_attr *attr,
uint8_t mt_idx,
diff --git a/drivers/net/mlx5/hws/mlx5dr_rule.h
b/drivers/net/mlx5/hws/mlx5dr_rule.h
index 07adf9c5ad..dffaec1c0f 100644
--- a/drivers/net/mlx5/hws/mlx5dr_rule.h
+++ b/drivers/net/mlx5/hws/mlx5dr_rule.h
@@ -72,10 +72,6 @@ int mlx5dr_rule_move_hws_remove(struct mlx5dr_rule *rule,
int mlx5dr_rule_move_hws_add(struct mlx5dr_rule *rule,
struct mlx5dr_rule_attr *attr);
-static inline bool mlx5dr_rule_move_in_progress(struct mlx5dr_rule *rule)
-{
- return rule->resize_info &&
- rule->resize_info->state != MLX5DR_RULE_RESIZE_STATE_IDLE;
-}
+bool mlx5dr_rule_move_in_progress(struct mlx5dr_rule *rule);
#endif /* MLX5DR_RULE_H_ */
--
2.27.0
[PATCH 2/2] net/mlx5/hws: fix port ID for root table
From: Erez Shitrit
In root tables matcher and rule need to have their port-id, otherwise
the translate function that done in dpdk layer will not get the right
attributes.
For that whenever the matcher is matching the source-port we need to get
the relevant port-id before calling the translate function.
Fixes: 405242c52dd5 ("net/mlx5/hws: add rule object")
Cc: sta...@dpdk.org
Signed-off-by: Yevgeny Kliteynik
Signed-off-by: Erez Shitrit
Acked-by: Matan Azrad
Signed-off-by: Yevgeny Kliteynik
---
drivers/net/mlx5/hws/mlx5dr_matcher.c | 17 +
drivers/net/mlx5/hws/mlx5dr_rule.c| 18 ++
drivers/net/mlx5/mlx5_flow.h | 22 ++
3 files changed, 57 insertions(+)
diff --git a/drivers/net/mlx5/hws/mlx5dr_matcher.c
b/drivers/net/mlx5/hws/mlx5dr_matcher.c
index 1c64abfa57..aeff300467 100644
--- a/drivers/net/mlx5/hws/mlx5dr_matcher.c
+++ b/drivers/net/mlx5/hws/mlx5dr_matcher.c
@@ -1220,6 +1220,7 @@ static int mlx5dr_matcher_init_root(struct mlx5dr_matcher
*matcher)
struct mlx5dv_flow_match_parameters *mask;
struct mlx5_flow_attr flow_attr = {0};
struct rte_flow_error rte_error;
+ struct rte_flow_item *item;
uint8_t match_criteria;
int ret;
@@ -1248,6 +1249,22 @@ static int mlx5dr_matcher_init_root(struct
mlx5dr_matcher *matcher)
return rte_errno;
}
+ /* We need the port id in case of matching representor */
+ item = matcher->mt[0].items;
+ while (item->type != RTE_FLOW_ITEM_TYPE_END) {
+ if (item->type == RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR ||
+ item->type == RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT) {
+ ret = flow_hw_get_port_id_from_ctx(ctx,
&flow_attr.port_id);
+ if (ret) {
+ DR_LOG(ERR, "Failed to get port id for dev %s",
+ ctx->ibv_ctx->device->name);
+ rte_errno = EINVAL;
+ return rte_errno;
+ }
+ }
+ ++item;
+ }
+
mask = simple_calloc(1, MLX5_ST_SZ_BYTES(fte_match_param) +
offsetof(struct mlx5dv_flow_match_parameters,
match_buf));
if (!mask) {
diff --git a/drivers/net/mlx5/hws/mlx5dr_rule.c
b/drivers/net/mlx5/hws/mlx5dr_rule.c
index 784f614d87..022263eb1d 100644
--- a/drivers/net/mlx5/hws/mlx5dr_rule.c
+++ b/drivers/net/mlx5/hws/mlx5dr_rule.c
@@ -687,10 +687,28 @@ static int mlx5dr_rule_create_root(struct mlx5dr_rule
*rule,
struct mlx5dv_flow_match_parameters *value;
struct mlx5_flow_attr flow_attr = {0};
struct mlx5dv_flow_action_attr *attr;
+ const struct rte_flow_item *cur_item;
struct rte_flow_error error;
uint8_t match_criteria;
int ret;
+ /* We need the port id in case of matching representor */
+ cur_item = items;
+ while (cur_item->type != RTE_FLOW_ITEM_TYPE_END) {
+ if (cur_item->type == RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR ||
+ cur_item->type == RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT) {
+ ret =
flow_hw_get_port_id_from_ctx(rule->matcher->tbl->ctx,
+ &flow_attr.port_id);
+ if (ret) {
+ DR_LOG(ERR, "Failed to get port id for dev %s",
+
rule->matcher->tbl->ctx->ibv_ctx->device->name);
+ rte_errno = EINVAL;
+ return rte_errno;
+ }
+ }
+ ++cur_item;
+ }
+
attr = simple_calloc(num_actions, sizeof(*attr));
if (!attr) {
rte_errno = ENOMEM;
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 34b5e0f45b..0065727a67 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -2001,6 +2001,28 @@ flow_hw_get_reg_id(struct rte_eth_dev *dev,
#endif
}
+static __rte_always_inline int
+flow_hw_get_port_id_from_ctx(void *dr_ctx, uint32_t *port_val)
+{
+#if defined(HAVE_IBV_FLOW_DV_SUPPORT) || !defined(HAVE_INFINIBAND_VERBS_H)
+ uint32_t port;
+
+ MLX5_ETH_FOREACH_DEV(port, NULL) {
+ struct mlx5_priv *priv;
+ priv = rte_eth_devices[port].data->dev_private;
+
+ if (priv->dr_ctx == dr_ctx) {
+ *port_val = port;
+ return 0;
+ }
+ }
+#else
+ RTE_SET_USED(dr_ctx);
+ RTE_SET_USED(port_val);
+#endif
+ return -EINVAL;
+}
+
/**
* Get GENEVE TLV option FW information according type and class.
*
--
2.27.0
Re: [PATCH] net/vmxnet3: Don't enable rx queue interrupts on FreeBSD
On 3/21/2024 10:31 AM, Tom Jones wrote:
> Commit 29a1c9107bb disabled interrupts on FreeBSD for the vmxnet3 driver
> as they are not supported. Rx queue interrupts were missed by this
> change, don't attempt to enable them on FreeBSD.
>
> Without this change applications enabling interrupts encounter an
> immediate abort on FreeBSD.
>
> Fixes: 40d5676ff1ea ("net/vmxnet3: fix initialization on FreeBSD")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Tom Jones
>
Acked-by: Ferruh Yigit
Applied to dpdk-next-net/main, thanks.
(
- Commit log updated slightly, removed "Commit 29a1c9107bb" references
- updated .mailmap
)
RE: [PATCH v2] doc: update LTS maintenance to 3 years
> From: Kevin Traynor > ... > Update the policy to indicate 3 years maintenance for LTS releases, but > note that it depends on community support. Acked-by: John McNamara
[PATCH v2] net/mlx5/hws: fix port ID for root table
From: Erez Shitrit
In root tables matcher and rule need to have their port-id, otherwise
the translate function that done in dpdk layer will not get the right
attributes.
For that whenever the matcher is matching the source-port we need to get
the relevant port-id before calling the translate function.
Fixes: 405242c52dd5 ("net/mlx5/hws: add rule object")
Cc: sta...@dpdk.org
Signed-off-by: Yevgeny Kliteynik
Signed-off-by: Erez Shitrit
Acked-by: Matan Azrad
---
V2 - removed duplicated sign-off line
drivers/net/mlx5/hws/mlx5dr_matcher.c | 17 +
drivers/net/mlx5/hws/mlx5dr_rule.c| 18 ++
drivers/net/mlx5/mlx5_flow.h | 22 ++
3 files changed, 57 insertions(+)
diff --git a/drivers/net/mlx5/hws/mlx5dr_matcher.c
b/drivers/net/mlx5/hws/mlx5dr_matcher.c
index 1c64abfa57..aeff300467 100644
--- a/drivers/net/mlx5/hws/mlx5dr_matcher.c
+++ b/drivers/net/mlx5/hws/mlx5dr_matcher.c
@@ -1220,6 +1220,7 @@ static int mlx5dr_matcher_init_root(struct mlx5dr_matcher
*matcher)
struct mlx5dv_flow_match_parameters *mask;
struct mlx5_flow_attr flow_attr = {0};
struct rte_flow_error rte_error;
+ struct rte_flow_item *item;
uint8_t match_criteria;
int ret;
@@ -1248,6 +1249,22 @@ static int mlx5dr_matcher_init_root(struct
mlx5dr_matcher *matcher)
return rte_errno;
}
+ /* We need the port id in case of matching representor */
+ item = matcher->mt[0].items;
+ while (item->type != RTE_FLOW_ITEM_TYPE_END) {
+ if (item->type == RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR ||
+ item->type == RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT) {
+ ret = flow_hw_get_port_id_from_ctx(ctx,
&flow_attr.port_id);
+ if (ret) {
+ DR_LOG(ERR, "Failed to get port id for dev %s",
+ ctx->ibv_ctx->device->name);
+ rte_errno = EINVAL;
+ return rte_errno;
+ }
+ }
+ ++item;
+ }
+
mask = simple_calloc(1, MLX5_ST_SZ_BYTES(fte_match_param) +
offsetof(struct mlx5dv_flow_match_parameters,
match_buf));
if (!mask) {
diff --git a/drivers/net/mlx5/hws/mlx5dr_rule.c
b/drivers/net/mlx5/hws/mlx5dr_rule.c
index 784f614d87..022263eb1d 100644
--- a/drivers/net/mlx5/hws/mlx5dr_rule.c
+++ b/drivers/net/mlx5/hws/mlx5dr_rule.c
@@ -687,10 +687,28 @@ static int mlx5dr_rule_create_root(struct mlx5dr_rule
*rule,
struct mlx5dv_flow_match_parameters *value;
struct mlx5_flow_attr flow_attr = {0};
struct mlx5dv_flow_action_attr *attr;
+ const struct rte_flow_item *cur_item;
struct rte_flow_error error;
uint8_t match_criteria;
int ret;
+ /* We need the port id in case of matching representor */
+ cur_item = items;
+ while (cur_item->type != RTE_FLOW_ITEM_TYPE_END) {
+ if (cur_item->type == RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR ||
+ cur_item->type == RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT) {
+ ret =
flow_hw_get_port_id_from_ctx(rule->matcher->tbl->ctx,
+ &flow_attr.port_id);
+ if (ret) {
+ DR_LOG(ERR, "Failed to get port id for dev %s",
+
rule->matcher->tbl->ctx->ibv_ctx->device->name);
+ rte_errno = EINVAL;
+ return rte_errno;
+ }
+ }
+ ++cur_item;
+ }
+
attr = simple_calloc(num_actions, sizeof(*attr));
if (!attr) {
rte_errno = ENOMEM;
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 34b5e0f45b..0065727a67 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -2001,6 +2001,28 @@ flow_hw_get_reg_id(struct rte_eth_dev *dev,
#endif
}
+static __rte_always_inline int
+flow_hw_get_port_id_from_ctx(void *dr_ctx, uint32_t *port_val)
+{
+#if defined(HAVE_IBV_FLOW_DV_SUPPORT) || !defined(HAVE_INFINIBAND_VERBS_H)
+ uint32_t port;
+
+ MLX5_ETH_FOREACH_DEV(port, NULL) {
+ struct mlx5_priv *priv;
+ priv = rte_eth_devices[port].data->dev_private;
+
+ if (priv->dr_ctx == dr_ctx) {
+ *port_val = port;
+ return 0;
+ }
+ }
+#else
+ RTE_SET_USED(dr_ctx);
+ RTE_SET_USED(port_val);
+#endif
+ return -EINVAL;
+}
+
/**
* Get GENEVE TLV option FW information according type and class.
*
--
2.27.0
DPDK Release Status Meeting 2024-03-21
Release status meeting minutes 2024-03-21 = Agenda: * Release Dates * Subtrees * Roadmaps * LTS * Defects * Opens Participants: * AMD * ARM * Intel * Marvell * Nvidia * Red Hat Release Dates - The following are the current/updated working dates for 24.03: * V1: 29 December 2023 * RC1: 21 February 2024 * RC2: 8 March2024 * RC3: 18 March2024 * RC4: 22 March2024 * Release: 27 March2024 https://core.dpdk.org/roadmap/#dates Subtrees * next-net * Some fixes merged. * Ready for Pull * next-net-intel * 2 fix/doc patches. * next-net-mlx * Series merged after RC3. * next-net-mvl * No new changes post RC3. * next-eventdev * No new changes post RC3. * next-baseband * No new changes post RC3. * next-virtio * No new changes post RC3. * next-crypto * Some doc patches. * Patch for ipsecgw sample app to be postponed to next release due to risk of breakage in other PMDs. * main * RH testing for RC3 - no major issues. * Looking at Windows patches for next release to make sure there aren't any API/ABI breaking changes. * Doc fixes and release notes. * Proposed 24.03 dates: * RC4: 22 March 2024 * Release: 27 March 2024 LTS --- Please add acks to confirm validation support for a 3 year LTS window: http://inbox.dpdk.org/dev/20240117161804.223582-1-ktray...@redhat.com/ * 23.11.1 - In progress. * 22.11.5 - In progress. * 21.11.7 - In progress. * 20.11.10 - Will only be updated with CVE and critical fixes. * 19.11.15 - Will only be updated with CVE and critical fixes. * Distros * Debian 12 contains DPDK v22.11 * Ubuntu 24.04-LTS will contain DPDK v23.11 * Ubuntu 23.04 contains DPDK v22.11 Defects --- * Bugzilla links, 'Bugs', added for hosted projects * https://www.dpdk.org/hosted-projects/ DPDK Release Status Meetings The DPDK Release Status Meeting is intended for DPDK Committers to discuss the status of the master tree and sub-trees, and for project managers to track progress or milestone dates. The meeting occurs on every Thursday at 9:30 UTC over Jitsi on https://meet.jit.si/DPDK You don't need an invite to join the meeting but if you want a calendar reminder just send an email to "John McNamara john.mcnam...@intel.com" for the invite.
Re: [PATCH v7 2/4] mbuf: remove rte marker fields
On Thu, Mar 21, 2024 at 10:32:02AM +, Bruce Richardson wrote:
> On Wed, Mar 20, 2024 at 03:01:36PM -0700, Tyler Retzlaff wrote:
> > RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Remove
> > RTE_MARKER fields from rte_mbuf struct.
> >
> > Maintain alignment of fields after removed cacheline1 marker by placing
> > C11 alignas(RTE_CACHE_LINE_MIN_SIZE).
> >
> > Provide new rearm_data and rx_descriptor_fields1 fields in anonymous
> > unions as single element arrays of with types matching the original
> > markers to maintain API compatibility.
> >
> > Signed-off-by: Tyler Retzlaff
> > ---
> > doc/guides/rel_notes/release_24_03.rst | 2 +
> > lib/mbuf/rte_mbuf.h| 4 +-
> > lib/mbuf/rte_mbuf_core.h | 188
> > ++---
> > 3 files changed, 104 insertions(+), 90 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/release_24_03.rst
> > b/doc/guides/rel_notes/release_24_03.rst
> > index 14826ea..4f18cca 100644
> > --- a/doc/guides/rel_notes/release_24_03.rst
> > +++ b/doc/guides/rel_notes/release_24_03.rst
> > @@ -216,6 +216,8 @@ Removed Items
> >
> > * acc101: Removed obsolete code for non productized HW variant.
> >
> > +* mbuf: ``RTE_MARKER`` fields ``cacheline0`` and ``cacheline1``
> > + have been removed from ``struct rte_mbuf``.
> >
> > API Changes
> > ---
> > diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
> > index 286b32b..4c4722e 100644
> > --- a/lib/mbuf/rte_mbuf.h
> > +++ b/lib/mbuf/rte_mbuf.h
> > @@ -108,7 +108,7 @@
> > static inline void
> > rte_mbuf_prefetch_part1(struct rte_mbuf *m)
> > {
> > - rte_prefetch0(&m->cacheline0);
> > + rte_prefetch0(m);
> > }
> >
> > /**
> > @@ -126,7 +126,7 @@
> > rte_mbuf_prefetch_part2(struct rte_mbuf *m)
> > {
> > #if RTE_CACHE_LINE_SIZE == 64
> > - rte_prefetch0(&m->cacheline1);
> > + rte_prefetch0(RTE_PTR_ADD(m, RTE_CACHE_LINE_MIN_SIZE));
> > #else
> > RTE_SET_USED(m);
> > #endif
> > diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
> > index 9f58076..665213c 100644
> > --- a/lib/mbuf/rte_mbuf_core.h
> > +++ b/lib/mbuf/rte_mbuf_core.h
> > @@ -465,8 +465,6 @@ enum {
> > * The generic rte_mbuf, containing a packet mbuf.
> > */
> > struct __rte_cache_aligned rte_mbuf {
> > - RTE_MARKER cacheline0;
> > -
> > void *buf_addr; /**< Virtual address of segment buffer. */
> > #if RTE_IOVA_IN_MBUF
> > /**
> > @@ -488,116 +486,130 @@ struct __rte_cache_aligned rte_mbuf {
> > #endif
> >
> > /* next 8 bytes are initialised on RX descriptor rearm */
> > - RTE_MARKER64 rearm_data;
> > - uint16_t data_off;
> > -
> > - /**
> > -* Reference counter. Its size should at least equal to the size
> > -* of port field (16 bits), to support zero-copy broadcast.
> > -* It should only be accessed using the following functions:
> > -* rte_mbuf_refcnt_update(), rte_mbuf_refcnt_read(), and
> > -* rte_mbuf_refcnt_set(). The functionality of these functions (atomic,
> > -* or non-atomic) is controlled by the RTE_MBUF_REFCNT_ATOMIC flag.
> > -*/
> > - RTE_ATOMIC(uint16_t) refcnt;
> > + union {
> > + uint64_t rearm_data[1];
> > + __extension__
> > + struct {
> > + uint16_t data_off;
> > +
> > + /**
> > +* Reference counter. Its size should at least equal to
> > the size
> > +* of port field (16 bits), to support zero-copy
> > broadcast.
> > +* It should only be accessed using the following
> > functions:
> > +* rte_mbuf_refcnt_update(), rte_mbuf_refcnt_read(), and
> > +* rte_mbuf_refcnt_set(). The functionality of these
> > functions (atomic,
> > +* or non-atomic) is controlled by the
> > RTE_MBUF_REFCNT_ATOMIC flag.
> > +*/
> > + RTE_ATOMIC(uint16_t) refcnt;
> >
> > - /**
> > -* Number of segments. Only valid for the first segment of an mbuf
> > -* chain.
> > -*/
> > - uint16_t nb_segs;
> > + /**
> > +* Number of segments. Only valid for the first segment
> > of an mbuf
> > +* chain.
> > +*/
> > + uint16_t nb_segs;
> >
> > - /** Input port (16 bits to support more than 256 virtual ports).
> > -* The event eth Tx adapter uses this field to specify the output port.
> > -*/
> > - uint16_t port;
> > + /** Input port (16 bits to support more than 256
> > virtual ports).
> > +* The event eth Tx adapter uses this field to specify
> > the output port.
> > +*/
> > + uint16_t port;
> > + };
> > + };
> >
> > uint64_t ol_flags;/**< Offload features. */
> >
> > /* remaining bytes are set on RX when pulling packet from descriptor */
Re: [PATCH 00/15] fix packing of structs when building with MSVC
On Wed, 20 Mar 2024 14:05:56 -0700 Tyler Retzlaff wrote: > MSVC struct packing is not compatible with GCC provide a macro that can > be used to push existing pack value and sets packing to 1-byte. The > existing __rte_packed macro is then used to restore the pack value > prior to the push. > > Instead of providing macros exclusively for MSVC and for GCC the > existing macro is deliberately utilized to trigger a warning if no > existing packing has been pushed allowing easy identification of > locations where the __rte_msvc_pack is missing. > > I've decided to only add the macro to packed structs that are built > for Windows. It seems there is little value in adding the macro tree > wide and if new code arrives that is built on Windows the __rte_packed > will flag where the preamble macro is required. > Why is packed used so many places in DPDK? Packed should be reserved for things like network protocols with unaligned fields. Many of these structure have no holes and are naturally packed. Adding packed attribute unnecessarily can generate poor code on architectures that do not support unaligned access.
Re: [PATCH 00/15] fix packing of structs when building with MSVC
On Thu, Mar 21, 2024 at 08:32:19AM -0700, Stephen Hemminger wrote: > On Wed, 20 Mar 2024 14:05:56 -0700 > Tyler Retzlaff wrote: > > > MSVC struct packing is not compatible with GCC provide a macro that can > > be used to push existing pack value and sets packing to 1-byte. The > > existing __rte_packed macro is then used to restore the pack value > > prior to the push. > > > > Instead of providing macros exclusively for MSVC and for GCC the > > existing macro is deliberately utilized to trigger a warning if no > > existing packing has been pushed allowing easy identification of > > locations where the __rte_msvc_pack is missing. > > > > I've decided to only add the macro to packed structs that are built > > for Windows. It seems there is little value in adding the macro tree > > wide and if new code arrives that is built on Windows the __rte_packed > > will flag where the preamble macro is required. > > > > Why is packed used so many places in DPDK? > Packed should be reserved for things like network protocols > with unaligned fields. I made the same observation. Even network frame formats can be handled without packing so long as you do some extra work to copy small units of data out which is often worth doing manually and once only instead of obfuscated behind codegen and direct field access. > Many of these structure have no holes and are naturally packed. > Adding packed attribute unnecessarily can generate poor code on > architectures that do not support unaligned access. For the specific case where their fields and alignments are naturally packed I'm not entirely certain you get different codegen but I agree it might and we'd like to avoid it if it does. In a lot of the cases it seems to be drivers and often appears like it is either structs that are used to hardware registers or firmware protocol data units. Both of which may be need packing. I will commit to removing packing in structs in this series iff individual maintainers identify the specific structs in reply to the series. If there is no request I'll leave it to them to figure out. Maintainers should review and request removal as appropriate. Thanks!
Re: [PATCH 02/15] eal: pack structures when building with MSVC
On Wed, Mar 20, 2024 at 02:05:58PM -0700, Tyler Retzlaff wrote:
> Add __rte_msvc_pack to all __rte_packed structs to cause packing
> when building with MSVC.
>
> Signed-off-by: Tyler Retzlaff
> ---
> lib/eal/common/eal_private.h | 1 +
> lib/eal/include/rte_memory.h | 1 +
> lib/eal/include/rte_memzone.h | 1 +
> lib/eal/include/rte_trace_point.h | 1 +
> lib/eal/x86/include/rte_memcpy.h | 3 +++
> 5 files changed, 7 insertions(+)
>
> diff --git a/lib/eal/common/eal_private.h b/lib/eal/common/eal_private.h
> index 71523cf..21ace2a 100644
> --- a/lib/eal/common/eal_private.h
> +++ b/lib/eal/common/eal_private.h
> @@ -43,6 +43,7 @@ struct lcore_config {
> /**
> * The global RTE configuration structure.
> */
> +__rte_msvc_pack
> struct rte_config {
> uint32_t main_lcore; /**< Id of the main lcore */
> uint32_t lcore_count;/**< Number of available logical cores. */
This struct almost certainly doesn't need to be packed - since it's in a
private header, I would imagine removing packing wouldn't be an ABI
break.
Also, removing rte_packed doesn't change the size for me for a 64-bit x86
build. Looking at the struct, I don't see why it would change on a 32-bit
build either.
> diff --git a/lib/eal/include/rte_memory.h b/lib/eal/include/rte_memory.h
> index 842362d..73bb00d 100644
> --- a/lib/eal/include/rte_memory.h
> +++ b/lib/eal/include/rte_memory.h
> @@ -46,6 +46,7 @@
> /**
> * Physical memory segment descriptor.
> */
> +__rte_msvc_pack
> struct rte_memseg {
> rte_iova_t iova;/**< Start IO address. */
> union {
> diff --git a/lib/eal/include/rte_memzone.h b/lib/eal/include/rte_memzone.h
> index 931497f..ca312c0 100644
> --- a/lib/eal/include/rte_memzone.h
> +++ b/lib/eal/include/rte_memzone.h
> @@ -45,6 +45,7 @@
> * A structure describing a memzone, which is a contiguous portion of
> * physical memory identified by a name.
> */
> +__rte_msvc_pack
> struct rte_memzone {
>
This also doesn't look like it should be packed. It is a public header
though so we may need to be more careful. Checking a 64-bit x86 build shows
no size change when removing the "packed" attribute, though. For 32-bit, I
think the "size_t" field in the middle would be followed by padding on
32-bit if we removed the "packed" attribute, so it may be a no-go for now.
:-(
> #define RTE_MEMZONE_NAMESIZE 32 /**< Maximum length of memory zone
> name.*/
> diff --git a/lib/eal/include/rte_trace_point.h
> b/lib/eal/include/rte_trace_point.h
> index 41e2a7f..63f333c 100644
> --- a/lib/eal/include/rte_trace_point.h
> +++ b/lib/eal/include/rte_trace_point.h
> @@ -292,6 +292,7 @@ int __rte_trace_point_register(rte_trace_point_t *trace,
> const char *name,
> #define __RTE_TRACE_FIELD_ENABLE_MASK (1ULL << 63)
> #define __RTE_TRACE_FIELD_ENABLE_DISCARD (1ULL << 62)
>
> +__rte_msvc_pack
> struct __rte_trace_stream_header {
> uint32_t magic;
> rte_uuid_t uuid;
>From code review, this doesn't look like "packed" has any impact, since all
fields should naturally be aligned on both 32-bit and 64-bit builds.
/Bruce
Re: [PATCH v3] dmadev: fix structure alignment
On Thu, Mar 21, 2024 at 11:06:34AM +0100, Thomas Monjalon wrote:
> 21/03/2024 10:18, Ma, WenwuX:
> > From: Thomas Monjalon
> > > 21/03/2024 02:25, Ma, WenwuX:
> > > > From: Thomas Monjalon
> > > > > 20/03/2024 08:23, Wenwu Ma:
> > > > > > The structure rte_dma_dev needs to be aligned to the cache line,
> > > > > > but the return value of malloc may not be aligned to the cache
> > > > > > line. When we use memset to clear the rte_dma_dev object, it may
> > > > > > cause a segmentation fault in clang-x86-platform.
> > > > > >
> > > > > > This is because clang uses the "vmovaps" assembly instruction for
> > > > > > memset, which requires that the operands (rte_dma_dev objects)
> > > > > > must aligned on a 16-byte boundary or a general-protection
> > > > > > exception (#GP) is generated.
> > > > > >
> > > > > > Therefore, either additional memory is applied for re-alignment,
> > > > > > or the rte_dma_dev object does not require cache line alignment.
> > > > > > The patch chooses the former option to fix the issue.
> > > > > >
> > > > > > Fixes: b36970f2e13e ("dmadev: introduce DMA device library")
> > > > > > Cc: sta...@dpdk.org
> > > > > >
> > > > > > Signed-off-by: Wenwu Ma
> > > > > [..]
> > > > > > - size = dma_devices_max * sizeof(struct rte_dma_dev);
> > > > > > - rte_dma_devices = malloc(size);
> > > > > > - if (rte_dma_devices == NULL)
> > > > > > + /* The dma device object is expected to align cacheline, but
> > > > > > +* the return value of malloc may not be aligned to the cache
> > > > > > line.
> > > > > > +* Therefore, extra memory is applied for realignment.
> > > > > > +* note: We do not call posix_memalign/aligned_alloc because it
> > > > > > is
> > > > > > +* version dependent on libc.
> > > > > > +*/
> > > > > > + size = dma_devices_max * sizeof(struct rte_dma_dev) +
> > > > > > + RTE_CACHE_LINE_SIZE;
> > > > > > + ptr = malloc(size);
> > > > > > + if (ptr == NULL)
> > > > > > return -ENOMEM;
> > > > > > - memset(rte_dma_devices, 0, size);
> > > > > > + memset(ptr, 0, size);
> > > > > > +
> > > > > > + rte_dma_devices = RTE_PTR_ALIGN(ptr, RTE_CACHE_LINE_SIZE);
> > > > >
> > > > > Why not using aligned_alloc()?
> > > > > https://en.cppreference.com/w/c/memory/aligned_alloc
> > > > >
> > > > >
> > > > because it is version dependent on libc.
> > >
> > > Which libc is required?
> > >
> >
> > using the 'man aligned_alloc' command, we has the following description:
> >
> > VERSIONS
> >The functions memalign(), valloc(), and pvalloc() have been
> > available in all Linux libc libraries.
> >
> >The function aligned_alloc() was added to glibc in version 2.16.
>
> released in 2012-06-30
If we are using C11 we probably already implicitly depend on the glibc
that supports aligned_alloc (introduced in C11).
>
> >The function posix_memalign() is available since glibc 2.1.91.
>
> I think we could bump our libc requirements for these functions.
>
> I understand there is also a concern on Windows,
> but an alternative exists there.
> We may need a wrapper like "rte_alloc_align".
Yes, I'm afraid we would probably have to introduce
rte_aligned_alloc/rte_aligned_free. On Windows this would simply
forward to _aligned_alloc() and _aligned_free() respectively.
ty
[PATCH v10 07/10] eal: allow user to set default log stream before init
It is useful for application to be able to set the default log
stream before call rte_eal_init(). This makes all messages go
to the new default.
For example, to skip using syslog; just doing
rte_openlog_stream(stderr);
There is no reason for helper command line applications to clutter
syslog with messages.
Signed-off-by: Stephen Hemminger
---
app/dumpcap/main.c | 3 +++
app/pdump/main.c | 3 +++
app/proc-info/main.c | 3 +++
lib/log/log.c | 6 ++
lib/log/log_internal.h | 2 ++
lib/log/log_unix.c | 4
lib/log/version.map| 1 +
7 files changed, 22 insertions(+)
diff --git a/app/dumpcap/main.c b/app/dumpcap/main.c
index cc0f66b2bc61..27934ca7e688 100644
--- a/app/dumpcap/main.c
+++ b/app/dumpcap/main.c
@@ -633,6 +633,9 @@ static void dpdk_init(void)
rte_panic("No memory\n");
}
+ /* keep any logging away from syslog. */
+ rte_openlog_stream(stderr);
+
if (rte_eal_init(eal_argc, eal_argv) < 0)
rte_exit(EXIT_FAILURE, "EAL init failed: is primary process
running?\n");
}
diff --git a/app/pdump/main.c b/app/pdump/main.c
index a9205e130bb1..7b9ba68b1a14 100644
--- a/app/pdump/main.c
+++ b/app/pdump/main.c
@@ -995,6 +995,9 @@ main(int argc, char **argv)
argc += 2;
+ /* keep any logging away from syslog. */
+ rte_openlog_stream(stderr);
+
diag = rte_eal_init(argc, argp);
if (diag < 0)
rte_panic("Cannot init EAL\n");
diff --git a/app/proc-info/main.c b/app/proc-info/main.c
index b672aaefbe99..24ee52c4ac7a 100644
--- a/app/proc-info/main.c
+++ b/app/proc-info/main.c
@@ -2149,6 +2149,9 @@ main(int argc, char **argv)
argc += 4;
+ /* keep any logging away from syslog. */
+ rte_openlog_stream(stderr);
+
ret = rte_eal_init(argc, argp);
if (ret < 0)
rte_panic("Cannot init EAL\n");
diff --git a/lib/log/log.c b/lib/log/log.c
index 255f757d94cc..4cc944305057 100644
--- a/lib/log/log.c
+++ b/lib/log/log.c
@@ -519,6 +519,12 @@ eal_log_set_default(FILE *default_log)
#endif
}
+FILE *
+eal_log_get_default(void)
+{
+ return default_log_stream;
+}
+
/*
* Called by eal_cleanup
*/
diff --git a/lib/log/log_internal.h b/lib/log/log_internal.h
index 451629f1c1ba..c77e687e28bc 100644
--- a/lib/log/log_internal.h
+++ b/lib/log/log_internal.h
@@ -21,6 +21,8 @@ int eal_log_init(const char *id, int facility);
*/
__rte_internal
void eal_log_set_default(FILE *default_log);
+__rte_internal
+FILE *eal_log_get_default(void);
/*
* Save a log option for later.
diff --git a/lib/log/log_unix.c b/lib/log/log_unix.c
index ae38b4bf3a59..c56f80ac6967 100644
--- a/lib/log/log_unix.c
+++ b/lib/log/log_unix.c
@@ -49,6 +49,10 @@ eal_log_init(const char *id, int facility)
{
FILE *log_stream;
+ /* skip if user has already setup a log stream */
+ if (eal_log_get_default())
+ return 0;
+
log_stream = fopencookie(NULL, "w+", console_log_func);
if (log_stream == NULL)
return -1;
diff --git a/lib/log/version.map b/lib/log/version.map
index 0648f8831aff..6ecc656d1d65 100644
--- a/lib/log/version.map
+++ b/lib/log/version.map
@@ -25,6 +25,7 @@ DPDK_24 {
INTERNAL {
global:
+ eal_log_get_default;
eal_log_init;
eal_log_level2str;
eal_log_save_pattern;
--
2.43.0
Re: [PATCH 07/15] dma/ioat: pack structures when building with MSVC
On Wed, Mar 20, 2024 at 02:06:03PM -0700, Tyler Retzlaff wrote:
> Add __rte_msvc_pushpack(1) to all __rte_packed structs to cause packing
> when building with MSVC.
>
> Signed-off-by: Tyler Retzlaff
> ---
> drivers/dma/ioat/ioat_hw_defs.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma/ioat/ioat_hw_defs.h b/drivers/dma/ioat/ioat_hw_defs.h
> index dc3493a..6e32807 100644
> --- a/drivers/dma/ioat/ioat_hw_defs.h
> +++ b/drivers/dma/ioat/ioat_hw_defs.h
> @@ -52,6 +52,7 @@
> #define IOAT_DMACAP_PQ (1 << 9)
> #define IOAT_DMACAP_DMA_DIF (1 << 10)
>
> +__rte_msvc_pack
> struct ioat_registers {
> uint8_t chancnt;
> uint8_t xfercap;
This struct has all gaps explicitly filled, so packed should not be
necessary. Struct has same size with and without the attribute.
/Bruce
[PATCH v10 10/10] doc: add documentation of logging options
Add documentation of new log-timestamp and log-color options. Signed-off-by: Stephen Hemminger --- doc/guides/linux_gsg/eal_args.include.rst | 54 +++ 1 file changed, 46 insertions(+), 8 deletions(-) diff --git a/doc/guides/linux_gsg/eal_args.include.rst b/doc/guides/linux_gsg/eal_args.include.rst index 9cfbf7de8456..8ba54a62c0f9 100644 --- a/doc/guides/linux_gsg/eal_args.include.rst +++ b/doc/guides/linux_gsg/eal_args.include.rst @@ -122,6 +122,52 @@ Memory-related options to system pthread stack size unless the optional size (in kbytes) is specified. +Logging options +~~~ + +* ``--log-level `` + +Specify log level for a specific component. For example:: + +--log-level lib.eal:debug + +Can be specified multiple times. + +* ``--log-facility=facility`` + +Specifies the ``syslog`` facility passed to ``openlog``. +The facility can be: ``auth``, ``cron``, ``daemon``, ``ftp``, +``lpr``, ``mail``, ``news``, ``user``, ``uucp``, +``local0``, ``local1``, ``local2``, ``local3``, ``local4``, +``local5``, ``local6``, or ``local7``. The default if +no facility is specified is ``daemon``. + +* ``--log-timestamp[=format]`` + +Add a time stamp to log messages that are sent to the console (stderr). +When format argument is omitted the time stamp is elapsed +seconds since the start of the DPDK application. +Other formats are: + +.. csv-table:: Log time stamp format + :header: "Format", "Description", "Example" + :widths: 6, 30, 32 + + "ctime", "Unix ctime", "``[Wed Mar 20 07:26:12 2024]``" + "delta", "Offset since last", "``[<3.162373>]``" + "reltime", "Seconds since last or time if minute changed", "``[ +3.001791]`` or ``[Mar20 07:26:12]``" + "iso", "ISO-8601", "``[2024-03-20T07:26:12−07:00]``" + +* ``--log-color[=when]`` + +Colorize the console output. +The optional argument ``when`` can be ``auto``, ``never`` or ``always``. +If the when argument is omitted, it defaults to ``auto``. +To disable use of color:: + +--log-color=none + + Debugging options ~ @@ -134,14 +180,6 @@ Debugging options Use anonymous memory instead of hugepages (implies no secondary process support). -* ``--log-level `` - -Specify log level for a specific component. For example:: - ---log-level lib.eal:debug - -Can be specified multiple times. - * ``--trace=`` Enable trace based on regular expression trace name. By default, the trace is -- 2.43.0
[PATCH v10 05/10] eal: do not duplicate rte_init_alert() messages
The message already goes through logging, and does not need
to be printed on stderr. Message level should be ALERT
to match function name.
Signed-off-by: Stephen Hemminger
---
lib/eal/freebsd/eal.c | 3 +--
lib/eal/linux/eal.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
index 70176339..e3f25f619715 100644
--- a/lib/eal/freebsd/eal.c
+++ b/lib/eal/freebsd/eal.c
@@ -530,8 +530,7 @@ rte_eal_iopl_init(void)
static void rte_eal_init_alert(const char *msg)
{
- fprintf(stderr, "EAL: FATAL: %s\n", msg);
- EAL_LOG(ERR, "%s", msg);
+ EAL_LOG(ALERT, "%s", msg);
}
/* Launch threads, called at application init(). */
diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c
index e515f3cbc8a8..461f0c093357 100644
--- a/lib/eal/linux/eal.c
+++ b/lib/eal/linux/eal.c
@@ -840,8 +840,7 @@ static int rte_eal_vfio_setup(void)
static void rte_eal_init_alert(const char *msg)
{
- fprintf(stderr, "EAL: FATAL: %s\n", msg);
- EAL_LOG(ERR, "%s", msg);
+ EAL_LOG(ALERT, "%s", msg);
}
/*
--
2.43.0
[PATCH v10 09/10] log: colorize log output
Like dmesg, colorize the log output (unless redirected to file).
Timestamp is green, the subsystem is in yellow and the message
is red if urgent, boldface if an error, and normal for info and
debug messages.
Signed-off-by: Stephen Hemminger
---
lib/eal/common/eal_common_options.c | 10 +++
lib/eal/common/eal_options.h| 2 +
lib/log/log_internal.h | 5 ++
lib/log/log_unix.c | 132 +---
lib/log/log_windows.c | 6 ++
lib/log/version.map | 1 +
6 files changed, 146 insertions(+), 10 deletions(-)
diff --git a/lib/eal/common/eal_common_options.c
b/lib/eal/common/eal_common_options.c
index 4e2c3d0f255c..522634f1dcfa 100644
--- a/lib/eal/common/eal_common_options.c
+++ b/lib/eal/common/eal_common_options.c
@@ -78,6 +78,7 @@ eal_long_options[] = {
{OPT_LCORES,1, NULL, OPT_LCORES_NUM },
{OPT_LOG_LEVEL, 1, NULL, OPT_LOG_LEVEL_NUM},
{OPT_LOG_TIMESTAMP, 2, NULL, OPT_LOG_TIMESTAMP_NUM},
+ {OPT_LOG_COLOR, 1, NULL, OPT_LOG_COLOR_NUM},
{OPT_TRACE, 1, NULL, OPT_TRACE_NUM},
{OPT_TRACE_DIR, 1, NULL, OPT_TRACE_DIR_NUM},
{OPT_TRACE_BUF_SIZE,1, NULL, OPT_TRACE_BUF_SIZE_NUM },
@@ -1910,6 +1911,15 @@ eal_parse_common_option(int opt, const char *optarg,
}
break;
+
+ case OPT_LOG_COLOR_NUM:
+ if (eal_log_color(optarg) < 0) {
+ EAL_LOG(ERR, "invalid parameters for --"
+ OPT_LOG_COLOR);
+ return -1;
+ }
+ break;
+
case OPT_TRACE_NUM: {
if (eal_trace_args_save(optarg) < 0) {
EAL_LOG(ERR, "invalid parameters for --"
diff --git a/lib/eal/common/eal_options.h b/lib/eal/common/eal_options.h
index e24c9eca53ca..5a63c1dd3a32 100644
--- a/lib/eal/common/eal_options.h
+++ b/lib/eal/common/eal_options.h
@@ -37,6 +37,8 @@ enum {
OPT_LOG_LEVEL_NUM,
#define OPT_LOG_TIMESTAMP "log-timestamp"
OPT_LOG_TIMESTAMP_NUM,
+#define OPT_LOG_COLOR"log-color"
+ OPT_LOG_COLOR_NUM,
#define OPT_TRACE "trace"
OPT_TRACE_NUM,
#define OPT_TRACE_DIR "trace-dir"
diff --git a/lib/log/log_internal.h b/lib/log/log_internal.h
index 0e18d147cf98..b90c668f4668 100644
--- a/lib/log/log_internal.h
+++ b/lib/log/log_internal.h
@@ -52,5 +52,10 @@ void rte_eal_log_cleanup(void);
__rte_internal
int eal_log_timestamp(const char *fmt);
+/*
+ * Enable or disable color in log messages
+ */
+__rte_internal
+int eal_log_color(const char *mode);
#endif /* LOG_INTERNAL_H */
diff --git a/lib/log/log_unix.c b/lib/log/log_unix.c
index cb8f17bc83ef..1af93795fec5 100644
--- a/lib/log/log_unix.c
+++ b/lib/log/log_unix.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include "log_internal.h"
@@ -24,15 +25,113 @@ enum eal_log_time_format {
EAL_LOG_TIMESTAMP_ISO,
};
+enum eal_log_color {
+ EAL_LOG_COLOR_AUTO = 0, /* default */
+ EAL_LOG_COLOR_NEVER,
+ EAL_LOG_COLOR_ALWAYS,
+};
+
static struct {
+ enum eal_log_color color_mode;
enum eal_log_time_format time_format;
+ bool show_color;
struct timespec start_time;
struct timespec last_time;
struct tm last_tm;
} log = {
+ .color_mode = EAL_LOG_COLOR_AUTO,
.time_format = EAL_LOG_TIMESTAMP_NONE,
};
+enum color {
+ COLOR_NONE,
+ COLOR_RED,
+ COLOR_GREEN,
+ COLOR_YELLOW,
+ COLOR_BLUE,
+ COLOR_MAGENTA,
+ COLOR_CYAN,
+ COLOR_WHITE,
+ COLOR_BOLD,
+ COLOR_CLEAR
+};
+
+static const char * const color_code[] = {
+ [COLOR_NONE]= "",
+ [COLOR_RED] = "\e[31m",
+ [COLOR_GREEN] = "\e[32m",
+ [COLOR_YELLOW] = "\e[33m",
+ [COLOR_BLUE]= "\e[34m",
+ [COLOR_MAGENTA] = "\e[35m",
+ [COLOR_CYAN]= "\e[36m",
+ [COLOR_WHITE] = "\e[37m",
+ [COLOR_BOLD]= "\e[1m",
+ [COLOR_CLEAR] = "\e[0m",
+};
+
+__rte_format_printf(3, 4)
+static int color_fprintf(FILE *out, enum color color, const char *fmt, ...)
+{
+ va_list args;
+ int ret = 0;
+
+ va_start(args, fmt);
+ ret = fprintf(out, "%s", color_code[color]);
+ ret += vfprintf(out, fmt, args);
+ ret += fprintf(out, "%s", color_code[COLOR_CLEAR]);
+
+ return ret;
+}
+
+static ssize_t
+color_log_write(FILE *f, int level, const char *msg, size_t size)
+{
+ size_t i;
+ ssize_t ret = 0;
+
+ /* find first : delimiter in message */
+ for (i = 0; i < size; i++) {
+ if (msg[i] == ':') {
+ ++i; /* put colon in the color */
+ ret = color_fprintf(stderr, COLOR_YELLOW, "%.*s",
(int)i, msg);
+ msg += i;
+
[PATCH v10 01/10] windows: make getopt functions have const properties
Having different prototypes on different platforms can lead
to lots of unnecessary workarounds. Looks like the version of
getopt used from windows was based on an older out of date
version from FreeBSD.
This patch changes getopt, getopt_long, etc to have the same const
attributes as Linux and FreeBSD. The changes are derived from
the current FreeBSD version of getopt_long.
Signed-off-by: Stephen Hemminger
Acked-by: Tyler Retzlaff
Acked-by: Dmitry Kozlyuk
---
lib/eal/windows/getopt.c | 23 ---
lib/eal/windows/include/getopt.h | 8
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/lib/eal/windows/getopt.c b/lib/eal/windows/getopt.c
index a1f51c6c2318..50ff71b9300d 100644
--- a/lib/eal/windows/getopt.c
+++ b/lib/eal/windows/getopt.c
@@ -20,7 +20,7 @@
#include
#include
-const char*optarg; /* argument associated with option */
+char*optarg; /* argument associated with option */
intopterr = 1; /* if error message should be printed */
intoptind = 1; /* index into parent argv vector */
intoptopt = '?'; /* character checked for validity */
@@ -39,9 +39,9 @@ static void pass(const char *a) {(void) a; }
#defineBADARG ((*options == ':') ? (int)':' : (int)'?')
#defineINORDER 1
-#defineEMSG""
+static char EMSG[] = "";
-static const char *place = EMSG; /* option letter processing */
+static char *place = EMSG; /* option letter processing */
/* XXX: set optreset to 1 rather than these two */
static int nonopt_start = -1; /* first non option argument (for permute) */
@@ -80,7 +80,7 @@ gcd(int a, int b)
*/
static void
permute_args(int panonopt_start, int panonopt_end, int opt_end,
- char **nargv)
+ char * const *nargv)
{
int cstart, cyclelen, i, j, ncycle, nnonopts, nopts, pos;
char *swap;
@@ -101,11 +101,12 @@ permute_args(int panonopt_start, int panonopt_end, int
opt_end,
pos -= nnonopts;
else
pos += nopts;
+
swap = nargv[pos];
/* LINTED const cast */
- ((char **) nargv)[pos] = nargv[cstart];
+ ((char **)(uintptr_t)nargv)[pos] = nargv[cstart];
/* LINTED const cast */
- ((char **)nargv)[cstart] = swap;
+ ((char **)(uintptr_t)nargv)[cstart] = swap;
}
}
}
@@ -116,7 +117,7 @@ permute_args(int panonopt_start, int panonopt_end, int
opt_end,
* Returns -1 if short_too is set and the option does not match long_options.
*/
static int
-parse_long_options(char **nargv, const char *options,
+parse_long_options(char * const *nargv, const char *options,
const struct option *long_options, int *idx, int short_too)
{
const char *current_argv;
@@ -236,7 +237,7 @@ parse_long_options(char **nargv, const char *options,
* Parse argc/argv argument vector. Called by user level routines.
*/
static int
-getopt_internal(int nargc, char **nargv, const char *options,
+getopt_internal(int nargc, char *const nargv[], const char *options,
const struct option *long_options, int *idx, int flags)
{
char *oli; /* option letter list index */
@@ -434,7 +435,7 @@ getopt_internal(int nargc, char **nargv, const char
*options,
* Parse argc/argv argument vector.
*/
int
-getopt(int nargc, char *nargv[], const char *options)
+getopt(int nargc, char *const nargv[], const char *options)
{
return getopt_internal(nargc, nargv, options, NULL, NULL,
FLAG_PERMUTE);
@@ -445,7 +446,7 @@ getopt(int nargc, char *nargv[], const char *options)
* Parse argc/argv argument vector.
*/
int
-getopt_long(int nargc, char *nargv[], const char *options,
+getopt_long(int nargc, char *const nargv[], const char *options,
const struct option *long_options, int *idx)
{
@@ -458,7 +459,7 @@ getopt_long(int nargc, char *nargv[], const char *options,
* Parse argc/argv argument vector.
*/
int
-getopt_long_only(int nargc, char *nargv[], const char *options,
+getopt_long_only(int nargc, char *const nargv[], const char *options,
const struct option *long_options, int *idx)
{
diff --git a/lib/eal/windows/include/getopt.h b/lib/eal/windows/include/getopt.h
index 6f57af454b17..e4cf6873cb0c 100644
--- a/lib/eal/windows/include/getopt.h
+++ b/lib/eal/windows/include/getopt.h
@@ -44,7 +44,7 @@
/** argument to current option, or NULL if it has none */
-extern const char *optarg;
+extern char *optarg;
/** Current position in arg string. Starts from 1.
* Setting to 0 resets state.
*/
@@ -80,14 +80,14 @@ struct option {
};
/** Compat: getopt */
-int getopt(int argc, char *argv[], const char *options);
+int getopt(int argc, cha
[PATCH v10 00/10] Logging enhancements.
Improvements and unification of logging library (for 24.07 release). This is update to earlier patch set. It adds two new features to the console log output. * Putting a timestamp on console output which is useful for analyzing performance of startup codes. Timestamp is optional and must be enabled on command line. The message going into syslog is already timestamped (by syslog) so no additional timestamp is needed. * Displaying console output with colors. It uses the standard conventions used by many other Linux commands for colorized display. The default is to enable color if the console output is going to a terminal. But it can be always on or disabled by command line flag. This default was chosen based on what dmesg(1) command does. I find color helpful because DPDK drivers and libraries print lots of not very useful messages. And having error messages highlighted in bold face helps. This might also get users to pay more attention to error messages. Many bug reports have earlier messages that are lost because there are so many info messages. Note: neither of these are possible on Windows because the fopencookie() function is a GNU libc and not Posix feature. Will add a release note in next release (after this is merged). v10 - put windows getopt patch in series since otherwise windows build fails. - support multiple timestamp formats - support colorized output - fix up rte_init_alert() and rte_exit() to match format expected by the timestamp and color modes - initialize logging much earlier in startup - add documentation about logging options Stephen Hemminger (10): windows: make getopt functions have const properties log: unify logging code eal: make eal_log_level_parse common eal: initialize log earlier in startup eal: do not duplicate rte_init_alert() messages eal: change rte_exit() output to match rte_log() eal: allow user to set default log stream before init eal: add option to put timestamp on console output log: colorize log output doc: add documentation of logging options app/dumpcap/main.c| 3 + app/pdump/main.c | 3 + app/proc-info/main.c | 3 + app/test/test_eal_flags.c | 17 + doc/guides/linux_gsg/eal_args.include.rst | 54 ++- doc/guides/linux_gsg/linux_eal_parameters.rst | 27 -- doc/guides/prog_guide/log_lib.rst | 28 +- lib/eal/common/eal_common_debug.c | 11 +- lib/eal/common/eal_common_options.c | 70 +++- lib/eal/common/eal_options.h | 5 + lib/eal/freebsd/eal.c | 53 +-- lib/eal/linux/eal.c | 58 +--- lib/eal/unix/eal_unix_log.c | 0 lib/eal/windows/eal.c | 35 -- lib/eal/windows/getopt.c | 23 +- lib/eal/windows/include/getopt.h | 8 +- lib/log/log.c | 6 + lib/log/log_freebsd.c | 12 - lib/log/log_internal.h| 16 + lib/log/log_linux.c | 61 lib/log/log_unix.c| 321 ++ lib/log/log_windows.c | 12 + lib/log/meson.build | 12 +- lib/log/version.map | 3 + 24 files changed, 577 insertions(+), 264 deletions(-) create mode 100644 lib/eal/unix/eal_unix_log.c delete mode 100644 lib/log/log_freebsd.c delete mode 100644 lib/log/log_linux.c create mode 100644 lib/log/log_unix.c -- 2.43.0
[PATCH v10 04/10] eal: initialize log earlier in startup
Want to make sure that as many log messages as possible
get added with the real log stream. Despite the comment,
there is no dependency on memzones in current code.
Signed-off-by: Stephen Hemminger
---
lib/eal/freebsd/eal.c | 14 +++---
lib/eal/linux/eal.c | 16
lib/eal/unix/eal_unix_log.c | 0
lib/log/log_unix.c | 4 ++--
4 files changed, 17 insertions(+), 17 deletions(-)
create mode 100644 lib/eal/unix/eal_unix_log.c
diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
index 94927472edfe..70176339 100644
--- a/lib/eal/freebsd/eal.c
+++ b/lib/eal/freebsd/eal.c
@@ -571,6 +571,13 @@ rte_eal_init(int argc, char **argv)
/* set log level as early as possible */
eal_log_level_parse(argc, argv);
+ if (eal_log_init(getprogname(), internal_conf->syslog_facility) < 0) {
+ rte_eal_init_alert("Cannot init logging.");
+ rte_errno = ENOMEM;
+ rte_atomic_store_explicit(&run_once, 0,
rte_memory_order_relaxed);
+ return -1;
+ }
+
if (rte_eal_cpu_init() < 0) {
rte_eal_init_alert("Cannot detect lcores.");
rte_errno = ENOTSUP;
@@ -719,13 +726,6 @@ rte_eal_init(int argc, char **argv)
#endif
}
- if (eal_log_init(getprogname(), internal_conf->syslog_facility) < 0) {
- rte_eal_init_alert("Cannot init logging.");
- rte_errno = ENOMEM;
- rte_atomic_store_explicit(&run_once, 0,
rte_memory_order_relaxed);
- return -1;
- }
-
/* in secondary processes, memory init may allocate additional fbarrays
* not present in primary processes, so to avoid any potential issues,
* initialize memzones first.
diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c
index bffeb1f34eb9..e515f3cbc8a8 100644
--- a/lib/eal/linux/eal.c
+++ b/lib/eal/linux/eal.c
@@ -959,6 +959,14 @@ rte_eal_init(int argc, char **argv)
/* clone argv to report out later in telemetry */
eal_save_args(argc, argv);
+ if (eal_log_init(program_invocation_short_name,
+internal_conf->syslog_facility) < 0) {
+ rte_eal_init_alert("Cannot init logging.");
+ rte_errno = ENOMEM;
+ rte_atomic_store_explicit(&run_once, 0,
rte_memory_order_relaxed);
+ return -1;
+ }
+
if (rte_eal_cpu_init() < 0) {
rte_eal_init_alert("Cannot detect lcores.");
rte_errno = ENOTSUP;
@@ -1107,14 +1115,6 @@ rte_eal_init(int argc, char **argv)
#endif
}
- if (eal_log_init(program_invocation_short_name,
-internal_conf->syslog_facility) < 0) {
- rte_eal_init_alert("Cannot init logging.");
- rte_errno = ENOMEM;
- rte_atomic_store_explicit(&run_once, 0,
rte_memory_order_relaxed);
- return -1;
- }
-
#ifdef VFIO_PRESENT
if (rte_eal_vfio_setup() < 0) {
rte_eal_init_alert("Cannot init VFIO");
diff --git a/lib/eal/unix/eal_unix_log.c b/lib/eal/unix/eal_unix_log.c
new file mode 100644
index ..e69de29bb2d1
diff --git a/lib/log/log_unix.c b/lib/log/log_unix.c
index 2dfb0c974b1d..ae38b4bf3a59 100644
--- a/lib/log/log_unix.c
+++ b/lib/log/log_unix.c
@@ -41,8 +41,8 @@ static cookie_io_functions_t console_log_func = {
};
/*
- * set the log to default function, called during eal init process,
- * once memzones are available.
+ * set the log to default function, called early in eal init process;
+ * before lcore's and memzones are setup.
*/
int
eal_log_init(const char *id, int facility)
--
2.43.0
[PATCH v10 03/10] eal: make eal_log_level_parse common
The code to parse for log-level option should be same on
all OS variants.
Signed-off-by: Stephen Hemminger
---
lib/eal/common/eal_common_options.c | 46 +
lib/eal/common/eal_options.h| 1 +
lib/eal/freebsd/eal.c | 42 --
lib/eal/linux/eal.c | 39
lib/eal/windows/eal.c | 35 --
5 files changed, 47 insertions(+), 116 deletions(-)
diff --git a/lib/eal/common/eal_common_options.c
b/lib/eal/common/eal_common_options.c
index e541f0793964..7310d10dfd78 100644
--- a/lib/eal/common/eal_common_options.c
+++ b/lib/eal/common/eal_common_options.c
@@ -1640,6 +1640,51 @@ eal_parse_huge_unlink(const char *arg, struct
hugepage_file_discipline *out)
return -1;
}
+/* Parse the all arguments looking for --log-level */
+int
+eal_log_level_parse(int argc, char * const argv[])
+{
+ struct internal_config *internal_conf =
eal_get_internal_configuration();
+ int option_index, opt;
+ const int old_optind = optind;
+ const int old_optopt = optopt;
+ const int old_opterr = opterr;
+ char *old_optarg = optarg;
+#ifdef RTE_EXEC_ENV_FREEBSD
+ const int old_optreset = optreset;
+ optreset = 1;
+#endif
+
+ optind = 1;
+ opterr = 0;
+
+ while ((opt = getopt_long(argc, argv, eal_short_options,
+ eal_long_options, &option_index)) != EOF) {
+
+ switch (opt) {
+ case OPT_LOG_LEVEL_NUM:
+ if (eal_parse_common_option(opt, optarg, internal_conf)
< 0)
+ return -1;
+ break;
+ case '?':
+ /* getopt is not happy, stop right now */
+ goto out;
+ default:
+ continue;
+ }
+ }
+out:
+ /* restore getopt lib */
+ optind = old_optind;
+ optopt = old_optopt;
+ optarg = old_optarg;
+ opterr = old_opterr;
+#ifdef RTE_EXEC_ENV_FREEBSD
+ optreset = old_optreset;
+#endif
+ return 0;
+}
+
int
eal_parse_common_option(int opt, const char *optarg,
struct internal_config *conf)
@@ -2173,6 +2218,7 @@ rte_vect_set_max_simd_bitwidth(uint16_t bitwidth)
return 0;
}
+
void
eal_common_usage(void)
{
diff --git a/lib/eal/common/eal_options.h b/lib/eal/common/eal_options.h
index 3cc9cb641284..f3f2e104f6d7 100644
--- a/lib/eal/common/eal_options.h
+++ b/lib/eal/common/eal_options.h
@@ -96,6 +96,7 @@ enum {
extern const char eal_short_options[];
extern const struct option eal_long_options[];
+int eal_log_level_parse(int argc, char * const argv[]);
int eal_parse_common_option(int opt, const char *argv,
struct internal_config *conf);
int eal_option_device_parse(void);
diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
index a57ee8406f0c..94927472edfe 100644
--- a/lib/eal/freebsd/eal.c
+++ b/lib/eal/freebsd/eal.c
@@ -364,48 +364,6 @@ eal_get_hugepage_mem_size(void)
return (size < SIZE_MAX) ? (size_t)(size) : SIZE_MAX;
}
-/* Parse the arguments for --log-level only */
-static void
-eal_log_level_parse(int argc, char **argv)
-{
- int opt;
- char **argvopt;
- int option_index;
- const int old_optind = optind;
- const int old_optopt = optopt;
- const int old_optreset = optreset;
- char * const old_optarg = optarg;
- struct internal_config *internal_conf =
- eal_get_internal_configuration();
-
- argvopt = argv;
- optind = 1;
- optreset = 1;
-
- while ((opt = getopt_long(argc, argvopt, eal_short_options,
- eal_long_options, &option_index)) != EOF) {
-
- int ret;
-
- /* getopt is not happy, stop right now */
- if (opt == '?')
- break;
-
- ret = (opt == OPT_LOG_LEVEL_NUM) ?
- eal_parse_common_option(opt, optarg, internal_conf) : 0;
-
- /* common parser is not happy */
- if (ret < 0)
- break;
- }
-
- /* restore getopt lib */
- optind = old_optind;
- optopt = old_optopt;
- optreset = old_optreset;
- optarg = old_optarg;
-}
-
/* Parse the argument given in the command line of the application */
static int
eal_parse_args(int argc, char **argv)
diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c
index fd422f1f6236..bffeb1f34eb9 100644
--- a/lib/eal/linux/eal.c
+++ b/lib/eal/linux/eal.c
@@ -546,45 +546,6 @@ eal_parse_vfio_vf_token(const char *vf_token)
return -1;
}
-/* Parse the arguments for --log-level only */
-static void
-eal_log_level_parse(int argc, char **argv)
-{
- int opt;
- char **argvopt;
- int option_index;
- const int old_optind = optind;
-
[PATCH v10 02/10] log: unify logging code
FreeBSD and Linux logging code can use common code. This also
fixes FreeBSD not using syslog.
Signed-off-by: Stephen Hemminger
---
doc/guides/linux_gsg/linux_eal_parameters.rst | 27 ---
doc/guides/prog_guide/log_lib.rst | 18 +++--
lib/eal/freebsd/eal.c | 8 ++
lib/log/log_freebsd.c | 12 -
lib/log/{log_linux.c => log_unix.c} | 0
lib/log/meson.build | 12 ++---
6 files changed, 32 insertions(+), 45 deletions(-)
delete mode 100644 lib/log/log_freebsd.c
rename lib/log/{log_linux.c => log_unix.c} (100%)
diff --git a/doc/guides/linux_gsg/linux_eal_parameters.rst
b/doc/guides/linux_gsg/linux_eal_parameters.rst
index ea8f38139119..d86f94d8a85d 100644
--- a/doc/guides/linux_gsg/linux_eal_parameters.rst
+++ b/doc/guides/linux_gsg/linux_eal_parameters.rst
@@ -108,30 +108,3 @@ Memory-related options
* ``--match-allocations``
Free hugepages back to system exactly as they were originally allocated.
-
-Other options
-~
-
-* ``--syslog ``
-
-Set syslog facility. Valid syslog facilities are::
-
-auth
-cron
-daemon
-ftp
-kern
-lpr
-mail
-news
-syslog
-user
-uucp
-local0
-local1
-local2
-local3
-local4
-local5
-local6
-local7
diff --git a/doc/guides/prog_guide/log_lib.rst
b/doc/guides/prog_guide/log_lib.rst
index ff9d1b54a2c8..aacb36c36ce0 100644
--- a/doc/guides/prog_guide/log_lib.rst
+++ b/doc/guides/prog_guide/log_lib.rst
@@ -5,8 +5,8 @@ Log Library
===
The DPDK Log library provides the logging functionality for other DPDK
libraries and drivers.
-By default, in a Linux application, logs are sent to syslog and also to the
console.
-On FreeBSD and Windows applications, logs are sent only to the console.
+By default, in a Linux (or FreeBSD) application, logs are sent to syslog and
also to the console.
+In Windows applications, logs are sent only to the console.
However, the log function can be overridden by the user to use a different
logging mechanism.
Log Levels
@@ -29,6 +29,7 @@ will be emitted by the application to the log output.
That level can be configured either by the application calling the relevant
APIs from the logging library,
or by the user passing the ``--log-level`` parameter to the EAL via the
application.
+
Setting Global Log Level
@@ -59,6 +60,19 @@ For example::
Within an application, the same result can be got using the
``rte_log_set_level_pattern()`` or ``rte_log_set_level_regex()`` APIs.
+
+Setting syslog facility
+~~~
+
+On Linux and FreeBSD, where syslog is used a ``facility`` argument can be
+used to specify what type of program is logging.
+The default facility is ``daemon`` but it can be overridden
+by the ``--syslog`` EAL parameter. See ``syslog.3`` man page for full values.
+For example::
+
+ /path/to/app --syslog local0
+
+
Using Logging APIs to Generate Log Messages
---
diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
index bab77118e967..a57ee8406f0c 100644
--- a/lib/eal/freebsd/eal.c
+++ b/lib/eal/freebsd/eal.c
@@ -53,6 +53,7 @@
#include "eal_options.h"
#include "eal_memcfg.h"
#include "eal_trace.h"
+#include "log_internal.h"
#define MEMSIZE_IF_NO_HUGE_PAGE (64ULL * 1024ULL * 1024ULL)
@@ -760,6 +761,13 @@ rte_eal_init(int argc, char **argv)
#endif
}
+ if (eal_log_init(getprogname(), internal_conf->syslog_facility) < 0) {
+ rte_eal_init_alert("Cannot init logging.");
+ rte_errno = ENOMEM;
+ rte_atomic_store_explicit(&run_once, 0,
rte_memory_order_relaxed);
+ return -1;
+ }
+
/* in secondary processes, memory init may allocate additional fbarrays
* not present in primary processes, so to avoid any potential issues,
* initialize memzones first.
diff --git a/lib/log/log_freebsd.c b/lib/log/log_freebsd.c
deleted file mode 100644
index 698d3c542337..
--- a/lib/log/log_freebsd.c
+++ /dev/null
@@ -1,12 +0,0 @@
-/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2023 Intel Corporation
- */
-
-#include
-#include "log_internal.h"
-
-int
-eal_log_init(__rte_unused const char *id, __rte_unused int facility)
-{
- return 0;
-}
diff --git a/lib/log/log_linux.c b/lib/log/log_unix.c
similarity index 100%
rename from lib/log/log_linux.c
rename to lib/log/log_unix.c
diff --git a/lib/log/meson.build b/lib/log/meson.build
index 0d4319b36f77..60516a0b2a2d 100644
--- a/lib/log/meson.build
+++ b/lib/log/meson.build
@@ -2,8 +2,12 @@
# Copyright(c) 2023 Intel Corporation
includes += global_inc
-sources = files(
-'log.c',
-'log_' + exec_env + '.c',
-)
+sources = files('log.c')
+
+if is_windows
+so
[PATCH v10 06/10] eal: change rte_exit() output to match rte_log()
The rte_exit() output format confuses the timestamp and coloring
options. Change it to use be a single line with proper prefix.
Before:
[ 0.006481] EAL: Error - exiting with code: 1
Cause: [ 0.006489] Cannot init EAL: Permission denied
After:
[ 0.006238] EAL: Error - exiting with code: 1
[ 0.006250] EAL: Cause: Cannot init EAL: Permission denied
Signed-off-by: Stephen Hemminger
---
lib/eal/common/eal_common_debug.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/lib/eal/common/eal_common_debug.c
b/lib/eal/common/eal_common_debug.c
index 3e77995896d5..568883830f20 100644
--- a/lib/eal/common/eal_common_debug.c
+++ b/lib/eal/common/eal_common_debug.c
@@ -34,17 +34,18 @@ void
rte_exit(int exit_code, const char *format, ...)
{
va_list ap;
+ char *msg = NULL;
if (exit_code != 0)
- RTE_LOG(CRIT, EAL, "Error - exiting with code: %d\n"
- " Cause: ", exit_code);
+ EAL_LOG(CRIT, "Error - exiting with code: %d", exit_code);
va_start(ap, format);
- rte_vlog(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, format, ap);
+ vasprintf(&msg, format, ap);
va_end(ap);
+ rte_log(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, "EAL: Cause: %s", msg);
+
if (rte_eal_cleanup() != 0 && rte_errno != EALREADY)
- EAL_LOG(CRIT,
- "EAL could not release all resources");
+ EAL_LOG(CRIT, "EAL could not release all resources");
exit(exit_code);
}
--
2.43.0
[PATCH v10 08/10] eal: add option to put timestamp on console output
When debugging driver or startup issues, it is useful to have
a timestamp on each message printed. The messages in syslog
already have a timestamp, but often syslog is not available
during testing.
There are multiple timestamp formats similar to Linux dmesg.
The default is time relative since startup. Other alternatives
are delta, ctime, reltime and iso formats.
Example:
$ dpdk-testpmd --log-timestamp -- -i
EAL: Detected CPU lcores: 8
EAL: Detected NUMA nodes: 1
[ 0.83] EAL: Detected static linkage of DPDK
[ 0.002000] EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
[ 0.003507] EAL: Selected IOVA mode 'VA'
[ 0.006272] testpmd: No probed ethernet devices
Interactive-mode selected
[ 0.029567] testpmd: create a new mbuf pool : n=203456,
size=2176, socket=0
[ 0.029588] testpmd: preferred mempool ops selected: ring_mp_mc
Signed-off-by: Stephen Hemminger
---
app/test/test_eal_flags.c | 17
doc/guides/prog_guide/log_lib.rst | 10 ++
lib/eal/common/eal_common_options.c | 14 ++-
lib/eal/common/eal_options.h| 2 +
lib/log/log_internal.h | 9 ++
lib/log/log_unix.c | 152 +++-
lib/log/log_windows.c | 6 ++
lib/log/version.map | 1 +
8 files changed, 205 insertions(+), 6 deletions(-)
diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
index 6cb4b0675730..eeb1799381d7 100644
--- a/app/test/test_eal_flags.c
+++ b/app/test/test_eal_flags.c
@@ -1055,6 +1055,14 @@ test_misc_flags(void)
const char * const argv22[] = {prgname, prefix, mp_flag,
"--huge-worker-stack=512"};
+ /* Try running with --log-timestamp */
+ const char * const argv23[] = {prgname, prefix, mp_flag,
+ "--log-timestamp" };
+
+ /* Try running with --log-timestamp=iso */
+ const char * const argv24[] = {prgname, prefix, mp_flag,
+ "--log-timestamp=iso" };
+
/* run all tests also applicable to FreeBSD first */
if (launch_proc(argv0) == 0) {
@@ -1162,6 +1170,15 @@ test_misc_flags(void)
printf("Error - process did not run ok with
--huge-worker-stack=size parameter\n");
goto fail;
}
+ if (launch_proc(argv23) != 0) {
+ printf("Error - process did not run ok with --log-timestamp
parameter\n");
+ goto fail;
+ }
+ if (launch_proc(argv24) != 0) {
+ printf("Error - process did not run ok with --log-timestamp=iso
parameter\n");
+ goto fail;
+ }
+
rmdir(hugepath_dir3);
rmdir(hugepath_dir2);
diff --git a/doc/guides/prog_guide/log_lib.rst
b/doc/guides/prog_guide/log_lib.rst
index aacb36c36ce0..1d6b2e3cea5d 100644
--- a/doc/guides/prog_guide/log_lib.rst
+++ b/doc/guides/prog_guide/log_lib.rst
@@ -73,6 +73,16 @@ For example::
/path/to/app --syslog local0
+Console timestamp
+~
+
+On Linux and FreeBSD, an optional timestamp can be added before each
+message by adding the ``--log-timestamp`` option.
+For example::
+
+ /path/to/app --log-level=lib.*:debug --log-timestamp
+
+
Using Logging APIs to Generate Log Messages
---
diff --git a/lib/eal/common/eal_common_options.c
b/lib/eal/common/eal_common_options.c
index 7310d10dfd78..4e2c3d0f255c 100644
--- a/lib/eal/common/eal_common_options.c
+++ b/lib/eal/common/eal_common_options.c
@@ -77,6 +77,7 @@ eal_long_options[] = {
{OPT_IOVA_MODE, 1, NULL, OPT_IOVA_MODE_NUM},
{OPT_LCORES,1, NULL, OPT_LCORES_NUM },
{OPT_LOG_LEVEL, 1, NULL, OPT_LOG_LEVEL_NUM},
+ {OPT_LOG_TIMESTAMP, 2, NULL, OPT_LOG_TIMESTAMP_NUM},
{OPT_TRACE, 1, NULL, OPT_TRACE_NUM},
{OPT_TRACE_DIR, 1, NULL, OPT_TRACE_DIR_NUM},
{OPT_TRACE_BUF_SIZE,1, NULL, OPT_TRACE_BUF_SIZE_NUM },
@@ -1663,6 +1664,7 @@ eal_log_level_parse(int argc, char * const argv[])
switch (opt) {
case OPT_LOG_LEVEL_NUM:
+ case OPT_LOG_TIMESTAMP_NUM:
if (eal_parse_common_option(opt, optarg, internal_conf)
< 0)
return -1;
break;
@@ -1890,7 +1892,7 @@ eal_parse_common_option(int opt, const char *optarg,
break;
#endif
- case OPT_LOG_LEVEL_NUM: {
+ case OPT_LOG_LEVEL_NUM:
if (eal_parse_log_level(optarg) < 0) {
EAL_LOG(ERR,
"invalid parameters for --"
@@ -1898,9 +1900,16 @@ eal_parse_common_option(int opt, const char *optarg,
return -1;
}
break;
- }
#ifndef RTE_EXEC_ENV_WINDOWS
+ case OPT_LOG_TIMESTAMP_N
RE: [PATCH v7 2/4] mbuf: remove rte marker fields
> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> Sent: Thursday, 21 March 2024 16.31
>
> On Thu, Mar 21, 2024 at 10:32:02AM +, Bruce Richardson wrote:
> > On Wed, Mar 20, 2024 at 03:01:36PM -0700, Tyler Retzlaff wrote:
> > > RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Remove
> > > RTE_MARKER fields from rte_mbuf struct.
> > >
> > > Maintain alignment of fields after removed cacheline1 marker by placing
> > > C11 alignas(RTE_CACHE_LINE_MIN_SIZE).
> > >
> > > Provide new rearm_data and rx_descriptor_fields1 fields in anonymous
> > > unions as single element arrays of with types matching the original
> > > markers to maintain API compatibility.
> > >
> > > Signed-off-by: Tyler Retzlaff
> > > ---
> > > doc/guides/rel_notes/release_24_03.rst | 2 +
> > > lib/mbuf/rte_mbuf.h| 4 +-
> > > lib/mbuf/rte_mbuf_core.h | 188 ++--
> -
> > > 3 files changed, 104 insertions(+), 90 deletions(-)
> > >
> > > diff --git a/doc/guides/rel_notes/release_24_03.rst
> b/doc/guides/rel_notes/release_24_03.rst
> > > index 14826ea..4f18cca 100644
> > > --- a/doc/guides/rel_notes/release_24_03.rst
> > > +++ b/doc/guides/rel_notes/release_24_03.rst
> > > @@ -216,6 +216,8 @@ Removed Items
> > >
> > > * acc101: Removed obsolete code for non productized HW variant.
> > >
> > > +* mbuf: ``RTE_MARKER`` fields ``cacheline0`` and ``cacheline1``
> > > + have been removed from ``struct rte_mbuf``.
> > >
> > > API Changes
> > > ---
> > > diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
> > > index 286b32b..4c4722e 100644
> > > --- a/lib/mbuf/rte_mbuf.h
> > > +++ b/lib/mbuf/rte_mbuf.h
> > > @@ -108,7 +108,7 @@
> > > static inline void
> > > rte_mbuf_prefetch_part1(struct rte_mbuf *m)
> > > {
> > > - rte_prefetch0(&m->cacheline0);
> > > + rte_prefetch0(m);
> > > }
> > >
> > > /**
> > > @@ -126,7 +126,7 @@
> > > rte_mbuf_prefetch_part2(struct rte_mbuf *m)
> > > {
> > > #if RTE_CACHE_LINE_SIZE == 64
> > > - rte_prefetch0(&m->cacheline1);
> > > + rte_prefetch0(RTE_PTR_ADD(m, RTE_CACHE_LINE_MIN_SIZE));
> > > #else
> > > RTE_SET_USED(m);
> > > #endif
> > > diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
> > > index 9f58076..665213c 100644
> > > --- a/lib/mbuf/rte_mbuf_core.h
> > > +++ b/lib/mbuf/rte_mbuf_core.h
> > > @@ -465,8 +465,6 @@ enum {
> > > * The generic rte_mbuf, containing a packet mbuf.
> > > */
> > > struct __rte_cache_aligned rte_mbuf {
> > > - RTE_MARKER cacheline0;
> > > -
> > > void *buf_addr; /**< Virtual address of segment buffer. */
> > > #if RTE_IOVA_IN_MBUF
> > > /**
> > > @@ -488,116 +486,130 @@ struct __rte_cache_aligned rte_mbuf {
> > > #endif
> > >
> > > /* next 8 bytes are initialised on RX descriptor rearm */
> > > - RTE_MARKER64 rearm_data;
> > > - uint16_t data_off;
> > > -
> > > - /**
> > > - * Reference counter. Its size should at least equal to the size
> > > - * of port field (16 bits), to support zero-copy broadcast.
> > > - * It should only be accessed using the following functions:
> > > - * rte_mbuf_refcnt_update(), rte_mbuf_refcnt_read(), and
> > > - * rte_mbuf_refcnt_set(). The functionality of these functions (atomic,
> > > - * or non-atomic) is controlled by the RTE_MBUF_REFCNT_ATOMIC flag.
> > > - */
> > > - RTE_ATOMIC(uint16_t) refcnt;
> > > + union {
> > > + uint64_t rearm_data[1];
> > > + __extension__
> > > + struct {
> > > + uint16_t data_off;
> > > +
> > > + /**
> > > + * Reference counter. Its size should at least equal to
> the size
> > > + * of port field (16 bits), to support zero-copy
> broadcast.
> > > + * It should only be accessed using the following
> functions:
> > > + * rte_mbuf_refcnt_update(), rte_mbuf_refcnt_read(), and
> > > + * rte_mbuf_refcnt_set(). The functionality of these
> functions (atomic,
> > > + * or non-atomic) is controlled by the
> RTE_MBUF_REFCNT_ATOMIC flag.
> > > + */
> > > + RTE_ATOMIC(uint16_t) refcnt;
> > >
> > > - /**
> > > - * Number of segments. Only valid for the first segment of an mbuf
> > > - * chain.
> > > - */
> > > - uint16_t nb_segs;
> > > + /**
> > > + * Number of segments. Only valid for the first segment
> > > of
> an mbuf
> > > + * chain.
> > > + */
> > > + uint16_t nb_segs;
> > >
> > > - /** Input port (16 bits to support more than 256 virtual ports).
> > > - * The event eth Tx adapter uses this field to specify the output port.
> > > - */
> > > - uint16_t port;
> > > + /** Input port (16 bits to support more than 256 virtual
> ports).
> > > + * The event eth Tx adapter uses this field to specify
> > > the
> output port.
> > > + */
> > > +
Re: [PATCH 1/2] net/txgbe: add vectorized functions for Rx/Tx
On 3/5/2024 8:10 AM, Jiawen Wu wrote:
> On Wed, Feb 7, 2024 11:13 AM, ferruh.yi...@amd.com wrote:
>> On 2/1/2024 3:00 AM, Jiawen Wu wrote:
>>> To optimize Rx/Tx burst process, add SSE/NEON vector instructions on
>>> x86/arm architecture.
>>>
>>
>> Do you have any performance improvement number with vector
>> implementation, if so can you put it into commit log for record?
>
> On our local x86 platforms, the performance was at full speed without
> using vector. So we don't have the performance improvement number
> with SSE yet. But I will add the test result for arm.
>
Ack
>>> @@ -2198,8 +2220,15 @@ txgbe_set_tx_function(struct rte_eth_dev *dev,
>>> struct txgbe_tx_queue *txq)
>>> #endif
>>> txq->tx_free_thresh >= RTE_PMD_TXGBE_TX_MAX_BURST) {
>>> PMD_INIT_LOG(DEBUG, "Using simple tx code path");
>>> - dev->tx_pkt_burst = txgbe_xmit_pkts_simple;
>>> dev->tx_pkt_prepare = NULL;
>>> + if (txq->tx_free_thresh <= RTE_TXGBE_TX_MAX_FREE_BUF_SZ &&
>>> + (rte_eal_process_type() != RTE_PROC_PRIMARY ||
>>>
>>
>> Why vector Tx enable only for secondary process?
>
> It is not only for secondary process. The constraint is
>
> (rte_eal_process_type() != RTE_PROC_PRIMARY || txgbe_txq_vec_setup(txq) == 0)
>
> This code references ixgbe, which explains:
> "When using multiple processes, the TX function used in all processes
> should be the same, otherwise the secondary processes cannot transmit
> more than tx-ring-size - 1 packets.
> To achieve this, we extract out the code to select the ixgbe TX function
> to be used into a separate function inside the ixgbe driver, and call
> that from a secondary process when it is attaching to an
> already-configured NIC."
>
Got it,
1- Is txgbe has the constraint that same Tx function should be used
separate queues?
Tx functions is all in SW, right? HW interface is same, so HW doesn't
know or care vector Tx or simple Tx is used.
As primary and secondary processes manage different queues, I don't know
why this constraint exists.
2. I see above logic prevents secondary to call 'txgbe_txq_vec_setup()'
again. Perhaps unlikely but technically, if 'txgbe_txq_vec_setup()'
fails for primary 'txgbe_xmit_pkts_simple' is set and for secondary
'txgbe_xmit_pkts_vec' is set, causing both primary and secondary have
different Tx functions, can you please check if this option is valid.
There are other comments not addressed, I assume they are accepted and
there will be a new version, but I want to highlight in case they are
missed.
Re: [PATCH 00/46] use stdatomic API
On Thu, Mar 21, 2024 at 08:33:23AM -0700, Stephen Hemminger wrote: > On Wed, 20 Mar 2024 13:50:46 -0700 > Tyler Retzlaff wrote: > > > This series converts all non-generic built atomics to use the rte_atomic > > macros that allow optional enablement of standard C11 atomics. > > > > Use of generic atomics for non-scalar types are not converted in this > > change and will be evaluated as a part of a separate series. > > > > Note if this series ends up requiring too much rebasing due to tree > > churn before it is merged i will break it up into smaller series. > > Maybe a coccinelle script to automate this and check/fix future usages? it also isn't strictly a 1:1 replacement so some __atomic_ could be text replaced sometimes you need to evaluate arguments on e.g. compare exchange to pick the right macro, sometimes there are generic vs scalar version to deal with. we already have a checkpatches check but right now it is (I think) being ignored when merging changes to drivers that have not been converted. so if we get things converted there shouldn't be any further reason to accept series that are being flagged by checkpatches. > > Series-acked-by: Stephen Hemminger
Re: [PATCH 09/15] net/iavf: pack structures when building with MSVC
On Wed, Mar 20, 2024 at 02:06:05PM -0700, Tyler Retzlaff wrote:
> Add __rte_msvc_pushpack(1) to all __rte_packed structs to cause packing
> when building with MSVC.
>
> Signed-off-by: Tyler Retzlaff
> ---
> drivers/net/iavf/iavf_ipsec_crypto.h | 3 +++
> drivers/net/iavf/iavf_rxtx.c | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/net/iavf/iavf_ipsec_crypto.h
> b/drivers/net/iavf/iavf_ipsec_crypto.h
> index 49f9202..36ced50 100644
> --- a/drivers/net/iavf/iavf_ipsec_crypto.h
> +++ b/drivers/net/iavf/iavf_ipsec_crypto.h
> @@ -11,12 +11,14 @@
>
>
>
> +__rte_msvc_pack
> struct iavf_tx_ipsec_desc {
> union {
> struct {
> __le64 qw0;
> __le64 qw1;
> };
> + __rte_msvc_pack
> struct {
> __le16 l4payload_length;
> __le32 esn;
Looking at the structure, I believe only the inner packed attribute is
necessary. However, given that we need packed attributes, for safety, let's
keep them both.
> @@ -84,6 +86,7 @@ enum iavf_ipsec_iv_len {
> * transmit data path. Parameters set for session by calling
> * rte_security_set_pkt_metadata() API.
> */
> +__rte_msvc_pack
> struct iavf_ipsec_crypto_pkt_metadata {
> uint32_t sa_idx;/* SA hardware index (20b/4B) */
>
This is exactly 16-bytes in size, with all members explicitly sized and
properly aligned. Therefore we can drop the packed atttribute.
> diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
> index 0a5246d..ba0fa6f 100644
> --- a/drivers/net/iavf/iavf_rxtx.c
> +++ b/drivers/net/iavf/iavf_rxtx.c
> @@ -50,6 +50,7 @@
> static uint16_t vxlan_gpe_udp_port = RTE_VXLAN_GPE_DEFAULT_PORT;
> static uint16_t geneve_udp_port = RTE_GENEVE_DEFAULT_PORT;
>
> +__rte_msvc_pack
> struct simple_gre_hdr {
> uint16_t flags;
> uint16_t proto;
Two 16-bit fields only, so no need to pack this struct either.
/Bruce
Re: [PATCH 1/2] net/txgbe: add vectorized functions for Rx/Tx
On 3/5/2024 8:10 AM, Jiawen Wu wrote: <...> >>> +++ b/drivers/net/txgbe/txgbe_rxtx_vec_neon.c >>> @@ -0,0 +1,604 @@ >>> +/* SPDX-License-Identifier: BSD-3-Clause >>> + * Copyright(c) 2015-2024 Beijing WangXun Technology Co., Ltd. >>> + * Copyright(c) 2010-2015 Intel Corporation >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> + >>> +#include "txgbe_ethdev.h" >>> +#include "txgbe_rxtx.h" >>> +#include "txgbe_rxtx_vec_common.h" >>> + >>> +#pragma GCC diagnostic ignored "-Wcast-qual" >>> + >> >> Is this pragma really required? > > Yes. Otherwise, there are warnings in the compilation: > > [1909/2921] Compiling C object > drivers/libtmp_rte_net_txgbe.a.p/net_txgbe_txgbe_rxtx_vec_neon.c.o > ../drivers/net/txgbe/txgbe_rxtx_vec_neon.c: In function ‘txgbe_rxq_rearm’: > ../drivers/net/txgbe/txgbe_rxtx_vec_neon.c:37:15: warning: cast discards > ‘volatile’ qualifier from pointer target type [-Wcast-qual] > vst1q_u64((uint64_t *)&rxdp[i], zero); >^ > ../drivers/net/txgbe/txgbe_rxtx_vec_neon.c:60:13: warning: cast discards > ‘volatile’ qualifier from pointer target type [-Wcast-qual] >vst1q_u64((uint64_t *)rxdp++, dma_addr0); > ^ > ../drivers/net/txgbe/txgbe_rxtx_vec_neon.c:65:13: warning: cast discards > ‘volatile’ qualifier from pointer target type [-Wcast-qual] >vst1q_u64((uint64_t *)rxdp++, dma_addr1); > Hi Honnappa, There are multiple drivers ignores "-Wcast-qual" for neon implementation. Is there a better, more proper way to address this warning? Thanks, ferruh
Re: [PATCH 13/15] app/testpmd: pack structures when building with MSVC
On Wed, Mar 20, 2024 at 02:06:09PM -0700, Tyler Retzlaff wrote:
> Add __rte_msvc_pushpack(1) to all __rte_packed structs to cause packing
> when building with MSVC.
>
> Signed-off-by: Tyler Retzlaff
> ---
> app/test-pmd/csumonly.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> index 6711dda..638e607 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -89,6 +89,7 @@ struct testpmd_offload_info {
> };
>
> /* simplified GRE header */
> +__rte_msvc_pack
> struct simple_gre_hdr {
> uint16_t flags;
> uint16_t proto;
Should not need to be packed, as no padding.
However, if we don't mark this as packed could we hit problems if (for
whatever reason) we ever receive a packet where the gre_hdr is not aligned
on an even byte boundary? Does packing affect the minimum alignment
requirements of the whole struct, as well as removing padding?
/Bruce
Re: [PATCH 15/15] examples: pack structures when building with MSVC
On Wed, Mar 20, 2024 at 02:06:11PM -0700, Tyler Retzlaff wrote:
> Add __rte_msvc_pushpack(1) to all __rte_packed structs to cause packing
> when building with MSVC.
>
> Signed-off-by: Tyler Retzlaff
> ---
> examples/common/neon/port_group.h | 1 +
> examples/ip_pipeline/cli.c| 5 +
> examples/ipsec-secgw/ipsec.h | 1 +
> examples/l3fwd-power/main.c | 2 ++
> examples/ptpclient/ptpclient.c| 8
> 5 files changed, 17 insertions(+)
>
> diff --git a/examples/common/neon/port_group.h
> b/examples/common/neon/port_group.h
> index 421e2e8..bd40590 100644
> --- a/examples/common/neon/port_group.h
> +++ b/examples/common/neon/port_group.h
> @@ -21,6 +21,7 @@
> port_groupx4(uint16_t pn[FWDSTEP + 1], uint16_t *lp, uint16x8_t dp1,
> uint16x8_t dp2)
> {
> + __rte_msvc_pack
> union {
> uint16_t u16[FWDSTEP + 1];
> uint64_t u64;
> diff --git a/examples/ip_pipeline/cli.c b/examples/ip_pipeline/cli.c
> index e8269ea..cae5c1f 100644
> --- a/examples/ip_pipeline/cli.c
> +++ b/examples/ip_pipeline/cli.c
> @@ -2566,6 +2566,7 @@
> *| lpm
> * ipv4 | ipv6
> */
> +__rte_msvc_pack
> struct pkt_key_qinq {
> uint16_t ethertype_svlan;
> uint16_t svlan;
> @@ -2573,6 +2574,7 @@ struct pkt_key_qinq {
> uint16_t cvlan;
> } __rte_packed;
>
> +__rte_msvc_pack
> struct pkt_key_ipv4_5tuple {
> uint8_t time_to_live;
> uint8_t proto;
> @@ -2583,6 +2585,7 @@ struct pkt_key_ipv4_5tuple {
> uint16_t dp;
> } __rte_packed;
>
> +__rte_msvc_pack
> struct pkt_key_ipv6_5tuple {
> uint16_t payload_length;
> uint8_t proto;
> @@ -2593,10 +2596,12 @@ struct pkt_key_ipv6_5tuple {
> uint16_t dp;
> } __rte_packed;
>
> +__rte_msvc_pack
> struct pkt_key_ipv4_addr {
> uint32_t addr;
> } __rte_packed;
>
> +__rte_msvc_pack
> struct pkt_key_ipv6_addr {
> uint8_t addr[16];
> } __rte_packed;
These structs don't look to me like they need packing. No padding should
appear between elements of the structs. The last struct definitely doesn't
need it, as it's a uint8_t array.
/Bruce
Re: [PATCH v10 03/10] eal: make eal_log_level_parse common
On Thu, Mar 21, 2024 at 09:00:19AM -0700, Stephen Hemminger wrote: > The code to parse for log-level option should be same on > all OS variants. > > Signed-off-by: Stephen Hemminger > --- Acked-by: Tyler Retzlaff
Re: [PATCH v10 06/10] eal: change rte_exit() output to match rte_log()
On Thu, Mar 21, 2024 at 09:00:22AM -0700, Stephen Hemminger wrote:
> The rte_exit() output format confuses the timestamp and coloring
> options. Change it to use be a single line with proper prefix.
>
> Before:
> [ 0.006481] EAL: Error - exiting with code: 1
> Cause: [ 0.006489] Cannot init EAL: Permission denied
>
> After:
> [ 0.006238] EAL: Error - exiting with code: 1
> [ 0.006250] EAL: Cause: Cannot init EAL: Permission denied
it is better but maybe : -> - for Cause?
[ 0.006238] EAL: Error - exiting with code: 1
[ 0.006250] EAL: Cause - Cannot init EAL: Permission denied
>
> Signed-off-by: Stephen Hemminger
> ---
ACked-by: Tyler Retzlaff
> lib/eal/common/eal_common_debug.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/lib/eal/common/eal_common_debug.c
> b/lib/eal/common/eal_common_debug.c
> index 3e77995896d5..568883830f20 100644
> --- a/lib/eal/common/eal_common_debug.c
> +++ b/lib/eal/common/eal_common_debug.c
> @@ -34,17 +34,18 @@ void
> rte_exit(int exit_code, const char *format, ...)
> {
> va_list ap;
> + char *msg = NULL;
>
> if (exit_code != 0)
> - RTE_LOG(CRIT, EAL, "Error - exiting with code: %d\n"
> - " Cause: ", exit_code);
> + EAL_LOG(CRIT, "Error - exiting with code: %d", exit_code);
>
> va_start(ap, format);
> - rte_vlog(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, format, ap);
> + vasprintf(&msg, format, ap);
> va_end(ap);
>
> + rte_log(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, "EAL: Cause: %s", msg);
> +
> if (rte_eal_cleanup() != 0 && rte_errno != EALREADY)
> - EAL_LOG(CRIT,
> - "EAL could not release all resources");
> + EAL_LOG(CRIT, "EAL could not release all resources");
> exit(exit_code);
> }
> --
> 2.43.0
Re: [PATCH v2 1/1] doc: update command scope information
07/03/2024 11:06, sk...@marvell.com: > From: Sunil Kumar Kori > > Set of CLI commands are classified into following types; > > - Commands which must be used in script only. > - Commands which must be used via telnet session only. > - Commands which can be used either in script or via telnet session. > > Rename "Dynamic" column to "Scope" to provide clear scope of commands. > > Signed-off-by: Sunil Kumar Kori > Acked-by: Rakesh Kudurumalla Applied, thanks.
Re: [PATCH v10 07/10] eal: allow user to set default log stream before init
On Thu, Mar 21, 2024 at 09:00:23AM -0700, Stephen Hemminger wrote: > It is useful for application to be able to set the default log > stream before call rte_eal_init(). This makes all messages go > to the new default. > > For example, to skip using syslog; just doing > rte_openlog_stream(stderr); > > There is no reason for helper command line applications to clutter > syslog with messages. > > Signed-off-by: Stephen Hemminger > --- Acked-by: Tyler Retzlaff
Re: [PATCH] net: stop using mmx intrinsics
20/03/2024 22:12, Tyler Retzlaff: > +#ifdef RTE_TOOLCHAIN_MSVC > +#include > +#else > #include > +#endif It is not the same include in MSVC? Is it something we want to wrap in a DPDK header file?
Re: [PATCH v10 08/10] eal: add option to put timestamp on console output
On Thu, Mar 21, 2024 at 09:00:24AM -0700, Stephen Hemminger wrote:
> When debugging driver or startup issues, it is useful to have
> a timestamp on each message printed. The messages in syslog
> already have a timestamp, but often syslog is not available
> during testing.
>
> There are multiple timestamp formats similar to Linux dmesg.
> The default is time relative since startup. Other alternatives
> are delta, ctime, reltime and iso formats.
>
> Example:
> $ dpdk-testpmd --log-timestamp -- -i
> EAL: Detected CPU lcores: 8
> EAL: Detected NUMA nodes: 1
> [ 0.83] EAL: Detected static linkage of DPDK
> [ 0.002000] EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> [ 0.003507] EAL: Selected IOVA mode 'VA'
> [ 0.006272] testpmd: No probed ethernet devices
> Interactive-mode selected
> [ 0.029567] testpmd: create a new mbuf pool : n=203456,
> size=2176, socket=0
> [ 0.029588] testpmd: preferred mempool ops selected: ring_mp_mc
>
> Signed-off-by: Stephen Hemminger
> ---
> app/test/test_eal_flags.c | 17
> doc/guides/prog_guide/log_lib.rst | 10 ++
> lib/eal/common/eal_common_options.c | 14 ++-
> lib/eal/common/eal_options.h| 2 +
> lib/log/log_internal.h | 9 ++
> lib/log/log_unix.c | 152 +++-
> lib/log/log_windows.c | 6 ++
> lib/log/version.map | 1 +
> 8 files changed, 205 insertions(+), 6 deletions(-)
>
> diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
> index 6cb4b0675730..eeb1799381d7 100644
> --- a/app/test/test_eal_flags.c
> +++ b/app/test/test_eal_flags.c
> @@ -1055,6 +1055,14 @@ test_misc_flags(void)
> const char * const argv22[] = {prgname, prefix, mp_flag,
> "--huge-worker-stack=512"};
>
> + /* Try running with --log-timestamp */
> + const char * const argv23[] = {prgname, prefix, mp_flag,
> +"--log-timestamp" };
> +
> + /* Try running with --log-timestamp=iso */
> + const char * const argv24[] = {prgname, prefix, mp_flag,
> +"--log-timestamp=iso" };
> +
> /* run all tests also applicable to FreeBSD first */
>
> if (launch_proc(argv0) == 0) {
> @@ -1162,6 +1170,15 @@ test_misc_flags(void)
> printf("Error - process did not run ok with
> --huge-worker-stack=size parameter\n");
> goto fail;
> }
> + if (launch_proc(argv23) != 0) {
> + printf("Error - process did not run ok with --log-timestamp
> parameter\n");
> + goto fail;
> + }
> + if (launch_proc(argv24) != 0) {
> + printf("Error - process did not run ok with --log-timestamp=iso
> parameter\n");
> + goto fail;
> + }
> +
>
> rmdir(hugepath_dir3);
> rmdir(hugepath_dir2);
> diff --git a/doc/guides/prog_guide/log_lib.rst
> b/doc/guides/prog_guide/log_lib.rst
> index aacb36c36ce0..1d6b2e3cea5d 100644
> --- a/doc/guides/prog_guide/log_lib.rst
> +++ b/doc/guides/prog_guide/log_lib.rst
> @@ -73,6 +73,16 @@ For example::
> /path/to/app --syslog local0
>
>
> +Console timestamp
> +~
> +
> +On Linux and FreeBSD, an optional timestamp can be added before each
> +message by adding the ``--log-timestamp`` option.
i don't think Windows should be excluded from the feature, in general
core libraries that get features should cover all platforms.
Re: [PATCH v1] doc: update QAT compression doc IDs
20/03/2024 10:58, Power, Ciara: > From: Sivaramakrishnan, VenkatX > > > > Missing GEN2, GEN3 and GEN4 devices updated for the QAT compression. > > > > Signed-off-by: Sivaramakrishnan Venkat > > --- > > doc/guides/compressdevs/qat_comp.rst | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/doc/guides/compressdevs/qat_comp.rst > > b/doc/guides/compressdevs/qat_comp.rst > > index 475c4a9f9f..7927119611 100644 > > --- a/doc/guides/compressdevs/qat_comp.rst > > +++ b/doc/guides/compressdevs/qat_comp.rst > > @@ -7,6 +7,10 @@ Intel(R) QuickAssist (QAT) Compression Poll Mode Driver > > The QAT compression PMD provides poll mode compression & decompression > > driver support for the following hardware accelerator devices: > > > > +* ``Intel QuickAssist Technology D15xx`` > > +* ``Intel QuickAssist Technology 200xx`` > > +* ``Intel QuickAssist Technology C4xxx`` > > +* ``Intel QuickAssist Technology 4xxx`` > > * ``Intel QuickAssist Technology C62x`` > > * ``Intel QuickAssist Technology C3xxx`` > > * ``Intel QuickAssist Technology DH895x`` > > Acked-by: Ciara Power I think it could be better listed if sorted, but I don't know enough. Applied, thanks.
Re: [PATCH v10 08/10] eal: add option to put timestamp on console output
On Thu, 21 Mar 2024 10:11:31 -0700 Tyler Retzlaff wrote: > > > > > > +Console timestamp > > +~ > > + > > +On Linux and FreeBSD, an optional timestamp can be added before each > > +message by adding the ``--log-timestamp`` option. > > i don't think Windows should be excluded from the feature, in general > core libraries that get features should cover all platforms. The problem is that current Linux/FreeBSD log code depends on fopencookie() to work. I could not find a way to do that on Windows.
Re: [PATCH] argparse: fix parser callback type name
07/03/2024 18:50, Tyler Retzlaff:
> On Thu, Mar 07, 2024 at 05:14:02PM +0100, David Marchand wrote:
> > All types exposed in a public header must be prefixed with rte_.
> >
> > Fixes: e3e579f5bab5 ("argparse: introduce argparse library")
> >
> > Signed-off-by: David Marchand
>
> Acked-by: Tyler Retzlaff
Acked-by: Chengwen Feng
Applied, thanks.
Re: [dpdk-dev] [PATCH] eal: add option to put timestamp on console output
19/10/2020 17:25, Stephen Hemminger: > On Mon, 19 Oct 2020 16:11:19 +0200 > Thomas Monjalon wrote: > > > There was no ack or conclusion for this patch. > > > > 17/08/2020 17:11, Stephen Hemminger: > > > On Mon, 17 Aug 2020 11:37:40 +0100 > > > Bruce Richardson wrote: > > > > > > > On Fri, Aug 14, 2020 at 12:20:28PM -0700, Stephen Hemminger wrote: > > > > > On Fri, 14 Aug 2020 22:09:11 +0300 > > > > > Dmitry Kozlyuk wrote: > > > > > > > > > > > On Fri, 14 Aug 2020 11:45:49 -0700, Stephen Hemminger wrote: > > > > > > > On Fri, 14 Aug 2020 21:39:29 +0300 > > > > > > > Dmitry Kozlyuk wrote: > > > > > > [...] > > > > > > > FreeBsd doesn't go through the same log code. > > > > > > > > > > > > Then --log-timestamp shouldn't appear on FreeBSD if it's > > > > > > unsupported. > > > > > > > > > > Was using same ifdef that is already there. There are several options > > > > > already > > > > > (like syslog facility) which do nothing on FreeBSD anyway. > > > > > > > > > While that is correct, I think that we really should support this on > > > > FreeBSD also, since I don't think there is any technical reason we > > > > can't do > > > > so, right? Even a sub-optimal solution where the timestamp write and log > > > > write are non-atomic would be better than nothing. > > > > > > > > /Bruce > > > > > > FreeBSD now just uses default log stream (stdout). > > > Linux has log stream to syslog and stdout. > > > > > > There is nothing Linux specific in the old or new code. > > > The Linux code could just be moved to common, and both could use it. > > > That is a separate patch, and someone with expertise and build setup for > > > FreeBSD needs to do it. > > > > > Lets fix FreeBSD to use common code for logging, then timestamp option can be > added? OK
Re: [PATCH] net: stop using mmx intrinsics
On Thu, Mar 21, 2024 at 06:09:01PM +0100, Thomas Monjalon wrote: > 20/03/2024 22:12, Tyler Retzlaff: > > +#ifdef RTE_TOOLCHAIN_MSVC > > +#include > > +#else > > #include > > +#endif > > It is not the same include in MSVC? unfortunately intrin.h is vestigial in the monolithic approach. to use any intrinsic you're supposed to include only the one and only true header instead of vendor/arch feature specific headers. > Is it something we want to wrap in a DPDK header file? do you mean create a monolithic rte_intrinsic.h header that is essentially #ifdef MSVC #include #else #include #include #include ... #endif i assumed that doing something like this might be unpopular due to the unnecessary namespace pollution. another alternative could be to find a way to limit that pollution only to msvc by stashing intrin.h in e.g. rte_common.h (or rte_os.h) under conditional compile but the problem i think we had with that approach is that some llvm headers don't define prototypes that match those from msvc see lib/eal/windows/include/rte_windows.h another issue arises where if the application includes intrin.h before dpdk headers we again have to deal with llvm vs msvc differences. fwiw the instance highlighted llvm should have volatile qualified in their prototype but didn't. i will commit to looking into this more after applications are working.
Re: [PATCH v4 0/6] refine argparse library
18/03/2024 12:18, Chengwen Feng: > 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 I'd like to get an approval from someone else for the API changes here. I feel it is better to wait post 24.03. Anyway it is a fresh experimental API.
Re: [PATCH v10 08/10] eal: add option to put timestamp on console output
On Thu, Mar 21, 2024 at 10:16:36AM -0700, Stephen Hemminger wrote: > On Thu, 21 Mar 2024 10:11:31 -0700 > Tyler Retzlaff wrote: > > > > > > > > > > +Console timestamp > > > +~ > > > + > > > +On Linux and FreeBSD, an optional timestamp can be added before each > > > +message by adding the ``--log-timestamp`` option. > > > > i don't think Windows should be excluded from the feature, in general > > core libraries that get features should cover all platforms. > > The problem is that current Linux/FreeBSD log code depends on fopencookie() > to work. I could not find a way to do that on Windows. but that looks like it is part of general log initialization. surely when we are talking about logging a timestamp to a console we're just talking about a standard stream and a format string for Windows? i'll try to study more to gain a better understanding. thanks
Community CI Meeting Minutes - March 21, 2024
March 21, 2024 # Attendees 1. Patrick Robb 2. Aaron Conole 3. Nicholas Pratte 4. Jeremy Spewock 5. Cody Cheng # Minutes = General Announcements * Daylight savings time has hit North America, and will also happen in Europe between this meeting and the next one. Should we adjust? * Going to push this decision back two weeks, and decide at the next CI Meeting * IPSEC-MB requirement increase: * This has been postponed to a future release * UNH did confirm that the final tag submitted by ARM for their repo (tag: SECLIB-IPSEC-2024.03.12) is compatible with the proposed changes from Intel in that DPDK now compiles, with tests passing. * V1.5 will ship with Ubuntu 24.04. Fedora already has it. Once it is widely available with latest versions of standard distros, this requirement will likely be reconsidered. * Server Refresh: * Aaron and Patrick presented this idea to Governing Board. It is still under consideration. * There was a followup provided showing which specific servers will have to be retired, which NICs will be migrated between servers, etc. * We can still use these systems as dev systems and/or SW based testing. * We are currently working with ARM to get a quote for a Grace system so we can follow up with GB for that too * Need to figure out what the lead time is for this server to ship * We have an agreed upon process and format for v2 of the Email Based Retest Framework. Zhoumin at Loongson is also working on the lab specific implementation needed in order for him to start using the get_reruns.py script and support retests. * https://inbox.dpdk.org/ci/de103a95-6f57-df25-0ab5-344dfd8a3...@loongson.cn/T/#t * Final conclusion is like: * A) If retest is requested without rebase key, then retest "original" dpdk artifact (either by re-using the existing tarball (unh lab) or tracking the commit from submit time and re-applying onto dpdk at that commit (loongson)). * B) If rebase key is included, apply to tip of the indicated branch. If, because the branch has changed, the patch no longer applies, then we can report an apply failure. Then, submitter has to refactor their patch and resubmit. * In either case, report the new results with an updated test result in the email (i.e. report "_Testing PASS RETEST #1" instead of "_Testing PASS" in the email body). * Depends-on support: The Patchwork maintainer accepted the plan for adding depend-on support to PW server. But, someone needs to write the code and submit it to the Patchwork project. Adam has indicated his willingness, but we want to check with the DPDK Community that it is a good value from the community’s perspective before we spend a lot of community lab resources on this. His email didn’t get a response but we’ll re-ping the thread after the 24.03 release when people are a little less busy. * https://inbox.dpdk.org/ci/cac-ywqhfpn5zrzsj_r6suehh1fzswpurfpgq-crag5p8nrh...@mail.gmail.com/T/#u * https://github.com/getpatchwork/patchwork/issues/583 and https://github.com/getpatchwork/git-pw/issues/71 * There will (probably) be a DPDK event in Montreal this Sept 9-11. * UNH will try to send as many people as possible, since we are so close = CI Status - UNH-IOL Community Lab * Hardware Refresh: * QAT 8970 is enabled in CI, running the crypto_perf_cryptodev_perf DTS testsuite. * Windows updates: * Unit tests, Clang compile Mingw64 compile are all added to the Windows 2022 machine * Cody got confirmation from the 23.11 LTS maintainer that the staging branch is now triggering when he pushes. * OvS DPDK testing: * What are we actually testing? Regressions coming in from DPDK patches, or latest state of x OVS branch? * The former * Performance testing requires some baremetal testbed topology, where we would send some traffic, run OvS on the DUT, pass packets to OvS in a VM, TestPMD forwards packets (or something). * Need to verify that the Community Lab is the correct setting for this testing, that we are able to provide meaningful and stable results. We just need to define more specifically what the test would look like, and then we will know. - Intel Lab * None - Github Actions * Yesterday there was an outage at Ubuntu for their main package archives for a few hours, so the Robot was failing due to this dependency. We will have to put in retests. * There was another failure in the last two weeks due to update of the Ubuntu container image. * https://github.com/actions/runner-images/i
Re: [PATCH 1/2] net/txgbe: add vectorized functions for Rx/Tx
On Thu, Mar 21, 2024 at 04:27:26PM +, Ferruh Yigit wrote: > On 3/5/2024 8:10 AM, Jiawen Wu wrote: > > <...> > > >>> +++ b/drivers/net/txgbe/txgbe_rxtx_vec_neon.c > >>> @@ -0,0 +1,604 @@ > >>> +/* SPDX-License-Identifier: BSD-3-Clause > >>> + * Copyright(c) 2015-2024 Beijing WangXun Technology Co., Ltd. > >>> + * Copyright(c) 2010-2015 Intel Corporation > >>> + */ > >>> + > >>> +#include > >>> +#include > >>> +#include > >>> + > >>> +#include "txgbe_ethdev.h" > >>> +#include "txgbe_rxtx.h" > >>> +#include "txgbe_rxtx_vec_common.h" > >>> + > >>> +#pragma GCC diagnostic ignored "-Wcast-qual" > >>> + > >> > >> Is this pragma really required? > > > > Yes. Otherwise, there are warnings in the compilation: > > > > [1909/2921] Compiling C object > > drivers/libtmp_rte_net_txgbe.a.p/net_txgbe_txgbe_rxtx_vec_neon.c.o > > ../drivers/net/txgbe/txgbe_rxtx_vec_neon.c: In function ‘txgbe_rxq_rearm’: > > ../drivers/net/txgbe/txgbe_rxtx_vec_neon.c:37:15: warning: cast discards > > ‘volatile’ qualifier from pointer target type [-Wcast-qual] > > vst1q_u64((uint64_t *)&rxdp[i], zero); > >^ > > ../drivers/net/txgbe/txgbe_rxtx_vec_neon.c:60:13: warning: cast discards > > ‘volatile’ qualifier from pointer target type [-Wcast-qual] > >vst1q_u64((uint64_t *)rxdp++, dma_addr0); > > ^ > > ../drivers/net/txgbe/txgbe_rxtx_vec_neon.c:65:13: warning: cast discards > > ‘volatile’ qualifier from pointer target type [-Wcast-qual] > >vst1q_u64((uint64_t *)rxdp++, dma_addr1); > > > > Hi Honnappa, > > There are multiple drivers ignores "-Wcast-qual" for neon implementation. > > Is there a better, more proper way to address this warning? rather than suppress the warning you could just cast away the volatile qualifier the common approach is to cast through uintptr_t to discard. volatile uint64_t *vp; uint64_t *p = (uint64_t *)(uintptr_t)vp; perhaps better than broad suppression of warnings. but does require code be reviewed to be certain it is okay to have the qualifier removed which i suspect is okay in functions that are inline assembly or intrinsics. > > > Thanks, > ferruh
Re: [PATCH] net: stop using mmx intrinsics
21/03/2024 18:27, Tyler Retzlaff: > On Thu, Mar 21, 2024 at 06:09:01PM +0100, Thomas Monjalon wrote: > > 20/03/2024 22:12, Tyler Retzlaff: > > > +#ifdef RTE_TOOLCHAIN_MSVC > > > +#include > > > +#else > > > #include > > > +#endif > > > > It is not the same include in MSVC? > > unfortunately intrin.h is vestigial in the monolithic approach. to use > any intrinsic you're supposed to include only the one and only true > header instead of vendor/arch feature specific headers. > > > Is it something we want to wrap in a DPDK header file? > > do you mean create a monolithic rte_intrinsic.h header that is > essentially > > #ifdef MSVC > #include > #else > #include > #include > #include > ... > #endif > > i assumed that doing something like this might be unpopular due to the > unnecessary namespace pollution. We already have such a file. It is rte_vect.h. I suppose we should just make sure it is included consistently instead of x86intrin.h or immintrin.h This command will show where changes are required: git grep intrin.h
Re: [PATCH 15/46] net/sfc: use rte stdatomic API
Tyler Retzlaff writes: > Replace the use of gcc builtin __atomic_xxx intrinsics with > corresponding rte_atomic_xxx optional rte stdatomic API. > > Signed-off-by: Tyler Retzlaff > --- > drivers/net/sfc/meson.build | 5 ++--- > drivers/net/sfc/sfc_mae_counter.c | 30 +++--- > drivers/net/sfc/sfc_repr_proxy.c | 8 > drivers/net/sfc/sfc_stats.h | 8 > 4 files changed, 25 insertions(+), 26 deletions(-) > > diff --git a/drivers/net/sfc/meson.build b/drivers/net/sfc/meson.build > index 5adde68..d3603a0 100644 > --- a/drivers/net/sfc/meson.build > +++ b/drivers/net/sfc/meson.build > @@ -47,9 +47,8 @@ int main(void) > __int128 a = 0; > __int128 b; > > -b = __atomic_load_n(&a, __ATOMIC_RELAXED); > -__atomic_store(&b, &a, __ATOMIC_RELAXED); > -__atomic_store_n(&b, a, __ATOMIC_RELAXED); > +b = rte_atomic_load_explicit(&a, rte_memory_order_relaxed); > +rte_atomic_store_explicit(&b, a, rte_memory_order_relaxed); > return 0; > } > ''' I think this is a case where simple find/replace is a problem. For example, this is a sample file that the meson build uses to determine if libatomic is properly installed. However, it is very bare-bones. Your change is likely causing a compile error when cc.links happens in the meson file. That leads to the ABI error. If the goal is to remove all the intrinsics, then maybe a better change would be dropping this libatomic check from here completely. WDYT?
Re: [PATCH 15/46] net/sfc: use rte stdatomic API
On Thu, Mar 21, 2024 at 02:11:00PM -0400, Aaron Conole wrote: > Tyler Retzlaff writes: > > > Replace the use of gcc builtin __atomic_xxx intrinsics with > > corresponding rte_atomic_xxx optional rte stdatomic API. > > > > Signed-off-by: Tyler Retzlaff > > --- > > drivers/net/sfc/meson.build | 5 ++--- > > drivers/net/sfc/sfc_mae_counter.c | 30 +++--- > > drivers/net/sfc/sfc_repr_proxy.c | 8 > > drivers/net/sfc/sfc_stats.h | 8 > > 4 files changed, 25 insertions(+), 26 deletions(-) > > > > diff --git a/drivers/net/sfc/meson.build b/drivers/net/sfc/meson.build > > index 5adde68..d3603a0 100644 > > --- a/drivers/net/sfc/meson.build > > +++ b/drivers/net/sfc/meson.build > > @@ -47,9 +47,8 @@ int main(void) > > __int128 a = 0; > > __int128 b; > > > > -b = __atomic_load_n(&a, __ATOMIC_RELAXED); > > -__atomic_store(&b, &a, __ATOMIC_RELAXED); > > -__atomic_store_n(&b, a, __ATOMIC_RELAXED); > > +b = rte_atomic_load_explicit(&a, rte_memory_order_relaxed); > > +rte_atomic_store_explicit(&b, a, rte_memory_order_relaxed); > > return 0; > > } > > ''' > > I think this is a case where simple find/replace is a problem. For > example, this is a sample file that the meson build uses to determine if > libatomic is properly installed. However, it is very bare-bones. > > Your change is likely causing a compile error when cc.links happens in > the meson file. That leads to the ABI error. > > If the goal is to remove all the intrinsics, then maybe a better change > would be dropping this libatomic check from here completely. > > WDYT? yeah, actually it wasn't a search replace mistake it was an unintentionally included file where i was experimenting with keeping the test (thought i had reverted it). i shouldn't have added the change to the series thanks for pointing the mistake out and sorry for the noise. appreciate it!
Re: [PATCH] net: stop using mmx intrinsics
On Thu, Mar 21, 2024 at 07:01:17PM +0100, Thomas Monjalon wrote: > 21/03/2024 18:27, Tyler Retzlaff: > > On Thu, Mar 21, 2024 at 06:09:01PM +0100, Thomas Monjalon wrote: > > > 20/03/2024 22:12, Tyler Retzlaff: > > > > +#ifdef RTE_TOOLCHAIN_MSVC > > > > +#include > > > > +#else > > > > #include > > > > +#endif > > > > > > It is not the same include in MSVC? > > > > unfortunately intrin.h is vestigial in the monolithic approach. to use > > any intrinsic you're supposed to include only the one and only true > > header instead of vendor/arch feature specific headers. > > > > > Is it something we want to wrap in a DPDK header file? > > > > do you mean create a monolithic rte_intrinsic.h header that is > > essentially > > > > #ifdef MSVC > > #include > > #else > > #include > > #include > > #include > > ... > > #endif > > > > i assumed that doing something like this might be unpopular due to the > > unnecessary namespace pollution. > > We already have such a file. > It is rte_vect.h. > I suppose we should just make sure it is included consistently > instead of x86intrin.h or immintrin.h > > This command will show where changes are required: > git grep intrin.h there were some corner cases i can't recall, but since you identified rte_vect.h is the preferred header let me do some experiments to see what i can learn. i'll either submit a series addressing it specifically or come back with details. thanks! > >
RE: [PATCH v5 1/6] examples/l3fwd: fix lcore ID restriction
[AMD Official Use Only - General]
> -Original Message-
> From: Thomas Monjalon
> Sent: Thursday, March 21, 2024 4:48 PM
> To: Tummala, Sivaprasad
> Cc: david.h...@intel.com; anatoly.bura...@intel.com; jer...@marvell.com;
> radu.nico...@intel.com; gak...@marvell.com; cristian.dumitre...@intel.com;
> Yigit,
> Ferruh ; konstantin.anan...@huawei.com;
> step...@networkplumber.org; david.march...@redhat.com; dev@dpdk.org;
> sta...@dpdk.org; Morten Brørup
> Subject: Re: [PATCH v5 1/6] examples/l3fwd: fix lcore ID restriction
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> 21/03/2024 12:05, Tummala, Sivaprasad:
> > From: Thomas Monjalon
> > > 19/03/2024 08:24, Morten Brørup:
> > > > > From: Sivaprasad Tummala [mailto:sivaprasad.tumm...@amd.com]
> > > > > Sent: Monday, 18 March 2024 18.32
> > > > >
> > > > > Currently the config option allows lcore IDs up to 255,
> > > > > irrespective of RTE_MAX_LCORES and needs to be fixed.
> > > > >
> > > > > The patch allows config options based on DPDK config.
> > > > >
> > > > > Fixes: af75078fece3 ("first public release")
> > > > > Cc: sta...@dpdk.org
> > > > >
> > > > > Signed-off-by: Sivaprasad Tummala
> > > > > Acked-by: Konstantin Ananyev
> > > > > ---
> > > >
> > > > I suggest you update the description of the individual patches
> > > > too, like you did
> > > for patch 0/6.
> > > >
> > > > E.g. this patch not only fixes the lcore_id, but also the queue_id type
> > > > size.
> > > >
> > > >
> > > > For the series,
> > > > Acked-by: Morten Brørup
> > >
> > > I would recommend a separate patch for queue id as it is a separate issue.
> > > However, there is no need to split per directory.
> > > You can have patches changing all examples at once.
> > >
> > There's a functional dependency and queue id change is required to
> > support higher lcore IDs and hence it makes sense to add in the same patch.
> > I had split the examples to help the maintainers review the patches
> > individually.
> > Please feel free to squash the git commits while merging.
>
> Then if there is a dependency, please make queue id the first patch.
OK! Will split the changes into separate patches in next version.
>
[PATCH v6 01/14] examples/l3fwd: fix queue ID restriction
Currently application supports queue IDs up to 255
and max queues of 256 irrespective of device support.
This limits the number of active lcores to 256.
The patch fixes these constraints by increasing
the queue IDs to support up to 65535.
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Konstantin Ananyev
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/l3fwd/l3fwd.h | 2 +-
examples/l3fwd/l3fwd_acl.c | 4 ++--
examples/l3fwd/l3fwd_em.c| 4 ++--
examples/l3fwd/l3fwd_event.h | 2 +-
examples/l3fwd/l3fwd_fib.c | 4 ++--
examples/l3fwd/l3fwd_lpm.c | 5 ++---
examples/l3fwd/main.c| 28
7 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index e7ae0e5834..12c264cb4c 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -74,7 +74,7 @@ struct mbuf_table {
struct lcore_rx_queue {
uint16_t port_id;
- uint8_t queue_id;
+ uint16_t queue_id;
} __rte_cache_aligned;
struct lcore_conf {
diff --git a/examples/l3fwd/l3fwd_acl.c b/examples/l3fwd/l3fwd_acl.c
index 401692bcec..2bd63181bc 100644
--- a/examples/l3fwd/l3fwd_acl.c
+++ b/examples/l3fwd/l3fwd_acl.c
@@ -997,7 +997,7 @@ acl_main_loop(__rte_unused void *dummy)
uint64_t prev_tsc, diff_tsc, cur_tsc;
int i, nb_rx;
uint16_t portid;
- uint8_t queueid;
+ uint16_t queueid;
struct lcore_conf *qconf;
int socketid;
const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1)
@@ -1020,7 +1020,7 @@ acl_main_loop(__rte_unused void *dummy)
portid = qconf->rx_queue_list[i].port_id;
queueid = qconf->rx_queue_list[i].queue_id;
RTE_LOG(INFO, L3FWD,
- " -- lcoreid=%u portid=%u rxqueueid=%hhu\n",
+ " -- lcoreid=%u portid=%u rxqueueid=%hu\n",
lcore_id, portid, queueid);
}
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 40e102b38a..cd2bb4a4bb 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -586,7 +586,7 @@ em_main_loop(__rte_unused void *dummy)
unsigned lcore_id;
uint64_t prev_tsc, diff_tsc, cur_tsc;
int i, nb_rx;
- uint8_t queueid;
+ uint16_t queueid;
uint16_t portid;
struct lcore_conf *qconf;
const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1) /
@@ -609,7 +609,7 @@ em_main_loop(__rte_unused void *dummy)
portid = qconf->rx_queue_list[i].port_id;
queueid = qconf->rx_queue_list[i].queue_id;
RTE_LOG(INFO, L3FWD,
- " -- lcoreid=%u portid=%u rxqueueid=%hhu\n",
+ " -- lcoreid=%u portid=%u rxqueueid=%hu\n",
lcore_id, portid, queueid);
}
diff --git a/examples/l3fwd/l3fwd_event.h b/examples/l3fwd/l3fwd_event.h
index 9aad358003..c6a4a89127 100644
--- a/examples/l3fwd/l3fwd_event.h
+++ b/examples/l3fwd/l3fwd_event.h
@@ -78,8 +78,8 @@ struct l3fwd_event_resources {
uint8_t deq_depth;
uint8_t has_burst;
uint8_t enabled;
- uint8_t eth_rx_queues;
uint8_t vector_enabled;
+ uint16_t eth_rx_queues;
uint16_t vector_size;
uint64_t vector_tmo_ns;
};
diff --git a/examples/l3fwd/l3fwd_fib.c b/examples/l3fwd/l3fwd_fib.c
index 6a21984415..7da55f707a 100644
--- a/examples/l3fwd/l3fwd_fib.c
+++ b/examples/l3fwd/l3fwd_fib.c
@@ -186,7 +186,7 @@ fib_main_loop(__rte_unused void *dummy)
uint64_t prev_tsc, diff_tsc, cur_tsc;
int i, nb_rx;
uint16_t portid;
- uint8_t queueid;
+ uint16_t queueid;
struct lcore_conf *qconf;
const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1) /
US_PER_S * BURST_TX_DRAIN_US;
@@ -208,7 +208,7 @@ fib_main_loop(__rte_unused void *dummy)
portid = qconf->rx_queue_list[i].port_id;
queueid = qconf->rx_queue_list[i].queue_id;
RTE_LOG(INFO, L3FWD,
- " -- lcoreid=%u portid=%u rxqueueid=%hhu\n",
+ " -- lcoreid=%u portid=%u rxqueueid=%hu\n",
lcore_id, portid, queueid);
}
diff --git a/examples/l3fwd/l3fwd_lpm.c b/examples/l3fwd/l3fwd_lpm.c
index a484a33089..01d38bc69c 100644
--- a/examples/l3fwd/l3fwd_lpm.c
+++ b/examples/l3fwd/l3fwd_lpm.c
@@ -148,8 +148,7 @@ lpm_main_loop(__rte_unused void *dummy)
unsigned lcore_id;
uint64_t prev_tsc, diff_tsc, cur_tsc;
int i, nb_rx;
- uint16_t portid;
- uint8_t queueid;
+ uint16_t portid, queueid;
struct lcore_conf *qconf;
const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1) /
US_PER_S * BURST_TX_DRAIN_US;
@@ -171,7 +170,7 @@ lpm_main_loop(__
[PATCH v6 00/10] fix lcore ID restriction
With modern CPUs, it is possible to have higher CPU count thus we can have higher RTE_MAX_LCORES. In DPDK sample applications, the current config lcore options are hard limited to 255. The patchset fixes these constraints by allowing all lcore IDs up to RTE_MAX_LCORES. Also the queue IDs are increased to support up to 65535. The port ID constraints were also fixed to support up to RTE_MAX_ETHPORTS. v6: - split queue_id, lcore_id and port_id changes as separate patches. - updated git commit description on individual patches v5: - updated lcore_id type to uint32_t v4: - fixed build errors with queue_id type in ipsec-secgw v3: - updated queue_id type to uint16_t v2: - fixed typo with lcore_id type in l3fwd Sivaprasad Tummala (10): examples/l3fwd: fix queue ID restriction examples/l3fwd-power: fix queue ID restriction examples/l3fwd-graph: fix queue ID restriction examples/ipsec-secgw: fix queue ID restriction examples/l3fwd: fix lcore ID restriction examples/l3fwd-power: fix lcore ID restriction examples/l3fwd-graph: fix lcore ID restriction examples/ipsec-secgw: fix lcore ID restriction examples/qos_sched: fix lcore ID restriction examples/vm_power_manager: fix lcore ID restriction examples/ipsec-secgw/event_helper.h | 2 +- examples/ipsec-secgw/ipsec-secgw.c| 35 +-- examples/ipsec-secgw/ipsec.c | 2 +- examples/ipsec-secgw/ipsec.h | 6 +- examples/ipsec-secgw/ipsec_worker.c | 10 ++-- examples/l3fwd-graph/main.c | 31 +- examples/l3fwd-power/main.c | 59 +-- examples/l3fwd-power/main.h | 4 +- examples/l3fwd-power/perf_core.c | 14 +++-- examples/l3fwd/l3fwd.h| 2 +- examples/l3fwd/l3fwd_acl.c| 4 +- examples/l3fwd/l3fwd_em.c | 4 +- examples/l3fwd/l3fwd_event.h | 2 +- examples/l3fwd/l3fwd_fib.c| 4 +- examples/l3fwd/l3fwd_lpm.c| 5 +- examples/l3fwd/main.c | 38 ++-- examples/qos_sched/args.c | 6 +- .../guest_cli/vm_power_cli_guest.c| 4 +- 18 files changed, 119 insertions(+), 113 deletions(-) -- 2.34.1
[PATCH v6 02/14] examples/l3fwd-power: fix queue ID restriction
Currently application supports queue IDs up to 255
and max queues of 256 irrespective of device support.
This limits the number of active lcores to 256.
The patch fixes these constraints by increasing
the queue IDs to support up to 65535.
Fixes: f88e7c175a68 ("examples/l3fwd-power: add high/regular perf cores
options")
Cc: radu.nico...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/l3fwd-power/main.c | 49
examples/l3fwd-power/main.h | 2 +-
examples/l3fwd-power/perf_core.c | 10 +--
3 files changed, 32 insertions(+), 29 deletions(-)
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index f4adcf41b5..1881b1b194 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -214,7 +214,7 @@ enum freq_scale_hint_t
struct lcore_rx_queue {
uint16_t port_id;
- uint8_t queue_id;
+ uint16_t queue_id;
enum freq_scale_hint_t freq_up_hint;
uint32_t zero_rx_packet_count;
uint32_t idle_hint;
@@ -838,7 +838,7 @@ sleep_until_rx_interrupt(int num, int lcore)
struct rte_epoll_event event[num];
int n, i;
uint16_t port_id;
- uint8_t queue_id;
+ uint16_t queue_id;
void *data;
if (status[lcore].wakeup) {
@@ -850,9 +850,9 @@ sleep_until_rx_interrupt(int num, int lcore)
n = rte_epoll_wait(RTE_EPOLL_PER_THREAD, event, num, 10);
for (i = 0; i < n; i++) {
data = event[i].epdata.data;
- port_id = ((uintptr_t)data) >> CHAR_BIT;
+ port_id = ((uintptr_t)data) >> (sizeof(uint16_t) * CHAR_BIT);
queue_id = ((uintptr_t)data) &
- RTE_LEN2MASK(CHAR_BIT, uint8_t);
+ RTE_LEN2MASK((sizeof(uint16_t) * CHAR_BIT), uint16_t);
RTE_LOG(INFO, L3FWD_POWER,
"lcore %u is waked up from rx interrupt on"
" port %d queue %d\n",
@@ -867,7 +867,7 @@ static void turn_on_off_intr(struct lcore_conf *qconf, bool
on)
{
int i;
struct lcore_rx_queue *rx_queue;
- uint8_t queue_id;
+ uint16_t queue_id;
uint16_t port_id;
for (i = 0; i < qconf->n_rx_queue; ++i) {
@@ -887,7 +887,7 @@ static void turn_on_off_intr(struct lcore_conf *qconf, bool
on)
static int event_register(struct lcore_conf *qconf)
{
struct lcore_rx_queue *rx_queue;
- uint8_t queueid;
+ uint16_t queueid;
uint16_t portid;
uint32_t data;
int ret;
@@ -897,7 +897,7 @@ static int event_register(struct lcore_conf *qconf)
rx_queue = &(qconf->rx_queue_list[i]);
portid = rx_queue->port_id;
queueid = rx_queue->queue_id;
- data = portid << CHAR_BIT | queueid;
+ data = portid << (sizeof(uint16_t) * CHAR_BIT) | queueid;
ret = rte_eth_dev_rx_intr_ctl_q(portid, queueid,
RTE_EPOLL_PER_THREAD,
@@ -917,8 +917,7 @@ static int main_intr_loop(__rte_unused void *dummy)
unsigned int lcore_id;
uint64_t prev_tsc, diff_tsc, cur_tsc;
int i, j, nb_rx;
- uint8_t queueid;
- uint16_t portid;
+ uint16_t portid, queueid;
struct lcore_conf *qconf;
struct lcore_rx_queue *rx_queue;
uint32_t lcore_rx_idle_count = 0;
@@ -946,7 +945,7 @@ static int main_intr_loop(__rte_unused void *dummy)
portid = qconf->rx_queue_list[i].port_id;
queueid = qconf->rx_queue_list[i].queue_id;
RTE_LOG(INFO, L3FWD_POWER,
- " -- lcoreid=%u portid=%u rxqueueid=%hhu\n",
+ " -- lcoreid=%u portid=%u rxqueueid=%hu\n",
lcore_id, portid, queueid);
}
@@ -1083,8 +1082,7 @@ main_telemetry_loop(__rte_unused void *dummy)
unsigned int lcore_id;
uint64_t prev_tsc, diff_tsc, cur_tsc, prev_tel_tsc;
int i, j, nb_rx;
- uint8_t queueid;
- uint16_t portid;
+ uint16_t portid, queueid;
struct lcore_conf *qconf;
struct lcore_rx_queue *rx_queue;
uint64_t ep_nep[2] = {0}, fp_nfp[2] = {0};
@@ -1114,7 +1112,7 @@ main_telemetry_loop(__rte_unused void *dummy)
portid = qconf->rx_queue_list[i].port_id;
queueid = qconf->rx_queue_list[i].queue_id;
RTE_LOG(INFO, L3FWD_POWER, " -- lcoreid=%u portid=%u "
- "rxqueueid=%hhu\n", lcore_id, portid, queueid);
+ "rxqueueid=%hu\n", lcore_id, portid, queueid);
}
while (!is_done()) {
@@ -1205,8 +1203,7 @@ main_legacy_loop(__rte_unused void *dummy)
uint64_t prev_tsc, diff_tsc, cur_tsc, tim_res_tsc, hz;
uint64_t prev_tsc_power = 0, cur_tsc_power, diff_tsc_power;
int i, j, nb_r
[PATCH v6 03/14] examples/l3fwd-graph: fix queue ID restriction
Currently application supports queue IDs up to 255
and max queues of 256 irrespective of device support.
This limits the number of active lcores to 256.
The patch fixes these constraints by increasing
the queue IDs to support up to 65535.
Fixes: 08bd1a174461 ("examples/l3fwd-graph: add graph-based l3fwd skeleton")
Cc: ndabilpu...@marvell.com
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/l3fwd-graph/main.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/examples/l3fwd-graph/main.c b/examples/l3fwd-graph/main.c
index 96cb1c81ff..c3a7b267e9 100644
--- a/examples/l3fwd-graph/main.c
+++ b/examples/l3fwd-graph/main.c
@@ -90,7 +90,7 @@ static int pcap_trace_enable;
struct lcore_rx_queue {
uint16_t port_id;
- uint8_t queue_id;
+ uint16_t queue_id;
char node_name[RTE_NODE_NAMESIZE];
};
@@ -110,7 +110,7 @@ static struct lcore_conf lcore_conf[RTE_MAX_LCORE];
struct lcore_params {
uint16_t port_id;
- uint8_t queue_id;
+ uint16_t queue_id;
uint8_t lcore_id;
} __rte_cache_aligned;
@@ -205,14 +205,14 @@ check_worker_model_params(void)
static int
check_lcore_params(void)
{
- uint8_t queue, lcore;
+ uint16_t queue, i;
int socketid;
- uint16_t i;
+ uint8_t lcore;
for (i = 0; i < nb_lcore_params; ++i) {
queue = lcore_params[i].queue_id;
if (queue >= MAX_RX_QUEUE_PER_PORT) {
- printf("Invalid queue number: %hhu\n", queue);
+ printf("Invalid queue number: %hu\n", queue);
return -1;
}
lcore = lcore_params[i].lcore_id;
@@ -257,7 +257,7 @@ check_port_config(void)
return 0;
}
-static uint8_t
+static uint16_t
get_port_n_rx_queues(const uint16_t port)
{
int queue = -1;
@@ -275,7 +275,7 @@ get_port_n_rx_queues(const uint16_t port)
}
}
- return (uint8_t)(++queue);
+ return (uint16_t)(++queue);
}
static int
@@ -450,7 +450,7 @@ parse_config(const char *q_arg)
lcore_params_array[nb_lcore_params].port_id =
(uint8_t)int_fld[FLD_PORT];
lcore_params_array[nb_lcore_params].queue_id =
- (uint8_t)int_fld[FLD_QUEUE];
+ (uint16_t)int_fld[FLD_QUEUE];
lcore_params_array[nb_lcore_params].lcore_id =
(uint8_t)int_fld[FLD_LCORE];
++nb_lcore_params;
@@ -1011,7 +1011,8 @@ main(int argc, char **argv)
"ethdev_tx-*",
"pkt_drop",
};
- uint8_t nb_rx_queue, queue, socketid;
+ uint8_t socketid;
+ uint16_t nb_rx_queue, queue;
struct rte_graph_param graph_conf;
struct rte_eth_dev_info dev_info;
uint32_t nb_ports, nb_conf = 0;
--
2.34.1
[PATCH v6 04/14] examples/ipsec-secgw: fix queue ID restriction
Currently application supports queue IDs up to 255
and max queues of 256 irrespective of device support.
This limits the number of active lcores to 256.
The patch fixes these constraints by increasing
the queue IDs to support up to 65535.
Signed-off-by: Sivaprasad Tummala
Acked-by: Konstantin Ananyev
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/ipsec-secgw/ipsec-secgw.c | 20 ++--
examples/ipsec-secgw/ipsec.h| 2 +-
examples/ipsec-secgw/ipsec_worker.c | 10 --
3 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/examples/ipsec-secgw/ipsec-secgw.c
b/examples/ipsec-secgw/ipsec-secgw.c
index 45a303850d..106a058b60 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -220,7 +220,7 @@ static const char *cfgfile;
struct lcore_params {
uint16_t port_id;
- uint8_t queue_id;
+ uint16_t queue_id;
uint8_t lcore_id;
} __rte_cache_aligned;
@@ -695,8 +695,7 @@ ipsec_poll_mode_worker(void)
struct rte_mbuf *pkts[MAX_PKT_BURST];
uint32_t lcore_id;
uint64_t prev_tsc, diff_tsc, cur_tsc;
- uint16_t i, nb_rx, portid;
- uint8_t queueid;
+ uint16_t i, nb_rx, portid, queueid;
struct lcore_conf *qconf;
int32_t rc, socket_id;
const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1)
@@ -743,7 +742,7 @@ ipsec_poll_mode_worker(void)
portid = rxql[i].port_id;
queueid = rxql[i].queue_id;
RTE_LOG(INFO, IPSEC,
- " -- lcoreid=%u portid=%u rxqueueid=%hhu\n",
+ " -- lcoreid=%u portid=%u rxqueueid=%hu\n",
lcore_id, portid, queueid);
}
@@ -788,8 +787,7 @@ int
check_flow_params(uint16_t fdir_portid, uint8_t fdir_qid)
{
uint16_t i;
- uint16_t portid;
- uint8_t queueid;
+ uint16_t portid, queueid;
for (i = 0; i < nb_lcore_params; ++i) {
portid = lcore_params_array[i].port_id;
@@ -851,7 +849,7 @@ check_poll_mode_params(struct eh_conf *eh_conf)
return 0;
}
-static uint8_t
+static uint16_t
get_port_nb_rx_queues(const uint16_t port)
{
int32_t queue = -1;
@@ -862,7 +860,7 @@ get_port_nb_rx_queues(const uint16_t port)
lcore_params[i].queue_id > queue)
queue = lcore_params[i].queue_id;
}
- return (uint8_t)(++queue);
+ return (uint16_t)(++queue);
}
static int32_t
@@ -1050,6 +1048,8 @@ parse_config(const char *q_arg)
char *str_fld[_NUM_FLD];
int32_t i;
uint32_t size;
+ uint32_t max_fld[_NUM_FLD] = {USHRT_MAX,
+ USHRT_MAX, UCHAR_MAX};
nb_lcore_params = 0;
@@ -1070,7 +1070,7 @@ parse_config(const char *q_arg)
for (i = 0; i < _NUM_FLD; i++) {
errno = 0;
int_fld[i] = strtoul(str_fld[i], &end, 0);
- if (errno != 0 || end == str_fld[i] || int_fld[i] > 255)
+ if (errno != 0 || end == str_fld[i] || int_fld[i] >
max_fld[i])
return -1;
}
if (nb_lcore_params >= MAX_LCORE_PARAMS) {
@@ -1081,7 +1081,7 @@ parse_config(const char *q_arg)
lcore_params_array[nb_lcore_params].port_id =
(uint8_t)int_fld[FLD_PORT];
lcore_params_array[nb_lcore_params].queue_id =
- (uint8_t)int_fld[FLD_QUEUE];
+ (uint16_t)int_fld[FLD_QUEUE];
lcore_params_array[nb_lcore_params].lcore_id =
(uint8_t)int_fld[FLD_LCORE];
++nb_lcore_params;
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index bdcada1c40..29b9b283f0 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -285,7 +285,7 @@ struct cnt_blk {
struct lcore_rx_queue {
uint16_t port_id;
- uint8_t queue_id;
+ uint16_t queue_id;
void *sec_ctx;
} __rte_cache_aligned;
diff --git a/examples/ipsec-secgw/ipsec_worker.c
b/examples/ipsec-secgw/ipsec_worker.c
index 8d122e8519..90a4c38ba4 100644
--- a/examples/ipsec-secgw/ipsec_worker.c
+++ b/examples/ipsec-secgw/ipsec_worker.c
@@ -1598,8 +1598,7 @@ ipsec_poll_mode_wrkr_inl_pr(void)
int32_t socket_id;
uint32_t lcore_id;
int32_t i, nb_rx;
- uint16_t portid;
- uint8_t queueid;
+ uint16_t portid, queueid;
prev_tsc = 0;
lcore_id = rte_lcore_id();
@@ -1633,7 +1632,7 @@ ipsec_poll_mode_wrkr_inl_pr(void)
portid = rxql[i].port_id;
queueid = rxql[i].queue_id;
RTE_LOG(INFO, IPSEC,
- " -- lcoreid=%u portid=%u rxqueueid=%hhu\n",
+ " -- lcoreid=%u portid=%u rxqueueid=%hu\n",
lcore_i
[PATCH v6 05/14] examples/l3fwd: fix lcore ID restriction
Currently the config option allows lcore IDs up to 255,
irrespective of RTE_MAX_LCORES and needs to be fixed.
The patch fixes these constraints by allowing all
lcore IDs up to RTE_MAX_LCORES.
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Konstantin Ananyev
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/l3fwd/main.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 4d4738b92b..9fb4fe97d4 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -99,7 +99,7 @@ struct parm_cfg parm_config;
struct lcore_params {
uint16_t port_id;
uint16_t queue_id;
- uint8_t lcore_id;
+ uint32_t lcore_id;
} __rte_cache_aligned;
static struct lcore_params lcore_params_array[MAX_LCORE_PARAMS];
@@ -293,7 +293,7 @@ static int
check_lcore_params(void)
{
uint16_t queue, i;
- uint8_t lcore;
+ uint32_t lcore;
int socketid;
for (i = 0; i < nb_lcore_params; ++i) {
@@ -304,12 +304,12 @@ check_lcore_params(void)
}
lcore = lcore_params[i].lcore_id;
if (!rte_lcore_is_enabled(lcore)) {
- printf("error: lcore %hhu is not enabled in lcore
mask\n", lcore);
+ printf("error: lcore %u is not enabled in lcore
mask\n", lcore);
return -1;
}
if ((socketid = rte_lcore_to_socket_id(lcore) != 0) &&
(numa_on == 0)) {
- printf("warning: lcore %hhu is on socket %d with numa
off \n",
+ printf("warning: lcore %u is on socket %d with numa
off\n",
lcore, socketid);
}
}
@@ -359,14 +359,14 @@ static int
init_lcore_rx_queues(void)
{
uint16_t i, nb_rx_queue;
- uint8_t lcore;
+ uint32_t lcore;
for (i = 0; i < nb_lcore_params; ++i) {
lcore = lcore_params[i].lcore_id;
nb_rx_queue = lcore_conf[lcore].n_rx_queue;
if (nb_rx_queue >= MAX_RX_QUEUE_PER_LCORE) {
printf("error: too many queues (%u) for lcore: %u\n",
- (unsigned int)nb_rx_queue + 1, (unsigned
int)lcore);
+ (unsigned int)nb_rx_queue + 1, lcore);
return -1;
} else {
lcore_conf[lcore].rx_queue_list[nb_rx_queue].port_id =
@@ -500,8 +500,8 @@ parse_config(const char *q_arg)
char *str_fld[_NUM_FLD];
int i;
unsigned size;
- uint16_t max_fld[_NUM_FLD] = {USHRT_MAX,
- USHRT_MAX, UCHAR_MAX};
+ uint32_t max_fld[_NUM_FLD] = {USHRT_MAX,
+ USHRT_MAX, RTE_MAX_LCORE};
nb_lcore_params = 0;
@@ -534,7 +534,7 @@ parse_config(const char *q_arg)
lcore_params_array[nb_lcore_params].queue_id =
(uint16_t)int_fld[FLD_QUEUE];
lcore_params_array[nb_lcore_params].lcore_id =
- (uint8_t)int_fld[FLD_LCORE];
+ (uint32_t)int_fld[FLD_LCORE];
++nb_lcore_params;
}
lcore_params = lcore_params_array;
--
2.34.1
[PATCH v6 06/14] examples/l3fwd-power: fix lcore ID restriction
Currently the config option allows lcore IDs up to 255,
irrespective of RTE_MAX_LCORES and needs to be fixed.
The patch fixes these constraints by allowing all
lcore IDs up to RTE_MAX_LCORES.
Fixes: f88e7c175a68 ("examples/l3fwd-power: add high/regular perf cores
options")
Cc: radu.nico...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/l3fwd-power/main.c | 14 +++---
examples/l3fwd-power/main.h | 2 +-
examples/l3fwd-power/perf_core.c | 6 +++---
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index 1881b1b194..5411592dca 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -1397,7 +1397,7 @@ static int
check_lcore_params(void)
{
uint16_t queue, i;
- uint8_t lcore;
+ uint32_t lcore;
int socketid;
for (i = 0; i < nb_lcore_params; ++i) {
@@ -1408,13 +1408,13 @@ check_lcore_params(void)
}
lcore = lcore_params[i].lcore_id;
if (!rte_lcore_is_enabled(lcore)) {
- printf("error: lcore %hhu is not enabled in lcore "
+ printf("error: lcore %u is not enabled in lcore "
"mask\n", lcore);
return -1;
}
if ((socketid = rte_lcore_to_socket_id(lcore) != 0) &&
(numa_on == 0)) {
- printf("warning: lcore %hhu is on socket %d with numa "
+ printf("warning: lcore %u is on socket %d with numa "
"off\n", lcore, socketid);
}
if (app_mode == APP_MODE_TELEMETRY && lcore == rte_lcore_id()) {
@@ -1466,14 +1466,14 @@ static int
init_lcore_rx_queues(void)
{
uint16_t i, nb_rx_queue;
- uint8_t lcore;
+ uint32_t lcore;
for (i = 0; i < nb_lcore_params; ++i) {
lcore = lcore_params[i].lcore_id;
nb_rx_queue = lcore_conf[lcore].n_rx_queue;
if (nb_rx_queue >= MAX_RX_QUEUE_PER_LCORE) {
printf("error: too many queues (%u) for lcore: %u\n",
- (unsigned)nb_rx_queue + 1, (unsigned)lcore);
+ (unsigned int)nb_rx_queue + 1, lcore);
return -1;
} else {
lcore_conf[lcore].rx_queue_list[nb_rx_queue].port_id =
@@ -1659,7 +1659,7 @@ parse_config(const char *q_arg)
int i;
unsigned size;
unsigned int max_fld[_NUM_FLD] = {USHRT_MAX,
- USHRT_MAX, UCHAR_MAX};
+ USHRT_MAX, RTE_MAX_LCORE};
nb_lcore_params = 0;
@@ -1693,7 +1693,7 @@ parse_config(const char *q_arg)
lcore_params_array[nb_lcore_params].queue_id =
(uint16_t)int_fld[FLD_QUEUE];
lcore_params_array[nb_lcore_params].lcore_id =
- (uint8_t)int_fld[FLD_LCORE];
+ (uint32_t)int_fld[FLD_LCORE];
++nb_lcore_params;
}
lcore_params = lcore_params_array;
diff --git a/examples/l3fwd-power/main.h b/examples/l3fwd-power/main.h
index 40b5194726..194bd82102 100644
--- a/examples/l3fwd-power/main.h
+++ b/examples/l3fwd-power/main.h
@@ -10,7 +10,7 @@
struct lcore_params {
uint16_t port_id;
uint16_t queue_id;
- uint8_t lcore_id;
+ uint32_t lcore_id;
} __rte_cache_aligned;
extern struct lcore_params *lcore_params;
diff --git a/examples/l3fwd-power/perf_core.c b/examples/l3fwd-power/perf_core.c
index 3088935ee0..d8b35d062c 100644
--- a/examples/l3fwd-power/perf_core.c
+++ b/examples/l3fwd-power/perf_core.c
@@ -24,7 +24,7 @@ struct perf_lcore_params {
uint16_t port_id;
uint16_t queue_id;
uint8_t high_perf;
- uint8_t lcore_idx;
+ uint32_t lcore_idx;
} __rte_cache_aligned;
static struct perf_lcore_params prf_lc_prms[MAX_LCORE_PARAMS];
@@ -133,7 +133,7 @@ parse_perf_config(const char *q_arg)
int i;
unsigned int size;
unsigned int max_fld[_NUM_FLD] = {USHRT_MAX, USHRT_MAX,
- UCHAR_MAX, UCHAR_MAX};
+ UCHAR_MAX, RTE_MAX_LCORE};
nb_prf_lc_prms = 0;
@@ -171,7 +171,7 @@ parse_perf_config(const char *q_arg)
prf_lc_prms[nb_prf_lc_prms].high_perf =
!!(uint8_t)int_fld[FLD_LCORE_HP];
prf_lc_prms[nb_prf_lc_prms].lcore_idx =
- (uint8_t)int_fld[FLD_LCORE_IDX];
+ (uint32_t)int_fld[FLD_LCORE_IDX];
++nb_prf_lc_prms;
}
[PATCH v6 07/14] examples/l3fwd-graph: fix lcore ID restriction
Currently the config option allows lcore IDs up to 255,
irrespective of RTE_MAX_LCORES and needs to be fixed.
The patch fixes these constraints by allowing all
lcore IDs up to RTE_MAX_LCORES. Also the queue
IDs are increased to support up to 65535.
Fixes: 08bd1a174461 ("examples/l3fwd-graph: add graph-based l3fwd skeleton")
Cc: ndabilpu...@marvell.com
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/l3fwd-graph/main.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/examples/l3fwd-graph/main.c b/examples/l3fwd-graph/main.c
index c3a7b267e9..8b7aa6642b 100644
--- a/examples/l3fwd-graph/main.c
+++ b/examples/l3fwd-graph/main.c
@@ -111,7 +111,7 @@ static struct lcore_conf lcore_conf[RTE_MAX_LCORE];
struct lcore_params {
uint16_t port_id;
uint16_t queue_id;
- uint8_t lcore_id;
+ uint32_t lcore_id;
} __rte_cache_aligned;
static struct lcore_params lcore_params_array[MAX_LCORE_PARAMS];
@@ -207,7 +207,7 @@ check_lcore_params(void)
{
uint16_t queue, i;
int socketid;
- uint8_t lcore;
+ uint32_t lcore;
for (i = 0; i < nb_lcore_params; ++i) {
queue = lcore_params[i].queue_id;
@@ -217,7 +217,7 @@ check_lcore_params(void)
}
lcore = lcore_params[i].lcore_id;
if (!rte_lcore_is_enabled(lcore)) {
- printf("Error: lcore %hhu is not enabled in lcore
mask\n",
+ printf("Error: lcore %u is not enabled in lcore mask\n",
lcore);
return -1;
}
@@ -228,7 +228,7 @@ check_lcore_params(void)
}
socketid = rte_lcore_to_socket_id(lcore);
if ((socketid != 0) && (numa_on == 0)) {
- printf("Warning: lcore %hhu is on socket %d with numa
off\n",
+ printf("Warning: lcore %u is on socket %d with numa
off\n",
lcore, socketid);
}
}
@@ -282,7 +282,7 @@ static int
init_lcore_rx_queues(void)
{
uint16_t i, nb_rx_queue;
- uint8_t lcore;
+ uint32_t lcore;
for (i = 0; i < nb_lcore_params; ++i) {
lcore = lcore_params[i].lcore_id;
@@ -290,7 +290,7 @@ init_lcore_rx_queues(void)
if (nb_rx_queue >= MAX_RX_QUEUE_PER_LCORE) {
printf("Error: too many queues (%u) for lcore: %u\n",
(unsigned int)nb_rx_queue + 1,
- (unsigned int)lcore);
+ lcore);
return -1;
}
@@ -452,7 +452,7 @@ parse_config(const char *q_arg)
lcore_params_array[nb_lcore_params].queue_id =
(uint16_t)int_fld[FLD_QUEUE];
lcore_params_array[nb_lcore_params].lcore_id =
- (uint8_t)int_fld[FLD_LCORE];
+ (uint32_t)int_fld[FLD_LCORE];
++nb_lcore_params;
}
lcore_params = lcore_params_array;
--
2.34.1
[PATCH v6 08/14] examples/ipsec-secgw: fix lcore ID restriction
Currently the config option allows lcore IDs up to 255,
irrespective of RTE_MAX_LCORES and needs to be fixed.
The patch fixes these constraints by allowing all
lcore IDs up to RTE_MAX_LCORES. Also the queue
IDs are increased to support up to 65535.
Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample application")
Cc: sergio.gonzalez.mon...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Konstantin Ananyev
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/ipsec-secgw/event_helper.h | 2 +-
examples/ipsec-secgw/ipsec-secgw.c | 17 +
examples/ipsec-secgw/ipsec.c| 2 +-
examples/ipsec-secgw/ipsec.h| 4 ++--
4 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/examples/ipsec-secgw/event_helper.h
b/examples/ipsec-secgw/event_helper.h
index dfb81bfcf1..be635685b4 100644
--- a/examples/ipsec-secgw/event_helper.h
+++ b/examples/ipsec-secgw/event_helper.h
@@ -102,7 +102,7 @@ struct eh_event_link_info {
/**< Event port ID */
uint8_t eventq_id;
/**< Event queue to be linked to the port */
- uint8_t lcore_id;
+ uint32_t lcore_id;
/**< Lcore to be polling on this port */
};
diff --git a/examples/ipsec-secgw/ipsec-secgw.c
b/examples/ipsec-secgw/ipsec-secgw.c
index 106a058b60..0fa9622626 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -221,7 +221,7 @@ static const char *cfgfile;
struct lcore_params {
uint16_t port_id;
uint16_t queue_id;
- uint8_t lcore_id;
+ uint32_t lcore_id;
} __rte_cache_aligned;
static struct lcore_params lcore_params_array[MAX_LCORE_PARAMS];
@@ -807,7 +807,7 @@ check_flow_params(uint16_t fdir_portid, uint8_t fdir_qid)
static int32_t
check_poll_mode_params(struct eh_conf *eh_conf)
{
- uint8_t lcore;
+ uint32_t lcore;
uint16_t portid;
uint16_t i;
int32_t socket_id;
@@ -826,13 +826,13 @@ check_poll_mode_params(struct eh_conf *eh_conf)
for (i = 0; i < nb_lcore_params; ++i) {
lcore = lcore_params[i].lcore_id;
if (!rte_lcore_is_enabled(lcore)) {
- printf("error: lcore %hhu is not enabled in "
+ printf("error: lcore %u is not enabled in "
"lcore mask\n", lcore);
return -1;
}
socket_id = rte_lcore_to_socket_id(lcore);
if (socket_id != 0 && numa_on == 0) {
- printf("warning: lcore %hhu is on socket %d "
+ printf("warning: lcore %u is on socket %d "
"with numa off\n",
lcore, socket_id);
}
@@ -867,7 +867,7 @@ static int32_t
init_lcore_rx_queues(void)
{
uint16_t i, nb_rx_queue;
- uint8_t lcore;
+ uint32_t lcore;
for (i = 0; i < nb_lcore_params; ++i) {
lcore = lcore_params[i].lcore_id;
@@ -1049,7 +1049,7 @@ parse_config(const char *q_arg)
int32_t i;
uint32_t size;
uint32_t max_fld[_NUM_FLD] = {USHRT_MAX,
- USHRT_MAX, UCHAR_MAX};
+ USHRT_MAX, RTE_MAX_LCORE};
nb_lcore_params = 0;
@@ -1083,7 +1083,7 @@ parse_config(const char *q_arg)
lcore_params_array[nb_lcore_params].queue_id =
(uint16_t)int_fld[FLD_QUEUE];
lcore_params_array[nb_lcore_params].lcore_id =
- (uint8_t)int_fld[FLD_LCORE];
+ (uint32_t)int_fld[FLD_LCORE];
++nb_lcore_params;
}
lcore_params = lcore_params_array;
@@ -1919,7 +1919,8 @@ port_init(uint16_t portid, uint64_t req_rx_offloads,
uint64_t req_tx_offloads,
struct rte_eth_dev_info dev_info;
struct rte_eth_txconf *txconf;
uint16_t nb_tx_queue, nb_rx_queue;
- uint16_t tx_queueid, rx_queueid, queue, lcore_id;
+ uint16_t tx_queueid, rx_queueid, queue;
+ uint32_t lcore_id;
int32_t ret, socket_id;
struct lcore_conf *qconf;
struct rte_ether_addr ethaddr;
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index c321108119..b52b0ffc3d 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -259,7 +259,7 @@ create_lookaside_session(struct ipsec_ctx
*ipsec_ctx_lcore[],
continue;
/* Looking for cryptodev, which can handle this SA */
- key.lcore_id = (uint8_t)lcore_id;
+ key.lcore_id = lcore_id;
key.cipher_algo = (uint8_t)sa->cipher_algo;
key.auth_algo = (uint8_t)sa->auth_algo;
key.aead_algo = (uint8_t)sa->aead_algo;
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index 29b9b283f0..6526a80d81 100644
--
[PATCH v6 09/14] examples/qos_sched: fix lcore ID restriction
Currently the config option allows lcore IDs up to 255,
irrespective of RTE_MAX_LCORES and needs to be fixed.
The patch fixes these constraints by allowing all
lcore IDs up to RTE_MAX_LCORES. Also the queue
IDs are increased to support up to 65535.
Fixes: de3cfa2c9823 ("sched: initial import")
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/qos_sched/args.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/examples/qos_sched/args.c b/examples/qos_sched/args.c
index 8d61d3e454..886542b3c1 100644
--- a/examples/qos_sched/args.c
+++ b/examples/qos_sched/args.c
@@ -184,10 +184,10 @@ app_parse_flow_conf(const char *conf_str)
pconf->rx_port = vals[0];
pconf->tx_port = vals[1];
- pconf->rx_core = (uint8_t)vals[2];
- pconf->wt_core = (uint8_t)vals[3];
+ pconf->rx_core = vals[2];
+ pconf->wt_core = vals[3];
if (ret == 5)
- pconf->tx_core = (uint8_t)vals[4];
+ pconf->tx_core = vals[4];
else
pconf->tx_core = pconf->wt_core;
--
2.34.1
[PATCH v6 10/14] examples/vm_power_manager: fix lcore ID restriction
Currently the config option allows lcore IDs up to 255,
irrespective of RTE_MAX_LCORES and needs to be fixed.
The patch fixes these constraints by allowing all
lcore IDs up to RTE_MAX_LCORES. Also the queue
IDs are increased to support up to 65535.
Fixes: 0e8f47491f09 ("examples/vm_power: add command to query CPU frequency")
Cc: marcinx.hajkow...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/vm_power_manager/guest_cli/vm_power_cli_guest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
index 94bfbbaf78..5eddb47847 100644
--- a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
+++ b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
@@ -401,7 +401,7 @@ check_response_cmd(unsigned int lcore_id, int *result)
struct cmd_set_cpu_freq_result {
cmdline_fixed_string_t set_cpu_freq;
- uint8_t lcore_id;
+ uint32_t lcore_id;
cmdline_fixed_string_t cmd;
};
@@ -444,7 +444,7 @@ cmdline_parse_token_string_t cmd_set_cpu_freq =
set_cpu_freq, "set_cpu_freq");
cmdline_parse_token_num_t cmd_set_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_set_cpu_freq_result,
- lcore_id, RTE_UINT8);
+ lcore_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_cpu_freq_cmd_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_set_cpu_freq_result,
cmd, "up#down#min#max#enable_turbo#disable_turbo");
--
2.34.1
[PATCH v6 11/14] examples/l3fwd: fix port ID restriction
Currently application supports port IDs up to 255
irrespective of RTE_MAX_ETHPORTS.
The patch fixes these constraints by allowing port
IDs up to RTE_MAX_ETHPORTS.
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Konstantin Ananyev
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/l3fwd/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 9fb4fe97d4..19e4d9dfa2 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -500,7 +500,7 @@ parse_config(const char *q_arg)
char *str_fld[_NUM_FLD];
int i;
unsigned size;
- uint32_t max_fld[_NUM_FLD] = {USHRT_MAX,
+ uint32_t max_fld[_NUM_FLD] = {RTE_MAX_ETHPORTS,
USHRT_MAX, RTE_MAX_LCORE};
nb_lcore_params = 0;
@@ -530,7 +530,7 @@ parse_config(const char *q_arg)
return -1;
}
lcore_params_array[nb_lcore_params].port_id =
- (uint8_t)int_fld[FLD_PORT];
+ (uint16_t)int_fld[FLD_PORT];
lcore_params_array[nb_lcore_params].queue_id =
(uint16_t)int_fld[FLD_QUEUE];
lcore_params_array[nb_lcore_params].lcore_id =
--
2.34.1
[PATCH v6 12/14] examples/l3fwd-power: fix port ID restriction
Currently application supports port IDs up to 255
irrespective of RTE_MAX_ETHPORTS.
The patch fixes these constraints by allowing port
IDs up to RTE_MAX_ETHPORTS.
Fixes: f88e7c175a68 ("examples/l3fwd-power: add high/regular perf cores
options")
Cc: radu.nico...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/l3fwd-power/main.c | 4 ++--
examples/l3fwd-power/perf_core.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index 5411592dca..822b802f29 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -1658,7 +1658,7 @@ parse_config(const char *q_arg)
char *str_fld[_NUM_FLD];
int i;
unsigned size;
- unsigned int max_fld[_NUM_FLD] = {USHRT_MAX,
+ unsigned int max_fld[_NUM_FLD] = {RTE_MAX_ETHPORTS,
USHRT_MAX, RTE_MAX_LCORE};
nb_lcore_params = 0;
@@ -1689,7 +1689,7 @@ parse_config(const char *q_arg)
return -1;
}
lcore_params_array[nb_lcore_params].port_id =
- (uint8_t)int_fld[FLD_PORT];
+ (uint16_t)int_fld[FLD_PORT];
lcore_params_array[nb_lcore_params].queue_id =
(uint16_t)int_fld[FLD_QUEUE];
lcore_params_array[nb_lcore_params].lcore_id =
diff --git a/examples/l3fwd-power/perf_core.c b/examples/l3fwd-power/perf_core.c
index d8b35d062c..c2cdc4bf49 100644
--- a/examples/l3fwd-power/perf_core.c
+++ b/examples/l3fwd-power/perf_core.c
@@ -132,7 +132,7 @@ parse_perf_config(const char *q_arg)
char *str_fld[_NUM_FLD];
int i;
unsigned int size;
- unsigned int max_fld[_NUM_FLD] = {USHRT_MAX, USHRT_MAX,
+ unsigned int max_fld[_NUM_FLD] = {RTE_MAX_ETHPORTS, USHRT_MAX,
UCHAR_MAX, RTE_MAX_LCORE};
nb_prf_lc_prms = 0;
@@ -165,7 +165,7 @@ parse_perf_config(const char *q_arg)
return -1;
}
prf_lc_prms[nb_prf_lc_prms].port_id =
- (uint8_t)int_fld[FLD_PORT];
+ (uint16_t)int_fld[FLD_PORT];
prf_lc_prms[nb_prf_lc_prms].queue_id =
(uint16_t)int_fld[FLD_QUEUE];
prf_lc_prms[nb_prf_lc_prms].high_perf =
--
2.34.1
[PATCH v6 14/14] examples/ipsec-secgw: fix port ID restriction
Currently application supports port IDs up to 255
irrespective of RTE_MAX_ETHPORTS.
The patch fixes these constraints by allowing port
IDs up to RTE_MAX_ETHPORTS.
Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample application")
Cc: sergio.gonzalez.mon...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Konstantin Ananyev
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/ipsec-secgw/ipsec-secgw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/examples/ipsec-secgw/ipsec-secgw.c
b/examples/ipsec-secgw/ipsec-secgw.c
index 0fa9622626..dc7491a2b9 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -1048,7 +1048,7 @@ parse_config(const char *q_arg)
char *str_fld[_NUM_FLD];
int32_t i;
uint32_t size;
- uint32_t max_fld[_NUM_FLD] = {USHRT_MAX,
+ uint32_t max_fld[_NUM_FLD] = {RTE_MAX_ETHPORTS,
USHRT_MAX, RTE_MAX_LCORE};
nb_lcore_params = 0;
@@ -1079,7 +1079,7 @@ parse_config(const char *q_arg)
return -1;
}
lcore_params_array[nb_lcore_params].port_id =
- (uint8_t)int_fld[FLD_PORT];
+ (uint16_t)int_fld[FLD_PORT];
lcore_params_array[nb_lcore_params].queue_id =
(uint16_t)int_fld[FLD_QUEUE];
lcore_params_array[nb_lcore_params].lcore_id =
--
2.34.1
[PATCH v6 00/10] fix lcore ID restriction
With modern CPUs, it is possible to have higher CPU count thus we can have higher RTE_MAX_LCORES. In DPDK sample applications, the current config lcore options are hard limited to 255. The patchset fixes these constraints by allowing all lcore IDs up to RTE_MAX_LCORES. Also the queue IDs are increased to support up to 65535. The port ID constraints were also fixed to support up to RTE_MAX_ETHPORTS. v6: - split queue_id, lcore_id and port_id changes as separate patches. - updated git commit description on individual patches v5: - updated lcore_id type to uint32_t v4: - fixed build errors with queue_id type in ipsec-secgw v3: - updated queue_id type to uint16_t v2: - fixed typo with lcore_id type in l3fwd Sivaprasad Tummala (10): examples/l3fwd: fix queue ID restriction examples/l3fwd-power: fix queue ID restriction examples/l3fwd-graph: fix queue ID restriction examples/ipsec-secgw: fix queue ID restriction examples/l3fwd: fix lcore ID restriction examples/l3fwd-power: fix lcore ID restriction examples/l3fwd-graph: fix lcore ID restriction examples/ipsec-secgw: fix lcore ID restriction examples/qos_sched: fix lcore ID restriction examples/vm_power_manager: fix lcore ID restriction examples/ipsec-secgw/event_helper.h | 2 +- examples/ipsec-secgw/ipsec-secgw.c| 35 +-- examples/ipsec-secgw/ipsec.c | 2 +- examples/ipsec-secgw/ipsec.h | 6 +- examples/ipsec-secgw/ipsec_worker.c | 10 ++-- examples/l3fwd-graph/main.c | 31 +- examples/l3fwd-power/main.c | 59 +-- examples/l3fwd-power/main.h | 4 +- examples/l3fwd-power/perf_core.c | 14 +++-- examples/l3fwd/l3fwd.h| 2 +- examples/l3fwd/l3fwd_acl.c| 4 +- examples/l3fwd/l3fwd_em.c | 4 +- examples/l3fwd/l3fwd_event.h | 2 +- examples/l3fwd/l3fwd_fib.c| 4 +- examples/l3fwd/l3fwd_lpm.c| 5 +- examples/l3fwd/main.c | 38 ++-- examples/qos_sched/args.c | 6 +- .../guest_cli/vm_power_cli_guest.c| 4 +- 18 files changed, 119 insertions(+), 113 deletions(-) -- 2.34.1
[PATCH v6 13/14] examples/l3fwd-graph: fix port ID restriction
Currently application supports port IDs up to 255
irrespective of RTE_MAX_ETHPORTS.
The patch fixes these constraints by allowing port
IDs up to RTE_MAX_ETHPORTS.
Fixes: 08bd1a174461 ("examples/l3fwd-graph: add graph-based l3fwd skeleton")
Cc: ndabilpu...@marvell.com
Cc: sta...@dpdk.org
Signed-off-by: Sivaprasad Tummala
Acked-by: Morten Brørup
Acked-by: Ferruh Yigit
---
examples/l3fwd-graph/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/l3fwd-graph/main.c b/examples/l3fwd-graph/main.c
index 8b7aa6642b..557ac6d823 100644
--- a/examples/l3fwd-graph/main.c
+++ b/examples/l3fwd-graph/main.c
@@ -448,7 +448,7 @@ parse_config(const char *q_arg)
}
lcore_params_array[nb_lcore_params].port_id =
- (uint8_t)int_fld[FLD_PORT];
+ (uint16_t)int_fld[FLD_PORT];
lcore_params_array[nb_lcore_params].queue_id =
(uint16_t)int_fld[FLD_QUEUE];
lcore_params_array[nb_lcore_params].lcore_id =
--
2.34.1
[PATCH v2 00/45] use stdatomic API
This series converts all non-generic built atomics to use the rte_atomic macros that allow optional enablement of standard C11 atomics. Use of generic atomics for non-scalar types are not converted in this change and will be evaluated as a part of a separate series. Note if this series ends up requiring too much rebasing due to tree churn before it is merged i will break it up into smaller series. v2: * drop the net/sfc driver from the series. the sfc driver uses generic __atomic_store not handled by the current macros. the cases where generic __atomic_xxx are used on objects that can't be accepted by __atomic_xxx_n will be addressed in a separate series. Tyler Retzlaff (45): net/mlx5: use rte stdatomic API net/ixgbe: use rte stdatomic API net/iavf: use rte stdatomic API net/ice: use rte stdatomic API net/i40e: use rte stdatomic API net/hns3: use rte stdatomic API net/bnxt: use rte stdatomic API net/cpfl: use rte stdatomic API net/af_xdp: use rte stdatomic API net/octeon_ep: use rte stdatomic API net/octeontx: use rte stdatomic API net/cxgbe: use rte stdatomic API net/gve: use rte stdatomic API net/memif: use rte stdatomic API net/thunderx: use rte stdatomic API net/virtio: use rte stdatomic API net/hinic: use rte stdatomic API net/idpf: use rte stdatomic API net/qede: use rte stdatomic API net/ring: use rte stdatomic API vdpa/mlx5: use rte stdatomic API raw/ifpga: use rte stdatomic API event/opdl: use rte stdatomic API event/octeontx: use rte stdatomic API event/dsw: use rte stdatomic API dma/skeleton: use rte stdatomic API crypto/octeontx: use rte stdatomic API common/mlx5: use rte stdatomic API common/idpf: use rte stdatomic API common/iavf: use rte stdatomic API baseband/acc: use rte stdatomic API net/txgbe: use rte stdatomic API net/null: use rte stdatomic API event/dlb2: use rte stdatomic API dma/idxd: use rte stdatomic API crypto/ccp: use rte stdatomic API common/cpt: use rte stdatomic API bus/vmbus: use rte stdatomic API examples: use rte stdatomic API app/dumpcap: use rte stdatomic API app/test: use rte stdatomic API app/test-eventdev: use rte stdatomic API app/test-crypto-perf: use rte stdatomic API app/test-compress-perf: use rte stdatomic API app/test-bbdev: use rte stdatomic API app/dumpcap/main.c | 12 +- app/test-bbdev/test_bbdev_perf.c | 183 + app/test-compress-perf/comp_perf_test_common.h | 2 +- app/test-compress-perf/comp_perf_test_cyclecount.c | 4 +- app/test-compress-perf/comp_perf_test_throughput.c | 10 +- app/test-compress-perf/comp_perf_test_verify.c | 6 +- app/test-crypto-perf/cperf_test_latency.c | 6 +- app/test-crypto-perf/cperf_test_pmd_cyclecount.c | 10 +- app/test-crypto-perf/cperf_test_throughput.c | 10 +- app/test-crypto-perf/cperf_test_verify.c | 10 +- app/test-eventdev/test_order_atq.c | 4 +- app/test-eventdev/test_order_common.c | 5 +- app/test-eventdev/test_order_common.h | 8 +- app/test-eventdev/test_order_queue.c | 4 +- app/test-eventdev/test_perf_common.h | 6 +- app/test/test_bpf.c| 46 -- app/test/test_distributor.c| 114 ++--- app/test/test_distributor_perf.c | 4 +- app/test/test_func_reentrancy.c| 28 ++-- app/test/test_hash_multiwriter.c | 16 +- app/test/test_hash_readwrite.c | 74 - app/test/test_hash_readwrite_lf_perf.c | 88 +- app/test/test_lcores.c | 25 +-- app/test/test_lpm_perf.c | 14 +- app/test/test_mcslock.c| 12 +- app/test/test_mempool_perf.c | 9 +- app/test/test_pflock.c | 13 +- app/test/test_pmd_perf.c | 10 +- app/test/test_rcu_qsbr_perf.c | 114 ++--- app/test/test_ring_perf.c | 11 +- app/test/test_ring_stress_impl.h | 10 +- app/test/test_rwlock.c | 9 +- app/test/test_seqlock.c| 6 +- app/test/test_service_cores.c | 24 +-- app/test/test_spinlock.c | 9 +- app/test/test_stack_perf.c | 12 +- app/test/test_threads.c| 33 ++-- app/test/test_ticketlock.c | 9 +- app/test/test_timer.c | 31 ++-- drivers/baseband/acc/rte_acc100_pmd.c | 36 ++-- drivers/baseband/acc/rte_vrb_pmd.c | 46 -- drivers/bus/vmbus/vmbus_channel.c | 9 +- drivers/common/cpt
[PATCH v2 02/45] net/ixgbe: use rte stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with
corresponding rte_atomic_xxx optional rte stdatomic API.
Signed-off-by: Tyler Retzlaff
---
drivers/net/ixgbe/ixgbe_ethdev.c | 14 --
drivers/net/ixgbe/ixgbe_ethdev.h | 2 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 4 ++--
3 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index c61c52b..e63ae1a 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1130,7 +1130,7 @@ struct rte_ixgbe_xstats_name_off {
}
/* NOTE: review for potential ordering optimization */
- __atomic_clear(&ad->link_thread_running, __ATOMIC_SEQ_CST);
+ rte_atomic_store_explicit(&ad->link_thread_running, 0,
rte_memory_order_seq_cst);
ixgbe_parse_devargs(eth_dev->data->dev_private,
pci_dev->device.devargs);
rte_eth_copy_pci_info(eth_dev, pci_dev);
@@ -1638,7 +1638,7 @@ static int ixgbe_l2_tn_filter_init(struct rte_eth_dev
*eth_dev)
}
/* NOTE: review for potential ordering optimization */
- __atomic_clear(&ad->link_thread_running, __ATOMIC_SEQ_CST);
+ rte_atomic_store_explicit(&ad->link_thread_running, 0,
rte_memory_order_seq_cst);
ixgbevf_parse_devargs(eth_dev->data->dev_private,
pci_dev->device.devargs);
@@ -4203,7 +4203,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused
struct rte_eth_dev *dev,
uint32_t timeout = timeout_ms ? timeout_ms : WARNING_TIMEOUT;
/* NOTE: review for potential ordering optimization */
- while (__atomic_load_n(&ad->link_thread_running, __ATOMIC_SEQ_CST)) {
+ while (rte_atomic_load_explicit(&ad->link_thread_running,
rte_memory_order_seq_cst)) {
msec_delay(1);
timeout--;
@@ -4240,7 +4240,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused
struct rte_eth_dev *dev,
intr->flags &= ~IXGBE_FLAG_NEED_LINK_CONFIG;
/* NOTE: review for potential ordering optimization */
- __atomic_clear(&ad->link_thread_running, __ATOMIC_SEQ_CST);
+ rte_atomic_store_explicit(&ad->link_thread_running, 0,
rte_memory_order_seq_cst);
return 0;
}
@@ -4336,7 +4336,8 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused
struct rte_eth_dev *dev,
if (ixgbe_get_media_type(hw) == ixgbe_media_type_fiber) {
ixgbe_dev_wait_setup_link_complete(dev, 0);
/* NOTE: review for potential ordering optimization */
- if (!__atomic_test_and_set(&ad->link_thread_running,
__ATOMIC_SEQ_CST)) {
+ if
(!rte_atomic_exchange_explicit(&ad->link_thread_running, 1,
+ rte_memory_order_seq_cst)) {
/* To avoid race condition between threads, set
* the IXGBE_FLAG_NEED_LINK_CONFIG flag only
* when there is no link thread running.
@@ -4348,7 +4349,8 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused
struct rte_eth_dev *dev,
PMD_DRV_LOG(ERR,
"Create link thread failed!");
/* NOTE: review for potential ordering
optimization */
-
__atomic_clear(&ad->link_thread_running, __ATOMIC_SEQ_CST);
+
rte_atomic_store_explicit(&ad->link_thread_running, 0,
+ rte_memory_order_seq_cst);
}
} else {
PMD_DRV_LOG(ERR,
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index 22fc3be..8ad841e 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -511,7 +511,7 @@ struct ixgbe_adapter {
*/
uint8_t pflink_fullchk;
uint8_t mac_ctrl_frame_fwd;
- bool link_thread_running;
+ RTE_ATOMIC(bool) link_thread_running;
rte_thread_t link_thread_tid;
};
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index f6c17d4..e7dfd6f 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -1831,7 +1831,7 @@
* Use acquire fence to ensure that status_error which includes
* DD bit is loaded before loading of other descriptor words.
*/
- rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
+ rte_atomic_thread_fence(rte_memory_order_acquire);
rxd = *rxdp;
@@ -2114,7 +2114,7 @@
* Use acquire fence to ensure that status_error which includes
* DD bit is loaded before loading of other descriptor words.
*/
- rt
[PATCH v2 01/45] net/mlx5: use rte stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with
corresponding rte_atomic_xxx optional rte stdatomic API.
Signed-off-by: Tyler Retzlaff
---
drivers/net/mlx5/linux/mlx5_ethdev_os.c | 6 +-
drivers/net/mlx5/linux/mlx5_verbs.c | 9 ++-
drivers/net/mlx5/mlx5.c | 9 ++-
drivers/net/mlx5/mlx5.h | 66 -
drivers/net/mlx5/mlx5_flow.c| 37 +-
drivers/net/mlx5/mlx5_flow.h| 8 +-
drivers/net/mlx5/mlx5_flow_aso.c| 43 ++-
drivers/net/mlx5/mlx5_flow_dv.c | 126
drivers/net/mlx5/mlx5_flow_flex.c | 14 ++--
drivers/net/mlx5/mlx5_flow_hw.c | 61 +---
drivers/net/mlx5/mlx5_flow_meter.c | 30
drivers/net/mlx5/mlx5_flow_quota.c | 32
drivers/net/mlx5/mlx5_hws_cnt.c | 71 +-
drivers/net/mlx5/mlx5_hws_cnt.h | 10 +--
drivers/net/mlx5/mlx5_rx.h | 14 ++--
drivers/net/mlx5/mlx5_rxq.c | 30
drivers/net/mlx5/mlx5_trigger.c | 2 +-
drivers/net/mlx5/mlx5_tx.h | 18 ++---
drivers/net/mlx5/mlx5_txpp.c| 84 ++---
drivers/net/mlx5/mlx5_txq.c | 12 +--
drivers/net/mlx5/mlx5_utils.c | 10 +--
drivers/net/mlx5/mlx5_utils.h | 4 +-
22 files changed, 351 insertions(+), 345 deletions(-)
diff --git a/drivers/net/mlx5/linux/mlx5_ethdev_os.c
b/drivers/net/mlx5/linux/mlx5_ethdev_os.c
index 40ea9d2..70bba6c 100644
--- a/drivers/net/mlx5/linux/mlx5_ethdev_os.c
+++ b/drivers/net/mlx5/linux/mlx5_ethdev_os.c
@@ -1918,9 +1918,9 @@ int mlx5_txpp_map_hca_bar(struct rte_eth_dev *dev)
return -ENOTSUP;
}
/* Check there is no concurrent mapping in other thread. */
- if (!__atomic_compare_exchange_n(&ppriv->hca_bar, &expected,
-base, false,
-__ATOMIC_RELAXED, __ATOMIC_RELAXED))
+ if (!rte_atomic_compare_exchange_strong_explicit(&ppriv->hca_bar,
&expected,
+base,
+rte_memory_order_relaxed,
rte_memory_order_relaxed))
rte_mem_unmap(base, MLX5_ST_SZ_BYTES(initial_seg));
return 0;
}
diff --git a/drivers/net/mlx5/linux/mlx5_verbs.c
b/drivers/net/mlx5/linux/mlx5_verbs.c
index b54f3cc..63da8f4 100644
--- a/drivers/net/mlx5/linux/mlx5_verbs.c
+++ b/drivers/net/mlx5/linux/mlx5_verbs.c
@@ -1117,7 +1117,7 @@
return 0;
}
/* Only need to check refcnt, 0 after "sh" is allocated. */
- if (!!(__atomic_fetch_add(&sh->self_lb.refcnt, 1, __ATOMIC_RELAXED))) {
+ if (!!(rte_atomic_fetch_add_explicit(&sh->self_lb.refcnt, 1,
rte_memory_order_relaxed))) {
MLX5_ASSERT(sh->self_lb.ibv_cq && sh->self_lb.qp);
priv->lb_used = 1;
return 0;
@@ -1163,7 +1163,7 @@
claim_zero(mlx5_glue->destroy_cq(sh->self_lb.ibv_cq));
sh->self_lb.ibv_cq = NULL;
}
- __atomic_fetch_sub(&sh->self_lb.refcnt, 1, __ATOMIC_RELAXED);
+ rte_atomic_fetch_sub_explicit(&sh->self_lb.refcnt, 1,
rte_memory_order_relaxed);
return -rte_errno;
#else
RTE_SET_USED(dev);
@@ -1186,8 +1186,9 @@
if (!priv->lb_used)
return;
- MLX5_ASSERT(__atomic_load_n(&sh->self_lb.refcnt, __ATOMIC_RELAXED));
- if (!(__atomic_fetch_sub(&sh->self_lb.refcnt, 1, __ATOMIC_RELAXED) -
1)) {
+ MLX5_ASSERT(rte_atomic_load_explicit(&sh->self_lb.refcnt,
rte_memory_order_relaxed));
+ if (!(rte_atomic_fetch_sub_explicit(&sh->self_lb.refcnt, 1,
+ rte_memory_order_relaxed) - 1)) {
if (sh->self_lb.qp) {
claim_zero(mlx5_glue->destroy_qp(sh->self_lb.qp));
sh->self_lb.qp = NULL;
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index d1a6382..2ff94db 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -855,8 +855,8 @@
ct_pool = mng->pools[idx];
for (i = 0; i < MLX5_ASO_CT_ACTIONS_PER_POOL; i++) {
ct = &ct_pool->actions[i];
- val = __atomic_fetch_sub(&ct->refcnt, 1,
-__ATOMIC_RELAXED);
+ val = rte_atomic_fetch_sub_explicit(&ct->refcnt, 1,
+rte_memory_order_relaxed);
MLX5_ASSERT(val == 1);
if (val > 1)
cnt++;
@@ -1082,7 +1082,8 @@
DRV_LOG(ERR, "Dynamic flex parser is not supported on HWS");
return -ENOTSUP;
}
- if (__atomic_fetch_add(&priv->sh->srh_flex_parser.refcnt, 1,
__ATOMIC_RELAXED) + 1 > 1)
+ if (rte_atomic_fetch_add_expl
[PATCH v2 03/45] net/iavf: use rte stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with
corresponding rte_atomic_xxx optional rte stdatomic API.
Signed-off-by: Tyler Retzlaff
---
drivers/net/iavf/iavf.h | 16
drivers/net/iavf/iavf_rxtx.c | 4 ++--
drivers/net/iavf/iavf_rxtx_vec_neon.c | 2 +-
drivers/net/iavf/iavf_vchnl.c | 14 +++---
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index 824ae4a..6b977e5 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -238,8 +238,8 @@ struct iavf_info {
struct virtchnl_vlan_caps vlan_v2_caps;
uint64_t supported_rxdid;
uint8_t *proto_xtr; /* proto xtr type for all queues */
- volatile enum virtchnl_ops pend_cmd; /* pending command not finished */
- uint32_t pend_cmd_count;
+ volatile RTE_ATOMIC(enum virtchnl_ops) pend_cmd; /* pending command not
finished */
+ RTE_ATOMIC(uint32_t) pend_cmd_count;
int cmd_retval; /* return value of the cmd response from PF */
uint8_t *aq_resp; /* buffer to store the adminq response from PF */
@@ -456,13 +456,13 @@ struct iavf_cmd_info {
_atomic_set_cmd(struct iavf_info *vf, enum virtchnl_ops ops)
{
enum virtchnl_ops op_unk = VIRTCHNL_OP_UNKNOWN;
- int ret = __atomic_compare_exchange(&vf->pend_cmd, &op_unk, &ops,
- 0, __ATOMIC_ACQUIRE, __ATOMIC_ACQUIRE);
+ int ret = rte_atomic_compare_exchange_strong_explicit(&vf->pend_cmd,
&op_unk, ops,
+ rte_memory_order_acquire, rte_memory_order_acquire);
if (!ret)
PMD_DRV_LOG(ERR, "There is incomplete cmd %d", vf->pend_cmd);
- __atomic_store_n(&vf->pend_cmd_count, 1, __ATOMIC_RELAXED);
+ rte_atomic_store_explicit(&vf->pend_cmd_count, 1,
rte_memory_order_relaxed);
return !ret;
}
@@ -472,13 +472,13 @@ struct iavf_cmd_info {
_atomic_set_async_response_cmd(struct iavf_info *vf, enum virtchnl_ops ops)
{
enum virtchnl_ops op_unk = VIRTCHNL_OP_UNKNOWN;
- int ret = __atomic_compare_exchange(&vf->pend_cmd, &op_unk, &ops,
- 0, __ATOMIC_ACQUIRE, __ATOMIC_ACQUIRE);
+ int ret = rte_atomic_compare_exchange_strong_explicit(&vf->pend_cmd,
&op_unk, ops,
+ rte_memory_order_acquire, rte_memory_order_acquire);
if (!ret)
PMD_DRV_LOG(ERR, "There is incomplete cmd %d", vf->pend_cmd);
- __atomic_store_n(&vf->pend_cmd_count, 2, __ATOMIC_RELAXED);
+ rte_atomic_store_explicit(&vf->pend_cmd_count, 2,
rte_memory_order_relaxed);
return !ret;
}
diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index 0a5246d..d1d4e9f 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -2025,7 +2025,7 @@ struct iavf_txq_ops iavf_txq_release_mbufs_ops[] = {
s[j] = rte_le_to_cpu_16(rxdp[j].wb.status_error0);
/* This barrier is to order loads of different words in the
descriptor */
- rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
+ rte_atomic_thread_fence(rte_memory_order_acquire);
/* Compute how many contiguous DD bits were set */
for (j = 0, nb_dd = 0; j < IAVF_LOOK_AHEAD; j++) {
@@ -2152,7 +2152,7 @@ struct iavf_txq_ops iavf_txq_release_mbufs_ops[] = {
}
/* This barrier is to order loads of different words in the
descriptor */
- rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
+ rte_atomic_thread_fence(rte_memory_order_acquire);
/* Compute how many contiguous DD bits were set */
for (j = 0, nb_dd = 0; j < IAVF_LOOK_AHEAD; j++) {
diff --git a/drivers/net/iavf/iavf_rxtx_vec_neon.c
b/drivers/net/iavf/iavf_rxtx_vec_neon.c
index 83825aa..20b656e 100644
--- a/drivers/net/iavf/iavf_rxtx_vec_neon.c
+++ b/drivers/net/iavf/iavf_rxtx_vec_neon.c
@@ -273,7 +273,7 @@
descs[0] = vld1q_u64((uint64_t *)(rxdp));
/* Use acquire fence to order loads of descriptor qwords */
- rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
+ rte_atomic_thread_fence(rte_memory_order_acquire);
/* A.2 reload qword0 to make it ordered after qword1 load */
descs[3] = vld1q_lane_u64((uint64_t *)(rxdp + 3), descs[3], 0);
descs[2] = vld1q_lane_u64((uint64_t *)(rxdp + 2), descs[2], 0);
diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
index d30..6d5969f 100644
--- a/drivers/net/iavf/iavf_vchnl.c
+++ b/drivers/net/iavf/iavf_vchnl.c
@@ -41,7 +41,7 @@ struct iavf_event_element {
};
struct iavf_event_handler {
- uint32_t ndev;
+ RTE_ATOMIC(uint32_t) ndev;
rte_thread_t tid;
int fd[2];
pthread_mutex_t lock;
@@ -129,7 +129,7 @@ struct iavf_event_handler {
{
struct iavf_
[PATCH v2 04/45] net/ice: use rte stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with
corresponding rte_atomic_xxx optional rte stdatomic API.
Signed-off-by: Tyler Retzlaff
---
drivers/net/ice/base/ice_osdep.h | 4 ++--
drivers/net/ice/ice_dcf.c| 6 +++---
drivers/net/ice/ice_dcf.h| 2 +-
drivers/net/ice/ice_dcf_ethdev.c | 8
drivers/net/ice/ice_dcf_parent.c | 16
drivers/net/ice/ice_ethdev.c | 12 ++--
drivers/net/ice/ice_ethdev.h | 2 +-
7 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ice/base/ice_osdep.h b/drivers/net/ice/base/ice_osdep.h
index 0e14b93..c17f1bf 100644
--- a/drivers/net/ice/base/ice_osdep.h
+++ b/drivers/net/ice/base/ice_osdep.h
@@ -235,7 +235,7 @@ struct ice_lock {
ice_alloc_dma_mem(__rte_unused struct ice_hw *hw,
struct ice_dma_mem *mem, u64 size)
{
- static uint64_t ice_dma_memzone_id;
+ static RTE_ATOMIC(uint64_t) ice_dma_memzone_id;
const struct rte_memzone *mz = NULL;
char z_name[RTE_MEMZONE_NAMESIZE];
@@ -243,7 +243,7 @@ struct ice_lock {
return NULL;
snprintf(z_name, sizeof(z_name), "ice_dma_%" PRIu64,
- __atomic_fetch_add(&ice_dma_memzone_id, 1, __ATOMIC_RELAXED));
+ rte_atomic_fetch_add_explicit(&ice_dma_memzone_id, 1,
rte_memory_order_relaxed));
mz = rte_memzone_reserve_bounded(z_name, size, SOCKET_ID_ANY, 0,
0, RTE_PGSIZE_2M);
if (!mz)
diff --git a/drivers/net/ice/ice_dcf.c b/drivers/net/ice/ice_dcf.c
index 7f8f516..204d4ea 100644
--- a/drivers/net/ice/ice_dcf.c
+++ b/drivers/net/ice/ice_dcf.c
@@ -764,7 +764,7 @@ struct virtchnl_proto_hdrs ice_dcf_inner_ipv6_sctp_tmplt = {
rte_spinlock_init(&hw->vc_cmd_queue_lock);
TAILQ_INIT(&hw->vc_cmd_queue);
- __atomic_store_n(&hw->vsi_update_thread_num, 0, __ATOMIC_RELAXED);
+ rte_atomic_store_explicit(&hw->vsi_update_thread_num, 0,
rte_memory_order_relaxed);
hw->arq_buf = rte_zmalloc("arq_buf", ICE_DCF_AQ_BUF_SZ, 0);
if (hw->arq_buf == NULL) {
@@ -888,8 +888,8 @@ struct virtchnl_proto_hdrs ice_dcf_inner_ipv6_sctp_tmplt = {
ice_dcf_dev_interrupt_handler, hw);
/* Wait for all `ice-thread` threads to exit. */
- while (__atomic_load_n(&hw->vsi_update_thread_num,
- __ATOMIC_ACQUIRE) != 0)
+ while (rte_atomic_load_explicit(&hw->vsi_update_thread_num,
+ rte_memory_order_acquire) != 0)
rte_delay_ms(ICE_DCF_CHECK_INTERVAL);
ice_dcf_mode_disable(hw);
diff --git a/drivers/net/ice/ice_dcf.h b/drivers/net/ice/ice_dcf.h
index aa2a723..7726681 100644
--- a/drivers/net/ice/ice_dcf.h
+++ b/drivers/net/ice/ice_dcf.h
@@ -105,7 +105,7 @@ struct ice_dcf_hw {
void (*vc_event_msg_cb)(struct ice_dcf_hw *dcf_hw,
uint8_t *msg, uint16_t msglen);
- int vsi_update_thread_num;
+ RTE_ATOMIC(int) vsi_update_thread_num;
uint8_t *arq_buf;
diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index d58ec9d..8f3a385 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -1743,7 +1743,7 @@ static int ice_dcf_xstats_get(struct rte_eth_dev *dev,
ice_dcf_adminq_need_retry(struct ice_adapter *ad)
{
return ad->hw.dcf_enabled &&
- !__atomic_load_n(&ad->dcf_state_on, __ATOMIC_RELAXED);
+ !rte_atomic_load_explicit(&ad->dcf_state_on,
rte_memory_order_relaxed);
}
/* Add UDP tunneling port */
@@ -1944,12 +1944,12 @@ static int ice_dcf_xstats_get(struct rte_eth_dev *dev,
adapter->real_hw.vc_event_msg_cb = ice_dcf_handle_pf_event_msg;
if (ice_dcf_init_hw(eth_dev, &adapter->real_hw) != 0) {
PMD_INIT_LOG(ERR, "Failed to init DCF hardware");
- __atomic_store_n(&parent_adapter->dcf_state_on, false,
-__ATOMIC_RELAXED);
+ rte_atomic_store_explicit(&parent_adapter->dcf_state_on, false,
+rte_memory_order_relaxed);
return -1;
}
- __atomic_store_n(&parent_adapter->dcf_state_on, true, __ATOMIC_RELAXED);
+ rte_atomic_store_explicit(&parent_adapter->dcf_state_on, true,
rte_memory_order_relaxed);
if (ice_dcf_init_parent_adapter(eth_dev) != 0) {
PMD_INIT_LOG(ERR, "Failed to init DCF parent adapter");
diff --git a/drivers/net/ice/ice_dcf_parent.c b/drivers/net/ice/ice_dcf_parent.c
index 6e845f4..a478b69 100644
--- a/drivers/net/ice/ice_dcf_parent.c
+++ b/drivers/net/ice/ice_dcf_parent.c
@@ -123,8 +123,8 @@ struct ice_dcf_reset_event_param {
container_of(hw, struct ice_dcf_adapter, real_hw);
struct ice_adapter *parent_adapter = &adapter->parent;
- __atomic_fetch_add(&hw->vsi_update_thread_num, 1,
- __ATOMIC_RELAXED);
+
[PATCH v2 06/45] net/hns3: use rte stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with
corresponding rte_atomic_xxx optional rte stdatomic API.
Signed-off-by: Tyler Retzlaff
---
drivers/net/hns3/hns3_cmd.c | 18 ++--
drivers/net/hns3/hns3_dcb.c | 2 +-
drivers/net/hns3/hns3_ethdev.c| 36 +++
drivers/net/hns3/hns3_ethdev.h| 32 ++---
drivers/net/hns3/hns3_ethdev_vf.c | 60 +++
drivers/net/hns3/hns3_intr.c | 36 +++
drivers/net/hns3/hns3_intr.h | 4 +--
drivers/net/hns3/hns3_mbx.c | 6 ++--
drivers/net/hns3/hns3_mp.c| 6 ++--
drivers/net/hns3/hns3_rxtx.c | 10 +++
drivers/net/hns3/hns3_tm.c| 4 +--
11 files changed, 107 insertions(+), 107 deletions(-)
diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index 001ff49..3c5fdbe 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -44,12 +44,12 @@
hns3_allocate_dma_mem(struct hns3_hw *hw, struct hns3_cmq_ring *ring,
uint64_t size, uint32_t alignment)
{
- static uint64_t hns3_dma_memzone_id;
+ static RTE_ATOMIC(uint64_t) hns3_dma_memzone_id;
const struct rte_memzone *mz = NULL;
char z_name[RTE_MEMZONE_NAMESIZE];
snprintf(z_name, sizeof(z_name), "hns3_dma_%" PRIu64,
- __atomic_fetch_add(&hns3_dma_memzone_id, 1, __ATOMIC_RELAXED));
+ rte_atomic_fetch_add_explicit(&hns3_dma_memzone_id, 1,
rte_memory_order_relaxed));
mz = rte_memzone_reserve_bounded(z_name, size, SOCKET_ID_ANY,
RTE_MEMZONE_IOVA_CONTIG, alignment,
RTE_PGSIZE_2M);
@@ -198,8 +198,8 @@
hns3_err(hw, "wrong cmd addr(%0x) head (%u, %u-%u)", addr, head,
csq->next_to_use, csq->next_to_clean);
if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
- __atomic_store_n(&hw->reset.disable_cmd, 1,
-__ATOMIC_RELAXED);
+ rte_atomic_store_explicit(&hw->reset.disable_cmd, 1,
+rte_memory_order_relaxed);
hns3_schedule_delayed_reset(HNS3_DEV_HW_TO_ADAPTER(hw));
}
@@ -313,7 +313,7 @@ static int hns3_cmd_poll_reply(struct hns3_hw *hw)
if (hns3_cmd_csq_done(hw))
return 0;
- if (__atomic_load_n(&hw->reset.disable_cmd, __ATOMIC_RELAXED)) {
+ if (rte_atomic_load_explicit(&hw->reset.disable_cmd,
rte_memory_order_relaxed)) {
hns3_err(hw,
"Don't wait for reply because of disable_cmd");
return -EBUSY;
@@ -360,7 +360,7 @@ static int hns3_cmd_poll_reply(struct hns3_hw *hw)
int retval;
uint32_t ntc;
- if (__atomic_load_n(&hw->reset.disable_cmd, __ATOMIC_RELAXED))
+ if (rte_atomic_load_explicit(&hw->reset.disable_cmd,
rte_memory_order_relaxed))
return -EBUSY;
rte_spinlock_lock(&hw->cmq.csq.lock);
@@ -747,7 +747,7 @@ static int hns3_cmd_poll_reply(struct hns3_hw *hw)
ret = -EBUSY;
goto err_cmd_init;
}
- __atomic_store_n(&hw->reset.disable_cmd, 0, __ATOMIC_RELAXED);
+ rte_atomic_store_explicit(&hw->reset.disable_cmd, 0,
rte_memory_order_relaxed);
ret = hns3_cmd_query_firmware_version_and_capability(hw);
if (ret) {
@@ -790,7 +790,7 @@ static int hns3_cmd_poll_reply(struct hns3_hw *hw)
return 0;
err_cmd_init:
- __atomic_store_n(&hw->reset.disable_cmd, 1, __ATOMIC_RELAXED);
+ rte_atomic_store_explicit(&hw->reset.disable_cmd, 1,
rte_memory_order_relaxed);
return ret;
}
@@ -819,7 +819,7 @@ static int hns3_cmd_poll_reply(struct hns3_hw *hw)
if (!hns->is_vf)
(void)hns3_firmware_compat_config(hw, false);
- __atomic_store_n(&hw->reset.disable_cmd, 1, __ATOMIC_RELAXED);
+ rte_atomic_store_explicit(&hw->reset.disable_cmd, 1,
rte_memory_order_relaxed);
/*
* A delay is added to ensure that the register cleanup operations
diff --git a/drivers/net/hns3/hns3_dcb.c b/drivers/net/hns3/hns3_dcb.c
index 915e4eb..2f917fe 100644
--- a/drivers/net/hns3/hns3_dcb.c
+++ b/drivers/net/hns3/hns3_dcb.c
@@ -648,7 +648,7 @@
* and configured directly to the hardware in the RESET_STAGE_RESTORE
* stage of the reset process.
*/
- if (__atomic_load_n(&hw->reset.resetting, __ATOMIC_RELAXED) == 0) {
+ if (rte_atomic_load_explicit(&hw->reset.resetting,
rte_memory_order_relaxed) == 0) {
for (i = 0; i < hw->rss_ind_tbl_size; i++)
rss_cfg->rss_indirection_tbl[i] =
i % hw->alloc_rss_size;
diff --git a/driv
[PATCH v2 05/45] net/i40e: use rte stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with
corresponding rte_atomic_xxx optional rte stdatomic API.
Signed-off-by: Tyler Retzlaff
---
drivers/net/i40e/i40e_ethdev.c| 4 ++--
drivers/net/i40e/i40e_rxtx.c | 6 +++---
drivers/net/i40e/i40e_rxtx_vec_neon.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 380ce1a..801cc95 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -4687,7 +4687,7 @@ enum i40e_status_code
u64 size,
u32 alignment)
{
- static uint64_t i40e_dma_memzone_id;
+ static RTE_ATOMIC(uint64_t) i40e_dma_memzone_id;
const struct rte_memzone *mz = NULL;
char z_name[RTE_MEMZONE_NAMESIZE];
@@ -4695,7 +4695,7 @@ enum i40e_status_code
return I40E_ERR_PARAM;
snprintf(z_name, sizeof(z_name), "i40e_dma_%" PRIu64,
- __atomic_fetch_add(&i40e_dma_memzone_id, 1, __ATOMIC_RELAXED));
+ rte_atomic_fetch_add_explicit(&i40e_dma_memzone_id, 1,
rte_memory_order_relaxed));
mz = rte_memzone_reserve_bounded(z_name, size, SOCKET_ID_ANY,
RTE_MEMZONE_IOVA_CONTIG, alignment, RTE_PGSIZE_2M);
if (!mz)
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 5d25ab4..155f243 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -486,7 +486,7 @@
}
/* This barrier is to order loads of different words in the
descriptor */
- rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
+ rte_atomic_thread_fence(rte_memory_order_acquire);
/* Compute how many status bits were set */
for (j = 0, nb_dd = 0; j < I40E_LOOK_AHEAD; j++) {
@@ -745,7 +745,7 @@
* Use acquire fence to ensure that qword1 which includes DD
* bit is loaded before loading of other descriptor words.
*/
- rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
+ rte_atomic_thread_fence(rte_memory_order_acquire);
rxd = *rxdp;
nb_hold++;
@@ -867,7 +867,7 @@
* Use acquire fence to ensure that qword1 which includes DD
* bit is loaded before loading of other descriptor words.
*/
- rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
+ rte_atomic_thread_fence(rte_memory_order_acquire);
rxd = *rxdp;
nb_hold++;
diff --git a/drivers/net/i40e/i40e_rxtx_vec_neon.c
b/drivers/net/i40e/i40e_rxtx_vec_neon.c
index d873e30..3a99137 100644
--- a/drivers/net/i40e/i40e_rxtx_vec_neon.c
+++ b/drivers/net/i40e/i40e_rxtx_vec_neon.c
@@ -425,7 +425,7 @@
descs[0] = vld1q_u64((uint64_t *)(rxdp));
/* Use acquire fence to order loads of descriptor qwords */
- rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
+ rte_atomic_thread_fence(rte_memory_order_acquire);
/* A.2 reload qword0 to make it ordered after qword1 load */
descs[3] = vld1q_lane_u64((uint64_t *)(rxdp + 3), descs[3], 0);
descs[2] = vld1q_lane_u64((uint64_t *)(rxdp + 2), descs[2], 0);
--
1.8.3.1
[PATCH v2 07/45] net/bnxt: use rte stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with
corresponding rte_atomic_xxx optional rte stdatomic API.
Signed-off-by: Tyler Retzlaff
---
drivers/net/bnxt/bnxt_cpr.h | 4 ++--
drivers/net/bnxt/bnxt_rxq.h | 2 +-
drivers/net/bnxt/bnxt_rxr.c | 13 -
drivers/net/bnxt/bnxt_rxtx_vec_neon.c | 2 +-
drivers/net/bnxt/bnxt_stats.c | 4 ++--
5 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_cpr.h b/drivers/net/bnxt/bnxt_cpr.h
index c7b3480..43f06fd 100644
--- a/drivers/net/bnxt/bnxt_cpr.h
+++ b/drivers/net/bnxt/bnxt_cpr.h
@@ -107,7 +107,7 @@ struct bnxt_cp_ring_info {
/**
* Check validity of a completion ring entry. If the entry is valid, include a
- * C11 __ATOMIC_ACQUIRE fence to ensure that subsequent loads of fields in the
+ * C11 rte_memory_order_acquire fence to ensure that subsequent loads of
fields in the
* completion are not hoisted by the compiler or by the CPU to come before the
* loading of the "valid" field.
*
@@ -130,7 +130,7 @@ struct bnxt_cp_ring_info {
expected = !(raw_cons & ring_size);
valid = !!(rte_le_to_cpu_32(c->info3_v) & CMPL_BASE_V);
if (valid == expected) {
- rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
+ rte_atomic_thread_fence(rte_memory_order_acquire);
return true;
}
return false;
diff --git a/drivers/net/bnxt/bnxt_rxq.h b/drivers/net/bnxt/bnxt_rxq.h
index 77bc382..36e0ac3 100644
--- a/drivers/net/bnxt/bnxt_rxq.h
+++ b/drivers/net/bnxt/bnxt_rxq.h
@@ -40,7 +40,7 @@ struct bnxt_rx_queue {
struct bnxt_rx_ring_info*rx_ring;
struct bnxt_cp_ring_info*cp_ring;
struct rte_mbuf fake_mbuf;
- uint64_trx_mbuf_alloc_fail;
+ RTE_ATOMIC(uint64_t)rx_mbuf_alloc_fail;
uint8_t need_realloc;
const struct rte_memzone *mz;
};
diff --git a/drivers/net/bnxt/bnxt_rxr.c b/drivers/net/bnxt/bnxt_rxr.c
index 3542975..ca5d2c6 100644
--- a/drivers/net/bnxt/bnxt_rxr.c
+++ b/drivers/net/bnxt/bnxt_rxr.c
@@ -49,7 +49,8 @@ static inline int bnxt_alloc_rx_data(struct bnxt_rx_queue
*rxq,
rx_buf = &rxr->rx_buf_ring[prod];
mbuf = __bnxt_alloc_rx_data(rxq->mb_pool);
if (!mbuf) {
- __atomic_fetch_add(&rxq->rx_mbuf_alloc_fail, 1,
__ATOMIC_RELAXED);
+ rte_atomic_fetch_add_explicit(&rxq->rx_mbuf_alloc_fail, 1,
+ rte_memory_order_relaxed);
/* If buff has failed already, setting this again won't hurt */
rxq->need_realloc = 1;
return -ENOMEM;
@@ -86,7 +87,8 @@ static inline int bnxt_alloc_ag_data(struct bnxt_rx_queue
*rxq,
mbuf = __bnxt_alloc_rx_data(rxq->mb_pool);
if (!mbuf) {
- __atomic_fetch_add(&rxq->rx_mbuf_alloc_fail, 1,
__ATOMIC_RELAXED);
+ rte_atomic_fetch_add_explicit(&rxq->rx_mbuf_alloc_fail, 1,
+ rte_memory_order_relaxed);
/* If buff has failed already, setting this again won't hurt */
rxq->need_realloc = 1;
return -ENOMEM;
@@ -465,7 +467,8 @@ static inline struct rte_mbuf *bnxt_tpa_end(
struct rte_mbuf *new_data = __bnxt_alloc_rx_data(rxq->mb_pool);
RTE_ASSERT(new_data != NULL);
if (!new_data) {
- __atomic_fetch_add(&rxq->rx_mbuf_alloc_fail, 1,
__ATOMIC_RELAXED);
+ rte_atomic_fetch_add_explicit(&rxq->rx_mbuf_alloc_fail, 1,
+ rte_memory_order_relaxed);
return NULL;
}
tpa_info->mbuf = new_data;
@@ -1677,8 +1680,8 @@ int bnxt_init_one_rx_ring(struct bnxt_rx_queue *rxq)
rxr->tpa_info[i].mbuf =
__bnxt_alloc_rx_data(rxq->mb_pool);
if (!rxr->tpa_info[i].mbuf) {
-
__atomic_fetch_add(&rxq->rx_mbuf_alloc_fail, 1,
- __ATOMIC_RELAXED);
+
rte_atomic_fetch_add_explicit(&rxq->rx_mbuf_alloc_fail, 1,
+
rte_memory_order_relaxed);
return -ENOMEM;
}
}
diff --git a/drivers/net/bnxt/bnxt_rxtx_vec_neon.c
b/drivers/net/bnxt/bnxt_rxtx_vec_neon.c
index 775400f..04864e0 100644
--- a/drivers/net/bnxt/bnxt_rxtx_vec_neon.c
+++ b/drivers/net/bnxt/bnxt_rxtx_vec_neon.c
@@ -240,7 +240,7 @@
rxcmp1[0] = vld1q_u32((void *)&cpr->cp_desc_ring[cons + 1]);
/* Use acquire fence to order loads of descriptor words. */
- rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
+ rte_atomic_thread_fence(rte_memory_order_acquire);
/* Reload lower 64b of d
[PATCH v2 08/45] net/cpfl: use rte stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with
corresponding rte_atomic_xxx optional rte stdatomic API.
Signed-off-by: Tyler Retzlaff
---
drivers/net/cpfl/cpfl_ethdev.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/cpfl/cpfl_ethdev.c b/drivers/net/cpfl/cpfl_ethdev.c
index ef19aa1..5b47e22 100644
--- a/drivers/net/cpfl/cpfl_ethdev.c
+++ b/drivers/net/cpfl/cpfl_ethdev.c
@@ -300,8 +300,9 @@ struct rte_cpfl_xstats_name_off {
for (i = 0; i < dev->data->nb_rx_queues; i++) {
cpfl_rxq = dev->data->rx_queues[i];
- mbuf_alloc_failed +=
__atomic_load_n(&cpfl_rxq->base.rx_stats.mbuf_alloc_failed,
-__ATOMIC_RELAXED);
+ mbuf_alloc_failed +=
+
rte_atomic_load_explicit(&cpfl_rxq->base.rx_stats.mbuf_alloc_failed,
+ rte_memory_order_relaxed);
}
return mbuf_alloc_failed;
@@ -349,7 +350,8 @@ struct rte_cpfl_xstats_name_off {
for (i = 0; i < dev->data->nb_rx_queues; i++) {
cpfl_rxq = dev->data->rx_queues[i];
- __atomic_store_n(&cpfl_rxq->base.rx_stats.mbuf_alloc_failed, 0,
__ATOMIC_RELAXED);
+
rte_atomic_store_explicit(&cpfl_rxq->base.rx_stats.mbuf_alloc_failed, 0,
+ rte_memory_order_relaxed);
}
}
--
1.8.3.1
[PATCH v2 09/45] net/af_xdp: use rte stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with
corresponding rte_atomic_xxx optional rte stdatomic API.
Signed-off-by: Tyler Retzlaff
---
drivers/net/af_xdp/rte_eth_af_xdp.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
b/drivers/net/af_xdp/rte_eth_af_xdp.c
index 268a130..4833180 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -116,7 +116,7 @@ struct xsk_umem_info {
const struct rte_memzone *mz;
struct rte_mempool *mb_pool;
void *buffer;
- uint8_t refcnt;
+ RTE_ATOMIC(uint8_t) refcnt;
uint32_t max_xsks;
};
@@ -995,7 +995,8 @@ static int link_xdp_prog_with_dev(int ifindex, int fd,
__u32 flags)
break;
xsk_socket__delete(rxq->xsk);
- if (__atomic_fetch_sub(&rxq->umem->refcnt, 1, __ATOMIC_ACQUIRE)
- 1 == 0)
+ if (rte_atomic_fetch_sub_explicit(&rxq->umem->refcnt, 1,
+ rte_memory_order_acquire) - 1 == 0)
xdp_umem_destroy(rxq->umem);
/* free pkt_tx_queue */
@@ -1097,8 +1098,8 @@ static inline uintptr_t get_base_addr(struct rte_mempool
*mp, uint64_t *align)
ret = -1;
goto out;
}
- if
(__atomic_load_n(&internals->rx_queues[i].umem->refcnt,
- __ATOMIC_ACQUIRE)) {
+ if
(rte_atomic_load_explicit(&internals->rx_queues[i].umem->refcnt,
+ rte_memory_order_acquire)) {
*umem = internals->rx_queues[i].umem;
goto out;
}
@@ -1131,11 +1132,11 @@ xsk_umem_info *xdp_umem_configure(struct pmd_internals
*internals,
return NULL;
if (umem != NULL &&
- __atomic_load_n(&umem->refcnt, __ATOMIC_ACQUIRE) <
+ rte_atomic_load_explicit(&umem->refcnt,
rte_memory_order_acquire) <
umem->max_xsks) {
AF_XDP_LOG(INFO, "%s,qid%i sharing UMEM\n",
internals->if_name, rxq->xsk_queue_idx);
- __atomic_fetch_add(&umem->refcnt, 1, __ATOMIC_ACQUIRE);
+ rte_atomic_fetch_add_explicit(&umem->refcnt, 1,
rte_memory_order_acquire);
}
}
@@ -1177,7 +1178,7 @@ xsk_umem_info *xdp_umem_configure(struct pmd_internals
*internals,
mb_pool->name, umem->max_xsks);
}
- __atomic_store_n(&umem->refcnt, 1, __ATOMIC_RELEASE);
+ rte_atomic_store_explicit(&umem->refcnt, 1,
rte_memory_order_release);
}
return umem;
@@ -1606,7 +1607,8 @@ struct msg_internal {
if (rxq->umem == NULL)
return -ENOMEM;
txq->umem = rxq->umem;
- reserve_before = __atomic_load_n(&rxq->umem->refcnt, __ATOMIC_ACQUIRE)
<= 1;
+ reserve_before = rte_atomic_load_explicit(&rxq->umem->refcnt,
+ rte_memory_order_acquire) <= 1;
#if defined(XDP_UMEM_UNALIGNED_CHUNK_FLAG)
ret = rte_pktmbuf_alloc_bulk(rxq->umem->mb_pool, fq_bufs, reserve_size);
@@ -1723,7 +1725,7 @@ struct msg_internal {
out_xsk:
xsk_socket__delete(rxq->xsk);
out_umem:
- if (__atomic_fetch_sub(&rxq->umem->refcnt, 1, __ATOMIC_ACQUIRE) - 1 ==
0)
+ if (rte_atomic_fetch_sub_explicit(&rxq->umem->refcnt, 1,
rte_memory_order_acquire) - 1 == 0)
xdp_umem_destroy(rxq->umem);
return ret;
--
1.8.3.1
[PATCH v2 10/45] net/octeon_ep: use rte stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with
corresponding rte_atomic_xxx optional rte stdatomic API.
Signed-off-by: Tyler Retzlaff
---
drivers/net/octeon_ep/cnxk_ep_rx.h| 5 +++--
drivers/net/octeon_ep/cnxk_ep_tx.c| 5 +++--
drivers/net/octeon_ep/cnxk_ep_vf.c| 8
drivers/net/octeon_ep/otx2_ep_vf.c| 8
drivers/net/octeon_ep/otx_ep_common.h | 4 ++--
drivers/net/octeon_ep/otx_ep_rxtx.c | 6 --
6 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/net/octeon_ep/cnxk_ep_rx.h
b/drivers/net/octeon_ep/cnxk_ep_rx.h
index ecf95cd..9422042 100644
--- a/drivers/net/octeon_ep/cnxk_ep_rx.h
+++ b/drivers/net/octeon_ep/cnxk_ep_rx.h
@@ -98,7 +98,7 @@
* This adds an extra local variable, but almost halves the
* number of PCIe writes.
*/
- val = __atomic_load_n(droq->pkts_sent_ism, __ATOMIC_RELAXED);
+ val = rte_atomic_load_explicit(droq->pkts_sent_ism,
rte_memory_order_relaxed);
new_pkts = val - droq->pkts_sent_prev;
droq->pkts_sent_prev = val;
@@ -111,7 +111,8 @@
rte_mb();
rte_write64(OTX2_SDP_REQUEST_ISM, droq->pkts_sent_reg);
- while (__atomic_load_n(droq->pkts_sent_ism, __ATOMIC_RELAXED)
>= val) {
+ while (rte_atomic_load_explicit(droq->pkts_sent_ism,
+ rte_memory_order_relaxed) >= val) {
rte_write64(OTX2_SDP_REQUEST_ISM, droq->pkts_sent_reg);
rte_mb();
}
diff --git a/drivers/net/octeon_ep/cnxk_ep_tx.c
b/drivers/net/octeon_ep/cnxk_ep_tx.c
index 233c8aa..e093140 100644
--- a/drivers/net/octeon_ep/cnxk_ep_tx.c
+++ b/drivers/net/octeon_ep/cnxk_ep_tx.c
@@ -15,7 +15,7 @@
* This adds an extra local variable, but almost halves the
* number of PCIe writes.
*/
- val = __atomic_load_n(iq->inst_cnt_ism, __ATOMIC_RELAXED);
+ val = rte_atomic_load_explicit(iq->inst_cnt_ism,
rte_memory_order_relaxed);
iq->inst_cnt += val - iq->inst_cnt_prev;
iq->inst_cnt_prev = val;
@@ -27,7 +27,8 @@
rte_mb();
rte_write64(OTX2_SDP_REQUEST_ISM, iq->inst_cnt_reg);
- while (__atomic_load_n(iq->inst_cnt_ism, __ATOMIC_RELAXED) >=
val) {
+ while (rte_atomic_load_explicit(iq->inst_cnt_ism,
+ rte_memory_order_relaxed) >= val) {
rte_write64(OTX2_SDP_REQUEST_ISM, iq->inst_cnt_reg);
rte_mb();
}
diff --git a/drivers/net/octeon_ep/cnxk_ep_vf.c
b/drivers/net/octeon_ep/cnxk_ep_vf.c
index 39f357e..39b28de 100644
--- a/drivers/net/octeon_ep/cnxk_ep_vf.c
+++ b/drivers/net/octeon_ep/cnxk_ep_vf.c
@@ -150,10 +150,10 @@
rte_write64(ism_addr, (uint8_t *)otx_ep->hw_addr +
CNXK_EP_R_IN_CNTS_ISM(iq_no));
iq->inst_cnt_ism =
- (uint32_t *)((uint8_t *)otx_ep->ism_buffer_mz->addr
+ (uint32_t __rte_atomic *)((uint8_t *)otx_ep->ism_buffer_mz->addr
+ CNXK_EP_IQ_ISM_OFFSET(iq_no));
otx_ep_err("SDP_R[%d] INST Q ISM virt: %p, dma: 0x%" PRIX64, iq_no,
- (void *)iq->inst_cnt_ism, ism_addr);
+ (void *)(uintptr_t)iq->inst_cnt_ism, ism_addr);
*iq->inst_cnt_ism = 0;
iq->inst_cnt_prev = 0;
iq->partial_ih = ((uint64_t)otx_ep->pkind) << 36;
@@ -235,10 +235,10 @@
rte_write64(ism_addr, (uint8_t *)otx_ep->hw_addr +
CNXK_EP_R_OUT_CNTS_ISM(oq_no));
droq->pkts_sent_ism =
- (uint32_t *)((uint8_t *)otx_ep->ism_buffer_mz->addr
+ (uint32_t __rte_atomic *)((uint8_t *)otx_ep->ism_buffer_mz->addr
+ CNXK_EP_OQ_ISM_OFFSET(oq_no));
otx_ep_err("SDP_R[%d] OQ ISM virt: %p dma: 0x%" PRIX64,
- oq_no, (void *)droq->pkts_sent_ism, ism_addr);
+ oq_no, (void *)(uintptr_t)droq->pkts_sent_ism, ism_addr);
*droq->pkts_sent_ism = 0;
droq->pkts_sent_prev = 0;
diff --git a/drivers/net/octeon_ep/otx2_ep_vf.c
b/drivers/net/octeon_ep/otx2_ep_vf.c
index 25e0e5a..2aeebb4 100644
--- a/drivers/net/octeon_ep/otx2_ep_vf.c
+++ b/drivers/net/octeon_ep/otx2_ep_vf.c
@@ -300,10 +300,10 @@ static int otx2_vf_enable_rxq_intr(struct otx_ep_device
*otx_epvf,
oct_ep_write64(ism_addr, (uint8_t *)otx_ep->hw_addr +
SDP_VF_R_IN_CNTS_ISM(iq_no));
iq->inst_cnt_ism =
- (uint32_t *)((uint8_t *)otx_ep->ism_buffer_mz->addr
+ (uint32_t __rte_atomic *)((uint8_t *)otx_ep->ism_buffer_mz->addr
+ OTX2_EP_IQ_ISM_OFFSET(iq_no));
otx_ep_err("SDP_R[%d] INST Q ISM virt: %p, dma: 0x%x", iq_no,
- (void *)iq->inst_cnt_ism,
+ (void *)(uintptr_t)iq->inst_cnt_ism,
(unsigned int)ism_addr);
*iq->inst_cnt_ism = 0;
iq->
[PATCH v2 11/45] net/octeontx: use rte stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with
corresponding rte_atomic_xxx optional rte stdatomic API.
Signed-off-by: Tyler Retzlaff
---
drivers/net/octeontx/octeontx_ethdev.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/octeontx/octeontx_ethdev.c
b/drivers/net/octeontx/octeontx_ethdev.c
index bec54fd..64d1666 100644
--- a/drivers/net/octeontx/octeontx_ethdev.c
+++ b/drivers/net/octeontx/octeontx_ethdev.c
@@ -31,7 +31,7 @@
/* Useful in stopping/closing event device if no of
* eth ports are using it.
*/
-uint16_t evdev_refcnt;
+RTE_ATOMIC(uint16_t) evdev_refcnt;
#define OCTEONTX_QLM_MODE_SGMII 7
#define OCTEONTX_QLM_MODE_XFI 12
@@ -559,7 +559,7 @@ enum octeontx_link_speed {
return 0;
/* Stopping/closing event device once all eth ports are closed. */
- if (__atomic_fetch_sub(&evdev_refcnt, 1, __ATOMIC_ACQUIRE) - 1 == 0) {
+ if (rte_atomic_fetch_sub_explicit(&evdev_refcnt, 1,
rte_memory_order_acquire) - 1 == 0) {
rte_event_dev_stop(nic->evdev);
rte_event_dev_close(nic->evdev);
}
@@ -1593,7 +1593,7 @@ static void build_xstat_names(struct rte_eth_xstat_name
*xstat_names)
nic->pko_vfid = pko_vfid;
nic->port_id = port;
nic->evdev = evdev;
- __atomic_fetch_add(&evdev_refcnt, 1, __ATOMIC_ACQUIRE);
+ rte_atomic_fetch_add_explicit(&evdev_refcnt, 1,
rte_memory_order_acquire);
res = octeontx_port_open(nic);
if (res < 0)
@@ -1844,7 +1844,7 @@ static void build_xstat_names(struct rte_eth_xstat_name
*xstat_names)
}
}
- __atomic_store_n(&evdev_refcnt, 0, __ATOMIC_RELEASE);
+ rte_atomic_store_explicit(&evdev_refcnt, 0, rte_memory_order_release);
/*
* Do 1:1 links for ports & queues. All queues would be mapped to
* one port. If there are more ports than queues, then some ports
--
1.8.3.1
