dev@dpdk.org
https://bugs.dpdk.org/show_bug.cgi?id=744 gaodaxue (daxuex@intel.com) changed: What|Removed |Added Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #14 from gaodaxue (daxuex@intel.com) --- Verified based on c511bb7787 PASSED. OS: Fedora 13.0.0~rc1-1.fc35/Ubuntu21/5.13.0-19-generic Compiler: Fedora (13.0.0~rc1-1.fc35/gcc 11.2.1)/(Ubuntu21/5.13.0-19-generic gcc 11.2.0) -- You are receiving this mail because: You are the assignee for the bug.
[PATCH v3] app/testpmd: fix issue with memory leaks when quit testpmd
A multicast address pool is allocated for a port when
using mcast_addr testpmd commands.
When closing a port or stopping testpmd, this pool was
not freed, resulting in a leak.This issue has been caught
using ASan.
Free this pool when closing the port.
Error info as following:
ERROR: LeakSanitizer: detected memory leaksDirect leak of
192 byte(s)
0 0x7f6a2e0aeffe in __interceptor_realloc
(/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
1 0x565361eb340f in mcast_addr_pool_extend
../app/test-pmd/config.c:5162
2 0x565361eb3556 in mcast_addr_pool_append
../app/test-pmd/config.c:5180
3 0x565361eb3aae in mcast_addr_add
../app/test-pmd/config.c:5243
Signed-off-by: Ke Zhang
---
app/test-pmd/config.c | 19 +++
app/test-pmd/testpmd.c | 1 +
app/test-pmd/testpmd.h | 1 +
3 files changed, 21 insertions(+)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index cc8e7aa138..a6fa9be3ef 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -5978,6 +5978,25 @@ mcast_addr_pool_remove(struct rte_port *port, uint32_t
addr_idx)
sizeof(struct rte_ether_addr) * (port->mc_addr_nb - addr_idx));
}
+int
+mcast_addr_pool_destroy(portid_t port_id)
+{
+ struct rte_port *port;
+
+ if (port_id_is_invalid(port_id, ENABLED_WARN) ||
+ port_id == (portid_t)RTE_PORT_ALL)
+ return -EINVAL;
+ port = &ports[port_id];
+
+ if (port->mc_addr_nb != 0) {
+ /* free the pool of multicast addresses. */
+ free(port->mc_addr_pool);
+ port->mc_addr_pool = NULL;
+ port->mc_addr_nb = 0;
+ }
+ return 0;
+}
+
static int
eth_port_multicast_addr_list_set(portid_t port_id)
{
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index fe2ce19f99..1861a02c2f 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -3137,6 +3137,7 @@ close_port(portid_t pid)
}
if (is_proc_primary()) {
+ mcast_addr_pool_destroy(pi);
port_flow_flush(pi);
port_flex_item_flush(pi);
rte_eth_dev_close(pi);
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 31f766c965..daa3c08317 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -965,6 +965,7 @@ int port_flow_create(portid_t port_id,
int port_action_handle_query(portid_t port_id, uint32_t id);
void update_age_action_context(const struct rte_flow_action *actions,
struct port_flow *pf);
+int mcast_addr_pool_destroy(portid_t port_id);
int port_flow_destroy(portid_t port_id, uint32_t n, const uint32_t *rule);
int port_flow_flush(portid_t port_id);
int port_flow_dump(portid_t port_id, bool dump_all,
--
2.25.1
[PATCH v3] app/testpmd: fix issue with memory leaks when quit testpmd
A multicast address pool is allocated for a port when
using mcast_addr testpmd commands.
When closing a port or stopping testpmd, this pool was
not freed, resulting in a leak.This issue has been caught
using ASan.
Free this pool when closing the port.
Error info as following:
ERROR: LeakSanitizer: detected memory leaksDirect leak of
192 byte(s)
0 0x7f6a2e0aeffe in __interceptor_realloc
(/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
1 0x565361eb340f in mcast_addr_pool_extend
../app/test-pmd/config.c:5162
2 0x565361eb3556 in mcast_addr_pool_append
../app/test-pmd/config.c:5180
3 0x565361eb3aae in mcast_addr_add
../app/test-pmd/config.c:5243
Signed-off-by: Ke Zhang
---
app/test-pmd/config.c | 19 +++
app/test-pmd/testpmd.c | 1 +
app/test-pmd/testpmd.h | 1 +
3 files changed, 21 insertions(+)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index cc8e7aa138..a6fa9be3ef 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -5978,6 +5978,25 @@ mcast_addr_pool_remove(struct rte_port *port, uint32_t
addr_idx)
sizeof(struct rte_ether_addr) * (port->mc_addr_nb - addr_idx));
}
+int
+mcast_addr_pool_destroy(portid_t port_id)
+{
+ struct rte_port *port;
+
+ if (port_id_is_invalid(port_id, ENABLED_WARN) ||
+ port_id == (portid_t)RTE_PORT_ALL)
+ return -EINVAL;
+ port = &ports[port_id];
+
+ if (port->mc_addr_nb != 0) {
+ /* free the pool of multicast addresses. */
+ free(port->mc_addr_pool);
+ port->mc_addr_pool = NULL;
+ port->mc_addr_nb = 0;
+ }
+ return 0;
+}
+
static int
eth_port_multicast_addr_list_set(portid_t port_id)
{
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index fe2ce19f99..1861a02c2f 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -3137,6 +3137,7 @@ close_port(portid_t pid)
}
if (is_proc_primary()) {
+ mcast_addr_pool_destroy(pi);
port_flow_flush(pi);
port_flex_item_flush(pi);
rte_eth_dev_close(pi);
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 31f766c965..daa3c08317 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -965,6 +965,7 @@ int port_flow_create(portid_t port_id,
int port_action_handle_query(portid_t port_id, uint32_t id);
void update_age_action_context(const struct rte_flow_action *actions,
struct port_flow *pf);
+int mcast_addr_pool_destroy(portid_t port_id);
int port_flow_destroy(portid_t port_id, uint32_t n, const uint32_t *rule);
int port_flow_flush(portid_t port_id);
int port_flow_dump(portid_t port_id, bool dump_all,
--
2.25.1
[Bug 981] vhost: avoid sleeping under mutex
https://bugs.dpdk.org/show_bug.cgi?id=981
Bug ID: 981
Summary: vhost: avoid sleeping under mutex
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: vhost/virtio
Assignee: dev@dpdk.org
Reporter: david.march...@redhat.com
Target Milestone: ---
Reported by covscan:
2. dpdk-21.11/lib/vhost/socket.c:852: lock_acquire: Calling function
"pthread_mutex_lock" acquires lock "vhost_user.mutex".
23. dpdk-21.11/lib/vhost/socket.c:955: sleep: Call to
"vhost_user_reconnect_init" might sleep while holding lock "vhost_user.mutex".
# 953|vsocket->reconnect = !(flags &
RTE_VHOST_USER_NO_RECONNECT);
# 954|if (vsocket->reconnect && reconn_tid == 0) {
# 955|-> if (vhost_user_reconnect_init() != 0)
# 956|goto out_mutex;
# 957|}
The reason for this warning is that creating a ctrl thread might end up with
sleep() calls.
Maybe creating the ctrl thread could be moved early (out of the mutex).
Plus, comparing (pthread_t) reconn_tid against 0 is ugly.
Fixing this bz would be a good time to clean this too.
--
You are receiving this mail because:
You are the assignee for the bug.
RE: [PATCH v1] dmadev: add telemetry support
> -Original Message-
> From: Sean Morrissey
> Sent: Wednesday, March 23, 2022 10:19 PM
> To: Chengwen Feng ; Laatz, Kevin
> ; Richardson, Bruce
> Cc: dev@dpdk.org; Morrissey, Sean
> Subject: [PATCH v1] dmadev: add telemetry support
>
> Telemetry commands are now registered through the dmadev library for the
> gathering of DSA stats. The corresponding callback functions for listing
> dmadevs and providing info and stats for a specific dmadev are implemented
> in the dmadev library.
>
> An example usage can be seen below:
>
> Connecting to /var/run/dpdk/rte/dpdk_telemetry.v2
> {"version": "DPDK 22.03.0-rc2", "pid": 2956551, "max_output_len": 16384}
> Connected to application: "dpdk-dma"
> --> /
> {"/": ["/", "/dmadev/info", "/dmadev/list", "/dmadev/stats", ...]}
> --> /dmadev/list
> {"/dmadev/list": [0, 1]}
> --> /dmadev/info,0
> {"/dmadev/info": {"name": ":00:01.0", "nb_vchans": 1, "numa_node": 0}}
> --> /dmadev/stats,0,0
> {"/dmadev/stats": {"submitted": 0, "completed": 0, "errors": 0}}
>
> Signed-off-by: Sean Morrissey
> ---
> doc/guides/prog_guide/dmadev.rst | 24 ++
> doc/guides/rel_notes/release_22_07.rst | 4 +
> lib/dmadev/meson.build | 2 +
> lib/dmadev/rte_dmadev.c| 105 +
> 4 files changed, 135 insertions(+)
>
Thanks for adding the telemetry support.
Tested-by: Sunil Pai G
Regards,
Sunil
RE: [PATCH] eventdev: fix telemetry Rx adapters stats reset
Looks good, thanks for posting this change.
Acked-by: Jay Jayatheerthan
-Jay
> -Original Message-
> From: David Marchand
> Sent: Thursday, March 24, 2022 8:59 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Jayatheerthan, Jay ; Jerin
> Jacob ; Naga Harish K, S V
> ; Kundapura, Ganapati
>
> Subject: [PATCH] eventdev: fix telemetry Rx adapters stats reset
>
> Caught by covscan:
>
> 1. dpdk-21.11/lib/eventdev/rte_event_eth_rx_adapter.c:3279:
> logical_vs_bitwise: "~(*__ctype_b_loc()[(int)*params] & 2048 /*
> (unsigned short)_ISdigit */)" is always 1/true regardless of the values
> of its operand. This occurs as the logical second operand of "||".
> 2. dpdk-21.11/lib/eventdev/rte_event_eth_rx_adapter.c:3279: remediation:
> Did you intend to use "!" rather than "~"?
>
> While isdigit return value should be compared as an int to 0,
> prefer ! since all of this file uses this convention.
>
> Fixes: 814d01709328 ("eventdev/eth_rx: support telemetry")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
> ---
> lib/eventdev/rte_event_eth_rx_adapter.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
> b/lib/eventdev/rte_event_eth_rx_adapter.c
> index ff83ce8b67..bf8741d2ea 100644
> --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> @@ -3334,7 +3334,7 @@ handle_rxa_stats_reset(const char *cmd __rte_unused,
> {
> uint8_t rx_adapter_id;
>
> - if (params == NULL || strlen(params) == 0 || ~isdigit(*params))
> + if (params == NULL || strlen(params) == 0 || !isdigit(*params))
> return -1;
>
> /* Get Rx adapter ID from parameter string */
> --
> 2.23.0
[PATCH v4] net/ixgbe: retry SFP ID read to handle misbehaving SFPs
From: Stephen Douthit
Some XGS-PON SFPs have been observed ACKing I2C reads and returning
uninitialized garbage while their uC boots. This can lead to the SFP ID
code marking an otherwise working SFP module as unsupported if a bogus
ID value is read while its internal PHY/microcontroller is still
booting.
Retry the ID read several times looking not just for NAK, but also for a
valid ID field.
Since the device isn't NAKing the trasanction the existing longer retry
code in ixgbe_read_i2c_byte_generic_int() doesn't apply here.
Signed-off-by: Stephen Douthit
Signed-off-by: Jeff Daly
---
Notes:
v4:
* Fixed git summary
v3:
* Removed extra braces around single statement if
v2:
* Removed superfluous DEBUGOUT
* Renamed id_reads to retries
* Don't assume status == 0 means IXGBE_SUCCESS
drivers/net/ixgbe/base/ixgbe_phy.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ixgbe/base/ixgbe_phy.c
b/drivers/net/ixgbe/base/ixgbe_phy.c
index 8d4d9bbfef..74c5db16fa 100644
--- a/drivers/net/ixgbe/base/ixgbe_phy.c
+++ b/drivers/net/ixgbe/base/ixgbe_phy.c
@@ -1267,6 +1267,7 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw)
u8 cable_tech = 0;
u8 cable_spec = 0;
u16 enforce_sfp = 0;
+ u8 retries;
DEBUGFUNC("ixgbe_identify_sfp_module_generic");
@@ -1279,9 +1280,29 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw
*hw)
/* LAN ID is needed for I2C access */
hw->mac.ops.set_lan_id(hw);
- status = hw->phy.ops.read_i2c_eeprom(hw,
-IXGBE_SFF_IDENTIFIER,
-&identifier);
+ /* Need to check this a couple of times for a sane value.
+*
+* SFPs that have a uC slaved to the I2C bus (vs. a dumb EEPROM) can be
+* poorly designed such that they will ACK I2C reads and return
+* whatever bogus data is in the SRAM (or whatever is backing the target
+* device) before things are truly initialized.
+*
+* In a perfect world devices would NAK I2C requests until they were
+* sane, but here we are.
+*
+* Give such devices a couple tries to get their act together before
+* marking the device as unsupported.
+*/
+ for (retries = 0; retries < 5; retries++) {
+ status = hw->phy.ops.read_i2c_eeprom(hw,
+IXGBE_SFF_IDENTIFIER,
+&identifier);
+
+ DEBUGOUT("status %d, SFF identifier 0x%x\n", status,
identifier);
+ if (status == IXGBE_SUCCESS &&
+ identifier == IXGBE_SFF_IDENTIFIER_SFP)
+ break;
+ }
if (status != IXGBE_SUCCESS)
goto err_read_i2c_eeprom;
--
2.25.1
[PATCH] event/cnxk: fix base pointer for SSO head wait
Function roc_sso_hws_head_wait() expects a base as input pointer, and it
will itself get tag_op from the base. By passing tag_op instead of base
pointer to this function will add SSOW_LF_GWS_TAG register offset twice,
which will lead to accessing wrong register.
Fixes: 1f5b3d55c041 ("event/cnxk: store and reuse workslot status")
Cc: sta...@dpdk.org
Signed-off-by: Volodymyr Fialko
---
drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 4 ++--
drivers/crypto/cnxk/cn10k_cryptodev_ops.h | 2 +-
drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 4 ++--
drivers/crypto/cnxk/cn9k_cryptodev_ops.h | 2 +-
drivers/event/cnxk/cn10k_worker.c | 3 +--
drivers/event/cnxk/cn9k_worker.c | 7 +++
6 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
b/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
index d217bbf383..1b08c67fea 100644
--- a/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
+++ b/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
@@ -265,7 +265,7 @@ cn10k_cpt_enqueue_burst(void *qptr, struct rte_crypto_op
**ops, uint16_t nb_ops)
}
uint16_t
-cn10k_cpt_crypto_adapter_enqueue(uintptr_t tag_op, struct rte_crypto_op *op)
+cn10k_cpt_crypto_adapter_enqueue(uintptr_t base, struct rte_crypto_op *op)
{
union rte_event_crypto_metadata *ec_mdata;
struct cpt_inflight_req *infl_req;
@@ -328,7 +328,7 @@ cn10k_cpt_crypto_adapter_enqueue(uintptr_t tag_op, struct
rte_crypto_op *op)
}
if (!rsp_info->sched_type)
- roc_sso_hws_head_wait(tag_op);
+ roc_sso_hws_head_wait(base);
lmt_arg = ROC_CN10K_CPT_LMT_ARG | (uint64_t)lmt_id;
roc_lmt_submit_steorl(lmt_arg, qp->lmtline.io_addr);
diff --git a/drivers/crypto/cnxk/cn10k_cryptodev_ops.h
b/drivers/crypto/cnxk/cn10k_cryptodev_ops.h
index d7e9f87396..1ad4c16873 100644
--- a/drivers/crypto/cnxk/cn10k_cryptodev_ops.h
+++ b/drivers/crypto/cnxk/cn10k_cryptodev_ops.h
@@ -13,7 +13,7 @@ extern struct rte_cryptodev_ops cn10k_cpt_ops;
void cn10k_cpt_set_enqdeq_fns(struct rte_cryptodev *dev);
__rte_internal
-uint16_t cn10k_cpt_crypto_adapter_enqueue(uintptr_t tag_op,
+uint16_t cn10k_cpt_crypto_adapter_enqueue(uintptr_t base,
struct rte_crypto_op *op);
__rte_internal
uintptr_t cn10k_cpt_crypto_adapter_dequeue(uintptr_t get_work1);
diff --git a/drivers/crypto/cnxk/cn9k_cryptodev_ops.c
b/drivers/crypto/cnxk/cn9k_cryptodev_ops.c
index ddba9d5dd0..d3858149c7 100644
--- a/drivers/crypto/cnxk/cn9k_cryptodev_ops.c
+++ b/drivers/crypto/cnxk/cn9k_cryptodev_ops.c
@@ -317,7 +317,7 @@ cn9k_cpt_enqueue_burst(void *qptr, struct rte_crypto_op
**ops, uint16_t nb_ops)
}
uint16_t
-cn9k_cpt_crypto_adapter_enqueue(uintptr_t tag_op, struct rte_crypto_op *op)
+cn9k_cpt_crypto_adapter_enqueue(uintptr_t base, struct rte_crypto_op *op)
{
union rte_event_crypto_metadata *ec_mdata;
struct cpt_inflight_req *infl_req;
@@ -374,7 +374,7 @@ cn9k_cpt_crypto_adapter_enqueue(uintptr_t tag_op, struct
rte_crypto_op *op)
}
if (!rsp_info->sched_type)
- roc_sso_hws_head_wait(tag_op);
+ roc_sso_hws_head_wait(base);
cn9k_cpt_inst_submit(&inst, qp->lmtline.lmt_base, qp->lmtline.io_addr);
diff --git a/drivers/crypto/cnxk/cn9k_cryptodev_ops.h
b/drivers/crypto/cnxk/cn9k_cryptodev_ops.h
index 309f507346..9f6dc24603 100644
--- a/drivers/crypto/cnxk/cn9k_cryptodev_ops.h
+++ b/drivers/crypto/cnxk/cn9k_cryptodev_ops.h
@@ -12,7 +12,7 @@ extern struct rte_cryptodev_ops cn9k_cpt_ops;
void cn9k_cpt_set_enqdeq_fns(struct rte_cryptodev *dev);
__rte_internal
-uint16_t cn9k_cpt_crypto_adapter_enqueue(uintptr_t tag_op,
+uint16_t cn9k_cpt_crypto_adapter_enqueue(uintptr_t base,
struct rte_crypto_op *op);
__rte_internal
uintptr_t cn9k_cpt_crypto_adapter_dequeue(uintptr_t get_work1);
diff --git a/drivers/event/cnxk/cn10k_worker.c
b/drivers/event/cnxk/cn10k_worker.c
index 975a22336a..1ffd48a5ab 100644
--- a/drivers/event/cnxk/cn10k_worker.c
+++ b/drivers/event/cnxk/cn10k_worker.c
@@ -68,6 +68,5 @@ cn10k_sso_hws_ca_enq(void *port, struct rte_event ev[],
uint16_t nb_events)
RTE_SET_USED(nb_events);
- return cn10k_cpt_crypto_adapter_enqueue(ws->base + SSOW_LF_GWS_TAG,
- ev->event_ptr);
+ return cn10k_cpt_crypto_adapter_enqueue(ws->base, ev->event_ptr);
}
diff --git a/drivers/event/cnxk/cn9k_worker.c b/drivers/event/cnxk/cn9k_worker.c
index a981bc986f..fca1f0dffa 100644
--- a/drivers/event/cnxk/cn9k_worker.c
+++ b/drivers/event/cnxk/cn9k_worker.c
@@ -128,8 +128,7 @@ cn9k_sso_hws_ca_enq(void *port, struct rte_event ev[],
uint16_t nb_events)
RTE_SET_USED(nb_events);
- return cn9k_cpt_crypto_adapter_enqueue(ws->base + SSOW_LF_GWS_TAG,
- ev->event_ptr);
+ return cn9k_cpt_crypto_adapter_enqueue(ws->base, ev->event_ptr);
}
[Bug 982] [dpdk-20.11.5-rc1] ieee1588/ieee1588_enable: ninja build failed with support RTE_LIBRTE_IEEE1588
https://bugs.dpdk.org/show_bug.cgi?id=982
Bug ID: 982
Summary: [dpdk-20.11.5-rc1] ieee1588/ieee1588_enable: ninja
build failed with support RTE_LIBRTE_IEEE1588
Product: DPDK
Version: 20.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: meson
Assignee: dev@dpdk.org
Reporter: linglix.c...@intel.com
Target Milestone: ---
dpdk-20.11.5-rc1: 576842a59ab35979dc102535f59061fa3d6ea16b
Reproduce Step:
1.CC=gcc meson -Denable_kmods=True -Dlibdir=lib -Dc_args=-DRTE_LIBRTE_IEEE1588
--default-library=static x86_64-native-linuxapp-gcc
2.ninja -C x86_64-native-linuxapp-gcc
Expect results: Build passed
Actual results: ninja: build stopped: subcommand failed.
ninja: Entering directory `x86_64-native-linuxapp-gcc'
[866/2458] Compiling C object
drivers/libtmp_rte_net_dpaa2.a.p/net_dpaa2_dpaa2_rxtx.c.o
FAILED: drivers/libtmp_rte_net_dpaa2.a.p/net_dpaa2_dpaa2_rxtx.c.o
gcc -Idrivers/libtmp_rte_net_dpaa2.a.p -Idrivers -I../drivers
-Idrivers/net/dpaa2 -I../drivers/net/dpaa2 -I../drivers/net/dpaa2/base
-I../drivers/net/dpaa2/mc -Ilib/librte_ethdev -I../lib/librte_ethdev -I. -I..
-Iconfig -I../config -Ilib/librte_eal/include -I../lib/librte_eal/include
-Ilib/librte_eal/linux/include -I../lib/librte_eal/linux/include
-Ilib/librte_eal/x86/include -I../lib/librte_eal/x86/include
-Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal
-I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs
-Ilib/librte_metrics -I../lib/librte_metrics -Ilib/librte_telemetry
-I../lib/librte_telemetry -Ilib/librte_net -I../lib/librte_net
-Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool
-I../lib/librte_mempool -Ilib/librte_ring -I../lib/librte_ring
-Ilib/librte_meter -I../lib/librte_meter -Idrivers/bus/pci -I../drivers/bus/pci
-I../drivers/bus/pci/linux -Ilib/librte_pci -I../lib/librte_pci
-Idrivers/bus/vdev -I../drivers/bus/vdev -Idrivers/mempool/dpaa2
-I../drivers/mempool/dpaa2 -Idrivers/bus/fslmc -I../drivers/bus/fslmc
-I../drivers/bus/fslmc/mc -I../drivers/bus/fslmc/qbman/include
-I../drivers/bus/fslmc/portal -Idrivers/common/dpaax -I../drivers/common/dpaax
-I../drivers/common/dpaax/caamflib -Ilib/librte_eventdev
-I../lib/librte_eventdev -Ilib/librte_hash -I../lib/librte_hash
-Ilib/librte_rcu -I../lib/librte_rcu -Ilib/librte_timer -I../lib/librte_timer
-Ilib/librte_cryptodev -I../lib/librte_cryptodev -fdiagnostics-color=always
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -include rte_config.h -Wextra
-Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes
-Wundef -Wwrite-strings -Wno-packed-not-aligned -Wno-missing-field-initializers
-D_GNU_SOURCE -fPIC -march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API
-Wno-format-truncation -MD -MQ
drivers/libtmp_rte_net_dpaa2.a.p/net_dpaa2_dpaa2_rxtx.c.o -MF
drivers/libtmp_rte_net_dpaa2.a.p/net_dpaa2_dpaa2_rxtx.c.o.d -o
drivers/libtmp_rte_net_dpaa2.a.p/net_dpaa2_dpaa2_rxtx.c.o -c
../drivers/net/dpaa2/dpaa2_rxtx.c
../drivers/net/dpaa2/dpaa2_rxtx.c: In function ‘dpaa2_dev_rx’:
../drivers/net/dpaa2/dpaa2_rxtx.c:863:4: error: ‘priv’ undeclared (first use in
this function); did you mean ‘ldiv’?
priv->rx_timestamp =
^~~~
ldiv
../drivers/net/dpaa2/dpaa2_rxtx.c:863:4: note: each undeclared identifier is
reported only once for each function it appears in
[963/2458] Compiling C object
lib/librte_pipeline.a.p/librte_pipeline_rte_table_action.c.o
ninja: build stopped: subcommand failed.
Is this issue a regression: Y
Version the regression was introduced: Specify git id if known.
First bad commit: 1d10966a22caf15f3b61e986becbeccdb2f03b33 (HEAD)
Author: Vanshika Shukla
Date: Mon Jan 3 15:31:19 2022 +0530
net/dpaa2: fix timestamping for IEEE1588
[ upstream commit 90762e5cb8154bb437618f81488ac92a24455521 ]
The current implementation of DPAA2 driver code is such
that it records Rx and Tx timestamp for PTP without checking
if they are PTP packets or not. Packets for which
RTE_MBUF_F_RX_IEEE1588_TMST and RTE_MBUF_F_TX_IEEE1588_TMST
is not set, Rx and Tx timestamp should not be recorded.
This patch fixes this issue by checking if the required
flags are set in the mbuf before recording timestamps.
Also this change defines separate values for
DPAA2_TX_CONF_ENABLE and DPAA2_NO_PREFETCH_RX
Fixes: e806bf878c17 ("net/dpaa2: support timestamp")
Signed-off-by: Vanshika Shukla
Acked-by: Hemant Agrawal
--
You are receiving this mail because:
You are the assignee for the bug.
[PATCH 0/2] Session crypto event metadata api
Implement API to set/get crypto event meta data per security session. Volodymyr Fialko (2): security: introduce per session event metadata crypto/cnxk: support for security session enqueue .../prog_guide/event_crypto_adapter.rst | 4 +- drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 5 +++ lib/security/rte_security.h | 43 +++ 3 files changed, 50 insertions(+), 2 deletions(-) -- 2.25.1
[PATCH 1/2] security: introduce per session event metadata
Implement API to set/get event data per security session.
Signed-off-by: Volodymyr Fialko
Acked-by: Akhil Goyal
Acked-by: Anoob Joseph
---
.../prog_guide/event_crypto_adapter.rst | 4 +-
lib/security/rte_security.h | 43 +++
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/doc/guides/prog_guide/event_crypto_adapter.rst
b/doc/guides/prog_guide/event_crypto_adapter.rst
index 4fb5c688e0..227b36b4b7 100644
--- a/doc/guides/prog_guide/event_crypto_adapter.rst
+++ b/doc/guides/prog_guide/event_crypto_adapter.rst
@@ -246,9 +246,9 @@ by ``rte_cryptodev_sym_session_get_user_data()`` API. The
RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA capability indicates
whether HW or SW supports this feature.
-For security session, ``rte_security_session_set_private_data()`` API
+For security session, ``rte_security_session_set_event_mdata()`` API
will be used to set request/response data. The same data will be obtained
-by ``rte_security_session_get_private_data()`` API.
+by ``rte_security_session_get_event_mdata()`` API.
For session-less it is mandatory to place the request/response data with
the ``rte_crypto_op``.
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index b080d10c2c..29ec514504 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -526,6 +526,8 @@ struct rte_security_session {
/**< Private session material */
uint64_t opaque_data;
/**< Opaque user defined data */
+ void *event_mdata;
+ /**< Event request/response information */
};
/**
@@ -729,6 +731,47 @@ set_sec_session_private_data(struct rte_security_session
*sess,
sess->sess_private_data = private_data;
}
+/**
+ * Get event meta data attached to a security session.
+ *
+ * @param sessSession pointer allocated by
+ * *rte_security_session_create*.
+ *
+ * @return
+ * - On success return pointer to the event crypto meta data which is set
+ *using *rte_security_session_set_event_mdata*
+ * - On failure returns NULL.
+ */
+__rte_experimental
+static inline void *
+rte_security_session_get_event_mdata(const struct rte_security_session *sess)
+{
+ return sess->event_mdata;
+}
+
+/**
+ * Attach event crypto meta data to a security session.
+ *
+ * Application can allocate memory for *rte_event_crypto_metadata* and set the
+ * reference pointer using this API which the PMD can retrieve using
+ * *rte_security_session_get_event_mdata*
+ *
+ * The API should be used only in case session is used for event crypto
+ * adapter.
+ *
+ * @param sessSession pointer allocated by
+ * *rte_security_session_create*.
+ * @param ev_mdataPointer to the event crypto meta data
+ * (aka *union rte_event_crypto_metadata*)
+ */
+__rte_experimental
+static inline void
+rte_security_session_set_event_mdata(struct rte_security_session *sess,
+void *ev_mdata)
+{
+ sess->event_mdata = ev_mdata;
+}
+
/**
* Attach a session to a crypto operation.
* This API is needed only in case of RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD
--
2.25.1
[PATCH 2/2] crypto/cnxk: support for security session enqueue
Add support for enqueue security session to event crypto adapter. Event metadata is used to store request/response information that is needed to enqueue an event after the crypto operation completed. Signed-off-by: Volodymyr Fialko --- drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/crypto/cnxk/cnxk_cryptodev_ops.h b/drivers/crypto/cnxk/cnxk_cryptodev_ops.h index 1c58254bef..857fe95e1c 100644 --- a/drivers/crypto/cnxk/cnxk_cryptodev_ops.h +++ b/drivers/crypto/cnxk/cnxk_cryptodev_ops.h @@ -7,6 +7,7 @@ #include #include +#include #include "roc_api.h" @@ -142,6 +143,10 @@ cnxk_event_crypto_mdata_get(struct rte_crypto_op *op) op->private_data_offset) ec_mdata = (union rte_event_crypto_metadata *)((uint8_t *)op + op->private_data_offset); + else if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION && +op->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC) + ec_mdata = rte_security_session_get_event_mdata( + op->sym->sec_session); else return NULL; -- 2.25.1
[dpdk-dev v1] crypto/qat: fix of cipher offset and length assignment
This patch fix the cipher offset and length values when convert
mbuf to vector chain for QAT build op.
Fixes: a815a04cea05 ("crypto/qat: support symmetric build op request")
Signed-off-by: Kai Ji
---
drivers/crypto/qat/dev/qat_crypto_pmd_gens.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
b/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
index 50a9c5ad5b..dc473e0624 100644
--- a/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
+++ b/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
@@ -395,12 +395,12 @@ qat_sym_convert_op_to_vec_chain(struct rte_crypto_op *op,
ret = qat_cipher_is_len_in_bits(ctx, op);
switch (ret) {
case 1:
- cipher_len = op->sym->aead.data.length >> 3;
- cipher_ofs = op->sym->aead.data.offset >> 3;
+ cipher_len = op->sym->cipher.data.length >> 3;
+ cipher_ofs = op->sym->cipher.data.offset >> 3;
break;
case 0:
- cipher_len = op->sym->aead.data.length;
- cipher_ofs = op->sym->aead.data.offset;
+ cipher_len = op->sym->cipher.data.length;
+ cipher_ofs = op->sym->cipher.data.offset;
break;
default:
QAT_DP_LOG(ERR,
@@ -426,7 +426,6 @@ qat_sym_convert_op_to_vec_chain(struct rte_crypto_op *op,
return -EINVAL;
}
- min_ofs = cipher_ofs < auth_ofs ? cipher_ofs : auth_ofs;
max_len = RTE_MAX(cipher_ofs + cipher_len, auth_ofs + auth_len);
/* digest in buffer check. Needed only for wireless algos */
@@ -463,7 +462,8 @@ qat_sym_convert_op_to_vec_chain(struct rte_crypto_op *op,
ctx->digest_length);
}
- n_src = rte_crypto_mbuf_to_vec(op->sym->m_src, min_ofs, max_len,
+ /* Passing 0 as cipher & auth offsets are assigned into ofs later */
+ n_src = rte_crypto_mbuf_to_vec(op->sym->m_src, 0, max_len,
in_sgl->vec, QAT_SYM_SGL_MAX_NUMBER);
if (unlikely(n_src < 0 || n_src > op->sym->m_src->nb_segs)) {
op->status = RTE_CRYPTO_OP_STATUS_ERROR;
--
2.17.1
[PATCH] examples/ipsec-secgw: fix uninitialized memory access
rte_flow_validate and rte_flow_create not always initialize flow error.
Using error.message in some error cases will cause read from
uninitialized memory.
Fixes: 6738c0a9569 ("examples/ipsec-secgw: support flow director")
Signed-off-by: Volodymyr Fialko
---
examples/ipsec-secgw/flow.c | 2 +-
examples/ipsec-secgw/ipsec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/examples/ipsec-secgw/flow.c b/examples/ipsec-secgw/flow.c
index 1a1ec7861c..c217b9e475 100644
--- a/examples/ipsec-secgw/flow.c
+++ b/examples/ipsec-secgw/flow.c
@@ -214,7 +214,7 @@ flow_init_single(struct flow_rule_entry *rule)
struct rte_flow_item pattern[MAX_RTE_FLOW_PATTERN] = {};
struct rte_flow_action action[MAX_RTE_FLOW_ACTIONS] = {};
struct rte_flow_attr attr = {};
- struct rte_flow_error err;
+ struct rte_flow_error err = {};
int ret;
attr.egress = 0;
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 2d4a26c962..b66ff2b650 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -496,7 +496,7 @@ int
create_ipsec_esp_flow(struct ipsec_sa *sa)
{
int ret = 0;
- struct rte_flow_error err;
+ struct rte_flow_error err = {};
if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_EGRESS) {
RTE_LOG(ERR, IPSEC,
"No Flow director rule for Egress traffic\n");
--
2.25.1
[dpdk-dev] [PATCH] maintainers: update for NFP
From: Heinrich Kuhn Niklas has been appointed the new maintainer for the NFP PMD. Update the MAINTAINERS file to reflect this Signed-off-by: Heinrich Kuhn --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index fdea1c623f..2ae2f8ffb4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -835,7 +835,7 @@ F: doc/guides/nics/nfb.rst F: doc/guides/nics/features/nfb.ini Netronome nfp -M: Heinrich Kuhn +M: Niklas Soderlund F: drivers/net/nfp/ F: doc/guides/nics/nfp.rst F: doc/guides/nics/features/nfp*.ini -- 2.30.1 (Apple Git-130)
Re:Re: [PATCH v4] net/bonding: another fix to LACP mempool size
Hi, Stephen, Min Hu,
I will fix the issues.
Thanks.
Gaoxiang.
At 2022-03-09 10:53:15, "Min Hu (Connor)" wrote:
>Hi, Stephen,
>
>在 2022/3/9 9:25, Stephen Hemminger 写道:
>> On Tue, 8 Mar 2022 22:24:02 +0800
>> Gaoxiang Liu wrote:
>>
>>> diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
>>> index 1e7a3c1527..fa15ed710f 100644
>>> --- a/lib/mempool/rte_mempool.h
>>> +++ b/lib/mempool/rte_mempool.h
>>> @@ -56,6 +56,8 @@
>>> extern "C" {
>>> #endif
>>>
>>> +#define RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER 1.5
>>
>> Why is a magic number from bonding ending up in the user API for mempool?
>Yes, I suggest putting the macro(name should be changed) in bonding. No
>need to define a new RTE_* macro in mempool.
>By the way, the RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER is the same as
>CACHE_FLUSHTHRESH_MULTIPLIER already defined in rte_mempool.c.
>
>
>> .
>>
[PATCH v5] net/bonding: another fix to LACP mempool size
The following log message may appear after a slave is idle(or nearly idle) for a few minutes:"PMD: Failed to allocate LACP packet from pool". And bond mode 4 negotiation may fail. Problem:When bond mode 4 has been chosed and delicated queue has not been enable, all mbufs from a slave' private pool(used exclusively for transmitting LACPDUs) have been allocated in interrupt thread, and are still sitting in the device's tx descriptor ring and other cores' mempool caches in fwd thread. Thus the interrupt thread can not alloc LACP packet from pool. Solution: Ensure that each slave'tx (LACPDU) mempool owns more than n-tx-queues * n-tx-descriptor + fwd_core_num * per-core-mmempool-flush-threshold mbufs. Note that the LACP tx machine fuction is the only code that allocates from a slave's private pool. It runs in the context of the interrupt thread, and thus it has no mempool cache of its own. Signed-off-by: Gaoxiang Liu --- v2: * Fixed compile issues. v3: * delete duplicate code. v4; * Fixed some issues. 1. total_tx_desc should use += 2. add detailed logs v5: * Fixed some issues. 1. move CACHE_FLUSHTHRESH_MULTIPLIER to rte_eth_bond-8023ad.c 2. use RTE_MIN --- drivers/net/bonding/rte_eth_bond_8023ad.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c b/drivers/net/bonding/rte_eth_bond_8023ad.c index ca50583d62..4c65e7fff7 100644 --- a/drivers/net/bonding/rte_eth_bond_8023ad.c +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c @@ -1050,6 +1050,7 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, uint32_t total_tx_desc; struct bond_tx_queue *bd_tx_q; uint16_t q_id; + uint32_t cache_size; /* Given slave mus not be in active list */ RTE_ASSERT(find_slave_by_id(internals->active_slaves, @@ -1100,11 +1101,15 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, total_tx_desc += bd_tx_q->nb_tx_desc; } +/* 8023AD_CACHE_FLUSHTHRESH_MULTIPLIER is the same as + * CACHE_FLUSHTHRESH_MULTIPLIER already defined in rte_mempool.c */ +#define 8023AD_CACHE_FLUSHTHRESH_MULTIPLIER 1.5 + + cache_size = RTE_MIN(RTE_MEMPOOL_CACHE_MAX_SIZE, 32); + total_tx_desc += rte_lcore_count() * cache_size * 8023AD_CACHE_FLUSHTHRESH_MULTIPLIER; snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", slave_id); port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, total_tx_desc, - RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? - 32 : RTE_MEMPOOL_CACHE_MAX_SIZE, - 0, element_size, socket_id); + cache_size, 0, element_size, socket_id); /* Any memory allocation failure in initialization is critical because * resources can't be free, so reinitialization is impossible. */ -- 2.32.0
Re: [PATCH] eal: factorize lcore main loop
On Thu, Mar 24, 2022 at 03:44:23PM +0100, David Marchand wrote:
> On Thu, Mar 24, 2022 at 9:31 AM Tyler Retzlaff
> wrote:
> > > diff --git a/lib/eal/common/eal_common_thread.c
> > > b/lib/eal/common/eal_common_thread.c
> > > index 684bea166c..256de91abc 100644
> > > --- a/lib/eal/common/eal_common_thread.c
> > > +++ b/lib/eal/common/eal_common_thread.c
> > > @@ -9,6 +9,7 @@
> > > #include
> > > #include
> > >
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -163,6 +164,77 @@ __rte_thread_uninit(void)
> > > RTE_PER_LCORE(_lcore_id) = LCORE_ID_ANY;
> > > }
> > >
> > > +/* main loop of threads */
> > > +__rte_noreturn void *
> > > +eal_thread_loop(__rte_unused void *arg)
> > > +{
> > > + char cpuset[RTE_CPU_AFFINITY_STR_LEN];
> > > + pthread_t thread_id = pthread_self();
> > > + unsigned int lcore_id;
> > > + int ret;
> > > +
> > > + /* retrieve our lcore_id from the configuration structure */
> > > + RTE_LCORE_FOREACH_WORKER(lcore_id) {
> > > + if (thread_id == lcore_config[lcore_id].thread_id)
> >
> >
> > i can see that in practice this isn't a problem since the linux
> > implementation of pthread_create(3) stores to pthread_t *thread before
> > executing start_routine.
> >
> > but strictly speaking i don't think the pthread_create api contractually
> > guarantees that the thread id is stored before start_routine runs. so this
> > is relying on an internal implementation detail.
> >
> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_create.html
> >
> > "Upon successful completion, pthread_create() shall store the ID of the
> >created thread in the location referenced by thread."
> >
> > https://man7.org/linux/man-pages/man3/pthread_create.3.html
> >
> > "Before returning, a successful call to pthread_create() stores
> >the ID of the new thread in the buffer pointed to by thread; this
> >identifier is used to refer to the thread in subsequent calls to
> >other pthreads functions."
> >
> > it doesn't really say when it does this in relation to start_routine
> > running.
> > depends how hair splitty you want to be about it. but since you're revamping
> > the code you might be interested in addressing it.
>
> I had wondered about this part too in the past.
>
> I don't see a reason to keep this loop (even considering baremetal,
> since this code is within the linux implementation of EAL).
> And this comment seems a good reason to cleanup the code (like simply
> pass lcore_id via arg).
>
> Something like:
>
> Author: David Marchand
> Date: Thu Mar 24 11:29:46 2022 +0100
>
> eal: cleanup lcore hand-over from main thread
>
> As noted by Tyler, there is nothing in the pthread API that strictly
> guarantees that the new thread won't start running eal_thread_loop
> before pthread_create writes to &lcore_config[xx].thread_id.
>
> Rather than rely on thread id, the main thread can directly pass the
> worker thread lcore.
>
> Signed-off-by: David Marchand
>
> diff --git a/lib/eal/common/eal_common_thread.c
> b/lib/eal/common/eal_common_thread.c
> index 256de91abc..962b7e9ac4 100644
> --- a/lib/eal/common/eal_common_thread.c
> +++ b/lib/eal/common/eal_common_thread.c
> @@ -166,26 +166,17 @@ __rte_thread_uninit(void)
>
> /* main loop of threads */
> __rte_noreturn void *
> -eal_thread_loop(__rte_unused void *arg)
> +eal_thread_loop(void *arg)
> {
> +unsigned int lcore_id = (uintptr_t)arg;
> char cpuset[RTE_CPU_AFFINITY_STR_LEN];
> -pthread_t thread_id = pthread_self();
> -unsigned int lcore_id;
> int ret;
>
> -/* retrieve our lcore_id from the configuration structure */
> -RTE_LCORE_FOREACH_WORKER(lcore_id) {
> -if (thread_id == lcore_config[lcore_id].thread_id)
> -break;
> -}
> -if (lcore_id == RTE_MAX_LCORE)
> -rte_panic("cannot retrieve lcore id\n");
> -
> __rte_thread_init(lcore_id, &lcore_config[lcore_id].cpuset);
>
> ret = eal_thread_dump_current_affinity(cpuset, sizeof(cpuset));
> RTE_LOG(DEBUG, EAL, "lcore %u is ready (tid=%zx;cpuset=[%s%s])\n",
> -lcore_id, (uintptr_t)thread_id, cpuset,
> +lcore_id, (uintptr_t)pthread_self(), cpuset,
> ret == 0 ? "" : "...");
>
> rte_eal_trace_thread_lcore_ready(lcore_id, cpuset);
> diff --git a/lib/eal/common/eal_thread.h b/lib/eal/common/eal_thread.h
> index b08dcf34b5..0fde33e70c 100644
> --- a/lib/eal/common/eal_thread.h
> +++ b/lib/eal/common/eal_thread.h
> @@ -11,7 +11,7 @@
> * basic loop of thread, called for each thread by eal_init().
> *
> * @param arg
> - * opaque pointer
> + * The lcore_id (passed as an integer) of this worker thread.
> */
> __rte_noreturn void *eal_thread_loop(void *arg);
>
> diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
> index 80bc3d25e0..a6b20960f2 100644
> --- a/lib/eal/freebsd/eal.c
>
Re: [PATCH] eal: factorize lcore main loop
On Wed, Mar 23, 2022 at 10:30:01AM +0100, David Marchand wrote: > All OS implementations provide the same main loop. > Introduce helpers (shared for Linux and FreeBSD) to handle synchronisation > between main and threads and factorize the rest as common code. > Thread id are now logged as string in a common format across OS. > > Signed-off-by: David Marchand > --- > I had this patch in store for a long time. > I don't particularly care about it, it's not fixing anything. > But it seems a good cleanup/consolidation, so I rebased it and I am > sending it to get feedback. Acked-By: Tyler Retzlaff
[PATCH 1/4] common/cnxk: add CN103XX platform support
Added support for CN103XX (cn10kb) platform.
Signed-off-by: Rahul Bhansali
---
doc/guides/platform/cnxk.rst| 1 +
drivers/common/cnxk/roc_constants.h | 1 +
drivers/common/cnxk/roc_model.c | 4
drivers/common/cnxk/roc_model.h | 11 ++-
4 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/doc/guides/platform/cnxk.rst b/doc/guides/platform/cnxk.rst
index 3dee725ac5..92aa702a78 100644
--- a/doc/guides/platform/cnxk.rst
+++ b/doc/guides/platform/cnxk.rst
@@ -18,6 +18,7 @@ Supported OCTEON cnxk SoCs
- CN98xx
- CN106xx
- CNF105xx
+- CN103XX
Resource Virtualization Unit architecture
-
diff --git a/drivers/common/cnxk/roc_constants.h
b/drivers/common/cnxk/roc_constants.h
index 38e2087a26..1daaabfe55 100644
--- a/drivers/common/cnxk/roc_constants.h
+++ b/drivers/common/cnxk/roc_constants.h
@@ -52,6 +52,7 @@
#define PCI_SUBSYSTEM_DEVID_CN10KA 0xB900
#define PCI_SUBSYSTEM_DEVID_CN10KAS 0xB900
#define PCI_SUBSYSTEM_DEVID_CNF10KA 0xBA00
+#define PCI_SUBSYSTEM_DEVID_CN10KB 0xB900
#define PCI_SUBSYSTEM_DEVID_CN9KA 0x
#define PCI_SUBSYSTEM_DEVID_CN9KB 0xb400
diff --git a/drivers/common/cnxk/roc_model.c b/drivers/common/cnxk/roc_model.c
index 4120029541..1dd374e0fd 100644
--- a/drivers/common/cnxk/roc_model.c
+++ b/drivers/common/cnxk/roc_model.c
@@ -16,6 +16,7 @@ struct roc_model *roc_model;
#define PART_106xx 0xB9
#define PART_105xx 0xBA
#define PART_105xxN 0xBC
+#define PART_103xx 0xBE
#define PART_98xx 0xB1
#define PART_96xx 0xB2
#define PART_95xx 0xB3
@@ -46,6 +47,7 @@ static const struct model_db {
} model_db[] = {
{VENDOR_ARM, PART_106xx, 0, 0, ROC_MODEL_CN106xx_A0, "cn10ka_a0"},
{VENDOR_ARM, PART_105xx, 0, 0, ROC_MODEL_CNF105xx_A0, "cnf10ka_a0"},
+ {VENDOR_ARM, PART_103xx, 0, 0, ROC_MODEL_CN103xx_A0, "cn10kb_a0"},
{VENDOR_ARM, PART_105xxN, 0, 0, ROC_MODEL_CNF105xxN_A0, "cnf10kb_a0"},
{VENDOR_CAVIUM, PART_98xx, 0, 0, ROC_MODEL_CN98xx_A0, "cn98xx_a0"},
{VENDOR_CAVIUM, PART_96xx, 0, 0, ROC_MODEL_CN96xx_A0, "cn96xx_a0"},
@@ -92,6 +94,8 @@ cn10k_part_get(void)
soc = PART_105xx;
} else if (strcmp("cnf10kb", ptr) == 0) {
soc = PART_105xxN;
+ } else if (strcmp("cn10kb", ptr) == 0) {
+ soc = PART_103xx;
} else {
plt_err("Unidentified 'CPU compatible': <%s>", ptr);
goto fclose;
diff --git a/drivers/common/cnxk/roc_model.h b/drivers/common/cnxk/roc_model.h
index 4567566169..885c3d668f 100644
--- a/drivers/common/cnxk/roc_model.h
+++ b/drivers/common/cnxk/roc_model.h
@@ -24,6 +24,7 @@ struct roc_model {
#define ROC_MODEL_CN106xx_A0 BIT_ULL(20)
#define ROC_MODEL_CNF105xx_A0 BIT_ULL(21)
#define ROC_MODEL_CNF105xxN_A0 BIT_ULL(22)
+#define ROC_MODEL_CN103xx_A0 BIT_ULL(23)
/* Following flags describe platform code is running on */
#define ROC_ENV_HW BIT_ULL(61)
#define ROC_ENV_EMUL BIT_ULL(62)
@@ -50,8 +51,10 @@ struct roc_model {
#define ROC_MODEL_CN106xx (ROC_MODEL_CN106xx_A0)
#define ROC_MODEL_CNF105xx (ROC_MODEL_CNF105xx_A0)
#define ROC_MODEL_CNF105xxN (ROC_MODEL_CNF105xxN_A0)
+#define ROC_MODEL_CN103xx (ROC_MODEL_CN103xx_A0)
#define ROC_MODEL_CN10K
\
- (ROC_MODEL_CN106xx | ROC_MODEL_CNF105xx | ROC_MODEL_CNF105xxN)
+ (ROC_MODEL_CN106xx | ROC_MODEL_CNF105xx | ROC_MODEL_CNF105xxN |\
+ROC_MODEL_CN103xx)
#define ROC_MODEL_CNF10K (ROC_MODEL_CNF105xx | ROC_MODEL_CNF105xxN)
/* Runtime variants */
@@ -152,6 +155,12 @@ roc_model_is_cnf10kb(void)
return roc_model->flag & ROC_MODEL_CNF105xxN;
}
+static inline uint64_t
+roc_model_is_cn10kb_a0(void)
+{
+ return roc_model->flag & ROC_MODEL_CN103xx_A0;
+}
+
static inline uint64_t
roc_model_is_cn10ka_a0(void)
{
--
2.25.1
[PATCH 2/4] net/cnxk: add CN103XX platform support
Added PCI device ID for CN103XX (cn10kb) platform.
Signed-off-by: Rahul Bhansali
---
drivers/net/cnxk/cn10k_ethdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/cnxk/cn10k_ethdev.c b/drivers/net/cnxk/cn10k_ethdev.c
index 15dbea2180..ce3707be6f 100644
--- a/drivers/net/cnxk/cn10k_ethdev.c
+++ b/drivers/net/cnxk/cn10k_ethdev.c
@@ -795,12 +795,15 @@ static const struct rte_pci_id cn10k_pci_nix_map[] = {
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KA, PCI_DEVID_CNXK_RVU_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KAS, PCI_DEVID_CNXK_RVU_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CNF10KA, PCI_DEVID_CNXK_RVU_PF),
+ CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KB, PCI_DEVID_CNXK_RVU_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KA, PCI_DEVID_CNXK_RVU_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KAS, PCI_DEVID_CNXK_RVU_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CNF10KA, PCI_DEVID_CNXK_RVU_VF),
+ CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KB, PCI_DEVID_CNXK_RVU_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KA, PCI_DEVID_CNXK_RVU_AF_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KAS, PCI_DEVID_CNXK_RVU_AF_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CNF10KA, PCI_DEVID_CNXK_RVU_AF_VF),
+ CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KB, PCI_DEVID_CNXK_RVU_AF_VF),
{
.vendor_id = 0,
},
--
2.25.1
[PATCH 4/4] mempool/cnxk: add CN103XX platform support
Added PCI device ID for CN103XX (cn10kb) platform.
Signed-off-by: Rahul Bhansali
---
drivers/mempool/cnxk/cnxk_mempool.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mempool/cnxk/cnxk_mempool.c
b/drivers/mempool/cnxk/cnxk_mempool.c
index ea473552dd..a28fe5406d 100644
--- a/drivers/mempool/cnxk/cnxk_mempool.c
+++ b/drivers/mempool/cnxk/cnxk_mempool.c
@@ -163,6 +163,7 @@ npa_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
static const struct rte_pci_id npa_pci_map[] = {
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KA, PCI_DEVID_CNXK_RVU_NPA_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KAS, PCI_DEVID_CNXK_RVU_NPA_PF),
+ CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KB, PCI_DEVID_CNXK_RVU_NPA_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN9KA, PCI_DEVID_CNXK_RVU_NPA_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN9KB, PCI_DEVID_CNXK_RVU_NPA_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN9KC, PCI_DEVID_CNXK_RVU_NPA_PF),
@@ -170,6 +171,7 @@ static const struct rte_pci_id npa_pci_map[] = {
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN9KE, PCI_DEVID_CNXK_RVU_NPA_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KA, PCI_DEVID_CNXK_RVU_NPA_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KAS, PCI_DEVID_CNXK_RVU_NPA_VF),
+ CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KB, PCI_DEVID_CNXK_RVU_NPA_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN9KA, PCI_DEVID_CNXK_RVU_NPA_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN9KB, PCI_DEVID_CNXK_RVU_NPA_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN9KC, PCI_DEVID_CNXK_RVU_NPA_VF),
--
2.25.1
[PATCH 3/4] event/cnxk: add CN103XX platform support
Added PCI device ID for CN103XX (cn10kb) platform.
Signed-off-by: Rahul Bhansali
---
drivers/event/cnxk/cn10k_eventdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/event/cnxk/cn10k_eventdev.c
b/drivers/event/cnxk/cn10k_eventdev.c
index 9b4d2895ec..75c748f611 100644
--- a/drivers/event/cnxk/cn10k_eventdev.c
+++ b/drivers/event/cnxk/cn10k_eventdev.c
@@ -935,9 +935,11 @@ static const struct rte_pci_id cn10k_pci_sso_map[] = {
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KA, PCI_DEVID_CNXK_RVU_SSO_TIM_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KAS, PCI_DEVID_CNXK_RVU_SSO_TIM_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CNF10KA, PCI_DEVID_CNXK_RVU_SSO_TIM_PF),
+ CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KB, PCI_DEVID_CNXK_RVU_SSO_TIM_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KA, PCI_DEVID_CNXK_RVU_SSO_TIM_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KAS, PCI_DEVID_CNXK_RVU_SSO_TIM_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CNF10KA, PCI_DEVID_CNXK_RVU_SSO_TIM_VF),
+ CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KB, PCI_DEVID_CNXK_RVU_SSO_TIM_VF),
{
.vendor_id = 0,
},
--
2.25.1
RE: [PATCH v5] net/bonding: another fix to LACP mempool size
+CC mempool maintainers > From: Gaoxiang Liu [mailto:gaoxiangl...@163.com] > Sent: Friday, 25 March 2022 14.02 > > The following log message may appear after a slave is idle(or nearly > idle) > for a few minutes:"PMD: Failed to allocate LACP packet from pool". > And bond mode 4 negotiation may fail. > > Problem:When bond mode 4 has been chosed and delicated queue has > not been enable, all mbufs from a slave' private pool(used > exclusively for transmitting LACPDUs) have been allocated in > interrupt thread, and are still sitting in the device's tx > descriptor ring and other cores' mempool caches in fwd thread. > Thus the interrupt thread can not alloc LACP packet from pool. > > Solution: Ensure that each slave'tx (LACPDU) mempool owns more than > n-tx-queues * n-tx-descriptor + fwd_core_num * > per-core-mmempool-flush-threshold mbufs. > > Note that the LACP tx machine fuction is the only code that allocates > from a slave's private pool. It runs in the context of the interrupt > thread, and thus it has no mempool cache of its own. > > Signed-off-by: Gaoxiang Liu > > --- > v2: > * Fixed compile issues. > > v3: > * delete duplicate code. > > v4; > * Fixed some issues. > 1. total_tx_desc should use += > 2. add detailed logs > > v5: > * Fixed some issues. > 1. move CACHE_FLUSHTHRESH_MULTIPLIER to rte_eth_bond-8023ad.c > 2. use RTE_MIN > --- > drivers/net/bonding/rte_eth_bond_8023ad.c | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c > b/drivers/net/bonding/rte_eth_bond_8023ad.c > index ca50583d62..2c39b0d062 100644 > --- a/drivers/net/bonding/rte_eth_bond_8023ad.c > +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c > @@ -1050,6 +1050,7 @@ bond_mode_8023ad_activate_slave(struct > rte_eth_dev *bond_dev, > uint32_t total_tx_desc; > struct bond_tx_queue *bd_tx_q; > uint16_t q_id; > + uint32_t cache_size; > > /* Given slave mus not be in active list */ > RTE_ASSERT(find_slave_by_id(internals->active_slaves, > @@ -1100,11 +1101,15 @@ bond_mode_8023ad_activate_slave(struct > rte_eth_dev *bond_dev, > total_tx_desc += bd_tx_q->nb_tx_desc; > } > > +/* BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER is the same as > + * CACHE_FLUSHTHRESH_MULTIPLIER already defined in rte_mempool.c */ > +#define BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER 1.5 Very important comment. Thank you! May I suggest that a similar comment is added to the rte_mempool.c file, so if CACHE_FLUSHTHRESH_MULTIPLIER is changed there, we don't forget to change the copy-pasted code in the rte_eth_bond_8023ad.c file too. It has previously been discussed changing it from 1.5 to 2 for symmetry reasons. > + > + cache_size = RTE_MIN(RTE_MEMPOOL_CACHE_MAX_SIZE, 32); > + total_tx_desc += rte_lcore_count() * cache_size * > BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER; > snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", > slave_id); > port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, > total_tx_desc, > - RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? > - 32 : RTE_MEMPOOL_CACHE_MAX_SIZE, > - 0, element_size, socket_id); > + cache_size, 0, element_size, socket_id); > > /* Any memory allocation failure in initialization is critical > because >* resources can't be free, so reinitialization is impossible. */ > -- > 2.32.0 >
RE: DPDK for Windows with MSVC compiler
> Is there a way to integrate DPDK module, built with clang/mingw, to our > MSVC application ? > I know both are different compilers, but in case if you are aware of a > way/tweak that will be of our help. > OR > If porting our application is the only option available then which > compiler (clang or mingw) is recommended for optimal performance. DPDK headers are incompatible with MSVC due to heavy use of extensions common to GCC, clang, and ICC. DPDK libraries can be linked trivially. If your app cannot be easily recompiled with clang, I think the best way is to use two compilers: compile the module that interfaces DPDK with clang and the rest of the app with MSVC, link DPDK libraries as any other external libraries. Note that DPDK installation on Windows is not fully functional yet: it does not install pthread.h which you can find in lib/eal/windows/include. +Tyler who might have relevant experience.
[PATCH v6] net/bonding: another fix to LACP mempool size
The following log message may appear after a slave is idle(or nearly idle) for a few minutes:"PMD: Failed to allocate LACP packet from pool". And bond mode 4 negotiation may fail. Problem:When bond mode 4 has been chosed and delicated queue has not been enable, all mbufs from a slave' private pool(used exclusively for transmitting LACPDUs) have been allocated in interrupt thread, and are still sitting in the device's tx descriptor ring and other cores' mempool caches in fwd thread. Thus the interrupt thread can not alloc LACP packet from pool. Solution: Ensure that each slave'tx (LACPDU) mempool owns more than n-tx-queues * n-tx-descriptor + fwd_core_num * per-core-mmempool-flush-threshold mbufs. Note that the LACP tx machine fuction is the only code that allocates from a slave's private pool. It runs in the context of the interrupt thread, and thus it has no mempool cache of its own. Signed-off-by: Gaoxiang Liu --- v2: * Fixed compile issues. v3: * delete duplicate code. v4; * Fixed some issues. 1. total_tx_desc should use += 2. add detailed logs v5: * Fixed some issues. 1. move CACHE_FLUSHTHRESH_MULTIPLIER to rte_eth_bond-8023ad.c 2. use RTE_MIN v6: * add a comment of CACHE_FLUSHTHRESH_MULTIPLIER macro --- drivers/net/bonding/rte_eth_bond_8023ad.c | 11 --- lib/mempool/rte_mempool.c | 2 ++ 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c b/drivers/net/bonding/rte_eth_bond_8023ad.c index ca50583d62..2c39b0d062 100644 --- a/drivers/net/bonding/rte_eth_bond_8023ad.c +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c @@ -1050,6 +1050,7 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, uint32_t total_tx_desc; struct bond_tx_queue *bd_tx_q; uint16_t q_id; + uint32_t cache_size; /* Given slave mus not be in active list */ RTE_ASSERT(find_slave_by_id(internals->active_slaves, @@ -1100,11 +1101,15 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, total_tx_desc += bd_tx_q->nb_tx_desc; } +/* BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER is the same as + * CACHE_FLUSHTHRESH_MULTIPLIER already defined in rte_mempool.c */ +#define BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER 1.5 + + cache_size = RTE_MIN(RTE_MEMPOOL_CACHE_MAX_SIZE, 32); + total_tx_desc += rte_lcore_count() * cache_size * BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER; snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", slave_id); port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, total_tx_desc, - RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? - 32 : RTE_MEMPOOL_CACHE_MAX_SIZE, - 0, element_size, socket_id); + cache_size, 0, element_size, socket_id); /* Any memory allocation failure in initialization is critical because * resources can't be free, so reinitialization is impossible. */ diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c index c5a699b1d6..6126067628 100644 --- a/lib/mempool/rte_mempool.c +++ b/lib/mempool/rte_mempool.c @@ -55,6 +55,8 @@ static void mempool_event_callback_invoke(enum rte_mempool_event event, struct rte_mempool *mp); +/* CACHE_FLUSHTHRESH_MULTIPLIER is the same as + * BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER in rte_eth_bond_8023ad.c */ #define CACHE_FLUSHTHRESH_MULTIPLIER 1.5 #define CALC_CACHE_FLUSHTHRESH(c) \ ((typeof(c))((c) * CACHE_FLUSHTHRESH_MULTIPLIER)) -- 2.32.0
[PATCH v5] net/bonding: another fix to LACP mempool size
The following log message may appear after a slave is idle(or nearly idle) for a few minutes:"PMD: Failed to allocate LACP packet from pool". And bond mode 4 negotiation may fail. Problem:When bond mode 4 has been chosed and delicated queue has not been enable, all mbufs from a slave' private pool(used exclusively for transmitting LACPDUs) have been allocated in interrupt thread, and are still sitting in the device's tx descriptor ring and other cores' mempool caches in fwd thread. Thus the interrupt thread can not alloc LACP packet from pool. Solution: Ensure that each slave'tx (LACPDU) mempool owns more than n-tx-queues * n-tx-descriptor + fwd_core_num * per-core-mmempool-flush-threshold mbufs. Note that the LACP tx machine fuction is the only code that allocates from a slave's private pool. It runs in the context of the interrupt thread, and thus it has no mempool cache of its own. Signed-off-by: Gaoxiang Liu --- v2: * Fixed compile issues. v3: * delete duplicate code. v4; * Fixed some issues. 1. total_tx_desc should use += 2. add detailed logs v5: * Fixed some issues. 1. move CACHE_FLUSHTHRESH_MULTIPLIER to rte_eth_bond-8023ad.c 2. use RTE_MIN --- drivers/net/bonding/rte_eth_bond_8023ad.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c b/drivers/net/bonding/rte_eth_bond_8023ad.c index ca50583d62..2c39b0d062 100644 --- a/drivers/net/bonding/rte_eth_bond_8023ad.c +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c @@ -1050,6 +1050,7 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, uint32_t total_tx_desc; struct bond_tx_queue *bd_tx_q; uint16_t q_id; + uint32_t cache_size; /* Given slave mus not be in active list */ RTE_ASSERT(find_slave_by_id(internals->active_slaves, @@ -1100,11 +1101,15 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, total_tx_desc += bd_tx_q->nb_tx_desc; } +/* BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER is the same as + * CACHE_FLUSHTHRESH_MULTIPLIER already defined in rte_mempool.c */ +#define BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER 1.5 + + cache_size = RTE_MIN(RTE_MEMPOOL_CACHE_MAX_SIZE, 32); + total_tx_desc += rte_lcore_count() * cache_size * BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER; snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", slave_id); port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, total_tx_desc, - RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? - 32 : RTE_MEMPOOL_CACHE_MAX_SIZE, - 0, element_size, socket_id); + cache_size, 0, element_size, socket_id); /* Any memory allocation failure in initialization is critical because * resources can't be free, so reinitialization is impossible. */ -- 2.32.0
Re: [PATCH v3] examples/vm_power: add support for list_foreach_safe
Hi Shibin,
On 22/3/2022 2:43 PM, Shibin Koikkara Reeny wrote:
Asan tool reported LIST_FOREACH should be replaced with
LIST_FOREACH_SAFE. Added support for LIST_FOREACH_SAFE
macro in rte_os.h file as Linux header file sys/queue.h
don't support LIST_FOREACH_SAFE macro.
RTE_LIST_FOREACH_SAFE is alias for LIST_FOREACH_SAFE.
Fixes: e8ae9b662506 ("examples/vm_power: channel manager and monitor in host")
Cc: alan.ca...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Shibin Koikkara Reeny
---
v3: add blank line after declaration
v2: add support for list_foreach_safe
---
examples/vm_power_manager/channel_manager.c | 10 ++
lib/eal/linux/include/rte_os.h | 11 +++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/examples/vm_power_manager/channel_manager.c
b/examples/vm_power_manager/channel_manager.c
index 838465ab4b..2d54641f2e 100644
--- a/examples/vm_power_manager/channel_manager.c
+++ b/examples/vm_power_manager/channel_manager.c
@@ -66,8 +66,9 @@ LIST_HEAD(, virtual_machine_info) vm_list_head;
static struct virtual_machine_info *
find_domain_by_name(const char *name)
{
- struct virtual_machine_info *info;
- LIST_FOREACH(info, &vm_list_head, vms_info) {
+ struct virtual_machine_info *info, *t_info;
+
+ RTE_LIST_FOREACH_SAFE(info, &vm_list_head, vms_info, t_info) {
if (!strncmp(info->name, name, CHANNEL_MGR_MAX_NAME_LEN-1))
return info;
}
@@ -1005,9 +1006,9 @@ channel_manager_exit(void)
{
unsigned i;
char mask[RTE_MAX_LCORE];
- struct virtual_machine_info *vm_info;
+ struct virtual_machine_info *vm_info, *t_info;
- LIST_FOREACH(vm_info, &vm_list_head, vms_info) {
+ RTE_LIST_FOREACH_SAFE(vm_info, &vm_list_head, vms_info, t_info) {
rte_spinlock_lock(&(vm_info->config_spinlock));
@@ -1024,6 +1025,7 @@ channel_manager_exit(void)
LIST_REMOVE(vm_info, vms_info);
rte_free(vm_info);
+
}
if (global_hypervisor_available) {
diff --git a/lib/eal/linux/include/rte_os.h b/lib/eal/linux/include/rte_os.h
index c72bf5b7e6..3acff49360 100644
--- a/lib/eal/linux/include/rte_os.h
+++ b/lib/eal/linux/include/rte_os.h
@@ -25,6 +25,8 @@ extern "C" {
#define RTE_TAILQ_NEXT(elem, field) TAILQ_NEXT(elem, field)
#define RTE_STAILQ_HEAD(name, type) STAILQ_HEAD(name, type)
#define RTE_STAILQ_ENTRY(type) STAILQ_ENTRY(type)
+#define RTE_LIST_FIRST(head) LIST_FIRST(head)
+#define RTE_LIST_NEXT(elem, field) LIST_NEXT(elem, field)
#ifdef CPU_SETSIZE /* may require _GNU_SOURCE */
typedef cpu_set_t rte_cpuset_t;
@@ -46,6 +48,15 @@ typedef cpu_set_t rte_cpuset_t;
} while (0)
#endif
+#ifndef LIST_FOREACH_SAFE
+#define LIST_FOREACH_SAFE(var, head, field, tvar) \
+ for ((var) = RTE_LIST_FIRST(head); \
+ (var) && ((tvar) = RTE_LIST_NEXT((var), field), 1); \
+ (var) = (tvar))
+#endif
+#define RTE_LIST_FOREACH_SAFE(var, head, field, tvar) \
+ LIST_FOREACH_SAFE(var, head, field, tvar)
+
#ifdef __cplusplus
}
#endif
Looks cleaner that the previous version.
Acked-by: David Hunt
RE: [PATCH v6] net/bonding: another fix to LACP mempool size
> From: Gaoxiang Liu [mailto:gaoxiangl...@163.com] > Sent: Friday, 25 March 2022 14.34 > > The following log message may appear after a slave is idle(or nearly > idle) > for a few minutes:"PMD: Failed to allocate LACP packet from pool". > And bond mode 4 negotiation may fail. > > Problem:When bond mode 4 has been chosed and delicated queue has > not been enable, all mbufs from a slave' private pool(used > exclusively for transmitting LACPDUs) have been allocated in > interrupt thread, and are still sitting in the device's tx > descriptor ring and other cores' mempool caches in fwd thread. > Thus the interrupt thread can not alloc LACP packet from pool. > > Solution: Ensure that each slave'tx (LACPDU) mempool owns more than > n-tx-queues * n-tx-descriptor + fwd_core_num * > per-core-mmempool-flush-threshold mbufs. > > Note that the LACP tx machine fuction is the only code that allocates > from a slave's private pool. It runs in the context of the interrupt > thread, and thus it has no mempool cache of its own. > > Signed-off-by: Gaoxiang Liu > > --- > v2: > * Fixed compile issues. > > v3: > * delete duplicate code. > > v4; > * Fixed some issues. > 1. total_tx_desc should use += > 2. add detailed logs > > v5: > * Fixed some issues. > 1. move CACHE_FLUSHTHRESH_MULTIPLIER to rte_eth_bond-8023ad.c > 2. use RTE_MIN > > v6: > * add a comment of CACHE_FLUSHTHRESH_MULTIPLIER macro > --- > drivers/net/bonding/rte_eth_bond_8023ad.c | 11 --- > lib/mempool/rte_mempool.c | 2 ++ > 2 files changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c > b/drivers/net/bonding/rte_eth_bond_8023ad.c > index ca50583d62..2c39b0d062 100644 > --- a/drivers/net/bonding/rte_eth_bond_8023ad.c > +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c > @@ -1050,6 +1050,7 @@ bond_mode_8023ad_activate_slave(struct > rte_eth_dev *bond_dev, > uint32_t total_tx_desc; > struct bond_tx_queue *bd_tx_q; > uint16_t q_id; > + uint32_t cache_size; > > /* Given slave mus not be in active list */ > RTE_ASSERT(find_slave_by_id(internals->active_slaves, > @@ -1100,11 +1101,15 @@ bond_mode_8023ad_activate_slave(struct > rte_eth_dev *bond_dev, > total_tx_desc += bd_tx_q->nb_tx_desc; > } > > +/* BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER is the same as > + * CACHE_FLUSHTHRESH_MULTIPLIER already defined in rte_mempool.c */ > +#define BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER 1.5 > + > + cache_size = RTE_MIN(RTE_MEMPOOL_CACHE_MAX_SIZE, 32); > + total_tx_desc += rte_lcore_count() * cache_size * > BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER; > snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", > slave_id); > port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, > total_tx_desc, > - RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? > - 32 : RTE_MEMPOOL_CACHE_MAX_SIZE, > - 0, element_size, socket_id); > + cache_size, 0, element_size, socket_id); > > /* Any memory allocation failure in initialization is critical > because >* resources can't be free, so reinitialization is impossible. */ > diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c > index c5a699b1d6..6126067628 100644 > --- a/lib/mempool/rte_mempool.c > +++ b/lib/mempool/rte_mempool.c > @@ -55,6 +55,8 @@ static void > mempool_event_callback_invoke(enum rte_mempool_event event, > struct rte_mempool *mp); > > +/* CACHE_FLUSHTHRESH_MULTIPLIER is the same as > + * BONDING_8023AD_CACHE_FLUSHTHRESH_MULTIPLIER in > rte_eth_bond_8023ad.c */ > #define CACHE_FLUSHTHRESH_MULTIPLIER 1.5 > #define CALC_CACHE_FLUSHTHRESH(c)\ > ((typeof(c))((c) * CACHE_FLUSHTHRESH_MULTIPLIER)) > -- > 2.32.0 > Acked-by: Morten Brørup
Re: [PATCH] ci: run more checks in private repositories
David Marchand writes: > Though devtools/checkpatches.sh is run as part of our CI, some other > (not well known) checks could help when run in private repositories > before submitting to the mailing list and even when run from the > ovsrobot. > > Most of them require a git history or checked sources to run. > And I can't guarantee there won't be false positives. > > Add a new job just for those checks so that it won't block compilation > tests in other jobs. > > Signed-off-by: David Marchand > --- Looks good to me. The extra fetches shouldn't take too long (since we refresh main branch weekly to the robot repository). The checks look good - and since it's part of the same build workflow, it will be reported in the same place (and hopefully in a readable form). Acked-by: Aaron Conole
Re: [PATCH] eal: factorize lcore main loop
25/03/2022 13:11, Tyler Retzlaff:
> On Thu, Mar 24, 2022 at 03:44:23PM +0100, David Marchand wrote:
> > On Thu, Mar 24, 2022 at 9:31 AM Tyler Retzlaff
> > wrote:
> > > > diff --git a/lib/eal/common/eal_common_thread.c
> > > > b/lib/eal/common/eal_common_thread.c
> > > > index 684bea166c..256de91abc 100644
> > > > --- a/lib/eal/common/eal_common_thread.c
> > > > +++ b/lib/eal/common/eal_common_thread.c
> > > > @@ -9,6 +9,7 @@
> > > > #include
> > > > #include
> > > >
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -163,6 +164,77 @@ __rte_thread_uninit(void)
> > > > RTE_PER_LCORE(_lcore_id) = LCORE_ID_ANY;
> > > > }
> > > >
> > > > +/* main loop of threads */
> > > > +__rte_noreturn void *
> > > > +eal_thread_loop(__rte_unused void *arg)
> > > > +{
> > > > + char cpuset[RTE_CPU_AFFINITY_STR_LEN];
> > > > + pthread_t thread_id = pthread_self();
> > > > + unsigned int lcore_id;
> > > > + int ret;
> > > > +
> > > > + /* retrieve our lcore_id from the configuration structure */
> > > > + RTE_LCORE_FOREACH_WORKER(lcore_id) {
> > > > + if (thread_id == lcore_config[lcore_id].thread_id)
> > >
> > >
> > > i can see that in practice this isn't a problem since the linux
> > > implementation of pthread_create(3) stores to pthread_t *thread before
> > > executing start_routine.
> > >
> > > but strictly speaking i don't think the pthread_create api contractually
> > > guarantees that the thread id is stored before start_routine runs. so this
> > > is relying on an internal implementation detail.
> > >
> > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_create.html
> > >
> > > "Upon successful completion, pthread_create() shall store the ID of the
> > >created thread in the location referenced by thread."
> > >
> > > https://man7.org/linux/man-pages/man3/pthread_create.3.html
> > >
> > > "Before returning, a successful call to pthread_create() stores
> > >the ID of the new thread in the buffer pointed to by thread; this
> > >identifier is used to refer to the thread in subsequent calls to
> > >other pthreads functions."
> > >
> > > it doesn't really say when it does this in relation to start_routine
> > > running.
> > > depends how hair splitty you want to be about it. but since you're
> > > revamping
> > > the code you might be interested in addressing it.
> >
> > I had wondered about this part too in the past.
> >
> > I don't see a reason to keep this loop (even considering baremetal,
> > since this code is within the linux implementation of EAL).
> > And this comment seems a good reason to cleanup the code (like simply
> > pass lcore_id via arg).
> >
> > Something like:
> >
> > Author: David Marchand
> > Date: Thu Mar 24 11:29:46 2022 +0100
> >
> > eal: cleanup lcore hand-over from main thread
> >
> > As noted by Tyler, there is nothing in the pthread API that strictly
> > guarantees that the new thread won't start running eal_thread_loop
> > before pthread_create writes to &lcore_config[xx].thread_id.
> >
> > Rather than rely on thread id, the main thread can directly pass the
> > worker thread lcore.
> >
> > Signed-off-by: David Marchand
> >
> > diff --git a/lib/eal/common/eal_common_thread.c
> > b/lib/eal/common/eal_common_thread.c
> > index 256de91abc..962b7e9ac4 100644
> > --- a/lib/eal/common/eal_common_thread.c
> > +++ b/lib/eal/common/eal_common_thread.c
> > @@ -166,26 +166,17 @@ __rte_thread_uninit(void)
> >
> > /* main loop of threads */
> > __rte_noreturn void *
> > -eal_thread_loop(__rte_unused void *arg)
> > +eal_thread_loop(void *arg)
> > {
> > +unsigned int lcore_id = (uintptr_t)arg;
> > char cpuset[RTE_CPU_AFFINITY_STR_LEN];
> > -pthread_t thread_id = pthread_self();
> > -unsigned int lcore_id;
> > int ret;
> >
> > -/* retrieve our lcore_id from the configuration structure */
> > -RTE_LCORE_FOREACH_WORKER(lcore_id) {
> > -if (thread_id == lcore_config[lcore_id].thread_id)
> > -break;
> > -}
> > -if (lcore_id == RTE_MAX_LCORE)
> > -rte_panic("cannot retrieve lcore id\n");
> > -
> > __rte_thread_init(lcore_id, &lcore_config[lcore_id].cpuset);
> >
> > ret = eal_thread_dump_current_affinity(cpuset, sizeof(cpuset));
> > RTE_LOG(DEBUG, EAL, "lcore %u is ready (tid=%zx;cpuset=[%s%s])\n",
> > -lcore_id, (uintptr_t)thread_id, cpuset,
> > +lcore_id, (uintptr_t)pthread_self(), cpuset,
> > ret == 0 ? "" : "...");
> >
> > rte_eal_trace_thread_lcore_ready(lcore_id, cpuset);
> > diff --git a/lib/eal/common/eal_thread.h b/lib/eal/common/eal_thread.h
> > index b08dcf34b5..0fde33e70c 100644
> > --- a/lib/eal/common/eal_thread.h
> > +++ b/lib/eal/common/eal_thread.h
> > @@ -11,7 +11,7 @@
> > * basic loop of thread, called for each thread by eal_init().
> > *
> > * @p
Re: [PATCH] eal: factorize lcore main loop
On Fri, Mar 25, 2022 at 3:58 PM Thomas Monjalon wrote: > > > But seeing how this code has been there from day 1, I would not > > > request a backport. > > > > this looks better to me it ends up being a bit less code and it solves > > the problem in a general fashion for platforms including windows. > > > > on windows the implementation does run the start_routine before assigning > > thread which was addressed with this patch. (still not merged) > > http://patchwork.dpdk.org/project/dpdk/list/?series=22094 > > > > it's likely your patch will be merged before mine so when that happens > > i'll just quietly abandon mine. however if some desire exists for a > > backport the simpler patch i provided could be used. > > Your patch could be merged now that we start a new cycle. > What do you prefer? Is David's solution better? > In this case, should we reject your patch? We can merge Tyler fix right away because it is a real issue on Windows and it can be backported. My series can be rebased and merged later as a cleanup/unified solution for all OS. -- David Marchand
[PATCH v1] examples/l3fwd: merge l3fwd-acl into l3fwd
l3fwd-acl contains duplicate functions to l3fwd. For this reason we merge l3fwd-acl code into l3fwd with '--lookup acl' cmdline option to run ACL. Signed-off-by: Sean Morrissey --- examples/l3fwd-acl/Makefile | 51 - examples/l3fwd-acl/main.c | 2272 - examples/l3fwd-acl/meson.build| 13 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 39 +- examples/l3fwd/l3fwd_acl.c| 1123 ++ examples/l3fwd/l3fwd_acl.h| 120 ++ examples/l3fwd/l3fwd_acl_scalar.h | 160 ++ examples/l3fwd/l3fwd_route.h | 16 + examples/l3fwd/main.c | 97 +- examples/l3fwd/meson.build|3 +- examples/meson.build |1 - 12 files changed, 1545 insertions(+), 2352 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c delete mode 100644 examples/l3fwd-acl/meson.build create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h diff --git a/examples/l3fwd-acl/Makefile b/examples/l3fwd-acl/Makefile deleted file mode 100644 index 85fd2c47a1..00 --- a/examples/l3fwd-acl/Makefile +++ /dev/null @@ -1,51 +0,0 @@ -# SPDX-License-Identifier: BSD-3-Clause -# Copyright(c) 2010-2014 Intel Corporation - -# binary name -APP = l3fwd-acl - -# all source are stored in SRCS-y -SRCS-y := main.c - -PKGCONF ?= pkg-config - -# Build using pkg-config variables if possible -ifneq ($(shell $(PKGCONF) --exists libdpdk && echo 0),0) -$(error "no installation of DPDK found") -endif - -all: shared -.PHONY: shared static -shared: build/$(APP)-shared - ln -sf $(APP)-shared build/$(APP) -static: build/$(APP)-static - ln -sf $(APP)-static build/$(APP) - -PC_FILE := $(shell $(PKGCONF) --path libdpdk 2>/dev/null) -CFLAGS += -O3 $(shell $(PKGCONF) --cflags libdpdk) -LDFLAGS_SHARED = $(shell $(PKGCONF) --libs libdpdk) -LDFLAGS_STATIC = $(shell $(PKGCONF) --static --libs libdpdk) - -ifeq ($(MAKECMDGOALS),static) -# check for broken pkg-config -ifeq ($(shell echo $(LDFLAGS_STATIC) | grep 'whole-archive.*l:lib.*no-whole-archive'),) -$(warning "pkg-config output list does not contain drivers between 'whole-archive'/'no-whole-archive' flags.") -$(error "Cannot generate statically-linked binaries with this version of pkg-config") -endif -endif - -CFLAGS += -DALLOW_EXPERIMENTAL_API - -build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build - $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_SHARED) - -build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build - $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_STATIC) - -build: - @mkdir -p $@ - -.PHONY: clean -clean: - rm -f build/$(APP) build/$(APP)-static build/$(APP)-shared - test -d build && rmdir -p build || true diff --git a/examples/l3fwd-acl/main.c b/examples/l3fwd-acl/main.c deleted file mode 100644 index 2d2ecc7635..00 --- a/examples/l3fwd-acl/main.c +++ /dev/null @@ -1,2272 +0,0 @@ -/* SPDX-License-Identifier: BSD-3-Clause - * Copyright(c) 2010-2016 Intel Corporation - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include - -#if RTE_LOG_DP_LEVEL >= RTE_LOG_DEBUG -#define L3FWDACL_DEBUG -#endif -#define DO_RFC_1812_CHECKS - -#define RTE_LOGTYPE_L3FWD RTE_LOGTYPE_USER1 - -#define MAX_JUMBO_PKT_LEN 9600 - -#define MEMPOOL_CACHE_SIZE 256 - -/* - * This expression is used to calculate the number of mbufs needed - * depending on user input, taking into account memory for rx and tx hardware - * rings, cache per lcore and mtable per port per lcore. - * RTE_MAX is used to ensure that NB_MBUF never goes below a - * minimum value of 8192 - */ - -#define NB_MBUFRTE_MAX(\ - (nb_ports * nb_rx_queue * nb_rxd + \ - nb_ports * nb_lcores * MAX_PKT_BURST + \ - nb_ports * n_tx_queue * nb_txd +\ - nb_lcores * MEMPOOL_CACHE_SIZE),\ - (unsigned)8192) - -#define MAX_PKT_BURST 32 -#define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */ - -#define NB_SOCKETS 8 - -/* Configure how many packets ahead to prefetch, when reading packets */ -#define PREFETCH_OFFSET3 - -/* - * Configurable number of RX/TX ring descriptors - */ -#define RTE_TEST_RX_DESC_DEFAULT 1024 -#define RTE_TEST_TX_DESC_DEFAULT 1024 -static uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT; -static uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT; - -/* mask of enabled ports */ -static uint32_t enabled_port_mask; -static int promiscuous_on; /**< Ports set in promiscuous mode off by default. */ -static int numa_on =
[PATCH] net/tap: Fixed RSS algorithm to support fragmented packets
From: Madhuker Mythri
As per analysis on DPDK Tap PMD, the existing RSS algorithm considering
4-tuple(Src-IP, Dst-IP, Src-port and Dst-port) and identification of fragment
packets is not done, thus we are seeing all the fragmented chunks of single
packet differs RSS hash value and distributed across multiple queues.
The RSS algorithm assumes that, all the incoming IP packets are based on
L4-protocol(UDP/TCP) and trying to fetch the L4 fields(Src-port and Dst-port)
for each incoming packet, but for the fragmented packets these L4-header will
not be present(except for first packet) and should not consider in RSS hash for
L4 header fields in-case of fragmented packets.
Which is a bug in the RSS algorithm implemented in the BPF functionality under
TAP PMD.
So, modified the RSS eBPF C-program and generated the structure of C-array in
the 'tap_bpf_insns.h' file, which is in eBPF byte-code instructions format.
Bugzilla Id: 870
Signed-off-by: Madhuker Mythri
---
drivers/net/tap/tap_bpf_insns.h | 3371 +++--
drivers/net/tap/tap_bpf_program.c | 48 +-
2 files changed, 1743 insertions(+), 1676 deletions(-)
diff --git a/drivers/net/tap/tap_bpf_insns.h b/drivers/net/tap/tap_bpf_insns.h
index 1a91bbad13..1ced9d3f0c 100644
--- a/drivers/net/tap/tap_bpf_insns.h
+++ b/drivers/net/tap/tap_bpf_insns.h
@@ -25,1672 +25,1707 @@ static struct bpf_insn cls_q_insns[] = {
/* bpf_insn array matching l3_l4 section. see tap_bpf_program.c file */
static struct bpf_insn l3_l4_hash_insns[] = {
- {0xbf,7,1,0, 0x},
- {0x61,8,7, 16, 0x},
- {0x61,6,7, 76, 0x},
- {0x61,9,7, 80, 0x},
- {0x18,1,0,0, 0xdeadbeef},
- {0x00,0,0,0, 0x},
- {0x63, 10,1, -4, 0x},
- {0xbf,2, 10,0, 0x},
- {0x07,2,0,0, 0xfffc},
- {0x18,1,1,0, 0xcafe},
- {0x00,0,0,0, 0x},
- {0x85,0,0,0, 0x0001},
- {0x55,0,0, 21, 0x},
- {0xb7,1,0,0, 0x0a64},
- {0x6b, 10,1, -16, 0x},
- {0x18,1,0,0, 0x69666e6f},
- {0x00,0,0,0, 0x65727567},
- {0x7b, 10,1, -24, 0x},
- {0x18,1,0,0, 0x6e207369},
- {0x00,0,0,0, 0x6320746f},
- {0x7b, 10,1, -32, 0x},
- {0x18,1,0,0, 0x20737372},
- {0x00,0,0,0, 0x2079656b},
- {0x7b, 10,1, -40, 0x},
- {0x18,1,0,0, 0x68736168},
- {0x00,0,0,0, 0x203a2928},
- {0x7b, 10,1, -48, 0x},
- {0xb7,7,0,0, 0x},
- {0x73, 10,7, -14, 0x},
- {0xbf,1, 10,0, 0x},
- {0x07,1,0,0, 0xffd0},
- {0xb7,2,0,0, 0x0023},
- {0x85,0,0,0, 0x0006},
- {0x05,0,0, 1632, 0x},
- {0xb7,1,0,0, 0x000e},
- {0x61,2,7, 20, 0x},
- {0x15,2,0, 10, 0x},
- {0x61,2,7, 28, 0x},
- {0x55,2,0,8, 0xa888},
- {0xbf,2,7,0, 0x},
- {0xb7,7,0,0, 0x},
- {0xbf,1,6,0, 0x},
- {0x07,1,0,0, 0x0012},
- {0x2d,1,9, 1622, 0x},
- {0xb7,1,0,0, 0x0012},
- {0x69,8,6, 16, 0x},
- {0xbf,7,2,0, 0x},
- {0x7b, 10,7, -56, 0x},
- {0x57,8,0,0, 0x},
- {0x15,8,0, 409, 0xdd86},
- {0xb7,7,0,0, 0x0003},
- {0x55,8,0, 1614, 0x0008},
- {0x0f,6,1,0, 0x},
- {0xb7,7,0,0, 0x},
- {0xbf,1,6,0, 0x},
- {0x07,1,0,0, 0x0018},
- {0x2d,1,9, 1609, 0x},
- {0x71,3,6, 12, 0x},
- {0xbf,1,3,0, 0x},
- {0x67,1,0,0, 0x0038},
- {0xc7,1,0,0, 0x0020},
- {0x77,1,0,0, 0x001f},
- {0x57,1,0,0, 0x2cc681d1},
- {0x67,3,0,0, 0x0018},
- {0xbf,4,3,0, 0x},
- {0x57,4,0,0, 0x4000},
- {0xb7,2,0,0, 0x},
- {0x1d,4,2,1, 0x},
- {0xa7,1,0,0, 0x598d03a2},
- {0xbf
[Bug 983] [21.11] net/mlx5: increase in number of required hugepages
https://bugs.dpdk.org/show_bug.cgi?id=983
Bug ID: 983
Summary: [21.11] net/mlx5: increase in number of required
hugepages
Product: DPDK
Version: 21.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: tudor.cor...@gmail.com
Target Milestone: future
Greetings,
I'm developing a DPDK application, and recently I've found myself in the need
to upgrade from version 20.11 to version 21.11.
I noticed that when I use a ConnectX-6 NIC in PCI-Passthrough mode it seems to
require me to allocate a few extra hugepages. I have not seen this behavior
when I use the NIC in SR-IOV mode, or with other existing drivers. I've not
seen this in version 20.11.
I think I may have managed to reproduce the same behavior using dpdk-testpmd.
I am using 2 MB hugepages on my local setup.
DPDK 20.11 - Mlx5 Driver
NR_HUGEPAGES=200
mount -p /mnt/hugepages
mount -t hugetlbfs hugetlbfs /mnt/hugepages
sysctl vm.nr_hugepages="${NR_NUGEPAGES}"
./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 1-4 --log-level=.*,8
DPDK 21.11 - Mlx5 Driver
NR_HUGEPAGES=220
mount -p /mnt/hugepages
mount -t hugetlbfs hugetlbfs /mnt/hugepages
sysctl vm.nr_hugepages="${NR_NUGEPAGES}"
./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 1-4 --log-level=.*,8
It seems that starting with DPDK 21.11, I have to allocate an extra 20
hugepages, otherwise the driver fails in allocating the mbuf pool.
testpmd: create a new mbuf pool : n=171456, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc
EAL: Error - exiting with code: 1
Cause: Creation of mbuf pool for socket 0 failed: Cannot allocate memory
I am trying to keep the number of used hugepages to a minimum, and I was
curious if something changed in the new driver that could determine it to
require more hugepages when managing a PF. I've tried to look at the PMD guide
[1] and then at the code, but I haven't really found anything yet which could
help me explain the increase.
The NIC that I'm using is the following:
00:04.0 Ethernet controller: Mellanox Technologies MT28908 Family [ConnectX-6]
OS Distribution: Ubuntu 20.04
[1] https://doc.dpdk.org/guides-21.11/nics/mlx5.html?highlight=mlx5
--
You are receiving this mail because:
You are the assignee for the bug.
Re: DPDK for Windows with MSVC compiler
On Fri, Mar 25, 2022 at 01:25:51PM +, Dmitry Kozlyuk wrote: > > Is there a way to integrate DPDK module, built with clang/mingw, to our > > MSVC application ? > > I know both are different compilers, but in case if you are aware of a > > way/tweak that will be of our help. > > OR > > If porting our application is the only option available then which > > compiler (clang or mingw) is recommended for optimal performance. > > DPDK headers are incompatible with MSVC > due to heavy use of extensions common to GCC, clang, and ICC. > DPDK libraries can be linked trivially. > If your app cannot be easily recompiled with clang, > I think the best way is to use two compilers: > compile the module that interfaces DPDK with clang > and the rest of the app with MSVC, > link DPDK libraries as any other external libraries. > Note that DPDK installation on Windows is not fully functional yet: > it does not install pthread.h which you can find in lib/eal/windows/include. > > +Tyler who might have relevant experience. while you could compile dpdk with clang and your application with msvc it is non-trivial and i would strongly advise against it. you'll spend more effort on maintaining the dpdk fork you have to create than it will take to improve your applications code to be more compiler agnostic. i would advise you to port your application to clang and when doing so use as much standard c as possible as opposed to compiler builtins or intrinsics and abstracting when standards don't provide common facilities. the desire to use msvc has been expressed by multiple dpdk community members both directly to microsoft and on the community mailing lists. microsoft is aware of the interest in using msvc and discussions are ongoing about how to best service the community members interested. thanks
Re: [PATCH] eal: factorize lcore main loop
On Fri, Mar 25, 2022 at 04:09:50PM +0100, David Marchand wrote: > On Fri, Mar 25, 2022 at 3:58 PM Thomas Monjalon wrote: > > > > But seeing how this code has been there from day 1, I would not > > > > request a backport. > > > > > > this looks better to me it ends up being a bit less code and it solves > > > the problem in a general fashion for platforms including windows. > > > > > > on windows the implementation does run the start_routine before assigning > > > thread which was addressed with this patch. (still not merged) > > > http://patchwork.dpdk.org/project/dpdk/list/?series=22094 > > > > > > it's likely your patch will be merged before mine so when that happens > > > i'll just quietly abandon mine. however if some desire exists for a > > > backport the simpler patch i provided could be used. > > > > Your patch could be merged now that we start a new cycle. > > What do you prefer? Is David's solution better? > > In this case, should we reject your patch? > > We can merge Tyler fix right away because it is a real issue on > Windows and it can be backported. > > My series can be rebased and merged later as a cleanup/unified > solution for all OS. sounds about right to me. no objection here. > > > -- > David Marchand
[RFC] eal: add seqlock
A sequence lock (seqlock) is synchronization primitive which allows
for data-race free, low-overhead, high-frequency reads, especially for
data structures shared across many cores and which are updated with
relatively low frequency.
A seqlock permits multiple parallel readers. The variant of seqlock
implemented in this patch supports multiple writers as well. A
spinlock is used for writer-writer serialization.
To avoid resource reclamation and other issues, the data protected by
a seqlock is best off being self-contained (i.e., no pointers [except
to constant data]).
One way to think about seqlocks is that they provide means to perform
atomic operations on data objects larger what the native atomic
machine instructions allow for.
DPDK seqlocks are not preemption safe on the writer side. A thread
preemption affects performance, not correctness.
A seqlock contains a sequence number, which can be thought of as the
generation of the data it protects.
A reader will
1. Load the sequence number (sn).
2. Load, in arbitrary order, the seqlock-protected data.
3. Load the sn again.
4. Check if the first and second sn are equal, and even numbered.
If they are not, discard the loaded data, and restart from 1.
The first three steps need to be ordered using suitable memory fences.
A writer will
1. Take the spinlock, to serialize writer access.
2. Load the sn.
3. Store the original sn + 1 as the new sn.
4. Perform load and stores to the seqlock-protected data.
5. Store the original sn + 2 as the new sn.
6. Release the spinlock.
Proper memory fencing is required to make sure the first sn store, the
data stores, and the second sn store appear to the reader in the
mentioned order.
The sn loads and stores must be atomic, but the data loads and stores
need not be.
The original seqlock design and implementation was done by Stephen
Hemminger. This is an independent implementation, using C11 atomics.
This RFC version lacks API documentation.
Reviewed-by: Ola Liljedahl
Signed-off-by: Mattias Rönnblom
---
app/test/meson.build | 2 +
app/test/test_seqlock.c | 197 ++
lib/eal/common/meson.build| 1 +
lib/eal/common/rte_seqlock.c | 12 +++
lib/eal/include/meson.build | 1 +
lib/eal/include/rte_seqlock.h | 84 +++
lib/eal/version.map | 3 +
7 files changed, 300 insertions(+)
create mode 100644 app/test/test_seqlock.c
create mode 100644 lib/eal/common/rte_seqlock.c
create mode 100644 lib/eal/include/rte_seqlock.h
diff --git a/app/test/meson.build b/app/test/meson.build
index 5fc1dd1b7b..5e418e8766 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -125,6 +125,7 @@ test_sources = files(
'test_rwlock.c',
'test_sched.c',
'test_security.c',
+'test_seqlock.c',
'test_service_cores.c',
'test_spinlock.c',
'test_stack.c',
@@ -214,6 +215,7 @@ fast_tests = [
['rwlock_rde_wro_autotest', true],
['sched_autotest', true],
['security_autotest', false],
+['seqlock_autotest', true],
['spinlock_autotest', true],
['stack_autotest', false],
['stack_lf_autotest', false],
diff --git a/app/test/test_seqlock.c b/app/test/test_seqlock.c
new file mode 100644
index 00..a727e16caf
--- /dev/null
+++ b/app/test/test_seqlock.c
@@ -0,0 +1,197 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Ericsson AB
+ */
+
+#include
+
+#include
+#include
+#include
+
+#include
+
+#include "test.h"
+
+struct data {
+ rte_seqlock_t lock;
+
+ uint64_t a;
+ uint64_t b __rte_cache_aligned;
+ uint64_t c __rte_cache_aligned;
+} __rte_cache_aligned;
+
+struct reader {
+ struct data *data;
+ uint8_t stop;
+};
+
+#define WRITER_RUNTIME (2.0) /* s */
+
+#define WRITER_MAX_DELAY (100) /* us */
+
+#define INTERRUPTED_WRITER_FREQUENCY (1000)
+#define WRITER_INTERRUPT_TIME (1) /* us */
+
+static int
+writer_start(void *arg)
+{
+ struct data *data = arg;
+ uint64_t deadline;
+
+ deadline = rte_get_timer_cycles() +
+ WRITER_RUNTIME * rte_get_timer_hz();
+
+ while (rte_get_timer_cycles() < deadline) {
+ bool interrupted;
+ uint64_t new_value;
+ unsigned int delay;
+
+ new_value = rte_rand();
+
+ interrupted = rte_rand_max(INTERRUPTED_WRITER_FREQUENCY) == 0;
+
+ rte_seqlock_write_begin(&data->lock);
+
+ data->c = new_value;
+
+ /* These compiler barriers (both on the test reader
+* and the test writer side) are here to ensure that
+* loads/stores *usually* happen in test program order
+* (always on a TSO machine). They are arrange in such
+* a way that the writer stores in a different order
+* than the reader loads, to emulate an arbitrary
+
Re: [RFC] eal: add seqlock
On Fri, 25 Mar 2022 21:24:28 +0100
Mattias Rönnblom wrote:
> diff --git a/lib/eal/include/rte_seqlock.h b/lib/eal/include/rte_seqlock.h
> new file mode 100644
> index 00..b975ca848a
> --- /dev/null
> +++ b/lib/eal/include/rte_seqlock.h
> @@ -0,0 +1,84 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2022 Ericsson AB
> + */
> +
> +#ifndef _RTE_SEQLOCK_H_
> +#define _RTE_SEQLOCK_H_
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +struct rte_seqlock {
> + uint64_t sn;
> + rte_spinlock_t lock;
> +};
> +
> +typedef struct rte_seqlock rte_seqlock_t;
> +
Add a reference to Wikipedia and/or Linux since not every DPDK
user maybe familar with this.
> +
> + sn = seqlock->sn + 1;
> +
> + __atomic_store_n(&seqlock->sn, sn, __ATOMIC_RELAXED);
> +
> + /* __ATOMIC_RELEASE to prevent stores after (in program order)
> + * from happening before the sn store.
> + */
> + rte_atomic_thread_fence(__ATOMIC_RELEASE);
Could this just be __atomic_fetch_add() with __ATOMIC_RELEASE?
[PATCH] meson: update doc logic for Windows
Support for shell scripts doxy-html-custom, generate_doxygen and
generate_examples are absent. The current patch address the same by
disabling document build notifying the user.
Steps to reproduce the error:
- Install dependencies doxygen & sphinix build on Windwos server 2019.
- Build DPDK with option enable_docs=true for API or User Guide.
This produces error
```
FAILED: doc/api/examples.dox
sh -e dpdk/doc/api/generate_examples.sh dpdk/examples doc/api/examples.dox
```
Signed-off-by: Vipin Varghese
---
doc/meson.build | 8
1 file changed, 8 insertions(+)
diff --git a/doc/meson.build b/doc/meson.build
index 6f74706aa2..d7c35a12f2 100644
--- a/doc/meson.build
+++ b/doc/meson.build
@@ -3,6 +3,14 @@
doc_targets = []
doc_target_names = []
+
+if is_windows
+if get_option('enable_docs')
+message('Docs target not supported on windows')
+endif
+subdir_done()
+endif
+
subdir('api')
subdir('guides')
--
2.25.1
