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 744B1423C3; Fri, 13 Jan 2023 15:18:59 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 177BA42D53; Fri, 13 Jan 2023 15:18:59 +0100 (CET) Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by mails.dpdk.org (Postfix) with ESMTP id 2BC6240E03 for ; Fri, 13 Jan 2023 15:18:58 +0100 (CET) Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-4d13cb4bbffso165783417b3.3 for ; Fri, 13 Jan 2023 06:18:58 -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=/s81q9201locBW/3f8FTp+lMpJCWFtLYC9iiUgdv0SY=; b=oyYE4LB2gQ98ivpoqBJCqsPbNkDEtidss5r/we1kmu4HGHZWUtDUOi/zG6jKAacfY4 b2APzb6s96fS98BTamXQdXSBvuWcRXQJBBA4gnn8rVTDrrCqPaeutF5UkjQ+u16Pv9Ry 3xiEDVAeaWLLe5U6Pb/VSML1bPbXGAEfOnxVpLCNhv5Z2A57CPt1ufNJO7tRKboo93uF OcOKqutlDj4WY42oZ7BoVTqqTHoD6l4NnQ9XVjbVUwqZj+CJxcETnoZfR6IFG294Wbez Mc7XxX1qluj4qXmJwaAqphKqvT3FaXDlcnD9ebIMM1Vg7oOzZji+SA1srHoCig+fiod5 aP3w== 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=/s81q9201locBW/3f8FTp+lMpJCWFtLYC9iiUgdv0SY=; b=aGFWDdqvrP6Jr4js3/nrkx5c28w5cq68YMUkP+/GtHuEe86OGgUlcHZSua6Cpk87d7 l6x56RVGzSujZHss0lAbqn5uHu+4xEYXcP8XEJQG5/uU9mb6+1m2Vit4NE23SNVpKln+ gKhVs4Zo8k4z7uNDWxtfQgflZzScWCx9VUdckSyOetmOyPpy5LvcKhH1CgR3tzZxxmon ucovTGrqUTSzcIFVqdP0c5xnOxfrzNlOvdt8xC+ICTDngVxE82DzfthqxE52cDD78VYk wipzbegbpSq03u+J8RJcdg8jR2B/O4Y2bqXNeN8e+Ql6L9Fr9iTwZKojlddI2ufabrU7 OgNA== X-Gm-Message-State: AFqh2krwJWv3J9KoinN2Uy8Bcp2+HQbyHttGqBsYWsXd+gvvmhs5KugS lt0HMPpmDNcQxF+lJU9J/+UCVKVUwF4/3nbUVCI= X-Google-Smtp-Source: AMrXdXtCu/6mKCppcQPff8kfxHTkB2HEUBwc0GpOMQMwlv5QzzgMaaZTRhLDXLbUJi2plBWLqJgEpLY9jHoJjlxYTfM= X-Received: by 2002:a0d:c7c6:0:b0:3df:21db:24f3 with SMTP id j189-20020a0dc7c6000000b003df21db24f3mr2139792ywd.25.1673619537472; Fri, 13 Jan 2023 06:18:57 -0800 (PST) MIME-Version: 1.0 References: <20230109225604.GA25566@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230110201033.GC21476@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D87651@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87656@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87659@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87659@smartserver.smartshare.dk> From: Ben Magistro Date: Fri, 13 Jan 2023 09:18:46 -0500 Message-ID: Subject: Re: RFC abstracting atomics To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: Bruce Richardson , Tyler Retzlaff , dev@dpdk.org Content-Type: multipart/alternative; boundary="00000000000005330105f225ea35" 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 --00000000000005330105f225ea35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As a user/developer I'll put a vote on Morten's side here. There are other libraries we utilize that have stated x.y.z is the last version that will support w, beginning on version l.m.n it will be standard o. I personally don't think a project asking for C11 support at a minimum would be unreasonable or overly burdensome. In that vein I thought there was a supported operating systems page (can't find it for 22.11 but did find it for an older version, 17.05). On more recent versions, there is the tested platforms page. Going back to the oldest LTS, 20.11 (and current 22.11 which includes some older OS not on the 20.11 list), I would be shocked if any of the listed operating systems didn't support C11 out of the box. Just my $0.01 On Wed, Jan 11, 2023 at 10:07 AM Morten Br=C3=B8rup wrote: > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > Sent: Wednesday, 11 January 2023 15.18 > > > > On Wed, Jan 11, 2023 at 01:46:02PM +0100, Morten Br=C3=B8rup wrote: > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > > Sent: Wednesday, 11 January 2023 12.57 > > > > > > > > On Wed, Jan 11, 2023 at 11:23:07AM +0100, Morten Br=C3=B8rup wrote: > > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > > > > Sent: Wednesday, 11 January 2023 11.10 > > > > > > > > > > > > One additional point that just became clear to me when I > > started > > > > > > thinking > > > > > > about upping our DPDK C-standard-baseline. We need to be > > careful > > > > what > > > > > > we > > > > > > are considering when we up our C baseline. We can mandate a > > > > specific > > > > > > compiler minimum and C version for compiling up DPDK itself, > > but I > > > > > > think we > > > > > > should not mandate that for the end applications. > > > > > > > > > > Why not? > > > > > > > > > > And do you consider this backwards compatibility a build time or > > run > > > > time requirement? > > > > > > > > > > > > > > > > > That means that our header files, such as atomics, should not > > > > require > > > > > > C99 > > > > > > or C11 even if the build of DPDK itself does. More > > specifically, > > > > even > > > > > > if we > > > > > > bump DPDK minimum to C11, we should still allow apps to build > > using > > > > > > older > > > > > > compiler settings. > > > > > > > > > > > > Therefore, we probably need to maintain non-C11 atomics code > > paths > > > > in > > > > > > headers beyond the point at which DPDK itself uses C11 as a > > code > > > > > > baseline. > > > > > > > > > > Am I misunderstanding your suggestion here: Code can be C11, but > > all > > > > APIs and header files must be C89? > > > > > > > > > > Wouldn't that also prevent DPDK inline functions from being C11? > > > > > > > > > Yes, it would. > > > > > > > > Now, perhaps we don't need to ensure that our headers have strict > > C89 > > > > compatibility, but I think we need to be very careful about > > mandating > > > > that > > > > end-user apps use particular c standard settings when compiling > > their > > > > own > > > > code. > > > > > > I get your point, Bruce, but I disagree. > > > > > > There should be a limit for how backwards compatible we want DPDK to > > be, and the limit should certainly not be C89. It might be C99 for a > > while, but it should soon be C11. > > > > > > If someone is stuck with a very old C compiler, and already rely on > > (extended) LTS for their compiler and runtime environment, why would > > they expect bleeding edge DPDK to cater for them? They can use some old > > DPDK version and rely on DPDK LTS. > > > > > > If you want to use an old compiler, you often have to use old > > libraries too, as new libraries often require newer compilers. This > > also applies to the Linux kernel. I don't see why DPDK should be any > > different. > > > > > > But... DPDK LTS is only two years!?! My point is: What you are > > describing is not a DPDK problem, it is a DPDK LTS policy problem. > > > > > > > I don't see it as a compiler problem, but as a codebase one. It doesn't > > matter if your compiler supports C11 if your codebase is using legacy > > features from C89 that are no longer supported by later versions. > > Changing > > compilers can be tricky, but updating a large legacy code-base is a > > much > > more challenging proposition. There is a lot of old code out there in > > the > > world! > > OK. But my same argument applies: Why would you need to use a brand new > DPDK release in your project when the rest of your code base is ancient? = In > that case, you should rely on DPDK LTS. > > > > > That said, I would hope that there are few large codebases out there > > that > > won't compile with a C99 or C11 standard language level, and there > > aren't > > that many things that should cause problems. However, I don't really > > know for > > sure, so urge caution. > > > > /Bruce > > --00000000000005330105f225ea35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a user/developer I'll put a vote on Morten's si= de here.=C2=A0 There are other libraries we utilize that have stated x.y.z = is the last version that will support w, beginning=C2=A0on version l.m.n it= will be standard o.=C2=A0 I personally don't think a project asking fo= r C11 support at a minimum would be unreasonable or overly burdensome.
=
In that vein I thought there was a supported operating syste= ms page (can't find it for 22.11 but did find it for an older version, = 17.05).=C2=A0 On more recent versions, there is the tested platforms page.= =C2=A0 Going back to the oldest LTS, 20.11 (and current 22.11 which include= s some older OS not on the 20.11 list), I would be shocked if any of the li= sted operating systems didn't support C11 out of the box.
Just my $0.01

On Wed, Jan 11, 2023 at 10:07 AM Morten Br= =C3=B8rup <mb@smartsharesyst= ems.com> wrote:
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Wednesday, 11 January 2023 15.18
>
> On Wed, Jan 11, 2023 at 01:46:02PM +0100, Morten Br=C3=B8rup wrote: > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Wednesday, 11 January 2023 12.57
> > >
> > > On Wed, Jan 11, 2023 at 11:23:07AM +0100, Morten Br=C3=B8rup= wrote:
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com= ]
> > > > > Sent: Wednesday, 11 January 2023 11.10
> > > > >
> > > > > One additional point that just became clear to me = when I
> started
> > > > > thinking
> > > > > about upping our DPDK C-standard-baseline. We need= to be
> careful
> > > what
> > > > > we
> > > > > are considering when we up our C baseline. We can = mandate a
> > > specific
> > > > > compiler minimum and C version for compiling up DP= DK itself,
> but I
> > > > > think we
> > > > > should not mandate that for the end applications.<= br> > > > >
> > > > Why not?
> > > >
> > > > And do you consider this backwards compatibility a buil= d time or
> run
> > > time requirement?
> > > >
> > > > >
> > > > > That means that our header files, such as atomics,= should not
> > > require
> > > > > C99
> > > > > or C11 even if the build of DPDK itself does. More=
> specifically,
> > > even
> > > > > if we
> > > > > bump DPDK minimum to C11, we should still allow ap= ps to build
> using
> > > > > older
> > > > > compiler settings.
> > > > >
> > > > > Therefore, we probably need to maintain non-C11 at= omics code
> paths
> > > in
> > > > > headers beyond the point at which DPDK itself uses= C11 as a
> code
> > > > > baseline.
> > > >
> > > > Am I misunderstanding your suggestion here: Code can be= C11, but
> all
> > > APIs and header files must be C89?
> > > >
> > > > Wouldn't that also prevent DPDK inline functions fr= om being C11?
> > > >
> > > Yes, it would.
> > >
> > > Now, perhaps we don't need to ensure that our headers ha= ve strict
> C89
> > > compatibility, but I think we need to be very careful about<= br> > mandating
> > > that
> > > end-user apps use particular c standard settings when compil= ing
> their
> > > own
> > > code.
> >
> > I get your point, Bruce, but I disagree.
> >
> > There should be a limit for how backwards compatible we want DPDK= to
> be, and the limit should certainly not be C89. It might be C99 for a > while, but it should soon be C11.
> >
> > If someone is stuck with a very old C compiler, and already rely = on
> (extended) LTS for their compiler and runtime environment, why would > they expect bleeding edge DPDK to cater for them? They can use some ol= d
> DPDK version and rely on DPDK LTS.
> >
> > If you want to use an old compiler, you often have to use old
> libraries too, as new libraries often require newer compilers. This > also applies to the Linux kernel. I don't see why DPDK should be a= ny
> different.
> >
> > But... DPDK LTS is only two years!?! My point is: What you are > describing is not a DPDK problem, it is a DPDK LTS policy problem.
> >
>
> I don't see it as a compiler problem, but as a codebase one. It do= esn't
> matter if your compiler supports C11 if your codebase is using legacy<= br> > features from C89 that are no longer supported by later versions.
> Changing
> compilers can be tricky, but updating a large legacy code-base is a > much
> more challenging proposition. There is a lot of old code out there in<= br> > the
> world!

OK. But my same argument applies: Why would you need to use a brand new DPD= K release in your project when the rest of your code base is ancient? In th= at case, you should rely on DPDK LTS.

>
> That said, I would hope that there are few large codebases out there > that
> won't compile with a C99 or C11 standard language level, and there=
> aren't
> that many things that should cause problems. However, I don't real= ly
> know for
> sure, so urge caution.
>
> /Bruce

--00000000000005330105f225ea35--