From: Simon Horman <horms@kernel.org>
To: Mengyuan Lou <mengyuanlou@net-swift.com>
Cc: netdev@vger.kernel.org, jiawenwu@trustnetic.com,
duanqiangwen@net-swift.com, kuba@kernel.org
Subject: Re: [PATCH net-next v4 3/3] net: libwx: support vf per-queue statistics via ethtool -S
Date: Thu, 11 Jun 2026 07:48:59 +0100 [thread overview]
Message-ID: <20260611064859.GP3920875@horms.kernel.org> (raw)
In-Reply-To: <20260608103946.25786-4-mengyuanlou@net-swift.com>
On Mon, Jun 08, 2026 at 06:39:46PM +0800, Mengyuan Lou wrote:
> Add per-queue TX/RX packet and byte counters to the VF ethtool stats
> table.
> The stats length is now dynamically determined based on whether the
> device is a VF or PF via wx_stats_len().
>
> Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com>
> ---
> .../net/ethernet/wangxun/libwx/wx_ethtool.c | 48 +++++++++++++++----
> drivers/net/ethernet/wangxun/libwx/wx_hw.c | 4 ++
> .../net/ethernet/wangxun/libwx/wx_vf_common.c | 2 +
> 3 files changed, 44 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/wangxun/libwx/wx_ethtool.c b/drivers/net/ethernet/wangxun/libwx/wx_ethtool.c
> index 30c6ef6103ac..86f6ac63acf7 100644
> --- a/drivers/net/ethernet/wangxun/libwx/wx_ethtool.c
> +++ b/drivers/net/ethernet/wangxun/libwx/wx_ethtool.c
> @@ -48,6 +48,10 @@ static const struct wx_stats wx_gstrings_stats[] = {
> WX_STAT("rx_hwtstamp_cleared", rx_hwtstamp_cleared),
> };
>
> +static const struct wx_stats wx_gstrings_stats_vf[] = {
> + WX_STAT("non_eop_descs", non_eop_descs),
> +};
> +
The AI-generated review available at https://netdev-ai.bots.linux.dev/sashiko/
flags that this is user-exposed and probably could benefit from a bit
more explanation in the patch description.
> static const struct wx_stats wx_gstrings_fdir_stats[] = {
> WX_STAT("fdir_match", stats.fdirmatch),
> WX_STAT("fdir_miss", stats.fdirmiss),
> @@ -69,15 +73,26 @@ static const struct wx_stats wx_gstrings_rsc_stats[] = {
> #define WX_QUEUE_STATS_LEN ( \
> (WX_NUM_TX_QUEUES + WX_NUM_RX_QUEUES) * \
> (sizeof(struct wx_queue_stats) / sizeof(u64)))
> -#define WX_GLOBAL_STATS_LEN ARRAY_SIZE(wx_gstrings_stats)
> #define WX_FDIR_STATS_LEN ARRAY_SIZE(wx_gstrings_fdir_stats)
> #define WX_RSC_STATS_LEN ARRAY_SIZE(wx_gstrings_rsc_stats)
> -#define WX_STATS_LEN (WX_GLOBAL_STATS_LEN + WX_QUEUE_STATS_LEN)
> +
> +static inline unsigned int wx_global_stats_len(const struct wx *wx)
> +{
> + return wx->pdev->is_virtfn ?
> + ARRAY_SIZE(wx_gstrings_stats_vf) : ARRAY_SIZE(wx_gstrings_stats);
> +}
Please don't use the inline keyword in .c files unless there is a
demonstrable - usually performance - reason to do so. Rather, please
let the compiler inline code (or not).
It is of course fine to use the inline keyword in .h files.
> +
> +static inline unsigned int wx_stats_len(const struct wx *wx)
> +{
> + struct net_device *netdev = wx->netdev;
netdev seems unused.
Flagged by AI-generated review on sashiko.dev
> +
> + return wx_global_stats_len(wx) + WX_QUEUE_STATS_LEN;
> +}
>
> int wx_get_sset_count(struct net_device *netdev, int sset)
> {
> struct wx *wx = netdev_priv(netdev);
> - int len = WX_STATS_LEN;
> + int len = wx_stats_len(wx);
>
> switch (sset) {
> case ETH_SS_STATS:
> @@ -100,8 +115,11 @@ void wx_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
>
> switch (stringset) {
> case ETH_SS_STATS:
> - for (i = 0; i < WX_GLOBAL_STATS_LEN; i++)
> - ethtool_puts(&p, wx_gstrings_stats[i].stat_string);
> + for (i = 0; i < wx_global_stats_len(wx); i++)
> + if (wx->pdev->is_virtfn)
> + ethtool_puts(&p, wx_gstrings_stats_vf[i].stat_string);
> + else
> + ethtool_puts(&p, wx_gstrings_stats[i].stat_string);
The AI-generated review at https://netdev-ai.bots.linux.dev/sashiko/ also
flags that these seem to cover statistics that can be exposed via
netdev_stat_ops, which is preferred.
If consistency with the PF stats is desired for VF stats, then perhaps
netdev_stat_ops can also be implemented for PF queues.
> if (test_bit(WX_FLAG_FDIR_CAPABLE, wx->flags)) {
> for (i = 0; i < WX_FDIR_STATS_LEN; i++)
> ethtool_puts(&p, wx_gstrings_fdir_stats[i].stat_string);
...
next prev parent reply other threads:[~2026-06-11 6:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 10:39 [PATCH net-next v4 0/3] net: libwx: improve VF ethtool support Mengyuan Lou
2026-06-08 10:39 ` [PATCH net-next v4 1/3] net: libwx: add support for set_ringparam in wx_ethtool_ops_vf Mengyuan Lou
2026-06-08 10:39 ` [PATCH net-next v4 2/3] net: libwx: add support for set_coalesce " Mengyuan Lou
2026-06-08 10:39 ` [PATCH net-next v4 3/3] net: libwx: support vf per-queue statistics via ethtool -S Mengyuan Lou
2026-06-11 6:48 ` Simon Horman [this message]
2026-06-11 8:46 ` mengyuanlou
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=20260611064859.GP3920875@horms.kernel.org \
--to=horms@kernel.org \
--cc=duanqiangwen@net-swift.com \
--cc=jiawenwu@trustnetic.com \
--cc=kuba@kernel.org \
--cc=mengyuanlou@net-swift.com \
--cc=netdev@vger.kernel.org \
/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