* [dpdk-dev] [PATCH v1 01/17] config: introduce global debug flag
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 02/17] config: remove unused config flags Lukasz Wojciechowski
` (16 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 02/17] config: remove unused config flags
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 01/17] config: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one Lukasz Wojciechowski
` (15 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 01/17] config: " Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 02/17] config: remove unused config flags Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-20 9:04 ` Dumitrescu, Cristian
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 04/17] eventdev: " Lukasz Wojciechowski
` (14 subsequent siblings)
17 siblings, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon, Igor Russkikh, Pavel Belous, Wenzhuo Lu,
Marcin Wojtas, Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin,
Igor Chauskin, John Daley, Hyong Youb Kim, Qi Zhang, Xiao Wang,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Beilei Xing, Jingjing Wu,
Qiming Yang, Konstantin Ananyev, Rasesh Mody, Shahed Shaikh,
Jasvinder Singh, Cristian Dumitrescu, Maxime Coquelin,
Zhihong Wang, Xiaolong Ye, Yong Wang, Ferruh Yigit,
Andrew Rybchenko, Olivier Matz
Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one Lukasz Wojciechowski
@ 2020-04-20 9:04 ` Dumitrescu, Cristian
2020-04-20 13:37 ` Ananyev, Konstantin
0 siblings, 1 reply; 74+ messages in thread
From: Dumitrescu, Cristian @ 2020-04-20 9:04 UTC (permalink / raw)
To: Lukasz Wojciechowski, Thomas Monjalon, Igor Russkikh,
Pavel Belous, Lu, Wenzhuo, Marcin Wojtas, Michal Krawczyk,
Guy Tzalik, Evgeny Schemeilin, Igor Chauskin, John Daley,
Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W, Ziyang Xuan,
Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier), Min Hu (Connor),
Yisen Zhuang, Xing, Beilei, Wu, Jingjing, Yang, Qiming,
Ananyev, Konstantin, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz
Cc: dev@dpdk.org
> -----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.
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-20 9:04 ` Dumitrescu, Cristian
@ 2020-04-20 13:37 ` Ananyev, Konstantin
2020-04-20 14:21 ` Bruce Richardson
0 siblings, 1 reply; 74+ messages in thread
From: Ananyev, Konstantin @ 2020-04-20 13:37 UTC (permalink / raw)
To: Dumitrescu, Cristian, Lukasz Wojciechowski, Thomas Monjalon,
Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz
Cc: dev@dpdk.org
>
>
>
> > -----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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-20 13:37 ` Ananyev, Konstantin
@ 2020-04-20 14:21 ` Bruce Richardson
2020-04-20 14:43 ` Lukasz Wojciechowski
0 siblings, 1 reply; 74+ messages in thread
From: Bruce Richardson @ 2020-04-20 14:21 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Dumitrescu, Cristian, Lukasz Wojciechowski, Thomas Monjalon,
Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-20 14:21 ` Bruce Richardson
@ 2020-04-20 14:43 ` Lukasz Wojciechowski
2020-04-20 17:11 ` Bruce Richardson
0 siblings, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-20 14:43 UTC (permalink / raw)
To: Bruce Richardson, Ananyev, Konstantin
Cc: Dumitrescu, Cristian, Thomas Monjalon, Igor Russkikh,
Pavel Belous, Lu, Wenzhuo, Marcin Wojtas, Michal Krawczyk,
Guy Tzalik, Evgeny Schemeilin, Igor Chauskin, John Daley,
Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W, Ziyang Xuan,
Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier), Min Hu (Connor),
Yisen Zhuang, Xing, Beilei, Wu, Jingjing, Yang, Qiming,
Rasesh Mody, Shahed Shaikh, Singh, Jasvinder, Maxime Coquelin,
Wang, Zhihong, Ye, Xiaolong, Yong Wang, Yigit, Ferruh,
Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-20 14:43 ` Lukasz Wojciechowski
@ 2020-04-20 17:11 ` Bruce Richardson
2020-04-20 17:21 ` Thomas Monjalon
2020-04-20 17:24 ` Bruce Richardson
0 siblings, 2 replies; 74+ messages in thread
From: Bruce Richardson @ 2020-04-20 17:11 UTC (permalink / raw)
To: Lukasz Wojciechowski
Cc: Ananyev, Konstantin, Dumitrescu, Cristian, Thomas Monjalon,
Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-20 17:11 ` Bruce Richardson
@ 2020-04-20 17:21 ` Thomas Monjalon
2020-04-20 17:30 ` Bruce Richardson
2020-04-20 17:24 ` Bruce Richardson
1 sibling, 1 reply; 74+ messages in thread
From: Thomas Monjalon @ 2020-04-20 17:21 UTC (permalink / raw)
To: Lukasz Wojciechowski, Bruce Richardson, Ananyev, Konstantin,
Dumitrescu, Cristian
Cc: Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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.
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-20 17:21 ` Thomas Monjalon
@ 2020-04-20 17:30 ` Bruce Richardson
2020-04-20 17:34 ` Lukasz Wojciechowski
2020-04-20 17:35 ` Thomas Monjalon
0 siblings, 2 replies; 74+ messages in thread
From: Bruce Richardson @ 2020-04-20 17:30 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Lukasz Wojciechowski, Ananyev, Konstantin, Dumitrescu, Cristian,
Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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.
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-20 17:30 ` Bruce Richardson
@ 2020-04-20 17:34 ` Lukasz Wojciechowski
2023-06-12 16:23 ` Stephen Hemminger
2020-04-20 17:35 ` Thomas Monjalon
1 sibling, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-20 17:34 UTC (permalink / raw)
To: Bruce Richardson, Thomas Monjalon
Cc: Ananyev, Konstantin, Dumitrescu, Cristian, Igor Russkikh,
Pavel Belous, Lu, Wenzhuo, Marcin Wojtas, Michal Krawczyk,
Guy Tzalik, Evgeny Schemeilin, Igor Chauskin, John Daley,
Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W, Ziyang Xuan,
Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier), Min Hu (Connor),
Yisen Zhuang, Xing, Beilei, Wu, Jingjing, Yang, Qiming,
Rasesh Mody, Shahed Shaikh, Singh, Jasvinder, Maxime Coquelin,
Wang, Zhihong, Ye, Xiaolong, Yong Wang, Yigit, Ferruh,
Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-20 17:34 ` Lukasz Wojciechowski
@ 2023-06-12 16:23 ` Stephen Hemminger
0 siblings, 0 replies; 74+ messages in thread
From: Stephen Hemminger @ 2023-06-12 16:23 UTC (permalink / raw)
To: Lukasz Wojciechowski
Cc: Bruce Richardson, Thomas Monjalon, Ananyev, Konstantin,
Dumitrescu, Cristian, Igor Russkikh, Pavel Belous, Lu, Wenzhuo,
Marcin Wojtas, Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin,
Igor Chauskin, John Daley, Hyong Youb Kim, Zhang, Qi Z,
Wang, Xiao W, Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou,
Wei Hu (Xavier), Min Hu (Connor), Yisen Zhuang, Xing, Beilei,
Wu, Jingjing, Yang, Qiming, Rasesh Mody, Shahed Shaikh,
Singh, Jasvinder, Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong,
Yong Wang, Yigit, Ferruh, Andrew Rybchenko, Olivier Matz,
dev@dpdk.org
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-20 17:30 ` Bruce Richardson
2020-04-20 17:34 ` Lukasz Wojciechowski
@ 2020-04-20 17:35 ` Thomas Monjalon
2020-04-20 18:57 ` Bruce Richardson
1 sibling, 1 reply; 74+ messages in thread
From: Thomas Monjalon @ 2020-04-20 17:35 UTC (permalink / raw)
To: Bruce Richardson
Cc: Lukasz Wojciechowski, Ananyev, Konstantin, Dumitrescu, Cristian,
Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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?
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-20 17:35 ` Thomas Monjalon
@ 2020-04-20 18:57 ` Bruce Richardson
2020-04-21 0:32 ` Ananyev, Konstantin
0 siblings, 1 reply; 74+ messages in thread
From: Bruce Richardson @ 2020-04-20 18:57 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Lukasz Wojciechowski, Ananyev, Konstantin, Dumitrescu, Cristian,
Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-20 18:57 ` Bruce Richardson
@ 2020-04-21 0:32 ` Ananyev, Konstantin
2020-04-21 20:58 ` Lukasz Wojciechowski
0 siblings, 1 reply; 74+ messages in thread
From: Ananyev, Konstantin @ 2020-04-21 0:32 UTC (permalink / raw)
To: Richardson, Bruce, Thomas Monjalon
Cc: Lukasz Wojciechowski, Dumitrescu, Cristian, Igor Russkikh,
Pavel Belous, Lu, Wenzhuo, Marcin Wojtas, Michal Krawczyk,
Guy Tzalik, Evgeny Schemeilin, Igor Chauskin, John Daley,
Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W, Ziyang Xuan,
Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier), Min Hu (Connor),
Yisen Zhuang, Xing, Beilei, Wu, Jingjing, Yang, Qiming,
Rasesh Mody, Shahed Shaikh, Singh, Jasvinder, Maxime Coquelin,
Wang, Zhihong, Ye, Xiaolong, Yong Wang, Yigit, Ferruh,
Andrew Rybchenko, Olivier Matz, dev@dpdk.org
> > > > > > >> 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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-21 0:32 ` Ananyev, Konstantin
@ 2020-04-21 20:58 ` Lukasz Wojciechowski
2020-04-21 21:38 ` Thomas Monjalon
0 siblings, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-21 20:58 UTC (permalink / raw)
To: Ananyev, Konstantin, Richardson, Bruce, Thomas Monjalon,
Dumitrescu, Cristian
Cc: Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-21 20:58 ` Lukasz Wojciechowski
@ 2020-04-21 21:38 ` Thomas Monjalon
2020-04-22 10:41 ` Lukasz Wojciechowski
0 siblings, 1 reply; 74+ messages in thread
From: Thomas Monjalon @ 2020-04-21 21:38 UTC (permalink / raw)
To: Ananyev, Konstantin, Richardson, Bruce, Dumitrescu, Cristian,
Lukasz Wojciechowski
Cc: Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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!
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-21 21:38 ` Thomas Monjalon
@ 2020-04-22 10:41 ` Lukasz Wojciechowski
2020-04-22 10:55 ` Bruce Richardson
0 siblings, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-22 10:41 UTC (permalink / raw)
To: Thomas Monjalon, Ananyev, Konstantin, Richardson, Bruce,
Dumitrescu, Cristian
Cc: Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-22 10:41 ` Lukasz Wojciechowski
@ 2020-04-22 10:55 ` Bruce Richardson
2020-04-22 11:02 ` Thomas Monjalon
0 siblings, 1 reply; 74+ messages in thread
From: Bruce Richardson @ 2020-04-22 10:55 UTC (permalink / raw)
To: Lukasz Wojciechowski
Cc: Thomas Monjalon, Ananyev, Konstantin, Dumitrescu, Cristian,
Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-22 10:55 ` Bruce Richardson
@ 2020-04-22 11:02 ` Thomas Monjalon
2020-04-22 11:16 ` Bruce Richardson
` (2 more replies)
0 siblings, 3 replies; 74+ messages in thread
From: Thomas Monjalon @ 2020-04-22 11:02 UTC (permalink / raw)
To: Lukasz Wojciechowski, Bruce Richardson
Cc: Ananyev, Konstantin, Dumitrescu, Cristian, Igor Russkikh,
Pavel Belous, Lu, Wenzhuo, Marcin Wojtas, Michal Krawczyk,
Guy Tzalik, Evgeny Schemeilin, Igor Chauskin, John Daley,
Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W, Ziyang Xuan,
Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier), Min Hu (Connor),
Yisen Zhuang, Xing, Beilei, Wu, Jingjing, Yang, Qiming,
Rasesh Mody, Shahed Shaikh, Singh, Jasvinder, Maxime Coquelin,
Wang, Zhihong, Ye, Xiaolong, Yong Wang, Yigit, Ferruh,
Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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(...)
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-22 11:02 ` Thomas Monjalon
@ 2020-04-22 11:16 ` Bruce Richardson
2020-04-22 11:29 ` Ananyev, Konstantin
2020-04-22 11:52 ` Lukasz Wojciechowski
2 siblings, 0 replies; 74+ messages in thread
From: Bruce Richardson @ 2020-04-22 11:16 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Lukasz Wojciechowski, Ananyev, Konstantin, Dumitrescu, Cristian,
Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-22 11:02 ` Thomas Monjalon
2020-04-22 11:16 ` Bruce Richardson
@ 2020-04-22 11:29 ` Ananyev, Konstantin
2020-04-22 12:24 ` Thomas Monjalon
2020-04-22 11:52 ` Lukasz Wojciechowski
2 siblings, 1 reply; 74+ messages in thread
From: Ananyev, Konstantin @ 2020-04-22 11:29 UTC (permalink / raw)
To: Thomas Monjalon, Lukasz Wojciechowski, Richardson, Bruce
Cc: Dumitrescu, Cristian, Igor Russkikh, Pavel Belous, Lu, Wenzhuo,
Marcin Wojtas, Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin,
Igor Chauskin, John Daley, Hyong Youb Kim, Zhang, Qi Z,
Wang, Xiao W, Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou,
Wei Hu (Xavier), Min Hu (Connor), Yisen Zhuang, Xing, Beilei,
Wu, Jingjing, Yang, Qiming, Rasesh Mody, Shahed Shaikh,
Singh, Jasvinder, Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong,
Yong Wang, Yigit, Ferruh, Andrew Rybchenko, Olivier Matz,
dev@dpdk.org
>
> 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.)
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-22 11:29 ` Ananyev, Konstantin
@ 2020-04-22 12:24 ` Thomas Monjalon
2020-07-09 14:09 ` Lukasz Wojciechowski
0 siblings, 1 reply; 74+ messages in thread
From: Thomas Monjalon @ 2020-04-22 12:24 UTC (permalink / raw)
To: Lukasz Wojciechowski, Richardson, Bruce, Ananyev, Konstantin
Cc: Dumitrescu, Cristian, Igor Russkikh, Pavel Belous, Lu, Wenzhuo,
Marcin Wojtas, Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin,
Igor Chauskin, John Daley, Hyong Youb Kim, Zhang, Qi Z,
Wang, Xiao W, Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou,
Wei Hu (Xavier), Min Hu (Connor), Yisen Zhuang, Xing, Beilei,
Wu, Jingjing, Yang, Qiming, Rasesh Mody, Shahed Shaikh,
Singh, Jasvinder, Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong,
Yong Wang, Yigit, Ferruh, Andrew Rybchenko, Olivier Matz,
dev@dpdk.org
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.
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-22 12:24 ` Thomas Monjalon
@ 2020-07-09 14:09 ` Lukasz Wojciechowski
2020-07-14 10:30 ` Ananyev, Konstantin
0 siblings, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-07-09 14:09 UTC (permalink / raw)
To: Thomas Monjalon, Richardson, Bruce, Ananyev, Konstantin
Cc: Dumitrescu, Cristian, Igor Russkikh, Pavel Belous, Lu, Wenzhuo,
Marcin Wojtas, Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin,
Igor Chauskin, John Daley, Hyong Youb Kim, Zhang, Qi Z,
Wang, Xiao W, Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou,
Wei Hu (Xavier), Min Hu (Connor), Yisen Zhuang, Xing, Beilei,
Wu, Jingjing, Yang, Qiming, Rasesh Mody, Shahed Shaikh,
Singh, Jasvinder, Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong,
Yong Wang, Yigit, Ferruh, Andrew Rybchenko, Olivier Matz,
dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-07-09 14:09 ` Lukasz Wojciechowski
@ 2020-07-14 10:30 ` Ananyev, Konstantin
0 siblings, 0 replies; 74+ messages in thread
From: Ananyev, Konstantin @ 2020-07-14 10:30 UTC (permalink / raw)
To: Lukasz Wojciechowski, Thomas Monjalon, Richardson, Bruce
Cc: Dumitrescu, Cristian, Igor Russkikh, Pavel Belous, Lu, Wenzhuo,
Marcin Wojtas, Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin,
Igor Chauskin, John Daley, Hyong Youb Kim, Zhang, Qi Z,
Wang, Xiao W, Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou,
Wei Hu (Xavier), Min Hu (Connor), Yisen Zhuang, Xing, Beilei,
Wu, Jingjing, Yang, Qiming, Rasesh Mody, Shahed Shaikh,
Singh, Jasvinder, Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong,
Yong Wang, Yigit, Ferruh, Andrew Rybchenko, Olivier Matz,
dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-22 11:02 ` Thomas Monjalon
2020-04-22 11:16 ` Bruce Richardson
2020-04-22 11:29 ` Ananyev, Konstantin
@ 2020-04-22 11:52 ` Lukasz Wojciechowski
2020-04-22 12:44 ` Bruce Richardson
2 siblings, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-22 11:52 UTC (permalink / raw)
To: Thomas Monjalon, Bruce Richardson
Cc: Ananyev, Konstantin, Dumitrescu, Cristian, Igor Russkikh,
Pavel Belous, Lu, Wenzhuo, Marcin Wojtas, Michal Krawczyk,
Guy Tzalik, Evgeny Schemeilin, Igor Chauskin, John Daley,
Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W, Ziyang Xuan,
Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier), Min Hu (Connor),
Yisen Zhuang, Xing, Beilei, Wu, Jingjing, Yang, Qiming,
Rasesh Mody, Shahed Shaikh, Singh, Jasvinder, Maxime Coquelin,
Wang, Zhihong, Ye, Xiaolong, Yong Wang, Yigit, Ferruh,
Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-22 11:52 ` Lukasz Wojciechowski
@ 2020-04-22 12:44 ` Bruce Richardson
0 siblings, 0 replies; 74+ messages in thread
From: Bruce Richardson @ 2020-04-22 12:44 UTC (permalink / raw)
To: Lukasz Wojciechowski
Cc: Thomas Monjalon, Ananyev, Konstantin, Dumitrescu, Cristian,
Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one
2020-04-20 17:11 ` Bruce Richardson
2020-04-20 17:21 ` Thomas Monjalon
@ 2020-04-20 17:24 ` Bruce Richardson
1 sibling, 0 replies; 74+ messages in thread
From: Bruce Richardson @ 2020-04-20 17:24 UTC (permalink / raw)
To: Lukasz Wojciechowski
Cc: Ananyev, Konstantin, Dumitrescu, Cristian, Thomas Monjalon,
Igor Russkikh, Pavel Belous, Lu, Wenzhuo, Marcin Wojtas,
Michal Krawczyk, Guy Tzalik, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Zhang, Qi Z, Wang, Xiao W,
Ziyang Xuan, Xiaoyun Wang, Guoyang Zhou, Wei Hu (Xavier),
Min Hu (Connor), Yisen Zhuang, Xing, Beilei, Wu, Jingjing,
Yang, Qiming, Rasesh Mody, Shahed Shaikh, Singh, Jasvinder,
Maxime Coquelin, Wang, Zhihong, Ye, Xiaolong, Yong Wang,
Yigit, Ferruh, Andrew Rybchenko, Olivier Matz, dev@dpdk.org
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* [dpdk-dev] [PATCH v1 04/17] eventdev: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (2 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-18 9:41 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 05/17] fib: " Lukasz Wojciechowski
` (13 subsequent siblings)
17 siblings, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon, Nikhil Rao, Jerin Jacob, Erik Gabriel Carrillo; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [EXT] [PATCH v1 04/17] eventdev: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 04/17] eventdev: " Lukasz Wojciechowski
@ 2020-04-18 9:41 ` Jerin Jacob Kollanukkaran
2020-04-18 9:53 ` Thomas Monjalon
0 siblings, 1 reply; 74+ messages in thread
From: Jerin Jacob Kollanukkaran @ 2020-04-18 9:41 UTC (permalink / raw)
To: Lukasz Wojciechowski, Thomas Monjalon, Nikhil Rao,
Erik Gabriel Carrillo
Cc: dev@dpdk.org
> -----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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [EXT] [PATCH v1 04/17] eventdev: replace library debug flag with global one
2020-04-18 9:41 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
@ 2020-04-18 9:53 ` Thomas Monjalon
2020-04-18 10:05 ` Jerin Jacob
0 siblings, 1 reply; 74+ messages in thread
From: Thomas Monjalon @ 2020-04-18 9:53 UTC (permalink / raw)
To: Lukasz Wojciechowski, Nikhil Rao, Erik Gabriel Carrillo,
Jerin Jacob Kollanukkaran
Cc: dev@dpdk.org
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [EXT] [PATCH v1 04/17] eventdev: replace library debug flag with global one
2020-04-18 9:53 ` Thomas Monjalon
@ 2020-04-18 10:05 ` Jerin Jacob
2020-04-18 13:22 ` Thomas Monjalon
0 siblings, 1 reply; 74+ messages in thread
From: Jerin Jacob @ 2020-04-18 10:05 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Lukasz Wojciechowski, Nikhil Rao, Erik Gabriel Carrillo,
Jerin Jacob Kollanukkaran, dev@dpdk.org
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.
>
>
>
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [EXT] [PATCH v1 04/17] eventdev: replace library debug flag with global one
2020-04-18 10:05 ` Jerin Jacob
@ 2020-04-18 13:22 ` Thomas Monjalon
0 siblings, 0 replies; 74+ messages in thread
From: Thomas Monjalon @ 2020-04-18 13:22 UTC (permalink / raw)
To: Jerin Jacob
Cc: Lukasz Wojciechowski, Nikhil Rao, Erik Gabriel Carrillo,
Jerin Jacob Kollanukkaran, dev@dpdk.org
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* [dpdk-dev] [PATCH v1 05/17] fib: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (3 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 04/17] eventdev: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 06/17] cmdline: " Lukasz Wojciechowski
` (12 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon, Vladimir Medvedkin; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 06/17] cmdline: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (4 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 05/17] fib: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 07/17] hash: " Lukasz Wojciechowski
` (11 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon, Olivier Matz; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 07/17] hash: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (5 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 06/17] cmdline: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 08/17] ip_frag: " Lukasz Wojciechowski
` (10 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon, Yipeng Wang, Sameh Gobriel, Bruce Richardson; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 08/17] ip_frag: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (6 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 07/17] hash: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 09/17] lpm: " Lukasz Wojciechowski
` (9 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon, Konstantin Ananyev, John McNamara,
Marko Kovacevic; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 09/17] lpm: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (7 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 08/17] ip_frag: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 10/17] mbuf: " Lukasz Wojciechowski
` (8 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Bruce Richardson, Vladimir Medvedkin, Thomas Monjalon; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 10/17] mbuf: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (8 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 09/17] lpm: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 11/17] mempool: " Lukasz Wojciechowski
` (7 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Olivier Matz, Thomas Monjalon, John McNamara, Marko Kovacevic; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 11/17] mempool: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (9 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 10/17] mbuf: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 12/17] power: " Lukasz Wojciechowski
` (6 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon, Olivier Matz, Andrew Rybchenko, John McNamara,
Marko Kovacevic
Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 12/17] power: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (10 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 11/17] mempool: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 13/17] rcu: " Lukasz Wojciechowski
` (5 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon, David Hunt; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 13/17] rcu: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (11 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 12/17] power: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 14/17] timer: " Lukasz Wojciechowski
` (4 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon, Honnappa Nagarahalli, John McNamara,
Marko Kovacevic; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 14/17] timer: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (12 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 13/17] rcu: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 15/17] vhost: " Lukasz Wojciechowski
` (3 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Robert Sanford, Erik Gabriel Carrillo, Thomas Monjalon; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 15/17] vhost: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (13 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 14/17] timer: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 16/17] eal: " Lukasz Wojciechowski
` (2 subsequent siblings)
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon, Maxime Coquelin, Zhihong Wang, Xiaolong Ye; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 16/17] eal: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (14 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 15/17] vhost: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 17/17] sched: " Lukasz Wojciechowski
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 0/3] introduce global debug flag Lukasz Wojciechowski
17 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Anatoly Burakov, Thomas Monjalon, John McNamara, Marko Kovacevic; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v1 17/17] sched: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (15 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 16/17] eal: " Lukasz Wojciechowski
@ 2020-04-17 21:57 ` Lukasz Wojciechowski
2020-04-20 9:04 ` Dumitrescu, Cristian
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 0/3] introduce global debug flag Lukasz Wojciechowski
17 siblings, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-17 21:57 UTC (permalink / raw)
To: Thomas Monjalon, Cristian Dumitrescu, Jasvinder Singh; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v1 17/17] sched: replace library debug flag with global one
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 17/17] sched: " Lukasz Wojciechowski
@ 2020-04-20 9:04 ` Dumitrescu, Cristian
0 siblings, 0 replies; 74+ messages in thread
From: Dumitrescu, Cristian @ 2020-04-20 9:04 UTC (permalink / raw)
To: Lukasz Wojciechowski, Thomas Monjalon, Singh, Jasvinder; +Cc: dev@dpdk.org
> -----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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* [dpdk-dev] [PATCH v2 0/3] introduce global debug flag
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 00/17] introduce global debug flag Lukasz Wojciechowski
` (16 preceding siblings ...)
2020-04-17 21:57 ` [dpdk-dev] [PATCH v1 17/17] sched: " Lukasz Wojciechowski
@ 2020-04-22 21:45 ` Lukasz Wojciechowski
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 1/3] config: introduce global rte " Lukasz Wojciechowski
` (4 more replies)
17 siblings, 5 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-22 21:45 UTC (permalink / raw)
Cc: dev
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
^ permalink raw reply [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 0/3] introduce global debug flag Lukasz Wojciechowski
@ 2020-04-22 21:45 ` Lukasz Wojciechowski
2020-06-26 16:56 ` Bruce Richardson
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 2/3] config: remove unused config flags Lukasz Wojciechowski
` (3 subsequent siblings)
4 siblings, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-22 21:45 UTC (permalink / raw)
To: Thomas Monjalon, Bruce Richardson; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 1/3] config: introduce global rte " Lukasz Wojciechowski
@ 2020-06-26 16:56 ` Bruce Richardson
2020-06-28 8:40 ` Andrew Rybchenko
2020-07-09 13:51 ` Lukasz Wojciechowski
0 siblings, 2 replies; 74+ messages in thread
From: Bruce Richardson @ 2020-06-26 16:56 UTC (permalink / raw)
To: Lukasz Wojciechowski; +Cc: Thomas Monjalon, dev
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>
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag
2020-06-26 16:56 ` Bruce Richardson
@ 2020-06-28 8:40 ` Andrew Rybchenko
2020-07-09 13:51 ` Lukasz Wojciechowski
1 sibling, 0 replies; 74+ messages in thread
From: Andrew Rybchenko @ 2020-06-28 8:40 UTC (permalink / raw)
To: Bruce Richardson, Lukasz Wojciechowski; +Cc: Thomas Monjalon, dev
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>
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag
2020-06-26 16:56 ` Bruce Richardson
2020-06-28 8:40 ` Andrew Rybchenko
@ 2020-07-09 13:51 ` Lukasz Wojciechowski
2020-07-09 14:09 ` Bruce Richardson
1 sibling, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-07-09 13:51 UTC (permalink / raw)
To: Bruce Richardson
Cc: Thomas Monjalon, dev, "'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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag
2020-07-09 13:51 ` Lukasz Wojciechowski
@ 2020-07-09 14:09 ` Bruce Richardson
2020-07-09 14:13 ` Lukasz Wojciechowski
0 siblings, 1 reply; 74+ messages in thread
From: Bruce Richardson @ 2020-07-09 14:09 UTC (permalink / raw)
To: Lukasz Wojciechowski; +Cc: Thomas Monjalon, dev
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag
2020-07-09 14:09 ` Bruce Richardson
@ 2020-07-09 14:13 ` Lukasz Wojciechowski
0 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-07-09 14:13 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Thomas Monjalon, dev
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* [dpdk-dev] [PATCH v2 2/3] config: remove unused config flags
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 0/3] introduce global debug flag Lukasz Wojciechowski
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 1/3] config: introduce global rte " Lukasz Wojciechowski
@ 2020-04-22 21:45 ` Lukasz Wojciechowski
2020-06-26 16:56 ` Bruce Richardson
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 3/3] mbuf: standardize library debug flag Lukasz Wojciechowski
` (2 subsequent siblings)
4 siblings, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-22 21:45 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 2/3] config: remove unused config flags
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 2/3] config: remove unused config flags Lukasz Wojciechowski
@ 2020-06-26 16:56 ` Bruce Richardson
0 siblings, 0 replies; 74+ messages in thread
From: Bruce Richardson @ 2020-06-26 16:56 UTC (permalink / raw)
To: Lukasz Wojciechowski; +Cc: Thomas Monjalon, dev
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>
^ permalink raw reply [flat|nested] 74+ messages in thread
* [dpdk-dev] [PATCH v2 3/3] mbuf: standardize library debug flag
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 0/3] introduce global debug flag Lukasz Wojciechowski
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 1/3] config: introduce global rte " Lukasz Wojciechowski
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 2/3] config: remove unused config flags Lukasz Wojciechowski
@ 2020-04-22 21:45 ` Lukasz Wojciechowski
2020-06-26 17:00 ` Bruce Richardson
2020-04-24 9:09 ` [dpdk-dev] [PATCH v2 0/3] introduce global " Bruce Richardson
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 0/4] " Lukasz Wojciechowski
4 siblings, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-22 21:45 UTC (permalink / raw)
To: Olivier Matz, Thomas Monjalon, John McNamara, Marko Kovacevic; +Cc: dev
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 3/3] mbuf: standardize library debug flag
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 3/3] mbuf: standardize library debug flag Lukasz Wojciechowski
@ 2020-06-26 17:00 ` Bruce Richardson
2020-07-09 13:50 ` Lukasz Wojciechowski
0 siblings, 1 reply; 74+ messages in thread
From: Bruce Richardson @ 2020-06-26 17:00 UTC (permalink / raw)
To: Lukasz Wojciechowski
Cc: Olivier Matz, Thomas Monjalon, John McNamara, Marko Kovacevic,
dev
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 3/3] mbuf: standardize library debug flag
2020-06-26 17:00 ` Bruce Richardson
@ 2020-07-09 13:50 ` Lukasz Wojciechowski
0 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-07-09 13:50 UTC (permalink / raw)
To: Bruce Richardson
Cc: Olivier Matz, Thomas Monjalon, John McNamara, Marko Kovacevic,
dev, "'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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v2 0/3] introduce global debug flag
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 0/3] introduce global debug flag Lukasz Wojciechowski
` (2 preceding siblings ...)
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 3/3] mbuf: standardize library debug flag Lukasz Wojciechowski
@ 2020-04-24 9:09 ` Bruce Richardson
2020-04-24 10:14 ` Lukasz Wojciechowski
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 0/4] " Lukasz Wojciechowski
4 siblings, 1 reply; 74+ messages in thread
From: Bruce Richardson @ 2020-04-24 9:09 UTC (permalink / raw)
To: Lukasz Wojciechowski; +Cc: dev
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.
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v2 0/3] introduce global debug flag
2020-04-24 9:09 ` [dpdk-dev] [PATCH v2 0/3] introduce global " Bruce Richardson
@ 2020-04-24 10:14 ` Lukasz Wojciechowski
0 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-24 10:14 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* [dpdk-dev] [PATCH v3 0/4] introduce global debug flag
2020-04-22 21:45 ` [dpdk-dev] [PATCH v2 0/3] introduce global debug flag Lukasz Wojciechowski
` (3 preceding siblings ...)
2020-04-24 9:09 ` [dpdk-dev] [PATCH v2 0/3] introduce global " Bruce Richardson
@ 2020-07-09 13:48 ` Lukasz Wojciechowski
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 1/4] config: introduce global rte " Lukasz Wojciechowski
` (4 more replies)
4 siblings, 5 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-07-09 13:48 UTC (permalink / raw)
Cc: dev, l.wojciechow
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
^ permalink raw reply [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v3 1/4] config: introduce global rte debug flag
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 0/4] " Lukasz Wojciechowski
@ 2020-07-09 13:48 ` Lukasz Wojciechowski
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 2/4] config: remove unused config flags Lukasz Wojciechowski
` (3 subsequent siblings)
4 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-07-09 13:48 UTC (permalink / raw)
To: Thomas Monjalon, Nicolas Chautru, Fiona Trahe, Ashish Gupta,
Bruce Richardson
Cc: dev, l.wojciechow
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v3 2/4] config: remove unused config flags
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 0/4] " Lukasz Wojciechowski
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 1/4] config: introduce global rte " Lukasz Wojciechowski
@ 2020-07-09 13:48 ` Lukasz Wojciechowski
2020-07-16 7:43 ` David Marchand
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 3/4] mbuf: standardize library debug flag Lukasz Wojciechowski
` (2 subsequent siblings)
4 siblings, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-07-09 13:48 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, l.wojciechow
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v3 2/4] config: remove unused config flags
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 2/4] config: remove unused config flags Lukasz Wojciechowski
@ 2020-07-16 7:43 ` David Marchand
2020-07-16 8:41 ` Ruifeng Wang
0 siblings, 1 reply; 74+ messages in thread
From: David Marchand @ 2020-07-16 7:43 UTC (permalink / raw)
To: Lukasz Wojciechowski
Cc: Thomas Monjalon, dev, Ruifeng Wang (Arm Technology China)
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v3 2/4] config: remove unused config flags
2020-07-16 7:43 ` David Marchand
@ 2020-07-16 8:41 ` Ruifeng Wang
0 siblings, 0 replies; 74+ messages in thread
From: Ruifeng Wang @ 2020-07-16 8:41 UTC (permalink / raw)
To: David Marchand, Lukasz Wojciechowski; +Cc: thomas@monjalon.net, dev, nd
> -----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
^ permalink raw reply [flat|nested] 74+ messages in thread
* [dpdk-dev] [PATCH v3 3/4] mbuf: standardize library debug flag
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 0/4] " Lukasz Wojciechowski
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 1/4] config: introduce global rte " Lukasz Wojciechowski
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 2/4] config: remove unused config flags Lukasz Wojciechowski
@ 2020-07-09 13:48 ` Lukasz Wojciechowski
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 4/4] app/test: add mbuf perf tests Lukasz Wojciechowski
2020-07-11 15:11 ` [dpdk-dev] [PATCH v3 0/4] introduce global debug flag Thomas Monjalon
4 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-07-09 13:48 UTC (permalink / raw)
To: Olivier Matz, Thomas Monjalon, John McNamara, Marko Kovacevic
Cc: dev, l.wojciechow
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* [dpdk-dev] [PATCH v3 4/4] app/test: add mbuf perf tests
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 0/4] " Lukasz Wojciechowski
` (2 preceding siblings ...)
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 3/4] mbuf: standardize library debug flag Lukasz Wojciechowski
@ 2020-07-09 13:48 ` Lukasz Wojciechowski
2020-07-11 15:11 ` [dpdk-dev] [PATCH v3 0/4] introduce global debug flag Thomas Monjalon
4 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-07-09 13:48 UTC (permalink / raw)
Cc: dev, l.wojciechow
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
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v3 0/4] introduce global debug flag
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 0/4] " Lukasz Wojciechowski
` (3 preceding siblings ...)
2020-07-09 13:48 ` [dpdk-dev] [PATCH v3 4/4] app/test: add mbuf perf tests Lukasz Wojciechowski
@ 2020-07-11 15:11 ` Thomas Monjalon
2020-07-13 9:04 ` Bruce Richardson
2020-07-13 22:39 ` Lukasz Wojciechowski
4 siblings, 2 replies; 74+ messages in thread
From: Thomas Monjalon @ 2020-07-11 15:11 UTC (permalink / raw)
To: Lukasz Wojciechowski; +Cc: dev, bruce.richardson, david.marchand
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?
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v3 0/4] introduce global debug flag
2020-07-11 15:11 ` [dpdk-dev] [PATCH v3 0/4] introduce global debug flag Thomas Monjalon
@ 2020-07-13 9:04 ` Bruce Richardson
2020-07-13 22:44 ` Lukasz Wojciechowski
2020-07-13 22:39 ` Lukasz Wojciechowski
1 sibling, 1 reply; 74+ messages in thread
From: Bruce Richardson @ 2020-07-13 9:04 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Lukasz Wojciechowski, dev, david.marchand
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v3 0/4] introduce global debug flag
2020-07-13 9:04 ` Bruce Richardson
@ 2020-07-13 22:44 ` Lukasz Wojciechowski
0 siblings, 0 replies; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-07-13 22:44 UTC (permalink / raw)
To: Bruce Richardson, Thomas Monjalon; +Cc: dev, david.marchand, Konstantin Ananyev
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [dpdk-dev] [PATCH v3 0/4] introduce global debug flag
2020-07-11 15:11 ` [dpdk-dev] [PATCH v3 0/4] introduce global debug flag Thomas Monjalon
2020-07-13 9:04 ` Bruce Richardson
@ 2020-07-13 22:39 ` Lukasz Wojciechowski
2020-07-14 1:23 ` Stephen Hemminger
1 sibling, 1 reply; 74+ messages in thread
From: Lukasz Wojciechowski @ 2020-07-13 22:39 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, bruce.richardson, david.marchand
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
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [dpdk-dev] [PATCH v3 0/4] introduce global debug flag
2020-07-13 22:39 ` Lukasz Wojciechowski
@ 2020-07-14 1:23 ` Stephen Hemminger
0 siblings, 0 replies; 74+ messages in thread
From: Stephen Hemminger @ 2020-07-14 1:23 UTC (permalink / raw)
To: Lukasz Wojciechowski
Cc: Thomas Monjalon, dev, bruce.richardson, david.marchand
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.
^ permalink raw reply [flat|nested] 74+ messages in thread