> > > > 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. > > Konstantin
Just my 2c on the 3 options. 1) What's the right max size? I don't know, so I would rather leave this for the user. 2) I prefer this option over (1) due to above reason. 3) ring itself is tricky specially under relaxed memory, RCU Is already complex. So, I would rather keep them separate. So, I prefer alloca() option. Thanks --wathsala
