From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5E83441BBE; Fri, 3 Feb 2023 17:45:18 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3C3204067B; Fri, 3 Feb 2023 17:45:18 +0100 (CET) Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by mails.dpdk.org (Postfix) with ESMTP id C90014021E for ; Fri, 3 Feb 2023 17:45:16 +0100 (CET) Received: by mail-yb1-f175.google.com with SMTP id i2so3688941ybt.2 for ; Fri, 03 Feb 2023 08:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+hL+AW7t4x1FNWnPSGEB63zpQctJDQx/nlnzQKjOVMc=; b=FTC8qYf51w43+upZ0amLcsy+BX6ymYRGNi0CXtpGzSuyNMebvwxubQqSVuvPUdzLFT vGgo7fINPboAOEGwYiw8mPhlv7PtYpRaHulK7C4Ouuk2LxP8jrVHUiegfFmwtkPSZ9BX rFrSdwbcKBrLN0eG821RNoSggCMgynymxSdvIinpwIXkcnwiYf7NZOIf+FwhpJggJwzD R8JsFmGmREgMSbqFatGvhR4o+QFihj5D6leBdTObeWMFr8M9ZPQzjRjNc1koMXQydvdD P8haGNT9x8IQCOMXlWLfBjo0S/7iOTJVMXxHskfPQbtoEVc3du/w12Hnv3laPkrLOsan 18kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+hL+AW7t4x1FNWnPSGEB63zpQctJDQx/nlnzQKjOVMc=; b=YtRusXTzSkjM2kdASh2+T/3jknE8gxkLGFFpmf12h/7QaPz8gvkm2Yig0DUCR0QV7d aZtSEsAZP5AsIIW/SeV2pv4y74VE86t20t7+kWprDR4yx18UEpBOQy0E2A7YzvJbYMXI 5uyeYe8sY9tMgajLZ/zU0zMoyq3T6UTnIhUGtTK7QbpKvHmjUA1gzLor/I3aqugV2sXr zAADr24tQ1dL6h4W5Kc3tqZM5xvIwkmYI6WBzupVW4dWp84JsYGG0P3YslQq9jpvDZ4Y NEa8q48CEITfvgetY8yd/BzJ+7RYALCWB/fID30LvUrBMXEiA5j7rZ5jyNKwDxSADiog b4ZA== X-Gm-Message-State: AO0yUKV1goQIaKGwCtQG7i8kOJvOh40erza2OsTW8GcnIVyo9vI/sKoK pPsQekJWTO1Bmjd85D34lP8yZaLcxgx2e3K/jk4= X-Google-Smtp-Source: AK7set/eN1vOp1+MpZndULU9CzC/SRoPb5ITEmC3G6fBRYEqBBlZRWdxESxNwkfUSK7ATNX3m2K9kT4UhBHlLg4KZ3k= X-Received: by 2002:a25:9f83:0:b0:86b:92e1:7597 with SMTP id u3-20020a259f83000000b0086b92e17597mr265663ybq.635.1675442716095; Fri, 03 Feb 2023 08:45:16 -0800 (PST) MIME-Version: 1.0 References: <20230112113556.47485-1-bruce.richardson@intel.com> In-Reply-To: From: Ben Magistro Date: Fri, 3 Feb 2023 11:45:04 -0500 Message-ID: Subject: Re: [RFC PATCH 0/1] Specify C-standard requirement for DPDK builds To: Bruce Richardson Cc: dev@dpdk.org, thomas@monjalon.net, david.marchand@redhat.com, mb@smartsharesystems.com, roretzla@linux.microsoft.com Content-Type: multipart/alternative; boundary="000000000000ef3d7f05f3ce6769" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000ef3d7f05f3ce6769 Content-Type: text/plain; charset="UTF-8" In our case we have other libraries that we are using that have required us to specify a minimum c++ version (14/17 most recently for one) so it doesn't feel like a big ask/issue to us (provided things don't start conflicting...hah; not anticipating any issue). Our software is also used internally so we have a fair bit of control over how fast we can adopt changes. This got me wondering what some other projects in the DPDK ecosystem are saying/doing around language standards/gcc versions. So some quick checking of the projects I am aware of/looked at/using... * trex: cannot find an obvious minimum gcc requirement * tldk: we are running our own public folk with several fixes, need to find time to solve the build sys change aspect to continue providing patches upstream; I know I have hit some places where it was easier to say the new minimum DPDK version is x at which point you just adopt the minimum requirements of DPDK * ovs: looks to be comfortable with an older gcc still * seastar: seems to be the most aggressive with adopting language standards/compilers I've seen [1] and are asking for gcc 9+ and cpp17+ * ans: based on release 19.02 (2019), they are on gcc >= 5.4 [2] and is the same on the main README file I do understand the concern, but if no one is voicing an opinion/objection does that mean they agree with/will not be affected by the change.... 1) https://docs.seastar.io/master/md_compatibility.html 2) https://github.com/ansyun/dpdk-ans/releases Cheers On Fri, Feb 3, 2023 at 10:09 AM Bruce Richardson wrote: > On Fri, Feb 03, 2023 at 09:09:14AM -0500, Ben Magistro wrote: > > Since this topic keeps coming up in other threads I'll chime in with > my > > $0.01 here. We've been using CentOS 7 for awhile (and working on > > migrating off) but have had to leverage devtoolset/llvmtoolset for > > various reasons. I remember a discussion of installing a different > > compiler coming up but don't remember which thread that was in/what > the > > outcome was. While I'd like to just brush over C7 and say there is a > > compatible compiler available so just make the change I also realize > > that making that change could be quite disruptive to existing code > > bases. > > However, the 22.11 LTS will be EOL in Nov 2024. CentOS 7 is EOL Jun > > 2024. For the 23.x series and going forward I don't think starting > > with a C11 requirement is an unreasonable ask. > > > Thanks for that input. If we drop support for Centos/RHEL 7, I think we > should be ok to pass -std=c11 for the build of DPDK. > > Have you any thoughts on the second part of the c11 move - where our > headers require c11 support and therefore may require that the end user > builds their own code using -std=c11? This latter part is the bit that > concerns me a little, as I feel it may be problematic for some with older > codebases. > > /Bruce > --000000000000ef3d7f05f3ce6769 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In our case we have other libraries that we are using that= have required us to specify a minimum c++ version (14/17 most=C2=A0recentl= y for one) so it doesn't feel like a big ask/issue to us (provided thin= gs don't start conflicting...hah; not anticipating any issue).=C2=A0 Ou= r software=C2=A0is also used internally so we have a fair bit of control ov= er how fast we can adopt changes.

This got me wondering = what some other projects in the DPDK ecosystem are saying/doing around lang= uage standards/gcc versions.=C2=A0 So some quick checking of the projects I= am aware of/looked at/using...
* trex: cannot find an obvious mi= nimum gcc requirement
* tldk: we are running our own public folk = with several fixes, need to find time to solve the build sys change aspect = to continue providing patches upstream; I know I have hit some places=C2=A0= where it was easier to say the new minimum DPDK version is x at which point= you just adopt the minimum requirements of DPDK
* ovs: looks to = be comfortable with an older gcc still
* seastar: seems to be the= most aggressive with adopting language standards/compilers I've seen [= 1] and are asking for gcc 9+ and cpp17+
* ans: based on release 1= 9.02 (2019), they are on gcc >=3D 5.4 [2] and is the same on the main RE= ADME file

I do understand the concern, but if no o= ne is voicing an opinion/objection does that mean they agree with/will not = be affected by the change....


Cheers

On Fri, Feb 3, 2023 at 10:09 AM= Bruce Richardson <bruce.r= ichardson@intel.com> wrote:
On Fri, Feb 03, 2023 at 09:09:14AM -0500, Ben Magistro w= rote:
>=C2=A0 =C2=A0 Since this topic keeps coming up in other threads I'l= l chime in with my
>=C2=A0 =C2=A0 $0.01 here.=C2=A0 We've been using CentOS 7 for awhil= e (and working on
>=C2=A0 =C2=A0 migrating off) but have had to leverage devtoolset/llvmto= olset for
>=C2=A0 =C2=A0 various reasons.=C2=A0 I remember a discussion of install= ing a different
>=C2=A0 =C2=A0 compiler coming up but don't remember which thread th= at was in/what the
>=C2=A0 =C2=A0 outcome was.=C2=A0 While I'd like to just brush over = C7 and say there is a
>=C2=A0 =C2=A0 compatible compiler available so just make the change I a= lso realize
>=C2=A0 =C2=A0 that making that change could be quite disruptive to exis= ting code
>=C2=A0 =C2=A0 bases.
>=C2=A0 =C2=A0 However, the 22.11 LTS will be EOL in Nov 2024.=C2=A0 Cen= tOS 7 is EOL Jun
>=C2=A0 =C2=A0 2024.=C2=A0 For the 23.x series and going forward I don&#= 39;t think starting
>=C2=A0 =C2=A0 with a C11 requirement is an unreasonable ask.
>
Thanks for that input. If we drop support for Centos/RHEL 7, I think we
should be ok to pass -std=3Dc11 for the build of DPDK.

Have you any thoughts on the second part of the c11 move - where our
headers require c11 support and therefore may require that the end user
builds their own code using -std=3Dc11? This latter part is the bit that concerns me a little, as I feel it may be problematic for some with older codebases.

/Bruce
--000000000000ef3d7f05f3ce6769--