> From: Stanisław Kardach [mailto:[email protected]] > Sent: Thursday, 16 November 2023 00.21 > > On Wed, Nov 15, 2023 at 10:31 PM Morten Brørup > <[email protected]> wrote: > > > > > From: Tyler Retzlaff [mailto:[email protected]] > > > Sent: Wednesday, 15 November 2023 22.17 > > > > > > Fix the alignment for rte_xmm_t it should be 16 instead of 8 bytes. > > > > > > Fixes: f22e705ebf12 ("eal/riscv: support RISC-V architecture") > > > Cc: [email protected] > > > Cc: [email protected] > > > Signed-off-by: Tyler Retzlaff <[email protected]> > > > --- > > > > Reviewed-by: Morten Brørup <[email protected]> > > > > As mentioned in the other thread: > > > > We need to urgently decide if this bug should live on in DPDK 23.11, > or if the fix should be included although we are very late in the > release process. > > > > Stanislaw, what do you think? > Good catch! As for backporting I'm not sure of the urgency given that > our examples still use scalar instructions for handling xmm_t. The > question is whether there is a platform in use which has vector > extensions enabled and that utilizes DPDK. I'm not that sure of it > though I'd be happy to be proven wrong.
Can we extrapolate this, and also conclude that postponing this bugfix until the next ABI/API breaking release, DPDK 24.11, is not really going to hurt anyone? Stanislaw, please confirm? Bruce, I don't feel 100 % confident in making this postponement recommendation. Could you please provide a second opinion regarding the timing of fixing this bug? Or rather: do you have any strong arguments *against* postponing it to DPDK 24.11? > > Reviewed-by: Stanislaw Kardach <[email protected]> > > > > > Furthermore, I wonder if it can be backported to stable, and to what > extent backporting it would break the ABI/API. Based on your input regarding the current deployment status, backporting the bugfix clearly isn't worth the effort. Excellent! > > > > > -- > Best Regards, > Stanisław Kardach
