From: Simon Horman <horms@kernel.org>
To: gongfan1@huawei.com
Cc: Simon Horman <horms@kernel.org>,
edumazet@google.com, zhengjiezhen@h-partners.com,
guoxin09@huawei.com, netdev@vger.kernel.org,
andrew+netdev@lunn.ch, maxime.chevallier@bootlin.com,
zhoushuai28@huawei.com, mohsin.bashr@gmail.com,
ioana.ciornei@nxp.com, zhuyikai1@h-partners.com,
luosifu@huawei.com, linux-kernel@vger.kernel.org,
kuba@kernel.org, davem@davemloft.net, linux-doc@vger.kernel.org,
pabeni@redhat.com, shijing34@huawei.com, wulike1@huawei.com
Subject: Re: [PATCH net-next v04 3/6] hinic3: Add ethtool coalesce ops
Date: Fri, 10 Apr 2026 21:12:09 +0100 [thread overview]
Message-ID: <20260410201209.651627-1-horms@kernel.org> (raw)
In-Reply-To: <f9f5c1239d17675283a2da8b307f5aca8f46864c.1775618798.git.zhuyikai1@h-partners.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
hinic3: Add ethtool coalesce ops
This patch implements ethtool .get_coalesce and .set_coalesce callback
functions to allow users to configure and monitor RX coalesce settings.
> diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_ethtool.c b/drivers/net/ethernet/huawei/hinic3/hinic3_ethtool.c
> index be26698fc658..a4b2d5ba81f8 100644
> --- a/drivers/net/ethernet/huawei/hinic3/hinic3_ethtool.c
> +++ b/drivers/net/ethernet/huawei/hinic3/hinic3_ethtool.c
[ ... ]
> @@ -985,9 +990,230 @@ static void hinic3_get_pause_stats(struct net_device *netdev,
> kfree(ps);
> }
>
> +static int hinic3_set_queue_coalesce(struct net_device *netdev, u16 q_id,
> + struct hinic3_intr_coal_info *coal)
> +{
> + struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
> + struct hinic3_intr_coal_info *intr_coal;
> + struct hinic3_interrupt_info info = {};
> + int err;
> +
> + intr_coal = &nic_dev->intr_coalesce[q_id];
> +
> + intr_coal->coalesce_timer_cfg = coal->coalesce_timer_cfg;
> + intr_coal->pending_limit = coal->pending_limit;
> + intr_coal->rx_pending_limit_low = coal->rx_pending_limit_low;
> + intr_coal->rx_pending_limit_high = coal->rx_pending_limit_high;
> +
> + if (!test_bit(HINIC3_INTF_UP, &nic_dev->flags) ||
> + q_id >= nic_dev->q_params.num_qps || nic_dev->adaptive_rx_coal)
> + return 0;
> +
> + info.msix_index = nic_dev->q_params.irq_cfg[q_id].msix_entry_idx;
> + info.interrupt_coalesc_set = 1;
> + info.coalesc_timer_cfg = intr_coal->coalesce_timer_cfg;
> + info.pending_limit = intr_coal->pending_limit;
> + info.resend_timer_cfg = intr_coal->resend_timer_cfg;
> + err = hinic3_set_interrupt_cfg(nic_dev->hwdev, info);
> + if (err) {
> + netdev_warn(netdev, "Failed to set queue%u coalesce\n", q_id);
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +static int is_coalesce_exceed_limit(struct net_device *netdev,
> + const struct ethtool_coalesce *coal)
> +{
> + const struct {
> + const char *name;
> + u32 value;
> + u32 limit;
> + } coalesce_limits[] = {
> + {"rx_coalesce_usecs",
> + coal->rx_coalesce_usecs,
> + COALESCE_MAX_TIMER_CFG},
> + {"rx_max_coalesced_frames",
> + coal->rx_max_coalesced_frames,
> + COALESCE_MAX_PENDING_LIMIT},
> + {"rx_max_coalesced_frames_low",
> + coal->rx_max_coalesced_frames_low,
> + COALESCE_MAX_PENDING_LIMIT},
> + {"rx_max_coalesced_frames_high",
> + coal->rx_max_coalesced_frames_high,
> + COALESCE_MAX_PENDING_LIMIT},
> + };
> +
> + for (int i = 0; i < ARRAY_SIZE(coalesce_limits); i++) {
> + if (coalesce_limits[i].value > coalesce_limits[i].limit) {
> + netdev_err(netdev, "%s out of range %d-%d\n",
> + coalesce_limits[i].name, 0,
> + coalesce_limits[i].limit);
> + return -ERANGE;
> + }
> + }
> + return 0;
> +}
> +
> +static int is_coalesce_legal(struct net_device *netdev,
> + const struct ethtool_coalesce *coal)
> +{
> + int err;
> +
> + err = is_coalesce_exceed_limit(netdev, coal);
> + if (err)
> + return err;
> +
> + if (coal->rx_max_coalesced_frames_low >
> + coal->rx_max_coalesced_frames_high) {
> + netdev_err(netdev, "invalid coalesce frame high %u, low %u, unit %d\n",
> + coal->rx_max_coalesced_frames_high,
> + coal->rx_max_coalesced_frames_low,
> + COALESCE_PENDING_LIMIT_UNIT);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
Does this validation allow non-zero low with zero high? For example, if
rx_max_coalesced_frames_low=10 and rx_max_coalesced_frames_high=0, the
condition 'low > high' would be true and return -EINVAL, which is correct.
However, this validation still accepts the case where low equals high, including
when both are zero. In v03, a reviewer asked: "So this would allow non-zero low
and zero high. For example, low = 10, high = 0. Is this expected?" The original
v03 logic was 'low >= high && high > 0' which rejected the case where low
equals high. In v04, this was changed to 'low > high' only, but the reviewer's
concern about whether allowing low=high (including low=0, high=0) is expected
behavior was not directly addressed.
Reference: https://lore.kernel.org/netdev/18d5a9b7-9c8d-4fc4-9332-fab27449dc58@gmail.com/
> +
> +static void check_coalesce_align(struct net_device *netdev,
> + u32 item, u32 unit, const char *str)
> +{
> + if (item % unit)
> + netdev_warn(netdev, "%s in %d units, change to %u\n",
> + str, unit, item - item % unit);
> +}
[ ... ]
> @@ -1003,6 +1229,8 @@ static const struct ethtool_ops hinic3_ethtool_ops = {
> .get_eth_ctrl_stats = hinic3_get_eth_ctrl_stats,
> .get_rmon_stats = hinic3_get_rmon_stats,
> .get_pause_stats = hinic3_get_pause_stats,
> + .get_coalesce = hinic3_get_coalesce,
> + .set_coalesce = hinic3_set_coalesce,
> };
>
> void hinic3_set_ethtool_ops(struct net_device *netdev)
[ ... ]
> @@ -985,9 +990,230 @@ static void hinic3_get_pause_stats(struct net_device *netdev,
>
> static const struct ethtool_ops hinic3_ethtool_ops = {
> - .supported_coalesce_params = ETHTOOL_COALESCE_USECS |
> - ETHTOOL_COALESCE_PKT_RATE_RX_USECS,
> + .supported_coalesce_params = ETHTOOL_COALESCE_RX_USECS |
> + ETHTOOL_COALESCE_RX_MAX_FRAMES |
> + ETHTOOL_COALESCE_USE_ADAPTIVE_RX |
> + ETHTOOL_COALESCE_RX_MAX_FRAMES_LOW |
> + ETHTOOL_COALESCE_RX_MAX_FRAMES_HIGH,
Was the removal of ETHTOOL_COALESCE_TX_USECS intentional? In v02, the code
included 'ETHTOOL_COALESCE_USECS | ETHTOOL_COALESCE_PKT_RATE_RX_USECS', but
v03 and v04 changed this to only RX-specific parameters. A reviewer asked if
this was intentional, but there was no response from the author and the v04
changelog does not mention this concern.
Reference: https://lore.kernel.org/netdev/18d5a9b7-9c8d-4fc4-9332-fab27449dc58@gmail.com/
next prev parent reply other threads:[~2026-04-10 20:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 4:03 [PATCH net-next v04 0/6] net: hinic3: PF initialization Fan Gong
2026-04-08 4:03 ` [PATCH net-next v04 1/6] hinic3: Add ethtool queue ops Fan Gong
2026-04-10 20:10 ` Simon Horman
2026-04-08 4:03 ` [PATCH net-next v04 2/6] hinic3: Add ethtool statistic ops Fan Gong
2026-04-08 4:03 ` [PATCH net-next v04 3/6] hinic3: Add ethtool coalesce ops Fan Gong
2026-04-10 20:12 ` Simon Horman [this message]
2026-04-08 4:03 ` [PATCH net-next v04 4/6] hinic3: Add ethtool rss ops Fan Gong
2026-04-08 4:03 ` [PATCH net-next v04 5/6] hinic3: Configure netdev->watchdog_timeo to set nic tx timeout Fan Gong
2026-04-08 4:03 ` [PATCH net-next v04 6/6] hinic3: Remove unneeded coalesce parameters Fan Gong
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=20260410201209.651627-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gongfan1@huawei.com \
--cc=guoxin09@huawei.com \
--cc=ioana.ciornei@nxp.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luosifu@huawei.com \
--cc=maxime.chevallier@bootlin.com \
--cc=mohsin.bashr@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shijing34@huawei.com \
--cc=wulike1@huawei.com \
--cc=zhengjiezhen@h-partners.com \
--cc=zhoushuai28@huawei.com \
--cc=zhuyikai1@h-partners.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