On 11/18/2020 6:09 PM, Jiawei(Jonny) Wang wrote:
Hi Ferruh,
-----Original Message-----
From: Ferruh Yigit <ferruh.yi...@intel.com>
Sent: Tuesday, November 17, 2020 8:07 PM
To: Jiawei(Jonny) Wang <jiaw...@nvidia.com>; wenzhuo...@intel.com;
beilei.x...@intel.com; bernard.iremon...@intel.com; Ori Kam
<or...@nvidia.com>; NBU-Contact-Thomas Monjalon
<tho...@monjalon.net>; Raslan Darawsheh <rasl...@nvidia.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] app/testpmd: fix testpmd packets dump
overlapping
On 11/14/2020 12:01 PM, Jiawei Wang wrote:
When testpmd enabled the verbosity for the received packets, if two
packets was received at the same time, for example, sampling packet
and normal packet, the dump output of these packets may be overlapping
due to multiple core handled the multiple queues simultaneously.
The patch uses one string buffer that collects all the packet dump
output into this buffer and then printout it at last, that guarantee
to printout separately the dump output per packet.
Fixes: d862c45 ("app/testpmd: move dumping packets to a separate
function")
Signed-off-by: Jiawei Wang <jiaw...@nvidia.com>
---
v2:
* Print dump output of per packet instead of per burst.
* Add the checking for return value of 'snprintf' and exit if required size
exceed the print buffer size.
* Update the log messages.
---
app/test-pmd/util.c | 378
++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 295 insertions(+), 83 deletions(-)
diff --git a/app/test-pmd/util.c b/app/test-pmd/util.c index
649bf8f..ffae590 100644
--- a/app/test-pmd/util.c
+++ b/app/test-pmd/util.c
@@ -12,15 +12,20 @@
#include <rte_vxlan.h>
#include <rte_ethdev.h>
#include <rte_flow.h>
+#include <rte_log.h>
#include "testpmd.h"
-static inline void
-print_ether_addr(const char *what, const struct rte_ether_addr
*eth_addr)
+#define MAX_STRING_LEN 8192
Isn't '8192' too large for a single packet, what do you think for '2048'?
2K is ok for the normal case, here consider the case that registered mbuf
dynamic flags names,
Then total maximum length can reach to 64* RTE_MBUF_DYN_NAMESIZE = 4096
// char dynf_names[64][RTE_MBUF_DYN_NAMESIZE];
So 2048 is not enough if all dynf_names be configured as maximum length of
dyn_names.
How about the 5K? I think should be enough for now.
OK, and no need to be tight, if there are cases requesting longer string perhaps
can keep the size as it is.
<...>
@@ -93,95 +103,269 @@
is_encapsulation = RTE_ETH_IS_TUNNEL_PKT(packet_type);
ret = rte_flow_get_restore_info(port_id, mb, &info, &error);
if (!ret) {
- printf("restore info:");
+ cur_len += snprintf(print_buf + cur_len,
+ buf_size - cur_len,
+ "restore info:");
What do you think having a macro like below to simplfy the code:
#define FOO(buf, buf_size, cur_len, ...) \
do { \
if (cur_len >= buf_size) break; \
cur_len += snprintf(buf + cur_len, buf_size - cur_len, __VA_ARGS__); \
} while (0)
It can be used as:
FOO(print_buf, buf_size, cur_len, "restore info:");
Agree, will move these common code into a MARCO,
I will use the "MKDUMPSTR" as MARCO name, means that making a dump string
buffer.
Ack
+ if (cur_len >= buf_size)
+ goto error;
This 'goto' goes out of the loop, not sure about breking the loop and not
processing all packets if buffer is out of space for one of the packets.
Anyway if you switch to macro above, the 'goto' is removed completely.
Use 'break' only break the do{} while and continue to following processing, but
won't filled anymore into printbuf since it will break firstly in the MARCO
checking.
Or could use 'goto lable' instead 'break' in the marco?
I think cleaner to not have the 'goto', yes processing will continue but no
space left case expected to happen very rare.
