> > > > As per guidance technical board meeting 2024/04/17. This series
> > > > removes the use of VLAs from code built for Windows for all 3
> > > > toolchains. If there are additional opportunities to convert VLAs
> > > > to regular C arrays please provide the details for incorporation
> > > > into the series.
> > > >
> > > > MSVC does not support VLAs, replace VLAs with standard C arrays
> > > > or alloca(). alloca() is available for all toolchain/platform
> > > > combinations officially supported by DPDK.
> > >
> > > - I have one concern wrt patch 7.
> > > This changes the API/ABI of the RCU library.
> > > ABI can't be broken in the 25.03 release.
> > >
> > > Since MSVC builds do not include RCU yet, I skipped this change and
> > > adjusted this libray meson.build.
> > >
> > > Konstantin, do you think patch 7 could be rewritten to make use of
> > > alloca() and avoid an API change?
> > > https://patchwork.dpdk.org/project/dpdk/patch/1738805610-17507-8-git-send-email-andre...@linux.microsoft.com/
> >
> > I am not big fan of alloca() approach, but yes it is surely possible.
> 
> Can you please explain your reluctance?

Mostly conceptual: using alloca() doesn't really differ from simply using VLA,
in fact it makes code looks uglier.
I understand that we do want MSVC enabled, and in many cases such mechanical
replacement is ok, but probably better to avoid  it whenever possible.  

> 
> 
> > BTW, why it is considered ad API/ABI change?
> > Because we introduce extra limit on max allowable size?
> 
> Yes, this is what was mentionned in the commitlog.
> 
> 
> > If that would help somehow, we can make it even bigger: 1K or so.
> 
> Strictly speaking, it is still an API change.
 
Ok, then I suppose we have 3 options:
1) wait for 25.11 to apply these changes
2) use alloca()
3) come-up with some smarter approach.

For 3) - I don't have any good ideas right now.
One option would be to allow ring_enqueue/ring_dequeue to accept custom 
copy_elem() functions as a parameter.
That would solve an issue, as in that case we wouldn't need to make temp copy 
of data on the stack,
but that's probably too big changes for such small thing.
So I am ok with both 1) and 2).
In fact - it is probably possible to go with 2) for now, and then switch to 1) 
or 3) in 25.11

Reply via email to