[PATCH] rcu: add deprecation notice about limit on defer queue element size

[Thomas Monjalon]

14/07/2025 11:01, Konstantin Ananyev:
> > 10/07/2025 16:37, Andre Muezerie:
> > > On Tue, Jul 01, 2025 at 04:17:20PM +0200, Thomas Monjalon wrote:
> > > > 23/05/2025 01:37, Andre Muezerie:
> > > > > The functions rte_rcu_qsbr_dq_create and rte_rcu_qsbr_dq_reclaim establish
> > > > > no limit on the size of each element in the defer queue.
> > > >
> > > > Very good, we need more unlimited API in DPDK.
> > > >
> > > > > With DPDK 25.11 a hard limit will be set (``RTE_QSBR_ESIZE_MAX``).
> > > >
> > > > I think it is a step in the wrong direction.
> > > > I prefer having no limit.
> > > >
> > > > > This will allow fixed C arrays to be used in the functions' implementations,
> > > > > avoiding VLAs and use of alloca().
> > > >
> > > > I don't understand this justification.
> > > > Why trying to remove the 2 alloca() in the lib RCU?
> > > >
> > >
> > > Only because other developer expressed concerns that using alloca() allows
> > > ill-intended callers to cause a stack overflow.
> > > I personally also prefer to have no hardcoded limits.
> > 
> > Yes I vote for keeping alloca().
> 
> Probably it was me who expressed some concerns, sorry for late reply.
> I can only repeat what I already replied to David:
>  
> For that particular case, my reasons are 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. 
> 
>  suppose we have 3 options:
> 1) use predefined max value (it could be quite big to fit any reasonable usage, let say 1KB or so).
> 2) use alloca().
> 3) come-up with some smarter approach.
> 
> For 3) - I don't have any good ideas.
> One option would be to create that ring RING_F_MP_HTS_ENQ  flags,
> then we can use peek API  for enqueue part too (rte_ring_enqueue_bulk_elem_start).
> That would solve an issue, as in that case we wouldn't need to make temp copy of data on the stack.
> My preference would be either 1) or 3), but I could leave with 2) too - specially that I don't really use that part of RCU lib.
> Would be really good to hear opinion of RCU lib maintainer.

Looks like this new constraint is not encouraged a lot.

Per our policy, it will miss the release 25.07.
It means we will stay with alloca() for now.