[PATCH] [v2]lib/telemetry:fix telemetry conns leak in case of socket write fail
Telemetry can only create 10 conns by default, each of which is processed
by a thread.
When a thread fails to write using socket, the thread will end directly
without reducing the total number of conns.
This will result in the machine running for a long time, and if there are
10 failures, the telemetry will be unavailable
Fixes: 6dd571fd07c3 ("telemetry: introduce new functionality")
Signed-off-by: Shaowei Sun <1819846...@qq.com>
---
lib/telemetry/telemetry.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
index 31e2391867..0b00c04090 100644
--- a/lib/telemetry/telemetry.c
+++ b/lib/telemetry/telemetry.c
@@ -378,8 +378,8 @@ client_handler(void *sock_id)
"{\"version\":\"%s\",\"pid\":%d,\"max_output_len\":%d}",
telemetry_version, getpid(), MAX_OUTPUT_LEN);
if (write(s, info_str, strlen(info_str)) < 0) {
- close(s);
- return NULL;
+ TMTY_LOG_LINE(ERR, "Socket write base info to client failed");
+ goto exit;
}
/* receive data is not null terminated */
@@ -404,6 +404,7 @@ client_handler(void *sock_id)
bytes = read(s, buffer, sizeof(buffer) - 1);
}
+exit:
close(s);
rte_atomic_fetch_sub_explicit(&v2_clients, 1, rte_memory_order_relaxed);
return NULL;
--
2.37.1 (Apple Git-137.1)
[PATCH] [v2]lib/telemetry:fix telemetry conns leak in case of socket write fail
Telemetry can only create 10 conns by default, each of which is processed
by a thread.
When a thread fails to write using socket, the thread will end directly
without reducing the total number of conns.
This will result in the machine running for a long time, and if there are
10 failures, the telemetry will be unavailable
Fixes: 6dd571fd07c3 ("telemetry: introduce new functionality")
Signed-off-by: Shaowei Sun <1819846...@qq.com>
---
lib/telemetry/telemetry.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
index 31e2391867..0b00c04090 100644
--- a/lib/telemetry/telemetry.c
+++ b/lib/telemetry/telemetry.c
@@ -378,8 +378,8 @@ client_handler(void *sock_id)
"{\"version\":\"%s\",\"pid\":%d,\"max_output_len\":%d}",
telemetry_version, getpid(), MAX_OUTPUT_LEN);
if (write(s, info_str, strlen(info_str)) < 0) {
- close(s);
- return NULL;
+ TMTY_LOG_LINE(ERR, "Socket write base info to client failed");
+ goto exit;
}
/* receive data is not null terminated */
@@ -404,6 +404,7 @@ client_handler(void *sock_id)
bytes = read(s, buffer, sizeof(buffer) - 1);
}
+exit:
close(s);
rte_atomic_fetch_sub_explicit(&v2_clients, 1, rte_memory_order_relaxed);
return NULL;
--
2.37.1 (Apple Git-137.1)
[PATCH] [v2]lib/telemetry:fix telemetry conns leak in case of socket write fail
Telemetry can only create 10 conns by default, each of which is processed
by a thread.
When a thread fails to write using socket, the thread will end directly
without reducing the total number of conns.
This will result in the machine running for a long time, and if there are
10 failures, the telemetry will be unavailable
Fixes: 6dd571fd07c3 ("telemetry: introduce new functionality")
Signed-off-by: Shaowei Sun <1819846...@qq.com>
---
lib/telemetry/telemetry.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
index 31e2391867..0b00c04090 100644
--- a/lib/telemetry/telemetry.c
+++ b/lib/telemetry/telemetry.c
@@ -378,8 +378,8 @@ client_handler(void *sock_id)
"{\"version\":\"%s\",\"pid\":%d,\"max_output_len\":%d}",
telemetry_version, getpid(), MAX_OUTPUT_LEN);
if (write(s, info_str, strlen(info_str)) < 0) {
- close(s);
- return NULL;
+ TMTY_LOG_LINE(ERR, "Socket write base info to client failed");
+ goto exit;
}
/* receive data is not null terminated */
@@ -404,6 +404,7 @@ client_handler(void *sock_id)
bytes = read(s, buffer, sizeof(buffer) - 1);
}
+exit:
close(s);
rte_atomic_fetch_sub_explicit(&v2_clients, 1, rte_memory_order_relaxed);
return NULL;
--
2.37.1 (Apple Git-137.1)
[PATCH] mempool: test performance with larger bursts
Bursts of up to 128 packets are not uncommon, so increase the maximum
tested get and put burst sizes from 32 to 128.
Some applications keep more than 512 objects, so increase the maximum
number of kept objects from 512 to 4096.
This exceeds the typical mempool cache size of 512 objects, so the test
also exercises the mempool driver.
Signed-off-by: Morten Brørup
---
app/test/test_mempool_perf.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/app/test/test_mempool_perf.c b/app/test/test_mempool_perf.c
index 96de347f04..f52106e833 100644
--- a/app/test/test_mempool_perf.c
+++ b/app/test/test_mempool_perf.c
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2010-2014 Intel Corporation
- * Copyright(c) 2022 SmartShare Systems
+ * Copyright(c) 2022-2024 SmartShare Systems
*/
#include
@@ -54,22 +54,24 @@
*
*- Bulk size (*n_get_bulk*, *n_put_bulk*)
*
- * - Bulk get from 1 to 32
- * - Bulk put from 1 to 32
- * - Bulk get and put from 1 to 32, compile time constant
+ * - Bulk get from 1 to 128
+ * - Bulk put from 1 to 128
+ * - Bulk get and put from 1 to 128, compile time constant
*
*- Number of kept objects (*n_keep*)
*
* - 32
* - 128
* - 512
+ * - 1024
+ * - 4096
*/
#define N 65536
#define TIME_S 5
#define MEMPOOL_ELT_SIZE 2048
-#define MAX_KEEP 512
-#define MEMPOOL_SIZE
((rte_lcore_count()*(MAX_KEEP+RTE_MEMPOOL_CACHE_MAX_SIZE))-1)
+#define MAX_KEEP 4096
+#define MEMPOOL_SIZE
((rte_lcore_count()*(MAX_KEEP+RTE_MEMPOOL_CACHE_MAX_SIZE*2))-1)
/* Number of pointers fitting into one cache line. */
#define CACHE_LINE_BURST (RTE_CACHE_LINE_SIZE / sizeof(uintptr_t))
@@ -204,6 +206,8 @@ per_lcore_mempool_test(void *arg)
CACHE_LINE_BURST, CACHE_LINE_BURST);
else if (n_get_bulk == 32)
ret = test_loop(mp, cache, n_keep, 32, 32);
+ else if (n_get_bulk == 128)
+ ret = test_loop(mp, cache, n_keep, 128, 128);
else
ret = -1;
@@ -289,9 +293,9 @@ launch_cores(struct rte_mempool *mp, unsigned int cores)
static int
do_one_mempool_test(struct rte_mempool *mp, unsigned int cores)
{
- unsigned int bulk_tab_get[] = { 1, 4, CACHE_LINE_BURST, 32, 0 };
- unsigned int bulk_tab_put[] = { 1, 4, CACHE_LINE_BURST, 32, 0 };
- unsigned int keep_tab[] = { 32, 128, 512, 0 };
+ unsigned int bulk_tab_get[] = { 1, 4, CACHE_LINE_BURST, 32, 128, 0 };
+ unsigned int bulk_tab_put[] = { 1, 4, CACHE_LINE_BURST, 32, 128, 0 };
+ unsigned int keep_tab[] = { 32, 128, 512, 1024, 4096, 0 };
unsigned *get_bulk_ptr;
unsigned *put_bulk_ptr;
unsigned *keep_ptr;
@@ -301,6 +305,9 @@ do_one_mempool_test(struct rte_mempool *mp, unsigned int
cores)
for (put_bulk_ptr = bulk_tab_put; *put_bulk_ptr;
put_bulk_ptr++) {
for (keep_ptr = keep_tab; *keep_ptr; keep_ptr++) {
+ if (*keep_ptr < *get_bulk_ptr || *keep_ptr <
*put_bulk_ptr)
+ continue;
+
use_constant_values = 0;
n_get_bulk = *get_bulk_ptr;
n_put_bulk = *put_bulk_ptr;
--
2.17.1
[RFC] mbuf: performance optimization
What is the largest realistic value of mbuf->priv_size (the size of an mbuf's application private data area) in any use case? I am wondering if its size could be reduced from 16 to 8 bit. If a max value of 255 isn't enough, then perhaps by knowing that the private data area must be aligned by 8 (RTE_MBUF_PRIV_ALIGN), its value can hold the size divided by 8. That would make the max value nearly 2 KB. I suppose that reducing mbuf->nb_segs from 16 to 8 bit is realistic, considering that a maximum size IP packet (64 KB) is unlikely to use more than 64 plus some segments. Does anyone know of any use case with more than 255 segments in an mbuf? These two changes would allow us to move mbuf->priv_size from the second to the first cache line. Furthermore, mbuf->timesync should be a dynamic field. This, along with the above changes, would give us one more available 32-bit dynamic field. Med venlig hilsen / Kind regards, -Morten Brørup
