On Mon, Feb 26, 2024 at 8:17 PM Morten Brørup <m...@smartsharesystems.com> wrote: > > > From: Jerin Jacob [mailto:jerinjac...@gmail.com] > > Sent: Monday, 26 February 2024 09.34 > > > > On Fri, Feb 23, 2024 at 7:30 PM Morten Brørup <m...@smartsharesystems.com> > > wrote: > > > > > > Bugfix: The vlan in the bulletin does not contain a VLAN header, only > > the > > > VLAN ID, so only copy 2 byte, not 4. The target structure has padding > > > after the field, so copying 2 byte too many is effectively harmless. > > > There is no need to backport this patch. > > > > > > Use RTE_PTR_ADD where copying arrays to the offset of a first field in > > a > > > structure holding multiple fields, to avoid compiler warnings with > > > decorated rte_memcpy. > > > > > > Bugzilla ID: 1146 > > > > > > Fixes: 540a211084a7695a1c7bc43068934c140d6989be ("bnx2x: driver core") > > > Cc: step...@networkplumber.org > > > Cc: rm...@marvell.com > > > Cc: shsha...@marvell.com > > > Cc: pa...@marvell.com > > > > > > Signed-off-by: Morten Brørup <m...@smartsharesystems.com> > > > Acked-by: Devendra Singh Rawat <dsinghra...@marvell.com> > > > --- > > > v9: > > > * Fix checkpatch warning about spaces. > > > > Fixed the following issues[1] and updated the git commit as follows > > and applied to dpdk-next-net-mrvl/for-main. Thanks > > Thank you, Jerin. > > [...] > > > Is it candidate for Cc: sta...@dpdk.org backport? > > No, I don't think so: > 1. The extra 2 byte copy is effectively harmless due to padding, as mentioned > in the commit message. > 2. The decorated rte_memcpy (if work on that patch series is ever resumed) is > an improvement, not a bug fix, and will not be backported. So the memcpy > parts of this patch are irrelevant for the stable versions.
Shall remove Fixes: tag then?. Since the patch has a Fixes tag, I thought good to merge to stable as it is fixing. Also, could you comment on @Stephen Hemminger latest comments, Should I wait for new version? or new changes can go as separate patches. >
