diff mbox series

config: remove explicit undef of unset values

Message ID 20211216111430.699717-1-bruce.richardson@intel.com (mailing list archive)
State New
Delegated to: David Marchand
Headers show
Series config: remove explicit undef of unset values | expand

Checks

Context Check Description
ci/intel-Testing success Testing PASS
ci/Intel-compilation success Compilation OK
ci/iol-intel-Performance success Performance Testing PASS
ci/github-robot: build success github build: passed
ci/iol-aarch64-compile-testing success Testing PASS
ci/iol-aarch64-unit-testing success Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-x86_64-compile-testing success Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-x86_64-unit-testing success Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS
ci/checkpatch warning coding style issues

Commit Message

Bruce Richardson Dec. 16, 2021, 11:14 a.m. UTC
Rather than explicitly clearing any setting of undefined values in our
rte_config.h file, it's better to instead just add a comment that the
value is not set. Using a comment allows the user to set the value using
CFLAGS or similar mechanism without the config file clearing the value
again.

The text used "<VALUE> is not set" is modelled after the kernel approach
of doing the same thing.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---

Although DPDK coding convention forbids use of "//" for comments, using
regular C comment style makes the config settings less clear, as they can
be confused with regular comments in the file. Using "//" makes them stand
out better, so I prefer it. However, if others feel strongly, they can be
changed to standard.

Note: this is a resubmission of patch [1] which was part of a rejected
series. However, the reasons for rejection - values in config being out
of sync with those used for building apps - are less relevant for
many, if not all, of these setting, so I believe the benefits for
testing outweigh the potential downsides. If any setting is likely
problematic, I can keep the explicit undef for that case in a new patch
version.

[1] http://patches.dpdk.org/project/dpdk/patch/20200903144942.671870-2-bruce.richardson@intel.com/
---
 config/rte_config.h | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)
diff mbox series

Patch

diff --git a/config/rte_config.h b/config/rte_config.h
index cab4390a97..953216babd 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -83,17 +83,17 @@ 
 
 /* ip_fragmentation defines */
 #define RTE_LIBRTE_IP_FRAG_MAX_FRAG 8
-#undef RTE_LIBRTE_IP_FRAG_TBL_STAT
+// RTE_LIBRTE_IP_FRAG_TBL_STAT is not set
 
 /* rte_power defines */
 #define RTE_MAX_LCORE_FREQS 64
 
 /* rte_sched defines */
-#undef RTE_SCHED_CMAN
-#undef RTE_SCHED_COLLECT_STATS
-#undef RTE_SCHED_SUBPORT_TC_OV
+// RTE_SCHED_CMAN is not set
+// RTE_SCHED_COLLECT_STATS is not set
+// RTE_SCHED_SUBPORT_TC_OV is not set
 #define RTE_SCHED_PORT_N_GRINDERS 8
-#undef RTE_SCHED_VECTOR
+// RTE_SCHED_VECTOR is not set
 
 /* KNI defines */
 #define RTE_KNI_PREEMPT_DEFAULT 1
@@ -127,7 +127,7 @@ 
 
 /* i40e defines */
 #define RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC 1
-#undef RTE_LIBRTE_I40E_16BYTE_RX_DESC
+// RTE_LIBRTE_I40E_16BYTE_RX_DESC is not set
 #define RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF 64
 #define RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF 4
 #define RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM 4
@@ -140,6 +140,6 @@ 
 #define RTE_LIBRTE_QEDE_FW ""
 
 /* DLB2 defines */
-#undef RTE_LIBRTE_PMD_DLB2_QUELL_STATS
+// RTE_LIBRTE_PMD_DLB2_QUELL_STATS is not set
 
 #endif /* _RTE_CONFIG_H_ */