From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
To: Rosen Penev <rosenp@gmail.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
<netdev@vger.kernel.org>, "Andrew Lunn" <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
"John Fastabend" <john.fastabend@gmail.com>,
"moderated list:INTEL ETHERNET DRIVERS"
<intel-wired-lan@lists.osuosl.org>,
open list <linux-kernel@vger.kernel.org>,
"open list:XDP (eXpress Data Path):Keyword:(?:b|_)xdp(?:b|_)"
<bpf@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCHv2 net-next iwl-next] net: intel: use ethtool string helpers
Date: Thu, 31 Oct 2024 08:45:49 +0100 [thread overview]
Message-ID: <59f4a6e6-23ad-4f99-b168-047f1d0d801a@intel.com> (raw)
In-Reply-To: <CAKxU2N9hhwfdZN28kTDf3qUT8GXuxLDPFsA04jBaJSWqPRaHqQ@mail.gmail.com>
On 10/30/24 23:52, Rosen Penev wrote:
> On Mon, Oct 28, 2024 at 3:13 AM Przemek Kitszel
> <przemyslaw.kitszel@intel.com> wrote:
>>
>> On 10/25/24 22:17, Rosen Penev wrote:
>>> The latter is the preferred way to copy ethtool strings.
>>>
>>> Avoids manually incrementing the pointer. Cleans up the code quite well.
>>>
>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>>> ---
>>> v2: add iwl-next tag. use inline int in for loops.
>>> .../net/ethernet/intel/e1000/e1000_ethtool.c | 10 ++---
>>> drivers/net/ethernet/intel/e1000e/ethtool.c | 14 +++----
>>> .../net/ethernet/intel/fm10k/fm10k_ethtool.c | 10 ++---
>>> .../net/ethernet/intel/i40e/i40e_ethtool.c | 6 +--
>>> drivers/net/ethernet/intel/ice/ice_ethtool.c | 37 +++++++++++--------
>>> drivers/net/ethernet/intel/igb/igb_ethtool.c | 35 ++++++++++--------
>>> drivers/net/ethernet/intel/igbvf/ethtool.c | 10 ++---
>>> drivers/net/ethernet/intel/igc/igc_ethtool.c | 36 +++++++++---------
>>> .../net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 32 ++++++++--------
>>
>> for ice, igb, igc, and ixgbe the current code already uses ethtool
>> string helpers, and in many places you are just changing variable name,
>> "p" to "data", I would rather avoid that.
> well, since I'm cleaning some of this code up, might as well get rid
> of variables. That was suggested to me with other similar patches.
>>
>> sorry for not spotting that earlier, and apologies that we have so many
>> drivers to fix up in the first place
>>
>>> diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
>>> index 2924ac61300d..62a152be8180 100644
>>> --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
>>> +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
>>> @@ -83,7 +83,7 @@ static const char ice_gstrings_test[][ETH_GSTRING_LEN] = {
>>> "Link test (on/offline)",
>>> };
>>>
>>> -#define ICE_TEST_LEN (sizeof(ice_gstrings_test) / ETH_GSTRING_LEN)
>>> +#define ICE_TEST_LEN ARRAY_SIZE(ice_gstrings_test)
>>>
>>> /* These PF_STATs might look like duplicates of some NETDEV_STATs,
>>> * but they aren't. This device is capable of supporting multiple
>>> @@ -1481,48 +1481,53 @@ static void
>>> __ice_get_strings(struct net_device *netdev, u32 stringset, u8 *data,
>>> struct ice_vsi *vsi)
>>> {
>>> + const char *str;
>>> unsigned int i;
>>> - u8 *p = data;
>>>
>>> switch (stringset) {
>>> case ETH_SS_STATS:
>>> - for (i = 0; i < ICE_VSI_STATS_LEN; i++)
>>> - ethtool_puts(&p, ice_gstrings_vsi_stats[i].stat_string);
>>> + for (i = 0; i < ICE_VSI_STATS_LEN; i++) {
>>> + str = ice_gstrings_vsi_stats[i].stat_string;
>>> + ethtool_puts(&data, str);
>>> + }
>>>
>>> if (ice_is_port_repr_netdev(netdev))
>>> return;
>>>
>>> ice_for_each_alloc_txq(vsi, i) {
>>> - ethtool_sprintf(&p, "tx_queue_%u_packets", i);
>>> - ethtool_sprintf(&p, "tx_queue_%u_bytes", i);
>>> + ethtool_sprintf(&data, "tx_queue_%u_packets", i);
>>> + ethtool_sprintf(&data, "tx_queue_%u_bytes", i);
>>> }
>>>
>>> ice_for_each_alloc_rxq(vsi, i) {
>>> - ethtool_sprintf(&p, "rx_queue_%u_packets", i);
>>> - ethtool_sprintf(&p, "rx_queue_%u_bytes", i);
>>> + ethtool_sprintf(&data, "rx_queue_%u_packets", i);
>>> + ethtool_sprintf(&data, "rx_queue_%u_bytes", i);
>>> }
>>>
>>> if (vsi->type != ICE_VSI_PF)
>>> return;
>>>
>>> - for (i = 0; i < ICE_PF_STATS_LEN; i++)
>>> - ethtool_puts(&p, ice_gstrings_pf_stats[i].stat_string);
>>> + for (i = 0; i < ICE_PF_STATS_LEN; i++) {
>>> + str = ice_gstrings_pf_stats[i].stat_string;
>>> + ethtool_puts(&data, str);
>>> + }
>>>
>>> for (i = 0; i < ICE_MAX_USER_PRIORITY; i++) {
>>> - ethtool_sprintf(&p, "tx_priority_%u_xon.nic", i);
>>> - ethtool_sprintf(&p, "tx_priority_%u_xoff.nic", i);
>>> + ethtool_sprintf(&data, "tx_priority_%u_xon.nic", i);
>>> + ethtool_sprintf(&data, "tx_priority_%u_xoff.nic", i);
>>> }
>>> for (i = 0; i < ICE_MAX_USER_PRIORITY; i++) {
>>> - ethtool_sprintf(&p, "rx_priority_%u_xon.nic", i);
>>> - ethtool_sprintf(&p, "rx_priority_%u_xoff.nic", i);
>>> + ethtool_sprintf(&data, "rx_priority_%u_xon.nic", i);
>>> + ethtool_sprintf(&data, "rx_priority_%u_xoff.nic", i);
>>> }
>>> break;
>>> case ETH_SS_TEST:
>>> - memcpy(data, ice_gstrings_test, ICE_TEST_LEN * ETH_GSTRING_LEN);
>>> + for (i = 0; i < ICE_TEST_LEN; i++)
>>> + ethtool_puts(&data, ice_gstrings_test[i]);
>>> break;
>>> case ETH_SS_PRIV_FLAGS:
>>> for (i = 0; i < ICE_PRIV_FLAG_ARRAY_SIZE; i++)
>>> - ethtool_puts(&p, ice_gstrings_priv_flags[i].name);
>>> + ethtool_puts(&data, ice_gstrings_priv_flags[i].name);
>>> break;
>>> default:
>>> break;
>>
>> really no need to git-blame touch most of the code here>
>
> Actually the function should be taking a double pointer here I think
> in case something gets called after it in the main function.
I mean that both @p and @data are (u8 *).
I'm fine getting rid of tmp var, and updating the originally passed
argument is fine. But you could achieve it by just changing param name.
BTW I guess it was @p to fit into 80 chars more easily ;)
next prev parent reply other threads:[~2024-10-31 7:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 20:17 [Intel-wired-lan] [PATCHv2 net-next iwl-next] net: intel: use ethtool string helpers Rosen Penev
2024-10-28 10:12 ` Przemek Kitszel
2024-10-30 22:52 ` Rosen Penev
2024-10-31 7:45 ` Przemek Kitszel [this message]
2024-10-31 21:03 ` Rosen Penev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59f4a6e6-23ad-4f99-b168-047f1d0d801a@intel.com \
--to=przemyslaw.kitszel@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rosenp@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox