From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Tyler Retzlaff" <roretzla@linux.microsoft.com>,
"Stephen Hemminger" <stephen@networkplumber.org>
Cc: <dev@dpdk.org>
Subject: RE: RFC acceptable handling of VLAs across toolchains
Date: Wed, 8 Nov 2023 09:19:37 +0100 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9EFED@smartserver.smartshare.dk> (raw)
In-Reply-To: <20231108032504.GB19492@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Wednesday, 8 November 2023 04.25
>
> On Tue, Nov 07, 2023 at 06:31:14PM -0800, Stephen Hemminger wrote:
> > On Tue, 7 Nov 2023 11:32:20 -0800
> > Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
> >
> > > hi folks,
> > >
> > > i'm seeking advice. we have use of VLAs which are now optional in
> > > standard C. some toolchains provide a conformant implementation and
> msvc
> > > does not (and never will).
Just so everyone is on the same page... this is a VLA (Variable Length Array):
void f(int n) {
int v[n]; // VLA: its size is determined at run-time.
}
> > >
> > > we seem to have a few options, just curious about what people would
> > > prefer.
> > >
> > > * use alloca
VLAs have the advantage that they are allocated on the stack, which usually means that the memory is already present in the CPU's L1 cache (or L2 cache if using a larger block of memory).
It seems alloca() also allocates on the stack, so alloca() should provide similar performance.
> > >
> > > * use dynamically allocated storage
This would probably have lower performance than alloca() due to using "cold" memory, as opposed to memory on the stack.
And it needs to be explicitly freed again, which is somewhat annoying, compared to automatically freed memory.
> > >
> > > * conditional compiled code where the msvc leg uses one of the
> previous
> > > two options
I agree with Stephen on this: Whatever VLA alternative we choose for MSVC, other compilers can use that too. There is no need for #ifdefs to keep VLAs for other compilers.
> > >
> > > i'll leave it simple for now, i'd like to hear input rather than
> provide
> > > a recommendation for now.
> > >
> >
> > VLAs are a bug magnet. Best to avoid them, most code doesn't need
> them.
>
> just in case i didn't clarify properly early when i said they were
> optional i meant they used to be non-optional.
VLAs were standard in C99, and became optional in C11.
> the intent of the RFC
> here isn't that i want to add more but i'm looking for the best
> approach
> to getting rid of the ones we already have.
> > The one common use case is code that accepts a burst of packets.
> > But such code could easily have an upper bound if necessary.
Exactly!
I suggest that we forbid the use of VLAs.
For fast path code, constant-size arrays should be strongly recommended.
For non-fast path code, use alloca() or whatever VLA alternative is convenient on a case-by-case basis.
Perhaps checkpatches can detect the use of VLAs? Or it could be updated to check for them.
For reference, VLAs are forbidden in the Linux Kernel [1]. A good excuse for also forbidding them in DPDK. ;-)
[1]: https://www.phoronix.com/news/Linux-Kills-The-VLA
> >
> > Please don't add more to the maze of #ifdef's
>
> thanks! i'll keep this in mind.
next prev parent reply other threads:[~2023-11-08 8:19 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-07 19:32 Tyler Retzlaff
2023-11-08 2:31 ` Stephen Hemminger
2023-11-08 3:25 ` Tyler Retzlaff
2023-11-08 8:19 ` Morten Brørup [this message]
2023-11-08 16:51 ` Stephen Hemminger
2023-11-08 17:48 ` Morten Brørup
2023-11-09 10:25 ` RFC: default burst sizes in rte_config Morten Brørup
2023-11-09 20:26 ` RFC acceptable handling of VLAs across toolchains Tyler Retzlaff
2024-03-21 0:12 ` Tyler Retzlaff
2024-04-04 17:15 ` [PATCH 0/4] RFC samples converting VLA to alloca Tyler Retzlaff
2024-04-04 17:15 ` [PATCH 1/4] latencystats: use alloca instead of vla trivial Tyler Retzlaff
2024-04-06 15:28 ` Morten Brørup
2024-04-07 9:36 ` Mattias Rönnblom
2024-04-07 17:00 ` Stephen Hemminger
2024-04-04 17:15 ` [PATCH 2/4] hash: " Tyler Retzlaff
2024-04-06 16:01 ` Morten Brørup
2024-04-04 17:15 ` [PATCH 3/4] vhost: use alloca instead of vla sizeof Tyler Retzlaff
2024-04-06 22:30 ` Morten Brørup
2024-04-04 17:15 ` [PATCH 4/4] dispatcher: use alloca instead of vla multi dimensional Tyler Retzlaff
2024-04-06 15:49 ` Morten Brørup
2024-04-07 9:31 ` [PATCH 0/4] RFC samples converting VLA to alloca Mattias Rönnblom
2024-04-07 11:07 ` Morten Brørup
2024-04-07 17:03 ` Stephen Hemminger
2024-04-08 15:27 ` Tyler Retzlaff
2024-04-08 15:53 ` Morten Brørup
2024-04-09 8:28 ` Konstantin Ananyev
2024-04-09 15:08 ` Tyler Retzlaff
2024-04-10 9:58 ` Konstantin Ananyev
2024-04-10 17:03 ` Tyler Retzlaff
2024-04-10 7:32 ` Mattias Rönnblom
2024-04-10 7:52 ` Morten Brørup
2024-04-10 17:04 ` Tyler Retzlaff
2024-04-10 7:27 ` Mattias Rönnblom
2024-04-10 17:10 ` Tyler Retzlaff
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=98CBD80474FA8B44BF855DF32C47DC35E9EFED@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=dev@dpdk.org \
--cc=roretzla@linux.microsoft.com \
--cc=stephen@networkplumber.org \
/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).