[dpdk-dev] [PATCH v1 00/17] introduce global debug flag

[dpdk-dev] [PATCH v1 00/17] introduce global debug flag

[Lukasz Wojciechowski]

This set of patches introduces a global debug flag for dpdk.
This will allow easy switch to debug build configuration using a single
flag. In the debug mode a RTE_DEBUG macro is defined to 1
and can be used to place a debug code inside #ifdef #endif clauses.

It should be used for enabling debug code in all dpdk project
components. Using this flag allows to make additional checks or tests
and provide additional logs even in performance sensitive parts of code.

The build system a built-in meson "debug" flag to switch to debug build.


The set of patches introduces the global debug flag and replaces library
debug flags. It is split to many small patches for easier review
as it affects almost all libraries. Before merge it can be squash into
larger patches (if preferred by maintainers).

As a next step I plan to prepare patches for drivers as well.


Lukasz Wojciechowski (17):
  config: introduce global debug flag
  config: remove unused config flags
  ethdev: replace library debug flag with global one
  eventdev: replace library debug flag with global one
  fib: replace library debug flag with global one
  cmdline: replace library debug flag with global one
  hash: replace library debug flag with global one
  ip_frag: replace library debug flag with global one
  lpm: replace library debug flag with global one
  mbuf: replace library debug flag with global one
  mempool: replace library debug flag with global one
  power: replace library debug flag with global one
  rcu: replace library debug flag with global one
  timer: replace library debug flag with global one
  vhost: replace library debug flag with global one
  eal: replace library debug flag with global one
  sched: replace library debug flag with global one

 app/test/test_lpm.c                           |  2 +-
 app/test/test_malloc.c                        |  4 ++--
 app/test/test_mbuf.c                          |  2 +-
 app/test/test_timer_secondary.c               |  2 +-
 config/common_base                            | 19 ------------------
 config/meson.build                            |  4 ++++
 .../prog_guide/env_abstraction_layer.rst      |  5 +++--
 .../prog_guide/ip_fragment_reassembly_lib.rst |  4 ++--
 doc/guides/prog_guide/mbuf_lib.rst            |  2 +-
 doc/guides/prog_guide/mempool_lib.rst         |  7 ++++---
 doc/guides/prog_guide/rcu_lib.rst             |  8 ++++----
 drivers/net/atlantic/atl_rxtx.c               |  2 +-
 drivers/net/e1000/em_rxtx.c                   |  2 +-
 drivers/net/e1000/igb_rxtx.c                  |  2 +-
 drivers/net/ena/ena_ethdev.c                  |  2 +-
 drivers/net/enic/enic_rxtx.c                  |  2 +-
 drivers/net/fm10k/fm10k_rxtx.c                |  2 +-
 drivers/net/hinic/hinic_pmd_tx.c              |  2 +-
 drivers/net/hns3/hns3_rxtx.c                  |  2 +-
 drivers/net/i40e/i40e_rxtx.c                  |  2 +-
 drivers/net/iavf/iavf_rxtx.c                  |  2 +-
 drivers/net/ice/ice_rxtx.c                    |  2 +-
 drivers/net/ixgbe/ixgbe_rxtx.c                |  2 +-
 drivers/net/qede/qede_rxtx.c                  |  4 ++--
 drivers/net/softnic/rte_eth_softnic.c         |  2 +-
 drivers/net/softnic/rte_eth_softnic_thread.c  |  2 +-
 drivers/net/virtio/virtio_rxtx.c              |  2 +-
 drivers/net/vmxnet3/vmxnet3_rxtx.c            |  2 +-
 lib/librte_cmdline/cmdline_cirbuf.h           |  2 +-
 lib/librte_cmdline/cmdline_parse.c            |  2 +-
 lib/librte_cmdline/cmdline_parse_num.c        |  2 +-
 lib/librte_eal/common/malloc_elem.c           |  2 +-
 lib/librte_eal/common/malloc_elem.h           |  4 ++--
 lib/librte_eal/common/rte_malloc.c            |  2 +-
 lib/librte_ethdev/rte_ethdev.h                | 16 +++++++--------
 .../rte_event_eth_tx_adapter.h                |  2 +-
 lib/librte_eventdev/rte_event_timer_adapter.c |  6 +++---
 lib/librte_eventdev/rte_event_timer_adapter.h |  6 +++---
 lib/librte_eventdev/rte_eventdev.h            |  4 ++--
 lib/librte_eventdev/rte_eventdev_pmd.h        |  2 +-
 lib/librte_fib/rte_fib.c                      |  2 +-
 lib/librte_fib/rte_fib6.c                     |  2 +-
 lib/librte_hash/rte_cuckoo_hash.h             |  4 ++--
 lib/librte_ip_frag/ip_frag_common.h           |  4 ++--
 lib/librte_lpm/rte_lpm.c                      |  2 +-
 lib/librte_lpm/rte_lpm.h                      |  2 +-
 lib/librte_mbuf/rte_mbuf.h                    |  6 +++---
 lib/librte_mempool/rte_mempool.c              | 16 +++++++--------
 lib/librte_mempool/rte_mempool.h              | 20 +++++++++----------
 lib/librte_net/rte_net.h                      |  4 ++--
 lib/librte_power/power_acpi_cpufreq.c         |  2 +-
 lib/librte_power/power_pstate_cpufreq.c       |  2 +-
 lib/librte_rcu/rte_rcu_qsbr.h                 | 16 +++++++--------
 lib/librte_sched/rte_sched.c                  | 10 +++++-----
 lib/librte_timer/rte_timer.c                  | 12 +++++------
 lib/librte_timer/rte_timer.h                  |  2 +-
 lib/librte_vhost/vhost.h                      |  2 +-
 lib/librte_vhost/vhost_crypto.c               |  2 +-
 lib/librte_vhost/vhost_user.c                 |  2 +-
 59 files changed, 122 insertions(+), 135 deletions(-)

-- 
2.17.1

[dpdk-dev] [PATCH v1 01/17] config: introduce global debug flag

[Lukasz Wojciechowski]

There already is a meson core option "debug". To enable this option
add -Ddebug=true to the meson command during setup or configuration
of the build environment.

By enabling this flag the globaly defined macro RTE_DEBUG becomes
defined. It should be used for enabling debug code in all dpdk project
components. Using this flag allows to make additional checks or tests
and provide additional logs even in performance sensitive parts of code.

The flag is disabled by default.

Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/meson.build | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/config/meson.build b/config/meson.build
index 58421342b..04909f922 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -176,6 +176,10 @@ endif
 # add -include rte_config to cflags
 add_project_arguments('-include', 'rte_config.h', language: 'c')
 
+if get_option('debug')
+	dpdk_conf.set('RTE_DEBUG', 1)
+endif
+
 # enable extra warnings and disable any unwanted warnings
 warning_flags = [
 	# -Wall is added by meson by default, so add -Wextra only
-- 
2.17.1

[dpdk-dev] [PATCH v1 02/17] config: remove unused config flags

[Lukasz Wojciechowski]

Following flags were still present in the common_base config,
but they were not used anywhere in the code:
* CONFIG_RTE_LIBRTE_ACL_DEBUG
* CONFIG_RTE_LIBRTE_NFP_DEBUG_TX
* CONFIG_RTE_LIBRTE_NFP_DEBUG_RX
* CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO_DEBUG

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/config/common_base b/config/common_base
index c31175f9d..c5be57f11 100644
--- a/config/common_base
+++ b/config/common_base
@@ -380,8 +380,6 @@ CONFIG_RTE_IBVERBS_LINK_STATIC=n
 # Compile burst-oriented Netronome NFP PMD driver
 #
 CONFIG_RTE_LIBRTE_NFP_PMD=n
-CONFIG_RTE_LIBRTE_NFP_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_NFP_DEBUG_RX=n
 
 # QLogic 10G/25G/40G/50G/100G PMD
 #
@@ -586,7 +584,6 @@ CONFIG_RTE_CRYPTO_MAX_DEVS=64
 # Compile PMD for ARMv8 Crypto device
 #
 CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO=n
-CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO_DEBUG=n
 
 #
 # Compile NXP CAAM JR crypto Driver
@@ -947,7 +944,6 @@ CONFIG_RTE_LIBRTE_LPM_DEBUG=n
 # Compile librte_acl
 #
 CONFIG_RTE_LIBRTE_ACL=y
-CONFIG_RTE_LIBRTE_ACL_DEBUG=n
 
 #
 # Compile librte_power
-- 
2.17.1

[dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_ETHDEV_DEBUG.
The old define is completely removed from source code and config.
The changes were applied also to all drivers using this flag.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base                           |  1 -
 drivers/net/atlantic/atl_rxtx.c              |  2 +-
 drivers/net/e1000/em_rxtx.c                  |  2 +-
 drivers/net/e1000/igb_rxtx.c                 |  2 +-
 drivers/net/ena/ena_ethdev.c                 |  2 +-
 drivers/net/enic/enic_rxtx.c                 |  2 +-
 drivers/net/fm10k/fm10k_rxtx.c               |  2 +-
 drivers/net/hinic/hinic_pmd_tx.c             |  2 +-
 drivers/net/hns3/hns3_rxtx.c                 |  2 +-
 drivers/net/i40e/i40e_rxtx.c                 |  2 +-
 drivers/net/iavf/iavf_rxtx.c                 |  2 +-
 drivers/net/ice/ice_rxtx.c                   |  2 +-
 drivers/net/ixgbe/ixgbe_rxtx.c               |  2 +-
 drivers/net/qede/qede_rxtx.c                 |  4 ++--
 drivers/net/softnic/rte_eth_softnic.c        |  2 +-
 drivers/net/softnic/rte_eth_softnic_thread.c |  2 +-
 drivers/net/virtio/virtio_rxtx.c             |  2 +-
 drivers/net/vmxnet3/vmxnet3_rxtx.c           |  2 +-
 lib/librte_ethdev/rte_ethdev.h               | 16 ++++++++--------
 lib/librte_net/rte_net.h                     |  4 ++--
 20 files changed, 28 insertions(+), 29 deletions(-)

diff --git a/config/common_base b/config/common_base
index c5be57f11..16a8f09b6 100644
--- a/config/common_base
+++ b/config/common_base
@@ -149,7 +149,6 @@ CONFIG_RTE_LIBRTE_KVARGS=y
 # Compile generic ethernet library
 #
 CONFIG_RTE_LIBRTE_ETHER=y
-CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
 CONFIG_RTE_MAX_ETHPORTS=32
 CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
 CONFIG_RTE_LIBRTE_IEEE1588=n
diff --git a/drivers/net/atlantic/atl_rxtx.c b/drivers/net/atlantic/atl_rxtx.c
index 449ffd454..eae54df22 100644
--- a/drivers/net/atlantic/atl_rxtx.c
+++ b/drivers/net/atlantic/atl_rxtx.c
@@ -821,7 +821,7 @@ atl_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts,
 			return i;
 		}
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/drivers/net/e1000/em_rxtx.c b/drivers/net/e1000/em_rxtx.c
index 49c53712a..c4083ff00 100644
--- a/drivers/net/e1000/em_rxtx.c
+++ b/drivers/net/e1000/em_rxtx.c
@@ -626,7 +626,7 @@ eth_em_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts,
 			return i;
 		}
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
index 684fa4ad8..6a78f26e6 100644
--- a/drivers/net/e1000/igb_rxtx.c
+++ b/drivers/net/e1000/igb_rxtx.c
@@ -641,7 +641,7 @@ eth_igb_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts,
 			return i;
 		}
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 665afee4f..b9855e91b 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -2145,7 +2145,7 @@ eth_ena_prep_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
 			return i;
 		}
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/drivers/net/enic/enic_rxtx.c b/drivers/net/enic/enic_rxtx.c
index 6a8718c08..c42d563b4 100644
--- a/drivers/net/enic/enic_rxtx.c
+++ b/drivers/net/enic/enic_rxtx.c
@@ -414,7 +414,7 @@ uint16_t enic_prep_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
 			rte_errno = ENOTSUP;
 			return i;
 		}
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index 4accaa2cd..43d773f08 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -710,7 +710,7 @@ fm10k_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts,
 			return i;
 		}
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/drivers/net/hinic/hinic_pmd_tx.c b/drivers/net/hinic/hinic_pmd_tx.c
index 64ec2c119..41d5a25b6 100644
--- a/drivers/net/hinic/hinic_pmd_tx.c
+++ b/drivers/net/hinic/hinic_pmd_tx.c
@@ -804,7 +804,7 @@ hinic_tx_offload_pkt_prepare(struct rte_mbuf *m,
 	    !(ol_flags & PKT_TX_TUNNEL_VXLAN))
 		return -ENOTSUP;
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	if (rte_validate_tx_offload(m) != 0)
 		return -EINVAL;
 #endif
diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index ec6d19f58..45aa64b70 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2296,7 +2296,7 @@ hns3_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts,
 			return i;
 		}
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 5e7c86ed8..282baf514 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -1499,7 +1499,7 @@ i40e_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts,
 			return i;
 		}
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index 85d9a8e3b..8122d35be 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -1689,7 +1689,7 @@ iavf_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts,
 			return i;
 		}
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index 1c9f31efd..fd8ed2573 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -3037,7 +3037,7 @@ ice_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts,
 			return i;
 		}
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 2e20e18c7..6964c4e52 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -992,7 +992,7 @@ ixgbe_prep_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
 			return i;
 		}
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
index b81788ca4..646eb2275 100644
--- a/drivers/net/qede/qede_rxtx.c
+++ b/drivers/net/qede/qede_rxtx.c
@@ -2156,7 +2156,7 @@ qede_xmit_prep_pkts(__rte_unused void *p_txq, struct rte_mbuf **tx_pkts,
 	uint64_t ol_flags;
 	struct rte_mbuf *m;
 	uint16_t i;
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	int ret;
 #endif
 
@@ -2196,7 +2196,7 @@ qede_xmit_prep_pkts(__rte_unused void *p_txq, struct rte_mbuf **tx_pkts,
 			break;
 		}
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/drivers/net/softnic/rte_eth_softnic.c b/drivers/net/softnic/rte_eth_softnic.c
index 11723778f..b5b169ff7 100644
--- a/drivers/net/softnic/rte_eth_softnic.c
+++ b/drivers/net/softnic/rte_eth_softnic.c
@@ -704,7 +704,7 @@ rte_pmd_softnic_manage(uint16_t port_id)
 	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
 	struct pmd_internals *softnic;
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
 #endif
 
diff --git a/drivers/net/softnic/rte_eth_softnic_thread.c b/drivers/net/softnic/rte_eth_softnic_thread.c
index d610b1617..2f7c3a838 100644
--- a/drivers/net/softnic/rte_eth_softnic_thread.c
+++ b/drivers/net/softnic/rte_eth_softnic_thread.c
@@ -3093,7 +3093,7 @@ rte_pmd_softnic_run(uint16_t port_id)
 {
 	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
 #endif
 
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 752faa0f6..02eaf38e3 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -1979,7 +1979,7 @@ virtio_xmit_pkts_prepare(void *tx_queue __rte_unused, struct rte_mbuf **tx_pkts,
 	for (nb_tx = 0; nb_tx < nb_pkts; nb_tx++) {
 		struct rte_mbuf *m = tx_pkts[nb_tx];
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		error = rte_validate_tx_offload(m);
 		if (unlikely(error)) {
 			rte_errno = -error;
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index dd99684be..a801290ff 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -373,7 +373,7 @@ vmxnet3_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts,
 			return i;
 		}
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 		ret = rte_validate_tx_offload(m);
 		if (ret != 0) {
 			rte_errno = -ret;
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index e9e3a1699..f314b57c7 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -4375,7 +4375,7 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
 	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
 	uint16_t nb_rx;
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
 	RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
 
@@ -4498,11 +4498,11 @@ rte_eth_rx_descriptor_status(uint16_t port_id, uint16_t queue_id,
 	struct rte_eth_dev *dev;
 	void *rxq;
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
 #endif
 	dev = &rte_eth_devices[port_id];
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	if (queue_id >= dev->data->nb_rx_queues)
 		return -ENODEV;
 #endif
@@ -4555,11 +4555,11 @@ static inline int rte_eth_tx_descriptor_status(uint16_t port_id,
 	struct rte_eth_dev *dev;
 	void *txq;
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
 #endif
 	dev = &rte_eth_devices[port_id];
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	if (queue_id >= dev->data->nb_tx_queues)
 		return -ENODEV;
 #endif
@@ -4641,7 +4641,7 @@ rte_eth_tx_burst(uint16_t port_id, uint16_t queue_id,
 {
 	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
 	RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_pkt_burst, 0);
 
@@ -4727,7 +4727,7 @@ rte_eth_tx_prepare(uint16_t port_id, uint16_t queue_id,
 {
 	struct rte_eth_dev *dev;
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	if (!rte_eth_dev_is_valid_port(port_id)) {
 		RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
 		rte_errno = EINVAL;
@@ -4737,7 +4737,7 @@ rte_eth_tx_prepare(uint16_t port_id, uint16_t queue_id,
 
 	dev = &rte_eth_devices[port_id];
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	if (queue_id >= dev->data->nb_tx_queues) {
 		RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", queue_id);
 		rte_errno = EINVAL;
diff --git a/lib/librte_net/rte_net.h b/lib/librte_net/rte_net.h
index 1560ecfa4..9a9732189 100644
--- a/lib/librte_net/rte_net.h
+++ b/lib/librte_net/rte_net.h
@@ -120,7 +120,7 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf *m, uint64_t ol_flags)
 	struct rte_udp_hdr *udp_hdr;
 	uint64_t inner_l3_offset = m->l2_len;
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	/*
 	 * Does packet set any of available offloads?
 	 * Mainly it is required to avoid fragmented headers check if
@@ -133,7 +133,7 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf *m, uint64_t ol_flags)
 	if (ol_flags & (PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IPV6))
 		inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
 
-#ifdef RTE_LIBRTE_ETHDEV_DEBUG
+#ifdef RTE_DEBUG
 	/*
 	 * Check if headers are fragmented.
 	 * The check could be less strict depending on which offloads are
-- 
2.17.1

[dpdk-dev] [PATCH v1 04/17] eventdev: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_EVENTDEV_DEBUG.
The old define is completely removed from source code and config.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base                             | 1 -
 lib/librte_eventdev/rte_event_eth_tx_adapter.h | 2 +-
 lib/librte_eventdev/rte_event_timer_adapter.c  | 6 +++---
 lib/librte_eventdev/rte_event_timer_adapter.h  | 6 +++---
 lib/librte_eventdev/rte_eventdev.h             | 4 ++--
 lib/librte_eventdev/rte_eventdev_pmd.h         | 2 +-
 6 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/config/common_base b/config/common_base
index 16a8f09b6..96d5031d9 100644
--- a/config/common_base
+++ b/config/common_base
@@ -722,7 +722,6 @@ CONFIG_RTE_LIBRTE_PMD_ZLIB=n
 # Compile generic event device library
 #
 CONFIG_RTE_LIBRTE_EVENTDEV=y
-CONFIG_RTE_LIBRTE_EVENTDEV_DEBUG=n
 CONFIG_RTE_EVENT_MAX_DEVS=16
 CONFIG_RTE_EVENT_MAX_QUEUES_PER_DEV=64
 CONFIG_RTE_EVENT_TIMER_ADAPTER_NUM_MAX=32
diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
index 93b717af9..de13ca7f0 100644
--- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
+++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
@@ -357,7 +357,7 @@ rte_event_eth_tx_adapter_enqueue(uint8_t dev_id,
 {
 	const struct rte_eventdev *dev = &rte_eventdevs[dev_id];
 
-#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
+#ifdef RTE_DEBUG
 	if (dev_id >= RTE_EVENT_MAX_DEVS ||
 		!rte_eventdevs[dev_id].attached) {
 		rte_errno = EINVAL;
diff --git a/lib/librte_eventdev/rte_event_timer_adapter.c b/lib/librte_eventdev/rte_event_timer_adapter.c
index 161e21a68..02c27b91e 100644
--- a/lib/librte_eventdev/rte_event_timer_adapter.c
+++ b/lib/librte_eventdev/rte_event_timer_adapter.c
@@ -43,7 +43,7 @@ static const struct rte_event_timer_adapter_ops swtim_ops;
 
 #define EVTIM_LOG_ERR(...) EVTIM_LOG(ERR, evtim_logtype, __VA_ARGS__)
 
-#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
+#ifdef RTE_DEBUG
 #define EVTIM_LOG_DBG(...) \
 	EVTIM_LOG(DEBUG, evtim_logtype, __VA_ARGS__)
 #define EVTIM_BUF_LOG_DBG(...) \
@@ -1008,7 +1008,7 @@ __swtim_arm_burst(const struct rte_event_timer_adapter *adapter,
 	struct rte_timer *tim, *tims[nb_evtims];
 	uint64_t cycles;
 
-#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
+#ifdef RTE_DEBUG
 	/* Check that the service is running. */
 	if (rte_service_runstate_get(adapter->data->service_id) != 1) {
 		rte_errno = EINVAL;
@@ -1114,7 +1114,7 @@ swtim_cancel_burst(const struct rte_event_timer_adapter *adapter,
 	uint64_t opaque;
 	struct swtim *sw = swtim_pmd_priv(adapter);
 
-#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
+#ifdef RTE_DEBUG
 	/* Check that the service is running. */
 	if (rte_service_runstate_get(adapter->data->service_id) != 1) {
 		rte_errno = EINVAL;
diff --git a/lib/librte_eventdev/rte_event_timer_adapter.h b/lib/librte_eventdev/rte_event_timer_adapter.h
index 7f6dc5c29..8e7e2b0e3 100644
--- a/lib/librte_eventdev/rte_event_timer_adapter.h
+++ b/lib/librte_eventdev/rte_event_timer_adapter.h
@@ -575,7 +575,7 @@ rte_event_timer_arm_burst(const struct rte_event_timer_adapter *adapter,
 			  struct rte_event_timer **evtims,
 			  uint16_t nb_evtims)
 {
-#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
+#ifdef RTE_DEBUG
 	ADAPTER_VALID_OR_ERR_RET(adapter, -EINVAL);
 	FUNC_PTR_OR_ERR_RET(adapter->arm_burst, -EINVAL);
 #endif
@@ -618,7 +618,7 @@ rte_event_timer_arm_tmo_tick_burst(
 			const uint64_t timeout_ticks,
 			const uint16_t nb_evtims)
 {
-#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
+#ifdef RTE_DEBUG
 	ADAPTER_VALID_OR_ERR_RET(adapter, -EINVAL);
 	FUNC_PTR_OR_ERR_RET(adapter->arm_tmo_tick_burst, -EINVAL);
 #endif
@@ -651,7 +651,7 @@ rte_event_timer_cancel_burst(const struct rte_event_timer_adapter *adapter,
 			     struct rte_event_timer **evtims,
 			     uint16_t nb_evtims)
 {
-#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
+#ifdef RTE_DEBUG
 	ADAPTER_VALID_OR_ERR_RET(adapter, -EINVAL);
 	FUNC_PTR_OR_ERR_RET(adapter->cancel_burst, -EINVAL);
 #endif
diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
index 226f352ad..cb237fdd0 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -1332,7 +1332,7 @@ __rte_event_enqueue_burst(uint8_t dev_id, uint8_t port_id,
 {
 	const struct rte_eventdev *dev = &rte_eventdevs[dev_id];
 
-#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
+#ifdef RTE_DEBUG
 	if (dev_id >= RTE_EVENT_MAX_DEVS || !rte_eventdevs[dev_id].attached) {
 		rte_errno = EINVAL;
 		return 0;
@@ -1609,7 +1609,7 @@ rte_event_dequeue_burst(uint8_t dev_id, uint8_t port_id, struct rte_event ev[],
 {
 	struct rte_eventdev *dev = &rte_eventdevs[dev_id];
 
-#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
+#ifdef RTE_DEBUG
 	if (dev_id >= RTE_EVENT_MAX_DEVS || !rte_eventdevs[dev_id].attached) {
 		rte_errno = EINVAL;
 		return 0;
diff --git a/lib/librte_eventdev/rte_eventdev_pmd.h b/lib/librte_eventdev/rte_eventdev_pmd.h
index d118b9e5b..090cb4309 100644
--- a/lib/librte_eventdev/rte_eventdev_pmd.h
+++ b/lib/librte_eventdev/rte_eventdev_pmd.h
@@ -34,7 +34,7 @@ extern "C" {
 		RTE_FMT("%s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
 			__func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__,)))
 
-#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
+#ifdef RTE_DEBUG
 #define RTE_EDEV_LOG_DEBUG(...) \
 	RTE_LOG(DEBUG, EVENTDEV, \
 		RTE_FMT("%s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
-- 
2.17.1

[dpdk-dev] [PATCH v1 05/17] fib: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_FIB_DEBUG.
The old define is completely removed from source code and config.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base        | 1 -
 lib/librte_fib/rte_fib.c  | 2 +-
 lib/librte_fib/rte_fib6.c | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/config/common_base b/config/common_base
index 96d5031d9..09f54c460 100644
--- a/config/common_base
+++ b/config/common_base
@@ -930,7 +930,6 @@ CONFIG_RTE_LIBRTE_RIB=y
 # Compile librte_fib
 #
 CONFIG_RTE_LIBRTE_FIB=y
-CONFIG_RTE_LIBRTE_FIB_DEBUG=n
 
 #
 # Compile librte_lpm
diff --git a/lib/librte_fib/rte_fib.c b/lib/librte_fib/rte_fib.c
index e0908084f..52a64f726 100644
--- a/lib/librte_fib/rte_fib.c
+++ b/lib/librte_fib/rte_fib.c
@@ -28,7 +28,7 @@ EAL_REGISTER_TAILQ(rte_fib_tailq)
 /* Maximum length of a FIB name. */
 #define RTE_FIB_NAMESIZE	64
 
-#if defined(RTE_LIBRTE_FIB_DEBUG)
+#ifdef RTE_DEBUG
 #define FIB_RETURN_IF_TRUE(cond, retval) do {		\
 	if (cond)					\
 		return retval;				\
diff --git a/lib/librte_fib/rte_fib6.c b/lib/librte_fib/rte_fib6.c
index a1f0db844..bd9b990cf 100644
--- a/lib/librte_fib/rte_fib6.c
+++ b/lib/librte_fib/rte_fib6.c
@@ -28,7 +28,7 @@ EAL_REGISTER_TAILQ(rte_fib6_tailq)
 /* Maximum length of a FIB name. */
 #define FIB6_NAMESIZE	64
 
-#if defined(RTE_LIBRTE_FIB_DEBUG)
+#ifdef RTE_DEBUG
 #define FIB6_RETURN_IF_TRUE(cond, retval) do {		\
 	if (cond)					\
 		return retval;				\
-- 
2.17.1

[dpdk-dev] [PATCH v1 06/17] cmdline: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_CMDLINE_DEBUG.
The old define is completely removed from source code and config.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base                     | 1 -
 lib/librte_cmdline/cmdline_cirbuf.h    | 2 +-
 lib/librte_cmdline/cmdline_parse.c     | 2 +-
 lib/librte_cmdline/cmdline_parse_num.c | 2 +-
 4 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/config/common_base b/config/common_base
index 09f54c460..ea5ccafc9 100644
--- a/config/common_base
+++ b/config/common_base
@@ -872,7 +872,6 @@ CONFIG_RTE_LIBRTE_CFGFILE=y
 # Compile librte_cmdline
 #
 CONFIG_RTE_LIBRTE_CMDLINE=y
-CONFIG_RTE_LIBRTE_CMDLINE_DEBUG=n
 
 #
 # Compile librte_hash
diff --git a/lib/librte_cmdline/cmdline_cirbuf.h b/lib/librte_cmdline/cmdline_cirbuf.h
index c23b211ad..d11394985 100644
--- a/lib/librte_cmdline/cmdline_cirbuf.h
+++ b/lib/librte_cmdline/cmdline_cirbuf.h
@@ -24,7 +24,7 @@ struct cirbuf {
 	char *buf;
 };
 
-#ifdef RTE_LIBRTE_CMDLINE_DEBUG
+#ifdef RTE_DEBUG
 #define dprintf_(fmt, ...) printf("line %3.3d - " fmt "%.0s", __LINE__, __VA_ARGS__)
 #define dprintf(...) dprintf_(__VA_ARGS__, "dummy")
 #else
diff --git a/lib/librte_cmdline/cmdline_parse.c b/lib/librte_cmdline/cmdline_parse.c
index b57b30e8f..72bf543d9 100644
--- a/lib/librte_cmdline/cmdline_parse.c
+++ b/lib/librte_cmdline/cmdline_parse.c
@@ -20,7 +20,7 @@
 #include "cmdline_parse.h"
 #include "cmdline.h"
 
-#ifdef RTE_LIBRTE_CMDLINE_DEBUG
+#ifdef RTE_DEBUG
 #define debug_printf printf
 #else
 #define debug_printf(args...) do {} while(0)
diff --git a/lib/librte_cmdline/cmdline_parse_num.c b/lib/librte_cmdline/cmdline_parse_num.c
index 478f181b4..ddcd14419 100644
--- a/lib/librte_cmdline/cmdline_parse_num.c
+++ b/lib/librte_cmdline/cmdline_parse_num.c
@@ -16,7 +16,7 @@
 #include "cmdline_parse.h"
 #include "cmdline_parse_num.h"
 
-#ifdef RTE_LIBRTE_CMDLINE_DEBUG
+#ifdef RTE_DEBUG
 #define debug_printf(args...) printf(args)
 #else
 #define debug_printf(args...) do {} while(0)
-- 
2.17.1

[dpdk-dev] [PATCH v1 07/17] hash: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_HASH_DEBUG.
The old define is completely removed from source code and config.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base                | 1 -
 lib/librte_hash/rte_cuckoo_hash.h | 4 ++--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/config/common_base b/config/common_base
index ea5ccafc9..a12a869a9 100644
--- a/config/common_base
+++ b/config/common_base
@@ -877,7 +877,6 @@ CONFIG_RTE_LIBRTE_CMDLINE=y
 # Compile librte_hash
 #
 CONFIG_RTE_LIBRTE_HASH=y
-CONFIG_RTE_LIBRTE_HASH_DEBUG=n
 
 #
 # Compile librte_efd
diff --git a/lib/librte_hash/rte_cuckoo_hash.h b/lib/librte_hash/rte_cuckoo_hash.h
index 345de6bf9..57ef74a47 100644
--- a/lib/librte_hash/rte_cuckoo_hash.h
+++ b/lib/librte_hash/rte_cuckoo_hash.h
@@ -20,7 +20,7 @@
 #endif
 
 /* Macro to enable/disable run-time checking of function parameters */
-#if defined(RTE_LIBRTE_HASH_DEBUG)
+#ifdef RTE_DEBUG
 #define RETURN_IF_TRUE(cond, retval) do { \
 	if (cond) \
 		return retval; \
@@ -29,7 +29,7 @@
 #define RETURN_IF_TRUE(cond, retval)
 #endif
 
-#if defined(RTE_LIBRTE_HASH_DEBUG)
+#ifdef RTE_DEBUG
 #define ERR_IF_TRUE(cond, fmt, args...) do { \
 	if (cond) { \
 		RTE_LOG(ERR, HASH, fmt, ##args); \
-- 
2.17.1

[dpdk-dev] [PATCH v1 08/17] ip_frag: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_IP_FRAG_DEBUG.
The old define is completely removed from source code and config.
The documentation was updated also.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base                                   | 1 -
 doc/guides/prog_guide/ip_fragment_reassembly_lib.rst | 4 ++--
 lib/librte_ip_frag/ip_frag_common.h                  | 4 ++--
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/config/common_base b/config/common_base
index a12a869a9..44a9ab75c 100644
--- a/config/common_base
+++ b/config/common_base
@@ -956,7 +956,6 @@ CONFIG_RTE_LIBRTE_NET=y
 # Compile librte_ip_frag
 #
 CONFIG_RTE_LIBRTE_IP_FRAG=y
-CONFIG_RTE_LIBRTE_IP_FRAG_DEBUG=n
 CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG=4
 CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n
 
diff --git a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
index 6ac1bba64..b48ccfbbf 100644
--- a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
+++ b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
@@ -104,7 +104,7 @@ Debug logging and Statistics Collection
 The RTE_LIBRTE_IP_FRAG_TBL_STAT config macro controls statistics collection for the Fragment Table.
 This macro is not enabled by default.
 
-The RTE_LIBRTE_IP_FRAG_DEBUG controls debug logging of IP fragments processing and reassembling.
-This macro is disabled by default.
+The RTE_DEBUG controls debug logging of IP fragments processing and reassembling.
+This macro is disabled by default and can be enabled using meson "debug" option.
 Note that while logging contains a lot of detailed information,
 it slows down packet processing and might cause the loss of a lot of packets.
diff --git a/lib/librte_ip_frag/ip_frag_common.h b/lib/librte_ip_frag/ip_frag_common.h
index a17a74076..79a0dbd18 100644
--- a/lib/librte_ip_frag/ip_frag_common.h
+++ b/lib/librte_ip_frag/ip_frag_common.h
@@ -8,11 +8,11 @@
 #include "rte_ip_frag.h"
 
 /* logging macros. */
-#ifdef RTE_LIBRTE_IP_FRAG_DEBUG
+#ifdef RTE_DEBUG
 #define	IP_FRAG_LOG(lvl, fmt, args...)	RTE_LOG(lvl, USER1, fmt, ##args)
 #else
 #define	IP_FRAG_LOG(lvl, fmt, args...)	do {} while(0)
-#endif /* IP_FRAG_DEBUG */
+#endif /* RTE_DEBUG */
 
 #define IPV4_KEYLEN 1
 #define IPV6_KEYLEN 4
-- 
2.17.1

[dpdk-dev] [PATCH v1 09/17] lpm: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_LPM_DEBUG.
The old define is completely removed from source code and config.
Application of the flag in tests was also adjusted.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 app/test/test_lpm.c      | 2 +-
 config/common_base       | 1 -
 lib/librte_lpm/rte_lpm.c | 2 +-
 lib/librte_lpm/rte_lpm.h | 2 +-
 4 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/app/test/test_lpm.c b/app/test/test_lpm.c
index 3a3fd097f..339999e04 100644
--- a/app/test/test_lpm.c
+++ b/app/test/test_lpm.c
@@ -234,7 +234,7 @@ test4(void)
 int32_t
 test5(void)
 {
-#if defined(RTE_LIBRTE_LPM_DEBUG)
+#ifdef RTE_DEBUG
 	struct rte_lpm *lpm = NULL;
 	struct rte_lpm_config config;
 
diff --git a/config/common_base b/config/common_base
index 44a9ab75c..310d5ab24 100644
--- a/config/common_base
+++ b/config/common_base
@@ -933,7 +933,6 @@ CONFIG_RTE_LIBRTE_FIB=y
 # Compile librte_lpm
 #
 CONFIG_RTE_LIBRTE_LPM=y
-CONFIG_RTE_LIBRTE_LPM_DEBUG=n
 
 #
 # Compile librte_acl
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index 268756419..0907cf11c 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -40,7 +40,7 @@ enum valid_flag {
 };
 
 /* Macro to enable/disable run-time checks. */
-#if defined(RTE_LIBRTE_LPM_DEBUG)
+#ifdef RTE_DEBUG
 #include <rte_debug.h>
 #define VERIFY_DEPTH(depth) do {                                \
 	if ((depth == 0) || (depth > RTE_LPM_MAX_DEPTH))        \
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index b9d49ac87..350fa6bc8 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -48,7 +48,7 @@ extern "C" {
 					RTE_LPM_TBL8_GROUP_NUM_ENTRIES)
 
 /** @internal Macro to enable/disable run-time checks. */
-#if defined(RTE_LIBRTE_LPM_DEBUG)
+#ifdef RTE_DEBUG
 #define RTE_LPM_RETURN_IF_TRUE(cond, retval) do { \
 	if (cond) return (retval);                \
 } while (0)
-- 
2.17.1

[dpdk-dev] [PATCH v1 10/17] mbuf: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_MBUF_DEBUG.
The old define is completely removed from source code and config.
Tests and documentation were also updated.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 app/test/test_mbuf.c               | 2 +-
 config/common_base                 | 1 -
 doc/guides/prog_guide/mbuf_lib.rst | 2 +-
 lib/librte_mbuf/rte_mbuf.h         | 6 +++---
 4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 8200b4f71..0f0036c49 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -994,7 +994,7 @@ test_pktmbuf_free_segment(struct rte_mempool *pktmbuf_pool)
 /*
  * Stress test for rte_mbuf atomic refcnt.
  * Implies that RTE_MBUF_REFCNT_ATOMIC is defined.
- * For more efficiency, recommended to run with RTE_LIBRTE_MBUF_DEBUG defined.
+ * For more efficiency, recommended to run with RTE_DEBUG defined.
  */
 
 #ifdef RTE_MBUF_REFCNT_ATOMIC
diff --git a/config/common_base b/config/common_base
index 310d5ab24..c24086789 100644
--- a/config/common_base
+++ b/config/common_base
@@ -852,7 +852,6 @@ CONFIG_RTE_LIBRTE_OCTEONTX2_MEMPOOL=y
 # Compile librte_mbuf
 #
 CONFIG_RTE_LIBRTE_MBUF=y
-CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
 CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS="ring_mp_mc"
 CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
 CONFIG_RTE_PKTMBUF_HEADROOM=128
diff --git a/doc/guides/prog_guide/mbuf_lib.rst b/doc/guides/prog_guide/mbuf_lib.rst
index 0d3223b08..c04bb45d8 100644
--- a/doc/guides/prog_guide/mbuf_lib.rst
+++ b/doc/guides/prog_guide/mbuf_lib.rst
@@ -243,7 +243,7 @@ can be found in several of the sample applications, for example, the IPv4 Multic
 Debug
 -----
 
-In debug mode (CONFIG_RTE_MBUF_DEBUG is enabled),
+In debug mode (RTE_DEBUG is enabled, e.g. by using "debug" option during meson setup),
 the functions of the mbuf library perform sanity checks before any operation (such as, buffer corruption, bad type, and so on).
 
 Use Cases
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index f8e492e59..2deb309e0 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -341,17 +341,17 @@ rte_pktmbuf_priv_flags(struct rte_mempool *mp)
 #define RTE_MBUF_HAS_PINNED_EXTBUF(mb) \
 	(rte_pktmbuf_priv_flags(mb->pool) & RTE_PKTMBUF_POOL_F_PINNED_EXT_BUF)
 
-#ifdef RTE_LIBRTE_MBUF_DEBUG
+#ifdef RTE_DEBUG
 
 /**  check mbuf type in debug mode */
 #define __rte_mbuf_sanity_check(m, is_h) rte_mbuf_sanity_check(m, is_h)
 
-#else /*  RTE_LIBRTE_MBUF_DEBUG */
+#else /*  RTE_DEBUG */
 
 /**  check mbuf type in debug mode */
 #define __rte_mbuf_sanity_check(m, is_h) do { } while (0)
 
-#endif /*  RTE_LIBRTE_MBUF_DEBUG */
+#endif /*  RTE_DEBUG */
 
 #ifdef RTE_MBUF_REFCNT_ATOMIC
 
-- 
2.17.1

[dpdk-dev] [PATCH v1 11/17] mempool: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_MEMPOOL_DEBUG.
The old define is completely removed from source code and config.
Documentation was also updated.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base                    |  1 -
 doc/guides/prog_guide/mempool_lib.rst |  7 ++++---
 lib/librte_mempool/rte_mempool.c      | 16 ++++++++--------
 lib/librte_mempool/rte_mempool.h      | 20 ++++++++++----------
 4 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/config/common_base b/config/common_base
index c24086789..b975a1feb 100644
--- a/config/common_base
+++ b/config/common_base
@@ -828,7 +828,6 @@ CONFIG_RTE_LIBRTE_STACK=y
 #
 CONFIG_RTE_LIBRTE_MEMPOOL=y
 CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
-CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
 
 #
 # Compile Mempool drivers
diff --git a/doc/guides/prog_guide/mempool_lib.rst b/doc/guides/prog_guide/mempool_lib.rst
index f8b430d65..b8104163e 100644
--- a/doc/guides/prog_guide/mempool_lib.rst
+++ b/doc/guides/prog_guide/mempool_lib.rst
@@ -17,14 +17,15 @@ This library is used by the :ref:`Mbuf Library <Mbuf_Library>`.
 Cookies
 -------
 
-In debug mode (CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG is enabled), cookies are added at the beginning and end of allocated blocks.
+In debug mode (RTE_DEBUG is enabled), cookies are added at the beginning and end of allocated blocks.
 The allocated objects then contain overwrite protection fields to help debugging buffer overflows.
+The RTE_DEBUG flag can be enabled using meson "debug" option.
 
 Stats
 -----
 
-In debug mode (CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG is enabled),
-statistics about get from/put in the pool are stored in the mempool structure.
+In debug mode (RTE_DEBUG is enabled), statistics about get from/put in the pool
+are stored in the mempool structure.
 Statistics are per-lcore to avoid concurrent access to statistics counters.
 
 Memory Alignment Constraints on x86 architecture
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 712c839a0..7772895cc 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -164,7 +164,7 @@ mempool_add_elem(struct rte_mempool *mp, __rte_unused void *opaque,
 	STAILQ_INSERT_TAIL(&mp->elt_list, hdr, next);
 	mp->populated_size++;
 
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 	hdr->cookie = RTE_MEMPOOL_HEADER_COOKIE2;
 	tlr = __mempool_get_trailer(obj);
 	tlr->cookie = RTE_MEMPOOL_TRAILER_COOKIE;
@@ -219,7 +219,7 @@ rte_mempool_calc_obj_size(uint32_t elt_size, uint32_t flags,
 		sz->header_size = RTE_ALIGN_CEIL(sz->header_size,
 			RTE_MEMPOOL_ALIGN);
 
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 	sz->trailer_size = sizeof(struct rte_mempool_objtlr);
 #else
 	sz->trailer_size = 0;
@@ -806,7 +806,7 @@ rte_mempool_create_empty(const char *name, unsigned n, unsigned elt_size,
 			  RTE_CACHE_LINE_MASK) != 0);
 	RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_cache) &
 			  RTE_CACHE_LINE_MASK) != 0);
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 	RTE_BUILD_BUG_ON((sizeof(struct rte_mempool_debug_stats) &
 			  RTE_CACHE_LINE_MASK) != 0);
 	RTE_BUILD_BUG_ON((offsetof(struct rte_mempool, stats) &
@@ -1033,7 +1033,7 @@ rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
 void rte_mempool_check_cookies(const struct rte_mempool *mp,
 	void * const *obj_table_const, unsigned n, int free)
 {
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 	struct rte_mempool_objhdr *hdr;
 	struct rte_mempool_objtlr *tlr;
 	uint64_t cookie;
@@ -1102,7 +1102,7 @@ void
 rte_mempool_contig_blocks_check_cookies(const struct rte_mempool *mp,
 	void * const *first_obj_table_const, unsigned int n, int free)
 {
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 	struct rte_mempool_info info;
 	const size_t total_elt_sz =
 		mp->header_size + mp->elt_size + mp->trailer_size;
@@ -1128,7 +1128,7 @@ rte_mempool_contig_blocks_check_cookies(const struct rte_mempool *mp,
 #endif
 }
 
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 static void
 mempool_obj_audit(struct rte_mempool *mp, __rte_unused void *opaque,
 	void *obj, __rte_unused unsigned idx)
@@ -1192,7 +1192,7 @@ rte_mempool_audit(struct rte_mempool *mp)
 void
 rte_mempool_dump(FILE *f, struct rte_mempool *mp)
 {
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 	struct rte_mempool_info info;
 	struct rte_mempool_debug_stats sum;
 	unsigned lcore_id;
@@ -1234,7 +1234,7 @@ rte_mempool_dump(FILE *f, struct rte_mempool *mp)
 	fprintf(f, "  common_pool_count=%u\n", common_count);
 
 	/* sum and dump statistics */
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 	rte_mempool_ops_get_info(mp, &info);
 	memset(&sum, 0, sizeof(sum));
 	for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index c90cf3146..dd16c1146 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -59,7 +59,7 @@ extern "C" {
 #define RTE_MEMPOOL_HEADER_COOKIE2  0xf2eef2eedadd2e55ULL /**< Header cookie. */
 #define RTE_MEMPOOL_TRAILER_COOKIE  0xadd2e55badbadbadULL /**< Trailer cookie.*/
 
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 /**
  * A structure that stores the mempool statistics (per-lcore).
  */
@@ -141,7 +141,7 @@ struct rte_mempool_objhdr {
 		rte_iova_t iova;         /**< IO address of the object. */
 		phys_addr_t physaddr;    /**< deprecated - Physical address of the object. */
 	};
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 	uint64_t cookie;                 /**< Debug cookie. */
 #endif
 };
@@ -151,7 +151,7 @@ struct rte_mempool_objhdr {
  */
 STAILQ_HEAD(rte_mempool_objhdr_list, rte_mempool_objhdr);
 
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 
 /**
  * Mempool object trailer structure
@@ -254,7 +254,7 @@ struct rte_mempool {
 	uint32_t nb_mem_chunks;          /**< Number of memory chunks */
 	struct rte_mempool_memhdr_list mem_list; /**< List of memory chunks */
 
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 	/** Per-lcore statistics. */
 	struct rte_mempool_debug_stats stats[RTE_MAX_LCORE];
 #endif
@@ -279,7 +279,7 @@ struct rte_mempool {
  * @param n
  *   Number to add to the object-oriented statistics.
  */
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 #define __MEMPOOL_STAT_ADD(mp, name, n) do {                    \
 		unsigned __lcore_id = rte_lcore_id();           \
 		if (__lcore_id < RTE_MAX_LCORE) {               \
@@ -357,12 +357,12 @@ static inline struct rte_mempool_objtlr *__mempool_get_trailer(void *obj)
 void rte_mempool_check_cookies(const struct rte_mempool *mp,
 	void * const *obj_table_const, unsigned n, int free);
 
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 #define __mempool_check_cookies(mp, obj_table_const, n, free) \
 	rte_mempool_check_cookies(mp, obj_table_const, n, free)
 #else
 #define __mempool_check_cookies(mp, obj_table_const, n, free) do {} while(0)
-#endif /* RTE_LIBRTE_MEMPOOL_DEBUG */
+#endif /* RTE_DEBUG */
 
 /**
  * @warning
@@ -385,7 +385,7 @@ void rte_mempool_check_cookies(const struct rte_mempool *mp,
 void rte_mempool_contig_blocks_check_cookies(const struct rte_mempool *mp,
 	void * const *first_obj_table_const, unsigned int n, int free);
 
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 #define __mempool_contig_blocks_check_cookies(mp, first_obj_table_const, n, \
 					      free) \
 	rte_mempool_contig_blocks_check_cookies(mp, first_obj_table_const, n, \
@@ -394,7 +394,7 @@ void rte_mempool_contig_blocks_check_cookies(const struct rte_mempool *mp,
 #define __mempool_contig_blocks_check_cookies(mp, first_obj_table_const, n, \
 					      free) \
 	do {} while (0)
-#endif /* RTE_LIBRTE_MEMPOOL_DEBUG */
+#endif /* RTE_DEBUG */
 
 #define RTE_MEMPOOL_OPS_NAMESIZE 32 /**< Max length of ops struct name. */
 
@@ -1337,7 +1337,7 @@ __mempool_generic_put(struct rte_mempool *mp, void * const *obj_table,
 ring_enqueue:
 
 	/* push remaining objects in ring */
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
+#ifdef RTE_DEBUG
 	if (rte_mempool_ops_enqueue_bulk(mp, obj_table, n) < 0)
 		rte_panic("cannot put objects in mempool\n");
 #else
-- 
2.17.1

[dpdk-dev] [PATCH v1 12/17] power: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_POWER_DEBUG.
The old define is completely removed from source code and config.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base                      | 1 -
 lib/librte_power/power_acpi_cpufreq.c   | 2 +-
 lib/librte_power/power_pstate_cpufreq.c | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/config/common_base b/config/common_base
index b975a1feb..5863b4327 100644
--- a/config/common_base
+++ b/config/common_base
@@ -941,7 +941,6 @@ CONFIG_RTE_LIBRTE_ACL=y
 # Compile librte_power
 #
 CONFIG_RTE_LIBRTE_POWER=n
-CONFIG_RTE_LIBRTE_POWER_DEBUG=n
 CONFIG_RTE_MAX_LCORE_FREQS=64
 
 #
diff --git a/lib/librte_power/power_acpi_cpufreq.c b/lib/librte_power/power_acpi_cpufreq.c
index f443fce69..d5791699d 100644
--- a/lib/librte_power/power_acpi_cpufreq.c
+++ b/lib/librte_power/power_acpi_cpufreq.c
@@ -20,7 +20,7 @@
 #include "power_acpi_cpufreq.h"
 #include "power_common.h"
 
-#ifdef RTE_LIBRTE_POWER_DEBUG
+#ifdef RTE_DEBUG
 #define POWER_DEBUG_TRACE(fmt, args...) do { \
 		RTE_LOG(ERR, POWER, "%s: " fmt, __func__, ## args); \
 } while (0)
diff --git a/lib/librte_power/power_pstate_cpufreq.c b/lib/librte_power/power_pstate_cpufreq.c
index 2d8a9499d..0e522f768 100644
--- a/lib/librte_power/power_pstate_cpufreq.c
+++ b/lib/librte_power/power_pstate_cpufreq.c
@@ -23,7 +23,7 @@
 #include "power_common.h"
 
 
-#ifdef RTE_LIBRTE_POWER_DEBUG
+#ifdef RTE_DEBUG
 #define POWER_DEBUG_TRACE(fmt, args...) do { \
 		RTE_LOG(ERR, POWER, "%s: " fmt, __func__, ## args); \
 } while (0)
-- 
2.17.1

[dpdk-dev] [PATCH v1 13/17] rcu: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_RCU_DEBUG.
The old define is completely removed from source code and config.
Documentation was also updated.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base                |  1 -
 doc/guides/prog_guide/rcu_lib.rst |  8 ++++----
 lib/librte_rcu/rte_rcu_qsbr.h     | 16 ++++++++--------
 3 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/config/common_base b/config/common_base
index 5863b4327..c22e9a6fe 100644
--- a/config/common_base
+++ b/config/common_base
@@ -915,7 +915,6 @@ CONFIG_RTE_LIBRTE_TELEMETRY=n
 # Compile librte_rcu
 #
 CONFIG_RTE_LIBRTE_RCU=y
-CONFIG_RTE_LIBRTE_RCU_DEBUG=n
 
 #
 # Compile librte_rib
diff --git a/doc/guides/prog_guide/rcu_lib.rst b/doc/guides/prog_guide/rcu_lib.rst
index 9b0bf138f..ecdea9c9c 100644
--- a/doc/guides/prog_guide/rcu_lib.rst
+++ b/doc/guides/prog_guide/rcu_lib.rst
@@ -186,7 +186,7 @@ they entered a quiescent state. This API checks if a writer has triggered a
 quiescent state query and update the state accordingly.
 
 The ``rte_rcu_qsbr_lock()`` and ``rte_rcu_qsbr_unlock()`` are empty functions.
-However, when ``CONFIG_RTE_LIBRTE_RCU_DEBUG`` is enabled, these APIs aid
-in debugging issues. One can mark the access to shared data structures on the
-reader side using these APIs. The ``rte_rcu_qsbr_quiescent()`` will check if
-all the locks are unlocked.
+However, when ``RTE_DEBUG`` is enabled, these APIs aid in debugging issues.
+One can mark the access to shared data structures on the reader side using
+these APIs. The ``rte_rcu_qsbr_quiescent()`` will check if all the locks
+are unlocked.
diff --git a/lib/librte_rcu/rte_rcu_qsbr.h b/lib/librte_rcu/rte_rcu_qsbr.h
index 0b5585925..bc8ab102c 100644
--- a/lib/librte_rcu/rte_rcu_qsbr.h
+++ b/lib/librte_rcu/rte_rcu_qsbr.h
@@ -45,7 +45,7 @@ extern int rte_rcu_log_type;
 #define __RTE_RCU_DP_LOG(level, fmt, args...)
 #endif
 
-#if defined(RTE_LIBRTE_RCU_DEBUG)
+#ifdef RTE_DEBUG
 #define __RTE_RCU_IS_LOCK_CNT_ZERO(v, thread_id, level, fmt, args...) do {\
 	if (v->qsbr_cnt[thread_id].lock_cnt) \
 		rte_log(RTE_LOG_ ## level, rte_rcu_log_type, \
@@ -78,7 +78,7 @@ struct rte_rcu_qsbr_cnt {
 	 *   changes to various APIs.
 	 */
 	uint32_t lock_cnt;
-	/**< Lock counter. Used when CONFIG_RTE_LIBRTE_RCU_DEBUG is enabled */
+	/**< Lock counter. Used when RTE_DEBUG is enabled */
 } __rte_cache_aligned;
 
 #define __RTE_QSBR_CNT_THR_OFFLINE 0
@@ -323,11 +323,11 @@ rte_rcu_qsbr_thread_offline(struct rte_rcu_qsbr *v, unsigned int thread_id)
  * This API is provided to aid debugging. This should be called before
  * accessing a shared data structure.
  *
- * When CONFIG_RTE_LIBRTE_RCU_DEBUG is enabled a lock counter is incremented.
+ * When RTE_DEBUG is enabled a lock counter is incremented.
  * Similarly rte_rcu_qsbr_unlock will decrement the counter. When the
  * rte_rcu_qsbr_check API will verify that this counter is 0.
  *
- * When CONFIG_RTE_LIBRTE_RCU_DEBUG is disabled, this API will do nothing.
+ * When RTE_DEBUG is disabled, this API will do nothing.
  *
  * @param v
  *   QS variable
@@ -341,7 +341,7 @@ rte_rcu_qsbr_lock(__rte_unused struct rte_rcu_qsbr *v,
 {
 	RTE_ASSERT(v != NULL && thread_id < v->max_threads);
 
-#if defined(RTE_LIBRTE_RCU_DEBUG)
+#ifdef RTE_DEBUG
 	/* Increment the lock counter */
 	__atomic_fetch_add(&v->qsbr_cnt[thread_id].lock_cnt,
 				1, __ATOMIC_ACQUIRE);
@@ -360,11 +360,11 @@ rte_rcu_qsbr_lock(__rte_unused struct rte_rcu_qsbr *v,
  * This API is provided to aid debugging. This should be called after
  * accessing a shared data structure.
  *
- * When CONFIG_RTE_LIBRTE_RCU_DEBUG is enabled, rte_rcu_qsbr_unlock will
+ * When RTE_DEBUG is enabled, rte_rcu_qsbr_unlock will
  * decrement a lock counter. rte_rcu_qsbr_check API will verify that this
  * counter is 0.
  *
- * When CONFIG_RTE_LIBRTE_RCU_DEBUG is disabled, this API will do nothing.
+ * When RTE_DEBUG is disabled, this API will do nothing.
  *
  * @param v
  *   QS variable
@@ -378,7 +378,7 @@ rte_rcu_qsbr_unlock(__rte_unused struct rte_rcu_qsbr *v,
 {
 	RTE_ASSERT(v != NULL && thread_id < v->max_threads);
 
-#if defined(RTE_LIBRTE_RCU_DEBUG)
+#ifdef RTE_DEBUG
 	/* Decrement the lock counter */
 	__atomic_fetch_sub(&v->qsbr_cnt[thread_id].lock_cnt,
 				1, __ATOMIC_RELEASE);
-- 
2.17.1

[dpdk-dev] [PATCH v1 14/17] timer: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_TIMER_DEBUG.
The old define is completely removed from source code and config.
The tests were adjusted to use new flag.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 app/test/test_timer_secondary.c |  2 +-
 config/common_base              |  1 -
 lib/librte_timer/rte_timer.c    | 12 ++++++------
 lib/librte_timer/rte_timer.h    |  2 +-
 4 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/app/test/test_timer_secondary.c b/app/test/test_timer_secondary.c
index 7a3bc873b..7f3d5645c 100644
--- a/app/test/test_timer_secondary.c
+++ b/app/test/test_timer_secondary.c
@@ -158,7 +158,7 @@ test_timer_secondary(void)
 		test_info->exit_flag = 1;
 		rte_eal_wait_lcore(*mgr_lcorep);
 
-#ifdef RTE_LIBRTE_TIMER_DEBUG
+#ifdef RTE_DEBUG
 		rte_timer_alt_dump_stats(test_info->timer_data_id, stdout);
 #endif
 
diff --git a/config/common_base b/config/common_base
index c22e9a6fe..025ae7c62 100644
--- a/config/common_base
+++ b/config/common_base
@@ -859,7 +859,6 @@ CONFIG_RTE_PKTMBUF_HEADROOM=128
 # Compile librte_timer
 #
 CONFIG_RTE_LIBRTE_TIMER=y
-CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
 
 #
 # Compile librte_cfgfile
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 89f27074f..fc96b1a2c 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -48,7 +48,7 @@ struct priv_timer {
 	/** running timer on this lcore now */
 	struct rte_timer *running_tim;
 
-#ifdef RTE_LIBRTE_TIMER_DEBUG
+#ifdef RTE_DEBUG
 	/** per-lcore statistics */
 	struct rte_timer_debug_stats stats;
 #endif
@@ -68,7 +68,7 @@ static const uint32_t default_data_id;
 static uint32_t rte_timer_subsystem_initialized;
 
 /* when debug is enabled, store some statistics */
-#ifdef RTE_LIBRTE_TIMER_DEBUG
+#ifdef RTE_DEBUG
 #define __TIMER_STAT_ADD(priv_timer, name, n) do {			\
 		unsigned __lcore_id = rte_lcore_id();			\
 		if (__lcore_id < RTE_MAX_LCORE)				\
@@ -302,7 +302,7 @@ timer_set_running_state(struct rte_timer *tim)
 static uint32_t
 timer_get_skiplist_level(unsigned curr_depth)
 {
-#ifdef RTE_LIBRTE_TIMER_DEBUG
+#ifdef RTE_DEBUG
 	static uint32_t i, count = 0;
 	static uint32_t levels[MAX_SKIPLIST_DEPTH] = {0};
 #endif
@@ -321,7 +321,7 @@ timer_get_skiplist_level(unsigned curr_depth)
 		level = curr_depth;
 	if (level >= MAX_SKIPLIST_DEPTH)
 		level = MAX_SKIPLIST_DEPTH-1;
-#ifdef RTE_LIBRTE_TIMER_DEBUG
+#ifdef RTE_DEBUG
 	count ++;
 	levels[level]++;
 	if (count % 10000 == 0)
@@ -1008,7 +1008,7 @@ rte_timer_next_ticks(void)
 static void
 __rte_timer_dump_stats(struct rte_timer_data *timer_data __rte_unused, FILE *f)
 {
-#ifdef RTE_LIBRTE_TIMER_DEBUG
+#ifdef RTE_DEBUG
 	struct rte_timer_debug_stats sum;
 	unsigned lcore_id;
 	struct priv_timer *priv_timer = timer_data->priv_timer;
@@ -1026,7 +1026,7 @@ __rte_timer_dump_stats(struct rte_timer_data *timer_data __rte_unused, FILE *f)
 	fprintf(f, "  manage = %"PRIu64"\n", sum.manage);
 	fprintf(f, "  pending = %"PRIu64"\n", sum.pending);
 #else
-	fprintf(f, "No timer statistics, RTE_LIBRTE_TIMER_DEBUG is disabled\n");
+	fprintf(f, "No timer statistics, RTE_DEBUG is disabled\n");
 #endif
 }
 
diff --git a/lib/librte_timer/rte_timer.h b/lib/librte_timer/rte_timer.h
index c6b3d450d..b4edd3f30 100644
--- a/lib/librte_timer/rte_timer.h
+++ b/lib/librte_timer/rte_timer.h
@@ -73,7 +73,7 @@ union rte_timer_status {
 	uint32_t u32;            /**< To atomic-set status + owner. */
 };
 
-#ifdef RTE_LIBRTE_TIMER_DEBUG
+#ifdef RTE_DEBUG
 /**
  * A structure that stores the timer statistics (per-lcore).
  */
-- 
2.17.1

[dpdk-dev] [PATCH v1 15/17] vhost: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_VHOST_DEBUG.
The old define is completely removed from source code and config.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base              | 1 -
 lib/librte_vhost/vhost.h        | 2 +-
 lib/librte_vhost/vhost_crypto.c | 2 +-
 lib/librte_vhost/vhost_user.c   | 2 +-
 4 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/config/common_base b/config/common_base
index 025ae7c62..1f7be1219 100644
--- a/config/common_base
+++ b/config/common_base
@@ -1031,7 +1031,6 @@ CONFIG_RTE_LIBRTE_PDUMP=y
 #
 CONFIG_RTE_LIBRTE_VHOST=n
 CONFIG_RTE_LIBRTE_VHOST_NUMA=n
-CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
 
 #
 # Compile vhost PMD
diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
index 2087d1400..ea44e3aa6 100644
--- a/lib/librte_vhost/vhost.h
+++ b/lib/librte_vhost/vhost.h
@@ -520,7 +520,7 @@ extern int vhost_data_log_level;
 		"VHOST_DATA : " fmt, ##args) :			\
 	 0)
 
-#ifdef RTE_LIBRTE_VHOST_DEBUG
+#ifdef RTE_DEBUG
 #define VHOST_MAX_PRINT_BUFF 6072
 #define PRINT_PACKET(device, addr, size, header) do { \
 	char *pkt_addr = (char *)(addr); \
diff --git a/lib/librte_vhost/vhost_crypto.c b/lib/librte_vhost/vhost_crypto.c
index 68911972b..5648e5c34 100644
--- a/lib/librte_vhost/vhost_crypto.c
+++ b/lib/librte_vhost/vhost_crypto.c
@@ -16,7 +16,7 @@
 #define IV_OFFSET		(sizeof(struct rte_crypto_op) + \
 				sizeof(struct rte_crypto_sym_op))
 
-#ifdef RTE_LIBRTE_VHOST_DEBUG
+#ifdef RTE_DEBUG
 #define VC_LOG_ERR(fmt, args...)				\
 	RTE_LOG(ERR, USER1, "[%s] %s() line %u: " fmt "\n",	\
 		"Vhost-Crypto",	__func__, __LINE__, ## args)
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index bd1be0104..dea334dfd 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -967,7 +967,7 @@ add_guest_pages(struct virtio_net *dev, struct rte_vhost_mem_region *reg,
 	return 0;
 }
 
-#ifdef RTE_LIBRTE_VHOST_DEBUG
+#ifdef RTE_DEBUG
 /* TODO: enable it only in debug mode? */
 static void
 dump_guest_pages(struct virtio_net *dev)
-- 
2.17.1

[dpdk-dev] [PATCH v1 16/17] eal: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_MALLOC_DEBUG.
The old define is completely removed from source code and config.
Tests and documentation were also updated.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 app/test/test_malloc.c                          | 4 ++--
 config/common_base                              | 1 -
 doc/guides/prog_guide/env_abstraction_layer.rst | 5 +++--
 lib/librte_eal/common/malloc_elem.c             | 2 +-
 lib/librte_eal/common/malloc_elem.h             | 4 ++--
 lib/librte_eal/common/rte_malloc.c              | 2 +-
 6 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/app/test/test_malloc.c b/app/test/test_malloc.c
index 232d3186d..61b89d0c1 100644
--- a/app/test/test_malloc.c
+++ b/app/test/test_malloc.c
@@ -641,7 +641,7 @@ test_rte_malloc_validate(void)
 	const size_t request_size = 1024;
 	size_t allocated_size;
 	char *data_ptr = rte_malloc(NULL, request_size, RTE_CACHE_LINE_SIZE);
-#ifdef RTE_MALLOC_DEBUG
+#ifdef RTE_DEBUG
 	int retval;
 	char *over_write_vals = NULL;
 #endif
@@ -663,7 +663,7 @@ test_rte_malloc_validate(void)
 	if (allocated_size < request_size)
 		err_return();
 
-#ifdef RTE_MALLOC_DEBUG
+#ifdef RTE_DEBUG
 
 	/****** change the header to be bad */
 	char save_buf[64];
diff --git a/config/common_base b/config/common_base
index 1f7be1219..ae6db0adb 100644
--- a/config/common_base
+++ b/config/common_base
@@ -107,7 +107,6 @@ CONFIG_RTE_EAL_IGB_UIO=n
 CONFIG_RTE_EAL_VFIO=n
 CONFIG_RTE_MAX_VFIO_GROUPS=64
 CONFIG_RTE_MAX_VFIO_CONTAINERS=64
-CONFIG_RTE_MALLOC_DEBUG=n
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
 CONFIG_RTE_USE_LIBBSD=n
 # Use WFE instructions to implement the rte_wait_for_equal_xxx APIs,
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index 48a2fec06..a8d2ef1a3 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -714,8 +714,9 @@ manual for more information.
 Cookies
 ~~~~~~~
 
-When CONFIG_RTE_MALLOC_DEBUG is enabled, the allocated memory contains
-overwrite protection fields to help identify buffer overflows.
+When RTE_DEBUG is enabled (e.g. by enabling "debug" option in meson setup,
+the allocated memory contains overwrite protection fields to help identify
+buffer overflows.
 
 Alignment and NUMA Constraints
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/librte_eal/common/malloc_elem.c b/lib/librte_eal/common/malloc_elem.c
index 885d00424..662adb6b9 100644
--- a/lib/librte_eal/common/malloc_elem.c
+++ b/lib/librte_eal/common/malloc_elem.c
@@ -28,7 +28,7 @@
  * to catch buggy programs. Otherwise, freed memory is set to zero
  * to avoid having to zero in zmalloc
  */
-#ifdef RTE_MALLOC_DEBUG
+#ifdef RTE_DEBUG
 #define MALLOC_POISON	       0x6b
 #else
 #define MALLOC_POISON	       0
diff --git a/lib/librte_eal/common/malloc_elem.h b/lib/librte_eal/common/malloc_elem.h
index a1e5f7f02..e5286415e 100644
--- a/lib/librte_eal/common/malloc_elem.h
+++ b/lib/librte_eal/common/malloc_elem.h
@@ -32,13 +32,13 @@ struct malloc_elem {
 	size_t size;
 	struct malloc_elem *orig_elem;
 	size_t orig_size;
-#ifdef RTE_MALLOC_DEBUG
+#ifdef RTE_DEBUG
 	uint64_t header_cookie;         /* Cookie marking start of data */
 	                                /* trailer cookie at start + size */
 #endif
 } __rte_cache_aligned;
 
-#ifndef RTE_MALLOC_DEBUG
+#ifndef RTE_DEBUG
 static const unsigned MALLOC_ELEM_TRAILER_LEN = 0;
 
 /* dummy function - just check if pointer is non-null */
diff --git a/lib/librte_eal/common/rte_malloc.c b/lib/librte_eal/common/rte_malloc.c
index d6026a2b1..912bfeb9b 100644
--- a/lib/librte_eal/common/rte_malloc.c
+++ b/lib/librte_eal/common/rte_malloc.c
@@ -78,7 +78,7 @@ rte_zmalloc_socket(const char *type, size_t size, unsigned align, int socket)
 {
 	void *ptr = rte_malloc_socket(type, size, align, socket);
 
-#ifdef RTE_MALLOC_DEBUG
+#ifdef RTE_DEBUG
 	/*
 	 * If DEBUG is enabled, then freed memory is marked with poison
 	 * value and set to zero on allocation.
-- 
2.17.1

[dpdk-dev] [PATCH v1 17/17] sched: replace library debug flag with global one

[Lukasz Wojciechowski]

Use global debug flag RTE_DEBUG instead of RTE_SCHED_DEBUG.
The old define is completely removed from source code and config.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base           |  1 -
 lib/librte_sched/rte_sched.c | 10 +++++-----
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/config/common_base b/config/common_base
index ae6db0adb..eb8b83224 100644
--- a/config/common_base
+++ b/config/common_base
@@ -976,7 +976,6 @@ CONFIG_RTE_LIBRTE_FLOW_CLASSIFY=y
 # Compile librte_sched
 #
 CONFIG_RTE_LIBRTE_SCHED=y
-CONFIG_RTE_SCHED_DEBUG=n
 CONFIG_RTE_SCHED_RED=n
 CONFIG_RTE_SCHED_COLLECT_STATS=n
 CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index c0983ddda..e19f1d959 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -1482,7 +1482,7 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
 	return 0;
 }
 
-#ifdef RTE_SCHED_DEBUG
+#ifdef RTE_DEBUG
 
 static inline int
 rte_sched_port_queue_is_empty(struct rte_sched_subport *subport,
@@ -1493,7 +1493,7 @@ rte_sched_port_queue_is_empty(struct rte_sched_subport *subport,
 	return queue->qr == queue->qw;
 }
 
-#endif /* RTE_SCHED_DEBUG */
+#endif /* RTE_DEBUG */
 
 #ifdef RTE_SCHED_COLLECT_STATS
 
@@ -1627,7 +1627,7 @@ static inline int rte_sched_port_red_drop(struct rte_sched_port *port __rte_unus
 
 #endif /* RTE_SCHED_RED */
 
-#ifdef RTE_SCHED_DEBUG
+#ifdef RTE_DEBUG
 
 static inline void
 debug_check_queue_slab(struct rte_sched_subport *subport, uint32_t bmp_pos,
@@ -1654,7 +1654,7 @@ debug_check_queue_slab(struct rte_sched_subport *subport, uint32_t bmp_pos,
 			bmp_slab, bmp_pos);
 }
 
-#endif /* RTE_SCHED_DEBUG */
+#endif /* RTE_DEBUG */
 
 static inline struct rte_sched_subport *
 rte_sched_port_subport(struct rte_sched_port *port,
@@ -2404,7 +2404,7 @@ grinder_next_pipe(struct rte_sched_port *port,
 		if (unlikely(rte_bitmap_scan(subport->bmp, &bmp_pos, &bmp_slab) <= 0))
 			return 0;
 
-#ifdef RTE_SCHED_DEBUG
+#ifdef RTE_DEBUG
 		debug_check_queue_slab(subport, bmp_pos, bmp_slab);
 #endif
 
-- 
2.17.1

Re: [dpdk-dev] [EXT] [PATCH v1 04/17] eventdev: replace library debug flag with global one

[Jerin Jacob Kollanukkaran]

> -----Original Message-----
> From: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> Sent: Saturday, April 18, 2020 3:27 AM
> To: Thomas Monjalon <thomas@monjalon.net>; Nikhil Rao
> <nikhil.rao@intel.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Erik
> Gabriel Carrillo <erik.g.carrillo@intel.com>
> Cc: dev@dpdk.org
> Subject: [EXT] [PATCH v1 04/17] eventdev: replace library debug flag with
> global one
> 
>
> Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_EVENTDEV_DEBUG.
> The old define is completely removed from source code and config.


May I know the rational for this change? Other subsystem like ethdev still have
CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n.

If we decide to make RTE_DEBUG then please submit the patch for all subsystem
across the DPDK.


> 
> Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> ---
>  config/common_base                             | 1 -
>  lib/librte_eventdev/rte_event_eth_tx_adapter.h | 2 +-
> lib/librte_eventdev/rte_event_timer_adapter.c  | 6 +++---
> lib/librte_eventdev/rte_event_timer_adapter.h  | 6 +++---
>  lib/librte_eventdev/rte_eventdev.h             | 4 ++--
>  lib/librte_eventdev/rte_eventdev_pmd.h         | 2 +-
>  6 files changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/config/common_base b/config/common_base index
> 16a8f09b6..96d5031d9 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -722,7 +722,6 @@ CONFIG_RTE_LIBRTE_PMD_ZLIB=n  # Compile generic
> event device library  #  CONFIG_RTE_LIBRTE_EVENTDEV=y -
> CONFIG_RTE_LIBRTE_EVENTDEV_DEBUG=n
>  CONFIG_RTE_EVENT_MAX_DEVS=16
>  CONFIG_RTE_EVENT_MAX_QUEUES_PER_DEV=64
>  CONFIG_RTE_EVENT_TIMER_ADAPTER_NUM_MAX=32
> diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> index 93b717af9..de13ca7f0 100644
> --- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> +++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> @@ -357,7 +357,7 @@ rte_event_eth_tx_adapter_enqueue(uint8_t dev_id,  {
>  	const struct rte_eventdev *dev = &rte_eventdevs[dev_id];
> 
> -#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	if (dev_id >= RTE_EVENT_MAX_DEVS ||
>  		!rte_eventdevs[dev_id].attached) {
>  		rte_errno = EINVAL;
> diff --git a/lib/librte_eventdev/rte_event_timer_adapter.c
> b/lib/librte_eventdev/rte_event_timer_adapter.c
> index 161e21a68..02c27b91e 100644
> --- a/lib/librte_eventdev/rte_event_timer_adapter.c
> +++ b/lib/librte_eventdev/rte_event_timer_adapter.c
> @@ -43,7 +43,7 @@ static const struct rte_event_timer_adapter_ops
> swtim_ops;
> 
>  #define EVTIM_LOG_ERR(...) EVTIM_LOG(ERR, evtim_logtype, __VA_ARGS__)
> 
> -#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> +#ifdef RTE_DEBUG
>  #define EVTIM_LOG_DBG(...) \
>  	EVTIM_LOG(DEBUG, evtim_logtype, __VA_ARGS__)  #define
> EVTIM_BUF_LOG_DBG(...) \ @@ -1008,7 +1008,7 @@
> __swtim_arm_burst(const struct rte_event_timer_adapter *adapter,
>  	struct rte_timer *tim, *tims[nb_evtims];
>  	uint64_t cycles;
> 
> -#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	/* Check that the service is running. */
>  	if (rte_service_runstate_get(adapter->data->service_id) != 1) {
>  		rte_errno = EINVAL;
> @@ -1114,7 +1114,7 @@ swtim_cancel_burst(const struct
> rte_event_timer_adapter *adapter,
>  	uint64_t opaque;
>  	struct swtim *sw = swtim_pmd_priv(adapter);
> 
> -#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	/* Check that the service is running. */
>  	if (rte_service_runstate_get(adapter->data->service_id) != 1) {
>  		rte_errno = EINVAL;
> diff --git a/lib/librte_eventdev/rte_event_timer_adapter.h
> b/lib/librte_eventdev/rte_event_timer_adapter.h
> index 7f6dc5c29..8e7e2b0e3 100644
> --- a/lib/librte_eventdev/rte_event_timer_adapter.h
> +++ b/lib/librte_eventdev/rte_event_timer_adapter.h
> @@ -575,7 +575,7 @@ rte_event_timer_arm_burst(const struct
> rte_event_timer_adapter *adapter,
>  			  struct rte_event_timer **evtims,
>  			  uint16_t nb_evtims)
>  {
> -#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	ADAPTER_VALID_OR_ERR_RET(adapter, -EINVAL);
>  	FUNC_PTR_OR_ERR_RET(adapter->arm_burst, -EINVAL);  #endif @@ -
> 618,7 +618,7 @@ rte_event_timer_arm_tmo_tick_burst(
>  			const uint64_t timeout_ticks,
>  			const uint16_t nb_evtims)
>  {
> -#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	ADAPTER_VALID_OR_ERR_RET(adapter, -EINVAL);
>  	FUNC_PTR_OR_ERR_RET(adapter->arm_tmo_tick_burst, -EINVAL);
> #endif @@ -651,7 +651,7 @@ rte_event_timer_cancel_burst(const struct
> rte_event_timer_adapter *adapter,
>  			     struct rte_event_timer **evtims,
>  			     uint16_t nb_evtims)
>  {
> -#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	ADAPTER_VALID_OR_ERR_RET(adapter, -EINVAL);
>  	FUNC_PTR_OR_ERR_RET(adapter->cancel_burst, -EINVAL);  #endif diff -
> -git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
> index 226f352ad..cb237fdd0 100644
> --- a/lib/librte_eventdev/rte_eventdev.h
> +++ b/lib/librte_eventdev/rte_eventdev.h
> @@ -1332,7 +1332,7 @@ __rte_event_enqueue_burst(uint8_t dev_id, uint8_t
> port_id,  {
>  	const struct rte_eventdev *dev = &rte_eventdevs[dev_id];
> 
> -#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	if (dev_id >= RTE_EVENT_MAX_DEVS ||
> !rte_eventdevs[dev_id].attached) {
>  		rte_errno = EINVAL;
>  		return 0;
> @@ -1609,7 +1609,7 @@ rte_event_dequeue_burst(uint8_t dev_id, uint8_t
> port_id, struct rte_event ev[],  {
>  	struct rte_eventdev *dev = &rte_eventdevs[dev_id];
> 
> -#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	if (dev_id >= RTE_EVENT_MAX_DEVS ||
> !rte_eventdevs[dev_id].attached) {
>  		rte_errno = EINVAL;
>  		return 0;
> diff --git a/lib/librte_eventdev/rte_eventdev_pmd.h
> b/lib/librte_eventdev/rte_eventdev_pmd.h
> index d118b9e5b..090cb4309 100644
> --- a/lib/librte_eventdev/rte_eventdev_pmd.h
> +++ b/lib/librte_eventdev/rte_eventdev_pmd.h
> @@ -34,7 +34,7 @@ extern "C" {
>  		RTE_FMT("%s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,)
> "\n", \
>  			__func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__,)))
> 
> -#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> +#ifdef RTE_DEBUG
>  #define RTE_EDEV_LOG_DEBUG(...) \
>  	RTE_LOG(DEBUG, EVENTDEV, \
>  		RTE_FMT("%s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,)
> "\n", \
> --
> 2.17.1

Re: [dpdk-dev] [EXT] [PATCH v1 04/17] eventdev: replace library debug flag with global one

[Thomas Monjalon]

18/04/2020 11:41, Jerin Jacob Kollanukkaran:
> From: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> > Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_EVENTDEV_DEBUG.
> > The old define is completely removed from source code and config.
> 
> 
> May I know the rational for this change?

You know the rationale, it was discussed several times in Technical Board:
we are limiting the number of compilation options, and meson config does
not propose them.

> Other subsystem like ethdev still have CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n.

No, look at the other patches in the series.

> If we decide to make RTE_DEBUG then please submit the patch for all subsystem
> across the DPDK.

Yes, this is what Lukasz did.

Re: [dpdk-dev] [EXT] [PATCH v1 04/17] eventdev: replace library debug flag with global one

[Jerin Jacob]

On Sat, Apr 18, 2020 at 3:23 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 18/04/2020 11:41, Jerin Jacob Kollanukkaran:
> > From: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> > > Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_EVENTDEV_DEBUG.
> > > The old define is completely removed from source code and config.
> >
> >
> > May I know the rational for this change?
>
> You know the rationale, it was discussed several times in Technical Board:

If I already know the rationale, Why should I ask in ml?


> we are limiting the number of compilation options, and meson config does
> not propose them.
>
> > Other subsystem like ethdev still have CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n.
>
> No, look at the other patches in the series.
>
> > If we decide to make RTE_DEBUG then please submit the patch for all subsystem
> > across the DPDK.
>
> Yes, this is what Lukasz did.

I missed the series. I just thought it is a single email due to email
filters. My bad.


>
>
>

Re: [dpdk-dev] [EXT] [PATCH v1 04/17] eventdev: replace library debug flag with global one

[Thomas Monjalon]

18/04/2020 12:05, Jerin Jacob:
> On Sat, Apr 18, 2020 at 3:23 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 18/04/2020 11:41, Jerin Jacob Kollanukkaran:
> > > From: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> > > > Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_EVENTDEV_DEBUG.
> > > > The old define is completely removed from source code and config.
> > >
> > >
> > > May I know the rational for this change?
> >
> > You know the rationale, it was discussed several times in Technical Board:
> 
> If I already know the rationale, Why should I ask in ml?

I meant you knew but you probably did not connect previous discussions
with this patch. That's why I explain below, no problem.

> > we are limiting the number of compilation options, and meson config does
> > not propose them.
> >
> > > Other subsystem like ethdev still have CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n.
> >
> > No, look at the other patches in the series.
> >
> > > If we decide to make RTE_DEBUG then please submit the patch for all subsystem
> > > across the DPDK.
> >
> > Yes, this is what Lukasz did.
> 
> I missed the series. I just thought it is a single email due to email
> filters. My bad.

Re: [dpdk-dev] [PATCH v1 17/17] sched: replace library debug flag with global one

[Dumitrescu, Cristian]

> -----Original Message-----
> From: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> Sent: Friday, April 17, 2020 10:58 PM
> To: Thomas Monjalon <thomas@monjalon.net>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; Singh, Jasvinder
> <jasvinder.singh@intel.com>
> Cc: dev@dpdk.org
> Subject: [PATCH v1 17/17] sched: replace library debug flag with global one
> 
> Use global debug flag RTE_DEBUG instead of RTE_SCHED_DEBUG.
> The old define is completely removed from source code and config.
> 
> Signed-off-by: Lukasz Wojciechowski
> <l.wojciechow@partner.samsung.com>
> ---
>  config/common_base           |  1 -
>  lib/librte_sched/rte_sched.c | 10 +++++-----
>  2 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/config/common_base b/config/common_base
> index ae6db0adb..eb8b83224 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -976,7 +976,6 @@ CONFIG_RTE_LIBRTE_FLOW_CLASSIFY=y
>  # Compile librte_sched
>  #
>  CONFIG_RTE_LIBRTE_SCHED=y
> -CONFIG_RTE_SCHED_DEBUG=n
>  CONFIG_RTE_SCHED_RED=n
>  CONFIG_RTE_SCHED_COLLECT_STATS=n
>  CONFIG_RTE_SCHED_SUBPORT_TC_OV=n
> diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> index c0983ddda..e19f1d959 100644
> --- a/lib/librte_sched/rte_sched.c
> +++ b/lib/librte_sched/rte_sched.c
> @@ -1482,7 +1482,7 @@ rte_sched_queue_read_stats(struct
> rte_sched_port *port,
>  	return 0;
>  }
> 
> -#ifdef RTE_SCHED_DEBUG
> +#ifdef RTE_DEBUG
> 
>  static inline int
>  rte_sched_port_queue_is_empty(struct rte_sched_subport *subport,
> @@ -1493,7 +1493,7 @@ rte_sched_port_queue_is_empty(struct
> rte_sched_subport *subport,
>  	return queue->qr == queue->qw;
>  }
> 
> -#endif /* RTE_SCHED_DEBUG */
> +#endif /* RTE_DEBUG */
> 
>  #ifdef RTE_SCHED_COLLECT_STATS
> 
> @@ -1627,7 +1627,7 @@ static inline int rte_sched_port_red_drop(struct
> rte_sched_port *port __rte_unus
> 
>  #endif /* RTE_SCHED_RED */
> 
> -#ifdef RTE_SCHED_DEBUG
> +#ifdef RTE_DEBUG
> 
>  static inline void
>  debug_check_queue_slab(struct rte_sched_subport *subport, uint32_t
> bmp_pos,
> @@ -1654,7 +1654,7 @@ debug_check_queue_slab(struct
> rte_sched_subport *subport, uint32_t bmp_pos,
>  			bmp_slab, bmp_pos);
>  }
> 
> -#endif /* RTE_SCHED_DEBUG */
> +#endif /* RTE_DEBUG */
> 
>  static inline struct rte_sched_subport *
>  rte_sched_port_subport(struct rte_sched_port *port,
> @@ -2404,7 +2404,7 @@ grinder_next_pipe(struct rte_sched_port *port,
>  		if (unlikely(rte_bitmap_scan(subport->bmp, &bmp_pos,
> &bmp_slab) <= 0))
>  			return 0;
> 
> -#ifdef RTE_SCHED_DEBUG
> +#ifdef RTE_DEBUG
>  		debug_check_queue_slab(subport, bmp_pos, bmp_slab);
>  #endif
> 
> --
> 2.17.1

The approach in this series does not make any sense to me: what if you want to debug just this library instead of the entire DPDK? We need to be able to enable debug for a single library at a time, as opposed to the user being flooded with unwanted debug messages from all the libraries.

NAK from me.

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Dumitrescu, Cristian]

> -----Original Message-----
> From: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> Sent: Friday, April 17, 2020 10:57 PM
> To: Thomas Monjalon <thomas@monjalon.net>; Igor Russkikh
> <igor.russkikh@aquantia.com>; Pavel Belous <pavel.belous@aquantia.com>;
> Lu, Wenzhuo <wenzhuo.lu@intel.com>; Marcin Wojtas
> <mw@semihalf.com>; Michal Krawczyk <mk@semihalf.com>; Guy Tzalik
> <gtzalik@amazon.com>; Evgeny Schemeilin <evgenys@amazon.com>; Igor
> Chauskin <igorch@amazon.com>; John Daley <johndale@cisco.com>; Hyong
> Youb Kim <hyonkim@cisco.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> Wang, Xiao W <xiao.w.wang@intel.com>; Ziyang Xuan
> <xuanziyang2@huawei.com>; Xiaoyun Wang
> <cloud.wangxiaoyun@huawei.com>; Guoyang Zhou
> <zhouguoyang@huawei.com>; Wei Hu (Xavier)
> <xavier.huwei@huawei.com>; Min Hu (Connor) <humin29@huawei.com>;
> Yisen Zhuang <yisen.zhuang@huawei.com>; Xing, Beilei
> <beilei.xing@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Rasesh Mody <rmody@marvell.com>;
> Shahed Shaikh <shshaikh@marvell.com>; Singh, Jasvinder
> <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; Maxime Coquelin
> <maxime.coquelin@redhat.com>; Wang, Zhihong
> <zhihong.wang@intel.com>; Ye, Xiaolong <xiaolong.ye@intel.com>; Yong
> Wang <yongwang@vmware.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> Andrew Rybchenko <arybchenko@solarflare.com>; Olivier Matz
> <olivier.matz@6wind.com>
> Cc: dev@dpdk.org
> Subject: [PATCH v1 03/17] ethdev: replace library debug flag with global one
> 
> Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_ETHDEV_DEBUG.
> The old define is completely removed from source code and config.
> The changes were applied also to all drivers using this flag.
> 
> Signed-off-by: Lukasz Wojciechowski
> <l.wojciechow@partner.samsung.com>
> ---
>  config/common_base                           |  1 -
>  drivers/net/atlantic/atl_rxtx.c              |  2 +-
>  drivers/net/e1000/em_rxtx.c                  |  2 +-
>  drivers/net/e1000/igb_rxtx.c                 |  2 +-
>  drivers/net/ena/ena_ethdev.c                 |  2 +-
>  drivers/net/enic/enic_rxtx.c                 |  2 +-
>  drivers/net/fm10k/fm10k_rxtx.c               |  2 +-
>  drivers/net/hinic/hinic_pmd_tx.c             |  2 +-
>  drivers/net/hns3/hns3_rxtx.c                 |  2 +-
>  drivers/net/i40e/i40e_rxtx.c                 |  2 +-
>  drivers/net/iavf/iavf_rxtx.c                 |  2 +-
>  drivers/net/ice/ice_rxtx.c                   |  2 +-
>  drivers/net/ixgbe/ixgbe_rxtx.c               |  2 +-
>  drivers/net/qede/qede_rxtx.c                 |  4 ++--
>  drivers/net/softnic/rte_eth_softnic.c        |  2 +-
>  drivers/net/softnic/rte_eth_softnic_thread.c |  2 +-
>  drivers/net/virtio/virtio_rxtx.c             |  2 +-
>  drivers/net/vmxnet3/vmxnet3_rxtx.c           |  2 +-
>  lib/librte_ethdev/rte_ethdev.h               | 16 ++++++++--------
>  lib/librte_net/rte_net.h                     |  4 ++--
>  20 files changed, 28 insertions(+), 29 deletions(-)
> 
> diff --git a/config/common_base b/config/common_base
> index c5be57f11..16a8f09b6 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -149,7 +149,6 @@ CONFIG_RTE_LIBRTE_KVARGS=y
>  # Compile generic ethernet library
>  #
>  CONFIG_RTE_LIBRTE_ETHER=y
> -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
>  CONFIG_RTE_MAX_ETHPORTS=32
>  CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
>  CONFIG_RTE_LIBRTE_IEEE1588=n
> diff --git a/drivers/net/atlantic/atl_rxtx.c b/drivers/net/atlantic/atl_rxtx.c
> index 449ffd454..eae54df22 100644
> --- a/drivers/net/atlantic/atl_rxtx.c
> +++ b/drivers/net/atlantic/atl_rxtx.c
> @@ -821,7 +821,7 @@ atl_prep_pkts(__rte_unused void *tx_queue, struct
> rte_mbuf **tx_pkts,
>  			return i;
>  		}
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/drivers/net/e1000/em_rxtx.c b/drivers/net/e1000/em_rxtx.c
> index 49c53712a..c4083ff00 100644
> --- a/drivers/net/e1000/em_rxtx.c
> +++ b/drivers/net/e1000/em_rxtx.c
> @@ -626,7 +626,7 @@ eth_em_prep_pkts(__rte_unused void *tx_queue,
> struct rte_mbuf **tx_pkts,
>  			return i;
>  		}
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
> index 684fa4ad8..6a78f26e6 100644
> --- a/drivers/net/e1000/igb_rxtx.c
> +++ b/drivers/net/e1000/igb_rxtx.c
> @@ -641,7 +641,7 @@ eth_igb_prep_pkts(__rte_unused void *tx_queue,
> struct rte_mbuf **tx_pkts,
>  			return i;
>  		}
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
> index 665afee4f..b9855e91b 100644
> --- a/drivers/net/ena/ena_ethdev.c
> +++ b/drivers/net/ena/ena_ethdev.c
> @@ -2145,7 +2145,7 @@ eth_ena_prep_pkts(void *tx_queue, struct
> rte_mbuf **tx_pkts,
>  			return i;
>  		}
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/drivers/net/enic/enic_rxtx.c b/drivers/net/enic/enic_rxtx.c
> index 6a8718c08..c42d563b4 100644
> --- a/drivers/net/enic/enic_rxtx.c
> +++ b/drivers/net/enic/enic_rxtx.c
> @@ -414,7 +414,7 @@ uint16_t enic_prep_pkts(void *tx_queue, struct
> rte_mbuf **tx_pkts,
>  			rte_errno = ENOTSUP;
>  			return i;
>  		}
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/drivers/net/fm10k/fm10k_rxtx.c
> b/drivers/net/fm10k/fm10k_rxtx.c
> index 4accaa2cd..43d773f08 100644
> --- a/drivers/net/fm10k/fm10k_rxtx.c
> +++ b/drivers/net/fm10k/fm10k_rxtx.c
> @@ -710,7 +710,7 @@ fm10k_prep_pkts(__rte_unused void *tx_queue,
> struct rte_mbuf **tx_pkts,
>  			return i;
>  		}
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/drivers/net/hinic/hinic_pmd_tx.c
> b/drivers/net/hinic/hinic_pmd_tx.c
> index 64ec2c119..41d5a25b6 100644
> --- a/drivers/net/hinic/hinic_pmd_tx.c
> +++ b/drivers/net/hinic/hinic_pmd_tx.c
> @@ -804,7 +804,7 @@ hinic_tx_offload_pkt_prepare(struct rte_mbuf *m,
>  	    !(ol_flags & PKT_TX_TUNNEL_VXLAN))
>  		return -ENOTSUP;
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	if (rte_validate_tx_offload(m) != 0)
>  		return -EINVAL;
>  #endif
> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
> index ec6d19f58..45aa64b70 100644
> --- a/drivers/net/hns3/hns3_rxtx.c
> +++ b/drivers/net/hns3/hns3_rxtx.c
> @@ -2296,7 +2296,7 @@ hns3_prep_pkts(__rte_unused void *tx_queue,
> struct rte_mbuf **tx_pkts,
>  			return i;
>  		}
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index 5e7c86ed8..282baf514 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -1499,7 +1499,7 @@ i40e_prep_pkts(__rte_unused void *tx_queue,
> struct rte_mbuf **tx_pkts,
>  			return i;
>  		}
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
> index 85d9a8e3b..8122d35be 100644
> --- a/drivers/net/iavf/iavf_rxtx.c
> +++ b/drivers/net/iavf/iavf_rxtx.c
> @@ -1689,7 +1689,7 @@ iavf_prep_pkts(__rte_unused void *tx_queue,
> struct rte_mbuf **tx_pkts,
>  			return i;
>  		}
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
> index 1c9f31efd..fd8ed2573 100644
> --- a/drivers/net/ice/ice_rxtx.c
> +++ b/drivers/net/ice/ice_rxtx.c
> @@ -3037,7 +3037,7 @@ ice_prep_pkts(__rte_unused void *tx_queue,
> struct rte_mbuf **tx_pkts,
>  			return i;
>  		}
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index 2e20e18c7..6964c4e52 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -992,7 +992,7 @@ ixgbe_prep_pkts(void *tx_queue, struct rte_mbuf
> **tx_pkts, uint16_t nb_pkts)
>  			return i;
>  		}
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
> index b81788ca4..646eb2275 100644
> --- a/drivers/net/qede/qede_rxtx.c
> +++ b/drivers/net/qede/qede_rxtx.c
> @@ -2156,7 +2156,7 @@ qede_xmit_prep_pkts(__rte_unused void *p_txq,
> struct rte_mbuf **tx_pkts,
>  	uint64_t ol_flags;
>  	struct rte_mbuf *m;
>  	uint16_t i;
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	int ret;
>  #endif
> 
> @@ -2196,7 +2196,7 @@ qede_xmit_prep_pkts(__rte_unused void *p_txq,
> struct rte_mbuf **tx_pkts,
>  			break;
>  		}
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/drivers/net/softnic/rte_eth_softnic.c
> b/drivers/net/softnic/rte_eth_softnic.c
> index 11723778f..b5b169ff7 100644
> --- a/drivers/net/softnic/rte_eth_softnic.c
> +++ b/drivers/net/softnic/rte_eth_softnic.c
> @@ -704,7 +704,7 @@ rte_pmd_softnic_manage(uint16_t port_id)
>  	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
>  	struct pmd_internals *softnic;
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
>  #endif
> 
> diff --git a/drivers/net/softnic/rte_eth_softnic_thread.c
> b/drivers/net/softnic/rte_eth_softnic_thread.c
> index d610b1617..2f7c3a838 100644
> --- a/drivers/net/softnic/rte_eth_softnic_thread.c
> +++ b/drivers/net/softnic/rte_eth_softnic_thread.c
> @@ -3093,7 +3093,7 @@ rte_pmd_softnic_run(uint16_t port_id)
>  {
>  	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
>  #endif
> 
> diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
> index 752faa0f6..02eaf38e3 100644
> --- a/drivers/net/virtio/virtio_rxtx.c
> +++ b/drivers/net/virtio/virtio_rxtx.c
> @@ -1979,7 +1979,7 @@ virtio_xmit_pkts_prepare(void *tx_queue
> __rte_unused, struct rte_mbuf **tx_pkts,
>  	for (nb_tx = 0; nb_tx < nb_pkts; nb_tx++) {
>  		struct rte_mbuf *m = tx_pkts[nb_tx];
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		error = rte_validate_tx_offload(m);
>  		if (unlikely(error)) {
>  			rte_errno = -error;
> diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c
> b/drivers/net/vmxnet3/vmxnet3_rxtx.c
> index dd99684be..a801290ff 100644
> --- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
> +++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
> @@ -373,7 +373,7 @@ vmxnet3_prep_pkts(__rte_unused void *tx_queue,
> struct rte_mbuf **tx_pkts,
>  			return i;
>  		}
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  		ret = rte_validate_tx_offload(m);
>  		if (ret != 0) {
>  			rte_errno = -ret;
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index e9e3a1699..f314b57c7 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -4375,7 +4375,7 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t
> queue_id,
>  	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
>  	uint16_t nb_rx;
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
>  	RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
> 
> @@ -4498,11 +4498,11 @@ rte_eth_rx_descriptor_status(uint16_t port_id,
> uint16_t queue_id,
>  	struct rte_eth_dev *dev;
>  	void *rxq;
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>  #endif
>  	dev = &rte_eth_devices[port_id];
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	if (queue_id >= dev->data->nb_rx_queues)
>  		return -ENODEV;
>  #endif
> @@ -4555,11 +4555,11 @@ static inline int
> rte_eth_tx_descriptor_status(uint16_t port_id,
>  	struct rte_eth_dev *dev;
>  	void *txq;
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>  #endif
>  	dev = &rte_eth_devices[port_id];
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	if (queue_id >= dev->data->nb_tx_queues)
>  		return -ENODEV;
>  #endif
> @@ -4641,7 +4641,7 @@ rte_eth_tx_burst(uint16_t port_id, uint16_t
> queue_id,
>  {
>  	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
>  	RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_pkt_burst, 0);
> 
> @@ -4727,7 +4727,7 @@ rte_eth_tx_prepare(uint16_t port_id, uint16_t
> queue_id,
>  {
>  	struct rte_eth_dev *dev;
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	if (!rte_eth_dev_is_valid_port(port_id)) {
>  		RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
>  		rte_errno = EINVAL;
> @@ -4737,7 +4737,7 @@ rte_eth_tx_prepare(uint16_t port_id, uint16_t
> queue_id,
> 
>  	dev = &rte_eth_devices[port_id];
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	if (queue_id >= dev->data->nb_tx_queues) {
>  		RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n",
> queue_id);
>  		rte_errno = EINVAL;
> diff --git a/lib/librte_net/rte_net.h b/lib/librte_net/rte_net.h
> index 1560ecfa4..9a9732189 100644
> --- a/lib/librte_net/rte_net.h
> +++ b/lib/librte_net/rte_net.h
> @@ -120,7 +120,7 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf
> *m, uint64_t ol_flags)
>  	struct rte_udp_hdr *udp_hdr;
>  	uint64_t inner_l3_offset = m->l2_len;
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	/*
>  	 * Does packet set any of available offloads?
>  	 * Mainly it is required to avoid fragmented headers check if
> @@ -133,7 +133,7 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf
> *m, uint64_t ol_flags)
>  	if (ol_flags & (PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IPV6))
>  		inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
> 
> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> +#ifdef RTE_DEBUG
>  	/*
>  	 * Check if headers are fragmented.
>  	 * The check could be less strict depending on which offloads are
> --
> 2.17.1

The approach in this series does not make any sense to me: what if you want to debug just this library instead of the entire DPDK? We need to be able to enable debug for a single library at a time, as opposed to the user being flooded with unwanted debug messages from all the libraries.

NAK from me.

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Ananyev, Konstantin]

> 
> 
> 
> > -----Original Message-----
> > From: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> > Sent: Friday, April 17, 2020 10:57 PM
> > To: Thomas Monjalon <thomas@monjalon.net>; Igor Russkikh
> > <igor.russkikh@aquantia.com>; Pavel Belous <pavel.belous@aquantia.com>;
> > Lu, Wenzhuo <wenzhuo.lu@intel.com>; Marcin Wojtas
> > <mw@semihalf.com>; Michal Krawczyk <mk@semihalf.com>; Guy Tzalik
> > <gtzalik@amazon.com>; Evgeny Schemeilin <evgenys@amazon.com>; Igor
> > Chauskin <igorch@amazon.com>; John Daley <johndale@cisco.com>; Hyong
> > Youb Kim <hyonkim@cisco.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> > Wang, Xiao W <xiao.w.wang@intel.com>; Ziyang Xuan
> > <xuanziyang2@huawei.com>; Xiaoyun Wang
> > <cloud.wangxiaoyun@huawei.com>; Guoyang Zhou
> > <zhouguoyang@huawei.com>; Wei Hu (Xavier)
> > <xavier.huwei@huawei.com>; Min Hu (Connor) <humin29@huawei.com>;
> > Yisen Zhuang <yisen.zhuang@huawei.com>; Xing, Beilei
> > <beilei.xing@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> > <qiming.yang@intel.com>; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>; Rasesh Mody <rmody@marvell.com>;
> > Shahed Shaikh <shshaikh@marvell.com>; Singh, Jasvinder
> > <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> > <cristian.dumitrescu@intel.com>; Maxime Coquelin
> > <maxime.coquelin@redhat.com>; Wang, Zhihong
> > <zhihong.wang@intel.com>; Ye, Xiaolong <xiaolong.ye@intel.com>; Yong
> > Wang <yongwang@vmware.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> > Andrew Rybchenko <arybchenko@solarflare.com>; Olivier Matz
> > <olivier.matz@6wind.com>
> > Cc: dev@dpdk.org
> > Subject: [PATCH v1 03/17] ethdev: replace library debug flag with global one
> >
> > Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_ETHDEV_DEBUG.
> > The old define is completely removed from source code and config.
> > The changes were applied also to all drivers using this flag.
> >
> > Signed-off-by: Lukasz Wojciechowski
> > <l.wojciechow@partner.samsung.com>
> > ---
> >  config/common_base                           |  1 -
> >  drivers/net/atlantic/atl_rxtx.c              |  2 +-
> >  drivers/net/e1000/em_rxtx.c                  |  2 +-
> >  drivers/net/e1000/igb_rxtx.c                 |  2 +-
> >  drivers/net/ena/ena_ethdev.c                 |  2 +-
> >  drivers/net/enic/enic_rxtx.c                 |  2 +-
> >  drivers/net/fm10k/fm10k_rxtx.c               |  2 +-
> >  drivers/net/hinic/hinic_pmd_tx.c             |  2 +-
> >  drivers/net/hns3/hns3_rxtx.c                 |  2 +-
> >  drivers/net/i40e/i40e_rxtx.c                 |  2 +-
> >  drivers/net/iavf/iavf_rxtx.c                 |  2 +-
> >  drivers/net/ice/ice_rxtx.c                   |  2 +-
> >  drivers/net/ixgbe/ixgbe_rxtx.c               |  2 +-
> >  drivers/net/qede/qede_rxtx.c                 |  4 ++--
> >  drivers/net/softnic/rte_eth_softnic.c        |  2 +-
> >  drivers/net/softnic/rte_eth_softnic_thread.c |  2 +-
> >  drivers/net/virtio/virtio_rxtx.c             |  2 +-
> >  drivers/net/vmxnet3/vmxnet3_rxtx.c           |  2 +-
> >  lib/librte_ethdev/rte_ethdev.h               | 16 ++++++++--------
> >  lib/librte_net/rte_net.h                     |  4 ++--
> >  20 files changed, 28 insertions(+), 29 deletions(-)
> >
> > diff --git a/config/common_base b/config/common_base
> > index c5be57f11..16a8f09b6 100644
> > --- a/config/common_base
> > +++ b/config/common_base
> > @@ -149,7 +149,6 @@ CONFIG_RTE_LIBRTE_KVARGS=y
> >  # Compile generic ethernet library
> >  #
> >  CONFIG_RTE_LIBRTE_ETHER=y
> > -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
> >  CONFIG_RTE_MAX_ETHPORTS=32
> >  CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
> >  CONFIG_RTE_LIBRTE_IEEE1588=n
> > diff --git a/drivers/net/atlantic/atl_rxtx.c b/drivers/net/atlantic/atl_rxtx.c
> > index 449ffd454..eae54df22 100644
> > --- a/drivers/net/atlantic/atl_rxtx.c
> > +++ b/drivers/net/atlantic/atl_rxtx.c
> > @@ -821,7 +821,7 @@ atl_prep_pkts(__rte_unused void *tx_queue, struct
> > rte_mbuf **tx_pkts,
> >  			return i;
> >  		}
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/drivers/net/e1000/em_rxtx.c b/drivers/net/e1000/em_rxtx.c
> > index 49c53712a..c4083ff00 100644
> > --- a/drivers/net/e1000/em_rxtx.c
> > +++ b/drivers/net/e1000/em_rxtx.c
> > @@ -626,7 +626,7 @@ eth_em_prep_pkts(__rte_unused void *tx_queue,
> > struct rte_mbuf **tx_pkts,
> >  			return i;
> >  		}
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
> > index 684fa4ad8..6a78f26e6 100644
> > --- a/drivers/net/e1000/igb_rxtx.c
> > +++ b/drivers/net/e1000/igb_rxtx.c
> > @@ -641,7 +641,7 @@ eth_igb_prep_pkts(__rte_unused void *tx_queue,
> > struct rte_mbuf **tx_pkts,
> >  			return i;
> >  		}
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
> > index 665afee4f..b9855e91b 100644
> > --- a/drivers/net/ena/ena_ethdev.c
> > +++ b/drivers/net/ena/ena_ethdev.c
> > @@ -2145,7 +2145,7 @@ eth_ena_prep_pkts(void *tx_queue, struct
> > rte_mbuf **tx_pkts,
> >  			return i;
> >  		}
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/drivers/net/enic/enic_rxtx.c b/drivers/net/enic/enic_rxtx.c
> > index 6a8718c08..c42d563b4 100644
> > --- a/drivers/net/enic/enic_rxtx.c
> > +++ b/drivers/net/enic/enic_rxtx.c
> > @@ -414,7 +414,7 @@ uint16_t enic_prep_pkts(void *tx_queue, struct
> > rte_mbuf **tx_pkts,
> >  			rte_errno = ENOTSUP;
> >  			return i;
> >  		}
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/drivers/net/fm10k/fm10k_rxtx.c
> > b/drivers/net/fm10k/fm10k_rxtx.c
> > index 4accaa2cd..43d773f08 100644
> > --- a/drivers/net/fm10k/fm10k_rxtx.c
> > +++ b/drivers/net/fm10k/fm10k_rxtx.c
> > @@ -710,7 +710,7 @@ fm10k_prep_pkts(__rte_unused void *tx_queue,
> > struct rte_mbuf **tx_pkts,
> >  			return i;
> >  		}
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/drivers/net/hinic/hinic_pmd_tx.c
> > b/drivers/net/hinic/hinic_pmd_tx.c
> > index 64ec2c119..41d5a25b6 100644
> > --- a/drivers/net/hinic/hinic_pmd_tx.c
> > +++ b/drivers/net/hinic/hinic_pmd_tx.c
> > @@ -804,7 +804,7 @@ hinic_tx_offload_pkt_prepare(struct rte_mbuf *m,
> >  	    !(ol_flags & PKT_TX_TUNNEL_VXLAN))
> >  		return -ENOTSUP;
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	if (rte_validate_tx_offload(m) != 0)
> >  		return -EINVAL;
> >  #endif
> > diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
> > index ec6d19f58..45aa64b70 100644
> > --- a/drivers/net/hns3/hns3_rxtx.c
> > +++ b/drivers/net/hns3/hns3_rxtx.c
> > @@ -2296,7 +2296,7 @@ hns3_prep_pkts(__rte_unused void *tx_queue,
> > struct rte_mbuf **tx_pkts,
> >  			return i;
> >  		}
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> > index 5e7c86ed8..282baf514 100644
> > --- a/drivers/net/i40e/i40e_rxtx.c
> > +++ b/drivers/net/i40e/i40e_rxtx.c
> > @@ -1499,7 +1499,7 @@ i40e_prep_pkts(__rte_unused void *tx_queue,
> > struct rte_mbuf **tx_pkts,
> >  			return i;
> >  		}
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
> > index 85d9a8e3b..8122d35be 100644
> > --- a/drivers/net/iavf/iavf_rxtx.c
> > +++ b/drivers/net/iavf/iavf_rxtx.c
> > @@ -1689,7 +1689,7 @@ iavf_prep_pkts(__rte_unused void *tx_queue,
> > struct rte_mbuf **tx_pkts,
> >  			return i;
> >  		}
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
> > index 1c9f31efd..fd8ed2573 100644
> > --- a/drivers/net/ice/ice_rxtx.c
> > +++ b/drivers/net/ice/ice_rxtx.c
> > @@ -3037,7 +3037,7 @@ ice_prep_pkts(__rte_unused void *tx_queue,
> > struct rte_mbuf **tx_pkts,
> >  			return i;
> >  		}
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> > index 2e20e18c7..6964c4e52 100644
> > --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> > +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> > @@ -992,7 +992,7 @@ ixgbe_prep_pkts(void *tx_queue, struct rte_mbuf
> > **tx_pkts, uint16_t nb_pkts)
> >  			return i;
> >  		}
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
> > index b81788ca4..646eb2275 100644
> > --- a/drivers/net/qede/qede_rxtx.c
> > +++ b/drivers/net/qede/qede_rxtx.c
> > @@ -2156,7 +2156,7 @@ qede_xmit_prep_pkts(__rte_unused void *p_txq,
> > struct rte_mbuf **tx_pkts,
> >  	uint64_t ol_flags;
> >  	struct rte_mbuf *m;
> >  	uint16_t i;
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	int ret;
> >  #endif
> >
> > @@ -2196,7 +2196,7 @@ qede_xmit_prep_pkts(__rte_unused void *p_txq,
> > struct rte_mbuf **tx_pkts,
> >  			break;
> >  		}
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/drivers/net/softnic/rte_eth_softnic.c
> > b/drivers/net/softnic/rte_eth_softnic.c
> > index 11723778f..b5b169ff7 100644
> > --- a/drivers/net/softnic/rte_eth_softnic.c
> > +++ b/drivers/net/softnic/rte_eth_softnic.c
> > @@ -704,7 +704,7 @@ rte_pmd_softnic_manage(uint16_t port_id)
> >  	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> >  	struct pmd_internals *softnic;
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> >  #endif
> >
> > diff --git a/drivers/net/softnic/rte_eth_softnic_thread.c
> > b/drivers/net/softnic/rte_eth_softnic_thread.c
> > index d610b1617..2f7c3a838 100644
> > --- a/drivers/net/softnic/rte_eth_softnic_thread.c
> > +++ b/drivers/net/softnic/rte_eth_softnic_thread.c
> > @@ -3093,7 +3093,7 @@ rte_pmd_softnic_run(uint16_t port_id)
> >  {
> >  	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> >  #endif
> >
> > diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
> > index 752faa0f6..02eaf38e3 100644
> > --- a/drivers/net/virtio/virtio_rxtx.c
> > +++ b/drivers/net/virtio/virtio_rxtx.c
> > @@ -1979,7 +1979,7 @@ virtio_xmit_pkts_prepare(void *tx_queue
> > __rte_unused, struct rte_mbuf **tx_pkts,
> >  	for (nb_tx = 0; nb_tx < nb_pkts; nb_tx++) {
> >  		struct rte_mbuf *m = tx_pkts[nb_tx];
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		error = rte_validate_tx_offload(m);
> >  		if (unlikely(error)) {
> >  			rte_errno = -error;
> > diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c
> > b/drivers/net/vmxnet3/vmxnet3_rxtx.c
> > index dd99684be..a801290ff 100644
> > --- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
> > +++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
> > @@ -373,7 +373,7 @@ vmxnet3_prep_pkts(__rte_unused void *tx_queue,
> > struct rte_mbuf **tx_pkts,
> >  			return i;
> >  		}
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  		ret = rte_validate_tx_offload(m);
> >  		if (ret != 0) {
> >  			rte_errno = -ret;
> > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> > index e9e3a1699..f314b57c7 100644
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > @@ -4375,7 +4375,7 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t
> > queue_id,
> >  	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> >  	uint16_t nb_rx;
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> >  	RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
> >
> > @@ -4498,11 +4498,11 @@ rte_eth_rx_descriptor_status(uint16_t port_id,
> > uint16_t queue_id,
> >  	struct rte_eth_dev *dev;
> >  	void *rxq;
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> >  #endif
> >  	dev = &rte_eth_devices[port_id];
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	if (queue_id >= dev->data->nb_rx_queues)
> >  		return -ENODEV;
> >  #endif
> > @@ -4555,11 +4555,11 @@ static inline int
> > rte_eth_tx_descriptor_status(uint16_t port_id,
> >  	struct rte_eth_dev *dev;
> >  	void *txq;
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> >  #endif
> >  	dev = &rte_eth_devices[port_id];
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	if (queue_id >= dev->data->nb_tx_queues)
> >  		return -ENODEV;
> >  #endif
> > @@ -4641,7 +4641,7 @@ rte_eth_tx_burst(uint16_t port_id, uint16_t
> > queue_id,
> >  {
> >  	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> >  	RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_pkt_burst, 0);
> >
> > @@ -4727,7 +4727,7 @@ rte_eth_tx_prepare(uint16_t port_id, uint16_t
> > queue_id,
> >  {
> >  	struct rte_eth_dev *dev;
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	if (!rte_eth_dev_is_valid_port(port_id)) {
> >  		RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
> >  		rte_errno = EINVAL;
> > @@ -4737,7 +4737,7 @@ rte_eth_tx_prepare(uint16_t port_id, uint16_t
> > queue_id,
> >
> >  	dev = &rte_eth_devices[port_id];
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	if (queue_id >= dev->data->nb_tx_queues) {
> >  		RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n",
> > queue_id);
> >  		rte_errno = EINVAL;
> > diff --git a/lib/librte_net/rte_net.h b/lib/librte_net/rte_net.h
> > index 1560ecfa4..9a9732189 100644
> > --- a/lib/librte_net/rte_net.h
> > +++ b/lib/librte_net/rte_net.h
> > @@ -120,7 +120,7 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf
> > *m, uint64_t ol_flags)
> >  	struct rte_udp_hdr *udp_hdr;
> >  	uint64_t inner_l3_offset = m->l2_len;
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	/*
> >  	 * Does packet set any of available offloads?
> >  	 * Mainly it is required to avoid fragmented headers check if
> > @@ -133,7 +133,7 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf
> > *m, uint64_t ol_flags)
> >  	if (ol_flags & (PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IPV6))
> >  		inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
> >
> > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > +#ifdef RTE_DEBUG
> >  	/*
> >  	 * Check if headers are fragmented.
> >  	 * The check could be less strict depending on which offloads are
> > --
> > 2.17.1
> 
> The approach in this series does not make any sense to me: what if you want to debug just this library instead of the entire DPDK? We need
> to be able to enable debug for a single library at a time, as opposed to the user being flooded with unwanted debug messages from all the
> libraries.
> 
> NAK from me.

I am agree with Cristian concern here:
that patch removes ability to enable/disable debug on particular library/PMD. 
If the purpose is to minimize number of config compile options,
I wonder can't it be done in a slightly different way:
1. introduce gloabal RTE_DEBUG
2. keep actual .[c,h] files intact  
3. In actual librte_xxx/meson.build  file check if RTE_DEBUG is enabled, 
If yes, then enable particular debug flag for these libs.
Something like:
If dpdk_conf.get('RTE_DEBUG') == true
	dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)

defines that are used by multiple libs, probably can be
set in upper layer meson.build.

That way will have global 'debug' flag, but users will still
have an ability to enable/disable debug flags on a per lib basis
via CFLAGS="-D..." 

Konstantin

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Bruce Richardson]

On Mon, Apr 20, 2020 at 01:37:12PM +0000, Ananyev, Konstantin wrote:
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> > > Sent: Friday, April 17, 2020 10:57 PM
> > > To: Thomas Monjalon <thomas@monjalon.net>; Igor Russkikh
> > > <igor.russkikh@aquantia.com>; Pavel Belous <pavel.belous@aquantia.com>;
> > > Lu, Wenzhuo <wenzhuo.lu@intel.com>; Marcin Wojtas
> > > <mw@semihalf.com>; Michal Krawczyk <mk@semihalf.com>; Guy Tzalik
> > > <gtzalik@amazon.com>; Evgeny Schemeilin <evgenys@amazon.com>; Igor
> > > Chauskin <igorch@amazon.com>; John Daley <johndale@cisco.com>; Hyong
> > > Youb Kim <hyonkim@cisco.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> > > Wang, Xiao W <xiao.w.wang@intel.com>; Ziyang Xuan
> > > <xuanziyang2@huawei.com>; Xiaoyun Wang
> > > <cloud.wangxiaoyun@huawei.com>; Guoyang Zhou
> > > <zhouguoyang@huawei.com>; Wei Hu (Xavier)
> > > <xavier.huwei@huawei.com>; Min Hu (Connor) <humin29@huawei.com>;
> > > Yisen Zhuang <yisen.zhuang@huawei.com>; Xing, Beilei
> > > <beilei.xing@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
> > > <qiming.yang@intel.com>; Ananyev, Konstantin
> > > <konstantin.ananyev@intel.com>; Rasesh Mody <rmody@marvell.com>;
> > > Shahed Shaikh <shshaikh@marvell.com>; Singh, Jasvinder
> > > <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> > > <cristian.dumitrescu@intel.com>; Maxime Coquelin
> > > <maxime.coquelin@redhat.com>; Wang, Zhihong
> > > <zhihong.wang@intel.com>; Ye, Xiaolong <xiaolong.ye@intel.com>; Yong
> > > Wang <yongwang@vmware.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> > > Andrew Rybchenko <arybchenko@solarflare.com>; Olivier Matz
> > > <olivier.matz@6wind.com>
> > > Cc: dev@dpdk.org
> > > Subject: [PATCH v1 03/17] ethdev: replace library debug flag with global one
> > >
> > > Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_ETHDEV_DEBUG.
> > > The old define is completely removed from source code and config.
> > > The changes were applied also to all drivers using this flag.
> > >
> > > Signed-off-by: Lukasz Wojciechowski
> > > <l.wojciechow@partner.samsung.com>
> > > ---
> > >  config/common_base                           |  1 -
> > >  drivers/net/atlantic/atl_rxtx.c              |  2 +-
> > >  drivers/net/e1000/em_rxtx.c                  |  2 +-
> > >  drivers/net/e1000/igb_rxtx.c                 |  2 +-
> > >  drivers/net/ena/ena_ethdev.c                 |  2 +-
> > >  drivers/net/enic/enic_rxtx.c                 |  2 +-
> > >  drivers/net/fm10k/fm10k_rxtx.c               |  2 +-
> > >  drivers/net/hinic/hinic_pmd_tx.c             |  2 +-
> > >  drivers/net/hns3/hns3_rxtx.c                 |  2 +-
> > >  drivers/net/i40e/i40e_rxtx.c                 |  2 +-
> > >  drivers/net/iavf/iavf_rxtx.c                 |  2 +-
> > >  drivers/net/ice/ice_rxtx.c                   |  2 +-
> > >  drivers/net/ixgbe/ixgbe_rxtx.c               |  2 +-
> > >  drivers/net/qede/qede_rxtx.c                 |  4 ++--
> > >  drivers/net/softnic/rte_eth_softnic.c        |  2 +-
> > >  drivers/net/softnic/rte_eth_softnic_thread.c |  2 +-
> > >  drivers/net/virtio/virtio_rxtx.c             |  2 +-
> > >  drivers/net/vmxnet3/vmxnet3_rxtx.c           |  2 +-
> > >  lib/librte_ethdev/rte_ethdev.h               | 16 ++++++++--------
> > >  lib/librte_net/rte_net.h                     |  4 ++--
> > >  20 files changed, 28 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/config/common_base b/config/common_base
> > > index c5be57f11..16a8f09b6 100644
> > > --- a/config/common_base
> > > +++ b/config/common_base
> > > @@ -149,7 +149,6 @@ CONFIG_RTE_LIBRTE_KVARGS=y
> > >  # Compile generic ethernet library
> > >  #
> > >  CONFIG_RTE_LIBRTE_ETHER=y
> > > -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
> > >  CONFIG_RTE_MAX_ETHPORTS=32
> > >  CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
> > >  CONFIG_RTE_LIBRTE_IEEE1588=n
> > > diff --git a/drivers/net/atlantic/atl_rxtx.c b/drivers/net/atlantic/atl_rxtx.c
> > > index 449ffd454..eae54df22 100644
> > > --- a/drivers/net/atlantic/atl_rxtx.c
> > > +++ b/drivers/net/atlantic/atl_rxtx.c
> > > @@ -821,7 +821,7 @@ atl_prep_pkts(__rte_unused void *tx_queue, struct
> > > rte_mbuf **tx_pkts,
> > >  			return i;
> > >  		}
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/drivers/net/e1000/em_rxtx.c b/drivers/net/e1000/em_rxtx.c
> > > index 49c53712a..c4083ff00 100644
> > > --- a/drivers/net/e1000/em_rxtx.c
> > > +++ b/drivers/net/e1000/em_rxtx.c
> > > @@ -626,7 +626,7 @@ eth_em_prep_pkts(__rte_unused void *tx_queue,
> > > struct rte_mbuf **tx_pkts,
> > >  			return i;
> > >  		}
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
> > > index 684fa4ad8..6a78f26e6 100644
> > > --- a/drivers/net/e1000/igb_rxtx.c
> > > +++ b/drivers/net/e1000/igb_rxtx.c
> > > @@ -641,7 +641,7 @@ eth_igb_prep_pkts(__rte_unused void *tx_queue,
> > > struct rte_mbuf **tx_pkts,
> > >  			return i;
> > >  		}
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
> > > index 665afee4f..b9855e91b 100644
> > > --- a/drivers/net/ena/ena_ethdev.c
> > > +++ b/drivers/net/ena/ena_ethdev.c
> > > @@ -2145,7 +2145,7 @@ eth_ena_prep_pkts(void *tx_queue, struct
> > > rte_mbuf **tx_pkts,
> > >  			return i;
> > >  		}
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/drivers/net/enic/enic_rxtx.c b/drivers/net/enic/enic_rxtx.c
> > > index 6a8718c08..c42d563b4 100644
> > > --- a/drivers/net/enic/enic_rxtx.c
> > > +++ b/drivers/net/enic/enic_rxtx.c
> > > @@ -414,7 +414,7 @@ uint16_t enic_prep_pkts(void *tx_queue, struct
> > > rte_mbuf **tx_pkts,
> > >  			rte_errno = ENOTSUP;
> > >  			return i;
> > >  		}
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/drivers/net/fm10k/fm10k_rxtx.c
> > > b/drivers/net/fm10k/fm10k_rxtx.c
> > > index 4accaa2cd..43d773f08 100644
> > > --- a/drivers/net/fm10k/fm10k_rxtx.c
> > > +++ b/drivers/net/fm10k/fm10k_rxtx.c
> > > @@ -710,7 +710,7 @@ fm10k_prep_pkts(__rte_unused void *tx_queue,
> > > struct rte_mbuf **tx_pkts,
> > >  			return i;
> > >  		}
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/drivers/net/hinic/hinic_pmd_tx.c
> > > b/drivers/net/hinic/hinic_pmd_tx.c
> > > index 64ec2c119..41d5a25b6 100644
> > > --- a/drivers/net/hinic/hinic_pmd_tx.c
> > > +++ b/drivers/net/hinic/hinic_pmd_tx.c
> > > @@ -804,7 +804,7 @@ hinic_tx_offload_pkt_prepare(struct rte_mbuf *m,
> > >  	    !(ol_flags & PKT_TX_TUNNEL_VXLAN))
> > >  		return -ENOTSUP;
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	if (rte_validate_tx_offload(m) != 0)
> > >  		return -EINVAL;
> > >  #endif
> > > diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
> > > index ec6d19f58..45aa64b70 100644
> > > --- a/drivers/net/hns3/hns3_rxtx.c
> > > +++ b/drivers/net/hns3/hns3_rxtx.c
> > > @@ -2296,7 +2296,7 @@ hns3_prep_pkts(__rte_unused void *tx_queue,
> > > struct rte_mbuf **tx_pkts,
> > >  			return i;
> > >  		}
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> > > index 5e7c86ed8..282baf514 100644
> > > --- a/drivers/net/i40e/i40e_rxtx.c
> > > +++ b/drivers/net/i40e/i40e_rxtx.c
> > > @@ -1499,7 +1499,7 @@ i40e_prep_pkts(__rte_unused void *tx_queue,
> > > struct rte_mbuf **tx_pkts,
> > >  			return i;
> > >  		}
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
> > > index 85d9a8e3b..8122d35be 100644
> > > --- a/drivers/net/iavf/iavf_rxtx.c
> > > +++ b/drivers/net/iavf/iavf_rxtx.c
> > > @@ -1689,7 +1689,7 @@ iavf_prep_pkts(__rte_unused void *tx_queue,
> > > struct rte_mbuf **tx_pkts,
> > >  			return i;
> > >  		}
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
> > > index 1c9f31efd..fd8ed2573 100644
> > > --- a/drivers/net/ice/ice_rxtx.c
> > > +++ b/drivers/net/ice/ice_rxtx.c
> > > @@ -3037,7 +3037,7 @@ ice_prep_pkts(__rte_unused void *tx_queue,
> > > struct rte_mbuf **tx_pkts,
> > >  			return i;
> > >  		}
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> > > index 2e20e18c7..6964c4e52 100644
> > > --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> > > +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> > > @@ -992,7 +992,7 @@ ixgbe_prep_pkts(void *tx_queue, struct rte_mbuf
> > > **tx_pkts, uint16_t nb_pkts)
> > >  			return i;
> > >  		}
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
> > > index b81788ca4..646eb2275 100644
> > > --- a/drivers/net/qede/qede_rxtx.c
> > > +++ b/drivers/net/qede/qede_rxtx.c
> > > @@ -2156,7 +2156,7 @@ qede_xmit_prep_pkts(__rte_unused void *p_txq,
> > > struct rte_mbuf **tx_pkts,
> > >  	uint64_t ol_flags;
> > >  	struct rte_mbuf *m;
> > >  	uint16_t i;
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	int ret;
> > >  #endif
> > >
> > > @@ -2196,7 +2196,7 @@ qede_xmit_prep_pkts(__rte_unused void *p_txq,
> > > struct rte_mbuf **tx_pkts,
> > >  			break;
> > >  		}
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/drivers/net/softnic/rte_eth_softnic.c
> > > b/drivers/net/softnic/rte_eth_softnic.c
> > > index 11723778f..b5b169ff7 100644
> > > --- a/drivers/net/softnic/rte_eth_softnic.c
> > > +++ b/drivers/net/softnic/rte_eth_softnic.c
> > > @@ -704,7 +704,7 @@ rte_pmd_softnic_manage(uint16_t port_id)
> > >  	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > >  	struct pmd_internals *softnic;
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> > >  #endif
> > >
> > > diff --git a/drivers/net/softnic/rte_eth_softnic_thread.c
> > > b/drivers/net/softnic/rte_eth_softnic_thread.c
> > > index d610b1617..2f7c3a838 100644
> > > --- a/drivers/net/softnic/rte_eth_softnic_thread.c
> > > +++ b/drivers/net/softnic/rte_eth_softnic_thread.c
> > > @@ -3093,7 +3093,7 @@ rte_pmd_softnic_run(uint16_t port_id)
> > >  {
> > >  	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> > >  #endif
> > >
> > > diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
> > > index 752faa0f6..02eaf38e3 100644
> > > --- a/drivers/net/virtio/virtio_rxtx.c
> > > +++ b/drivers/net/virtio/virtio_rxtx.c
> > > @@ -1979,7 +1979,7 @@ virtio_xmit_pkts_prepare(void *tx_queue
> > > __rte_unused, struct rte_mbuf **tx_pkts,
> > >  	for (nb_tx = 0; nb_tx < nb_pkts; nb_tx++) {
> > >  		struct rte_mbuf *m = tx_pkts[nb_tx];
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		error = rte_validate_tx_offload(m);
> > >  		if (unlikely(error)) {
> > >  			rte_errno = -error;
> > > diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c
> > > b/drivers/net/vmxnet3/vmxnet3_rxtx.c
> > > index dd99684be..a801290ff 100644
> > > --- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
> > > +++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
> > > @@ -373,7 +373,7 @@ vmxnet3_prep_pkts(__rte_unused void *tx_queue,
> > > struct rte_mbuf **tx_pkts,
> > >  			return i;
> > >  		}
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  		ret = rte_validate_tx_offload(m);
> > >  		if (ret != 0) {
> > >  			rte_errno = -ret;
> > > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> > > index e9e3a1699..f314b57c7 100644
> > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > +++ b/lib/librte_ethdev/rte_ethdev.h
> > > @@ -4375,7 +4375,7 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t
> > > queue_id,
> > >  	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > >  	uint16_t nb_rx;
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> > >  	RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
> > >
> > > @@ -4498,11 +4498,11 @@ rte_eth_rx_descriptor_status(uint16_t port_id,
> > > uint16_t queue_id,
> > >  	struct rte_eth_dev *dev;
> > >  	void *rxq;
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > >  #endif
> > >  	dev = &rte_eth_devices[port_id];
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	if (queue_id >= dev->data->nb_rx_queues)
> > >  		return -ENODEV;
> > >  #endif
> > > @@ -4555,11 +4555,11 @@ static inline int
> > > rte_eth_tx_descriptor_status(uint16_t port_id,
> > >  	struct rte_eth_dev *dev;
> > >  	void *txq;
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > >  #endif
> > >  	dev = &rte_eth_devices[port_id];
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	if (queue_id >= dev->data->nb_tx_queues)
> > >  		return -ENODEV;
> > >  #endif
> > > @@ -4641,7 +4641,7 @@ rte_eth_tx_burst(uint16_t port_id, uint16_t
> > > queue_id,
> > >  {
> > >  	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> > >  	RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_pkt_burst, 0);
> > >
> > > @@ -4727,7 +4727,7 @@ rte_eth_tx_prepare(uint16_t port_id, uint16_t
> > > queue_id,
> > >  {
> > >  	struct rte_eth_dev *dev;
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	if (!rte_eth_dev_is_valid_port(port_id)) {
> > >  		RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
> > >  		rte_errno = EINVAL;
> > > @@ -4737,7 +4737,7 @@ rte_eth_tx_prepare(uint16_t port_id, uint16_t
> > > queue_id,
> > >
> > >  	dev = &rte_eth_devices[port_id];
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	if (queue_id >= dev->data->nb_tx_queues) {
> > >  		RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n",
> > > queue_id);
> > >  		rte_errno = EINVAL;
> > > diff --git a/lib/librte_net/rte_net.h b/lib/librte_net/rte_net.h
> > > index 1560ecfa4..9a9732189 100644
> > > --- a/lib/librte_net/rte_net.h
> > > +++ b/lib/librte_net/rte_net.h
> > > @@ -120,7 +120,7 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf
> > > *m, uint64_t ol_flags)
> > >  	struct rte_udp_hdr *udp_hdr;
> > >  	uint64_t inner_l3_offset = m->l2_len;
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	/*
> > >  	 * Does packet set any of available offloads?
> > >  	 * Mainly it is required to avoid fragmented headers check if
> > > @@ -133,7 +133,7 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf
> > > *m, uint64_t ol_flags)
> > >  	if (ol_flags & (PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IPV6))
> > >  		inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
> > >
> > > -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> > > +#ifdef RTE_DEBUG
> > >  	/*
> > >  	 * Check if headers are fragmented.
> > >  	 * The check could be less strict depending on which offloads are
> > > --
> > > 2.17.1
> > 
> > The approach in this series does not make any sense to me: what if you want to debug just this library instead of the entire DPDK? We need
> > to be able to enable debug for a single library at a time, as opposed to the user being flooded with unwanted debug messages from all the
> > libraries.
> > 
> > NAK from me.
> 
> I am agree with Cristian concern here:
> that patch removes ability to enable/disable debug on particular library/PMD. 
> If the purpose is to minimize number of config compile options,
> I wonder can't it be done in a slightly different way:
> 1. introduce gloabal RTE_DEBUG
> 2. keep actual .[c,h] files intact  
> 3. In actual librte_xxx/meson.build  file check if RTE_DEBUG is enabled, 
> If yes, then enable particular debug flag for these libs.
> Something like:
> If dpdk_conf.get('RTE_DEBUG') == true
> 	dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> 
> defines that are used by multiple libs, probably can be
> set in upper layer meson.build.
> 
> That way will have global 'debug' flag, but users will still
> have an ability to enable/disable debug flags on a per lib basis
> via CFLAGS="-D..." 
> 
> Konstantin
> 
That seems a reasonable idea to me.

However, in this case, we don't need the RTE_DEBUG flag at all, we can
either:

* allow each component meson.build file define its own flags after checking
  get_option('debug')
* have lib/meson.build and drivers/meson.build automatically define a
  specific define for each library or driver to standardize the naming.
  [This would save anyone working on it from having to lookup what the
  define was, since it's always e.g. RTE_DEBUG_ + library-base-name, e.g.
  RTE_DEBUG_LPM, RTE_DEBUG_SCHED etc]

Theoretically we can also do both, have the standard ones defined and then
allow a component to provide extra flags itself if so desired.

/Bruce

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Lukasz Wojciechowski]

W dniu 20.04.2020 o 16:21, Bruce Richardson pisze:
> On Mon, Apr 20, 2020 at 01:37:12PM +0000, Ananyev, Konstantin wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
>>>> Sent: Friday, April 17, 2020 10:57 PM
>>>> To: Thomas Monjalon <thomas@monjalon.net>; Igor Russkikh
>>>> <igor.russkikh@aquantia.com>; Pavel Belous <pavel.belous@aquantia.com>;
>>>> Lu, Wenzhuo <wenzhuo.lu@intel.com>; Marcin Wojtas
>>>> <mw@semihalf.com>; Michal Krawczyk <mk@semihalf.com>; Guy Tzalik
>>>> <gtzalik@amazon.com>; Evgeny Schemeilin <evgenys@amazon.com>; Igor
>>>> Chauskin <igorch@amazon.com>; John Daley <johndale@cisco.com>; Hyong
>>>> Youb Kim <hyonkim@cisco.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
>>>> Wang, Xiao W <xiao.w.wang@intel.com>; Ziyang Xuan
>>>> <xuanziyang2@huawei.com>; Xiaoyun Wang
>>>> <cloud.wangxiaoyun@huawei.com>; Guoyang Zhou
>>>> <zhouguoyang@huawei.com>; Wei Hu (Xavier)
>>>> <xavier.huwei@huawei.com>; Min Hu (Connor) <humin29@huawei.com>;
>>>> Yisen Zhuang <yisen.zhuang@huawei.com>; Xing, Beilei
>>>> <beilei.xing@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; Yang, Qiming
>>>> <qiming.yang@intel.com>; Ananyev, Konstantin
>>>> <konstantin.ananyev@intel.com>; Rasesh Mody <rmody@marvell.com>;
>>>> Shahed Shaikh <shshaikh@marvell.com>; Singh, Jasvinder
>>>> <jasvinder.singh@intel.com>; Dumitrescu, Cristian
>>>> <cristian.dumitrescu@intel.com>; Maxime Coquelin
>>>> <maxime.coquelin@redhat.com>; Wang, Zhihong
>>>> <zhihong.wang@intel.com>; Ye, Xiaolong <xiaolong.ye@intel.com>; Yong
>>>> Wang <yongwang@vmware.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
>>>> Andrew Rybchenko <arybchenko@solarflare.com>; Olivier Matz
>>>> <olivier.matz@6wind.com>
>>>> Cc: dev@dpdk.org
>>>> Subject: [PATCH v1 03/17] ethdev: replace library debug flag with global one
>>>>
>>>> Use global debug flag RTE_DEBUG instead of RTE_LIBRTE_ETHDEV_DEBUG.
>>>> The old define is completely removed from source code and config.
>>>> The changes were applied also to all drivers using this flag.
>>>>
>>>> Signed-off-by: Lukasz Wojciechowski
>>>> <l.wojciechow@partner.samsung.com>
>>>> ---
>>>>   config/common_base                           |  1 -
>>>>   drivers/net/atlantic/atl_rxtx.c              |  2 +-
>>>>   drivers/net/e1000/em_rxtx.c                  |  2 +-
>>>>   drivers/net/e1000/igb_rxtx.c                 |  2 +-
>>>>   drivers/net/ena/ena_ethdev.c                 |  2 +-
>>>>   drivers/net/enic/enic_rxtx.c                 |  2 +-
>>>>   drivers/net/fm10k/fm10k_rxtx.c               |  2 +-
>>>>   drivers/net/hinic/hinic_pmd_tx.c             |  2 +-
>>>>   drivers/net/hns3/hns3_rxtx.c                 |  2 +-
>>>>   drivers/net/i40e/i40e_rxtx.c                 |  2 +-
>>>>   drivers/net/iavf/iavf_rxtx.c                 |  2 +-
>>>>   drivers/net/ice/ice_rxtx.c                   |  2 +-
>>>>   drivers/net/ixgbe/ixgbe_rxtx.c               |  2 +-
>>>>   drivers/net/qede/qede_rxtx.c                 |  4 ++--
>>>>   drivers/net/softnic/rte_eth_softnic.c        |  2 +-
>>>>   drivers/net/softnic/rte_eth_softnic_thread.c |  2 +-
>>>>   drivers/net/virtio/virtio_rxtx.c             |  2 +-
>>>>   drivers/net/vmxnet3/vmxnet3_rxtx.c           |  2 +-
>>>>   lib/librte_ethdev/rte_ethdev.h               | 16 ++++++++--------
>>>>   lib/librte_net/rte_net.h                     |  4 ++--
>>>>   20 files changed, 28 insertions(+), 29 deletions(-)
>>>>
>>>> diff --git a/config/common_base b/config/common_base
>>>> index c5be57f11..16a8f09b6 100644
>>>> --- a/config/common_base
>>>> +++ b/config/common_base
>>>> @@ -149,7 +149,6 @@ CONFIG_RTE_LIBRTE_KVARGS=y
>>>>   # Compile generic ethernet library
>>>>   #
>>>>   CONFIG_RTE_LIBRTE_ETHER=y
>>>> -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
>>>>   CONFIG_RTE_MAX_ETHPORTS=32
>>>>   CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
>>>>   CONFIG_RTE_LIBRTE_IEEE1588=n
>>>> diff --git a/drivers/net/atlantic/atl_rxtx.c b/drivers/net/atlantic/atl_rxtx.c
>>>> index 449ffd454..eae54df22 100644
>>>> --- a/drivers/net/atlantic/atl_rxtx.c
>>>> +++ b/drivers/net/atlantic/atl_rxtx.c
>>>> @@ -821,7 +821,7 @@ atl_prep_pkts(__rte_unused void *tx_queue, struct
>>>> rte_mbuf **tx_pkts,
>>>>   			return i;
>>>>   		}
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/drivers/net/e1000/em_rxtx.c b/drivers/net/e1000/em_rxtx.c
>>>> index 49c53712a..c4083ff00 100644
>>>> --- a/drivers/net/e1000/em_rxtx.c
>>>> +++ b/drivers/net/e1000/em_rxtx.c
>>>> @@ -626,7 +626,7 @@ eth_em_prep_pkts(__rte_unused void *tx_queue,
>>>> struct rte_mbuf **tx_pkts,
>>>>   			return i;
>>>>   		}
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
>>>> index 684fa4ad8..6a78f26e6 100644
>>>> --- a/drivers/net/e1000/igb_rxtx.c
>>>> +++ b/drivers/net/e1000/igb_rxtx.c
>>>> @@ -641,7 +641,7 @@ eth_igb_prep_pkts(__rte_unused void *tx_queue,
>>>> struct rte_mbuf **tx_pkts,
>>>>   			return i;
>>>>   		}
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
>>>> index 665afee4f..b9855e91b 100644
>>>> --- a/drivers/net/ena/ena_ethdev.c
>>>> +++ b/drivers/net/ena/ena_ethdev.c
>>>> @@ -2145,7 +2145,7 @@ eth_ena_prep_pkts(void *tx_queue, struct
>>>> rte_mbuf **tx_pkts,
>>>>   			return i;
>>>>   		}
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/drivers/net/enic/enic_rxtx.c b/drivers/net/enic/enic_rxtx.c
>>>> index 6a8718c08..c42d563b4 100644
>>>> --- a/drivers/net/enic/enic_rxtx.c
>>>> +++ b/drivers/net/enic/enic_rxtx.c
>>>> @@ -414,7 +414,7 @@ uint16_t enic_prep_pkts(void *tx_queue, struct
>>>> rte_mbuf **tx_pkts,
>>>>   			rte_errno = ENOTSUP;
>>>>   			return i;
>>>>   		}
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/drivers/net/fm10k/fm10k_rxtx.c
>>>> b/drivers/net/fm10k/fm10k_rxtx.c
>>>> index 4accaa2cd..43d773f08 100644
>>>> --- a/drivers/net/fm10k/fm10k_rxtx.c
>>>> +++ b/drivers/net/fm10k/fm10k_rxtx.c
>>>> @@ -710,7 +710,7 @@ fm10k_prep_pkts(__rte_unused void *tx_queue,
>>>> struct rte_mbuf **tx_pkts,
>>>>   			return i;
>>>>   		}
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/drivers/net/hinic/hinic_pmd_tx.c
>>>> b/drivers/net/hinic/hinic_pmd_tx.c
>>>> index 64ec2c119..41d5a25b6 100644
>>>> --- a/drivers/net/hinic/hinic_pmd_tx.c
>>>> +++ b/drivers/net/hinic/hinic_pmd_tx.c
>>>> @@ -804,7 +804,7 @@ hinic_tx_offload_pkt_prepare(struct rte_mbuf *m,
>>>>   	    !(ol_flags & PKT_TX_TUNNEL_VXLAN))
>>>>   		return -ENOTSUP;
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	if (rte_validate_tx_offload(m) != 0)
>>>>   		return -EINVAL;
>>>>   #endif
>>>> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
>>>> index ec6d19f58..45aa64b70 100644
>>>> --- a/drivers/net/hns3/hns3_rxtx.c
>>>> +++ b/drivers/net/hns3/hns3_rxtx.c
>>>> @@ -2296,7 +2296,7 @@ hns3_prep_pkts(__rte_unused void *tx_queue,
>>>> struct rte_mbuf **tx_pkts,
>>>>   			return i;
>>>>   		}
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
>>>> index 5e7c86ed8..282baf514 100644
>>>> --- a/drivers/net/i40e/i40e_rxtx.c
>>>> +++ b/drivers/net/i40e/i40e_rxtx.c
>>>> @@ -1499,7 +1499,7 @@ i40e_prep_pkts(__rte_unused void *tx_queue,
>>>> struct rte_mbuf **tx_pkts,
>>>>   			return i;
>>>>   		}
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
>>>> index 85d9a8e3b..8122d35be 100644
>>>> --- a/drivers/net/iavf/iavf_rxtx.c
>>>> +++ b/drivers/net/iavf/iavf_rxtx.c
>>>> @@ -1689,7 +1689,7 @@ iavf_prep_pkts(__rte_unused void *tx_queue,
>>>> struct rte_mbuf **tx_pkts,
>>>>   			return i;
>>>>   		}
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
>>>> index 1c9f31efd..fd8ed2573 100644
>>>> --- a/drivers/net/ice/ice_rxtx.c
>>>> +++ b/drivers/net/ice/ice_rxtx.c
>>>> @@ -3037,7 +3037,7 @@ ice_prep_pkts(__rte_unused void *tx_queue,
>>>> struct rte_mbuf **tx_pkts,
>>>>   			return i;
>>>>   		}
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
>>>> index 2e20e18c7..6964c4e52 100644
>>>> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
>>>> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
>>>> @@ -992,7 +992,7 @@ ixgbe_prep_pkts(void *tx_queue, struct rte_mbuf
>>>> **tx_pkts, uint16_t nb_pkts)
>>>>   			return i;
>>>>   		}
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
>>>> index b81788ca4..646eb2275 100644
>>>> --- a/drivers/net/qede/qede_rxtx.c
>>>> +++ b/drivers/net/qede/qede_rxtx.c
>>>> @@ -2156,7 +2156,7 @@ qede_xmit_prep_pkts(__rte_unused void *p_txq,
>>>> struct rte_mbuf **tx_pkts,
>>>>   	uint64_t ol_flags;
>>>>   	struct rte_mbuf *m;
>>>>   	uint16_t i;
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	int ret;
>>>>   #endif
>>>>
>>>> @@ -2196,7 +2196,7 @@ qede_xmit_prep_pkts(__rte_unused void *p_txq,
>>>> struct rte_mbuf **tx_pkts,
>>>>   			break;
>>>>   		}
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/drivers/net/softnic/rte_eth_softnic.c
>>>> b/drivers/net/softnic/rte_eth_softnic.c
>>>> index 11723778f..b5b169ff7 100644
>>>> --- a/drivers/net/softnic/rte_eth_softnic.c
>>>> +++ b/drivers/net/softnic/rte_eth_softnic.c
>>>> @@ -704,7 +704,7 @@ rte_pmd_softnic_manage(uint16_t port_id)
>>>>   	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
>>>>   	struct pmd_internals *softnic;
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
>>>>   #endif
>>>>
>>>> diff --git a/drivers/net/softnic/rte_eth_softnic_thread.c
>>>> b/drivers/net/softnic/rte_eth_softnic_thread.c
>>>> index d610b1617..2f7c3a838 100644
>>>> --- a/drivers/net/softnic/rte_eth_softnic_thread.c
>>>> +++ b/drivers/net/softnic/rte_eth_softnic_thread.c
>>>> @@ -3093,7 +3093,7 @@ rte_pmd_softnic_run(uint16_t port_id)
>>>>   {
>>>>   	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
>>>>   #endif
>>>>
>>>> diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
>>>> index 752faa0f6..02eaf38e3 100644
>>>> --- a/drivers/net/virtio/virtio_rxtx.c
>>>> +++ b/drivers/net/virtio/virtio_rxtx.c
>>>> @@ -1979,7 +1979,7 @@ virtio_xmit_pkts_prepare(void *tx_queue
>>>> __rte_unused, struct rte_mbuf **tx_pkts,
>>>>   	for (nb_tx = 0; nb_tx < nb_pkts; nb_tx++) {
>>>>   		struct rte_mbuf *m = tx_pkts[nb_tx];
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		error = rte_validate_tx_offload(m);
>>>>   		if (unlikely(error)) {
>>>>   			rte_errno = -error;
>>>> diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c
>>>> b/drivers/net/vmxnet3/vmxnet3_rxtx.c
>>>> index dd99684be..a801290ff 100644
>>>> --- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
>>>> +++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
>>>> @@ -373,7 +373,7 @@ vmxnet3_prep_pkts(__rte_unused void *tx_queue,
>>>> struct rte_mbuf **tx_pkts,
>>>>   			return i;
>>>>   		}
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   		ret = rte_validate_tx_offload(m);
>>>>   		if (ret != 0) {
>>>>   			rte_errno = -ret;
>>>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>>>> index e9e3a1699..f314b57c7 100644
>>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>>> @@ -4375,7 +4375,7 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t
>>>> queue_id,
>>>>   	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
>>>>   	uint16_t nb_rx;
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
>>>>   	RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
>>>>
>>>> @@ -4498,11 +4498,11 @@ rte_eth_rx_descriptor_status(uint16_t port_id,
>>>> uint16_t queue_id,
>>>>   	struct rte_eth_dev *dev;
>>>>   	void *rxq;
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>>>>   #endif
>>>>   	dev = &rte_eth_devices[port_id];
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	if (queue_id >= dev->data->nb_rx_queues)
>>>>   		return -ENODEV;
>>>>   #endif
>>>> @@ -4555,11 +4555,11 @@ static inline int
>>>> rte_eth_tx_descriptor_status(uint16_t port_id,
>>>>   	struct rte_eth_dev *dev;
>>>>   	void *txq;
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>>>>   #endif
>>>>   	dev = &rte_eth_devices[port_id];
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	if (queue_id >= dev->data->nb_tx_queues)
>>>>   		return -ENODEV;
>>>>   #endif
>>>> @@ -4641,7 +4641,7 @@ rte_eth_tx_burst(uint16_t port_id, uint16_t
>>>> queue_id,
>>>>   {
>>>>   	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
>>>>   	RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_pkt_burst, 0);
>>>>
>>>> @@ -4727,7 +4727,7 @@ rte_eth_tx_prepare(uint16_t port_id, uint16_t
>>>> queue_id,
>>>>   {
>>>>   	struct rte_eth_dev *dev;
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	if (!rte_eth_dev_is_valid_port(port_id)) {
>>>>   		RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
>>>>   		rte_errno = EINVAL;
>>>> @@ -4737,7 +4737,7 @@ rte_eth_tx_prepare(uint16_t port_id, uint16_t
>>>> queue_id,
>>>>
>>>>   	dev = &rte_eth_devices[port_id];
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	if (queue_id >= dev->data->nb_tx_queues) {
>>>>   		RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n",
>>>> queue_id);
>>>>   		rte_errno = EINVAL;
>>>> diff --git a/lib/librte_net/rte_net.h b/lib/librte_net/rte_net.h
>>>> index 1560ecfa4..9a9732189 100644
>>>> --- a/lib/librte_net/rte_net.h
>>>> +++ b/lib/librte_net/rte_net.h
>>>> @@ -120,7 +120,7 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf
>>>> *m, uint64_t ol_flags)
>>>>   	struct rte_udp_hdr *udp_hdr;
>>>>   	uint64_t inner_l3_offset = m->l2_len;
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	/*
>>>>   	 * Does packet set any of available offloads?
>>>>   	 * Mainly it is required to avoid fragmented headers check if
>>>> @@ -133,7 +133,7 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf
>>>> *m, uint64_t ol_flags)
>>>>   	if (ol_flags & (PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IPV6))
>>>>   		inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
>>>>
>>>> -#ifdef RTE_LIBRTE_ETHDEV_DEBUG
>>>> +#ifdef RTE_DEBUG
>>>>   	/*
>>>>   	 * Check if headers are fragmented.
>>>>   	 * The check could be less strict depending on which offloads are
>>>> --
>>>> 2.17.1
>>> The approach in this series does not make any sense to me: what if you want to debug just this library instead of the entire DPDK? We need
>>> to be able to enable debug for a single library at a time, as opposed to the user being flooded with unwanted debug messages from all the
>>> libraries.
>>>
>>> NAK from me.
>> I am agree with Cristian concern here:
>> that patch removes ability to enable/disable debug on particular library/PMD.
>> If the purpose is to minimize number of config compile options,
>> I wonder can't it be done in a slightly different way:
>> 1. introduce gloabal RTE_DEBUG
>> 2. keep actual .[c,h] files intact
>> 3. In actual librte_xxx/meson.build  file check if RTE_DEBUG is enabled,
>> If yes, then enable particular debug flag for these libs.
>> Something like:
>> If dpdk_conf.get('RTE_DEBUG') == true
>> 	dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
>>
>> defines that are used by multiple libs, probably can be
>> set in upper layer meson.build.
>>
>> That way will have global 'debug' flag, but users will still
>> have an ability to enable/disable debug flags on a per lib basis
>> via CFLAGS="-D..."
>>
>> Konstantin
>>
> That seems a reasonable idea to me.
>
> However, in this case, we don't need the RTE_DEBUG flag at all, we can
> either:
>
> * allow each component meson.build file define its own flags after checking
>    get_option('debug')
> * have lib/meson.build and drivers/meson.build automatically define a
>    specific define for each library or driver to standardize the naming.
>    [This would save anyone working on it from having to lookup what the
>    define was, since it's always e.g. RTE_DEBUG_ + library-base-name, e.g.
>    RTE_DEBUG_LPM, RTE_DEBUG_SCHED etc]
>
> Theoretically we can also do both, have the standard ones defined and then
> allow a component to provide extra flags itself if so desired.
>
> /Bruce
OK, so let's summarize how the patches should be redo:
* usage of global "debug" flag for meson build stays
* we standardize names of debug flags in the components to RTE_DEBUG_ + 
components name
* debug flag enables al the RTE_DEBUG_... flags

This allow to easily use both:
* the debug flag - to enable all debugs
* or define manually RTE_DEBUG+component name, just for debug from a 
single component

I like Bruce's idea of adding it to the lib/meson.build and 
drivers/meson.build. This way they will be added to dpdk_conf meson 
object and written then later to rte_build_config.h before compilation 
stage.
All the other modules will be able to use these flags.

If there are no objections for such solution,  I'll prepare v2 
containing above changes.

-- 

Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Bruce Richardson]

On Mon, Apr 20, 2020 at 04:43:21PM +0200, Lukasz Wojciechowski wrote:
> 
> W dniu 20.04.2020 o 16:21, Bruce Richardson pisze:
> > On Mon, Apr 20, 2020 at 01:37:12PM +0000, Ananyev, Konstantin wrote:
> >>>
<snip>
> >> I am agree with Cristian concern here: that patch removes ability to
> >> enable/disable debug on particular library/PMD.  If the purpose is to
> >> minimize number of config compile options, I wonder can't it be done
> >> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> >> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> >> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> >> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> >> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> >>
> >> defines that are used by multiple libs, probably can be set in upper
> >> layer meson.build.
> >>
> >> That way will have global 'debug' flag, but users will still have an
> >> ability to enable/disable debug flags on a per lib basis via
> >> CFLAGS="-D..."
> >>
> >> Konstantin
> >>
> > That seems a reasonable idea to me.
> >
> > However, in this case, we don't need the RTE_DEBUG flag at all, we can
> > either:
> >
> > * allow each component meson.build file define its own flags after
> > checking get_option('debug') * have lib/meson.build and
> > drivers/meson.build automatically define a specific define for each
> > library or driver to standardize the naming.  [This would save anyone
> > working on it from having to lookup what the define was, since it's
> > always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> > RTE_DEBUG_SCHED etc]
> >
> > Theoretically we can also do both, have the standard ones defined and
> > then allow a component to provide extra flags itself if so desired.
> >
> > /Bruce
> OK, so let's summarize how the patches should be redo: * usage of global
> "debug" flag for meson build stays * we standardize names of debug flags
> in the components to RTE_DEBUG_ + components name * debug flag enables al
> the RTE_DEBUG_... flags
> 
> This allow to easily use both: * the debug flag - to enable all debugs *
> or define manually RTE_DEBUG+component name, just for debug from a single
> component
> 
> I like Bruce's idea of adding it to the lib/meson.build and
> drivers/meson.build. This way they will be added to dpdk_conf meson
> object and written then later to rte_build_config.h before compilation
> stage.  All the other modules will be able to use these flags.
>
Sounds good to me (obviously!), but I'd like other feedback to ensure
others are ok with this before you spend too much effort implementing it.

For the drivers, the flag probably needs to include the category as well as
the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
name confusion. Those flags can then be checked inside individual
meson.build files to enable other debug flags if necessary e.g. in ixgbe,
you could theoretically do:

if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
	...
endif

to enable more fine-grained control if so desired, and to maintain
compatibility with existing defines, again if so desired.

/Bruce

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Thomas Monjalon]

20/04/2020 19:11, Bruce Richardson:
> On Mon, Apr 20, 2020 at 04:43:21PM +0200, Lukasz Wojciechowski wrote:
> > 
> > W dniu 20.04.2020 o 16:21, Bruce Richardson pisze:
> > > On Mon, Apr 20, 2020 at 01:37:12PM +0000, Ananyev, Konstantin wrote:
> > >>>
> <snip>
> > >> I am agree with Cristian concern here: that patch removes ability to
> > >> enable/disable debug on particular library/PMD.  If the purpose is to
> > >> minimize number of config compile options, I wonder can't it be done
> > >> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> > >> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> > >> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> > >> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> > >> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> > >>
> > >> defines that are used by multiple libs, probably can be set in upper
> > >> layer meson.build.
> > >>
> > >> That way will have global 'debug' flag, but users will still have an
> > >> ability to enable/disable debug flags on a per lib basis via
> > >> CFLAGS="-D..."
> > >>
> > >> Konstantin
> > >>
> > > That seems a reasonable idea to me.
> > >
> > > However, in this case, we don't need the RTE_DEBUG flag at all, we can
> > > either:
> > >
> > > * allow each component meson.build file define its own flags after
> > > checking get_option('debug') * have lib/meson.build and
> > > drivers/meson.build automatically define a specific define for each
> > > library or driver to standardize the naming.  [This would save anyone
> > > working on it from having to lookup what the define was, since it's
> > > always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> > > RTE_DEBUG_SCHED etc]
> > >
> > > Theoretically we can also do both, have the standard ones defined and
> > > then allow a component to provide extra flags itself if so desired.
> > >
> > > /Bruce
> > OK, so let's summarize how the patches should be redo: * usage of global
> > "debug" flag for meson build stays * we standardize names of debug flags
> > in the components to RTE_DEBUG_ + components name * debug flag enables al
> > the RTE_DEBUG_... flags
> > 
> > This allow to easily use both: * the debug flag - to enable all debugs *
> > or define manually RTE_DEBUG+component name, just for debug from a single
> > component
> > 
> > I like Bruce's idea of adding it to the lib/meson.build and
> > drivers/meson.build. This way they will be added to dpdk_conf meson
> > object and written then later to rte_build_config.h before compilation
> > stage.  All the other modules will be able to use these flags.
> >
> Sounds good to me (obviously!), but I'd like other feedback to ensure
> others are ok with this before you spend too much effort implementing it.
> 
> For the drivers, the flag probably needs to include the category as well as
> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> name confusion. Those flags can then be checked inside individual
> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> you could theoretically do:
> 
> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> 	...
> endif
> 
> to enable more fine-grained control if so desired, and to maintain
> compatibility with existing defines, again if so desired.

Nak the nak from Cristian.

We don't need all these flags.
If the user choose to compile DPDK for debug, every debug facilities
should be enabled. Then at runtime it is possible to enable/disable
the interesting logs.
If you need to disable something which is not a log,
you can align with the log level thanks to the function rte_log_can_log.

Please let's stop complicating things for the contributors and the users.
Note: I am strong on this position.

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Bruce Richardson]

On Mon, Apr 20, 2020 at 06:11:30PM +0100, Bruce Richardson wrote:
> On Mon, Apr 20, 2020 at 04:43:21PM +0200, Lukasz Wojciechowski wrote:
> > 
> > W dniu 20.04.2020 o 16:21, Bruce Richardson pisze:
> > > On Mon, Apr 20, 2020 at 01:37:12PM +0000, Ananyev, Konstantin wrote:
> > >>>
> <snip>
> > >> I am agree with Cristian concern here: that patch removes ability to
> > >> enable/disable debug on particular library/PMD.  If the purpose is to
> > >> minimize number of config compile options, I wonder can't it be done
> > >> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> > >> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> > >> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> > >> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> > >> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> > >>
> > >> defines that are used by multiple libs, probably can be set in upper
> > >> layer meson.build.
> > >>
> > >> That way will have global 'debug' flag, but users will still have an
> > >> ability to enable/disable debug flags on a per lib basis via
> > >> CFLAGS="-D..."
> > >>
> > >> Konstantin
> > >>
> > > That seems a reasonable idea to me.
> > >
> > > However, in this case, we don't need the RTE_DEBUG flag at all, we can
> > > either:
> > >
> > > * allow each component meson.build file define its own flags after
> > > checking get_option('debug') * have lib/meson.build and
> > > drivers/meson.build automatically define a specific define for each
> > > library or driver to standardize the naming.  [This would save anyone
> > > working on it from having to lookup what the define was, since it's
> > > always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> > > RTE_DEBUG_SCHED etc]
> > >
> > > Theoretically we can also do both, have the standard ones defined and
> > > then allow a component to provide extra flags itself if so desired.
> > >
> > > /Bruce
> > OK, so let's summarize how the patches should be redo: * usage of global
> > "debug" flag for meson build stays * we standardize names of debug flags
> > in the components to RTE_DEBUG_ + components name * debug flag enables al
> > the RTE_DEBUG_... flags
> > 
> > This allow to easily use both: * the debug flag - to enable all debugs *
> > or define manually RTE_DEBUG+component name, just for debug from a single
> > component
> > 
> > I like Bruce's idea of adding it to the lib/meson.build and
> > drivers/meson.build. This way they will be added to dpdk_conf meson
> > object and written then later to rte_build_config.h before compilation
> > stage.  All the other modules will be able to use these flags.
> >
> Sounds good to me (obviously!), but I'd like other feedback to ensure
> others are ok with this before you spend too much effort implementing it.
> 
> For the drivers, the flag probably needs to include the category as well as
> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> name confusion. Those flags can then be checked inside individual
> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> you could theoretically do:
> 
> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> 	...
> endif
> 
> to enable more fine-grained control if so desired, and to maintain
> compatibility with existing defines, again if so desired.
> 
> /Bruce

Apologies for the self-reply, but I'd also like to ensure that basing it
all off the meson debug flag is the right thing to do. Currently that flag
is used to place debug info in the binary, which is quite different to
turning all a massive amount of prints from each component. Some drivers
etc. can be very chatty when debug flags are on.

A further option might be to have a general debug_drivers or
debug_libraries option, working with globs in the same was as the current
"disable_drivers" option does. That would allow more fine grain debugging
without resorting to manual CFLAG hacking, and it would also keep separate
the debug info from the compiler (which adds no perf hit) from debug prints
from drivers and libs which definitely do.

/Bruce

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Bruce Richardson]

On Mon, Apr 20, 2020 at 07:21:32PM +0200, Thomas Monjalon wrote:
> 20/04/2020 19:11, Bruce Richardson:
> > On Mon, Apr 20, 2020 at 04:43:21PM +0200, Lukasz Wojciechowski wrote:
> > > 
> > > W dniu 20.04.2020 o 16:21, Bruce Richardson pisze:
> > > > On Mon, Apr 20, 2020 at 01:37:12PM +0000, Ananyev, Konstantin wrote:
> > > >>>
> > <snip>
> > > >> I am agree with Cristian concern here: that patch removes ability to
> > > >> enable/disable debug on particular library/PMD.  If the purpose is to
> > > >> minimize number of config compile options, I wonder can't it be done
> > > >> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> > > >> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> > > >> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> > > >> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> > > >> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> > > >>
> > > >> defines that are used by multiple libs, probably can be set in upper
> > > >> layer meson.build.
> > > >>
> > > >> That way will have global 'debug' flag, but users will still have an
> > > >> ability to enable/disable debug flags on a per lib basis via
> > > >> CFLAGS="-D..."
> > > >>
> > > >> Konstantin
> > > >>
> > > > That seems a reasonable idea to me.
> > > >
> > > > However, in this case, we don't need the RTE_DEBUG flag at all, we can
> > > > either:
> > > >
> > > > * allow each component meson.build file define its own flags after
> > > > checking get_option('debug') * have lib/meson.build and
> > > > drivers/meson.build automatically define a specific define for each
> > > > library or driver to standardize the naming.  [This would save anyone
> > > > working on it from having to lookup what the define was, since it's
> > > > always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> > > > RTE_DEBUG_SCHED etc]
> > > >
> > > > Theoretically we can also do both, have the standard ones defined and
> > > > then allow a component to provide extra flags itself if so desired.
> > > >
> > > > /Bruce
> > > OK, so let's summarize how the patches should be redo: * usage of global
> > > "debug" flag for meson build stays * we standardize names of debug flags
> > > in the components to RTE_DEBUG_ + components name * debug flag enables al
> > > the RTE_DEBUG_... flags
> > > 
> > > This allow to easily use both: * the debug flag - to enable all debugs *
> > > or define manually RTE_DEBUG+component name, just for debug from a single
> > > component
> > > 
> > > I like Bruce's idea of adding it to the lib/meson.build and
> > > drivers/meson.build. This way they will be added to dpdk_conf meson
> > > object and written then later to rte_build_config.h before compilation
> > > stage.  All the other modules will be able to use these flags.
> > >
> > Sounds good to me (obviously!), but I'd like other feedback to ensure
> > others are ok with this before you spend too much effort implementing it.
> > 
> > For the drivers, the flag probably needs to include the category as well as
> > the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> > name confusion. Those flags can then be checked inside individual
> > meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> > you could theoretically do:
> > 
> > if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> > 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> > 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> > 	...
> > endif
> > 
> > to enable more fine-grained control if so desired, and to maintain
> > compatibility with existing defines, again if so desired.
> 
> Nak the nak from Cristian.
> 
> We don't need all these flags.
> If the user choose to compile DPDK for debug, every debug facilities
> should be enabled. Then at runtime it is possible to enable/disable
> the interesting logs.
> If you need to disable something which is not a log,
> you can align with the log level thanks to the function rte_log_can_log.
> 
> Please let's stop complicating things for the contributors and the users.
> Note: I am strong on this position.
>
Note, this means that you need to ensure all debug printouts from libs and
drivers are using the RTE_LOG macros so can be runtime controlled. I think
that may be some distance from reality right now.

Even if we do want all debug enabled from one flag, I'm still not 100%
convinced that the existing debug flag is the way to do, since it only adds
debug info to binary without affecting code generation.

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Lukasz Wojciechowski]

W dniu 20.04.2020 o 19:30, Bruce Richardson pisze:
> On Mon, Apr 20, 2020 at 07:21:32PM +0200, Thomas Monjalon wrote:
>> 20/04/2020 19:11, Bruce Richardson:
>>> On Mon, Apr 20, 2020 at 04:43:21PM +0200, Lukasz Wojciechowski wrote:
>>>> W dniu 20.04.2020 o 16:21, Bruce Richardson pisze:
>>>>> On Mon, Apr 20, 2020 at 01:37:12PM +0000, Ananyev, Konstantin wrote:
>>> <snip>
>>>>>> I am agree with Cristian concern here: that patch removes ability to
>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
>>>>>> minimize number of config compile options, I wonder can't it be done
>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
>>>>>>
>>>>>> defines that are used by multiple libs, probably can be set in upper
>>>>>> layer meson.build.
>>>>>>
>>>>>> That way will have global 'debug' flag, but users will still have an
>>>>>> ability to enable/disable debug flags on a per lib basis via
>>>>>> CFLAGS="-D..."
>>>>>>
>>>>>> Konstantin
>>>>>>
>>>>> That seems a reasonable idea to me.
>>>>>
>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
>>>>> either:
>>>>>
>>>>> * allow each component meson.build file define its own flags after
>>>>> checking get_option('debug') * have lib/meson.build and
>>>>> drivers/meson.build automatically define a specific define for each
>>>>> library or driver to standardize the naming.  [This would save anyone
>>>>> working on it from having to lookup what the define was, since it's
>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
>>>>> RTE_DEBUG_SCHED etc]
>>>>>
>>>>> Theoretically we can also do both, have the standard ones defined and
>>>>> then allow a component to provide extra flags itself if so desired.
>>>>>
>>>>> /Bruce
>>>> OK, so let's summarize how the patches should be redo: * usage of global
>>>> "debug" flag for meson build stays * we standardize names of debug flags
>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
>>>> the RTE_DEBUG_... flags
>>>>
>>>> This allow to easily use both: * the debug flag - to enable all debugs *
>>>> or define manually RTE_DEBUG+component name, just for debug from a single
>>>> component
>>>>
>>>> I like Bruce's idea of adding it to the lib/meson.build and
>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
>>>> object and written then later to rte_build_config.h before compilation
>>>> stage.  All the other modules will be able to use these flags.
>>>>
>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
>>> others are ok with this before you spend too much effort implementing it.
>>>
>>> For the drivers, the flag probably needs to include the category as well as
>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
>>> name confusion. Those flags can then be checked inside individual
>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
>>> you could theoretically do:
>>>
>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
>>> 	...
>>> endif
>>>
>>> to enable more fine-grained control if so desired, and to maintain
>>> compatibility with existing defines, again if so desired.
>> Nak the nak from Cristian.
>>
>> We don't need all these flags.
>> If the user choose to compile DPDK for debug, every debug facilities
>> should be enabled. Then at runtime it is possible to enable/disable
>> the interesting logs.
>> If you need to disable something which is not a log,
>> you can align with the log level thanks to the function rte_log_can_log.
>>
>> Please let's stop complicating things for the contributors and the users.
>> Note: I am strong on this position.
>>
> Note, this means that you need to ensure all debug printouts from libs and
> drivers are using the RTE_LOG macros so can be runtime controlled. I think
> that may be some distance from reality right now.
>
> Even if we do want all debug enabled from one flag, I'm still not 100%
> convinced that the existing debug flag is the way to do, since it only adds
> debug info to binary without affecting code generation.
OK, I see that there are different opinions on what shape the debug flag 
should look like.
So I think, I'll hold on work on any implementation until we all agree, 
what do we want.

@Bruce: What code generation do you have on mind?

-- 

Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Thomas Monjalon]

20/04/2020 19:30, Bruce Richardson:
> On Mon, Apr 20, 2020 at 07:21:32PM +0200, Thomas Monjalon wrote:
> > 20/04/2020 19:11, Bruce Richardson:
> > > On Mon, Apr 20, 2020 at 04:43:21PM +0200, Lukasz Wojciechowski wrote:
> > > > W dniu 20.04.2020 o 16:21, Bruce Richardson pisze:
> > > > > On Mon, Apr 20, 2020 at 01:37:12PM +0000, Ananyev, Konstantin wrote:
> > > > >>>
> > > <snip>
> > > > >> I am agree with Cristian concern here: that patch removes ability to
> > > > >> enable/disable debug on particular library/PMD.  If the purpose is to
> > > > >> minimize number of config compile options, I wonder can't it be done
> > > > >> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> > > > >> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> > > > >> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> > > > >> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> > > > >> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> > > > >>
> > > > >> defines that are used by multiple libs, probably can be set in upper
> > > > >> layer meson.build.
> > > > >>
> > > > >> That way will have global 'debug' flag, but users will still have an
> > > > >> ability to enable/disable debug flags on a per lib basis via
> > > > >> CFLAGS="-D..."
> > > > >>
> > > > >> Konstantin
> > > > >>
> > > > > That seems a reasonable idea to me.
> > > > >
> > > > > However, in this case, we don't need the RTE_DEBUG flag at all, we can
> > > > > either:
> > > > >
> > > > > * allow each component meson.build file define its own flags after
> > > > > checking get_option('debug') * have lib/meson.build and
> > > > > drivers/meson.build automatically define a specific define for each
> > > > > library or driver to standardize the naming.  [This would save anyone
> > > > > working on it from having to lookup what the define was, since it's
> > > > > always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> > > > > RTE_DEBUG_SCHED etc]
> > > > >
> > > > > Theoretically we can also do both, have the standard ones defined and
> > > > > then allow a component to provide extra flags itself if so desired.
> > > > >
> > > > > /Bruce
> > > > OK, so let's summarize how the patches should be redo: * usage of global
> > > > "debug" flag for meson build stays * we standardize names of debug flags
> > > > in the components to RTE_DEBUG_ + components name * debug flag enables al
> > > > the RTE_DEBUG_... flags
> > > > 
> > > > This allow to easily use both: * the debug flag - to enable all debugs *
> > > > or define manually RTE_DEBUG+component name, just for debug from a single
> > > > component
> > > > 
> > > > I like Bruce's idea of adding it to the lib/meson.build and
> > > > drivers/meson.build. This way they will be added to dpdk_conf meson
> > > > object and written then later to rte_build_config.h before compilation
> > > > stage.  All the other modules will be able to use these flags.
> > > >
> > > Sounds good to me (obviously!), but I'd like other feedback to ensure
> > > others are ok with this before you spend too much effort implementing it.
> > > 
> > > For the drivers, the flag probably needs to include the category as well as
> > > the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> > > name confusion. Those flags can then be checked inside individual
> > > meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> > > you could theoretically do:
> > > 
> > > if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> > > 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> > > 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> > > 	...
> > > endif
> > > 
> > > to enable more fine-grained control if so desired, and to maintain
> > > compatibility with existing defines, again if so desired.
> > 
> > Nak the nak from Cristian.
> > 
> > We don't need all these flags.
> > If the user choose to compile DPDK for debug, every debug facilities
> > should be enabled. Then at runtime it is possible to enable/disable
> > the interesting logs.
> > If you need to disable something which is not a log,
> > you can align with the log level thanks to the function rte_log_can_log.
> > 
> > Please let's stop complicating things for the contributors and the users.
> > Note: I am strong on this position.
> >
> Note, this means that you need to ensure all debug printouts from libs and
> drivers are using the RTE_LOG macros so can be runtime controlled. I think
> that may be some distance from reality right now.

Perfect! Let's expose those nasty logs which are not (yet) controllable.
And next step is to block any patch in those drivers or libs,
until it is fixed. Dynamic logging should have been complete for long.

> Even if we do want all debug enabled from one flag, I'm still not 100%
> convinced that the existing debug flag is the way to do, since it only adds
> debug info to binary without affecting code generation.

OK, we want to keep this flag for gdb symbols only?
And add a new flag for debugging facilities which hurt the runtime performance?

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Bruce Richardson]

On Mon, Apr 20, 2020 at 07:35:36PM +0200, Thomas Monjalon wrote:
> 20/04/2020 19:30, Bruce Richardson:
> > On Mon, Apr 20, 2020 at 07:21:32PM +0200, Thomas Monjalon wrote:
> > > 20/04/2020 19:11, Bruce Richardson:
> > > > On Mon, Apr 20, 2020 at 04:43:21PM +0200, Lukasz Wojciechowski wrote:
> > > > > W dniu 20.04.2020 o 16:21, Bruce Richardson pisze:
> > > > > > On Mon, Apr 20, 2020 at 01:37:12PM +0000, Ananyev, Konstantin wrote:
> > > > > >>>
> > > > <snip>
> > > > > >> I am agree with Cristian concern here: that patch removes ability to
> > > > > >> enable/disable debug on particular library/PMD.  If the purpose is to
> > > > > >> minimize number of config compile options, I wonder can't it be done
> > > > > >> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> > > > > >> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> > > > > >> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> > > > > >> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> > > > > >> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> > > > > >>
> > > > > >> defines that are used by multiple libs, probably can be set in upper
> > > > > >> layer meson.build.
> > > > > >>
> > > > > >> That way will have global 'debug' flag, but users will still have an
> > > > > >> ability to enable/disable debug flags on a per lib basis via
> > > > > >> CFLAGS="-D..."
> > > > > >>
> > > > > >> Konstantin
> > > > > >>
> > > > > > That seems a reasonable idea to me.
> > > > > >
> > > > > > However, in this case, we don't need the RTE_DEBUG flag at all, we can
> > > > > > either:
> > > > > >
> > > > > > * allow each component meson.build file define its own flags after
> > > > > > checking get_option('debug') * have lib/meson.build and
> > > > > > drivers/meson.build automatically define a specific define for each
> > > > > > library or driver to standardize the naming.  [This would save anyone
> > > > > > working on it from having to lookup what the define was, since it's
> > > > > > always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> > > > > > RTE_DEBUG_SCHED etc]
> > > > > >
> > > > > > Theoretically we can also do both, have the standard ones defined and
> > > > > > then allow a component to provide extra flags itself if so desired.
> > > > > >
> > > > > > /Bruce
> > > > > OK, so let's summarize how the patches should be redo: * usage of global
> > > > > "debug" flag for meson build stays * we standardize names of debug flags
> > > > > in the components to RTE_DEBUG_ + components name * debug flag enables al
> > > > > the RTE_DEBUG_... flags
> > > > > 
> > > > > This allow to easily use both: * the debug flag - to enable all debugs *
> > > > > or define manually RTE_DEBUG+component name, just for debug from a single
> > > > > component
> > > > > 
> > > > > I like Bruce's idea of adding it to the lib/meson.build and
> > > > > drivers/meson.build. This way they will be added to dpdk_conf meson
> > > > > object and written then later to rte_build_config.h before compilation
> > > > > stage.  All the other modules will be able to use these flags.
> > > > >
> > > > Sounds good to me (obviously!), but I'd like other feedback to ensure
> > > > others are ok with this before you spend too much effort implementing it.
> > > > 
> > > > For the drivers, the flag probably needs to include the category as well as
> > > > the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> > > > name confusion. Those flags can then be checked inside individual
> > > > meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> > > > you could theoretically do:
> > > > 
> > > > if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> > > > 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> > > > 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> > > > 	...
> > > > endif
> > > > 
> > > > to enable more fine-grained control if so desired, and to maintain
> > > > compatibility with existing defines, again if so desired.
> > > 
> > > Nak the nak from Cristian.
> > > 
> > > We don't need all these flags.
> > > If the user choose to compile DPDK for debug, every debug facilities
> > > should be enabled. Then at runtime it is possible to enable/disable
> > > the interesting logs.
> > > If you need to disable something which is not a log,
> > > you can align with the log level thanks to the function rte_log_can_log.
> > > 
> > > Please let's stop complicating things for the contributors and the users.
> > > Note: I am strong on this position.
> > >
> > Note, this means that you need to ensure all debug printouts from libs and
> > drivers are using the RTE_LOG macros so can be runtime controlled. I think
> > that may be some distance from reality right now.
> 
> Perfect! Let's expose those nasty logs which are not (yet) controllable.
> And next step is to block any patch in those drivers or libs,
> until it is fixed. Dynamic logging should have been complete for long.
> 
I can live with that, I suppose. Do we have any idea of the magnitude of
the work required here?

> > Even if we do want all debug enabled from one flag, I'm still not 100%
> > convinced that the existing debug flag is the way to do, since it only adds
> > debug info to binary without affecting code generation.
> 
> OK, we want to keep this flag for gdb symbols only?
> And add a new flag for debugging facilities which hurt the runtime performance?
> 
I think that would be wise, yes. We can call the option "rte_debug" or
something instead.

/Bruce

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Ananyev, Konstantin]

> > > > > > >> I am agree with Cristian concern here: that patch removes ability to
> > > > > > >> enable/disable debug on particular library/PMD.  If the purpose is to
> > > > > > >> minimize number of config compile options, I wonder can't it be done
> > > > > > >> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> > > > > > >> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> > > > > > >> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> > > > > > >> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> > > > > > >> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> > > > > > >>
> > > > > > >> defines that are used by multiple libs, probably can be set in upper
> > > > > > >> layer meson.build.
> > > > > > >>
> > > > > > >> That way will have global 'debug' flag, but users will still have an
> > > > > > >> ability to enable/disable debug flags on a per lib basis via
> > > > > > >> CFLAGS="-D..."
> > > > > > >>
> > > > > > >> Konstantin
> > > > > > >>
> > > > > > > That seems a reasonable idea to me.
> > > > > > >
> > > > > > > However, in this case, we don't need the RTE_DEBUG flag at all, we can
> > > > > > > either:
> > > > > > >
> > > > > > > * allow each component meson.build file define its own flags after
> > > > > > > checking get_option('debug') * have lib/meson.build and
> > > > > > > drivers/meson.build automatically define a specific define for each
> > > > > > > library or driver to standardize the naming.  [This would save anyone
> > > > > > > working on it from having to lookup what the define was, since it's
> > > > > > > always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> > > > > > > RTE_DEBUG_SCHED etc]
> > > > > > >
> > > > > > > Theoretically we can also do both, have the standard ones defined and
> > > > > > > then allow a component to provide extra flags itself if so desired.
> > > > > > >
> > > > > > > /Bruce
> > > > > > OK, so let's summarize how the patches should be redo: * usage of global
> > > > > > "debug" flag for meson build stays * we standardize names of debug flags
> > > > > > in the components to RTE_DEBUG_ + components name * debug flag enables al
> > > > > > the RTE_DEBUG_... flags
> > > > > >
> > > > > > This allow to easily use both: * the debug flag - to enable all debugs *
> > > > > > or define manually RTE_DEBUG+component name, just for debug from a single
> > > > > > component
> > > > > >
> > > > > > I like Bruce's idea of adding it to the lib/meson.build and
> > > > > > drivers/meson.build. This way they will be added to dpdk_conf meson
> > > > > > object and written then later to rte_build_config.h before compilation
> > > > > > stage.  All the other modules will be able to use these flags.
> > > > > >
> > > > > Sounds good to me (obviously!), but I'd like other feedback to ensure
> > > > > others are ok with this before you spend too much effort implementing it.
> > > > >
> > > > > For the drivers, the flag probably needs to include the category as well as
> > > > > the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> > > > > name confusion. Those flags can then be checked inside individual
> > > > > meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> > > > > you could theoretically do:
> > > > >
> > > > > if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> > > > > 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> > > > > 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> > > > > 	...
> > > > > endif
> > > > >
> > > > > to enable more fine-grained control if so desired, and to maintain
> > > > > compatibility with existing defines, again if so desired.
> > > >
> > > > Nak the nak from Cristian.
> > > >
> > > > We don't need all these flags.
> > > > If the user choose to compile DPDK for debug, every debug facilities
> > > > should be enabled. Then at runtime it is possible to enable/disable
> > > > the interesting logs.
> > > > If you need to disable something which is not a log,
> > > > you can align with the log level thanks to the function rte_log_can_log.

For many libs these flags mean much more than just logging.
Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
drivers - extra validation performed.
RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
rte_mbuf_sanity_check() instead of just NOP.
Which means performance would be greatly affected.
RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
and enforce extra checking, stats collection.
etc.
Probably that's ok for some cases to enable all that extra validation we have at once.
But I suppose in many cases people just interested to enable debug on one
(ok might be two/three) particular libraries, not the whole system.
Right now there is such ability, we are going to remove it without
providing adequate replacement.   
Approach with rte_log_can_log() seems workable,
but right now these patches don't implement it. 
Konstantin

> > > >
> > > > Please let's stop complicating things for the contributors and the users.
> > > > Note: I am strong on this position.
> > > >
> > > Note, this means that you need to ensure all debug printouts from libs and
> > > drivers are using the RTE_LOG macros so can be runtime controlled. I think
> > > that may be some distance from reality right now.
> >
> > Perfect! Let's expose those nasty logs which are not (yet) controllable.
> > And next step is to block any patch in those drivers or libs,
> > until it is fixed. Dynamic logging should have been complete for long.
> >
> I can live with that, I suppose. Do we have any idea of the magnitude of
> the work required here?
> 
> > > Even if we do want all debug enabled from one flag, I'm still not 100%
> > > convinced that the existing debug flag is the way to do, since it only adds
> > > debug info to binary without affecting code generation.
> >
> > OK, we want to keep this flag for gdb symbols only?
> > And add a new flag for debugging facilities which hurt the runtime performance?
> >
> I think that would be wise, yes. We can call the option "rte_debug" or
> something instead.
> 
> /Bruce

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Lukasz Wojciechowski]

W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze:
>
>>>>>>>>> I am agree with Cristian concern here: that patch removes ability to
>>>>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
>>>>>>>>> minimize number of config compile options, I wonder can't it be done
>>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
>>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
>>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
>>>>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
>>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
>>>>>>>>>
>>>>>>>>> defines that are used by multiple libs, probably can be set in upper
>>>>>>>>> layer meson.build.
>>>>>>>>>
>>>>>>>>> That way will have global 'debug' flag, but users will still have an
>>>>>>>>> ability to enable/disable debug flags on a per lib basis via
>>>>>>>>> CFLAGS="-D..."
>>>>>>>>>
>>>>>>>>> Konstantin
>>>>>>>>>
>>>>>>>> That seems a reasonable idea to me.
>>>>>>>>
>>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
>>>>>>>> either:
>>>>>>>>
>>>>>>>> * allow each component meson.build file define its own flags after
>>>>>>>> checking get_option('debug') * have lib/meson.build and
>>>>>>>> drivers/meson.build automatically define a specific define for each
>>>>>>>> library or driver to standardize the naming.  [This would save anyone
>>>>>>>> working on it from having to lookup what the define was, since it's
>>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
>>>>>>>> RTE_DEBUG_SCHED etc]
>>>>>>>>
>>>>>>>> Theoretically we can also do both, have the standard ones defined and
>>>>>>>> then allow a component to provide extra flags itself if so desired.
>>>>>>>>
>>>>>>>> /Bruce
>>>>>>> OK, so let's summarize how the patches should be redo: * usage of global
>>>>>>> "debug" flag for meson build stays * we standardize names of debug flags
>>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
>>>>>>> the RTE_DEBUG_... flags
>>>>>>>
>>>>>>> This allow to easily use both: * the debug flag - to enable all debugs *
>>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single
>>>>>>> component
>>>>>>>
>>>>>>> I like Bruce's idea of adding it to the lib/meson.build and
>>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
>>>>>>> object and written then later to rte_build_config.h before compilation
>>>>>>> stage.  All the other modules will be able to use these flags.
>>>>>>>
>>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
>>>>>> others are ok with this before you spend too much effort implementing it.
>>>>>>
>>>>>> For the drivers, the flag probably needs to include the category as well as
>>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
>>>>>> name confusion. Those flags can then be checked inside individual
>>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
>>>>>> you could theoretically do:
>>>>>>
>>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
>>>>>> 	...
>>>>>> endif
>>>>>>
>>>>>> to enable more fine-grained control if so desired, and to maintain
>>>>>> compatibility with existing defines, again if so desired.
>>>>> Nak the nak from Cristian.
>>>>>
>>>>> We don't need all these flags.
>>>>> If the user choose to compile DPDK for debug, every debug facilities
>>>>> should be enabled. Then at runtime it is possible to enable/disable
>>>>> the interesting logs.
>>>>> If you need to disable something which is not a log,
>>>>> you can align with the log level thanks to the function rte_log_can_log.
> For many libs these flags mean much more than just logging.
> Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
> drivers - extra validation performed.
> RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
> rte_mbuf_sanity_check() instead of just NOP.
> Which means performance would be greatly affected.
> RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
> and enforce extra checking, stats collection.
> etc.
> Probably that's ok for some cases to enable all that extra validation we have at once.
> But I suppose in many cases people just interested to enable debug on one
> (ok might be two/three) particular libraries, not the whole system.
> Right now there is such ability, we are going to remove it without
> providing adequate replacement.
> Approach with rte_log_can_log() seems workable,
> but right now these patches don't implement it.
> Konstantin
>
>>>>> Please let's stop complicating things for the contributors and the users.
>>>>> Note: I am strong on this position.
>>>>>
>>>> Note, this means that you need to ensure all debug printouts from libs and
>>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think
>>>> that may be some distance from reality right now.
>>> Perfect! Let's expose those nasty logs which are not (yet) controllable.
>>> And next step is to block any patch in those drivers or libs,
>>> until it is fixed. Dynamic logging should have been complete for long.
>>>
>> I can live with that, I suppose. Do we have any idea of the magnitude of
>> the work required here?
>>
>>>> Even if we do want all debug enabled from one flag, I'm still not 100%
>>>> convinced that the existing debug flag is the way to do, since it only adds
>>>> debug info to binary without affecting code generation.
>>> OK, we want to keep this flag for gdb symbols only?
>>> And add a new flag for debugging facilities which hurt the runtime performance?
>>>
>> I think that would be wise, yes. We can call the option "rte_debug" or
>> something instead.
>>
>> /Bruce
OK, lets's summarize current opinions and requirements to make a 
proposal for version2 of these patches, that I can implement if all agree:

1) The global debug flag is required to enable all the sanity checks and 
validations that are normally not used due to performance reasons

2) The best option would be to have a single flag - not to introduce too 
many build options

3) This option should be separated from meson "debug" option (used for 
build with symbols) and can be called "rte_debug"

4) The currently existing DEBUG macros should not be replaced with a 
RTE_DEBUG macro. This would allow to still enable them using 
CFLAGS="-D..." to test a single module (library, driver).

5) Currently existing options' names should be standardized to 
RTE_DEBUG_{library/driver name}, so they can be automatically enabled 
when rte_debug is set. Standardized names would allow easy usage in 
other modules.
Should they? Or should we leave the current debug macros? Please share 
your opinions as I see both cons and pros of this idea.

6) To avoid logs flood using this option, logging functionality in the 
debug section of the code should use valid logtype, so they can be 
filtered out by rte_log_can_log().
This can be done in 2nd stage, when all logs not using proper logtype 
will be exposed in rte_debug mode.

7) For the drivers, which have multiple debug flags ..._TX, ..._RX, etc. 
in case of rt_debug all can be enabled in driver's internal meson.build 
(as Bruce proposed above)


There is also an alternative proposed: defining options like 
debug_drivers or debug_libraries that would use globs and work similar 
way to the disable_drivers.


Please share you opinion about this plan!

-- 

Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Thomas Monjalon]

21/04/2020 22:58, Lukasz Wojciechowski:
> 
> W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze:
> >
> >>>>>>>>> I am agree with Cristian concern here: that patch removes ability to
> >>>>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
> >>>>>>>>> minimize number of config compile options, I wonder can't it be done
> >>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> >>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> >>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> >>>>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> >>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> >>>>>>>>>
> >>>>>>>>> defines that are used by multiple libs, probably can be set in upper
> >>>>>>>>> layer meson.build.
> >>>>>>>>>
> >>>>>>>>> That way will have global 'debug' flag, but users will still have an
> >>>>>>>>> ability to enable/disable debug flags on a per lib basis via
> >>>>>>>>> CFLAGS="-D..."
> >>>>>>>>>
> >>>>>>>>> Konstantin
> >>>>>>>>>
> >>>>>>>> That seems a reasonable idea to me.
> >>>>>>>>
> >>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
> >>>>>>>> either:
> >>>>>>>>
> >>>>>>>> * allow each component meson.build file define its own flags after
> >>>>>>>> checking get_option('debug') * have lib/meson.build and
> >>>>>>>> drivers/meson.build automatically define a specific define for each
> >>>>>>>> library or driver to standardize the naming.  [This would save anyone
> >>>>>>>> working on it from having to lookup what the define was, since it's
> >>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> >>>>>>>> RTE_DEBUG_SCHED etc]
> >>>>>>>>
> >>>>>>>> Theoretically we can also do both, have the standard ones defined and
> >>>>>>>> then allow a component to provide extra flags itself if so desired.
> >>>>>>>>
> >>>>>>>> /Bruce
> >>>>>>> OK, so let's summarize how the patches should be redo: * usage of global
> >>>>>>> "debug" flag for meson build stays * we standardize names of debug flags
> >>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
> >>>>>>> the RTE_DEBUG_... flags
> >>>>>>>
> >>>>>>> This allow to easily use both: * the debug flag - to enable all debugs *
> >>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single
> >>>>>>> component
> >>>>>>>
> >>>>>>> I like Bruce's idea of adding it to the lib/meson.build and
> >>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
> >>>>>>> object and written then later to rte_build_config.h before compilation
> >>>>>>> stage.  All the other modules will be able to use these flags.
> >>>>>>>
> >>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
> >>>>>> others are ok with this before you spend too much effort implementing it.
> >>>>>>
> >>>>>> For the drivers, the flag probably needs to include the category as well as
> >>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> >>>>>> name confusion. Those flags can then be checked inside individual
> >>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> >>>>>> you could theoretically do:
> >>>>>>
> >>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> >>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> >>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> >>>>>> 	...
> >>>>>> endif
> >>>>>>
> >>>>>> to enable more fine-grained control if so desired, and to maintain
> >>>>>> compatibility with existing defines, again if so desired.
> >>>>> Nak the nak from Cristian.
> >>>>>
> >>>>> We don't need all these flags.
> >>>>> If the user choose to compile DPDK for debug, every debug facilities
> >>>>> should be enabled. Then at runtime it is possible to enable/disable
> >>>>> the interesting logs.
> >>>>> If you need to disable something which is not a log,
> >>>>> you can align with the log level thanks to the function rte_log_can_log.
> > For many libs these flags mean much more than just logging.
> > Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
> > drivers - extra validation performed.
> > RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
> > rte_mbuf_sanity_check() instead of just NOP.
> > Which means performance would be greatly affected.
> > RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
> > and enforce extra checking, stats collection.
> > etc.
> > Probably that's ok for some cases to enable all that extra validation we have at once.
> > But I suppose in many cases people just interested to enable debug on one
> > (ok might be two/three) particular libraries, not the whole system.
> > Right now there is such ability, we are going to remove it without
> > providing adequate replacement.
> > Approach with rte_log_can_log() seems workable,
> > but right now these patches don't implement it.
> > Konstantin
> >
> >>>>> Please let's stop complicating things for the contributors and the users.
> >>>>> Note: I am strong on this position.
> >>>>>
> >>>> Note, this means that you need to ensure all debug printouts from libs and
> >>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think
> >>>> that may be some distance from reality right now.
> >>> Perfect! Let's expose those nasty logs which are not (yet) controllable.
> >>> And next step is to block any patch in those drivers or libs,
> >>> until it is fixed. Dynamic logging should have been complete for long.
> >>>
> >> I can live with that, I suppose. Do we have any idea of the magnitude of
> >> the work required here?
> >>
> >>>> Even if we do want all debug enabled from one flag, I'm still not 100%
> >>>> convinced that the existing debug flag is the way to do, since it only adds
> >>>> debug info to binary without affecting code generation.
> >>> OK, we want to keep this flag for gdb symbols only?
> >>> And add a new flag for debugging facilities which hurt the runtime performance?
> >>>
> >> I think that would be wise, yes. We can call the option "rte_debug" or
> >> something instead.
> >>
> >> /Bruce
> OK, lets's summarize current opinions and requirements to make a 
> proposal for version2 of these patches, that I can implement if all agree:
> 
> 1) The global debug flag is required to enable all the sanity checks and 
> validations that are normally not used due to performance reasons

Yes

> 2) The best option would be to have a single flag - not to introduce too 
> many build options

Yes

> 3) This option should be separated from meson "debug" option (used for 
> build with symbols) and can be called "rte_debug"

Yes, it looks to be the consensus.

> 4) The currently existing DEBUG macros should not be replaced with a 
> RTE_DEBUG macro. This would allow to still enable them using 
> CFLAGS="-D..." to test a single module (library, driver).
> 
> 5) Currently existing options' names should be standardized to 
> RTE_DEBUG_{library/driver name}, so they can be automatically enabled 
> when rte_debug is set. Standardized names would allow easy usage in 
> other modules.

I don't understand difference between 4) et 5).

> Should they? Or should we leave the current debug macros? Please share 
> your opinions as I see both cons and pros of this idea.

I am not sure we need to keep fine-grain debug flags per libs/drivers.
In case RTE_DEBUG is enabled, which kind of debug processing
(except logs) do we want to be able to disable?
Is it possible to decide based on a call to rte_log_can_log()?

> 6) To avoid logs flood using this option, logging functionality in the 
> debug section of the code should use valid logtype, so they can be 
> filtered out by rte_log_can_log().

rte_log_can_log() is not for logs. It allows to enable/disable some
code following the same rule as a logtype.

> This can be done in 2nd stage, when all logs not using proper logtype 
> will be exposed in rte_debug mode.
> 
> 7) For the drivers, which have multiple debug flags ..._TX, ..._RX, etc. 
> in case of rt_debug all can be enabled in driver's internal meson.build 
> (as Bruce proposed above)
> 
> 
> There is also an alternative proposed: defining options like 
> debug_drivers or debug_libraries that would use globs and work similar 
> way to the disable_drivers.
> 
> 
> Please share you opinion about this plan!

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Lukasz Wojciechowski]

W dniu 21.04.2020 o 23:38, Thomas Monjalon pisze:
> 21/04/2020 22:58, Lukasz Wojciechowski:
>> W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze:
>>>>>>>>>>> I am agree with Cristian concern here: that patch removes ability to
>>>>>>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
>>>>>>>>>>> minimize number of config compile options, I wonder can't it be done
>>>>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
>>>>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
>>>>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
>>>>>>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
>>>>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
>>>>>>>>>>>
>>>>>>>>>>> defines that are used by multiple libs, probably can be set in upper
>>>>>>>>>>> layer meson.build.
>>>>>>>>>>>
>>>>>>>>>>> That way will have global 'debug' flag, but users will still have an
>>>>>>>>>>> ability to enable/disable debug flags on a per lib basis via
>>>>>>>>>>> CFLAGS="-D..."
>>>>>>>>>>>
>>>>>>>>>>> Konstantin
>>>>>>>>>>>
>>>>>>>>>> That seems a reasonable idea to me.
>>>>>>>>>>
>>>>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
>>>>>>>>>> either:
>>>>>>>>>>
>>>>>>>>>> * allow each component meson.build file define its own flags after
>>>>>>>>>> checking get_option('debug') * have lib/meson.build and
>>>>>>>>>> drivers/meson.build automatically define a specific define for each
>>>>>>>>>> library or driver to standardize the naming.  [This would save anyone
>>>>>>>>>> working on it from having to lookup what the define was, since it's
>>>>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
>>>>>>>>>> RTE_DEBUG_SCHED etc]
>>>>>>>>>>
>>>>>>>>>> Theoretically we can also do both, have the standard ones defined and
>>>>>>>>>> then allow a component to provide extra flags itself if so desired.
>>>>>>>>>>
>>>>>>>>>> /Bruce
>>>>>>>>> OK, so let's summarize how the patches should be redo: * usage of global
>>>>>>>>> "debug" flag for meson build stays * we standardize names of debug flags
>>>>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
>>>>>>>>> the RTE_DEBUG_... flags
>>>>>>>>>
>>>>>>>>> This allow to easily use both: * the debug flag - to enable all debugs *
>>>>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single
>>>>>>>>> component
>>>>>>>>>
>>>>>>>>> I like Bruce's idea of adding it to the lib/meson.build and
>>>>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
>>>>>>>>> object and written then later to rte_build_config.h before compilation
>>>>>>>>> stage.  All the other modules will be able to use these flags.
>>>>>>>>>
>>>>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
>>>>>>>> others are ok with this before you spend too much effort implementing it.
>>>>>>>>
>>>>>>>> For the drivers, the flag probably needs to include the category as well as
>>>>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
>>>>>>>> name confusion. Those flags can then be checked inside individual
>>>>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
>>>>>>>> you could theoretically do:
>>>>>>>>
>>>>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
>>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
>>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
>>>>>>>> 	...
>>>>>>>> endif
>>>>>>>>
>>>>>>>> to enable more fine-grained control if so desired, and to maintain
>>>>>>>> compatibility with existing defines, again if so desired.
>>>>>>> Nak the nak from Cristian.
>>>>>>>
>>>>>>> We don't need all these flags.
>>>>>>> If the user choose to compile DPDK for debug, every debug facilities
>>>>>>> should be enabled. Then at runtime it is possible to enable/disable
>>>>>>> the interesting logs.
>>>>>>> If you need to disable something which is not a log,
>>>>>>> you can align with the log level thanks to the function rte_log_can_log.
>>> For many libs these flags mean much more than just logging.
>>> Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
>>> drivers - extra validation performed.
>>> RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
>>> rte_mbuf_sanity_check() instead of just NOP.
>>> Which means performance would be greatly affected.
>>> RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
>>> and enforce extra checking, stats collection.
>>> etc.
>>> Probably that's ok for some cases to enable all that extra validation we have at once.
>>> But I suppose in many cases people just interested to enable debug on one
>>> (ok might be two/three) particular libraries, not the whole system.
>>> Right now there is such ability, we are going to remove it without
>>> providing adequate replacement.
>>> Approach with rte_log_can_log() seems workable,
>>> but right now these patches don't implement it.
>>> Konstantin
>>>
>>>>>>> Please let's stop complicating things for the contributors and the users.
>>>>>>> Note: I am strong on this position.
>>>>>>>
>>>>>> Note, this means that you need to ensure all debug printouts from libs and
>>>>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think
>>>>>> that may be some distance from reality right now.
>>>>> Perfect! Let's expose those nasty logs which are not (yet) controllable.
>>>>> And next step is to block any patch in those drivers or libs,
>>>>> until it is fixed. Dynamic logging should have been complete for long.
>>>>>
>>>> I can live with that, I suppose. Do we have any idea of the magnitude of
>>>> the work required here?
>>>>
>>>>>> Even if we do want all debug enabled from one flag, I'm still not 100%
>>>>>> convinced that the existing debug flag is the way to do, since it only adds
>>>>>> debug info to binary without affecting code generation.
>>>>> OK, we want to keep this flag for gdb symbols only?
>>>>> And add a new flag for debugging facilities which hurt the runtime performance?
>>>>>
>>>> I think that would be wise, yes. We can call the option "rte_debug" or
>>>> something instead.
>>>>
>>>> /Bruce
>> OK, lets's summarize current opinions and requirements to make a
>> proposal for version2 of these patches, that I can implement if all agree:
>>
>> 1) The global debug flag is required to enable all the sanity checks and
>> validations that are normally not used due to performance reasons
> Yes
>
>> 2) The best option would be to have a single flag - not to introduce too
>> many build options
> Yes
>
>> 3) This option should be separated from meson "debug" option (used for
>> build with symbols) and can be called "rte_debug"
> Yes, it looks to be the consensus.
>
>> 4) The currently existing DEBUG macros should not be replaced with a
>> RTE_DEBUG macro. This would allow to still enable them using
>> CFLAGS="-D..." to test a single module (library, driver).
>>
>> 5) Currently existing options' names should be standardized to
>> RTE_DEBUG_{library/driver name}, so they can be automatically enabled
>> when rte_debug is set. Standardized names would allow easy usage in
>> other modules.
> I don't understand difference between 4) et 5).

In current version of patches, I replaced all the DEBUG macros with 
RTE_DEBUG. It would be much better to keep fine-grained debugs as they 
are defined currently in dpdk. This is what I have on mind in 4)

However the currently used debug macros have different naming 
conventions: some use RTE_LIBRTE_{name}_DEBUG convention, other 
RTE_{name}_DEBUG, some just {name}_DEBUG.
So in 5) I follow Bruce's proposal to standardize them to one form 
RTE_DEBUG_{name}. However this will change the existing macros and 
someone might not like it, so I ask for the opinion about it.


>> Should they? Or should we leave the current debug macros? Please share
>> your opinions as I see both cons and pros of this idea.
> I am not sure we need to keep fine-grain debug flags per libs/drivers.
> In case RTE_DEBUG is enabled, which kind of debug processing
> (except logs) do we want to be able to disable?
> Is it possible to decide based on a call to rte_log_can_log()?
I think it's rather opposite way round. Sometimes we would like to 
enable just some debug processing, e.g. when working on single lib or 
driver.
If we will use rte_debug - every debug  processing would be enabled, we 
won't disable anything, but without rte_debug we will still have the 
possibility of enabling debugs on a single module.

I believe it is possible to do it with rte_log_can_log, but changing 
build time enabled options into runtime enabled options might affect 
performance. It might make working on a single library or driver harder.

>
>> 6) To avoid logs flood using this option, logging functionality in the
>> debug section of the code should use valid logtype, so they can be
>> filtered out by rte_log_can_log().
> rte_log_can_log() is not for logs. It allows to enable/disable some
> code following the same rule as a logtype.
Oh, I didn't know, that it should be used this way also.
Currently except for logs it's used in 5 places and are related with 
printing some information. So I thought it was just for logging.
>
>> This can be done in 2nd stage, when all logs not using proper logtype
>> will be exposed in rte_debug mode.
>>
>> 7) For the drivers, which have multiple debug flags ..._TX, ..._RX, etc.
>> in case of rt_debug all can be enabled in driver's internal meson.build
>> (as Bruce proposed above)
>>
>>
>> There is also an alternative proposed: defining options like
>> debug_drivers or debug_libraries that would use globs and work similar
>> way to the disable_drivers.
>>
>>
>> Please share you opinion about this plan!
>
>
>
-- 

Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Bruce Richardson]

On Wed, Apr 22, 2020 at 12:41:49PM +0200, Lukasz Wojciechowski wrote:
> 
> W dniu 21.04.2020 o 23:38, Thomas Monjalon pisze:
> > 21/04/2020 22:58, Lukasz Wojciechowski:
> >> W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze:
> >>>>>>>>>>> I am agree with Cristian concern here: that patch removes ability to
> >>>>>>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
> >>>>>>>>>>> minimize number of config compile options, I wonder can't it be done
> >>>>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> >>>>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> >>>>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> >>>>>>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> >>>>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> >>>>>>>>>>>
> >>>>>>>>>>> defines that are used by multiple libs, probably can be set in upper
> >>>>>>>>>>> layer meson.build.
> >>>>>>>>>>>
> >>>>>>>>>>> That way will have global 'debug' flag, but users will still have an
> >>>>>>>>>>> ability to enable/disable debug flags on a per lib basis via
> >>>>>>>>>>> CFLAGS="-D..."
> >>>>>>>>>>>
> >>>>>>>>>>> Konstantin
> >>>>>>>>>>>
> >>>>>>>>>> That seems a reasonable idea to me.
> >>>>>>>>>>
> >>>>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
> >>>>>>>>>> either:
> >>>>>>>>>>
> >>>>>>>>>> * allow each component meson.build file define its own flags after
> >>>>>>>>>> checking get_option('debug') * have lib/meson.build and
> >>>>>>>>>> drivers/meson.build automatically define a specific define for each
> >>>>>>>>>> library or driver to standardize the naming.  [This would save anyone
> >>>>>>>>>> working on it from having to lookup what the define was, since it's
> >>>>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> >>>>>>>>>> RTE_DEBUG_SCHED etc]
> >>>>>>>>>>
> >>>>>>>>>> Theoretically we can also do both, have the standard ones defined and
> >>>>>>>>>> then allow a component to provide extra flags itself if so desired.
> >>>>>>>>>>
> >>>>>>>>>> /Bruce
> >>>>>>>>> OK, so let's summarize how the patches should be redo: * usage of global
> >>>>>>>>> "debug" flag for meson build stays * we standardize names of debug flags
> >>>>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
> >>>>>>>>> the RTE_DEBUG_... flags
> >>>>>>>>>
> >>>>>>>>> This allow to easily use both: * the debug flag - to enable all debugs *
> >>>>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single
> >>>>>>>>> component
> >>>>>>>>>
> >>>>>>>>> I like Bruce's idea of adding it to the lib/meson.build and
> >>>>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
> >>>>>>>>> object and written then later to rte_build_config.h before compilation
> >>>>>>>>> stage.  All the other modules will be able to use these flags.
> >>>>>>>>>
> >>>>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
> >>>>>>>> others are ok with this before you spend too much effort implementing it.
> >>>>>>>>
> >>>>>>>> For the drivers, the flag probably needs to include the category as well as
> >>>>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> >>>>>>>> name confusion. Those flags can then be checked inside individual
> >>>>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> >>>>>>>> you could theoretically do:
> >>>>>>>>
> >>>>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> >>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> >>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> >>>>>>>> 	...
> >>>>>>>> endif
> >>>>>>>>
> >>>>>>>> to enable more fine-grained control if so desired, and to maintain
> >>>>>>>> compatibility with existing defines, again if so desired.
> >>>>>>> Nak the nak from Cristian.
> >>>>>>>
> >>>>>>> We don't need all these flags.
> >>>>>>> If the user choose to compile DPDK for debug, every debug facilities
> >>>>>>> should be enabled. Then at runtime it is possible to enable/disable
> >>>>>>> the interesting logs.
> >>>>>>> If you need to disable something which is not a log,
> >>>>>>> you can align with the log level thanks to the function rte_log_can_log.
> >>> For many libs these flags mean much more than just logging.
> >>> Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
> >>> drivers - extra validation performed.
> >>> RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
> >>> rte_mbuf_sanity_check() instead of just NOP.
> >>> Which means performance would be greatly affected.
> >>> RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
> >>> and enforce extra checking, stats collection.
> >>> etc.
> >>> Probably that's ok for some cases to enable all that extra validation we have at once.
> >>> But I suppose in many cases people just interested to enable debug on one
> >>> (ok might be two/three) particular libraries, not the whole system.
> >>> Right now there is such ability, we are going to remove it without
> >>> providing adequate replacement.
> >>> Approach with rte_log_can_log() seems workable,
> >>> but right now these patches don't implement it.
> >>> Konstantin
> >>>
> >>>>>>> Please let's stop complicating things for the contributors and the users.
> >>>>>>> Note: I am strong on this position.
> >>>>>>>
> >>>>>> Note, this means that you need to ensure all debug printouts from libs and
> >>>>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think
> >>>>>> that may be some distance from reality right now.
> >>>>> Perfect! Let's expose those nasty logs which are not (yet) controllable.
> >>>>> And next step is to block any patch in those drivers or libs,
> >>>>> until it is fixed. Dynamic logging should have been complete for long.
> >>>>>
> >>>> I can live with that, I suppose. Do we have any idea of the magnitude of
> >>>> the work required here?
> >>>>
> >>>>>> Even if we do want all debug enabled from one flag, I'm still not 100%
> >>>>>> convinced that the existing debug flag is the way to do, since it only adds
> >>>>>> debug info to binary without affecting code generation.
> >>>>> OK, we want to keep this flag for gdb symbols only?
> >>>>> And add a new flag for debugging facilities which hurt the runtime performance?
> >>>>>
> >>>> I think that would be wise, yes. We can call the option "rte_debug" or
> >>>> something instead.
> >>>>
> >>>> /Bruce
> >> OK, lets's summarize current opinions and requirements to make a
> >> proposal for version2 of these patches, that I can implement if all agree:
> >>
> >> 1) The global debug flag is required to enable all the sanity checks and
> >> validations that are normally not used due to performance reasons
> > Yes
> >
> >> 2) The best option would be to have a single flag - not to introduce too
> >> many build options
> > Yes
> >
> >> 3) This option should be separated from meson "debug" option (used for
> >> build with symbols) and can be called "rte_debug"
> > Yes, it looks to be the consensus.
> >
> >> 4) The currently existing DEBUG macros should not be replaced with a
> >> RTE_DEBUG macro. This would allow to still enable them using
> >> CFLAGS="-D..." to test a single module (library, driver).
> >>
> >> 5) Currently existing options' names should be standardized to
> >> RTE_DEBUG_{library/driver name}, so they can be automatically enabled
> >> when rte_debug is set. Standardized names would allow easy usage in
> >> other modules.
> > I don't understand difference between 4) et 5).
> 
> In current version of patches, I replaced all the DEBUG macros with 
> RTE_DEBUG. It would be much better to keep fine-grained debugs as they 
> are defined currently in dpdk. This is what I have on mind in 4)
> 
> However the currently used debug macros have different naming 
> conventions: some use RTE_LIBRTE_{name}_DEBUG convention, other 
> RTE_{name}_DEBUG, some just {name}_DEBUG.
> So in 5) I follow Bruce's proposal to standardize them to one form 
> RTE_DEBUG_{name}. However this will change the existing macros and 
> someone might not like it, so I ask for the opinion about it.
> 
My thought is to standardize in the build and then leave it to module
owners to either change their macros to use those standard ones as time
goes on.

> 
> >> Should they? Or should we leave the current debug macros? Please share
> >> your opinions as I see both cons and pros of this idea.
> > I am not sure we need to keep fine-grain debug flags per libs/drivers.
> > In case RTE_DEBUG is enabled, which kind of debug processing
> > (except logs) do we want to be able to disable?
> > Is it possible to decide based on a call to rte_log_can_log()?
> I think it's rather opposite way round. Sometimes we would like to 
> enable just some debug processing, e.g. when working on single lib or 
> driver.
> If we will use rte_debug - every debug  processing would be enabled, we 
> won't disable anything, but without rte_debug we will still have the 
> possibility of enabling debugs on a single module.
> 
> I believe it is possible to do it with rte_log_can_log, but changing 
> build time enabled options into runtime enabled options might affect 
> performance. It might make working on a single library or driver harder.
> 

I think the idea is to use both. When RTE_DEBUG is enabled, then the
rte_log_can_log() calls will be used to control the actual output. Without
RTE_DEBUG, the whole block is skipped.

#ifdef RTE_DEBUG
	if rte_log_can_log(...) {
		/* do debug stuff */
	}
#endif

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Thomas Monjalon]

22/04/2020 12:55, Bruce Richardson:
> On Wed, Apr 22, 2020 at 12:41:49PM +0200, Lukasz Wojciechowski wrote:
> > W dniu 21.04.2020 o 23:38, Thomas Monjalon pisze:
> > > 21/04/2020 22:58, Lukasz Wojciechowski:
> > >> W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze:
> > >>>>>>>>>>> I am agree with Cristian concern here: that patch removes ability to
> > >>>>>>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
> > >>>>>>>>>>> minimize number of config compile options, I wonder can't it be done
> > >>>>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> > >>>>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> > >>>>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> > >>>>>>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> > >>>>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> > >>>>>>>>>>>
> > >>>>>>>>>>> defines that are used by multiple libs, probably can be set in upper
> > >>>>>>>>>>> layer meson.build.
> > >>>>>>>>>>>
> > >>>>>>>>>>> That way will have global 'debug' flag, but users will still have an
> > >>>>>>>>>>> ability to enable/disable debug flags on a per lib basis via
> > >>>>>>>>>>> CFLAGS="-D..."
> > >>>>>>>>>>>
> > >>>>>>>>>>> Konstantin
> > >>>>>>>>>>>
> > >>>>>>>>>> That seems a reasonable idea to me.
> > >>>>>>>>>>
> > >>>>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
> > >>>>>>>>>> either:
> > >>>>>>>>>>
> > >>>>>>>>>> * allow each component meson.build file define its own flags after
> > >>>>>>>>>> checking get_option('debug') * have lib/meson.build and
> > >>>>>>>>>> drivers/meson.build automatically define a specific define for each
> > >>>>>>>>>> library or driver to standardize the naming.  [This would save anyone
> > >>>>>>>>>> working on it from having to lookup what the define was, since it's
> > >>>>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> > >>>>>>>>>> RTE_DEBUG_SCHED etc]
> > >>>>>>>>>>
> > >>>>>>>>>> Theoretically we can also do both, have the standard ones defined and
> > >>>>>>>>>> then allow a component to provide extra flags itself if so desired.
> > >>>>>>>>>>
> > >>>>>>>>>> /Bruce
> > >>>>>>>>> OK, so let's summarize how the patches should be redo: * usage of global
> > >>>>>>>>> "debug" flag for meson build stays * we standardize names of debug flags
> > >>>>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
> > >>>>>>>>> the RTE_DEBUG_... flags
> > >>>>>>>>>
> > >>>>>>>>> This allow to easily use both: * the debug flag - to enable all debugs *
> > >>>>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single
> > >>>>>>>>> component
> > >>>>>>>>>
> > >>>>>>>>> I like Bruce's idea of adding it to the lib/meson.build and
> > >>>>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
> > >>>>>>>>> object and written then later to rte_build_config.h before compilation
> > >>>>>>>>> stage.  All the other modules will be able to use these flags.
> > >>>>>>>>>
> > >>>>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
> > >>>>>>>> others are ok with this before you spend too much effort implementing it.
> > >>>>>>>>
> > >>>>>>>> For the drivers, the flag probably needs to include the category as well as
> > >>>>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> > >>>>>>>> name confusion. Those flags can then be checked inside individual
> > >>>>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> > >>>>>>>> you could theoretically do:
> > >>>>>>>>
> > >>>>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> > >>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> > >>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> > >>>>>>>> 	...
> > >>>>>>>> endif
> > >>>>>>>>
> > >>>>>>>> to enable more fine-grained control if so desired, and to maintain
> > >>>>>>>> compatibility with existing defines, again if so desired.
> > >>>>>>> Nak the nak from Cristian.
> > >>>>>>>
> > >>>>>>> We don't need all these flags.
> > >>>>>>> If the user choose to compile DPDK for debug, every debug facilities
> > >>>>>>> should be enabled. Then at runtime it is possible to enable/disable
> > >>>>>>> the interesting logs.
> > >>>>>>> If you need to disable something which is not a log,
> > >>>>>>> you can align with the log level thanks to the function rte_log_can_log.
> > >>> For many libs these flags mean much more than just logging.
> > >>> Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
> > >>> drivers - extra validation performed.
> > >>> RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
> > >>> rte_mbuf_sanity_check() instead of just NOP.
> > >>> Which means performance would be greatly affected.
> > >>> RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
> > >>> and enforce extra checking, stats collection.
> > >>> etc.
> > >>> Probably that's ok for some cases to enable all that extra validation we have at once.
> > >>> But I suppose in many cases people just interested to enable debug on one
> > >>> (ok might be two/three) particular libraries, not the whole system.
> > >>> Right now there is such ability, we are going to remove it without
> > >>> providing adequate replacement.
> > >>> Approach with rte_log_can_log() seems workable,
> > >>> but right now these patches don't implement it.
> > >>> Konstantin
> > >>>
> > >>>>>>> Please let's stop complicating things for the contributors and the users.
> > >>>>>>> Note: I am strong on this position.
> > >>>>>>>
> > >>>>>> Note, this means that you need to ensure all debug printouts from libs and
> > >>>>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think
> > >>>>>> that may be some distance from reality right now.
> > >>>>> Perfect! Let's expose those nasty logs which are not (yet) controllable.
> > >>>>> And next step is to block any patch in those drivers or libs,
> > >>>>> until it is fixed. Dynamic logging should have been complete for long.
> > >>>>>
> > >>>> I can live with that, I suppose. Do we have any idea of the magnitude of
> > >>>> the work required here?
> > >>>>
> > >>>>>> Even if we do want all debug enabled from one flag, I'm still not 100%
> > >>>>>> convinced that the existing debug flag is the way to do, since it only adds
> > >>>>>> debug info to binary without affecting code generation.
> > >>>>> OK, we want to keep this flag for gdb symbols only?
> > >>>>> And add a new flag for debugging facilities which hurt the runtime performance?
> > >>>>>
> > >>>> I think that would be wise, yes. We can call the option "rte_debug" or
> > >>>> something instead.
> > >>>>
> > >>>> /Bruce
> > >> OK, lets's summarize current opinions and requirements to make a
> > >> proposal for version2 of these patches, that I can implement if all agree:
> > >>
> > >> 1) The global debug flag is required to enable all the sanity checks and
> > >> validations that are normally not used due to performance reasons
> > > Yes
> > >
> > >> 2) The best option would be to have a single flag - not to introduce too
> > >> many build options
> > > Yes
> > >
> > >> 3) This option should be separated from meson "debug" option (used for
> > >> build with symbols) and can be called "rte_debug"
> > > Yes, it looks to be the consensus.
> > >
> > >> 4) The currently existing DEBUG macros should not be replaced with a
> > >> RTE_DEBUG macro. This would allow to still enable them using
> > >> CFLAGS="-D..." to test a single module (library, driver).
> > >>
> > >> 5) Currently existing options' names should be standardized to
> > >> RTE_DEBUG_{library/driver name}, so they can be automatically enabled
> > >> when rte_debug is set. Standardized names would allow easy usage in
> > >> other modules.
> > > I don't understand difference between 4) et 5).
> > 
> > In current version of patches, I replaced all the DEBUG macros with 
> > RTE_DEBUG. It would be much better to keep fine-grained debugs as they 
> > are defined currently in dpdk. This is what I have on mind in 4)
> > 
> > However the currently used debug macros have different naming 
> > conventions: some use RTE_LIBRTE_{name}_DEBUG convention, other 
> > RTE_{name}_DEBUG, some just {name}_DEBUG.
> > So in 5) I follow Bruce's proposal to standardize them to one form 
> > RTE_DEBUG_{name}. However this will change the existing macros and 
> > someone might not like it, so I ask for the opinion about it.
> > 
> My thought is to standardize in the build and then leave it to module
> owners to either change their macros to use those standard ones as time
> goes on.

In order to maintain a good global user experience,
we need to drive such change with a roadmap and deadlines.

> > >> Should they? Or should we leave the current debug macros? Please share
> > >> your opinions as I see both cons and pros of this idea.
> > > I am not sure we need to keep fine-grain debug flags per libs/drivers.
> > > In case RTE_DEBUG is enabled, which kind of debug processing
> > > (except logs) do we want to be able to disable?
> > > Is it possible to decide based on a call to rte_log_can_log()?
> > I think it's rather opposite way round. Sometimes we would like to 
> > enable just some debug processing, e.g. when working on single lib or 
> > driver.
> > If we will use rte_debug - every debug  processing would be enabled, we 
> > won't disable anything, but without rte_debug we will still have the 
> > possibility of enabling debugs on a single module.
> > 
> > I believe it is possible to do it with rte_log_can_log, but changing 
> > build time enabled options into runtime enabled options might affect 
> > performance. It might make working on a single library or driver harder.
> > 
> 
> I think the idea is to use both. When RTE_DEBUG is enabled, then the
> rte_log_can_log() calls will be used to control the actual output. Without
> RTE_DEBUG, the whole block is skipped.
> 
> #ifdef RTE_DEBUG
> 	if rte_log_can_log(...) {
> 		/* do debug stuff */
> 	}
> #endif

This is what I had in mind.
The question is about performance impact in the case
we enable RTE_DEBUG at compilation time, and don't enable a
specific debug at runtime: is this check overhead acceptable?
	if rte_log_can_log(...)

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Bruce Richardson]

On Wed, Apr 22, 2020 at 01:02:42PM +0200, Thomas Monjalon wrote:
> 22/04/2020 12:55, Bruce Richardson:
> > On Wed, Apr 22, 2020 at 12:41:49PM +0200, Lukasz Wojciechowski wrote:
> > > W dniu 21.04.2020 o 23:38, Thomas Monjalon pisze:
> > > > 21/04/2020 22:58, Lukasz Wojciechowski:
> > > >> W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze:
> > > >>>>>>>>>>> I am agree with Cristian concern here: that patch removes ability to
> > > >>>>>>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
> > > >>>>>>>>>>> minimize number of config compile options, I wonder can't it be done
> > > >>>>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> > > >>>>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> > > >>>>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> > > >>>>>>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> > > >>>>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> defines that are used by multiple libs, probably can be set in upper
> > > >>>>>>>>>>> layer meson.build.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> That way will have global 'debug' flag, but users will still have an
> > > >>>>>>>>>>> ability to enable/disable debug flags on a per lib basis via
> > > >>>>>>>>>>> CFLAGS="-D..."
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Konstantin
> > > >>>>>>>>>>>
> > > >>>>>>>>>> That seems a reasonable idea to me.
> > > >>>>>>>>>>
> > > >>>>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
> > > >>>>>>>>>> either:
> > > >>>>>>>>>>
> > > >>>>>>>>>> * allow each component meson.build file define its own flags after
> > > >>>>>>>>>> checking get_option('debug') * have lib/meson.build and
> > > >>>>>>>>>> drivers/meson.build automatically define a specific define for each
> > > >>>>>>>>>> library or driver to standardize the naming.  [This would save anyone
> > > >>>>>>>>>> working on it from having to lookup what the define was, since it's
> > > >>>>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> > > >>>>>>>>>> RTE_DEBUG_SCHED etc]
> > > >>>>>>>>>>
> > > >>>>>>>>>> Theoretically we can also do both, have the standard ones defined and
> > > >>>>>>>>>> then allow a component to provide extra flags itself if so desired.
> > > >>>>>>>>>>
> > > >>>>>>>>>> /Bruce
> > > >>>>>>>>> OK, so let's summarize how the patches should be redo: * usage of global
> > > >>>>>>>>> "debug" flag for meson build stays * we standardize names of debug flags
> > > >>>>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
> > > >>>>>>>>> the RTE_DEBUG_... flags
> > > >>>>>>>>>
> > > >>>>>>>>> This allow to easily use both: * the debug flag - to enable all debugs *
> > > >>>>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single
> > > >>>>>>>>> component
> > > >>>>>>>>>
> > > >>>>>>>>> I like Bruce's idea of adding it to the lib/meson.build and
> > > >>>>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
> > > >>>>>>>>> object and written then later to rte_build_config.h before compilation
> > > >>>>>>>>> stage.  All the other modules will be able to use these flags.
> > > >>>>>>>>>
> > > >>>>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
> > > >>>>>>>> others are ok with this before you spend too much effort implementing it.
> > > >>>>>>>>
> > > >>>>>>>> For the drivers, the flag probably needs to include the category as well as
> > > >>>>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> > > >>>>>>>> name confusion. Those flags can then be checked inside individual
> > > >>>>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> > > >>>>>>>> you could theoretically do:
> > > >>>>>>>>
> > > >>>>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> > > >>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> > > >>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> > > >>>>>>>> 	...
> > > >>>>>>>> endif
> > > >>>>>>>>
> > > >>>>>>>> to enable more fine-grained control if so desired, and to maintain
> > > >>>>>>>> compatibility with existing defines, again if so desired.
> > > >>>>>>> Nak the nak from Cristian.
> > > >>>>>>>
> > > >>>>>>> We don't need all these flags.
> > > >>>>>>> If the user choose to compile DPDK for debug, every debug facilities
> > > >>>>>>> should be enabled. Then at runtime it is possible to enable/disable
> > > >>>>>>> the interesting logs.
> > > >>>>>>> If you need to disable something which is not a log,
> > > >>>>>>> you can align with the log level thanks to the function rte_log_can_log.
> > > >>> For many libs these flags mean much more than just logging.
> > > >>> Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
> > > >>> drivers - extra validation performed.
> > > >>> RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
> > > >>> rte_mbuf_sanity_check() instead of just NOP.
> > > >>> Which means performance would be greatly affected.
> > > >>> RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
> > > >>> and enforce extra checking, stats collection.
> > > >>> etc.
> > > >>> Probably that's ok for some cases to enable all that extra validation we have at once.
> > > >>> But I suppose in many cases people just interested to enable debug on one
> > > >>> (ok might be two/three) particular libraries, not the whole system.
> > > >>> Right now there is such ability, we are going to remove it without
> > > >>> providing adequate replacement.
> > > >>> Approach with rte_log_can_log() seems workable,
> > > >>> but right now these patches don't implement it.
> > > >>> Konstantin
> > > >>>
> > > >>>>>>> Please let's stop complicating things for the contributors and the users.
> > > >>>>>>> Note: I am strong on this position.
> > > >>>>>>>
> > > >>>>>> Note, this means that you need to ensure all debug printouts from libs and
> > > >>>>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think
> > > >>>>>> that may be some distance from reality right now.
> > > >>>>> Perfect! Let's expose those nasty logs which are not (yet) controllable.
> > > >>>>> And next step is to block any patch in those drivers or libs,
> > > >>>>> until it is fixed. Dynamic logging should have been complete for long.
> > > >>>>>
> > > >>>> I can live with that, I suppose. Do we have any idea of the magnitude of
> > > >>>> the work required here?
> > > >>>>
> > > >>>>>> Even if we do want all debug enabled from one flag, I'm still not 100%
> > > >>>>>> convinced that the existing debug flag is the way to do, since it only adds
> > > >>>>>> debug info to binary without affecting code generation.
> > > >>>>> OK, we want to keep this flag for gdb symbols only?
> > > >>>>> And add a new flag for debugging facilities which hurt the runtime performance?
> > > >>>>>
> > > >>>> I think that would be wise, yes. We can call the option "rte_debug" or
> > > >>>> something instead.
> > > >>>>
> > > >>>> /Bruce
> > > >> OK, lets's summarize current opinions and requirements to make a
> > > >> proposal for version2 of these patches, that I can implement if all agree:
> > > >>
> > > >> 1) The global debug flag is required to enable all the sanity checks and
> > > >> validations that are normally not used due to performance reasons
> > > > Yes
> > > >
> > > >> 2) The best option would be to have a single flag - not to introduce too
> > > >> many build options
> > > > Yes
> > > >
> > > >> 3) This option should be separated from meson "debug" option (used for
> > > >> build with symbols) and can be called "rte_debug"
> > > > Yes, it looks to be the consensus.
> > > >
> > > >> 4) The currently existing DEBUG macros should not be replaced with a
> > > >> RTE_DEBUG macro. This would allow to still enable them using
> > > >> CFLAGS="-D..." to test a single module (library, driver).
> > > >>
> > > >> 5) Currently existing options' names should be standardized to
> > > >> RTE_DEBUG_{library/driver name}, so they can be automatically enabled
> > > >> when rte_debug is set. Standardized names would allow easy usage in
> > > >> other modules.
> > > > I don't understand difference between 4) et 5).
> > > 
> > > In current version of patches, I replaced all the DEBUG macros with 
> > > RTE_DEBUG. It would be much better to keep fine-grained debugs as they 
> > > are defined currently in dpdk. This is what I have on mind in 4)
> > > 
> > > However the currently used debug macros have different naming 
> > > conventions: some use RTE_LIBRTE_{name}_DEBUG convention, other 
> > > RTE_{name}_DEBUG, some just {name}_DEBUG.
> > > So in 5) I follow Bruce's proposal to standardize them to one form 
> > > RTE_DEBUG_{name}. However this will change the existing macros and 
> > > someone might not like it, so I ask for the opinion about it.
> > > 
> > My thought is to standardize in the build and then leave it to module
> > owners to either change their macros to use those standard ones as time
> > goes on.
> 
> In order to maintain a good global user experience,
> we need to drive such change with a roadmap and deadlines.
> 
> > > >> Should they? Or should we leave the current debug macros? Please share
> > > >> your opinions as I see both cons and pros of this idea.
> > > > I am not sure we need to keep fine-grain debug flags per libs/drivers.
> > > > In case RTE_DEBUG is enabled, which kind of debug processing
> > > > (except logs) do we want to be able to disable?
> > > > Is it possible to decide based on a call to rte_log_can_log()?
> > > I think it's rather opposite way round. Sometimes we would like to 
> > > enable just some debug processing, e.g. when working on single lib or 
> > > driver.
> > > If we will use rte_debug - every debug  processing would be enabled, we 
> > > won't disable anything, but without rte_debug we will still have the 
> > > possibility of enabling debugs on a single module.
> > > 
> > > I believe it is possible to do it with rte_log_can_log, but changing 
> > > build time enabled options into runtime enabled options might affect 
> > > performance. It might make working on a single library or driver harder.
> > > 
> > 
> > I think the idea is to use both. When RTE_DEBUG is enabled, then the
> > rte_log_can_log() calls will be used to control the actual output. Without
> > RTE_DEBUG, the whole block is skipped.
> > 
> > #ifdef RTE_DEBUG
> > 	if rte_log_can_log(...) {
> > 		/* do debug stuff */
> > 	}
> > #endif
> 
> This is what I had in mind.
> The question is about performance impact in the case
> we enable RTE_DEBUG at compilation time, and don't enable a
> specific debug at runtime: is this check overhead acceptable?
> 	if rte_log_can_log(...)
> 
I believe it should be fine since:
* at runtime the branch will be predictable, since we don't go changing the
  logging level each time through the code path.
* there is the ability to disable at build time, and it will be off by
  default anyway, so only developers will use it.
* for non-developer investigation at runtime, the tracing library is the
  preferred option.

/Bruce

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Ananyev, Konstantin]

> 
> 22/04/2020 12:55, Bruce Richardson:
> > On Wed, Apr 22, 2020 at 12:41:49PM +0200, Lukasz Wojciechowski wrote:
> > > W dniu 21.04.2020 o 23:38, Thomas Monjalon pisze:
> > > > 21/04/2020 22:58, Lukasz Wojciechowski:
> > > >> W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze:
> > > >>>>>>>>>>> I am agree with Cristian concern here: that patch removes ability to
> > > >>>>>>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
> > > >>>>>>>>>>> minimize number of config compile options, I wonder can't it be done
> > > >>>>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> > > >>>>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> > > >>>>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> > > >>>>>>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> > > >>>>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> defines that are used by multiple libs, probably can be set in upper
> > > >>>>>>>>>>> layer meson.build.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> That way will have global 'debug' flag, but users will still have an
> > > >>>>>>>>>>> ability to enable/disable debug flags on a per lib basis via
> > > >>>>>>>>>>> CFLAGS="-D..."
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Konstantin
> > > >>>>>>>>>>>
> > > >>>>>>>>>> That seems a reasonable idea to me.
> > > >>>>>>>>>>
> > > >>>>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
> > > >>>>>>>>>> either:
> > > >>>>>>>>>>
> > > >>>>>>>>>> * allow each component meson.build file define its own flags after
> > > >>>>>>>>>> checking get_option('debug') * have lib/meson.build and
> > > >>>>>>>>>> drivers/meson.build automatically define a specific define for each
> > > >>>>>>>>>> library or driver to standardize the naming.  [This would save anyone
> > > >>>>>>>>>> working on it from having to lookup what the define was, since it's
> > > >>>>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> > > >>>>>>>>>> RTE_DEBUG_SCHED etc]
> > > >>>>>>>>>>
> > > >>>>>>>>>> Theoretically we can also do both, have the standard ones defined and
> > > >>>>>>>>>> then allow a component to provide extra flags itself if so desired.
> > > >>>>>>>>>>
> > > >>>>>>>>>> /Bruce
> > > >>>>>>>>> OK, so let's summarize how the patches should be redo: * usage of global
> > > >>>>>>>>> "debug" flag for meson build stays * we standardize names of debug flags
> > > >>>>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
> > > >>>>>>>>> the RTE_DEBUG_... flags
> > > >>>>>>>>>
> > > >>>>>>>>> This allow to easily use both: * the debug flag - to enable all debugs *
> > > >>>>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single
> > > >>>>>>>>> component
> > > >>>>>>>>>
> > > >>>>>>>>> I like Bruce's idea of adding it to the lib/meson.build and
> > > >>>>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
> > > >>>>>>>>> object and written then later to rte_build_config.h before compilation
> > > >>>>>>>>> stage.  All the other modules will be able to use these flags.
> > > >>>>>>>>>
> > > >>>>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
> > > >>>>>>>> others are ok with this before you spend too much effort implementing it.
> > > >>>>>>>>
> > > >>>>>>>> For the drivers, the flag probably needs to include the category as well as
> > > >>>>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> > > >>>>>>>> name confusion. Those flags can then be checked inside individual
> > > >>>>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> > > >>>>>>>> you could theoretically do:
> > > >>>>>>>>
> > > >>>>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> > > >>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> > > >>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> > > >>>>>>>> 	...
> > > >>>>>>>> endif
> > > >>>>>>>>
> > > >>>>>>>> to enable more fine-grained control if so desired, and to maintain
> > > >>>>>>>> compatibility with existing defines, again if so desired.
> > > >>>>>>> Nak the nak from Cristian.
> > > >>>>>>>
> > > >>>>>>> We don't need all these flags.
> > > >>>>>>> If the user choose to compile DPDK for debug, every debug facilities
> > > >>>>>>> should be enabled. Then at runtime it is possible to enable/disable
> > > >>>>>>> the interesting logs.
> > > >>>>>>> If you need to disable something which is not a log,
> > > >>>>>>> you can align with the log level thanks to the function rte_log_can_log.
> > > >>> For many libs these flags mean much more than just logging.
> > > >>> Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
> > > >>> drivers - extra validation performed.
> > > >>> RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
> > > >>> rte_mbuf_sanity_check() instead of just NOP.
> > > >>> Which means performance would be greatly affected.
> > > >>> RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
> > > >>> and enforce extra checking, stats collection.
> > > >>> etc.
> > > >>> Probably that's ok for some cases to enable all that extra validation we have at once.
> > > >>> But I suppose in many cases people just interested to enable debug on one
> > > >>> (ok might be two/three) particular libraries, not the whole system.
> > > >>> Right now there is such ability, we are going to remove it without
> > > >>> providing adequate replacement.
> > > >>> Approach with rte_log_can_log() seems workable,
> > > >>> but right now these patches don't implement it.
> > > >>> Konstantin
> > > >>>
> > > >>>>>>> Please let's stop complicating things for the contributors and the users.
> > > >>>>>>> Note: I am strong on this position.
> > > >>>>>>>
> > > >>>>>> Note, this means that you need to ensure all debug printouts from libs and
> > > >>>>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think
> > > >>>>>> that may be some distance from reality right now.
> > > >>>>> Perfect! Let's expose those nasty logs which are not (yet) controllable.
> > > >>>>> And next step is to block any patch in those drivers or libs,
> > > >>>>> until it is fixed. Dynamic logging should have been complete for long.
> > > >>>>>
> > > >>>> I can live with that, I suppose. Do we have any idea of the magnitude of
> > > >>>> the work required here?
> > > >>>>
> > > >>>>>> Even if we do want all debug enabled from one flag, I'm still not 100%
> > > >>>>>> convinced that the existing debug flag is the way to do, since it only adds
> > > >>>>>> debug info to binary without affecting code generation.
> > > >>>>> OK, we want to keep this flag for gdb symbols only?
> > > >>>>> And add a new flag for debugging facilities which hurt the runtime performance?
> > > >>>>>
> > > >>>> I think that would be wise, yes. We can call the option "rte_debug" or
> > > >>>> something instead.
> > > >>>>
> > > >>>> /Bruce
> > > >> OK, lets's summarize current opinions and requirements to make a
> > > >> proposal for version2 of these patches, that I can implement if all agree:
> > > >>
> > > >> 1) The global debug flag is required to enable all the sanity checks and
> > > >> validations that are normally not used due to performance reasons
> > > > Yes
> > > >
> > > >> 2) The best option would be to have a single flag - not to introduce too
> > > >> many build options
> > > > Yes
> > > >
> > > >> 3) This option should be separated from meson "debug" option (used for
> > > >> build with symbols) and can be called "rte_debug"
> > > > Yes, it looks to be the consensus.
> > > >
> > > >> 4) The currently existing DEBUG macros should not be replaced with a
> > > >> RTE_DEBUG macro. This would allow to still enable them using
> > > >> CFLAGS="-D..." to test a single module (library, driver).
> > > >>
> > > >> 5) Currently existing options' names should be standardized to
> > > >> RTE_DEBUG_{library/driver name}, so they can be automatically enabled
> > > >> when rte_debug is set. Standardized names would allow easy usage in
> > > >> other modules.
> > > > I don't understand difference between 4) et 5).
> > >
> > > In current version of patches, I replaced all the DEBUG macros with
> > > RTE_DEBUG. It would be much better to keep fine-grained debugs as they
> > > are defined currently in dpdk. This is what I have on mind in 4)
> > >
> > > However the currently used debug macros have different naming
> > > conventions: some use RTE_LIBRTE_{name}_DEBUG convention, other
> > > RTE_{name}_DEBUG, some just {name}_DEBUG.
> > > So in 5) I follow Bruce's proposal to standardize them to one form
> > > RTE_DEBUG_{name}. However this will change the existing macros and
> > > someone might not like it, so I ask for the opinion about it.
> > >
> > My thought is to standardize in the build and then leave it to module
> > owners to either change their macros to use those standard ones as time
> > goes on.
> 
> In order to maintain a good global user experience,
> we need to drive such change with a roadmap and deadlines.
> 
> > > >> Should they? Or should we leave the current debug macros? Please share
> > > >> your opinions as I see both cons and pros of this idea.
> > > > I am not sure we need to keep fine-grain debug flags per libs/drivers.
> > > > In case RTE_DEBUG is enabled, which kind of debug processing
> > > > (except logs) do we want to be able to disable?
> > > > Is it possible to decide based on a call to rte_log_can_log()?
> > > I think it's rather opposite way round. Sometimes we would like to
> > > enable just some debug processing, e.g. when working on single lib or
> > > driver.
> > > If we will use rte_debug - every debug  processing would be enabled, we
> > > won't disable anything, but without rte_debug we will still have the
> > > possibility of enabling debugs on a single module.
> > >
> > > I believe it is possible to do it with rte_log_can_log, but changing
> > > build time enabled options into runtime enabled options might affect
> > > performance. It might make working on a single library or driver harder.
> > >
> >
> > I think the idea is to use both. When RTE_DEBUG is enabled, then the
> > rte_log_can_log() calls will be used to control the actual output. Without
> > RTE_DEBUG, the whole block is skipped.
> >
> > #ifdef RTE_DEBUG
> > 	if rte_log_can_log(...) {
> > 		/* do debug stuff */
> > 	}
> > #endif
> 
> This is what I had in mind.
> The question is about performance impact in the case
> we enable RTE_DEBUG at compilation time, and don't enable a
> specific debug at runtime: is this check overhead acceptable?
> 	if rte_log_can_log(...)

We probably wouldn't know the answer  before trying.
Probably best way to make such changes for rte_mbuf and see how
big the drop will be. 
I suppose mbuf will be the one mostly affected, 
as we'll call rte_log_can_log() for nearly every mbuf op (free/detach/attach/reset, etc.)
 

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Lukasz Wojciechowski]

W dniu 22.04.2020 o 13:02, Thomas Monjalon pisze:
> 22/04/2020 12:55, Bruce Richardson:
>> On Wed, Apr 22, 2020 at 12:41:49PM +0200, Lukasz Wojciechowski wrote:
>>> W dniu 21.04.2020 o 23:38, Thomas Monjalon pisze:
>>>> 21/04/2020 22:58, Lukasz Wojciechowski:
>>>>> W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze:
>>>>>>>>>>>>>> I am agree with Cristian concern here: that patch removes ability to
>>>>>>>>>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
>>>>>>>>>>>>>> minimize number of config compile options, I wonder can't it be done
>>>>>>>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
>>>>>>>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
>>>>>>>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
>>>>>>>>>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
>>>>>>>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> defines that are used by multiple libs, probably can be set in upper
>>>>>>>>>>>>>> layer meson.build.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That way will have global 'debug' flag, but users will still have an
>>>>>>>>>>>>>> ability to enable/disable debug flags on a per lib basis via
>>>>>>>>>>>>>> CFLAGS="-D..."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>
>>>>>>>>>>>>> That seems a reasonable idea to me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
>>>>>>>>>>>>> either:
>>>>>>>>>>>>>
>>>>>>>>>>>>> * allow each component meson.build file define its own flags after
>>>>>>>>>>>>> checking get_option('debug') * have lib/meson.build and
>>>>>>>>>>>>> drivers/meson.build automatically define a specific define for each
>>>>>>>>>>>>> library or driver to standardize the naming.  [This would save anyone
>>>>>>>>>>>>> working on it from having to lookup what the define was, since it's
>>>>>>>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
>>>>>>>>>>>>> RTE_DEBUG_SCHED etc]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Theoretically we can also do both, have the standard ones defined and
>>>>>>>>>>>>> then allow a component to provide extra flags itself if so desired.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Bruce
>>>>>>>>>>>> OK, so let's summarize how the patches should be redo: * usage of global
>>>>>>>>>>>> "debug" flag for meson build stays * we standardize names of debug flags
>>>>>>>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
>>>>>>>>>>>> the RTE_DEBUG_... flags
>>>>>>>>>>>>
>>>>>>>>>>>> This allow to easily use both: * the debug flag - to enable all debugs *
>>>>>>>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single
>>>>>>>>>>>> component
>>>>>>>>>>>>
>>>>>>>>>>>> I like Bruce's idea of adding it to the lib/meson.build and
>>>>>>>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
>>>>>>>>>>>> object and written then later to rte_build_config.h before compilation
>>>>>>>>>>>> stage.  All the other modules will be able to use these flags.
>>>>>>>>>>>>
>>>>>>>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
>>>>>>>>>>> others are ok with this before you spend too much effort implementing it.
>>>>>>>>>>>
>>>>>>>>>>> For the drivers, the flag probably needs to include the category as well as
>>>>>>>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
>>>>>>>>>>> name confusion. Those flags can then be checked inside individual
>>>>>>>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
>>>>>>>>>>> you could theoretically do:
>>>>>>>>>>>
>>>>>>>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
>>>>>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
>>>>>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
>>>>>>>>>>> 	...
>>>>>>>>>>> endif
>>>>>>>>>>>
>>>>>>>>>>> to enable more fine-grained control if so desired, and to maintain
>>>>>>>>>>> compatibility with existing defines, again if so desired.
>>>>>>>>>> Nak the nak from Cristian.
>>>>>>>>>>
>>>>>>>>>> We don't need all these flags.
>>>>>>>>>> If the user choose to compile DPDK for debug, every debug facilities
>>>>>>>>>> should be enabled. Then at runtime it is possible to enable/disable
>>>>>>>>>> the interesting logs.
>>>>>>>>>> If you need to disable something which is not a log,
>>>>>>>>>> you can align with the log level thanks to the function rte_log_can_log.
>>>>>> For many libs these flags mean much more than just logging.
>>>>>> Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
>>>>>> drivers - extra validation performed.
>>>>>> RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
>>>>>> rte_mbuf_sanity_check() instead of just NOP.
>>>>>> Which means performance would be greatly affected.
>>>>>> RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
>>>>>> and enforce extra checking, stats collection.
>>>>>> etc.
>>>>>> Probably that's ok for some cases to enable all that extra validation we have at once.
>>>>>> But I suppose in many cases people just interested to enable debug on one
>>>>>> (ok might be two/three) particular libraries, not the whole system.
>>>>>> Right now there is such ability, we are going to remove it without
>>>>>> providing adequate replacement.
>>>>>> Approach with rte_log_can_log() seems workable,
>>>>>> but right now these patches don't implement it.
>>>>>> Konstantin
>>>>>>
>>>>>>>>>> Please let's stop complicating things for the contributors and the users.
>>>>>>>>>> Note: I am strong on this position.
>>>>>>>>>>
>>>>>>>>> Note, this means that you need to ensure all debug printouts from libs and
>>>>>>>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think
>>>>>>>>> that may be some distance from reality right now.
>>>>>>>> Perfect! Let's expose those nasty logs which are not (yet) controllable.
>>>>>>>> And next step is to block any patch in those drivers or libs,
>>>>>>>> until it is fixed. Dynamic logging should have been complete for long.
>>>>>>>>
>>>>>>> I can live with that, I suppose. Do we have any idea of the magnitude of
>>>>>>> the work required here?
>>>>>>>
>>>>>>>>> Even if we do want all debug enabled from one flag, I'm still not 100%
>>>>>>>>> convinced that the existing debug flag is the way to do, since it only adds
>>>>>>>>> debug info to binary without affecting code generation.
>>>>>>>> OK, we want to keep this flag for gdb symbols only?
>>>>>>>> And add a new flag for debugging facilities which hurt the runtime performance?
>>>>>>>>
>>>>>>> I think that would be wise, yes. We can call the option "rte_debug" or
>>>>>>> something instead.
>>>>>>>
>>>>>>> /Bruce
>>>>> OK, lets's summarize current opinions and requirements to make a
>>>>> proposal for version2 of these patches, that I can implement if all agree:
>>>>>
>>>>> 1) The global debug flag is required to enable all the sanity checks and
>>>>> validations that are normally not used due to performance reasons
>>>> Yes
>>>>
>>>>> 2) The best option would be to have a single flag - not to introduce too
>>>>> many build options
>>>> Yes
>>>>
>>>>> 3) This option should be separated from meson "debug" option (used for
>>>>> build with symbols) and can be called "rte_debug"
>>>> Yes, it looks to be the consensus.
>>>>
>>>>> 4) The currently existing DEBUG macros should not be replaced with a
>>>>> RTE_DEBUG macro. This would allow to still enable them using
>>>>> CFLAGS="-D..." to test a single module (library, driver).
>>>>>
>>>>> 5) Currently existing options' names should be standardized to
>>>>> RTE_DEBUG_{library/driver name}, so they can be automatically enabled
>>>>> when rte_debug is set. Standardized names would allow easy usage in
>>>>> other modules.
>>>> I don't understand difference between 4) et 5).
>>> In current version of patches, I replaced all the DEBUG macros with
>>> RTE_DEBUG. It would be much better to keep fine-grained debugs as they
>>> are defined currently in dpdk. This is what I have on mind in 4)
>>>
>>> However the currently used debug macros have different naming
>>> conventions: some use RTE_LIBRTE_{name}_DEBUG convention, other
>>> RTE_{name}_DEBUG, some just {name}_DEBUG.
>>> So in 5) I follow Bruce's proposal to standardize them to one form
>>> RTE_DEBUG_{name}. However this will change the existing macros and
>>> someone might not like it, so I ask for the opinion about it.
>>>
>> My thought is to standardize in the build and then leave it to module
>> owners to either change their macros to use those standard ones as time
>> goes on.
> In order to maintain a good global user experience,
> we need to drive such change with a roadmap and deadlines.
What is the process of documenting new wanted feature and adding it the 
roadmap?
>
>>>>> Should they? Or should we leave the current debug macros? Please share
>>>>> your opinions as I see both cons and pros of this idea.
>>>> I am not sure we need to keep fine-grain debug flags per libs/drivers.
>>>> In case RTE_DEBUG is enabled, which kind of debug processing
>>>> (except logs) do we want to be able to disable?
>>>> Is it possible to decide based on a call to rte_log_can_log()?
>>> I think it's rather opposite way round. Sometimes we would like to
>>> enable just some debug processing, e.g. when working on single lib or
>>> driver.
>>> If we will use rte_debug - every debug  processing would be enabled, we
>>> won't disable anything, but without rte_debug we will still have the
>>> possibility of enabling debugs on a single module.
>>>
>>> I believe it is possible to do it with rte_log_can_log, but changing
>>> build time enabled options into runtime enabled options might affect
>>> performance. It might make working on a single library or driver harder.
>>>
>> I think the idea is to use both. When RTE_DEBUG is enabled, then the
>> rte_log_can_log() calls will be used to control the actual output. Without
>> RTE_DEBUG, the whole block is skipped.
>>
>> #ifdef RTE_DEBUG
>> 	if rte_log_can_log(...) {
>> 		/* do debug stuff */
>> 	}
>> #endif
I thought that we are closer to agree to remain old macros, like:

#ifdef RET_DEBUG_SOMELIBRARY
         if rte_log_can_log(...) {

with enabling RET_DEBUG_SOMELIBRARY in general library meson.build when 
rte_debug option is set.

> This is what I had in mind.
> The question is about performance impact in the case
> we enable RTE_DEBUG at compilation time, and don't enable a
> specific debug at runtime: is this check overhead acceptable?
> 	if rte_log_can_log(...)
I guess that with rte_debug enabled you must accept drop of performance, 
but let libraries and drivers maintainers share their opinion.
>
>
>
-- 

Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Thomas Monjalon]

22/04/2020 13:29, Ananyev, Konstantin:
> > 22/04/2020 12:55, Bruce Richardson:
> > > On Wed, Apr 22, 2020 at 12:41:49PM +0200, Lukasz Wojciechowski wrote:
> > > > W dniu 21.04.2020 o 23:38, Thomas Monjalon pisze:
> > > > > 21/04/2020 22:58, Lukasz Wojciechowski:
> > > > >> W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze:
> > > > >>>>>>>>>>> I am agree with Cristian concern here: that patch removes ability to
> > > > >>>>>>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
> > > > >>>>>>>>>>> minimize number of config compile options, I wonder can't it be done
> > > > >>>>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> > > > >>>>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> > > > >>>>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> > > > >>>>>>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> > > > >>>>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> defines that are used by multiple libs, probably can be set in upper
> > > > >>>>>>>>>>> layer meson.build.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> That way will have global 'debug' flag, but users will still have an
> > > > >>>>>>>>>>> ability to enable/disable debug flags on a per lib basis via
> > > > >>>>>>>>>>> CFLAGS="-D..."
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Konstantin
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> That seems a reasonable idea to me.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
> > > > >>>>>>>>>> either:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> * allow each component meson.build file define its own flags after
> > > > >>>>>>>>>> checking get_option('debug') * have lib/meson.build and
> > > > >>>>>>>>>> drivers/meson.build automatically define a specific define for each
> > > > >>>>>>>>>> library or driver to standardize the naming.  [This would save anyone
> > > > >>>>>>>>>> working on it from having to lookup what the define was, since it's
> > > > >>>>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> > > > >>>>>>>>>> RTE_DEBUG_SCHED etc]
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Theoretically we can also do both, have the standard ones defined and
> > > > >>>>>>>>>> then allow a component to provide extra flags itself if so desired.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> /Bruce
> > > > >>>>>>>>> OK, so let's summarize how the patches should be redo: * usage of global
> > > > >>>>>>>>> "debug" flag for meson build stays * we standardize names of debug flags
> > > > >>>>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
> > > > >>>>>>>>> the RTE_DEBUG_... flags
> > > > >>>>>>>>>
> > > > >>>>>>>>> This allow to easily use both: * the debug flag - to enable all debugs *
> > > > >>>>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single
> > > > >>>>>>>>> component
> > > > >>>>>>>>>
> > > > >>>>>>>>> I like Bruce's idea of adding it to the lib/meson.build and
> > > > >>>>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
> > > > >>>>>>>>> object and written then later to rte_build_config.h before compilation
> > > > >>>>>>>>> stage.  All the other modules will be able to use these flags.
> > > > >>>>>>>>>
> > > > >>>>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
> > > > >>>>>>>> others are ok with this before you spend too much effort implementing it.
> > > > >>>>>>>>
> > > > >>>>>>>> For the drivers, the flag probably needs to include the category as well as
> > > > >>>>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> > > > >>>>>>>> name confusion. Those flags can then be checked inside individual
> > > > >>>>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> > > > >>>>>>>> you could theoretically do:
> > > > >>>>>>>>
> > > > >>>>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> > > > >>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> > > > >>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> > > > >>>>>>>> 	...
> > > > >>>>>>>> endif
> > > > >>>>>>>>
> > > > >>>>>>>> to enable more fine-grained control if so desired, and to maintain
> > > > >>>>>>>> compatibility with existing defines, again if so desired.
> > > > >>>>>>> Nak the nak from Cristian.
> > > > >>>>>>>
> > > > >>>>>>> We don't need all these flags.
> > > > >>>>>>> If the user choose to compile DPDK for debug, every debug facilities
> > > > >>>>>>> should be enabled. Then at runtime it is possible to enable/disable
> > > > >>>>>>> the interesting logs.
> > > > >>>>>>> If you need to disable something which is not a log,
> > > > >>>>>>> you can align with the log level thanks to the function rte_log_can_log.
> > > > >>> For many libs these flags mean much more than just logging.
> > > > >>> Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
> > > > >>> drivers - extra validation performed.
> > > > >>> RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
> > > > >>> rte_mbuf_sanity_check() instead of just NOP.
> > > > >>> Which means performance would be greatly affected.
> > > > >>> RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
> > > > >>> and enforce extra checking, stats collection.
> > > > >>> etc.
> > > > >>> Probably that's ok for some cases to enable all that extra validation we have at once.
> > > > >>> But I suppose in many cases people just interested to enable debug on one
> > > > >>> (ok might be two/three) particular libraries, not the whole system.
> > > > >>> Right now there is such ability, we are going to remove it without
> > > > >>> providing adequate replacement.
> > > > >>> Approach with rte_log_can_log() seems workable,
> > > > >>> but right now these patches don't implement it.
> > > > >>> Konstantin
> > > > >>>
> > > > >>>>>>> Please let's stop complicating things for the contributors and the users.
> > > > >>>>>>> Note: I am strong on this position.
> > > > >>>>>>>
> > > > >>>>>> Note, this means that you need to ensure all debug printouts from libs and
> > > > >>>>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think
> > > > >>>>>> that may be some distance from reality right now.
> > > > >>>>> Perfect! Let's expose those nasty logs which are not (yet) controllable.
> > > > >>>>> And next step is to block any patch in those drivers or libs,
> > > > >>>>> until it is fixed. Dynamic logging should have been complete for long.
> > > > >>>>>
> > > > >>>> I can live with that, I suppose. Do we have any idea of the magnitude of
> > > > >>>> the work required here?
> > > > >>>>
> > > > >>>>>> Even if we do want all debug enabled from one flag, I'm still not 100%
> > > > >>>>>> convinced that the existing debug flag is the way to do, since it only adds
> > > > >>>>>> debug info to binary without affecting code generation.
> > > > >>>>> OK, we want to keep this flag for gdb symbols only?
> > > > >>>>> And add a new flag for debugging facilities which hurt the runtime performance?
> > > > >>>>>
> > > > >>>> I think that would be wise, yes. We can call the option "rte_debug" or
> > > > >>>> something instead.
> > > > >>>>
> > > > >>>> /Bruce
> > > > >> OK, lets's summarize current opinions and requirements to make a
> > > > >> proposal for version2 of these patches, that I can implement if all agree:
> > > > >>
> > > > >> 1) The global debug flag is required to enable all the sanity checks and
> > > > >> validations that are normally not used due to performance reasons
> > > > > Yes
> > > > >
> > > > >> 2) The best option would be to have a single flag - not to introduce too
> > > > >> many build options
> > > > > Yes
> > > > >
> > > > >> 3) This option should be separated from meson "debug" option (used for
> > > > >> build with symbols) and can be called "rte_debug"
> > > > > Yes, it looks to be the consensus.
> > > > >
> > > > >> 4) The currently existing DEBUG macros should not be replaced with a
> > > > >> RTE_DEBUG macro. This would allow to still enable them using
> > > > >> CFLAGS="-D..." to test a single module (library, driver).
> > > > >>
> > > > >> 5) Currently existing options' names should be standardized to
> > > > >> RTE_DEBUG_{library/driver name}, so they can be automatically enabled
> > > > >> when rte_debug is set. Standardized names would allow easy usage in
> > > > >> other modules.
> > > > > I don't understand difference between 4) et 5).
> > > >
> > > > In current version of patches, I replaced all the DEBUG macros with
> > > > RTE_DEBUG. It would be much better to keep fine-grained debugs as they
> > > > are defined currently in dpdk. This is what I have on mind in 4)
> > > >
> > > > However the currently used debug macros have different naming
> > > > conventions: some use RTE_LIBRTE_{name}_DEBUG convention, other
> > > > RTE_{name}_DEBUG, some just {name}_DEBUG.
> > > > So in 5) I follow Bruce's proposal to standardize them to one form
> > > > RTE_DEBUG_{name}. However this will change the existing macros and
> > > > someone might not like it, so I ask for the opinion about it.
> > > >
> > > My thought is to standardize in the build and then leave it to module
> > > owners to either change their macros to use those standard ones as time
> > > goes on.
> > 
> > In order to maintain a good global user experience,
> > we need to drive such change with a roadmap and deadlines.
> > 
> > > > >> Should they? Or should we leave the current debug macros? Please share
> > > > >> your opinions as I see both cons and pros of this idea.
> > > > > I am not sure we need to keep fine-grain debug flags per libs/drivers.
> > > > > In case RTE_DEBUG is enabled, which kind of debug processing
> > > > > (except logs) do we want to be able to disable?
> > > > > Is it possible to decide based on a call to rte_log_can_log()?
> > > > I think it's rather opposite way round. Sometimes we would like to
> > > > enable just some debug processing, e.g. when working on single lib or
> > > > driver.
> > > > If we will use rte_debug - every debug  processing would be enabled, we
> > > > won't disable anything, but without rte_debug we will still have the
> > > > possibility of enabling debugs on a single module.
> > > >
> > > > I believe it is possible to do it with rte_log_can_log, but changing
> > > > build time enabled options into runtime enabled options might affect
> > > > performance. It might make working on a single library or driver harder.
> > > >
> > >
> > > I think the idea is to use both. When RTE_DEBUG is enabled, then the
> > > rte_log_can_log() calls will be used to control the actual output. Without
> > > RTE_DEBUG, the whole block is skipped.
> > >
> > > #ifdef RTE_DEBUG
> > > 	if rte_log_can_log(...) {
> > > 		/* do debug stuff */
> > > 	}
> > > #endif
> > 
> > This is what I had in mind.
> > The question is about performance impact in the case
> > we enable RTE_DEBUG at compilation time, and don't enable a
> > specific debug at runtime: is this check overhead acceptable?
> > 	if rte_log_can_log(...)
> 
> We probably wouldn't know the answer  before trying.
> Probably best way to make such changes for rte_mbuf and see how
> big the drop will be. 
> I suppose mbuf will be the one mostly affected, 
> as we'll call rte_log_can_log() for nearly every mbuf op (free/detach/attach/reset, etc.)

Yes I like the idea of trying with mbuf,
and see how much a compilation flag for global debugging
affects the mbuf performance.

Note that we should also manage RTE_ENABLE_ASSERT with the global meson option.

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Bruce Richardson]

On Wed, Apr 22, 2020 at 01:52:21PM +0200, Lukasz Wojciechowski wrote:
> 
> W dniu 22.04.2020 o 13:02, Thomas Monjalon pisze:
> > 22/04/2020 12:55, Bruce Richardson:
> >> On Wed, Apr 22, 2020 at 12:41:49PM +0200, Lukasz Wojciechowski wrote:
> >>> W dniu 21.04.2020 o 23:38, Thomas Monjalon pisze:
> >>>> 21/04/2020 22:58, Lukasz Wojciechowski:
> >>>>> W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze:
> >>>>>>>>>>>>>> I am agree with Cristian concern here: that patch removes ability to
> >>>>>>>>>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
> >>>>>>>>>>>>>> minimize number of config compile options, I wonder can't it be done
> >>>>>>>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
> >>>>>>>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
> >>>>>>>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
> >>>>>>>>>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
> >>>>>>>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> defines that are used by multiple libs, probably can be set in upper
> >>>>>>>>>>>>>> layer meson.build.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> That way will have global 'debug' flag, but users will still have an
> >>>>>>>>>>>>>> ability to enable/disable debug flags on a per lib basis via
> >>>>>>>>>>>>>> CFLAGS="-D..."
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Konstantin
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> That seems a reasonable idea to me.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
> >>>>>>>>>>>>> either:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> * allow each component meson.build file define its own flags after
> >>>>>>>>>>>>> checking get_option('debug') * have lib/meson.build and
> >>>>>>>>>>>>> drivers/meson.build automatically define a specific define for each
> >>>>>>>>>>>>> library or driver to standardize the naming.  [This would save anyone
> >>>>>>>>>>>>> working on it from having to lookup what the define was, since it's
> >>>>>>>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
> >>>>>>>>>>>>> RTE_DEBUG_SCHED etc]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Theoretically we can also do both, have the standard ones defined and
> >>>>>>>>>>>>> then allow a component to provide extra flags itself if so desired.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Bruce
> >>>>>>>>>>>> OK, so let's summarize how the patches should be redo: * usage of global
> >>>>>>>>>>>> "debug" flag for meson build stays * we standardize names of debug flags
> >>>>>>>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
> >>>>>>>>>>>> the RTE_DEBUG_... flags
> >>>>>>>>>>>>
> >>>>>>>>>>>> This allow to easily use both: * the debug flag - to enable all debugs *
> >>>>>>>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single
> >>>>>>>>>>>> component
> >>>>>>>>>>>>
> >>>>>>>>>>>> I like Bruce's idea of adding it to the lib/meson.build and
> >>>>>>>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
> >>>>>>>>>>>> object and written then later to rte_build_config.h before compilation
> >>>>>>>>>>>> stage.  All the other modules will be able to use these flags.
> >>>>>>>>>>>>
> >>>>>>>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
> >>>>>>>>>>> others are ok with this before you spend too much effort implementing it.
> >>>>>>>>>>>
> >>>>>>>>>>> For the drivers, the flag probably needs to include the category as well as
> >>>>>>>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
> >>>>>>>>>>> name confusion. Those flags can then be checked inside individual
> >>>>>>>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
> >>>>>>>>>>> you could theoretically do:
> >>>>>>>>>>>
> >>>>>>>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
> >>>>>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
> >>>>>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
> >>>>>>>>>>> 	...
> >>>>>>>>>>> endif
> >>>>>>>>>>>
> >>>>>>>>>>> to enable more fine-grained control if so desired, and to maintain
> >>>>>>>>>>> compatibility with existing defines, again if so desired.
> >>>>>>>>>> Nak the nak from Cristian.
> >>>>>>>>>>
> >>>>>>>>>> We don't need all these flags.
> >>>>>>>>>> If the user choose to compile DPDK for debug, every debug facilities
> >>>>>>>>>> should be enabled. Then at runtime it is possible to enable/disable
> >>>>>>>>>> the interesting logs.
> >>>>>>>>>> If you need to disable something which is not a log,
> >>>>>>>>>> you can align with the log level thanks to the function rte_log_can_log.
> >>>>>> For many libs these flags mean much more than just logging.
> >>>>>> Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
> >>>>>> drivers - extra validation performed.
> >>>>>> RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
> >>>>>> rte_mbuf_sanity_check() instead of just NOP.
> >>>>>> Which means performance would be greatly affected.
> >>>>>> RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
> >>>>>> and enforce extra checking, stats collection.
> >>>>>> etc.
> >>>>>> Probably that's ok for some cases to enable all that extra validation we have at once.
> >>>>>> But I suppose in many cases people just interested to enable debug on one
> >>>>>> (ok might be two/three) particular libraries, not the whole system.
> >>>>>> Right now there is such ability, we are going to remove it without
> >>>>>> providing adequate replacement.
> >>>>>> Approach with rte_log_can_log() seems workable,
> >>>>>> but right now these patches don't implement it.
> >>>>>> Konstantin
> >>>>>>
> >>>>>>>>>> Please let's stop complicating things for the contributors and the users.
> >>>>>>>>>> Note: I am strong on this position.
> >>>>>>>>>>
> >>>>>>>>> Note, this means that you need to ensure all debug printouts from libs and
> >>>>>>>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think
> >>>>>>>>> that may be some distance from reality right now.
> >>>>>>>> Perfect! Let's expose those nasty logs which are not (yet) controllable.
> >>>>>>>> And next step is to block any patch in those drivers or libs,
> >>>>>>>> until it is fixed. Dynamic logging should have been complete for long.
> >>>>>>>>
> >>>>>>> I can live with that, I suppose. Do we have any idea of the magnitude of
> >>>>>>> the work required here?
> >>>>>>>
> >>>>>>>>> Even if we do want all debug enabled from one flag, I'm still not 100%
> >>>>>>>>> convinced that the existing debug flag is the way to do, since it only adds
> >>>>>>>>> debug info to binary without affecting code generation.
> >>>>>>>> OK, we want to keep this flag for gdb symbols only?
> >>>>>>>> And add a new flag for debugging facilities which hurt the runtime performance?
> >>>>>>>>
> >>>>>>> I think that would be wise, yes. We can call the option "rte_debug" or
> >>>>>>> something instead.
> >>>>>>>
> >>>>>>> /Bruce
> >>>>> OK, lets's summarize current opinions and requirements to make a
> >>>>> proposal for version2 of these patches, that I can implement if all agree:
> >>>>>
> >>>>> 1) The global debug flag is required to enable all the sanity checks and
> >>>>> validations that are normally not used due to performance reasons
> >>>> Yes
> >>>>
> >>>>> 2) The best option would be to have a single flag - not to introduce too
> >>>>> many build options
> >>>> Yes
> >>>>
> >>>>> 3) This option should be separated from meson "debug" option (used for
> >>>>> build with symbols) and can be called "rte_debug"
> >>>> Yes, it looks to be the consensus.
> >>>>
> >>>>> 4) The currently existing DEBUG macros should not be replaced with a
> >>>>> RTE_DEBUG macro. This would allow to still enable them using
> >>>>> CFLAGS="-D..." to test a single module (library, driver).
> >>>>>
> >>>>> 5) Currently existing options' names should be standardized to
> >>>>> RTE_DEBUG_{library/driver name}, so they can be automatically enabled
> >>>>> when rte_debug is set. Standardized names would allow easy usage in
> >>>>> other modules.
> >>>> I don't understand difference between 4) et 5).
> >>> In current version of patches, I replaced all the DEBUG macros with
> >>> RTE_DEBUG. It would be much better to keep fine-grained debugs as they
> >>> are defined currently in dpdk. This is what I have on mind in 4)
> >>>
> >>> However the currently used debug macros have different naming
> >>> conventions: some use RTE_LIBRTE_{name}_DEBUG convention, other
> >>> RTE_{name}_DEBUG, some just {name}_DEBUG.
> >>> So in 5) I follow Bruce's proposal to standardize them to one form
> >>> RTE_DEBUG_{name}. However this will change the existing macros and
> >>> someone might not like it, so I ask for the opinion about it.
> >>>
> >> My thought is to standardize in the build and then leave it to module
> >> owners to either change their macros to use those standard ones as time
> >> goes on.
> > In order to maintain a good global user experience,
> > we need to drive such change with a roadmap and deadlines.
> What is the process of documenting new wanted feature and adding it the 
> roadmap?
> >
> >>>>> Should they? Or should we leave the current debug macros? Please share
> >>>>> your opinions as I see both cons and pros of this idea.
> >>>> I am not sure we need to keep fine-grain debug flags per libs/drivers.
> >>>> In case RTE_DEBUG is enabled, which kind of debug processing
> >>>> (except logs) do we want to be able to disable?
> >>>> Is it possible to decide based on a call to rte_log_can_log()?
> >>> I think it's rather opposite way round. Sometimes we would like to
> >>> enable just some debug processing, e.g. when working on single lib or
> >>> driver.
> >>> If we will use rte_debug - every debug  processing would be enabled, we
> >>> won't disable anything, but without rte_debug we will still have the
> >>> possibility of enabling debugs on a single module.
> >>>
> >>> I believe it is possible to do it with rte_log_can_log, but changing
> >>> build time enabled options into runtime enabled options might affect
> >>> performance. It might make working on a single library or driver harder.
> >>>
> >> I think the idea is to use both. When RTE_DEBUG is enabled, then the
> >> rte_log_can_log() calls will be used to control the actual output. Without
> >> RTE_DEBUG, the whole block is skipped.
> >>
> >> #ifdef RTE_DEBUG
> >> 	if rte_log_can_log(...) {
> >> 		/* do debug stuff */
> >> 	}
> >> #endif
> I thought that we are closer to agree to remain old macros, like:
> 
> #ifdef RET_DEBUG_SOMELIBRARY
>          if rte_log_can_log(...) {
> 
> with enabling RET_DEBUG_SOMELIBRARY in general library meson.build when 
> rte_debug option is set.
> 
Yes, looks better to me, since it does allow use of CFLAGS if you *really*
want to limit the debug to just one module.

[dpdk-dev] [PATCH v2 0/3] introduce global debug flag

[Lukasz Wojciechowski]

This set of patches introduces a global rte_debug flag for dpdk.
This will allow easy switch to debug build configuration using a single
flag. In the debug mode a RTE_DEBUG macro is defined to 1
and for every enabled to be built librarte a RTE_DEBUG_{library name}
is also defined. These macros can be used to place a debug code
inside #ifdef #endif clauses.

The following requirements were discussed on the mailing list:
1) The global debug flag is required to enable all the sanity checks
and validations that are normally not used due to performance reasons

2) The best option would be to have a single flag - not to introduce
too many build options

3) This option should be separated from meson "debug" option
(used for build with symbols) and can be called "rte_debug"

4) The currently existing DEBUG macros should not be replaced with
a RTE_DEBUG macro. This would allow to still enable them using
CFLAGS="-D..." to test a single module (library, driver).

5) Currently existing options' names should be standardized
to RTE_DEBUG_{library/driver name}, so they can be automatically enabled
when rte_debug is set. Standardized names would allow easy usage
in other modules.

6) The debug functionality should be encapsulated in:
        if (rte_log_can_log(...)) {
                ...
        }
for possibility to be filtered out in runtime.


Because of the hot discussion of v1 version of patches, I limit
the v2 version to mbuf library changes only, to see how it will impact
the performance with rte_log_can_log usage and to get opinions.

Next steps would be to follow changes in other libraries and drivers.

---
v2:
* Use new meson option rte_debug instead of debug
* Add standardized defines for built libraries
* Limit patches to mbuf library (as a POC)
* Use rte_log_can_log to wrap debug section

Lukasz Wojciechowski (3):
  config: introduce global rte debug flag
  config: remove unused config flags
  mbuf: standardize library debug flag

 app/test/test_mbuf.c               |  3 ++-
 config/common_base                 |  5 -----
 config/meson.build                 |  4 ++++
 doc/guides/prog_guide/mbuf_lib.rst |  2 +-
 lib/librte_mbuf/rte_mbuf.h         | 12 ++++++++----
 lib/meson.build                    |  4 ++++
 meson_options.txt                  |  2 ++
 7 files changed, 21 insertions(+), 11 deletions(-)

-- 
2.17.1

[dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag

[Lukasz Wojciechowski]

A new boolean meson build flag is introduced with this patch: rte_debug.
To enable this option add -Drte_debug=true to the meson configure command.

By enabling this flag the globaly defined macro RTE_DEBUG becomes
defined. It should be used for enabling debug code in all dpdk project
components. Using this flag allows to make additional checks or tests
and provide additional logs even in performance sensitive parts of code.

The flag is disabled by default.

Additionally for all enabled to be built libraries
a RTE_DEBUG_{library name} is defined and assigned a value 1.
This standardize names of library specific debug macros. Those can
be used also without rte_debug option by using CFLAGS="-D..." build
parameter.

Code put inside RTE_DEBUG* #ifdef sections should be also put inside
if (rte_log_can_log(...)) condition to allow run-time filtering of
sanity checks, validations, logs and dumps when using rte_debug option.

Libraries will be adjusted to the change in separate patches.

Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/meson.build | 4 ++++
 lib/meson.build    | 4 ++++
 meson_options.txt  | 2 ++
 3 files changed, 10 insertions(+)

diff --git a/config/meson.build b/config/meson.build
index 224d29e1c..5ab510009 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -183,6 +183,10 @@ endif
 # add -include rte_config to cflags
 add_project_arguments('-include', 'rte_config.h', language: 'c')
 
+if get_option('rte_debug')
+	dpdk_conf.set('RTE_DEBUG', 1)
+endif
+
 # enable extra warnings and disable any unwanted warnings
 warning_flags = [
 	# -Wall is added by meson by default, so add -Wextra only
diff --git a/lib/meson.build b/lib/meson.build
index 63c17ee75..8e0abca1e 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -88,6 +88,10 @@ foreach l:libraries
 		dpdk_conf.set('RTE_LIBRTE_' + name.to_upper(), 1)
 		install_headers(headers)
 
+		if get_option('rte_debug')
+			dpdk_conf.set('RTE_DEBUG_' + name.to_upper(), 1)
+		endif
+
 		libname = 'rte_' + name
 		includes += include_directories(dir_name)
 
diff --git a/meson_options.txt b/meson_options.txt
index 9e4923a4f..a14f0efdb 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -30,6 +30,8 @@ option('max_lcores', type: 'integer', value: 128,
 	description: 'maximum number of cores/threads supported by EAL')
 option('max_numa_nodes', type: 'integer', value: 4,
 	description: 'maximum number of NUMA nodes supported by EAL')
+option('rte_debug', type: 'boolean', value: false,
+	description: 'build with additional sanity checks, validations and logs')
 option('tests', type: 'boolean', value: true,
 	description: 'build unit tests')
 option('use_hpet', type: 'boolean', value: false,
-- 
2.17.1

[dpdk-dev] [PATCH v2 2/3] config: remove unused config flags

[Lukasz Wojciechowski]

Following flags were still present in the common_base config,
but they were not used anywhere in the code:
* CONFIG_RTE_LIBRTE_ACL_DEBUG
* CONFIG_RTE_LIBRTE_NFP_DEBUG_TX
* CONFIG_RTE_LIBRTE_NFP_DEBUG_RX
* CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO_DEBUG

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/config/common_base b/config/common_base
index 9ec689dde..38c5ada26 100644
--- a/config/common_base
+++ b/config/common_base
@@ -380,8 +380,6 @@ CONFIG_RTE_IBVERBS_LINK_STATIC=n
 # Compile burst-oriented Netronome NFP PMD driver
 #
 CONFIG_RTE_LIBRTE_NFP_PMD=n
-CONFIG_RTE_LIBRTE_NFP_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_NFP_DEBUG_RX=n
 
 # QLogic 10G/25G/40G/50G/100G PMD
 #
@@ -591,7 +589,6 @@ CONFIG_RTE_CRYPTO_MAX_DEVS=64
 # Compile PMD for ARMv8 Crypto device
 #
 CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO=n
-CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO_DEBUG=n
 
 #
 # Compile NXP CAAM JR crypto Driver
@@ -952,7 +949,6 @@ CONFIG_RTE_LIBRTE_LPM_DEBUG=n
 # Compile librte_acl
 #
 CONFIG_RTE_LIBRTE_ACL=y
-CONFIG_RTE_LIBRTE_ACL_DEBUG=n
 
 #
 # Compile librte_power
-- 
2.17.1

[dpdk-dev] [PATCH v2 3/3] mbuf: standardize library debug flag

[Lukasz Wojciechowski]

Use standardized debug macro RTE_DEBUG_MBUF instead of
RTE_LIBRTE_MBUF_DEBUG for wrapping sanity checks.

Add runtime control of running sanity checks basing on
rte_log_can_log() function.

To run mbuf sanity checks all following conditions must occur:
1) RTE_DEBUG_MBUF - must be defined, this can be done by enabling meson
    rte_debug option or defining CFLAGS="-DRTE_DEBUG_MBUF"
2) global log level must be set to RTE_LOG_DEBUG
3) mbuf library logtype log level (lib.mbuf) must be set to RTE_LOG_DEBUG

Tests and documentation were also updated.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 app/test/test_mbuf.c               |  3 ++-
 config/common_base                 |  1 -
 doc/guides/prog_guide/mbuf_lib.rst |  2 +-
 lib/librte_mbuf/rte_mbuf.h         | 12 ++++++++----
 4 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 8200b4f71..b7b956659 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -994,7 +994,8 @@ test_pktmbuf_free_segment(struct rte_mempool *pktmbuf_pool)
 /*
  * Stress test for rte_mbuf atomic refcnt.
  * Implies that RTE_MBUF_REFCNT_ATOMIC is defined.
- * For more efficiency, recommended to run with RTE_LIBRTE_MBUF_DEBUG defined.
+ * For more efficiency, recommended to run with RTE_DEBUG_MBUF defined
+ * or using rte_debug meson build option.
  */
 
 #ifdef RTE_MBUF_REFCNT_ATOMIC
diff --git a/config/common_base b/config/common_base
index 38c5ada26..80fa3281f 100644
--- a/config/common_base
+++ b/config/common_base
@@ -859,7 +859,6 @@ CONFIG_RTE_LIBRTE_OCTEONTX2_MEMPOOL=y
 # Compile librte_mbuf
 #
 CONFIG_RTE_LIBRTE_MBUF=y
-CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
 CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS="ring_mp_mc"
 CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
 CONFIG_RTE_PKTMBUF_HEADROOM=128
diff --git a/doc/guides/prog_guide/mbuf_lib.rst b/doc/guides/prog_guide/mbuf_lib.rst
index 0d3223b08..d633e9609 100644
--- a/doc/guides/prog_guide/mbuf_lib.rst
+++ b/doc/guides/prog_guide/mbuf_lib.rst
@@ -243,7 +243,7 @@ can be found in several of the sample applications, for example, the IPv4 Multic
 Debug
 -----
 
-In debug mode (CONFIG_RTE_MBUF_DEBUG is enabled),
+In debug mode (RTE_DEBUG_MBUF is enabled, e.g. by using "rte_debug" option during meson build),
 the functions of the mbuf library perform sanity checks before any operation (such as, buffer corruption, bad type, and so on).
 
 Use Cases
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index f8e492e59..f27d5e26e 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -35,6 +35,7 @@
 #include <rte_compat.h>
 #include <rte_common.h>
 #include <rte_config.h>
+#include <rte_log.h>
 #include <rte_mempool.h>
 #include <rte_memory.h>
 #include <rte_atomic.h>
@@ -341,17 +342,20 @@ rte_pktmbuf_priv_flags(struct rte_mempool *mp)
 #define RTE_MBUF_HAS_PINNED_EXTBUF(mb) \
 	(rte_pktmbuf_priv_flags(mb->pool) & RTE_PKTMBUF_POOL_F_PINNED_EXT_BUF)
 
-#ifdef RTE_LIBRTE_MBUF_DEBUG
+#ifdef RTE_DEBUG_MBUF
 
 /**  check mbuf type in debug mode */
-#define __rte_mbuf_sanity_check(m, is_h) rte_mbuf_sanity_check(m, is_h)
+#define __rte_mbuf_sanity_check(m, is_h) do {			\
+	if (rte_log_can_log(RTE_LOGTYPE_MBUF, RTE_LOG_DEBUG))	\
+		rte_mbuf_sanity_check(m, is_h);			\
+} while (0)
 
-#else /*  RTE_LIBRTE_MBUF_DEBUG */
+#else /*  RTE_DEBUG_MBUF */
 
 /**  check mbuf type in debug mode */
 #define __rte_mbuf_sanity_check(m, is_h) do { } while (0)
 
-#endif /*  RTE_LIBRTE_MBUF_DEBUG */
+#endif /*  RTE_DEBUG_MBUF */
 
 #ifdef RTE_MBUF_REFCNT_ATOMIC
 
-- 
2.17.1

Re: [dpdk-dev] [PATCH v2 0/3] introduce global debug flag

[Bruce Richardson]

On Wed, Apr 22, 2020 at 11:45:52PM +0200, Lukasz Wojciechowski wrote:
> This set of patches introduces a global rte_debug flag for dpdk.
> This will allow easy switch to debug build configuration using a single
> flag. In the debug mode a RTE_DEBUG macro is defined to 1
> and for every enabled to be built librarte a RTE_DEBUG_{library name}
> is also defined. These macros can be used to place a debug code
> inside #ifdef #endif clauses.
> 
> The following requirements were discussed on the mailing list:
> 1) The global debug flag is required to enable all the sanity checks
> and validations that are normally not used due to performance reasons
> 
> 2) The best option would be to have a single flag - not to introduce
> too many build options
> 
> 3) This option should be separated from meson "debug" option
> (used for build with symbols) and can be called "rte_debug"
> 
> 4) The currently existing DEBUG macros should not be replaced with
> a RTE_DEBUG macro. This would allow to still enable them using
> CFLAGS="-D..." to test a single module (library, driver).
> 
> 5) Currently existing options' names should be standardized
> to RTE_DEBUG_{library/driver name}, so they can be automatically enabled
> when rte_debug is set. Standardized names would allow easy usage
> in other modules.
> 
> 6) The debug functionality should be encapsulated in:
>         if (rte_log_can_log(...)) {
>                 ...
>         }
> for possibility to be filtered out in runtime.
> 
> 
> Because of the hot discussion of v1 version of patches, I limit
> the v2 version to mbuf library changes only, to see how it will impact
> the performance with rte_log_can_log usage and to get opinions.
> 
> Next steps would be to follow changes in other libraries and drivers.
> 
> ---
> v2:
> * Use new meson option rte_debug instead of debug
> * Add standardized defines for built libraries
> * Limit patches to mbuf library (as a POC)
> * Use rte_log_can_log to wrap debug section
> 
> Lukasz Wojciechowski (3):
>   config: introduce global rte debug flag
>   config: remove unused config flags
>   mbuf: standardize library debug flag
> 
I really like this set, looks a good approach to me anyway.

Out of interest - did you automate the scanning for all the different build
flags to find those in the second patch that weren't used, or did you come
across them by chance? Just wondering if there are any other unused flags
we can remove.

Re: [dpdk-dev] [PATCH v2 0/3] introduce global debug flag

[Lukasz Wojciechowski]

W dniu 24.04.2020 o 11:09, Bruce Richardson pisze:
> On Wed, Apr 22, 2020 at 11:45:52PM +0200, Lukasz Wojciechowski wrote:
>> This set of patches introduces a global rte_debug flag for dpdk.
>> This will allow easy switch to debug build configuration using a single
>> flag. In the debug mode a RTE_DEBUG macro is defined to 1
>> and for every enabled to be built librarte a RTE_DEBUG_{library name}
>> is also defined. These macros can be used to place a debug code
>> inside #ifdef #endif clauses.
>>
>> The following requirements were discussed on the mailing list:
>> 1) The global debug flag is required to enable all the sanity checks
>> and validations that are normally not used due to performance reasons
>>
>> 2) The best option would be to have a single flag - not to introduce
>> too many build options
>>
>> 3) This option should be separated from meson "debug" option
>> (used for build with symbols) and can be called "rte_debug"
>>
>> 4) The currently existing DEBUG macros should not be replaced with
>> a RTE_DEBUG macro. This would allow to still enable them using
>> CFLAGS="-D..." to test a single module (library, driver).
>>
>> 5) Currently existing options' names should be standardized
>> to RTE_DEBUG_{library/driver name}, so they can be automatically enabled
>> when rte_debug is set. Standardized names would allow easy usage
>> in other modules.
>>
>> 6) The debug functionality should be encapsulated in:
>>          if (rte_log_can_log(...)) {
>>                  ...
>>          }
>> for possibility to be filtered out in runtime.
>>
>>
>> Because of the hot discussion of v1 version of patches, I limit
>> the v2 version to mbuf library changes only, to see how it will impact
>> the performance with rte_log_can_log usage and to get opinions.
>>
>> Next steps would be to follow changes in other libraries and drivers.
>>
>> ---
>> v2:
>> * Use new meson option rte_debug instead of debug
>> * Add standardized defines for built libraries
>> * Limit patches to mbuf library (as a POC)
>> * Use rte_log_can_log to wrap debug section
>>
>> Lukasz Wojciechowski (3):
>>    config: introduce global rte debug flag
>>    config: remove unused config flags
>>    mbuf: standardize library debug flag
>>
> I really like this set, looks a good approach to me anyway.
>
> Out of interest - did you automate the scanning for all the different build
> flags to find those in the second patch that weren't used, or did you come
> across them by chance? Just wondering if there are any other unused flags
> we can remove.
I've done this semi-automated way. Just some greping and seding, but I 
focused  only on debug flags, so there might be more other flags.

-- 

Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com

Re: [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag

[Bruce Richardson]

On Wed, Apr 22, 2020 at 11:45:53PM +0200, Lukasz Wojciechowski wrote:
> A new boolean meson build flag is introduced with this patch: rte_debug.
> To enable this option add -Drte_debug=true to the meson configure command.
> 
> By enabling this flag the globaly defined macro RTE_DEBUG becomes
> defined. It should be used for enabling debug code in all dpdk project
> components. Using this flag allows to make additional checks or tests
> and provide additional logs even in performance sensitive parts of code.
> 
> The flag is disabled by default.
> 
> Additionally for all enabled to be built libraries
> a RTE_DEBUG_{library name} is defined and assigned a value 1.
> This standardize names of library specific debug macros. Those can
> be used also without rte_debug option by using CFLAGS="-D..." build
> parameter.
> 
> Code put inside RTE_DEBUG* #ifdef sections should be also put inside
> if (rte_log_can_log(...)) condition to allow run-time filtering of
> sanity checks, validations, logs and dumps when using rte_debug option.
> 
> Libraries will be adjusted to the change in separate patches.
> 
> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
> Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>

The drivers are missing debug flag options, which probably need to be
defined as <driver_type>_<driver_name> e.g. RTE_DEBUG_NET_I40E,
RTE_DEBUG_EVENT_SW, etc.

However, this is definitely a good start.

Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Re: [dpdk-dev] [PATCH v2 2/3] config: remove unused config flags

[Bruce Richardson]

On Wed, Apr 22, 2020 at 11:45:54PM +0200, Lukasz Wojciechowski wrote:
> Following flags were still present in the common_base config,
> but they were not used anywhere in the code:
> * CONFIG_RTE_LIBRTE_ACL_DEBUG
> * CONFIG_RTE_LIBRTE_NFP_DEBUG_TX
> * CONFIG_RTE_LIBRTE_NFP_DEBUG_RX
> * CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO_DEBUG
> 
> Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Re: [dpdk-dev] [PATCH v2 3/3] mbuf: standardize library debug flag

[Bruce Richardson]

On Wed, Apr 22, 2020 at 11:45:55PM +0200, Lukasz Wojciechowski wrote:
> Use standardized debug macro RTE_DEBUG_MBUF instead of
> RTE_LIBRTE_MBUF_DEBUG for wrapping sanity checks.
> 
> Add runtime control of running sanity checks basing on
> rte_log_can_log() function.
> 
> To run mbuf sanity checks all following conditions must occur:
> 1) RTE_DEBUG_MBUF - must be defined, this can be done by enabling meson
>     rte_debug option or defining CFLAGS="-DRTE_DEBUG_MBUF"
> 2) global log level must be set to RTE_LOG_DEBUG
> 3) mbuf library logtype log level (lib.mbuf) must be set to RTE_LOG_DEBUG
> 
> Tests and documentation were also updated.
> 
> Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> ---
>  app/test/test_mbuf.c               |  3 ++-
>  config/common_base                 |  1 -
>  doc/guides/prog_guide/mbuf_lib.rst |  2 +-
>  lib/librte_mbuf/rte_mbuf.h         | 12 ++++++++----
>  4 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
> index 8200b4f71..b7b956659 100644
> --- a/app/test/test_mbuf.c
> +++ b/app/test/test_mbuf.c
> @@ -994,7 +994,8 @@ test_pktmbuf_free_segment(struct rte_mempool *pktmbuf_pool)
>  /*
>   * Stress test for rte_mbuf atomic refcnt.
>   * Implies that RTE_MBUF_REFCNT_ATOMIC is defined.
> - * For more efficiency, recommended to run with RTE_LIBRTE_MBUF_DEBUG defined.
> + * For more efficiency, recommended to run with RTE_DEBUG_MBUF defined
> + * or using rte_debug meson build option.
>   */
>  
>  #ifdef RTE_MBUF_REFCNT_ATOMIC
> diff --git a/config/common_base b/config/common_base
> index 38c5ada26..80fa3281f 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -859,7 +859,6 @@ CONFIG_RTE_LIBRTE_OCTEONTX2_MEMPOOL=y
>  # Compile librte_mbuf
>  #
>  CONFIG_RTE_LIBRTE_MBUF=y
> -CONFIG_RTE_LIBRTE_MBUF_DEBUG=n

This provides no "standard" way to enable the debug options with make,
right? I think that is perhaps a step too far. Two options I see:
* Rather than dropping this flag, it could be converted inside the mbuf
  library (maybe the makefile) to the new version
* Replace this macro with CONFIG_RTE_DEBUG_MBUF

What do you think?

/Bruce

Re: [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag

[Andrew Rybchenko]

On 6/26/20 7:56 PM, Bruce Richardson wrote:
> On Wed, Apr 22, 2020 at 11:45:53PM +0200, Lukasz Wojciechowski wrote:
>> A new boolean meson build flag is introduced with this patch: rte_debug.
>> To enable this option add -Drte_debug=true to the meson configure command.
>>
>> By enabling this flag the globaly defined macro RTE_DEBUG becomes
>> defined. It should be used for enabling debug code in all dpdk project
>> components. Using this flag allows to make additional checks or tests
>> and provide additional logs even in performance sensitive parts of code.
>>
>> The flag is disabled by default.
>>
>> Additionally for all enabled to be built libraries
>> a RTE_DEBUG_{library name} is defined and assigned a value 1.
>> This standardize names of library specific debug macros. Those can
>> be used also without rte_debug option by using CFLAGS="-D..." build
>> parameter.
>>
>> Code put inside RTE_DEBUG* #ifdef sections should be also put inside
>> if (rte_log_can_log(...)) condition to allow run-time filtering of
>> sanity checks, validations, logs and dumps when using rte_debug option.
>>
>> Libraries will be adjusted to the change in separate patches.
>>
>> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
>> Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> 
> The drivers are missing debug flag options, which probably need to be
> defined as <driver_type>_<driver_name> e.g. RTE_DEBUG_NET_I40E,
> RTE_DEBUG_EVENT_SW, etc.
> 
> However, this is definitely a good start.
> 
> Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> 

Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>

[dpdk-dev] [PATCH v3 0/4] introduce global debug flag

[Lukasz Wojciechowski]

This set of patches introduces a global rte_debug flag for dpdk.
This will allow easy switch to debug build configuration using a single
flag. In the debug mode a RTE_DEBUG macro is defined to 1
and for every enabled to be built library a RTE_DEBUG_{library name}
and for every enabled to be built driver
a RTE_DEBUG_{driver_class}_{driver_name} is also defined.
These macros can be used to place a debug code
inside #ifdef #endif clauses.

The following requirements were discussed on the mailing list:
1) The global debug flag is required to enable all the sanity checks
and validations that are normally not used due to performance reasons

2) The best option would be to have a single flag - not to introduce
too many build options

3) This option should be separated from meson "debug" option
(used for build with symbols) and can be called "rte_debug"

4) The currently existing DEBUG macros should not be replaced with
a RTE_DEBUG macro. This would allow to still enable them using
CFLAGS="-D..." to test a single module (library, driver).

5) Currently existing options' names should be standardized
to RTE_DEBUG_{library/driver name}, so they can be automatically enabled
when rte_debug is set. Standardized names would allow easy usage
in other modules.

6) The debug functionality should be encapsulated in:
        if (rte_log_can_log(...)) {
                ...
        }
for possibility to be filtered out in runtime.


Because of the hot discussion of v1 version of patches, I limit
the v2 version to mbuf library changes only, to see how it will impact
the performance with rte_log_can_log usage and to get opinions.

v3 contains mbuf performance tests, which might help dpdk developers
community to decide if drop of performance related to rte_log_can_log
can be accepted.

If agreement is reached, next steps would be to follow changes
in other libraries and drivers.

---
v3:
* Define RTE_DEBUG_* flags also for drivers
* Bring back CONFIG option for librte_mbuf, but with new flag name
* Add mbuf performance tests

v2:
* Use new meson option rte_debug instead of debug
* Add standardized defines for built libraries
* Limit patches to mbuf library (as a POC)
* Use rte_log_can_log to wrap debug section

Lukasz Wojciechowski (4):
  config: introduce global rte debug flag
  config: remove unused config flags
  mbuf: standardize library debug flag
  app/test: add mbuf perf tests

 app/test/Makefile                  |   1 +
 app/test/meson.build               |   4 +-
 app/test/test_mbuf.c               |   3 +-
 app/test/test_mbuf_perf.c          | 273 +++++++++++++++++++++++++++++
 config/common_base                 |   6 +-
 config/meson.build                 |   4 +
 doc/guides/prog_guide/mbuf_lib.rst |   2 +-
 drivers/baseband/meson.build       |   1 +
 drivers/bus/meson.build            |   1 +
 drivers/common/meson.build         |   1 +
 drivers/compress/meson.build       |   1 +
 drivers/crypto/meson.build         |   1 +
 drivers/event/meson.build          |   1 +
 drivers/mempool/meson.build        |   1 +
 drivers/meson.build                |   3 +
 drivers/net/meson.build            |   1 +
 drivers/raw/meson.build            |   1 +
 drivers/vdpa/meson.build           |   1 +
 lib/librte_mbuf/rte_mbuf.h         |  12 +-
 lib/meson.build                    |   4 +
 meson_options.txt                  |   2 +
 21 files changed, 312 insertions(+), 12 deletions(-)
 create mode 100644 app/test/test_mbuf_perf.c

-- 
2.17.1

[dpdk-dev] [PATCH v3 1/4] config: introduce global rte debug flag

[Lukasz Wojciechowski]

A new boolean meson build flag is introduced with this patch: rte_debug.
To enable this option add -Drte_debug=true to the meson configure command.

By enabling this flag the globaly defined macro RTE_DEBUG becomes
defined. It should be used for enabling debug code in all dpdk project
components. Using this flag allows to make additional checks or tests
and provide additional logs even in performance sensitive parts of code.

The flag is disabled by default.

Additionally for all enabled to be built libraries
a RTE_DEBUG_{library name} is defined and assigned a value 1.
This standardize names of library specific debug macros. Those can
be used also without rte_debug option by using CFLAGS="-D..." build
parameter.

Code put inside RTE_DEBUG* #ifdef sections should be also put inside
if (rte_log_can_log(...)) condition to allow run-time filtering of
sanity checks, validations, logs and dumps when using rte_debug option.

Libraries will be adjusted to the change in separate patches.

Similarly for all enabled to be built drivers
a RTE_DEBUG_{driver_class}_{driver_name} is defined and assigned value 1.

Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/meson.build           | 4 ++++
 drivers/baseband/meson.build | 1 +
 drivers/bus/meson.build      | 1 +
 drivers/common/meson.build   | 1 +
 drivers/compress/meson.build | 1 +
 drivers/crypto/meson.build   | 1 +
 drivers/event/meson.build    | 1 +
 drivers/mempool/meson.build  | 1 +
 drivers/meson.build          | 3 +++
 drivers/net/meson.build      | 1 +
 drivers/raw/meson.build      | 1 +
 drivers/vdpa/meson.build     | 1 +
 lib/meson.build              | 4 ++++
 meson_options.txt            | 2 ++
 14 files changed, 23 insertions(+)

diff --git a/config/meson.build b/config/meson.build
index cff8b33dd..c65c6412a 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -179,6 +179,10 @@ endif
 # add -include rte_config to cflags
 add_project_arguments('-include', 'rte_config.h', language: 'c')
 
+if get_option('rte_debug')
+	dpdk_conf.set('RTE_DEBUG', 1)
+endif
+
 # enable extra warnings and disable any unwanted warnings
 warning_flags = [
 	# -Wall is added by meson by default, so add -Wextra only
diff --git a/drivers/baseband/meson.build b/drivers/baseband/meson.build
index 415b6724b..11ff30e5a 100644
--- a/drivers/baseband/meson.build
+++ b/drivers/baseband/meson.build
@@ -9,3 +9,4 @@ drivers = ['null', 'turbo_sw', 'fpga_lte_fec', 'fpga_5gnr_fec']
 
 config_flag_fmt = 'RTE_LIBRTE_PMD_BBDEV_@0@'
 driver_name_fmt = 'rte_pmd_bbdev_@0@'
+rte_debug_fmt = 'RTE_DEBUG_BASEBAND_@0@'
diff --git a/drivers/bus/meson.build b/drivers/bus/meson.build
index 80de2d91d..8ccbce75b 100644
--- a/drivers/bus/meson.build
+++ b/drivers/bus/meson.build
@@ -5,3 +5,4 @@ drivers = ['dpaa', 'fslmc', 'ifpga', 'pci', 'vdev', 'vmbus']
 std_deps = ['eal']
 config_flag_fmt = 'RTE_LIBRTE_@0@_BUS'
 driver_name_fmt = 'rte_bus_@0@'
+rte_debug_fmt = 'RTE_DEBUG_BUS_@0@'
diff --git a/drivers/common/meson.build b/drivers/common/meson.build
index 5db7e29b1..a72f14905 100644
--- a/drivers/common/meson.build
+++ b/drivers/common/meson.build
@@ -9,3 +9,4 @@ std_deps = ['eal']
 drivers = ['cpt', 'dpaax', 'iavf', 'mlx5', 'mvep', 'octeontx', 'octeontx2', 'qat']
 config_flag_fmt = 'RTE_LIBRTE_@0@_COMMON'
 driver_name_fmt = 'rte_common_@0@'
+rte_debug_fmt = 'RTE_DEBUG_COMMON_@0@'
diff --git a/drivers/compress/meson.build b/drivers/compress/meson.build
index ee883c3f9..b446bd988 100644
--- a/drivers/compress/meson.build
+++ b/drivers/compress/meson.build
@@ -10,3 +10,4 @@ drivers = ['isal', 'octeontx', 'qat', 'zlib']
 std_deps = ['compressdev'] # compressdev pulls in all other needed deps
 config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
 driver_name_fmt = 'rte_pmd_@0@'
+rte_debug_fmt = 'RTE_DEBUG_COMPRESS_@0@'
diff --git a/drivers/crypto/meson.build b/drivers/crypto/meson.build
index a2423507a..02c2c8752 100644
--- a/drivers/crypto/meson.build
+++ b/drivers/crypto/meson.build
@@ -28,3 +28,4 @@ drivers = ['aesni_gcm',
 std_deps = ['cryptodev'] # cryptodev pulls in all other needed deps
 config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
 driver_name_fmt = 'rte_pmd_@0@'
+rte_debug_fmt = 'RTE_DEBUG_CRYPTO_@0@'
diff --git a/drivers/event/meson.build b/drivers/event/meson.build
index ebe76a75c..3e3c221c3 100644
--- a/drivers/event/meson.build
+++ b/drivers/event/meson.build
@@ -13,3 +13,4 @@ endif
 std_deps = ['eventdev', 'kvargs']
 config_flag_fmt = 'RTE_LIBRTE_@0@_EVENTDEV_PMD'
 driver_name_fmt = 'rte_pmd_@0@_event'
+rte_debug_fmt = 'RTE_DEBUG_EVENT_@0@'
diff --git a/drivers/mempool/meson.build b/drivers/mempool/meson.build
index c9609f145..ada93a75a 100644
--- a/drivers/mempool/meson.build
+++ b/drivers/mempool/meson.build
@@ -9,3 +9,4 @@ drivers = ['bucket', 'dpaa', 'dpaa2', 'octeontx', 'octeontx2', 'ring', 'stack']
 std_deps = ['mempool']
 config_flag_fmt = 'RTE_LIBRTE_@0@_MEMPOOL'
 driver_name_fmt = 'rte_mempool_@0@'
+rte_debug_fmt = 'RTE_DEBUG_MEMPOOL_@0@'
diff --git a/drivers/meson.build b/drivers/meson.build
index 161cfda04..975e1774b 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -99,6 +99,9 @@ foreach class:dpdk_driver_classes
 				fmt_name = name
 			endif
 			dpdk_conf.set(config_flag_fmt.format(fmt_name.to_upper()),1)
+			if get_option('rte_debug')
+				dpdk_conf.set(rte_debug_fmt.format(fmt_name.to_upper()),1)
+			endif
 			lib_name = driver_name_fmt.format(fmt_name)
 
 			dpdk_extra_ldflags += pkgconfig_extra_libs
diff --git a/drivers/net/meson.build b/drivers/net/meson.build
index d56b24051..0b4037b5f 100644
--- a/drivers/net/meson.build
+++ b/drivers/net/meson.build
@@ -60,3 +60,4 @@ std_deps += ['bus_pci']         # very many PMDs depend on PCI, so make std
 std_deps += ['bus_vdev']        # same with vdev bus
 config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
 driver_name_fmt = 'rte_pmd_@0@'
+rte_debug_fmt = 'RTE_DEBUG_NET_@0@'
diff --git a/drivers/raw/meson.build b/drivers/raw/meson.build
index 2c1e65ec7..703c2b8a8 100644
--- a/drivers/raw/meson.build
+++ b/drivers/raw/meson.build
@@ -13,3 +13,4 @@ drivers = ['dpaa2_cmdif', 'dpaa2_qdma',
 std_deps = ['rawdev']
 config_flag_fmt = 'RTE_LIBRTE_PMD_@0@_RAWDEV'
 driver_name_fmt = 'rte_rawdev_@0@'
+rte_debug_fmt = 'RTE_DEBUG_RAW_@0@'
diff --git a/drivers/vdpa/meson.build b/drivers/vdpa/meson.build
index 798eb3830..7e86a0c49 100644
--- a/drivers/vdpa/meson.build
+++ b/drivers/vdpa/meson.build
@@ -11,3 +11,4 @@ std_deps = ['bus_pci', 'kvargs']
 std_deps += ['vhost']
 config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
 driver_name_fmt = 'rte_pmd_@0@'
+rte_debug_fmt = 'RTE_DEBUG_VDPA_@0@'
diff --git a/lib/meson.build b/lib/meson.build
index 3852c0156..a06099a15 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -99,6 +99,10 @@ foreach l:libraries
 		dpdk_conf.set('RTE_LIBRTE_' + name.to_upper(), 1)
 		install_headers(headers)
 
+		if get_option('rte_debug')
+			dpdk_conf.set('RTE_DEBUG_' + name.to_upper(), 1)
+		endif
+
 		libname = 'rte_' + name
 		includes += include_directories(dir_name)
 
diff --git a/meson_options.txt b/meson_options.txt
index 9bf18ab6b..fc0fedd69 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -32,6 +32,8 @@ option('max_numa_nodes', type: 'integer', value: 4,
 	description: 'maximum number of NUMA nodes supported by EAL')
 option('enable_trace_fp', type: 'boolean', value: false,
 	description: 'enable fast path trace points.')
+option('rte_debug', type: 'boolean', value: false,
+	description: 'build with additional sanity checks, validations and logs')
 option('tests', type: 'boolean', value: true,
 	description: 'build unit tests')
 option('use_hpet', type: 'boolean', value: false,
-- 
2.17.1

[dpdk-dev] [PATCH v3 2/4] config: remove unused config flags

[Lukasz Wojciechowski]

Following flags were still present in the common_base config,
but they were not used anywhere in the code:
* CONFIG_RTE_LIBRTE_ACL_DEBUG
* CONFIG_RTE_LIBRTE_NFP_DEBUG_TX
* CONFIG_RTE_LIBRTE_NFP_DEBUG_RX
* CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO_DEBUG

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 config/common_base | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/config/common_base b/config/common_base
index cc9d034be..897100887 100644
--- a/config/common_base
+++ b/config/common_base
@@ -388,8 +388,6 @@ CONFIG_RTE_IBVERBS_LINK_STATIC=n
 # Compile burst-oriented Netronome NFP PMD driver
 #
 CONFIG_RTE_LIBRTE_NFP_PMD=n
-CONFIG_RTE_LIBRTE_NFP_DEBUG_TX=n
-CONFIG_RTE_LIBRTE_NFP_DEBUG_RX=n
 
 # QLogic 10G/25G/40G/50G/100G PMD
 #
@@ -599,7 +597,6 @@ CONFIG_RTE_CRYPTO_MAX_DEVS=64
 # Compile PMD for ARMv8 Crypto device
 #
 CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO=n
-CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO_DEBUG=n
 
 #
 # Compile NXP CAAM JR crypto Driver
@@ -967,7 +964,6 @@ CONFIG_RTE_LIBRTE_LPM_DEBUG=n
 # Compile librte_acl
 #
 CONFIG_RTE_LIBRTE_ACL=y
-CONFIG_RTE_LIBRTE_ACL_DEBUG=n
 
 #
 # Compile librte_power
-- 
2.17.1

[dpdk-dev] [PATCH v3 3/4] mbuf: standardize library debug flag

[Lukasz Wojciechowski]

Use standardized debug macro RTE_DEBUG_MBUF instead of
RTE_LIBRTE_MBUF_DEBUG for wrapping sanity checks.

Add runtime control of running sanity checks basing on
rte_log_can_log() function.

To run mbuf sanity checks all following conditions must occur:
1) RTE_DEBUG_MBUF - must be defined, this can be done by enabling meson
    rte_debug option or defining CFLAGS="-DRTE_DEBUG_MBUF"
2) global log level must be set to RTE_LOG_DEBUG
3) mbuf library logtype log level (lib.mbuf) must be set to RTE_LOG_DEBUG

Tests and documentation were also updated.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 app/test/test_mbuf.c               |  3 ++-
 config/common_base                 |  2 +-
 doc/guides/prog_guide/mbuf_lib.rst |  2 +-
 lib/librte_mbuf/rte_mbuf.h         | 12 ++++++++----
 4 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 06e44f0a7..b8cdd6efb 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -994,7 +994,8 @@ test_pktmbuf_free_segment(struct rte_mempool *pktmbuf_pool)
 /*
  * Stress test for rte_mbuf atomic refcnt.
  * Implies that RTE_MBUF_REFCNT_ATOMIC is defined.
- * For more efficiency, recommended to run with RTE_LIBRTE_MBUF_DEBUG defined.
+ * For more efficiency, recommended to run with RTE_DEBUG_MBUF defined
+ * or using rte_debug meson build option.
  */
 
 #ifdef RTE_MBUF_REFCNT_ATOMIC
diff --git a/config/common_base b/config/common_base
index 897100887..2805c1c2b 100644
--- a/config/common_base
+++ b/config/common_base
@@ -874,7 +874,7 @@ CONFIG_RTE_LIBRTE_OCTEONTX2_MEMPOOL=y
 # Compile librte_mbuf
 #
 CONFIG_RTE_LIBRTE_MBUF=y
-CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
+CONFIG_RTE_DEBUG_MBUF=n
 CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS="ring_mp_mc"
 CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
 CONFIG_RTE_PKTMBUF_HEADROOM=128
diff --git a/doc/guides/prog_guide/mbuf_lib.rst b/doc/guides/prog_guide/mbuf_lib.rst
index c3dbfb922..86ee29e07 100644
--- a/doc/guides/prog_guide/mbuf_lib.rst
+++ b/doc/guides/prog_guide/mbuf_lib.rst
@@ -266,7 +266,7 @@ can be found in several of the sample applications, for example, the IPv4 Multic
 Debug
 -----
 
-In debug mode (CONFIG_RTE_MBUF_DEBUG is enabled),
+In debug mode (RTE_DEBUG_MBUF is enabled, e.g. by using "rte_debug" option during meson build),
 the functions of the mbuf library perform sanity checks before any operation (such as, buffer corruption, bad type, and so on).
 
 Use Cases
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index f8e492e59..f27d5e26e 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -35,6 +35,7 @@
 #include <rte_compat.h>
 #include <rte_common.h>
 #include <rte_config.h>
+#include <rte_log.h>
 #include <rte_mempool.h>
 #include <rte_memory.h>
 #include <rte_atomic.h>
@@ -341,17 +342,20 @@ rte_pktmbuf_priv_flags(struct rte_mempool *mp)
 #define RTE_MBUF_HAS_PINNED_EXTBUF(mb) \
 	(rte_pktmbuf_priv_flags(mb->pool) & RTE_PKTMBUF_POOL_F_PINNED_EXT_BUF)
 
-#ifdef RTE_LIBRTE_MBUF_DEBUG
+#ifdef RTE_DEBUG_MBUF
 
 /**  check mbuf type in debug mode */
-#define __rte_mbuf_sanity_check(m, is_h) rte_mbuf_sanity_check(m, is_h)
+#define __rte_mbuf_sanity_check(m, is_h) do {			\
+	if (rte_log_can_log(RTE_LOGTYPE_MBUF, RTE_LOG_DEBUG))	\
+		rte_mbuf_sanity_check(m, is_h);			\
+} while (0)
 
-#else /*  RTE_LIBRTE_MBUF_DEBUG */
+#else /*  RTE_DEBUG_MBUF */
 
 /**  check mbuf type in debug mode */
 #define __rte_mbuf_sanity_check(m, is_h) do { } while (0)
 
-#endif /*  RTE_LIBRTE_MBUF_DEBUG */
+#endif /*  RTE_DEBUG_MBUF */
 
 #ifdef RTE_MBUF_REFCNT_ATOMIC
 
-- 
2.17.1

[dpdk-dev] [PATCH v3 4/4] app/test: add mbuf perf tests

[Lukasz Wojciechowski]

This patch adds new test command mbuf_perf_autotest to test app,
which executes six basic performance tests:
* alloc_free - allocation and freeing mbufs one by one
* bulk_alloc_free - as above but in bulks
* data_manipulation - few command modifying mbuf
* sanity_checks_without_header - only sanity checks with unset header flag
* sanity_checks_with_header - as above but with header flag set
* sanity_checks_with_header_in_chain - as above but all mbufs are
    chained into one list

Purpose of this patch is to measure drop of performance, when using
realtime checks with rte_log_can_log in rte_debug enabled configuration.

Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
---
 app/test/Makefile         |   1 +
 app/test/meson.build      |   4 +-
 app/test/test_mbuf_perf.c | 273 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 277 insertions(+), 1 deletion(-)
 create mode 100644 app/test/test_mbuf_perf.c

diff --git a/app/test/Makefile b/app/test/Makefile
index e5440774b..09567a239 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -111,6 +111,7 @@ SRCS-y += test_mempool.c
 SRCS-y += test_mempool_perf.c
 
 SRCS-y += test_mbuf.c
+SRCS-y += test_mbuf_perf.c
 SRCS-y += test_logs.c
 
 SRCS-y += test_memcpy.c
diff --git a/app/test/meson.build b/app/test/meson.build
index 39f295d73..b64bc4684 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -74,6 +74,7 @@ test_sources = files('commands.c',
 	'test_lpm_perf.c',
 	'test_malloc.c',
 	'test_mbuf.c',
+	'test_mbuf_perf.c',
 	'test_member.c',
 	'test_member_perf.c',
 	'test_memcpy.c',
@@ -295,7 +296,8 @@ perf_test_names = [
         'hash_readwrite_perf_autotest',
         'hash_readwrite_lf_perf_autotest',
         'trace_perf_autotest',
-	'ipsec_perf_autotest',
+        'ipsec_perf_autotest',
+        'mbuf_perf_autotest',
 ]
 
 driver_test_names = [
diff --git a/app/test/test_mbuf_perf.c b/app/test/test_mbuf_perf.c
new file mode 100644
index 000000000..42f2079ac
--- /dev/null
+++ b/app/test/test_mbuf_perf.c
@@ -0,0 +1,273 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (c) 2020 Samsung Electronics Co., Ltd All Rights Reserved
+ */
+
+#include <stdio.h>
+#include <sys/time.h>
+
+#include <rte_common.h>
+#include <rte_mbuf.h>
+#include <rte_memory.h>
+
+#include "test.h"
+
+#define NB_MBUF                 1024
+#define MEMPOOL_CACHE_SIZE	0
+#define MBUF_DATA_SIZE		2048
+#define MBUF_PRIV_SIZE		128
+#define REPEAT			(1024*1024)
+
+static int
+case_mbuf_alloc_free(struct rte_mempool *pktmbuf_pool)
+{
+	unsigned int i;
+	int ret = TEST_SUCCESS;
+	int r;
+
+	struct rte_mbuf *m[NB_MBUF];
+	for (i = 0; i < NB_MBUF; i++)
+		m[i] = NULL;
+
+	for (r = 0; r < REPEAT; r++) {
+		for (i = 0; i < NB_MBUF; i++) {
+			m[i] = rte_pktmbuf_alloc(pktmbuf_pool);
+			if (m[i] == NULL) {
+				printf("rte_pktmbuf_alloc() failed (%u)"
+					" at repetition %d\n", i, r);
+				ret = TEST_FAILED;
+				goto end;
+			}
+		}
+		for (i = 0; i < NB_MBUF; i++) {
+			if (m[i] != NULL) {
+				rte_pktmbuf_free(m[i]);
+				m[i] = NULL;
+			}
+		}
+	}
+
+end:
+	for (i = 0; i < NB_MBUF; i++) {
+		if (m[i] != NULL)
+			rte_pktmbuf_free(m[i]);
+	}
+	return ret;
+}
+
+static int
+case_mbuf_bulk_alloc_free(struct rte_mempool *pktmbuf_pool)
+{
+	int ret = TEST_SUCCESS;
+	int r;
+	struct rte_mbuf *m[NB_MBUF];
+
+	for (r = 0; r < REPEAT; r++) {
+		ret = rte_pktmbuf_alloc_bulk(pktmbuf_pool, m, NB_MBUF);
+		if (ret != 0) {
+			printf("rte_pktmbuf_alloc_bulk() failed"
+				" at repetition %d\n", r);
+			ret = TEST_FAILED;
+			break;
+		}
+		rte_pktmbuf_free_bulk(m, NB_MBUF);
+	}
+	return ret;
+}
+
+static int
+case_mbuf_data_manipulation(struct rte_mempool *pktmbuf_pool)
+{
+	unsigned int i;
+	int ret = TEST_SUCCESS;
+	int r;
+
+	struct rte_mbuf *m[NB_MBUF];
+	ret = rte_pktmbuf_alloc_bulk(pktmbuf_pool, m, NB_MBUF);
+	if (ret != 0) {
+		printf("rte_pktmbuf_alloc_bulk() failed\n");
+		return TEST_FAILED;
+	}
+
+	for (r = 0; r < REPEAT; r++) {
+		for (i = 0; i < NB_MBUF; i++) {
+			if (!rte_pktmbuf_is_contiguous(m[i])) {
+				printf("rte_pktmbuf_is_contiguous() failed"
+					" (%u)\n", i);
+				ret = TEST_FAILED;
+				goto end;
+			}
+			if (rte_pktmbuf_append(m[i], 0) == NULL) {
+				printf("rte_pktmbuf_append() failed"
+					" (%u)\n", i);
+				ret = TEST_FAILED;
+				goto end;
+			}
+			if (rte_pktmbuf_trim(m[i], 0) < 0) {
+				printf("rte_pktmbuf_trim() failed (%u)\n", i);
+				ret = TEST_FAILED;
+				goto end;
+			}
+			if (rte_pktmbuf_prepend(m[i], 0) == NULL) {
+				printf("rte_pktmbuf_prepend() failed"
+					" (%u)\n", i);
+				ret = TEST_FAILED;
+				goto end;
+			}
+			if (rte_pktmbuf_adj(m[i], 0) == NULL) {
+				printf("rte_pktmbuf_adj() failed (%u)\n", i);
+				ret = TEST_FAILED;
+				goto end;
+			}
+		}
+	}
+
+end:
+	rte_pktmbuf_free_bulk(m, NB_MBUF);
+	return ret;
+}
+
+static int
+case_mbuf_sanity_checks_without_header(struct rte_mempool *pktmbuf_pool)
+{
+	unsigned int i;
+	int ret = TEST_SUCCESS;
+	int r;
+
+	struct rte_mbuf *m[NB_MBUF];
+	ret = rte_pktmbuf_alloc_bulk(pktmbuf_pool, m, NB_MBUF);
+	if (ret != 0) {
+		printf("rte_pktmbuf_alloc_bulk() failed\n");
+		return TEST_FAILED;
+	}
+
+	for (r = 0; r < REPEAT; r++)
+		for (i = 0; i < NB_MBUF; i++)
+			rte_mbuf_sanity_check(m[i], 0);
+
+	rte_pktmbuf_free_bulk(m, NB_MBUF);
+	return ret;
+}
+
+static int
+case_mbuf_sanity_checks_with_header(struct rte_mempool *pktmbuf_pool)
+{
+	unsigned int i;
+	int ret = TEST_SUCCESS;
+	int r;
+
+	struct rte_mbuf *m[NB_MBUF];
+	ret = rte_pktmbuf_alloc_bulk(pktmbuf_pool, m, NB_MBUF);
+	if (ret != 0) {
+		printf("rte_pktmbuf_alloc_bulk() failed\n");
+		return TEST_FAILED;
+	}
+
+	for (r = 0; r < REPEAT; r++)
+		for (i = 0; i < NB_MBUF; i++)
+			rte_mbuf_sanity_check(m[i], 1);
+
+	rte_pktmbuf_free_bulk(m, NB_MBUF);
+	return ret;
+}
+
+static int
+case_mbuf_sanity_checks_with_header_in_chain(struct rte_mempool *pktmbuf_pool)
+{
+	unsigned int i;
+	int ret = TEST_SUCCESS;
+	int r;
+
+	struct rte_mbuf *m[NB_MBUF];
+	ret = rte_pktmbuf_alloc_bulk(pktmbuf_pool, m, NB_MBUF);
+	if (ret != 0) {
+		printf("rte_pktmbuf_alloc_bulk() failed\n");
+		return TEST_FAILED;
+	}
+
+	for (i = 1; i < NB_MBUF; i++) {
+		ret = rte_pktmbuf_chain(m[0], m[i]);
+		if (ret != 0) {
+			printf("rte_pktmbuf_chain() failed: %d\n", ret);
+			goto end;
+		}
+		m[i] = NULL;
+	}
+
+	for (r = 0; r < REPEAT; r++)
+		rte_mbuf_sanity_check(m[0], 1);
+
+end:
+	rte_pktmbuf_free_bulk(m, NB_MBUF);
+	return ret;
+}
+
+struct testcase {
+	int (*func)(struct rte_mempool *pktmbuf_pool);
+	const char *name;
+	double time;
+	int ret;
+};
+
+#define TC(F) {.func = F, .name = RTE_STR(F), .time = 0.0, .ret = TEST_SKIPPED}
+
+static int
+test_mbuf_perf(void)
+{
+	int ret = TEST_SUCCESS;
+	struct timeval tv_begin, tv_end;
+	struct testcase cases[] = {
+		TC(case_mbuf_alloc_free),
+		TC(case_mbuf_bulk_alloc_free),
+		TC(case_mbuf_data_manipulation),
+		TC(case_mbuf_sanity_checks_without_header),
+		TC(case_mbuf_sanity_checks_with_header),
+		TC(case_mbuf_sanity_checks_with_header_in_chain),
+	};
+	int i, n = RTE_DIM(cases);
+	const char *status_ok = "[ OK ]";
+	const char *status_skip = "[SKIP]";
+	const char *status_fail = "[FAIL]";
+	const char *status;
+	struct rte_mempool *pktmbuf_pool = NULL;
+
+	pktmbuf_pool = rte_pktmbuf_pool_create("test_pktmbuf_pool",
+			NB_MBUF, MEMPOOL_CACHE_SIZE, MBUF_PRIV_SIZE,
+			MBUF_DATA_SIZE,	SOCKET_ID_ANY);
+	if (pktmbuf_pool == NULL) {
+		printf("cannot allocate mbuf pool\n");
+		ret = TEST_FAILED;
+		goto end;
+	}
+
+	for (i = 0; i < n; i++) {
+		printf("=== running %s ===\n", cases[i].name);
+		gettimeofday(&tv_begin, NULL);
+		cases[i].ret = cases[i].func(pktmbuf_pool);
+		gettimeofday(&tv_end, NULL);
+		cases[i].time = (double)(tv_end.tv_sec - tv_begin.tv_sec)
+			+ ((double)tv_end.tv_usec - tv_begin.tv_usec)/1000000;
+	}
+
+	printf("%-50s %-10s %s:\n", "TestName", "Status", "Time(seconds)");
+	for (i = 0; i < n; i++) {
+		if (cases[i].ret == TEST_SKIPPED)
+			status = status_skip;
+		else if (cases[i].ret == TEST_SUCCESS)
+			status = status_ok;
+		else {
+			status = status_fail;
+			ret = TEST_FAILED;
+		}
+		printf("%-50s %-10s %8.3f\n", cases[i].name, status,
+			cases[i].time);
+	}
+
+end:
+	if (pktmbuf_pool != NULL)
+		rte_mempool_free(pktmbuf_pool);
+
+	return ret;
+}
+
+REGISTER_TEST_COMMAND(mbuf_perf_autotest, test_mbuf_perf);
+
-- 
2.17.1

Re: [dpdk-dev] [PATCH v2 3/3] mbuf: standardize library debug flag

[Lukasz Wojciechowski]

W dniu 26.06.2020 o 19:00, Bruce Richardson pisze:
> On Wed, Apr 22, 2020 at 11:45:55PM +0200, Lukasz Wojciechowski wrote:
>> Use standardized debug macro RTE_DEBUG_MBUF instead of
>> RTE_LIBRTE_MBUF_DEBUG for wrapping sanity checks.
>>
>> Add runtime control of running sanity checks basing on
>> rte_log_can_log() function.
>>
>> To run mbuf sanity checks all following conditions must occur:
>> 1) RTE_DEBUG_MBUF - must be defined, this can be done by enabling meson
>>      rte_debug option or defining CFLAGS="-DRTE_DEBUG_MBUF"
>> 2) global log level must be set to RTE_LOG_DEBUG
>> 3) mbuf library logtype log level (lib.mbuf) must be set to RTE_LOG_DEBUG
>>
>> Tests and documentation were also updated.
>>
>> Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
>> ---
>>   app/test/test_mbuf.c               |  3 ++-
>>   config/common_base                 |  1 -
>>   doc/guides/prog_guide/mbuf_lib.rst |  2 +-
>>   lib/librte_mbuf/rte_mbuf.h         | 12 ++++++++----
>>   4 files changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
>> index 8200b4f71..b7b956659 100644
>> --- a/app/test/test_mbuf.c
>> +++ b/app/test/test_mbuf.c
>> @@ -994,7 +994,8 @@ test_pktmbuf_free_segment(struct rte_mempool *pktmbuf_pool)
>>   /*
>>    * Stress test for rte_mbuf atomic refcnt.
>>    * Implies that RTE_MBUF_REFCNT_ATOMIC is defined.
>> - * For more efficiency, recommended to run with RTE_LIBRTE_MBUF_DEBUG defined.
>> + * For more efficiency, recommended to run with RTE_DEBUG_MBUF defined
>> + * or using rte_debug meson build option.
>>    */
>>   
>>   #ifdef RTE_MBUF_REFCNT_ATOMIC
>> diff --git a/config/common_base b/config/common_base
>> index 38c5ada26..80fa3281f 100644
>> --- a/config/common_base
>> +++ b/config/common_base
>> @@ -859,7 +859,6 @@ CONFIG_RTE_LIBRTE_OCTEONTX2_MEMPOOL=y
>>   # Compile librte_mbuf
>>   #
>>   CONFIG_RTE_LIBRTE_MBUF=y
>> -CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
> This provides no "standard" way to enable the debug options with make,
> right? I think that is perhaps a step too far. Two options I see:
> * Rather than dropping this flag, it could be converted inside the mbuf
>    library (maybe the makefile) to the new version
> * Replace this macro with CONFIG_RTE_DEBUG_MBUF
>
> What do you think?

I prefer the second option because we want to standardize the names - so 
let it be only one flag with proper name. Using conversion would be a 
bit messy as probably final user will be able to achieve the same effect 
using either old or new flag.

Change applied in v3.


> /Bruce
>
>
-- 
Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com

Re: [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag

[Lukasz Wojciechowski]

W dniu 26.06.2020 o 18:56, Bruce Richardson pisze:
> On Wed, Apr 22, 2020 at 11:45:53PM +0200, Lukasz Wojciechowski wrote:
>> A new boolean meson build flag is introduced with this patch: rte_debug.
>> To enable this option add -Drte_debug=true to the meson configure command.
>>
>> By enabling this flag the globaly defined macro RTE_DEBUG becomes
>> defined. It should be used for enabling debug code in all dpdk project
>> components. Using this flag allows to make additional checks or tests
>> and provide additional logs even in performance sensitive parts of code.
>>
>> The flag is disabled by default.
>>
>> Additionally for all enabled to be built libraries
>> a RTE_DEBUG_{library name} is defined and assigned a value 1.
>> This standardize names of library specific debug macros. Those can
>> be used also without rte_debug option by using CFLAGS="-D..." build
>> parameter.
>>
>> Code put inside RTE_DEBUG* #ifdef sections should be also put inside
>> if (rte_log_can_log(...)) condition to allow run-time filtering of
>> sanity checks, validations, logs and dumps when using rte_debug option.
>>
>> Libraries will be adjusted to the change in separate patches.
>>
>> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
>> Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> The drivers are missing debug flag options, which probably need to be
> defined as <driver_type>_<driver_name> e.g. RTE_DEBUG_NET_I40E,
> RTE_DEBUG_EVENT_SW, etc.
I added also flags for drivers constructed as you suggested (see v3).
It might however be a bit tricky to differentiate library debug flags 
form drivers, e.g.
RTE_DEBUG_MEMPOOL (library) vs RTE_DEBUG_MEMPOOL_DPAA (driver).

If there is a need the macro names can be changed by adding _LIB_ or _DRV_.
What do you think?
> However, this is definitely a good start.
>
> Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>
-- 
Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com

Re: [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag

[Bruce Richardson]

On Thu, Jul 09, 2020 at 03:51:25PM +0200, Lukasz Wojciechowski wrote:
> 
> W dniu 26.06.2020 o 18:56, Bruce Richardson pisze:
> > On Wed, Apr 22, 2020 at 11:45:53PM +0200, Lukasz Wojciechowski wrote:
> >> A new boolean meson build flag is introduced with this patch: rte_debug.
> >> To enable this option add -Drte_debug=true to the meson configure command.
> >>
> >> By enabling this flag the globaly defined macro RTE_DEBUG becomes
> >> defined. It should be used for enabling debug code in all dpdk project
> >> components. Using this flag allows to make additional checks or tests
> >> and provide additional logs even in performance sensitive parts of code.
> >>
> >> The flag is disabled by default.
> >>
> >> Additionally for all enabled to be built libraries
> >> a RTE_DEBUG_{library name} is defined and assigned a value 1.
> >> This standardize names of library specific debug macros. Those can
> >> be used also without rte_debug option by using CFLAGS="-D..." build
> >> parameter.
> >>
> >> Code put inside RTE_DEBUG* #ifdef sections should be also put inside
> >> if (rte_log_can_log(...)) condition to allow run-time filtering of
> >> sanity checks, validations, logs and dumps when using rte_debug option.
> >>
> >> Libraries will be adjusted to the change in separate patches.
> >>
> >> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
> >> Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> > The drivers are missing debug flag options, which probably need to be
> > defined as <driver_type>_<driver_name> e.g. RTE_DEBUG_NET_I40E,
> > RTE_DEBUG_EVENT_SW, etc.
> I added also flags for drivers constructed as you suggested (see v3).
> It might however be a bit tricky to differentiate library debug flags 
> form drivers, e.g.
> RTE_DEBUG_MEMPOOL (library) vs RTE_DEBUG_MEMPOOL_DPAA (driver).
> 
> If there is a need the macro names can be changed by adding _LIB_ or _DRV_.
> What do you think?

I don't think DRV is needed for the drivers, though perhaps LIB (or RTE) could
be added for the libs. I actually think that mempool is the only case where
we might have any confusion, for other device classes the library names
tend to have "dev" on the end, e.g. cryptodev, rawdev etc.

So overall, I'd suggest it's not a problem, but if you want modify the lib
one.

/Bruce

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Lukasz Wojciechowski]

W dniu 22.04.2020 o 14:24, Thomas Monjalon pisze:
> 22/04/2020 13:29, Ananyev, Konstantin:
>>> 22/04/2020 12:55, Bruce Richardson:
>>>> On Wed, Apr 22, 2020 at 12:41:49PM +0200, Lukasz Wojciechowski wrote:
>>>>> W dniu 21.04.2020 o 23:38, Thomas Monjalon pisze:
>>>>>> 21/04/2020 22:58, Lukasz Wojciechowski:
>>>>>>> W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze:
>>>>>>>>>>>>>>>> I am agree with Cristian concern here: that patch removes ability to
>>>>>>>>>>>>>>>> enable/disable debug on particular library/PMD.  If the purpose is to
>>>>>>>>>>>>>>>> minimize number of config compile options, I wonder can't it be done
>>>>>>>>>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep
>>>>>>>>>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build  file
>>>>>>>>>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug
>>>>>>>>>>>>>>>> flag for these libs.  Something like: If dpdk_conf.get('RTE_DEBUG') ==
>>>>>>>>>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> defines that are used by multiple libs, probably can be set in upper
>>>>>>>>>>>>>>>> layer meson.build.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That way will have global 'debug' flag, but users will still have an
>>>>>>>>>>>>>>>> ability to enable/disable debug flags on a per lib basis via
>>>>>>>>>>>>>>>> CFLAGS="-D..."
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That seems a reasonable idea to me.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can
>>>>>>>>>>>>>>> either:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * allow each component meson.build file define its own flags after
>>>>>>>>>>>>>>> checking get_option('debug') * have lib/meson.build and
>>>>>>>>>>>>>>> drivers/meson.build automatically define a specific define for each
>>>>>>>>>>>>>>> library or driver to standardize the naming.  [This would save anyone
>>>>>>>>>>>>>>> working on it from having to lookup what the define was, since it's
>>>>>>>>>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g.  RTE_DEBUG_LPM,
>>>>>>>>>>>>>>> RTE_DEBUG_SCHED etc]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Theoretically we can also do both, have the standard ones defined and
>>>>>>>>>>>>>>> then allow a component to provide extra flags itself if so desired.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Bruce
>>>>>>>>>>>>>> OK, so let's summarize how the patches should be redo: * usage of global
>>>>>>>>>>>>>> "debug" flag for meson build stays * we standardize names of debug flags
>>>>>>>>>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al
>>>>>>>>>>>>>> the RTE_DEBUG_... flags
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This allow to easily use both: * the debug flag - to enable all debugs *
>>>>>>>>>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single
>>>>>>>>>>>>>> component
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I like Bruce's idea of adding it to the lib/meson.build and
>>>>>>>>>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson
>>>>>>>>>>>>>> object and written then later to rte_build_config.h before compilation
>>>>>>>>>>>>>> stage.  All the other modules will be able to use these flags.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure
>>>>>>>>>>>>> others are ok with this before you spend too much effort implementing it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For the drivers, the flag probably needs to include the category as well as
>>>>>>>>>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible
>>>>>>>>>>>>> name confusion. Those flags can then be checked inside individual
>>>>>>>>>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe,
>>>>>>>>>>>>> you could theoretically do:
>>>>>>>>>>>>>
>>>>>>>>>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE')
>>>>>>>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX'
>>>>>>>>>>>>> 	cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX'
>>>>>>>>>>>>> 	...
>>>>>>>>>>>>> endif
>>>>>>>>>>>>>
>>>>>>>>>>>>> to enable more fine-grained control if so desired, and to maintain
>>>>>>>>>>>>> compatibility with existing defines, again if so desired.
>>>>>>>>>>>> Nak the nak from Cristian.
>>>>>>>>>>>>
>>>>>>>>>>>> We don't need all these flags.
>>>>>>>>>>>> If the user choose to compile DPDK for debug, every debug facilities
>>>>>>>>>>>> should be enabled. Then at runtime it is possible to enable/disable
>>>>>>>>>>>> the interesting logs.
>>>>>>>>>>>> If you need to disable something which is not a log,
>>>>>>>>>>>> you can align with the log level thanks to the function rte_log_can_log.
>>>>>>>> For many libs these flags mean much more than just logging.
>>>>>>>> Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many
>>>>>>>> drivers - extra validation performed.
>>>>>>>> RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call  to real
>>>>>>>> rte_mbuf_sanity_check() instead of just NOP.
>>>>>>>> Which means performance would be greatly affected.
>>>>>>>> RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header
>>>>>>>> and enforce extra checking, stats collection.
>>>>>>>> etc.
>>>>>>>> Probably that's ok for some cases to enable all that extra validation we have at once.
>>>>>>>> But I suppose in many cases people just interested to enable debug on one
>>>>>>>> (ok might be two/three) particular libraries, not the whole system.
>>>>>>>> Right now there is such ability, we are going to remove it without
>>>>>>>> providing adequate replacement.
>>>>>>>> Approach with rte_log_can_log() seems workable,
>>>>>>>> but right now these patches don't implement it.
>>>>>>>> Konstantin
>>>>>>>>
>>>>>>>>>>>> Please let's stop complicating things for the contributors and the users.
>>>>>>>>>>>> Note: I am strong on this position.
>>>>>>>>>>>>
>>>>>>>>>>> Note, this means that you need to ensure all debug printouts from libs and
>>>>>>>>>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think
>>>>>>>>>>> that may be some distance from reality right now.
>>>>>>>>>> Perfect! Let's expose those nasty logs which are not (yet) controllable.
>>>>>>>>>> And next step is to block any patch in those drivers or libs,
>>>>>>>>>> until it is fixed. Dynamic logging should have been complete for long.
>>>>>>>>>>
>>>>>>>>> I can live with that, I suppose. Do we have any idea of the magnitude of
>>>>>>>>> the work required here?
>>>>>>>>>
>>>>>>>>>>> Even if we do want all debug enabled from one flag, I'm still not 100%
>>>>>>>>>>> convinced that the existing debug flag is the way to do, since it only adds
>>>>>>>>>>> debug info to binary without affecting code generation.
>>>>>>>>>> OK, we want to keep this flag for gdb symbols only?
>>>>>>>>>> And add a new flag for debugging facilities which hurt the runtime performance?
>>>>>>>>>>
>>>>>>>>> I think that would be wise, yes. We can call the option "rte_debug" or
>>>>>>>>> something instead.
>>>>>>>>>
>>>>>>>>> /Bruce
>>>>>>> OK, lets's summarize current opinions and requirements to make a
>>>>>>> proposal for version2 of these patches, that I can implement if all agree:
>>>>>>>
>>>>>>> 1) The global debug flag is required to enable all the sanity checks and
>>>>>>> validations that are normally not used due to performance reasons
>>>>>> Yes
>>>>>>
>>>>>>> 2) The best option would be to have a single flag - not to introduce too
>>>>>>> many build options
>>>>>> Yes
>>>>>>
>>>>>>> 3) This option should be separated from meson "debug" option (used for
>>>>>>> build with symbols) and can be called "rte_debug"
>>>>>> Yes, it looks to be the consensus.
>>>>>>
>>>>>>> 4) The currently existing DEBUG macros should not be replaced with a
>>>>>>> RTE_DEBUG macro. This would allow to still enable them using
>>>>>>> CFLAGS="-D..." to test a single module (library, driver).
>>>>>>>
>>>>>>> 5) Currently existing options' names should be standardized to
>>>>>>> RTE_DEBUG_{library/driver name}, so they can be automatically enabled
>>>>>>> when rte_debug is set. Standardized names would allow easy usage in
>>>>>>> other modules.
>>>>>> I don't understand difference between 4) et 5).
>>>>> In current version of patches, I replaced all the DEBUG macros with
>>>>> RTE_DEBUG. It would be much better to keep fine-grained debugs as they
>>>>> are defined currently in dpdk. This is what I have on mind in 4)
>>>>>
>>>>> However the currently used debug macros have different naming
>>>>> conventions: some use RTE_LIBRTE_{name}_DEBUG convention, other
>>>>> RTE_{name}_DEBUG, some just {name}_DEBUG.
>>>>> So in 5) I follow Bruce's proposal to standardize them to one form
>>>>> RTE_DEBUG_{name}. However this will change the existing macros and
>>>>> someone might not like it, so I ask for the opinion about it.
>>>>>
>>>> My thought is to standardize in the build and then leave it to module
>>>> owners to either change their macros to use those standard ones as time
>>>> goes on.
>>> In order to maintain a good global user experience,
>>> we need to drive such change with a roadmap and deadlines.
>>>
>>>>>>> Should they? Or should we leave the current debug macros? Please share
>>>>>>> your opinions as I see both cons and pros of this idea.
>>>>>> I am not sure we need to keep fine-grain debug flags per libs/drivers.
>>>>>> In case RTE_DEBUG is enabled, which kind of debug processing
>>>>>> (except logs) do we want to be able to disable?
>>>>>> Is it possible to decide based on a call to rte_log_can_log()?
>>>>> I think it's rather opposite way round. Sometimes we would like to
>>>>> enable just some debug processing, e.g. when working on single lib or
>>>>> driver.
>>>>> If we will use rte_debug - every debug  processing would be enabled, we
>>>>> won't disable anything, but without rte_debug we will still have the
>>>>> possibility of enabling debugs on a single module.
>>>>>
>>>>> I believe it is possible to do it with rte_log_can_log, but changing
>>>>> build time enabled options into runtime enabled options might affect
>>>>> performance. It might make working on a single library or driver harder.
>>>>>
>>>> I think the idea is to use both. When RTE_DEBUG is enabled, then the
>>>> rte_log_can_log() calls will be used to control the actual output. Without
>>>> RTE_DEBUG, the whole block is skipped.
>>>>
>>>> #ifdef RTE_DEBUG
>>>> 	if rte_log_can_log(...) {
>>>> 		/* do debug stuff */
>>>> 	}
>>>> #endif
>>> This is what I had in mind.
>>> The question is about performance impact in the case
>>> we enable RTE_DEBUG at compilation time, and don't enable a
>>> specific debug at runtime: is this check overhead acceptable?
>>> 	if rte_log_can_log(...)
>> We probably wouldn't know the answer  before trying.
>> Probably best way to make such changes for rte_mbuf and see how
>> big the drop will be.
>> I suppose mbuf will be the one mostly affected,
>> as we'll call rte_log_can_log() for nearly every mbuf op (free/detach/attach/reset, etc.)
> Yes I like the idea of trying with mbuf,
> and see how much a compilation flag for global debugging
> affects the mbuf performance.

I've just pushed v3 with minor fixes and mbuf performance tests. There 
are 6 very simple tests:
* alloc_free allocates and frees mbufs from/to mempool one by one
* bulk_alloc_free does the same but in bulks
* data_manipulation uses few functions containing sanity checks 
(is_contiguous, append, trim, prepend, adj)
* sanity_checks_without_header runs robust sanity checks (with header 
parameter = 0)
* sanity_checks_with_header does full  sanity checks (with header 
parameter = 1)
* sanity_checks_with_header_in_chain does the same as above, but all 
mbufs are chained into single list.

I run those tests in 3 different compilations:
* debug without_rte_log_can_log - sanity checks not empty, but without 
runtime checks of rte_log_can_log
* debug with_rte_log_can_log - debug enabled and runtime checks used
* no debug - debug mode  disabled - sanity checks are empty macros

All the tests use 1024 mbufs of size (2048 + 128) and repeat test 1e6 times.

I repeated every scenario 5 times and calculated average times as you 
can see in the below table. All times are in seconds.

There is no much difference between both debug variants. Of course 
without rte_log it's slightly better, but the time deviation between 
samples is very big and in many cases bigger than differences.

There is a huge difference between debug and non-debug scenarios 
especially in data_manipulation test case.


So Konstantin, what do you think about these results. Can we apply 
similar patches for other libraries and drivers?

> Note that we should also manage RTE_ENABLE_ASSERT with the global meson option.
>
>
>
>
-- 
Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com

Re: [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag

[Lukasz Wojciechowski]

W dniu 09.07.2020 o 16:09, Bruce Richardson pisze:
> On Thu, Jul 09, 2020 at 03:51:25PM +0200, Lukasz Wojciechowski wrote:
>> W dniu 26.06.2020 o 18:56, Bruce Richardson pisze:
>>> On Wed, Apr 22, 2020 at 11:45:53PM +0200, Lukasz Wojciechowski wrote:
>>>> A new boolean meson build flag is introduced with this patch: rte_debug.
>>>> To enable this option add -Drte_debug=true to the meson configure command.
>>>>
>>>> By enabling this flag the globaly defined macro RTE_DEBUG becomes
>>>> defined. It should be used for enabling debug code in all dpdk project
>>>> components. Using this flag allows to make additional checks or tests
>>>> and provide additional logs even in performance sensitive parts of code.
>>>>
>>>> The flag is disabled by default.
>>>>
>>>> Additionally for all enabled to be built libraries
>>>> a RTE_DEBUG_{library name} is defined and assigned a value 1.
>>>> This standardize names of library specific debug macros. Those can
>>>> be used also without rte_debug option by using CFLAGS="-D..." build
>>>> parameter.
>>>>
>>>> Code put inside RTE_DEBUG* #ifdef sections should be also put inside
>>>> if (rte_log_can_log(...)) condition to allow run-time filtering of
>>>> sanity checks, validations, logs and dumps when using rte_debug option.
>>>>
>>>> Libraries will be adjusted to the change in separate patches.
>>>>
>>>> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
>>>> Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
>>> The drivers are missing debug flag options, which probably need to be
>>> defined as <driver_type>_<driver_name> e.g. RTE_DEBUG_NET_I40E,
>>> RTE_DEBUG_EVENT_SW, etc.
>> I added also flags for drivers constructed as you suggested (see v3).
>> It might however be a bit tricky to differentiate library debug flags
>> form drivers, e.g.
>> RTE_DEBUG_MEMPOOL (library) vs RTE_DEBUG_MEMPOOL_DPAA (driver).
>>
>> If there is a need the macro names can be changed by adding _LIB_ or _DRV_.
>> What do you think?
> I don't think DRV is needed for the drivers, though perhaps LIB (or RTE) could
> be added for the libs. I actually think that mempool is the only case where
> we might have any confusion, for other device classes the library names
> tend to have "dev" on the end, e.g. cryptodev, rawdev etc.
maybe also with net
>
> So overall, I'd suggest it's not a problem, but if you want modify the lib
> one.

If it's not a problem, I'll leave it as it is for now.

>
> /Bruce
>
-- 
Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com

Re: [dpdk-dev] [PATCH v3 0/4] introduce global debug flag

[Thomas Monjalon]

09/07/2020 15:48, Lukasz Wojciechowski:
> This set of patches introduces a global rte_debug flag for dpdk.
> This will allow easy switch to debug build configuration using a single
> flag. In the debug mode a RTE_DEBUG macro is defined to 1
> and for every enabled to be built library a RTE_DEBUG_{library name}
> and for every enabled to be built driver
> a RTE_DEBUG_{driver_class}_{driver_name} is also defined.
> These macros can be used to place a debug code
> inside #ifdef #endif clauses.
> 
> The following requirements were discussed on the mailing list:
> 1) The global debug flag is required to enable all the sanity checks
> and validations that are normally not used due to performance reasons
> 
> 2) The best option would be to have a single flag - not to introduce
> too many build options
> 
> 3) This option should be separated from meson "debug" option
> (used for build with symbols) and can be called "rte_debug"
> 
> 4) The currently existing DEBUG macros should not be replaced with
> a RTE_DEBUG macro. This would allow to still enable them using
> CFLAGS="-D..." to test a single module (library, driver).

Please can we clarify this point?
You mean not replacing driver macros with the global RTE_DEBUG?
But we agree (next point) to replace existing macros?

> 5) Currently existing options' names should be standardized
> to RTE_DEBUG_{library/driver name}, so they can be automatically enabled
> when rte_debug is set. Standardized names would allow easy usage
> in other modules.
> 
> 6) The debug functionality should be encapsulated in:
>         if (rte_log_can_log(...)) {
>                 ...
>         }
> for possibility to be filtered out in runtime.
> 
> 
> Because of the hot discussion of v1 version of patches, I limit
> the v2 version to mbuf library changes only, to see how it will impact
> the performance with rte_log_can_log usage and to get opinions.
> 
> v3 contains mbuf performance tests, which might help dpdk developers
> community to decide if drop of performance related to rte_log_can_log
> can be accepted.
> 
> If agreement is reached, next steps would be to follow changes
> in other libraries and drivers.

If I understand well, it makes no sense to apply this v3,
without having the rest of the code converted?

Re: [dpdk-dev] [PATCH v3 0/4] introduce global debug flag

[Bruce Richardson]

On Sat, Jul 11, 2020 at 05:11:52PM +0200, Thomas Monjalon wrote:
> 09/07/2020 15:48, Lukasz Wojciechowski:
> > This set of patches introduces a global rte_debug flag for dpdk.
> > This will allow easy switch to debug build configuration using a single
> > flag. In the debug mode a RTE_DEBUG macro is defined to 1
> > and for every enabled to be built library a RTE_DEBUG_{library name}
> > and for every enabled to be built driver
> > a RTE_DEBUG_{driver_class}_{driver_name} is also defined.
> > These macros can be used to place a debug code
> > inside #ifdef #endif clauses.
> > 
> > The following requirements were discussed on the mailing list:
> > 1) The global debug flag is required to enable all the sanity checks
> > and validations that are normally not used due to performance reasons
> > 
> > 2) The best option would be to have a single flag - not to introduce
> > too many build options
> > 
> > 3) This option should be separated from meson "debug" option
> > (used for build with symbols) and can be called "rte_debug"
> > 
> > 4) The currently existing DEBUG macros should not be replaced with
> > a RTE_DEBUG macro. This would allow to still enable them using
> > CFLAGS="-D..." to test a single module (library, driver).
> 
> Please can we clarify this point?
> You mean not replacing driver macros with the global RTE_DEBUG?
> But we agree (next point) to replace existing macros?
> 
> > 5) Currently existing options' names should be standardized
> > to RTE_DEBUG_{library/driver name}, so they can be automatically enabled
> > when rte_debug is set. Standardized names would allow easy usage
> > in other modules.
> > 
> > 6) The debug functionality should be encapsulated in:
> >         if (rte_log_can_log(...)) {
> >                 ...
> >         }
> > for possibility to be filtered out in runtime.
> > 
> > 
> > Because of the hot discussion of v1 version of patches, I limit
> > the v2 version to mbuf library changes only, to see how it will impact
> > the performance with rte_log_can_log usage and to get opinions.
> > 
> > v3 contains mbuf performance tests, which might help dpdk developers
> > community to decide if drop of performance related to rte_log_can_log
> > can be accepted.
> > 
> > If agreement is reached, next steps would be to follow changes
> > in other libraries and drivers.
> 
> If I understand well, it makes no sense to apply this v3,
> without having the rest of the code converted?
> 
I'd nearly take the opposite view, that merging this patchset is a
pre-requisite to converting the rest of the code. By merging this now, it
allows others to work in parallel on any conversion they want to do, rather
than requiring it all to be part of the one patchset.

On the other hand, it would be good to get more buy-in from maintainers
that this does meet their requirements at this point (and if not what could
be changed to make it meet them)

Regards,
/Bruce

Re: [dpdk-dev] [PATCH v3 0/4] introduce global debug flag

[Lukasz Wojciechowski]

W dniu 11.07.2020 o 17:11, Thomas Monjalon pisze:
> 09/07/2020 15:48, Lukasz Wojciechowski:
>> This set of patches introduces a global rte_debug flag for dpdk.
>> This will allow easy switch to debug build configuration using a single
>> flag. In the debug mode a RTE_DEBUG macro is defined to 1
>> and for every enabled to be built library a RTE_DEBUG_{library name}
>> and for every enabled to be built driver
>> a RTE_DEBUG_{driver_class}_{driver_name} is also defined.
>> These macros can be used to place a debug code
>> inside #ifdef #endif clauses.
>>
>> The following requirements were discussed on the mailing list:
>> 1) The global debug flag is required to enable all the sanity checks
>> and validations that are normally not used due to performance reasons
>>
>> 2) The best option would be to have a single flag - not to introduce
>> too many build options
>>
>> 3) This option should be separated from meson "debug" option
>> (used for build with symbols) and can be called "rte_debug"
>>
>> 4) The currently existing DEBUG macros should not be replaced with
>> a RTE_DEBUG macro. This would allow to still enable them using
>> CFLAGS="-D..." to test a single module (library, driver).
> Please can we clarify this point?
> You mean not replacing driver macros with the global RTE_DEBUG?
> But we agree (next point) to replace existing macros?
Yes, I'll try.

This point was added after discussion about using a single RTE_DEBUG 
flag for all debugs.
I think we all agreed that it will be better to keep separate flags for 
separate libraries or drivers instead of using only one RTE_DEBUG flag 
for all debugs.
e.g. in current version of patches there is a flag RTE_DEBUG_MBUF for 
debugs related to librte_mbuf.
This allows to enable only some debugs at compile time passing them to 
CFLAGS.

>> 5) Currently existing options' names should be standardized
>> to RTE_DEBUG_{library/driver name}, so they can be automatically enabled
>> when rte_debug is set. Standardized names would allow easy usage
>> in other modules.
>>
>> 6) The debug functionality should be encapsulated in:
>>          if (rte_log_can_log(...)) {
>>                  ...
>>          }
>> for possibility to be filtered out in runtime.
>>
>>
>> Because of the hot discussion of v1 version of patches, I limit
>> the v2 version to mbuf library changes only, to see how it will impact
>> the performance with rte_log_can_log usage and to get opinions.
>>
>> v3 contains mbuf performance tests, which might help dpdk developers
>> community to decide if drop of performance related to rte_log_can_log
>> can be accepted.
>>
>> If agreement is reached, next steps would be to follow changes
>> in other libraries and drivers.
> If I understand well, it makes no sense to apply this v3,
> without having the rest of the code converted?
>
>
>
>
-- 
Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com

Re: [dpdk-dev] [PATCH v3 0/4] introduce global debug flag

[Lukasz Wojciechowski]

W dniu 13.07.2020 o 11:04, Bruce Richardson pisze:
> On Sat, Jul 11, 2020 at 05:11:52PM +0200, Thomas Monjalon wrote:
>> 09/07/2020 15:48, Lukasz Wojciechowski:
>>> This set of patches introduces a global rte_debug flag for dpdk.
>>> This will allow easy switch to debug build configuration using a single
>>> flag. In the debug mode a RTE_DEBUG macro is defined to 1
>>> and for every enabled to be built library a RTE_DEBUG_{library name}
>>> and for every enabled to be built driver
>>> a RTE_DEBUG_{driver_class}_{driver_name} is also defined.
>>> These macros can be used to place a debug code
>>> inside #ifdef #endif clauses.
>>>
>>> The following requirements were discussed on the mailing list:
>>> 1) The global debug flag is required to enable all the sanity checks
>>> and validations that are normally not used due to performance reasons
>>>
>>> 2) The best option would be to have a single flag - not to introduce
>>> too many build options
>>>
>>> 3) This option should be separated from meson "debug" option
>>> (used for build with symbols) and can be called "rte_debug"
>>>
>>> 4) The currently existing DEBUG macros should not be replaced with
>>> a RTE_DEBUG macro. This would allow to still enable them using
>>> CFLAGS="-D..." to test a single module (library, driver).
>> Please can we clarify this point?
>> You mean not replacing driver macros with the global RTE_DEBUG?
>> But we agree (next point) to replace existing macros?
>>
>>> 5) Currently existing options' names should be standardized
>>> to RTE_DEBUG_{library/driver name}, so they can be automatically enabled
>>> when rte_debug is set. Standardized names would allow easy usage
>>> in other modules.
>>>
>>> 6) The debug functionality should be encapsulated in:
>>>          if (rte_log_can_log(...)) {
>>>                  ...
>>>          }
>>> for possibility to be filtered out in runtime.
>>>
>>>
>>> Because of the hot discussion of v1 version of patches, I limit
>>> the v2 version to mbuf library changes only, to see how it will impact
>>> the performance with rte_log_can_log usage and to get opinions.
>>>
>>> v3 contains mbuf performance tests, which might help dpdk developers
>>> community to decide if drop of performance related to rte_log_can_log
>>> can be accepted.
>>>
>>> If agreement is reached, next steps would be to follow changes
>>> in other libraries and drivers.
>> If I understand well, it makes no sense to apply this v3,
>> without having the rest of the code converted?
>>
> I'd nearly take the opposite view, that merging this patchset is a
> pre-requisite to converting the rest of the code. By merging this now, it
> allows others to work in parallel on any conversion they want to do, rather
> than requiring it all to be part of the one patchset.
>
> On the other hand, it would be good to get more buy-in from maintainers
> that this does meet their requirements at this point (and if not what could
> be changed to make it meet them)
>
> Regards,
> /Bruce
I agree with Bruce. These patches are ready to apply. After they are 
introduced work can be parallelized and done for following libraries and 
drivers.

However the mbuf library was chosen to verify performance of the solution.
I published mbuf performance tests and the results for various 
compilation variants as a reply to former discussion, but there is no 
answer yet.
The most interested person seemed to be Konstantin. Maybe we should wait 
for his opinion.

-- 
Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com

Re: [dpdk-dev] [PATCH v3 0/4] introduce global debug flag

[Stephen Hemminger]

On Tue, 14 Jul 2020 00:39:43 +0200
Lukasz Wojciechowski <l.wojciechow@partner.samsung.com> wrote:

> W dniu 11.07.2020 o 17:11, Thomas Monjalon pisze:
> > 09/07/2020 15:48, Lukasz Wojciechowski:  
> >> This set of patches introduces a global rte_debug flag for dpdk.
> >> This will allow easy switch to debug build configuration using a single
> >> flag. In the debug mode a RTE_DEBUG macro is defined to 1
> >> and for every enabled to be built library a RTE_DEBUG_{library name}
> >> and for every enabled to be built driver
> >> a RTE_DEBUG_{driver_class}_{driver_name} is also defined.
> >> These macros can be used to place a debug code
> >> inside #ifdef #endif clauses.
> >>
> >> The following requirements were discussed on the mailing list:
> >> 1) The global debug flag is required to enable all the sanity checks
> >> and validations that are normally not used due to performance reasons
> >>
> >> 2) The best option would be to have a single flag - not to introduce
> >> too many build options
> >>
> >> 3) This option should be separated from meson "debug" option
> >> (used for build with symbols) and can be called "rte_debug"
> >>
> >> 4) The currently existing DEBUG macros should not be replaced with
> >> a RTE_DEBUG macro. This would allow to still enable them using
> >> CFLAGS="-D..." to test a single module (library, driver).  
> > Please can we clarify this point?
> > You mean not replacing driver macros with the global RTE_DEBUG?
> > But we agree (next point) to replace existing macros?  
> Yes, I'll try.
> 
> This point was added after discussion about using a single RTE_DEBUG 
> flag for all debugs.
> I think we all agreed that it will be better to keep separate flags for 
> separate libraries or drivers instead of using only one RTE_DEBUG flag 
> for all debugs.
> e.g. in current version of patches there is a flag RTE_DEBUG_MBUF for 
> debugs related to librte_mbuf.
> This allows to enable only some debugs at compile time passing them to 
> CFLAGS.

Has anyone investigated doing static branches in userspace?
It might mean doing self-modifying code.
That would allow always keeping/compiling in the debug code but at zero runtime cost.

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Ananyev, Konstantin]

Hi Lukasz,



> I've just pushed v3 with minor fixes and mbuf performance tests. There are 6 very simple tests:

> * alloc_free allocates and frees mbufs from/to mempool one by one

> * bulk_alloc_free does the same but in bulks

> * data_manipulation uses few functions containing sanity checks (is_contiguous, append, trim, prepend, adj)

> * sanity_checks_without_header runs robust sanity checks (with header parameter = 0)

> * sanity_checks_with_header does full  sanity checks (with header parameter = 1)

> * sanity_checks_with_header_in_chain does the same as above, but all mbufs are chained into single list.

> I run those tests in 3 different compilations:

> * debug without_rte_log_can_log - sanity checks not empty, but without runtime checks of rte_log_can_log

> * debug with_rte_log_can_log - debug enabled and runtime checks used

> * no debug - debug mode  disabled - sanity checks are empty macros



Do we have data when debug was enabled at build-time (RTE_DEBUG is on),

but was disabled at run-time (rte_log_can_log() will return zero for mbuf functions)?

That the situation I was concerned about.
Konstantin

Re: [dpdk-dev] [PATCH v3 2/4] config: remove unused config flags

[David Marchand]

On Thu, Jul 9, 2020 at 3:49 PM Lukasz Wojciechowski
<l.wojciechow@partner.samsung.com> wrote:
>
> Following flags were still present in the common_base config,
> but they were not used anywhere in the code:
> * CONFIG_RTE_LIBRTE_ACL_DEBUG
> * CONFIG_RTE_LIBRTE_NFP_DEBUG_TX
> * CONFIG_RTE_LIBRTE_NFP_DEBUG_RX
> * CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO_DEBUG

This could be separated from the rte_debug series.
In the armv8 crypto driver case, it is a typo (Cc: Ruifeng for info).

$ git show 169ca3db55 |grep CRYPTO_DEBUG
+CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO_DEBUG=n
+#ifdef RTE_LIBRTE_ARMV8_CRYPTO_DEBUG


-- 
David Marchand

Re: [dpdk-dev] [PATCH v3 2/4] config: remove unused config flags

[Ruifeng Wang]

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Thursday, July 16, 2020 3:43 PM
> To: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
> Cc: thomas@monjalon.net; dev <dev@dpdk.org>; Ruifeng Wang
> <Ruifeng.Wang@arm.com>
> Subject: Re: [dpdk-dev] [PATCH v3 2/4] config: remove unused config flags
> 
> On Thu, Jul 9, 2020 at 3:49 PM Lukasz Wojciechowski
> <l.wojciechow@partner.samsung.com> wrote:
> >
> > Following flags were still present in the common_base config, but they
> > were not used anywhere in the code:
> > * CONFIG_RTE_LIBRTE_ACL_DEBUG
> > * CONFIG_RTE_LIBRTE_NFP_DEBUG_TX
> > * CONFIG_RTE_LIBRTE_NFP_DEBUG_RX
> > * CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO_DEBUG
> 
> This could be separated from the rte_debug series.
> In the armv8 crypto driver case, it is a typo (Cc: Ruifeng for info).

Yes, the armv8 crypto one is a typo. It should be CONFIG_RTE_LIBRTE_ARMV8_CRYPTO_DEBUG, without PMD.
The configuration is expected to be used by armv8 crypto PMD.
I will send a patch to fix this.

Thanks.
/Ruifeng
> 
> $ git show 169ca3db55 |grep CRYPTO_DEBUG
> +CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO_DEBUG=n
> +#ifdef RTE_LIBRTE_ARMV8_CRYPTO_DEBUG
> 
> 
> --
> David Marchand

Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one

[Stephen Hemminger]

On Mon, 20 Apr 2020 19:34:43 +0200
Lukasz Wojciechowski <l.wojciechow@partner.samsung.com> wrote:

> > Note, this means that you need to ensure all debug printouts from libs and
> > drivers are using the RTE_LOG macros so can be runtime controlled. I think
> > that may be some distance from reality right now.
> >
> > Even if we do want all debug enabled from one flag, I'm still not 100%
> > convinced that the existing debug flag is the way to do, since it only adds
> > debug info to binary without affecting code generation.  
> OK, I see that there are different opinions on what shape the debug flag 
> should look like.
> So I think, I'll hold on work on any implementation until we all agree, 
> what do we want.
> 
> @Bruce: What code generation do you have on mind?

This patchset seems stagnated by good intentions but no later effort.
Agree that having:
  - a global flag for all debugs enabled would be good.
  - CI should do a build with that flag turned on.
  
This will check that debug code actually works and is not so verbose that
it can't run (which is often the case now).

But current patchset doesn't do that.  So leaving final disposition
as "Changes requested" and someone can pick it up if they want to continue.