From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 84069A04DB;
	Tue, 17 Nov 2020 13:06:56 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 6479237B1;
	Tue, 17 Nov 2020 13:06:55 +0100 (CET)
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id DACA137B0
 for <dev@dpdk.org>; Tue, 17 Nov 2020 13:06:53 +0100 (CET)
IronPort-SDR: F8XWVWvU1U+v/a/EsnHxppavTYHLpD1iORA1Ld8Ex/5GQgEubuTTVJsivN7xEJZFoa5YFxMWpq
 93Oj7h/Fhomw==
X-IronPort-AV: E=McAfee;i="6000,8403,9807"; a="188966034"
X-IronPort-AV: E=Sophos;i="5.77,485,1596524400"; d="scan'208";a="188966034"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga004.fm.intel.com ([10.253.24.48])
 by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 17 Nov 2020 04:06:51 -0800
IronPort-SDR: jAi6ZdzpPlGlL9LMeOpnmP5uQIxiH6DhhkSXwh3oql8Y+U0Kyern/4PIVgYWblZCJgOxSd76WG
 /Oz1B+1hsK1A==
X-IronPort-AV: E=Sophos;i="5.77,485,1596524400"; d="scan'208";a="358867786"
Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.210.196])
 ([10.213.210.196])
 by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 17 Nov 2020 04:06:49 -0800
To: Jiawei Wang <jiaweiw@nvidia.com>, wenzhuo.lu@intel.com,
 beilei.xing@intel.com, bernard.iremonger@intel.com, orika@nvidia.com,
 thomas@monjalon.net, rasland@nvidia.com
Cc: dev@dpdk.org
References: <1605170202-293829-1-git-send-email-jiaweiw@nvidia.com>
 <1605355308-427475-1-git-send-email-jiaweiw@nvidia.com>
From: Ferruh Yigit <ferruh.yigit@intel.com>
Message-ID: <d897c390-0199-d525-3fb5-724ab26a2c4b@intel.com>
Date: Tue, 17 Nov 2020 12:06:46 +0000
MIME-Version: 1.0
In-Reply-To: <1605355308-427475-1-git-send-email-jiaweiw@nvidia.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [dpdk-dev] [PATCH v2] app/testpmd: fix testpmd packets dump
 overlapping
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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 <jiaweiw@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'?

<...>

> @@ -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:");

> +			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.

<...>

> +		if (cur_len >= buf_size)
> +			goto error;
> +		TESTPMD_LOG(INFO, "%s", print_buf);

Using 'TESTPMD_LOG' appends "testpmd: " at the beggining of the each line, for 
this case it is noise I think, what do you think turning back to printf() as 
done originally?

> +		cur_len = 0;
>   	}
> +	return;
> +error:
> +	TESTPMD_LOG(INFO, "%s the output was truncated ...\n", print_buf);

What do you think having something shorter to notify the truncation, I think 
some special chars can work better, something like "...", "@@", "-->", "???" ?

>   }
>   
>   uint16_t
>