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 0973B423C5; Fri, 13 Jan 2023 17:10:48 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CB37C410D4; Fri, 13 Jan 2023 17:10:47 +0100 (CET) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) by mails.dpdk.org (Postfix) with ESMTP id 5231940E03 for ; Fri, 13 Jan 2023 17:10:46 +0100 (CET) Received: by mail-vs1-f47.google.com with SMTP id 186so17396022vsz.13 for ; Fri, 13 Jan 2023 08:10:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=L/Wmqr5nSx7+y6YVsr49RMa1KBtH63A+kdCDHB0YqPI=; b=Dul8n4gDX06BwBbqich7JyRT7ylIpOMtyoEDK38q4Olk3Gf1QFZ21gCaKxdVernrZz hT7vClWk3lEBPxv8s4tbpv85GpAo6ShvTPU89u68DXghF8kZhRo7W3lvmm2pkaIlanP3 lOx/7wAou4bxs/eW57zloKblyT09e8o0cj/vUVXQHx26O9xTEXOruPyvuVy3BENSg6fN s5y0mz2nW+9MMG/7SGlcRHgcBQzk3z0H/iWx6s8C9tZum4cZ0DADVAypxDcuH3IG51hf b9Ggaacep3prxKKpjOOfo3mz5jlIk3AOrhoCyPN/N06F/v+vmig20sWhg7JdWZR92Krr JP6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=L/Wmqr5nSx7+y6YVsr49RMa1KBtH63A+kdCDHB0YqPI=; b=1+4XQ6icO0hSjzZPRTuOHY806VnmNY1yjINr/fASV6M1GESJj6DcS/7lUoVBFbuQM7 YRijlwl1pEGZogH8XY57Wtn0ivK/u/W9sQdMlrdr9JWfXL1C1PWuzss+9TBX3OxR3stn HdxSztiIlethzKZg8b26QxXYUNRj5NoP9MHfmBZTSNtvaET2bE0zGRydWu+wgKMzOoSF qv/Za0jPhqInD0flAf5/q0PFEy9Ympk09NP/zDc5la1i1a9bIE0A7SZUg332oXspa8sh qdFBlB9LHpEYC6Oqw3JrpTMiG4ZE+UjpPyelHkAjJIQMZermnuAc4HWy1/cq9CP43Y6s HAFg== X-Gm-Message-State: AFqh2kpi0Fd0UufGqlUsO/AVXQwn3n78CbGB0zAla9abrJT/ct7sffUw MKWdym5JBdGXSwAkDNt4L8IFGTOYyhBF3ev3Nhd1QrGGgOLJw1qfjaU= X-Google-Smtp-Source: AMrXdXtCv66gh4wXNqpR7Ag1ak+7yUjDo3oDnOXogK+NZXYtEP0Rn1DY/gBtogPwKxNaL2tQYC7OrchWZEs5FgGuteU= X-Received: by 2002:a67:ae45:0:b0:3d0:c96e:25ac with SMTP id u5-20020a67ae45000000b003d0c96e25acmr1981736vsh.73.1673626245443; Fri, 13 Jan 2023 08:10:45 -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: From: Jerin Jacob Date: Fri, 13 Jan 2023 21:40:20 +0530 Message-ID: Subject: Re: RFC abstracting atomics To: Ben Magistro Cc: =?UTF-8?Q?Morten_Br=C3=B8rup?= , Bruce Richardson , Tyler Retzlaff , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Fri, Jan 13, 2023 at 7:49 PM Ben Magistro wrote: > > As a user/developer I'll put a vote on Morten's side here. There are oth= er libraries we utilize that have stated x.y.z is the last version that wil= l support w, beginning on version l.m.n it will be standard o. I personall= y don't think a project asking for C11 support at a minimum would be unreas= onable or overly burdensome. +1 Instead of polluting new DPDK code for legacy applications(If some reason they want absolutely want to move latest and greatest DPDK), I think it should be possible for legacy application selectivity turning on/of like "#pragma GCC diagnostic warning "-std=3Dc++11" or worst case move DPDK function in wrapper(which is already case in most of the applications) in their app and compile the wrapper only with C11 > > 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 old= est LTS, 20.11 (and current 22.11 which includes some older OS not on the 2= 0.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 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 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 >>