| Message ID | 20220215230058.64760-1-stephen@networkplumber.org (mailing list archive) |
|---|---|
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 40E95A00C5; Wed, 16 Feb 2022 00:01:03 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 08526410F7; Wed, 16 Feb 2022 00:01:03 +0100 (CET) Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by mails.dpdk.org (Postfix) with ESMTP id 32A78410F3 for <dev@dpdk.org>; Wed, 16 Feb 2022 00:01:02 +0100 (CET) Received: by mail-pg1-f171.google.com with SMTP id z21so439211pgn.0 for <dev@dpdk.org>; Tue, 15 Feb 2022 15:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=xEYgkyKgV3Y1+9gbhMosjrIU3qxH64Yu0zfAGBDxw0g=; b=2eYNzs54XpEcr84PISxkHE+AQn+vDQF0dZhc4lqT5s/lrkz6i/WPwNFRzgEtY2MplP Xa5W67xJzEYK1nz/HMp+Z/MXHl+zUT+jC5wRcUDnAPXHO+NsDQZB5puPxrLv3nsjOs3J lIY2LqpBrzkM5VFdq7+lmjJ3aTzyCV2WOYIdRYfzvAL4pKuFmN0qHhZ++cm+cPGB1hfJ lsnc9CjaQIJsRPRFaptH5CzN28KZzzbDr+TA+tBPu+tH81+WaNTAyxaVl4tpGZ7Dd1Bn Aa3avpyjVcc4hxPYHKLXE9Saym10d/rsqJOC71ts6e4LurdonppKV1XyUa22n1CtdQCz ktgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=xEYgkyKgV3Y1+9gbhMosjrIU3qxH64Yu0zfAGBDxw0g=; b=Qf7rGuar8beGKFlEQUzBufibM7wz+fJ6CwtI8xsIx0jvyl+rg5zhkRRt/Jw8aS4UxS LVPYq/S1BpaMKCqrlabaPf70808h5x77REHcOv3tJ2uExUG++fCNLAlafPxn4qrCeSFD XPDB9ZgAElkfwD3NFiIXl/B82AkgeHh9vqbghcqJqzW6JyWWICKqJpGsgoc7jsAUpvAU TFMAI9tgoxVdWWxQXarkPz98Yf9+FAVCzeA4iT60yyYqCOIGv3Gq0jVVDYaNjQXHVxVy HNmD3q5yKb3JvA3Zso3pAaAcj2UvDVWU06XIWl4c2RnQQ2z0dTsmaL1jgQMP+I2Wdnry wQyg== X-Gm-Message-State: AOAM533WVmzWbHBAp2oMd6+FlQ/IRtwoJjLBMF1HAzpRPkitNsS8RtIX wSJAmS3JsPudvtqk9syeGB1tdf5BjUkh6GJW X-Google-Smtp-Source: ABdhPJxWT6WkEnFivdsssYoIKqYWVD+7yZNpdTNnJvN4OwKwt1vs3fQF2ZuLeSJifPXi9sFjGgltVA== X-Received: by 2002:a05:6a00:847:: with SMTP id q7mr1163226pfk.0.1644966060887; Tue, 15 Feb 2022 15:01:00 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id h25sm38204574pfn.208.2022.02.15.15.01.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Feb 2022 15:01:00 -0800 (PST) From: Stephen Hemminger <stephen@networkplumber.org> To: dev@dpdk.org Cc: Stephen Hemminger <stephen@networkplumber.org> Subject: [RFC 0/2] Eliminate zero length arrays in DPDK Date: Tue, 15 Feb 2022 15:00:56 -0800 Message-Id: <20220215230058.64760-1-stephen@networkplumber.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org |
| Series |
Eliminate zero length arrays in DPDK
|
|
Message
Stephen Hemminger
Feb. 15, 2022, 11 p.m. UTC
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
Comments
> From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Wednesday, 16 February 2022 00.01 > > 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 > > -- > 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. :-) Series-Acked-By: Morten Brørup <mb@smartsharesystems.com>
On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote: > 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).
> From: Bruce Richardson [mailto:bruce.richardson@intel.com] > Sent: Wednesday, 16 February 2022 10.33 > > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote: > > 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). 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.
On Wed, Feb 16, 2022 at 11:05:09AM +0100, Morten Brørup wrote: > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > Sent: Wednesday, 16 February 2022 10.33 > > > > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote: > > > 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). > > 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. > > 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
On Wed, 16 Feb 2022 09:33:02 +0000 Bruce Richardson <bruce.richardson@intel.com> wrote: > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote: > > 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.
On Wed, Feb 16, 2022 at 10:10:01AM +0000, Bruce Richardson wrote: > On Wed, Feb 16, 2022 at 11:05:09AM +0100, Morten Brørup wrote: > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > Sent: Wednesday, 16 February 2022 10.33 > > > > > > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote: > > > > 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). > > > > 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. > > > > > 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? 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
On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote: > Yet another case of applying Linux kernel best practices > to DPDK. Flexible arrays are supported by Clang, GCC and > Microsoft compilers (part of C99). Series-Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com> subject to the outcome of documenting C99 compiler as a minimum requirement.
> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > Sent: Thursday, 17 February 2022 08.42 > > On Wed, Feb 16, 2022 at 10:10:01AM +0000, Bruce Richardson wrote: > > On Wed, Feb 16, 2022 at 11:05:09AM +0100, Morten Brørup wrote: > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > > Sent: Wednesday, 16 February 2022 10.33 > > > > > > > > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger > wrote: > > > > > 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). > > > > > > 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. > > > > > > > > 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? > > 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 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
On Thu, 24 Feb 2022 22:51:31 +0100 Morten Brørup <mb@smartsharesystems.com> wrote: > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > Sent: Thursday, 17 February 2022 08.42 > > > > On Wed, Feb 16, 2022 at 10:10:01AM +0000, Bruce Richardson wrote: > > > On Wed, Feb 16, 2022 at 11:05:09AM +0100, Morten Brørup wrote: > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > > > Sent: Wednesday, 16 February 2022 10.33 > > > > > > > > > > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger > > wrote: > > > > > > 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). > > > > > > > > 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. > > > > > > > > > > > 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? > > > > 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 > > 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.