[v9] net/bnx2x: fix warnings about rte_memcpy lengths
Checks
Commit Message
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: stephen@networkplumber.org
Cc: rmody@marvell.com
Cc: shshaikh@marvell.com
Cc: palok@marvell.com
Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Devendra Singh Rawat <dsinghrawat@marvell.com>
---
v9:
* Fix checkpatch warning about spaces.
v8:
* Use memcpy instead of rte_memcpy in slow path. (Stephen Hemminger)
v7:
* No changes.
v6:
* Add Fixes to patch description.
* Fix checkpatch warnings.
v5:
* No changes.
v4:
* Type casting did not fix the warnings, so use RTE_PTR_ADD instead.
v3:
* First patch in series.
---
drivers/net/bnx2x/bnx2x_stats.c | 14 ++++++++------
drivers/net/bnx2x/bnx2x_vfpf.c | 14 +++++++-------
2 files changed, 15 insertions(+), 13 deletions(-)
Comments
On Fri, Feb 23, 2024 at 7:30 PM Morten Brørup <mb@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: stephen@networkplumber.org
> Cc: rmody@marvell.com
> Cc: shshaikh@marvell.com
> Cc: palok@marvell.com
>
> Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Devendra Singh Rawat <dsinghrawat@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
net/bnx2x: fix warnings about memcpy lengths
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.
Fix it by using generic memcpy version instead of specialized
rte version as it not used in fast path.
Also, 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 memcpy.
Bugzilla ID: 1146
Fixes: 540a211084a7 ("bnx2x: driver core")
Cc: stable@dpdk.org
Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Devendra Singh Rawat <dsinghrawat@marvell.com>
[1]
Wrong headline format:
net/bnx2x: fix warnings about rte_memcpy lengths
Wrong tag:
Bugfix: The vlan in the bulletin does not contain a VLAN
header, only the
Is it candidate for Cc: stable@dpdk.org backport?
net/bnx2x: fix warnings about rte_memcpy lengths
Invalid patch(es) found - checked 1 patch
check-git-log failed
### [PATCH] net/bnx2x: fix warnings about rte_memcpy lengths
WARNING:BAD_FIXES_TAG: Please use correct Fixes: style 'Fixes: <12
chars of sha1> ("<title line>")' - ie: 'Fixes: 540a211084a7 ("bnx2x:
driver core")'
#20:
Fixes: 540a211084a7695a1c7bc43068934c140d6989be ("bnx2x: driver core")
total: 0 errors, 1 warnings, 0 checks, 76 lines checked
0/1 valid patch
checkpatch failed
> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> Sent: Monday, 26 February 2024 09.34
>
> On Fri, Feb 23, 2024 at 7:30 PM Morten Brørup <mb@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: stephen@networkplumber.org
> > Cc: rmody@marvell.com
> > Cc: shshaikh@marvell.com
> > Cc: palok@marvell.com
> >
> > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > Acked-by: Devendra Singh Rawat <dsinghrawat@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: stable@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.
On Fri, 23 Feb 2024 15:00:56 +0100
Morten Brørup <mb@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: stephen@networkplumber.org
> Cc: rmody@marvell.com
> Cc: shshaikh@marvell.com
> Cc: palok@marvell.com
>
> Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Devendra Singh Rawat <dsinghrawat@marvell.com>
> ---
> v9:
> * Fix checkpatch warning about spaces.
> v8:
> * Use memcpy instead of rte_memcpy in slow path. (Stephen Hemminger)
> v7:
> * No changes.
> v6:
> * Add Fixes to patch description.
> * Fix checkpatch warnings.
> v5:
> * No changes.
> v4:
> * Type casting did not fix the warnings, so use RTE_PTR_ADD instead.
> v3:
> * First patch in series.
> ---
> drivers/net/bnx2x/bnx2x_stats.c | 14 ++++++++------
> drivers/net/bnx2x/bnx2x_vfpf.c | 14 +++++++-------
> 2 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/bnx2x/bnx2x_stats.c b/drivers/net/bnx2x/bnx2x_stats.c
> index c07b01510a..8105375d44 100644
> --- a/drivers/net/bnx2x/bnx2x_stats.c
> +++ b/drivers/net/bnx2x/bnx2x_stats.c
}
>
> @@ -817,10 +817,10 @@ bnx2x_hw_stats_update(struct bnx2x_softc *sc)
> etherstatspktsover1522octets);
> }
>
> - rte_memcpy(old, new, sizeof(struct nig_stats));
> + memcpy(old, new, sizeof(struct nig_stats));
This could just be structure assignment which is type safe.
*new = *old;
>
> - rte_memcpy(&(estats->rx_stat_ifhcinbadoctets_hi), &(pstats->mac_stx[1]),
> - sizeof(struct mac_stx));
> + memcpy(RTE_PTR_ADD(estats, offsetof(struct bnx2x_eth_stats, rx_stat_ifhcinbadoctets_hi)),
> + &pstats->mac_stx[1], sizeof(struct mac_stx));
> estats->brb_drop_hi = pstats->brb_drop_hi;
> estats->brb_drop_lo = pstats->brb_drop_lo;
>
> @@ -1492,9 +1492,11 @@ bnx2x_stats_init(struct bnx2x_softc *sc)
> REG_RD(sc, NIG_REG_STAT0_BRB_TRUNCATE + port*0x38);
> if (!CHIP_IS_E3(sc)) {
> REG_RD_DMAE(sc, NIG_REG_STAT0_EGRESS_MAC_PKT0 + port*0x50,
> - &(sc->port.old_nig_stats.egress_mac_pkt0_lo), 2);
> + RTE_PTR_ADD(&sc->port.old_nig_stats,
> + offsetof(struct nig_stats, egress_mac_pkt0_lo)), 2);
> REG_RD_DMAE(sc, NIG_REG_STAT0_EGRESS_MAC_PKT1 + port*0x50,
> - &(sc->port.old_nig_stats.egress_mac_pkt1_lo), 2);
> + RTE_PTR_ADD(&sc->port.old_nig_stats,
> + offsetof(struct nig_stats, egress_mac_pkt1_lo)), 2);
> }
>
> /* function stats */
> diff --git a/drivers/net/bnx2x/bnx2x_vfpf.c b/drivers/net/bnx2x/bnx2x_vfpf.c
> index 63953c2979..5411df3a38 100644
> --- a/drivers/net/bnx2x/bnx2x_vfpf.c
> +++ b/drivers/net/bnx2x/bnx2x_vfpf.c
> @@ -52,9 +52,9 @@ bnx2x_check_bull(struct bnx2x_softc *sc)
>
> /* check the mac address and VLAN and allocate memory if valid */
> if (valid_bitmap & (1 << MAC_ADDR_VALID) && memcmp(bull->mac, sc->old_bulletin.mac, ETH_ALEN))
> - rte_memcpy(&sc->link_params.mac_addr, bull->mac, ETH_ALEN);
> + memcpy(&sc->link_params.mac_addr, bull->mac, ETH_ALEN);
> if (valid_bitmap & (1 << VLAN_VALID))
> - rte_memcpy(&bull->vlan, &sc->old_bulletin.vlan, RTE_VLAN_HLEN);
> + memcpy(&bull->vlan, &sc->old_bulletin.vlan, sizeof(bull->vlan));
>
> sc->old_bulletin = *bull;
>
> @@ -569,7 +569,7 @@ bnx2x_vf_set_mac(struct bnx2x_softc *sc, int set)
>
> bnx2x_check_bull(sc);
>
> - rte_memcpy(query->filters[0].mac, sc->link_params.mac_addr, ETH_ALEN);
> + memcpy(query->filters[0].mac, sc->link_params.mac_addr, ETH_ALEN);
>
> bnx2x_add_tlv(sc, query, query->first_tlv.tl.length,
> BNX2X_VF_TLV_LIST_END,
> @@ -583,9 +583,9 @@ bnx2x_vf_set_mac(struct bnx2x_softc *sc, int set)
> while (BNX2X_VF_STATUS_FAILURE == reply->status &&
> bnx2x_check_bull(sc)) {
> /* A new mac was configured by PF for us */
> - rte_memcpy(sc->link_params.mac_addr, sc->pf2vf_bulletin->mac,
> + memcpy(sc->link_params.mac_addr, sc->pf2vf_bulletin->mac,
> ETH_ALEN);
> - rte_memcpy(query->filters[0].mac, sc->pf2vf_bulletin->mac,
> + memcpy(query->filters[0].mac, sc->pf2vf_bulletin->mac,
> ETH_ALEN);
>
> rc = bnx2x_do_req4pf(sc, sc->vf2pf_mbox_mapping.paddr);
> @@ -622,10 +622,10 @@ bnx2x_vf_config_rss(struct bnx2x_softc *sc,
> BNX2X_VF_TLV_LIST_END,
> sizeof(struct channel_list_end_tlv));
>
> - rte_memcpy(query->rss_key, params->rss_key, sizeof(params->rss_key));
> + memcpy(query->rss_key, params->rss_key, sizeof(params->rss_key));
> query->rss_key_size = T_ETH_RSS_KEY;
>
> - rte_memcpy(query->ind_table, params->ind_table, T_ETH_INDIRECTION_TABLE_SIZE);
> + memcpy(query->ind_table, params->ind_table, T_ETH_INDIRECTION_TABLE_SIZE);
> query->ind_table_size = T_ETH_INDIRECTION_TABLE_SIZE;
>
> query->rss_result_mask = params->rss_result_mask;
The driver is also using rte_memcpy for 2 byte values in bnx2x.c.
Another issue is the driver is using one element array as a flexible array.
A good static checker should catch this and report out of bounds access.
union bnx2x_stats_show_data {
uint32_t op; /* ioctl sub-command */
struct {
uint32_t num; /* return number of stats */
uint32_t len; /* length of each string item */
} desc;
/* variable length... */
char str[1]; /* holds names of desc.num stats, each desc.len in length */
/* variable length... */
uint64_t stats[1]; /* holds all stats */
};
On Mon, Feb 26, 2024 at 8:17 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> > Sent: Monday, 26 February 2024 09.34
> >
> > On Fri, Feb 23, 2024 at 7:30 PM Morten Brørup <mb@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: stephen@networkplumber.org
> > > Cc: rmody@marvell.com
> > > Cc: shshaikh@marvell.com
> > > Cc: palok@marvell.com
> > >
> > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > > Acked-by: Devendra Singh Rawat <dsinghrawat@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: stable@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.
>
+To: Raslan, regarding MLX5 patch
> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> Sent: Tuesday, 27 February 2024 12.01
>
> On Mon, Feb 26, 2024 at 8:17 PM Morten Brørup <mb@smartsharesystems.com>
> wrote:
> >
> > > From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> > > Sent: Monday, 26 February 2024 09.34
> > >
> > > On Fri, Feb 23, 2024 at 7:30 PM Morten Brørup <mb@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: stephen@networkplumber.org
> > > > Cc: rmody@marvell.com
> > > > Cc: shshaikh@marvell.com
> > > > Cc: palok@marvell.com
> > > >
> > > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > > > Acked-by: Devendra Singh Rawat <dsinghrawat@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: stable@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.
Although the patch formally fixes a bug, the bug is harmless, so I don't think it is worth the effort backporting.
I don't know the policy for Fixes: tags in such cases. However you proceed with it is perfectly fine with me.
>
> Also, could you comment on @Stephen Hemminger latest comments, Should
> I wait for new version? or new changes can go as separate patches.
I'm not providing a new version of this patch.
This patch was part of a series, where its rte_memcpy changes were required for the primary patch in the series [1]. The purpose of the primary patch was to tighten rte_memcpy's parameter requirements by adding access-mode attributes.
[1]: https://patchwork.dpdk.org/project/dpdk/patch/20230116130724.50277-4-mb@smartsharesystems.com/
It was not really my intention to fix other things in the drivers I submitted patches for. That was only a positive side effect. ;-)
@Raslan: Also, the patch for the mlx5 driver [2] has seen no progress for a year, so I'm going to abandon it. I will resume it if I start working on the decorated rte_memcpy again. Should I change it's state to Not Applicable or something else?
[2]: https://patchwork.dpdk.org/project/dpdk/patch/20230116130724.50277-3-mb@smartsharesystems.com/
On Tue, 27 Feb 2024 12:27:31 +0100
Morten Brørup <mb@smartsharesystems.com> wrote:
> > > 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.
The function rte_memcpy only exists because glibc and gcc version of memcpy
is not optimized enough. Would love to see it go away in future.
Hi,
> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Tuesday, February 27, 2024 1:28 PM
> To: Jerin Jacob <jerinjacobk@gmail.com>; Raslan Darawsheh
> <rasland@nvidia.com>
> Cc: julien_dpdk@jaube.fr; dev@dpdk.org; stephen@networkplumber.org;
> rmody@marvell.com; shshaikh@marvell.com; palok@marvell.com
> Subject: RE: [PATCH v9] net/bnx2x: fix warnings about rte_memcpy lengths
>
> +To: Raslan, regarding MLX5 patch
>
> > From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> > Sent: Tuesday, 27 February 2024 12.01
> >
> > On Mon, Feb 26, 2024 at 8:17 PM Morten Brørup
> > <mb@smartsharesystems.com>
> > wrote:
> > >
> > > > From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> > > > Sent: Monday, 26 February 2024 09.34
> > > >
> > > > On Fri, Feb 23, 2024 at 7:30 PM Morten Brørup
> > > > <mb@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: stephen@networkplumber.org
> > > > > Cc: rmody@marvell.com
> > > > > Cc: shshaikh@marvell.com
> > > > > Cc: palok@marvell.com
> > > > >
> > > > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > Acked-by: Devendra Singh Rawat <dsinghrawat@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: stable@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.
>
> Although the patch formally fixes a bug, the bug is harmless, so I don't think it
> is worth the effort backporting.
> I don't know the policy for Fixes: tags in such cases. However you proceed with
> it is perfectly fine with me.
>
> >
> > Also, could you comment on @Stephen Hemminger latest comments,
> Should
> > I wait for new version? or new changes can go as separate patches.
>
> I'm not providing a new version of this patch.
>
> This patch was part of a series, where its rte_memcpy changes were required
> for the primary patch in the series [1]. The purpose of the primary patch was
> to tighten rte_memcpy's parameter requirements by adding access-mode
> attributes.
>
> [1]:
> https://patchwork.dpdk.org/project/dpdk/patch/20230116130724.50277-
> 4-mb@smartsharesystems.com/
>
> It was not really my intention to fix other things in the drivers I submitted
> patches for. That was only a positive side effect. ;-)
>
> @Raslan: Also, the patch for the mlx5 driver [2] has seen no progress for a
> year, so I'm going to abandon it. I will resume it if I start working on the
> decorated rte_memcpy again. Should I change it's state to Not Applicable or
> something else?
>
> [2]:
> https://patchwork.dpdk.org/project/dpdk/patch/20230116130724.50277-
> 3-mb@smartsharesystems.com/
I think I might have forgotten it for some reason,
I can pick it still as I can see it's still applicable I will take it to next-net-mlx directly,
Kindest regards
Raslan Darawsheh
On Tue, Feb 27, 2024 at 11:06:04AM -0800, Stephen Hemminger wrote:
> On Tue, 27 Feb 2024 12:27:31 +0100
> Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > > > 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.
>
> The function rte_memcpy only exists because glibc and gcc version of memcpy
> is not optimized enough. Would love to see it go away in future.
Definite +1.
@@ -114,7 +114,7 @@ bnx2x_hw_stats_post(struct bnx2x_softc *sc)
/* Update MCP's statistics if possible */
if (sc->func_stx) {
- rte_memcpy(BNX2X_SP(sc, func_stats), &sc->func_stats,
+ memcpy(BNX2X_SP(sc, func_stats), &sc->func_stats,
sizeof(sc->func_stats));
}
@@ -817,10 +817,10 @@ bnx2x_hw_stats_update(struct bnx2x_softc *sc)
etherstatspktsover1522octets);
}
- rte_memcpy(old, new, sizeof(struct nig_stats));
+ memcpy(old, new, sizeof(struct nig_stats));
- rte_memcpy(&(estats->rx_stat_ifhcinbadoctets_hi), &(pstats->mac_stx[1]),
- sizeof(struct mac_stx));
+ memcpy(RTE_PTR_ADD(estats, offsetof(struct bnx2x_eth_stats, rx_stat_ifhcinbadoctets_hi)),
+ &pstats->mac_stx[1], sizeof(struct mac_stx));
estats->brb_drop_hi = pstats->brb_drop_hi;
estats->brb_drop_lo = pstats->brb_drop_lo;
@@ -1492,9 +1492,11 @@ bnx2x_stats_init(struct bnx2x_softc *sc)
REG_RD(sc, NIG_REG_STAT0_BRB_TRUNCATE + port*0x38);
if (!CHIP_IS_E3(sc)) {
REG_RD_DMAE(sc, NIG_REG_STAT0_EGRESS_MAC_PKT0 + port*0x50,
- &(sc->port.old_nig_stats.egress_mac_pkt0_lo), 2);
+ RTE_PTR_ADD(&sc->port.old_nig_stats,
+ offsetof(struct nig_stats, egress_mac_pkt0_lo)), 2);
REG_RD_DMAE(sc, NIG_REG_STAT0_EGRESS_MAC_PKT1 + port*0x50,
- &(sc->port.old_nig_stats.egress_mac_pkt1_lo), 2);
+ RTE_PTR_ADD(&sc->port.old_nig_stats,
+ offsetof(struct nig_stats, egress_mac_pkt1_lo)), 2);
}
/* function stats */
@@ -52,9 +52,9 @@ bnx2x_check_bull(struct bnx2x_softc *sc)
/* check the mac address and VLAN and allocate memory if valid */
if (valid_bitmap & (1 << MAC_ADDR_VALID) && memcmp(bull->mac, sc->old_bulletin.mac, ETH_ALEN))
- rte_memcpy(&sc->link_params.mac_addr, bull->mac, ETH_ALEN);
+ memcpy(&sc->link_params.mac_addr, bull->mac, ETH_ALEN);
if (valid_bitmap & (1 << VLAN_VALID))
- rte_memcpy(&bull->vlan, &sc->old_bulletin.vlan, RTE_VLAN_HLEN);
+ memcpy(&bull->vlan, &sc->old_bulletin.vlan, sizeof(bull->vlan));
sc->old_bulletin = *bull;
@@ -569,7 +569,7 @@ bnx2x_vf_set_mac(struct bnx2x_softc *sc, int set)
bnx2x_check_bull(sc);
- rte_memcpy(query->filters[0].mac, sc->link_params.mac_addr, ETH_ALEN);
+ memcpy(query->filters[0].mac, sc->link_params.mac_addr, ETH_ALEN);
bnx2x_add_tlv(sc, query, query->first_tlv.tl.length,
BNX2X_VF_TLV_LIST_END,
@@ -583,9 +583,9 @@ bnx2x_vf_set_mac(struct bnx2x_softc *sc, int set)
while (BNX2X_VF_STATUS_FAILURE == reply->status &&
bnx2x_check_bull(sc)) {
/* A new mac was configured by PF for us */
- rte_memcpy(sc->link_params.mac_addr, sc->pf2vf_bulletin->mac,
+ memcpy(sc->link_params.mac_addr, sc->pf2vf_bulletin->mac,
ETH_ALEN);
- rte_memcpy(query->filters[0].mac, sc->pf2vf_bulletin->mac,
+ memcpy(query->filters[0].mac, sc->pf2vf_bulletin->mac,
ETH_ALEN);
rc = bnx2x_do_req4pf(sc, sc->vf2pf_mbox_mapping.paddr);
@@ -622,10 +622,10 @@ bnx2x_vf_config_rss(struct bnx2x_softc *sc,
BNX2X_VF_TLV_LIST_END,
sizeof(struct channel_list_end_tlv));
- rte_memcpy(query->rss_key, params->rss_key, sizeof(params->rss_key));
+ memcpy(query->rss_key, params->rss_key, sizeof(params->rss_key));
query->rss_key_size = T_ETH_RSS_KEY;
- rte_memcpy(query->ind_table, params->ind_table, T_ETH_INDIRECTION_TABLE_SIZE);
+ memcpy(query->ind_table, params->ind_table, T_ETH_INDIRECTION_TABLE_SIZE);
query->ind_table_size = T_ETH_INDIRECTION_TABLE_SIZE;
query->rss_result_mask = params->rss_result_mask;