From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Thomas Monjalon <thomas@monjalon.net>,
Tyler Retzlaff <roretzla@linux.microsoft.com>
Cc: "Bruce Richardson" <bruce.richardson@intel.com>,
"Stephen Hemminger" <stephen@networkplumber.org>,
david.marchand@redhat.com, dev@dpdk.org,
"Morten Brørup" <mb@smartsharesystems.com>,
honnappa.nagarahalli@arm.com, jerinj@marvell.com,
ktraynor@redhat.com, maxime.coquelin@redhat.com
Subject: Re: [PATCH v2 1/2] eal: provide leading and trailing zero bit count abstraction
Date: Tue, 10 Jan 2023 09:18:44 +0000 [thread overview]
Message-ID: <822b122f-6664-c399-1a2d-1bc40fdd4356@amd.com> (raw)
In-Reply-To: <2092862.OBFZWjSADL@thomas>
On 1/6/2023 8:51 PM, Thomas Monjalon wrote:
> 06/01/2023 19:58, Tyler Retzlaff:
>> On Fri, Jan 06, 2023 at 02:40:59PM +0100, Thomas Monjalon wrote:
>>> 06/01/2023 13:41, Morten Brørup:
>>>>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>>>>> Sent: Friday, 6 January 2023 12.48
>>>>>
>>>>> On Thu, Jan 05, 2023 at 04:32:40PM -0800, Stephen Hemminger wrote:
>>>>>> On Thu, 5 Jan 2023 09:21:18 -0800
>>>>>> Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
>>>>>>
>>>>>>> On Thu, Jan 05, 2023 at 10:01:31AM +0100, Thomas Monjalon wrote:
>>>>>>>> 05/01/2023 08:09, Morten Brørup:
>>>>>>>>>> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
>>>>>>>>>> +/**
>>>>>>>>>> + * @warning
>>>>>>>>>> + * @b EXPERIMENTAL: this API may change, or be removed,
>>>>> without prior
>>>>>>>>>> notice
>>>>>>>>>> + *
>>>>>>>>>> + * Get the count of leading 0-bits in v.
>>>>>>>>>> + *
>>>>>>>>>> + * @param v
>>>>>>>>>> + * The value.
>>>>>>>>>> + * @return
>>>>>>>>>> + * The count of leading zero bits.
>>>>>>>>>> + */
>>>>>>>>>> +__rte_experimental
>>>>>>>>>> +static inline unsigned int
>>>>>>>>>> +rte_clzl(unsigned long v)
>>>>>>>>>
>>>>>>>>> Don't use l (long) and ll (long long) for names (and types),
>>>>> use explicit bit lengths, 32 and 64.
>>>>>>>>>
>>>>>>>>> E.g.: rte_clz32(uint32_t v)
>>>>>>>>
>>>>>>>> I agree on using numbers.
>>>>>>>>
>>>>>>>
>>>>>>> love the idea, fewer functions too.
>>>>>>>
>>>>>>> though it is a shame we cannot adopt C11 standard because we could
>>>>> just
>>>>>>> do away with the bit suffixes entirely.
>>>>>>
>>>>>> We could but the project needs to support older RHEL releases
>>>>>> which have older tool sets. Though probably this is moot point given
>>>>>> how much meson seems to change.
>>>>>
>>>>> True, though meson tends to be a bit easier to update than GCC on a
>>>>> system
>>>>> - no "pip3 install --upgrade gcc", sadly :-)
>>>>>
>>>>> If we can't go all the way to C11 support, how about at least going to
>>>>> C99
>>>>> support? As far as I know DPDK has never updated its minimum C-standard
>>>>> version, and it might be a good idea to start the process of doing so,
>>>>> even
>>>>> if it is a baby step.
>>>
>>> I am in favor of this baby step: define -std=c99 porject-wise
>>> and see what are the effects during the year.
>>>
>>>
>>>> The DPDK Getting Started Guide [1] says:
>>>>
>>>> "Required Tools and Libraries:
>>>> [...]
>>>> a supported C compiler such as gcc (version 4.9+)"
>>>>
>>>> GCC version 4.9 supports C11 [2]:
>>>> "GCC 4.9 Changes: "ISO C11 support is now at a similar level of completeness to ISO C99 support [...]"
>>>>
>>>> So why are we not going to support C11?
>>>
>>> We should make a plan to switch to C11 during next year.
>>>
>>>
>>>> Probably because of RHEL 7, which only provides GCC 4.8 [3].
>>>>
>>>> RHEL 7 was released for GA on June 10, 2014 [4]. If someone has a server with a nine year old distro still used in production, it is probably because it is running some legacy application, which is difficult to get up and running on a newer distro. Partial conclusion: RHEL 7 is probably still widely used in production.
>>>>
>>>> However, I have a hard time understanding why anyone would build and/or deploy a brand new DPDK application (based on DPDK 23.03) on such a server. Can someone please justify this?
>>>>
>>>> Are we really going to postpone C11 support in DPDK until June 30, 2026, when RHEL 7 ends its Extended Life Cycle Support [4]?
>>>
>>> RHEL does its own choices to support old software for long.
>>> Upstream development should move forward.
>>>
>>>
>>>> If so, then the GCC version mentioned in the DPDK Getting Started Guide should be corrected accordingly.
>>>
>>> No let's keep GCC 4.9 as a minimum for now.
>>> If needed we could upgrade it later.
>>
>> but i think the point Morten is making is that RHEL 7 gcc is 4.8 and
>> therefore we implicitly no longer support it if we document requiring
>> gcc 4.9.
>
> Yes I got it.
> I think everything in DPDK works on RHEL 7 today,
> but I believe RHEL 7 is not a strong requirement anymore for the mainline.
> Asking for confirmation here.
>
>> so i think the way to do this is through clarification at the next
>> release / ltsc release. starting with dpdk 23.xx will require
>> compiler conforming to standard X and optional features / annexes from
>> standard X. anyone building applications targeting that version of dpdk
>> release will need a conforming implementation.
>>
>> from there we just need to take care not to backport any code to
>> stable branches that depend on standard features that exceed the
>> requirements documented for that release.
>
> We could even start testing C99 requirement in 23.03 I think.
>
>
I missed discussion in this thread, but replied in other thread,
replying here too.
+1 to switch C99 support.
There are bunch of C99 features used within DPDK already, and there were
some drivers compiled with c89 support, that restriction is removed now,
so it should be OK to move to C99 support.
next prev parent reply other threads:[~2023-01-10 9:18 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 22:14 [PATCH 0/2] eal: provide leading and trailing zero bit count Tyler Retzlaff
2022-11-23 22:14 ` [PATCH 1/2] eal: provide leading and trailing zero bit count abstraction Tyler Retzlaff
2023-04-03 21:46 ` Mattias Rönnblom
2022-11-23 22:14 ` [PATCH 2/2] test/bitcount: add bitcount tests Tyler Retzlaff
2022-11-23 23:43 ` [PATCH v2 0/2] eal: provide leading and trailing zero bit count Tyler Retzlaff
2022-11-23 23:43 ` [PATCH v2 1/2] eal: provide leading and trailing zero bit count abstraction Tyler Retzlaff
2022-11-24 10:17 ` Morten Brørup
2022-11-28 17:13 ` Tyler Retzlaff
2022-11-28 17:22 ` Morten Brørup
2022-11-28 17:27 ` Tyler Retzlaff
2023-01-05 9:04 ` Thomas Monjalon
2023-01-05 17:23 ` Tyler Retzlaff
2023-01-05 17:27 ` Tyler Retzlaff
2023-01-05 20:57 ` Tyler Retzlaff
2023-01-05 21:34 ` Morten Brørup
2023-01-05 22:06 ` Tyler Retzlaff
2023-01-05 23:10 ` Morten Brørup
2023-01-06 1:04 ` Tyler Retzlaff
2023-01-06 10:09 ` Thomas Monjalon
2023-01-06 10:00 ` Thomas Monjalon
2023-01-05 7:09 ` Morten Brørup
2023-01-05 9:01 ` Thomas Monjalon
2023-01-05 17:21 ` Tyler Retzlaff
2023-01-06 0:32 ` Stephen Hemminger
2023-01-06 11:48 ` Bruce Richardson
2023-01-06 12:41 ` Morten Brørup
2023-01-06 13:40 ` Thomas Monjalon
2023-01-06 18:58 ` Tyler Retzlaff
2023-01-06 20:51 ` Thomas Monjalon
2023-01-10 9:18 ` Ferruh Yigit [this message]
2023-01-06 18:47 ` Tyler Retzlaff
2023-01-09 8:50 ` Bruce Richardson
2023-04-04 21:23 ` Tyler Retzlaff
2023-04-05 8:44 ` Bruce Richardson
2023-04-05 15:22 ` Tyler Retzlaff
2023-04-05 15:51 ` Bruce Richardson
2023-04-05 17:25 ` Tyler Retzlaff
2022-11-23 23:43 ` [PATCH v2 2/2] test/bitcount: add bitcount tests Tyler Retzlaff
2023-01-04 23:46 ` [PATCH v2 0/2] eal: provide leading and trailing zero bit count Tyler Retzlaff
2023-01-09 17:36 ` [PATCH v4 0/2] eal: provide leading and trailing zero bit count abstraction Tyler Retzlaff
2023-01-09 17:36 ` [PATCH v4 1/2] eal: move bit operation functions from common to bitops header Tyler Retzlaff
2023-01-10 13:56 ` Ferruh Yigit
2023-01-09 17:36 ` [PATCH v4 2/2] eal: provide leading and trailing zero bit count abstraction Tyler Retzlaff
2023-01-10 13:55 ` Ferruh Yigit
2023-01-10 17:34 ` Tyler Retzlaff
2023-01-10 18:37 ` Tyler Retzlaff
2023-01-10 13:56 ` [PATCH v4 0/2] " Ferruh Yigit
2023-01-06 22:01 ` [PATCH v3 0/3] eal: provide leading and trailing zero bit count Tyler Retzlaff
2023-01-06 22:01 ` [PATCH v3 1/3] eal: move bit functions from common to bitops header Tyler Retzlaff
2023-01-06 22:01 ` [PATCH v3 2/3] eal: provide leading and trailing zero bit count abstraction Tyler Retzlaff
2023-01-06 22:01 ` [PATCH v3 3/3] test/bitcount: add bitcount tests Tyler Retzlaff
2023-01-07 8:15 ` Thomas Monjalon
2023-01-09 16:57 ` Tyler Retzlaff
2023-01-09 17:26 ` Tyler Retzlaff
2023-01-07 13:40 ` Morten Brørup
2023-01-09 8:51 ` [PATCH v3 0/3] eal: provide leading and trailing zero bit count Bruce Richardson
2023-01-10 19:38 ` [PATCH v5 0/2] eal: provide leading and trailing zero bit count abstraction Tyler Retzlaff
2023-01-10 19:38 ` [PATCH v5 1/2] eal: move bit operation common to bitops header Tyler Retzlaff
2023-01-10 19:38 ` [PATCH v5 2/2] eal: provide leading and trailing zero bit count abstraction Tyler Retzlaff
2023-01-10 19:46 ` [PATCH v6 0/2] " Tyler Retzlaff
2023-01-10 19:46 ` [PATCH v6 1/2] eal: move bit operation common to bitops header Tyler Retzlaff
2023-01-10 19:46 ` [PATCH v6 2/2] eal: provide leading and trailing zero bit count abstraction Tyler Retzlaff
2023-01-20 22:14 ` [PATCH v6 0/2] " Tyler Retzlaff
2023-02-02 9:14 ` David Marchand
2023-02-02 10:56 ` David Marchand
2023-02-02 15:57 ` Tyler Retzlaff
2023-02-03 9:14 ` David Marchand
2023-02-02 15:56 ` Tyler Retzlaff
2023-02-03 9:21 ` David Marchand
2023-04-01 0:45 ` [PATCH v7 0/4] eal: provide abstracted bit counting functions Tyler Retzlaff
2023-04-01 0:45 ` [PATCH v7 1/4] eal: move bit count functions to bitops header Tyler Retzlaff
2023-04-01 0:45 ` [PATCH v7 2/4] eal: provide abstracted bit count functions Tyler Retzlaff
2023-04-01 0:45 ` [PATCH v7 3/4] pipeline: add include of bitops Tyler Retzlaff
2023-04-01 0:45 ` [PATCH v7 4/4] maintainers: add bitcount test under EAL API and common code Tyler Retzlaff
2023-04-01 7:08 ` [PATCH v7 0/4] eal: provide abstracted bit counting functions Morten Brørup
2023-04-04 0:11 ` [PATCH v8 0/3] " Tyler Retzlaff
2023-04-04 0:11 ` [PATCH v8 1/3] eal: move bit count functions to bitops header Tyler Retzlaff
2023-04-04 0:11 ` [PATCH v8 2/3] eal: provide abstracted bit count functions Tyler Retzlaff
2023-04-04 0:11 ` [PATCH v8 3/3] maintainers: add bitcount test under EAL API and common code Tyler Retzlaff
2023-04-04 8:27 ` [PATCH v8 0/3] eal: provide abstracted bit counting functions Bruce Richardson
2023-08-25 8:41 ` David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=822b122f-6664-c399-1a2d-1bc40fdd4356@amd.com \
--to=ferruh.yigit@amd.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=honnappa.nagarahalli@arm.com \
--cc=jerinj@marvell.com \
--cc=ktraynor@redhat.com \
--cc=maxime.coquelin@redhat.com \
--cc=mb@smartsharesystems.com \
--cc=roretzla@linux.microsoft.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).