> From: Stanisław Kardach [mailto:k...@semihalf.com] > Sent: Thursday, 16 November 2023 00.21 > > On Wed, Nov 15, 2023 at 10:31 PM Morten Brørup > <m...@smartsharesystems.com> wrote: > > > > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > > > 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: m...@semihalf.com > > > Cc: sta...@dpdk.org > > > Signed-off-by: Tyler Retzlaff <roret...@linux.microsoft.com> > > > --- > > > > Reviewed-by: Morten Brørup <m...@smartsharesystems.com> > > > > 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 <k...@semihalf.com> > > > > > 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
