Eliminate zero length arrays in DPDK
Subsystems (4)
cover Eliminate zero length arrays in DPDK
Yet another case of applying Linux kernel best practices to DPDK. Flexible arrays are supported by Clang, GCC and Microsoft compilers (part of C99).
Stephen Hemminger (2):
devtools: add script to check for zero length array
treewide: replace zero-length array with flex array
app/test/test_table_tables.c | 2 +- devtools/cocci/zerolengtharray.cocci | 17 +++++++++++++++++ drivers/bus/dpaa/include/netcfg.h | 4 ++-- drivers/common/cnxk/roc_se.h | 2 +- drivers/common/dpaax/caamflib/desc/ipsec.h | 2 +- drivers/common/dpaax/dpaax_iova_table.h | 2 +- drivers/common/mlx5/mlx5_prm.h | 8 ++++---- drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 2 +- drivers/crypto/ipsec_mb/ipsec_mb_private.h | 4 ++-- drivers/crypto/virtio/virtio_ring.h | 4 ++-- drivers/crypto/virtio/virtqueue.h | 2 +- drivers/net/cxgbe/clip_tbl.h | 2 +- drivers/net/cxgbe/l2t.h | 2 +- drivers/net/cxgbe/mps_tcam.h | 2 +- drivers/net/cxgbe/smt.h | 2 +- drivers/net/enic/base/vnic_devcmd.h | 4 ++-- drivers/net/hinic/hinic_pmd_tx.h | 2 +- drivers/net/nfp/nfpcore/nfp_nsp.h | 2 +- drivers/net/virtio/virtio_ring.h | 4 ++-- drivers/net/virtio/virtio_user/vhost_kernel.c | 2 +- drivers/net/virtio/virtio_user/vhost_vdpa.c | 2 +- drivers/net/virtio/virtqueue.h | 2 +- drivers/regex/mlx5/mlx5_rxp.h | 2 +- examples/ip_reassembly/main.c | 2 +- lib/cryptodev/cryptodev_pmd.h | 2 +- lib/cryptodev/rte_cryptodev.h | 2 +- lib/ip_frag/ip_reassembly.h | 2 +- lib/ipsec/sa.h | 2 +- lib/rib/rte_rib.c | 2 +- lib/rib/rte_rib6.c | 2 +- lib/table/rte_swx_table_learner.c | 2 +- lib/table/rte_table_hash_key16.c | 4 ++-- lib/table/rte_table_hash_key32.c | 4 ++-- lib/table/rte_table_hash_key8.c | 4 ++-- lib/vhost/rte_vhost.h | 4 ++-- 35 files changed, 63 insertions(+), 46 deletions(-) create mode 100644 devtools/cocci/zerolengtharray.cocci
Signature · 1 line
2.34.1
RFC 1/2 devtools: add script to check for zero length array
Use the same script as Linux kernel to find and replace zero length arrays at end of structures.
Flexible arrays were introduced in C99 and help catch some obvious errors (like incorrect sizeof).
--- devtools/cocci/zerolengtharray.cocci | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 devtools/cocci/zerolengtharray.cocci
devtools/cocci/zerolengtharray.cocci new file +17 -0
@@ -0,0 +1,17 @@ +// +// Replace all older style of one-element or zero length arrays +// with current flexible member arraya +// + +@@ +identifier S, member, array; +type T1, T2; +@@ + +struct S { + ... + T1 member; + T2 array[ +- 0 + ]; +};
Signature · 1 line
2.34.1
RFC 2/2 treewide: replace zero-length array with flex array
In reply to Stephen HemmingerApply the coccinelle strip to find/fix use of zero length arrays at end of structures.
--- app/test/test_table_tables.c | 2 +- drivers/bus/dpaa/include/netcfg.h | 4 ++-- drivers/common/cnxk/roc_se.h | 2 +- drivers/common/dpaax/caamflib/desc/ipsec.h | 2 +- drivers/common/dpaax/dpaax_iova_table.h | 2 +- drivers/common/mlx5/mlx5_prm.h | 8 ++++---- drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 2 +- drivers/crypto/ipsec_mb/ipsec_mb_private.h | 4 ++-- drivers/crypto/virtio/virtio_ring.h | 4 ++-- drivers/crypto/virtio/virtqueue.h | 2 +- drivers/net/cxgbe/clip_tbl.h | 2 +- drivers/net/cxgbe/l2t.h | 2 +- drivers/net/cxgbe/mps_tcam.h | 2 +- drivers/net/cxgbe/smt.h | 2 +- drivers/net/enic/base/vnic_devcmd.h | 4 ++-- drivers/net/hinic/hinic_pmd_tx.h | 2 +- drivers/net/nfp/nfpcore/nfp_nsp.h | 2 +- drivers/net/virtio/virtio_ring.h | 4 ++-- drivers/net/virtio/virtio_user/vhost_kernel.c | 2 +- drivers/net/virtio/virtio_user/vhost_vdpa.c | 2 +- drivers/net/virtio/virtqueue.h | 2 +- drivers/regex/mlx5/mlx5_rxp.h | 2 +- examples/ip_reassembly/main.c | 2 +- lib/cryptodev/cryptodev_pmd.h | 2 +- lib/cryptodev/rte_cryptodev.h | 2 +- lib/ip_frag/ip_reassembly.h | 2 +- lib/ipsec/sa.h | 2 +- lib/rib/rte_rib.c | 2 +- lib/rib/rte_rib6.c | 2 +- lib/table/rte_swx_table_learner.c | 2 +- lib/table/rte_table_hash_key16.c | 4 ++-- lib/table/rte_table_hash_key32.c | 4 ++-- lib/table/rte_table_hash_key8.c | 4 ++-- lib/vhost/rte_vhost.h | 4 ++-- 34 files changed, 46 insertions(+), 46 deletions(-)
app/test/test_table_tables.c +1 -1
@@ -53,7 +53,7 @@ struct rte_bucket_4_8 {uint64_t next_valid;uint64_t key[4 ];/* Cache line 1 */ -uint8_t data[0 ]; +uint8_t data[]; };#if RTE_TABLE_HASH_LRU_STRATEGY ==3
drivers/bus/dpaa/include/netcfg.h +2 -2
@@ -23,7 +23,7 @@ struct fm_eth_port_cfg {struct netcfg_info {uint8_t num_ethports;/**< Number of ports */ -struct fm_eth_port_cfg port_cfg[0 ]; +struct fm_eth_port_cfg port_cfg[];/**< Variable structure array of size num_ethports */ };
@@ -38,7 +38,7 @@ struct interface_info {struct netcfg_interface {uint8_t numof_netcfg_interface;uint8_t numof_fman_enabled_macless; -struct interface_info interface_info[0 ]; +struct interface_info interface_info[]; };/* pcd_file: FMC netpcd XML ("policy") file, that contains PCD information.
drivers/common/cnxk/roc_se.h +1 -1
@@ -246,7 +246,7 @@ struct roc_se_buf_ptr {/* IOV Pointer */ struct roc_se_iov_ptr {int buf_cnt; -struct roc_se_buf_ptr bufs[0 ]; +struct roc_se_buf_ptr bufs[]; };struct roc_se_fc_params {
drivers/common/dpaax/caamflib/desc/ipsec.h +1 -1
@@ -350,7 +350,7 @@ struct ipsec_encap_pdb { };uint32_t spi;uint32_t ip_hdr_len; -uint8_t ip_hdr[0 ]; +uint8_t ip_hdr[]; }; static inline unsigned int
drivers/common/dpaax/dpaax_iova_table.h +1 -1
@@ -32,7 +32,7 @@ struct dpaax_iovat_element {struct dpaax_iova_table {unsigned int count;/**< No. of blocks of contiguous physical pages */ -struct dpaax_iovat_element entries[0 ]; +struct dpaax_iovat_element entries[]; };/* Pointer to the table, which is common for DPAA/DPAA2 and only a single
drivers/common/mlx5/mlx5_prm.h +4 -4
@@ -3433,7 +3433,7 @@ struct mlx5_ifc_qpc_pas_list_bits {#endif struct mlx5_ifc_qpc_extension_and_pas_list_bits {struct mlx5_ifc_qpc_extension_bits qpc_data_extension; -u8 pas[0 ][0x40 ]; +u8 pas[][0x40 ]; };
@@ -3657,7 +3657,7 @@ struct mlx5_ifc_query_qp_out_bits {u8 reserved_at_a0[0x20 ];struct mlx5_ifc_qpc_bits qpc;u8 reserved_at_800[0x80 ]; -u8 pas[0 ][0x40 ]; +u8 pas[][0x40 ]; };#ifdef PEDANTIC #pragma GCC diagnostic error "-Wpedantic"
@@ -3697,7 +3697,7 @@ struct mlx5_ifc_access_register_out_bits {u8 reserved_at_8[0x18 ];u8 syndrome[0x20 ];u8 reserved_at_40[0x40 ]; -u8 register_data[0 ][0x20 ]; +u8 register_data[][0x20 ]; };struct mlx5_ifc_access_register_in_bits {
@@ -3708,7 +3708,7 @@ struct mlx5_ifc_access_register_in_bits {u8 reserved_at_40[0x10 ];u8 register_id[0x10 ];u8 argument[0x20 ]; -u8 register_data[0 ][0x20 ]; +u8 register_data[][0x20 ]; };#ifdef PEDANTIC #pragma GCC diagnostic error "-Wpedantic"
drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h +1 -1
@@ -128,7 +128,7 @@ struct sec_flc_desc {struct ctxt_priv {struct rte_mempool *fle_pool;/* per device memory pool for FLE */ -struct sec_flc_desc flc_desc[0 ]; +struct sec_flc_desc flc_desc[]; };enum dpaa2_sec_op_type {
drivers/crypto/ipsec_mb/ipsec_mb_private.h +2 -2
@@ -120,7 +120,7 @@ struct ipsec_mb_dev_private {/**< PMD type */ uint32_t max_nb_queue_pairs;/**< Max number of queue pairs supported by device */ - __extension__uint8_t priv[0 ]; + __extension__uint8_t priv[]; };/** IPSEC Multi buffer queue pair common queue pair data for all PMDs */
@@ -147,7 +147,7 @@ struct ipsec_mb_qp {/* Multi buffer manager */ const struct rte_memzone *mb_mgr_mz;/* Shared memzone for storing mb_mgr */ - __extension__uint8_t additional_data[0 ]; + __extension__uint8_t additional_data[];/**< Storing PMD specific additional data */ };
drivers/crypto/virtio/virtio_ring.h +2 -2
@@ -40,7 +40,7 @@ struct vring_desc {struct vring_avail {uint16_t flags;uint16_t idx; -uint16_t ring[0 ]; +uint16_t ring[]; };/* id is a 16bit index. uint32_t is used here for ids for padding reasons. */
@@ -54,7 +54,7 @@ struct vring_used_elem {struct vring_used {uint16_t flags;volatile uint16_t idx; -struct vring_used_elem ring[0 ]; +struct vring_used_elem ring[]; };struct vring {
drivers/crypto/virtio/virtqueue.h +1 -1
@@ -88,7 +88,7 @@ struct virtqueue {uint16_t *notify_addr; -struct vq_desc_extra vq_descx[0 ]; +struct vq_desc_extra vq_descx[]; };/**
drivers/net/cxgbe/clip_tbl.h +1 -1
@@ -20,7 +20,7 @@ struct clip_tbl {unsigned int clipt_start;/* start index of CLIP table */ unsigned int clipt_size;/* size of CLIP table */ rte_rwlock_t lock;/* table rw lock */ -struct clip_entry cl_list[0 ];/* MUST BE LAST */ +struct clip_entry cl_list[];/* MUST BE LAST */ }; struct clip_tbl *t4_init_clip_tbl(unsigned int clipt_start,
drivers/net/cxgbe/l2t.h +1 -1
@@ -37,7 +37,7 @@ struct l2t_data {unsigned int l2t_start;/* start index of our piece of the L2T */ unsigned int l2t_size;/* number of entries in l2tab */ rte_rwlock_t lock;/* table rw lock */ -struct l2t_entry l2tab[0 ];/* MUST BE LAST */ +struct l2t_entry l2tab[];/* MUST BE LAST */ };#define L2T_LPBK true
drivers/net/cxgbe/mps_tcam.h +1 -1
@@ -41,7 +41,7 @@ struct mpstcam_table {* free_idx cannot alone determine * if the table is full */ -struct mps_tcam_entry entry[0 ]; +struct mps_tcam_entry entry[]; };struct mpstcam_table *t4_init_mpstcam (struct adapter *adap);
drivers/net/cxgbe/smt.h +1 -1
@@ -31,7 +31,7 @@ struct smt_data {unsigned int smt_size;unsigned int smt_start;rte_rwlock_t lock; -struct smt_entry smtab[0 ]; +struct smt_entry smtab[]; };struct smt_data *t4_init_smt (u32 smt_start_idx,u32 smt_size);
drivers/net/enic/base/vnic_devcmd.h +2 -2
@@ -765,7 +765,7 @@ struct vnic_devcmd_notify {struct vnic_devcmd_provinfo {uint8_t oui[3 ];uint8_t type; -uint8_t data[0 ]; +uint8_t data[]; };/*
@@ -997,7 +997,7 @@ enum {struct filter_tlv {uint32_t type;uint32_t length; -uint32_t val[0 ]; +uint32_t val[]; };/* Data for CMD_ADD_FILTER is 2 TLV and filter + action structs */
drivers/net/hinic/hinic_pmd_tx.h +1 -1
@@ -81,7 +81,7 @@ struct hinic_sq_wqe {struct hinic_sq_task task;/* sq sge section start address, 1~127 sges */ -struct hinic_sq_bufdesc buf_descs[0 ]; +struct hinic_sq_bufdesc buf_descs[]; };struct hinic_txq_stats {
drivers/net/nfp/nfpcore/nfp_nsp.h +1 -1
@@ -224,7 +224,7 @@ struct nfp_eth_table {int is_split;unsigned int fec_modes_supported; - } ports[0 ]; + } ports[]; };struct nfp_eth_table *nfp_eth_read_ports (struct nfp_cpp *cpp);
drivers/net/virtio/virtio_ring.h +2 -2
@@ -46,7 +46,7 @@ struct vring_desc {struct vring_avail {uint16_t flags;uint16_t idx; -uint16_t ring[0 ]; +uint16_t ring[]; };/* id is a 16bit index. uint32_t is used here for ids for padding reasons. */
@@ -60,7 +60,7 @@ struct vring_used_elem {struct vring_used {uint16_t flags;uint16_t idx; -struct vring_used_elem ring[0 ]; +struct vring_used_elem ring[]; };/* For support of packed virtqueues in Virtio 1.1 the format of descriptors
drivers/net/virtio/virtio_user/vhost_kernel.c +1 -1
@@ -22,7 +22,7 @@ struct vhost_kernel_data {struct vhost_memory_kernel {uint32_t nregions;uint32_t padding; -struct vhost_memory_region regions[0 ]; +struct vhost_memory_region regions[]; };/* vhost kernel ioctls */
drivers/net/virtio/virtio_user/vhost_vdpa.c +1 -1
@@ -70,7 +70,7 @@ struct vhost_iotlb_msg {struct vhost_vdpa_config {uint32_t off;uint32_t len; -uint8_t buf[0 ]; +uint8_t buf[]; };struct vhost_msg {
drivers/net/virtio/virtqueue.h +1 -1
@@ -309,7 +309,7 @@ struct virtqueue {uint16_t *notify_addr;struct rte_mbuf **sw_ring;/**< RX software ring. */ -struct vq_desc_extra vq_descx[0 ]; +struct vq_desc_extra vq_descx[]; };/* If multiqueue is provided by host, then we support it. */
drivers/regex/mlx5/mlx5_rxp.h +1 -1
@@ -64,7 +64,7 @@ struct mlx5_rxp_match_tuple {struct mlx5_rxp_response {struct mlx5_rxp_response_desc header; -struct mlx5_rxp_match_tuple matches[0 ]; +struct mlx5_rxp_match_tuple matches[]; };#define MLX5_RXP_MAX_MATCHES 254
examples/ip_reassembly/main.c +1 -1
@@ -126,7 +126,7 @@ struct mbuf_table {uint32_t len;uint32_t head;uint32_t tail; -struct rte_mbuf *m_table[0 ]; +struct rte_mbuf *m_table[]; };struct rx_queue {
lib/cryptodev/cryptodev_pmd.h +1 -1
@@ -637,7 +637,7 @@ RTE_STD_C11 struct rte_cryptodev_asym_session {uint16_t user_data_sz;/**< Session user data will be placed after sess_data */ uint8_t padding[3 ]; - uint8_t sess_private_data[0]; + uint8_t sess_private_data[]; };#endif /* _CRYPTODEV_PMD_H_ */
lib/cryptodev/rte_cryptodev.h +1 -1
@@ -914,7 +914,7 @@ struct rte_cryptodev_sym_session { __extension__struct {void *data;uint16_t refcnt; - } sess_data[0 ]; + } sess_data[];/**< Driver specific session material, variable size */ };
lib/ip_frag/ip_reassembly.h +1 -1
@@ -83,7 +83,7 @@ struct rte_ip_frag_tbl {struct ip_frag_pkt *last;/* last used entry. */ struct ip_pkt_list lru;/* LRU list for table entries. */ struct ip_frag_tbl_stat stat;/* statistics counters. */ - __extension__ struct ip_frag_pkt pkt[0]; /* hash table. */ + __extension__ struct ip_frag_pkt pkt[]; /* hash table. */ };#endif /* _IP_REASSEMBLY_H_ */
lib/ipsec/sa.h +1 -1
@@ -60,7 +60,7 @@ union sym_op_data {struct replay_sqn {rte_rwlock_t rwl;uint64_t sqn; - __extension__uint64_t window[0 ]; + __extension__uint64_t window[]; };/*IPSEC SA supported algorithms */
lib/rib/rte_rib.c +1 -1
@@ -37,7 +37,7 @@ struct rte_rib_node {uint8_t depth;uint8_t flag;uint64_t nh; - __extension__uint64_t ext[0 ]; + __extension__uint64_t ext[]; };struct rte_rib {
lib/rib/rte_rib6.c +1 -1
@@ -36,7 +36,7 @@ struct rte_rib6_node {uint8_t ip[RTE_RIB6_IPV6_ADDR_SIZE ];uint8_t depth;uint8_t flag; - __extension__uint64_t ext[0 ]; + __extension__uint64_t ext[]; };struct rte_rib6 {
lib/table/rte_swx_table_learner.c +1 -1
@@ -238,7 +238,7 @@ struct table_bucket {uint32_t time[TABLE_KEYS_PER_BUCKET ];uint32_t sig[TABLE_KEYS_PER_BUCKET ];uint8_t pad[TABLE_BUCKET_PAD_SIZE ]; -uint8_t key[0 ]; +uint8_t key[]; };struct table_params {
lib/table/rte_table_hash_key16.c +2 -2
@@ -45,7 +45,7 @@ struct rte_bucket_4_16 {uint64_t key[4 ][2 ];/* Cache line 2 */ -uint8_t data[0 ]; +uint8_t data[]; };#else struct rte_bucket_4_16 {
@@ -60,7 +60,7 @@ struct rte_bucket_4_16 {uint64_t key[4 ][2 ];/* Cache line 2 */ - uint8_t data[0]; + uint8_t data[]; };#endif
lib/table/rte_table_hash_key32.c +2 -2
@@ -45,7 +45,7 @@ struct rte_bucket_4_32 {uint64_t key[4 ][4 ];/* Cache line 3 */ -uint8_t data[0 ]; +uint8_t data[]; };#else struct rte_bucket_4_32 {
@@ -60,7 +60,7 @@ struct rte_bucket_4_32 {uint64_t key[4 ][4 ];/* Cache line 3 */ - uint8_t data[0]; + uint8_t data[]; };#endif
lib/table/rte_table_hash_key8.c +2 -2
@@ -42,7 +42,7 @@ struct rte_bucket_4_8 {uint64_t key[4 ];/* Cache line 1 */ -uint8_t data[0 ]; +uint8_t data[]; };#else struct rte_bucket_4_8 {
@@ -56,7 +56,7 @@ struct rte_bucket_4_8 {uint64_t key[4 ];/* Cache line 1 */ - uint8_t data[0]; + uint8_t data[]; };#endif
lib/vhost/rte_vhost.h +2 -2
@@ -154,7 +154,7 @@ struct rte_vhost_inflight_info_split {uint16_t desc_num;uint16_t last_inflight_io;uint16_t used_idx; -struct rte_vhost_inflight_desc_split desc[0 ]; +struct rte_vhost_inflight_desc_split desc[]; };struct rte_vhost_inflight_desc_packed {
@@ -181,7 +181,7 @@ struct rte_vhost_inflight_info_packed {uint8_t used_wrap_counter;uint8_t old_used_wrap_counter;uint8_t padding[7 ]; -struct rte_vhost_inflight_desc_packed desc[0 ]; +struct rte_vhost_inflight_desc_packed desc[]; };struct rte_vhost_resubmit_desc {
Signature · 1 line
2.34.1
Quoted 49 lines
From: Stephen Hemminger [mailto:[email protected]]
Sent: Wednesday, 16 February 2022 00.01Yet another case of applying Linux kernel best practices to DPDK. Flexible arrays are supported by Clang, GCC and Microsoft compilers (part of C99).
Stephen Hemminger (2):
devtools: add script to check for zero length array
treewide: replace zero-length array with flex arrayapp/test/test_table_tables.c | 2 +- devtools/cocci/zerolengtharray.cocci | 17 +++++++++++++++++ drivers/bus/dpaa/include/netcfg.h | 4 ++-- drivers/common/cnxk/roc_se.h | 2 +- drivers/common/dpaax/caamflib/desc/ipsec.h | 2 +- drivers/common/dpaax/dpaax_iova_table.h | 2 +- drivers/common/mlx5/mlx5_prm.h | 8 ++++---- drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 2 +- drivers/crypto/ipsec_mb/ipsec_mb_private.h | 4 ++-- drivers/crypto/virtio/virtio_ring.h | 4 ++-- drivers/crypto/virtio/virtqueue.h | 2 +- drivers/net/cxgbe/clip_tbl.h | 2 +- drivers/net/cxgbe/l2t.h | 2 +- drivers/net/cxgbe/mps_tcam.h | 2 +- drivers/net/cxgbe/smt.h | 2 +- drivers/net/enic/base/vnic_devcmd.h | 4 ++-- drivers/net/hinic/hinic_pmd_tx.h | 2 +- drivers/net/nfp/nfpcore/nfp_nsp.h | 2 +- drivers/net/virtio/virtio_ring.h | 4 ++-- drivers/net/virtio/virtio_user/vhost_kernel.c | 2 +- drivers/net/virtio/virtio_user/vhost_vdpa.c | 2 +- drivers/net/virtio/virtqueue.h | 2 +- drivers/regex/mlx5/mlx5_rxp.h | 2 +- examples/ip_reassembly/main.c | 2 +- lib/cryptodev/cryptodev_pmd.h | 2 +- lib/cryptodev/rte_cryptodev.h | 2 +- lib/ip_frag/ip_reassembly.h | 2 +- lib/ipsec/sa.h | 2 +- lib/rib/rte_rib.c | 2 +- lib/rib/rte_rib6.c | 2 +- lib/table/rte_swx_table_learner.c | 2 +- lib/table/rte_table_hash_key16.c | 4 ++-- lib/table/rte_table_hash_key32.c | 4 ++-- lib/table/rte_table_hash_key8.c | 4 ++-- lib/vhost/rte_vhost.h | 4 ++-- 35 files changed, 63 insertions(+), 46 deletions(-) create mode 100644 devtools/cocci/zerolengtharray.cocci
Quoted 2 lines
--
2.34.1
Thank you! We must all appreciate the DPDK housekeeping efforts, where it DPDK gets some real love, and not just added support for new bells and whistles in fancy NICs. :-)
Quoted 4 lines · Stephen Hemminger
Yet another case of applying Linux kernel best practices to DPDK. Flexible arrays are supported by Clang, GCC and Microsoft compilers (part of C99).
Do we need to start explicitly stating that DPDK uses C99 features, and adding -std=c99 to our build flags? Are we also requiring that applications are compiled with c99 features to use this (I would hope that they are, but I'm not sure we can mandate it).
Quoted 8 lines
From: Bruce Richardson [mailto:[email protected]]
Sent: Wednesday, 16 February 2022 10.33Quoted 4 lines · Stephen Hemminger
Yet another case of applying Linux kernel best practices to DPDK. Flexible arrays are supported by Clang, GCC and Microsoft compilers (part of C99).
Quoted 6 lines
Do we need to start explicitly stating that DPDK uses C99 features, and adding -std=c99 to our build flags? Are we also requiring that applications
are compiled with c99 features to use this (I would hope that they are, but
I'm not sure we can mandate it).
No to -std=c99. It's >= C99 for applications; we should not prevent them from using a newer C standard.
Adding a note about the C standard version to the DPDK requirements documentation would be very nice. It only mentions a certain compiler version required. But I think that documenting the detailed build and runtime requirements (and why they are that way) is another task.
Quoted 8 lines · Morten Brørup
Quoted 8 lines
From: Bruce Richardson [mailto:[email protected]]
Sent: Wednesday, 16 February 2022 10.33Quoted 4 lines · Stephen Hemminger
Yet another case of applying Linux kernel best practices to DPDK. Flexible arrays are supported by Clang, GCC and Microsoft compilers (part of C99).
Quoted 8 lines
Quoted 6 lines
Do we need to start explicitly stating that DPDK uses C99 features, and adding -std=c99 to our build flags? Are we also requiring that applications
are compiled with c99 features to use this (I would hope that they are, but
I'm not sure we can mandate it).No to -std=c99. It's >= C99 for applications; we should not prevent them from using a newer C standard.
Yes. For build flags, I was referring only to having it in the cflags for the build of DPDK itself, not for apps. We definitely need to minimise the build flags we expose to apps.
Quoted 6 lines
Adding a note about the C standard version to the DPDK requirements documentation would be very nice. It only mentions a certain compiler version required. But I think that documenting the detailed build and runtime requirements (and why they are that way) is another task.
Sure, we should do that. I am just wanting to be sure that if we specify a minimum of C99, we won't get complaints back from those with legacy codebasees which only support C89/C90. I am therefore wondering if we need to have our public headers C90-compliant?
/Bruce
Quoted 28 lines · Bruce Richardson
Quoted 8 lines · Morten Brørup
Quoted 8 lines
From: Bruce Richardson [mailto:[email protected]]
Sent: Wednesday, 16 February 2022 10.33Quoted 4 lines · Stephen Hemminger
Yet another case of applying Linux kernel best practices to DPDK. Flexible arrays are supported by Clang, GCC and Microsoft compilers (part of C99).
Quoted 8 lines
Quoted 6 lines
Do we need to start explicitly stating that DPDK uses C99 features, and adding -std=c99 to our build flags? Are we also requiring that applications
are compiled with c99 features to use this (I would hope that they are, but
I'm not sure we can mandate it).No to -std=c99. It's >= C99 for applications; we should not prevent them from using a newer C standard.
Yes. For build flags, I was referring only to having it in the cflags for the build of DPDK itself, not for apps. We definitely need to minimise the build flags we expose to apps.
Quoted 6 lines
Adding a note about the C standard version to the DPDK requirements documentation would be very nice. It only mentions a certain compiler version required. But I think that documenting the detailed build and runtime requirements (and why they are that way) is another task.
Quoted 4 lines
Sure, we should do that. I am just wanting to be sure that if we specify a minimum of C99, we won't get complaints back from those with legacy codebasees which only support C89/C90. I am therefore wondering if we need to have our public headers C90-compliant?
this seems to be the real question. what "minimum" C standard should be documented as required to consume dpdk. we can obviously use any standard we wish to build/provide binaries. similarly we ought to document a minimum C++ standard for consumption.
i would advocate for C99 however before setting that in stone it is fair to ask if there are any consumers using < C99.
we may also want to consider that the minimum required may differ depending on the platform/port. though most differences in public interface i would hope could be trivially abstracted though.
ty
Quoted 57 lines
From: Tyler Retzlaff [mailto:[email protected]]
Sent: Thursday, 17 February 2022 08.42Quoted 5 lines · Bruce Richardson
Quoted 4 lines · Morten Brørup
Quoted 4 lines
From: Bruce Richardson [mailto:[email protected]]
Sent: Wednesday, 16 February 2022 10.33On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger
Quoted 5 lines · wrote:
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Yet another case of applying Linux kernel best practices to DPDK. Flexible arrays are supported by Clang, GCC and Microsoft compilers (part of C99).
Do we need to start explicitly stating that DPDK uses C99
features, and
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
adding -std=c99 to our build flags? Are we also requiring that applications
are compiled with c99 features to use this (I would hope thatthey are,
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
but
I'm not sure we can mandate it).No to -std=c99. It's >= C99 for applications; we should not prevent
them from using a newer C standard.
Quoted 2 lines
Yes. For build flags, I was referring only to having it in the cflags
for the
Quoted 1 line
build of DPDK itself, not for apps. We definitely need to minimise
the
Quoted 5 lines
build flags we expose to apps.
Quoted 3 lines
Adding a note about the C standard version to the DPDK requirements documentation would be very nice. It only mentions a certain
compiler
Quoted 1 line
Quoted 1 line
version required. But I think that documenting the detailed build
and
Quoted 3 lines
Quoted 2 lines
runtime requirements (and why they are that way) is another task.
Sure, we should do that. I am just wanting to be sure that if we
specify a
Quoted 2 lines
minimum of C99, we won't get complaints back from those with legacy codebasees which only support C89/C90. I am therefore wondering if we
need
Quoted 1 line
to have our public headers C90-compliant?
this seems to be the real question. what "minimum" C standard should be documented as required to consume dpdk. we can obviously use any standard
we wish to build/provide binaries. similarly we ought to document a minimum C++ standard for consumption.i would advocate for C99 however before setting that in stone it is fair
to ask if there are any consumers using < C99.
Quoted 6 lines
we may also want to consider that the minimum required may differ depending on the platform/port. though most differences in public interface
i would hope could be trivially abstracted though.ty
Just read that the Linux kernel is moving towards C11, or at minimum C99, for version 5.18:
https://lwn.net/SubscriberLink/885941/01fdc39df2ecc25f/
Let's be bold and push for the same for DPDK! :-)
-Morten
Quoted 62 lines · On Thu, 24 Feb 2022 22:51:31 +0100 Morten Brørup <[email protected]>…
Quoted 62 lines
From: Tyler Retzlaff [mailto:[email protected]]
Sent: Thursday, 17 February 2022 08.42Quoted 5 lines · Bruce Richardson
Quoted 4 lines · Morten Brørup
Quoted 4 lines
From: Bruce Richardson [mailto:[email protected]]
Sent: Wednesday, 16 February 2022 10.33On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger
Quoted 5 lines · wrote:
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Yet another case of applying Linux kernel best practices to DPDK. Flexible arrays are supported by Clang, GCC and Microsoft compilers (part of C99).
Do we need to start explicitly stating that DPDK uses C99
features, and
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
adding -std=c99 to our build flags? Are we also requiring that applications
are compiled with c99 features to use this (I would hope thatthey are,
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
but
I'm not sure we can mandate it).No to -std=c99. It's >= C99 for applications; we should not prevent
them from using a newer C standard.
Quoted 2 lines
Yes. For build flags, I was referring only to having it in the cflags
for the
Quoted 1 line
build of DPDK itself, not for apps. We definitely need to minimise
the
Quoted 5 lines
build flags we expose to apps.
Quoted 3 lines
Adding a note about the C standard version to the DPDK requirements documentation would be very nice. It only mentions a certain
compiler
Quoted 1 line
Quoted 1 line
version required. But I think that documenting the detailed build
and
Quoted 3 lines
Quoted 2 lines
runtime requirements (and why they are that way) is another task.
Sure, we should do that. I am just wanting to be sure that if we
specify a
Quoted 2 lines
minimum of C99, we won't get complaints back from those with legacy codebasees which only support C89/C90. I am therefore wondering if we
need
Quoted 1 line
to have our public headers C90-compliant?
this seems to be the real question. what "minimum" C standard should be documented as required to consume dpdk. we can obviously use any standard
we wish to build/provide binaries. similarly we ought to document a minimum C++ standard for consumption.i would advocate for C99 however before setting that in stone it is fair
to ask if there are any consumers using < C99.we may also want to consider that the minimum required may differ depending on the platform/port. though most differences in public interface
i would hope could be trivially abstracted though.
Quoted 6 lines
Quoted 1 line
ty
Just read that the Linux kernel is moving towards C11, or at minimum C99, for version 5.18:
https://lwn.net/SubscriberLink/885941/01fdc39df2ecc25f/Let's be bold and push for the same for DPDK! :-)
Would be good, but still getting held back by legacy distros (RHEL) and other compiler environments ICC, etc.
Quoted 9 lines · On Wed, 16 Feb 2022 09:33:02 +0000 Bruce Richardson…
Quoted 4 lines · Stephen Hemminger
Yet another case of applying Linux kernel best practices to DPDK. Flexible arrays are supported by Clang, GCC and Microsoft compilers (part of C99).
Do we need to start explicitly stating that DPDK uses C99 features, and adding -std=c99 to our build flags? Are we also requiring that applications are compiled with c99 features to use this (I would hope that they are, but I'm not sure we can mandate it).
There are already many uses of flex array in DPDK. This is nothing new.
Quoted 3 lines · Stephen Hemminger
Yet another case of applying Linux kernel best practices to DPDK. Flexible arrays are supported by Clang, GCC and Microsoft compilers (part of C99).
subject to the outcome of documenting C99 compiler as a minimum requirement.