[PATCH net-next 00/10][pull request] Intel Wired LAN Driver Updates 2026-09-29 (ice)

[PATCH net-next 00/10][pull request] Intel Wired LAN Driver Updates 2026-09-29 (ice)

[Tony Nguyen]

Grzegorz reduces DSCP message from error to debug when FW DCB
management is active since it's an expected condition.

Marcin utilizes, existing, ice_fill_eth_hdr() call to set ethernet
header value.

Jake reduces padding in ice_flash_info struct by moving sr_words
location.

Aleksandr adjusts OICR interrupt moderation rate to reduce latency for
Tx timestamps and VF mailbox messages. He also simplifies IPv6 mask
checks; replacing memcmp() and mask structs to helper functions.

Przemek Korba adds an Rx timestamp tracepoint to help debug PTP issues.

Weimin Xiong converts parser-table allocation to kcalloc().

Yury Norov simplifies PF nominal-state check by reducing the number of
calls and removes a redundant NULL check as most are already non-NULL.

Przemek Kitszel simplifies VF queue disabling by removing ineffective
batching for queues.

The following are changes since commit 6e23f90f2b8c3ea3bf904f86f3ed06bf2844b4bc:
  Merge branch 'net-consolidate-devmem-net_iov-freelist-and-dma-handling'
and are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue 100GbE

Aleksandr Loktionov (2):
  ice: increase OICR interrupt moderation rate to 20K interrupts/sec
  ice: use inline helpers instead of memcmp() for IPv6 mask checks in
    ice_ethtool_fdir

Grzegorz Nitka (1):
  ice: reduce loglevel to debug for 'Can't delete DSCP' message

Jacob Keller (1):
  ice: reorder ice_flash_info fields to eliminate padding

Marcin Szycik (1):
  ice: use ice_fill_eth_hdr() in ice_fill_sw_rule()

Przemek Kitszel (1):
  ice: simplify ice_vc_dis_qs_msg() a little

Przemyslaw Korba (1):
  ice: add rx timestamp tracepoint for debugging

Weimin Xiong (1):
  ice: parser: use kcalloc for table allocation

Yury Norov (2):
  ice: simplify ice_pf_state_is_nominal()
  ice: drop pf == NULL check in ice_pf_state_is_nominal()

 drivers/net/ethernet/intel/ice/ice_dcb_nl.c   |  2 +-
 .../ethernet/intel/ice/ice_ethtool_ntuple.c   | 57 ++++++-------------
 drivers/net/ethernet/intel/ice/ice_lib.c      | 11 +---
 drivers/net/ethernet/intel/ice/ice_main.c     |  4 +-
 drivers/net/ethernet/intel/ice/ice_parser.c   |  2 +-
 drivers/net/ethernet/intel/ice/ice_ptp.c      |  2 +
 drivers/net/ethernet/intel/ice/ice_switch.c   |  6 +-
 drivers/net/ethernet/intel/ice/ice_trace.h    | 18 ++++++
 drivers/net/ethernet/intel/ice/ice_type.h     |  2 +-
 drivers/net/ethernet/intel/ice/virt/queues.c  | 17 +-----
 10 files changed, 47 insertions(+), 74 deletions(-)

-- 
2.47.1

[PATCH net-next 01/10] ice: reduce loglevel to debug for 'Can't delete DSCP' message

[Tony Nguyen]

From: Grzegorz Nitka <grzegorz.nitka@intel.com>

Reduce netdev message "Can't delete DSCP netlink app ..." from error
to debug level when in FW (firmware) DCB mode.
This is not a real error and a kind of expected behavior. The device
is fully operational and error message might be wrongly interpreted by
the user.

Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_dcb_nl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_dcb_nl.c b/drivers/net/ethernet/intel/ice/ice_dcb_nl.c
index a10c1c8d8697..bb5cc0a2ba69 100644
--- a/drivers/net/ethernet/intel/ice/ice_dcb_nl.c
+++ b/drivers/net/ethernet/intel/ice/ice_dcb_nl.c
@@ -872,7 +872,7 @@ static int ice_dcbnl_delapp(struct net_device *netdev, struct dcb_app *app)
 	int ret = 0;
 
 	if (pf->dcbx_cap & DCB_CAP_DCBX_LLD_MANAGED) {
-		netdev_err(netdev, "can't delete DSCP netlink app when FW DCB agent is active\n");
+		netdev_dbg(netdev, "can't delete DSCP netlink app when FW DCB agent is active\n");
 		return -EINVAL;
 	}
 
-- 
2.47.1

Re: [PATCH net-next 01/10] ice: reduce loglevel to debug for 'Can't delete DSCP' message

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 1 · Medium: 0 (1) · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [High] In FW DCB mode, the driver's own flush of removed APPs always
  fails, and this patch hides that failure.

Pre-existing issues:
- [Medium] This problem wasn't introduced by this patch, but
  ice_dcbnl_delapp() compacts the desired APP table using the local…

--

ice: reduce loglevel to debug for 'Can't delete DSCP' message

This commit lowers the "can't delete DSCP netlink app when FW DCB agent
is active" message in ice_dcbnl_delapp() from netdev_err() to
netdev_dbg(). The commit message says this is expected behavior in FW
DCB mode and that the device is fully operational.

> diff --git a/drivers/net/ethernet/intel/ice/ice_dcb_nl.c b/drivers/net/ethernet/intel/ice/ice_dcb_nl.c
> index a10c1c8d86977..bb5cc0a2ba69b 100644
> --- a/drivers/net/ethernet/intel/ice/ice_dcb_nl.c
> +++ b/drivers/net/ethernet/intel/ice/ice_dcb_nl.c
> @@ -872,7 +872,7 @@ static int ice_dcbnl_delapp(struct net_device *netdev, struct dcb_app *app)
>  	int ret = 0;
>  
>  	if (pf->dcbx_cap & DCB_CAP_DCBX_LLD_MANAGED) {
> -		netdev_err(netdev, "can't delete DSCP netlink app when FW DCB agent is active\n");
> +		netdev_dbg(netdev, "can't delete DSCP netlink app when FW DCB agent is active\n");
>  		return -EINVAL;
>  	}

[Severity: High]
Is this message really expected behavior? It looks like it may be the only
visible sign that the driver's own APP flush always fails in FW DCB mode.

In FW mode, ice_dcb_process_lldp_set_mib_change() takes pf->tc_mutex,
refreshes dcbx_cap and then flushes the removed APPs:

drivers/net/ethernet/intel/ice/ice_dcb_lib.c:ice_dcb_process_lldp_set_mib_change() {
    ...
	pf->dcbx_cap = ice_dcb_get_mode(pi, false);

	need_reconfig = ice_dcb_need_recfg(pf, &tmp_dcbx_cfg,
					   &pi->qos_cfg.local_dcbx_cfg);
	ice_dcbnl_flush_apps(pf, &tmp_dcbx_cfg, &pi->qos_cfg.local_dcbx_cfg);
    ...
}

ice_dcb_get_mode(pi, false) always sets DCB_CAP_DCBX_LLD_MANAGED. The flush
then goes through the user-facing .ieee_delapp op:

ice_dcbnl_flush_apps()
  ice_dcbnl_vsi_del_app()
    ice_dcbnl_delapp()
      if (pf->dcbx_cap & DCB_CAP_DCBX_LLD_MANAGED)
          return -EINVAL;

So dcb_ieee_delapp() is never reached, and the entry stays in the netdev's
dcbnl APP table.

The add side, ice_dcbnl_set_all(), calls dcb_ieee_setapp() directly, with
no FW-mode check. In FW mode, APPs get added but are never removed when
firmware drops or re-prioritises them. For example, an LLDP peer can
trigger this by changing the TLVs it advertises. The stale entries stay
visible through DCB_CMD_IEEE_GET and through dcb_ieee_getapp_mask() and
dcb_getapp().

This also doesn't match the ice_dcbnl_flush_apps() kernel-doc, which says:

 * Find and delete all APPS that are not present in the passed
 * DCB configuration

Even without the guard, ice_dcbnl_delapp() would not work as the callee
here. The caller already holds pf->tc_mutex, and ice_dcbnl_delapp() calls
mutex_lock(&pf->tc_mutex) again.

Could ice_dcbnl_vsi_del_app() call dcb_ieee_delapp() directly instead,
the same way ice_dcbnl_set_all() calls dcb_ieee_setapp()? That would
remove the stale entries and drop the spurious message on the internal
path. User-initiated deletes rejected in FW mode would keep their error
message. With that fix, this log level change would no longer be needed.

[Severity: Medium]
This is a pre-existing issue and was not introduced by this patch.
Further down in ice_dcbnl_delapp(), the desired table is compacted using
the local table as the source:

	old_cfg = &pf->hw.port_info->qos_cfg.local_dcbx_cfg;
	...
	new_cfg = &pf->hw.port_info->qos_cfg.desired_dcbx_cfg;
	...
	for (j = i; j < new_cfg->numapps; j++) {
		new_cfg->app[j].selector = old_cfg->app[j + 1].selector;
		new_cfg->app[j].prot_id = old_cfg->app[j + 1].prot_id;
		new_cfg->app[j].priority = old_cfg->app[j + 1].priority;
	}

Index i was found in desired_dcbx_cfg, but the shifted entries come from
local_dcbx_cfg. Can the two tables be out of sync at this point?

The early exit for non-DSCP selectors returns before ice_pf_dcb_cfg() runs,
so the local table is never synced:

	if (app->selector != IEEE_8021QAZ_APP_SEL_DSCP ||
	    !ice_is_feature_supported(pf, ICE_F_DSCP)) {
		ret = ICE_DCB_HW_CHG;
		goto delapp_out;
	}

ice_pf_dcb_cfg() can also fail after desired has been edited: -EBUSY with
custom Tx enabled, or -EINVAL from ice_dcb_bwchk(). When ice_set_dcb_cfg()
fails, it restores local_dcbx_cfg from old_cfg, but desired keeps the edit.

For example, start with local = desired = [A,B,C,D]:

1. Deleting B leaves desired as [A,C,D].
2. A HW failure restores local to [A,B,C,D].
3. Deleting C finds i = 1 in desired and copies local[2] = C into
   desired[1], leaving desired as [A,C].

C comes back and D is lost. ice_pf_dcb_cfg() can then commit that table to
hardware.

Should the shift copy from new_cfg->app[j + 1] instead? The compaction
logic appears to date back to commits b94b013eb626 ("ice: Implement DCBNL
support") and fc2d1165d4a4 ("ice: Refactor DCB related variables out of
the ice_port_info struct").

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260929224153.1455466-1-anthony.l.nguyen%40intel.com

[PATCH net-next 02/10] ice: use ice_fill_eth_hdr() in ice_fill_sw_rule()

[Tony Nguyen]

From: Marcin Szycik <marcin.szycik@intel.com>

Use the already existing helper function to fill Ethernet header. Also
replace sizeof with a (also existing) macro to reduce the number of
variables.

Suggested-by: Martyna Szapar-Mudlaw <martyna.szapar-mudlaw@intel.com>
Signed-off-by: Marcin Szycik <marcin.szycik@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_switch.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c
index 6a5875bd9c6b..4daee252e2a6 100644
--- a/drivers/net/ethernet/intel/ice/ice_switch.c
+++ b/drivers/net/ethernet/intel/ice/ice_switch.c
@@ -2612,7 +2612,6 @@ ice_fill_sw_rule(struct ice_hw *hw, struct ice_fltr_info *f_info,
 	u16 vlan_id = ICE_MAX_VLAN_ID + 1;
 	u16 vlan_tpid = ETH_P_8021Q;
 	void *daddr = NULL;
-	u16 eth_hdr_sz;
 	u8 *eth_hdr;
 	u32 act = 0;
 	__be16 *off;
@@ -2625,11 +2624,10 @@ ice_fill_sw_rule(struct ice_hw *hw, struct ice_fltr_info *f_info,
 		return;
 	}
 
-	eth_hdr_sz = sizeof(dummy_eth_header);
 	eth_hdr = s_rule->hdr_data;
 
 	/* initialize the ether header with a dummy header */
-	memcpy(eth_hdr, dummy_eth_header, eth_hdr_sz);
+	ice_fill_eth_hdr(eth_hdr);
 	ice_fill_sw_info(hw, f_info);
 
 	switch (f_info->fltr_act) {
@@ -2730,7 +2728,7 @@ ice_fill_sw_rule(struct ice_hw *hw, struct ice_fltr_info *f_info,
 
 	/* Create the switch rule with the final dummy Ethernet header */
 	if (opc != ice_aqc_opc_update_sw_rules)
-		s_rule->hdr_len = cpu_to_le16(eth_hdr_sz);
+		s_rule->hdr_len = cpu_to_le16(DUMMY_ETH_HDR_LEN);
 }
 
 /**
-- 
2.47.1

[PATCH net-next 03/10] ice: reorder ice_flash_info fields to eliminate padding

[Tony Nguyen]

From: Jacob Keller <jacob.e.keller@intel.com>

The ice_flash_info structure has a u16 sr_words field before a u32
flash_size value. This creates a 2-byte hole as well as 3 bytes of
padding at the end of the structure due to the blank_nvm_mode bitfield.

Re-order the structure to place flash_size first, which gives a better
layout and reduces padding.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_type.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_type.h b/drivers/net/ethernet/intel/ice/ice_type.h
index f1a80da6239e..b8bdd7e8c768 100644
--- a/drivers/net/ethernet/intel/ice/ice_type.h
+++ b/drivers/net/ethernet/intel/ice/ice_type.h
@@ -529,8 +529,8 @@ struct ice_flash_info {
 	struct ice_nvm_info nvm;	/* NVM version information */
 	struct ice_netlist_info netlist;/* Netlist version info */
 	struct ice_bank_info banks;	/* Flash Bank information */
-	u16 sr_words;			/* Shadow RAM size in words */
 	u32 flash_size;			/* Size of available flash in bytes */
+	u16 sr_words;			/* Shadow RAM size in words */
 	u8 blank_nvm_mode;		/* is NVM empty (no FW present) */
 };
 
-- 
2.47.1

[PATCH net-next 04/10] ice: increase OICR interrupt moderation rate to 20K interrupts/sec

[Tony Nguyen]

From: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

The miscellaneous interrupt cause (OICR) is throttled to 8K
interrupts per second (124 us minimum spacing). This interrupt
handles VF mailbox messages and Tx timestamps, so the low rate
imposes a minimum latency floor on both use-cases.

Raise the rate to 20K interrupts per second (50 us minimum
spacing) to allow lower latency handling for Tx timestamp
bursts and high VF message rates.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 707c7431b91a..73f69d453542 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3428,7 +3428,7 @@ static int ice_req_irq_msix_misc(struct ice_pf *pf)
 		     ((pf->ll_ts_irq.index + pf_intr_start_offset) &
 		      PFINT_SB_CTL_MSIX_INDX_M) | PFINT_SB_CTL_CAUSE_ENA_M);
 	wr32(hw, GLINT_ITR(ICE_RX_ITR, pf->oicr_irq.index),
-	     ITR_REG_ALIGN(ICE_ITR_8K) >> ICE_ITR_GRAN_S);
+	     ITR_REG_ALIGN(ICE_ITR_20K) >> ICE_ITR_GRAN_S);
 
 	ice_flush(hw);
 	ice_irq_dynamic_ena(hw, NULL, NULL);
-- 
2.47.1

Re: [PATCH net-next 04/10] ice: increase OICR interrupt moderation rate to 20K interrupts/sec

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] This patch removes the only user of ICE_ITR_8K (the OICR ITR
  write in ice_req_irq_msix_misc(),…

--

ice: increase OICR interrupt moderation rate to 20K interrupts/sec

This commit raises the OICR interrupt throttle rate in
ice_req_irq_msix_misc() from 8K interrupts per second to 20K.
The goal is lower latency for VF mailbox messages and Tx timestamp
handling.

> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index 707c7431b91a6..73f69d453542b 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -3428,7 +3428,7 @@ static int ice_req_irq_msix_misc(struct ice_pf *pf)
>  		     ((pf->ll_ts_irq.index + pf_intr_start_offset) &
>  		      PFINT_SB_CTL_MSIX_INDX_M) | PFINT_SB_CTL_CAUSE_ENA_M);
>  	wr32(hw, GLINT_ITR(ICE_RX_ITR, pf->oicr_irq.index),
> -	     ITR_REG_ALIGN(ICE_ITR_8K) >> ICE_ITR_GRAN_S);
> +	     ITR_REG_ALIGN(ICE_ITR_20K) >> ICE_ITR_GRAN_S);

[Severity: Low]
This isn't a bug, but this change removes the last user of ICE_ITR_8K.
After this patch the only remaining match for it under
drivers/net/ethernet/intel/ is the definition in
drivers/net/ethernet/intel/ice/ice_txrx.h:

#define ICE_ITR_8K	124
#define ICE_ITR_20K	50

Should the now unused ICE_ITR_8K define be removed, either in this patch
or in a follow-up?

>  
>  	ice_flush(hw);
>  	ice_irq_dynamic_ena(hw, NULL, NULL);

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260929224153.1455466-1-anthony.l.nguyen%40intel.com

[PATCH net-next 05/10] ice: use inline helpers instead of memcmp() for IPv6 mask checks in ice_ethtool_fdir

[Tony Nguyen]

From: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Replace static full_ipv6_addr_mask / zero_ipv6_addr_mask structs
and the associated memcmp() calls in ice_ethtool_fdir.c with the
kernel-provided ipv6_addr_any() helper and a new ice_ipv6_mask_full()
inline, reducing boilerplate and making intent clearer.

Suggested-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 .../ethernet/intel/ice/ice_ethtool_ntuple.c   | 57 ++++++-------------
 1 file changed, 16 insertions(+), 41 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool_ntuple.c b/drivers/net/ethernet/intel/ice/ice_ethtool_ntuple.c
index 516b57ff3b1c..ad519a8513db 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool_ntuple.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool_ntuple.c
@@ -8,23 +8,10 @@
 #include "ice_fdir.h"
 #include "ice_flow.h"
 
-static struct in6_addr full_ipv6_addr_mask = {
-	.in6_u = {
-		.u6_addr8 = {
-			0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
-			0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
-		}
-	}
-};
-
-static struct in6_addr zero_ipv6_addr_mask = {
-	.in6_u = {
-		.u6_addr8 = {
-			0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-			0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-		}
-	}
-};
+static bool ice_ipv6_mask_full(const __be32 *a)
+{
+	return (a[0] & a[1] & a[2] & a[3]) == cpu_to_be32(0xffffffff);
+}
 
 /* calls to ice_flow_add_prof require the number of segments in the array
  * for segs_cnt. In this code that is one more than the index.
@@ -1070,10 +1057,8 @@ ice_set_fdir_ip6_seg(struct ice_flow_seg_info *seg,
 	enum ice_flow_field src_port, dst_port;
 
 	/* make sure we don't have any empty rule */
-	if (!memcmp(tcp_ip6_spec->ip6src, &zero_ipv6_addr_mask,
-		    sizeof(struct in6_addr)) &&
-	    !memcmp(tcp_ip6_spec->ip6dst, &zero_ipv6_addr_mask,
-		    sizeof(struct in6_addr)) &&
+	if (ipv6_addr_any((struct in6_addr *)tcp_ip6_spec->ip6src) &&
+	    ipv6_addr_any((struct in6_addr *)tcp_ip6_spec->ip6dst) &&
 	    !tcp_ip6_spec->psrc && !tcp_ip6_spec->pdst)
 		return -EINVAL;
 
@@ -1097,24 +1082,20 @@ ice_set_fdir_ip6_seg(struct ice_flow_seg_info *seg,
 	*perfect_fltr = true;
 	ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV6 | l4_proto);
 
-	if (!memcmp(tcp_ip6_spec->ip6src, &full_ipv6_addr_mask,
-		    sizeof(struct in6_addr)))
+	if (ice_ipv6_mask_full(tcp_ip6_spec->ip6src))
 		ice_flow_set_fld(seg, ICE_FLOW_FIELD_IDX_IPV6_SA,
 				 ICE_FLOW_FLD_OFF_INVAL, ICE_FLOW_FLD_OFF_INVAL,
 				 ICE_FLOW_FLD_OFF_INVAL, false);
-	else if (!memcmp(tcp_ip6_spec->ip6src, &zero_ipv6_addr_mask,
-			 sizeof(struct in6_addr)))
+	else if (ipv6_addr_any((struct in6_addr *)tcp_ip6_spec->ip6src))
 		*perfect_fltr = false;
 	else
 		return -EOPNOTSUPP;
 
-	if (!memcmp(tcp_ip6_spec->ip6dst, &full_ipv6_addr_mask,
-		    sizeof(struct in6_addr)))
+	if (ice_ipv6_mask_full(tcp_ip6_spec->ip6dst))
 		ice_flow_set_fld(seg, ICE_FLOW_FIELD_IDX_IPV6_DA,
 				 ICE_FLOW_FLD_OFF_INVAL, ICE_FLOW_FLD_OFF_INVAL,
 				 ICE_FLOW_FLD_OFF_INVAL, false);
-	else if (!memcmp(tcp_ip6_spec->ip6dst, &zero_ipv6_addr_mask,
-			 sizeof(struct in6_addr)))
+	else if (ipv6_addr_any((struct in6_addr *)tcp_ip6_spec->ip6dst))
 		*perfect_fltr = false;
 	else
 		return -EOPNOTSUPP;
@@ -1167,33 +1148,27 @@ ice_set_fdir_ip6_usr_seg(struct ice_flow_seg_info *seg,
 	if (usr_ip6_spec->l4_proto)
 		return -EOPNOTSUPP;
 	/* empty rules are not valid */
-	if (!memcmp(usr_ip6_spec->ip6src, &zero_ipv6_addr_mask,
-		    sizeof(struct in6_addr)) &&
-	    !memcmp(usr_ip6_spec->ip6dst, &zero_ipv6_addr_mask,
-		    sizeof(struct in6_addr)))
+	if (ipv6_addr_any((struct in6_addr *)usr_ip6_spec->ip6src) &&
+	    ipv6_addr_any((struct in6_addr *)usr_ip6_spec->ip6dst))
 		return -EINVAL;
 
 	*perfect_fltr = true;
 	ICE_FLOW_SET_HDRS(seg, ICE_FLOW_SEG_HDR_IPV6);
 
-	if (!memcmp(usr_ip6_spec->ip6src, &full_ipv6_addr_mask,
-		    sizeof(struct in6_addr)))
+	if (ice_ipv6_mask_full(usr_ip6_spec->ip6src))
 		ice_flow_set_fld(seg, ICE_FLOW_FIELD_IDX_IPV6_SA,
 				 ICE_FLOW_FLD_OFF_INVAL, ICE_FLOW_FLD_OFF_INVAL,
 				 ICE_FLOW_FLD_OFF_INVAL, false);
-	else if (!memcmp(usr_ip6_spec->ip6src, &zero_ipv6_addr_mask,
-			 sizeof(struct in6_addr)))
+	else if (ipv6_addr_any((struct in6_addr *)usr_ip6_spec->ip6src))
 		*perfect_fltr = false;
 	else
 		return -EOPNOTSUPP;
 
-	if (!memcmp(usr_ip6_spec->ip6dst, &full_ipv6_addr_mask,
-		    sizeof(struct in6_addr)))
+	if (ice_ipv6_mask_full(usr_ip6_spec->ip6dst))
 		ice_flow_set_fld(seg, ICE_FLOW_FIELD_IDX_IPV6_DA,
 				 ICE_FLOW_FLD_OFF_INVAL, ICE_FLOW_FLD_OFF_INVAL,
 				 ICE_FLOW_FLD_OFF_INVAL, false);
-	else if (!memcmp(usr_ip6_spec->ip6dst, &zero_ipv6_addr_mask,
-			 sizeof(struct in6_addr)))
+	else if (ipv6_addr_any((struct in6_addr *)usr_ip6_spec->ip6dst))
 		*perfect_fltr = false;
 	else
 		return -EOPNOTSUPP;
-- 
2.47.1

Re: [PATCH net-next 05/10] ice: use inline helpers instead of memcmp() for IPv6 mask checks in ice_ethtool_fdir

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The commit message does not match the code.

--

ice: use inline helpers instead of memcmp() for IPv6 mask checks in ice_ethtool_fdir

This commit removes the static full_ipv6_addr_mask and zero_ipv6_addr_mask
structs and the memcmp() calls that used them. They are replaced by
ipv6_addr_any() and a new ice_ipv6_mask_full() helper. The mask checks in
ice_set_fdir_ip6_seg() and ice_set_fdir_ip6_usr_seg() are converted.

> ice: use inline helpers instead of memcmp() for IPv6 mask checks in ice_ethtool_fdir

[ ... ]

> Replace static full_ipv6_addr_mask / zero_ipv6_addr_mask structs
> and the associated memcmp() calls in ice_ethtool_fdir.c with the
> kernel-provided ipv6_addr_any() helper and a new ice_ipv6_mask_full()
> inline, reducing boilerplate and making intent clearer.

[Severity: Low]
Should the subject and body say ice_ethtool_ntuple instead of
ice_ethtool_fdir? There is no ice_ethtool_fdir.c in
drivers/net/ethernet/intel/ice/, either before or after this patch. The file
this patch changes is ice_ethtool_ntuple.c.

The body also calls ice_ipv6_mask_full() an inline, but the patch declares
it without the inline keyword:

    +static bool ice_ipv6_mask_full(const __be32 *a)

Could the description drop the word "inline", or could the helper be marked
static inline?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260929224153.1455466-1-anthony.l.nguyen%40intel.com

[PATCH net-next 06/10] ice: add rx timestamp tracepoint for debugging

[Tony Nguyen]

From: Przemyslaw Korba <przemyslaw.korba@intel.com>

Add ice_rx_hwtstamp trace event to help debug PTP rx timestamp issues.
The trace captures cached_time, ts_high, and the extended ts_ns value in
ice_ptp_get_rx_hwts().

Enable with:
echo 1 > /sys/kernel/debug/tracing/events/ice/ice_rx_hwtstamp/enable
cat /sys/kernel/debug/tracing/trace_pipe

Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_ptp.c   |  2 ++
 drivers/net/ethernet/intel/ice/ice_trace.h | 18 ++++++++++++++++++
 2 files changed, 20 insertions(+)

diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
index e54a98a0bdd0..b781004f856d 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
@@ -2330,6 +2330,8 @@ u64 ice_ptp_get_rx_hwts(const union ice_32b_rx_flex_desc *rx_desc,
 	ts_high = le32_to_cpu(rx_desc->wb.flex_ts.ts_high);
 	ts_ns = ice_ptp_extend_32b_ts(cached_time, ts_high);
 
+	ice_trace(rx_hwtstamp, cached_time, ts_high, ts_ns);
+
 	return ts_ns;
 }
 
diff --git a/drivers/net/ethernet/intel/ice/ice_trace.h b/drivers/net/ethernet/intel/ice/ice_trace.h
index 7568c917cdbe..7c43683a77d4 100644
--- a/drivers/net/ethernet/intel/ice/ice_trace.h
+++ b/drivers/net/ethernet/intel/ice/ice_trace.h
@@ -261,6 +261,24 @@ DEFINE_TX_TSTAMP_OP_EVENT(ice_tx_tstamp_fw_req);
 DEFINE_TX_TSTAMP_OP_EVENT(ice_tx_tstamp_fw_done);
 DEFINE_TX_TSTAMP_OP_EVENT(ice_tx_tstamp_complete);
 
+/* Trace event for Rx timestamp */
+TRACE_EVENT(ice_rx_hwtstamp,
+	    TP_PROTO(u64 cached_time, u32 ts_high, u64 ts_ns),
+
+	    TP_ARGS(cached_time, ts_high, ts_ns),
+
+	    TP_STRUCT__entry(__field(u64, cached_time)
+			     __field(u32, ts_high)
+			     __field(u64, ts_ns)),
+
+	    TP_fast_assign(__entry->cached_time = cached_time;
+			   __entry->ts_high = ts_high;
+			   __entry->ts_ns = ts_ns;),
+
+	    TP_printk("cached_time=%llu ts_high=%u ts_ns=%llu",
+		      __entry->cached_time, __entry->ts_high, __entry->ts_ns)
+);
+
 DECLARE_EVENT_CLASS(ice_esw_br_fdb_template,
 		    TP_PROTO(struct ice_esw_br_fdb_entry *fdb),
 		    TP_ARGS(fdb),
-- 
2.47.1

[PATCH net-next 07/10] ice: parser: use kcalloc for table allocation

[Tony Nguyen]

From: Weimin Xiong <xiongwm2026@163.com>

Use kcalloc() when calculating the parser table allocation size so an
overflow in the firmware-provided item dimensions is detected before
allocation.

Signed-off-by: Weimin Xiong <xiongwm2026@163.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_parser.c b/drivers/net/ethernet/intel/ice/ice_parser.c
index 3ede4c1a5a8a..d239102c52ff 100644
--- a/drivers/net/ethernet/intel/ice/ice_parser.c
+++ b/drivers/net/ethernet/intel/ice/ice_parser.c
@@ -102,7 +102,7 @@ ice_parser_create_table(struct ice_hw *hw, u32 sect_type,
 	if (!seg)
 		return ERR_PTR(-EINVAL);
 
-	table = kzalloc(item_size * length, GFP_KERNEL);
+	table = kcalloc(length, item_size, GFP_KERNEL);
 	if (!table)
 		return ERR_PTR(-ENOMEM);
 
-- 
2.47.1

Re: [PATCH net-next 07/10] ice: parser: use kcalloc for table allocation

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 1 (1) · Medium: 1 (1) · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [High] ice_parser_create_table() still allows a heap out-of-bounds
  write controlled by firmware data.
- [Medium] The commit message says kcalloc() is used so that "an overflow
  in the firmware-provided item dimensions is detected before…

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but it is a high-
  severity bug on the same allocation-failure path.
- [Medium] This problem wasn't introduced by this patch.

--

ice: parser: use kcalloc for table allocation

This commit changes the allocation in ice_parser_create_table() from
kzalloc(item_size * length) to kcalloc(length, item_size). The goal is
to catch multiplication overflow before the allocation.

> Use kcalloc() when calculating the parser table allocation size so an
> overflow in the firmware-provided item dimensions is detected before
> allocation.

[Severity: Medium]
Is this description accurate? In ice_parser_create_table(), neither
item_size nor length comes from firmware.

All of the *_table_get() callers pass a sizeof() and an ICE_*_TABLE_SIZE
constant. For example, ice_pg_cam_table_get() does this:

	return ice_parser_create_table(hw, ICE_SID_RXPARSER_CAM,
				       sizeof(struct ice_pg_cam_item),
				       ICE_PG_CAM_TABLE_SIZE,

The largest length is ICE_PG_CAM_TABLE_SIZE (2048). The multiplication
cannot overflow, so the kcalloc() overflow check can never fire.

Could the commit message describe this as a cleanup, not as hardening
against firmware input?

> diff --git a/drivers/net/ethernet/intel/ice/ice_parser.c b/drivers/net/ethernet/intel/ice/ice_parser.c
> index 3ede4c1a5a8a5..d239102c52ffd 100644
> --- a/drivers/net/ethernet/intel/ice/ice_parser.c
> +++ b/drivers/net/ethernet/intel/ice/ice_parser.c
> @@ -102,7 +102,7 @@ ice_parser_create_table(struct ice_hw *hw, u32 sect_type,
>  	if (!seg)
>  		return ERR_PTR(-EINVAL);
>  
> -	table = kzalloc(item_size * length, GFP_KERNEL);
> +	table = kcalloc(length, item_size, GFP_KERNEL);

[Severity: High]
The table holds length entries. Can the fill loop right after this still
write past the end of it?

In ice_parser_create_table(), the index comes from the package section
header, and nothing compares it with length:

		if (data) {
			struct ice_pkg_sect_hdr *hdr = state.sect;

			if (!no_offset)
				idx = le16_to_cpu(hdr->offset) +
					state.entry_idx;

			item = (void *)((uintptr_t)table + idx * item_size);
			parse_item(hw, idx, item, data, item_size);

			if (no_offset)
				idx++;
		}

ice_parser_sect_item_get() only checks the entry index against the
package's own hdr->count. In no_offset mode (bst_tcam, bst_lbl,
ptype_mk_tcam), idx goes up once for every entry in every section of
that type, with no limit.

For example, the flg_rd table has ICE_FLG_RD_TABLE_SIZE (64) entries. A
section with count = 1 and offset = 64 would make ice_flg_rd_parse_item()
write to table[64]:

	rdi->idx = idx;
	rdi->expose = FIELD_GET(ICE_FRT_EXPO, d8);
	rdi->intr_flg_id = FIELD_GET(ICE_FRT_IFID, d8);

The source data is hw->seg, which comes from the DDP package in
/lib/firmware. A VF request can trigger the table fill at runtime:

ice_vc_fdir_parse_raw() / ice_parse_raw_rss_pattern()
  ice_parser_create()
    ice_flg_rd_table_get()
      ice_parser_create_table()

The commit message is about guarding this table against firmware input.
Would it make sense to compute idx in a type wide enough not to wrap, and
to reject or skip entries with idx >= length before computing item and
calling parse_item()?

>  	if (!table)
>  		return ERR_PTR(-ENOMEM);

[Severity: High]
This isn't a bug introduced by this patch, but what happens to this
ERR_PTR(-ENOMEM) once it gets back to ice_parser_create()?

Each sub-table result is stored in the struct before the IS_ERR() check,
and the field is not cleared before the jump to the error label:

	p->imem_table = ice_imem_table_get(hw);
	if (IS_ERR(p->imem_table)) {
		err = p->imem_table;
		goto err;
	}
	...
err:
	ice_parser_destroy(p);
	return err;

ice_parser_destroy() then calls kfree() on every field without checking
IS_ERR():

	kfree(psr->imem_table);
	kfree(psr->mi_table);
	...

kfree() only returns early for ZERO_OR_NULL_PTR(). An ERR_PTR value goes
on to virt_to_page() and the slab free path with a bogus address.

A failed kcalloc() here can cause this. The pg_cam table has 2048
entries, so that is a multi-page GFP_KERNEL allocation. Other sources
are ERR_PTR(-EINVAL) when hw->seg is NULL, and ice_xlt_kb_get()
returning ERR_PTR(-EINVAL) for a missing key builder section or
ERR_PTR(-ENOMEM) when its kzalloc fails.

ice_parser_create() can be reached from VF raw FDIR and RSS requests.
Can a VF keep triggering an invalid free on the host this way?

Would it help to keep each result in a local variable and assign it only
on success, or to set the field to NULL before goto err?

>  

[Severity: Medium]
This is a pre-existing issue, but can the data pointer passed to
parse_item() point past the end of the package section?

ice_parser_sect_item_get() only checks the index against the section's
own count:

	hdr = section;
	if (index >= le16_to_cpu(hdr->count))
		return NULL;

	return section + data_off + index * size;

ice_pkg_enum_section() checks that the section's offset and size fit in
ICE_PKG_BUF_SIZE. Nothing checks that data_off + count * size fits
inside the section.

Counts can be as high as 65535, and entries as large as
ICE_SID_LBL_ENTRY_SIZE bytes. With a large count, the returned pointers
would go past the 4 KB package buffer. Each parse_item callback then
reads size bytes from there into the parser tables.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260929224153.1455466-1-anthony.l.nguyen%40intel.com

[PATCH net-next 08/10] ice: simplify ice_pf_state_is_nominal()

[Tony Nguyen]

From: Yury Norov <ynorov@nvidia.com>

The function creates a temporary mask on stack just to check that
first ICE_STATE_NOMINAL_CHECK_BITS is empty. Simplify it by using
the ice_pf_state_is_nominal().

Signed-off-by: Yury Norov <ynorov@nvidia.com>
Reviewed-by: Sergey Temerkhanov <sergey.temerkhanov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_lib.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
index 9e08db376d3d..73996e3022ef 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -1705,16 +1705,10 @@ static void ice_vsi_set_rss_flow_fld(struct ice_vsi *vsi)
  */
 bool ice_pf_state_is_nominal(struct ice_pf *pf)
 {
-	DECLARE_BITMAP(check_bits, ICE_STATE_NBITS) = { 0 };
-
 	if (!pf)
 		return false;
 
-	bitmap_set(check_bits, 0, ICE_STATE_NOMINAL_CHECK_BITS);
-	if (bitmap_intersects(pf->state, check_bits, ICE_STATE_NBITS))
-		return false;
-
-	return true;
+	return bitmap_empty(pf->state, ICE_STATE_NOMINAL_CHECK_BITS);
 }
 
 #define ICE_FW_MODE_REC_M BIT(1)
-- 
2.47.1

Re: [PATCH net-next 08/10] ice: simplify ice_pf_state_is_nominal()

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The commit message for "ice: simplify ice_pf_state_is_nominal()"
  names the wrong helper.

--

ice: simplify ice_pf_state_is_nominal()

This commit changes ice_pf_state_is_nominal() so it no longer builds a
temporary mask on the stack and calls bitmap_intersects(). It now calls
bitmap_empty() on the first ICE_STATE_NOMINAL_CHECK_BITS of pf->state.

> The function creates a temporary mask on stack just to check that
> first ICE_STATE_NOMINAL_CHECK_BITS is empty. Simplify it by using
> the ice_pf_state_is_nominal().

[Severity: Low]
This isn't a bug, but should this say bitmap_empty() instead of
ice_pf_state_is_nominal()? As written, the sentence names the function
being changed.

The helper the patch adds in ice_pf_state_is_nominal() is:

	return bitmap_empty(pf->state, ICE_STATE_NOMINAL_CHECK_BITS);

Would "Simplify it by using bitmap_empty()" be the intended wording?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260929224153.1455466-1-anthony.l.nguyen%40intel.com

[PATCH net-next 09/10] ice: drop pf == NULL check in ice_pf_state_is_nominal()

[Tony Nguyen]

From: Yury Norov <ynorov@nvidia.com>

The function has 3 callers, all except one explicitly require
pf != NULL. Add the corresponding check to the remaining caller,
and remove it from the ice_pf_state_is_nominal(). It makes the
fun function a one-liner.

Signed-off-by: Yury Norov <ynorov@nvidia.com>
Reviewed-by: Sergey Temerkhanov <sergey.temerkhanov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_lib.c  | 3 ---
 drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
index 73996e3022ef..6d5b8acc4764 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -1705,9 +1705,6 @@ static void ice_vsi_set_rss_flow_fld(struct ice_vsi *vsi)
  */
 bool ice_pf_state_is_nominal(struct ice_pf *pf)
 {
-	if (!pf)
-		return false;
-
 	return bitmap_empty(pf->state, ICE_STATE_NOMINAL_CHECK_BITS);
 }
 
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 73f69d453542..454fba07d4ec 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -5530,7 +5530,7 @@ static int ice_suspend(struct device *dev)
 
 	pf = pci_get_drvdata(pdev);
 
-	if (!ice_pf_state_is_nominal(pf)) {
+	if (!pf || !ice_pf_state_is_nominal(pf)) {
 		dev_err(dev, "Device is not ready, no need to suspend it\n");
 		return -EBUSY;
 	}
-- 
2.47.1

[PATCH net-next 10/10] ice: simplify ice_vc_dis_qs_msg() a little

[Tony Nguyen]

From: Przemek Kitszel <przemyslaw.kitszel@intel.com>

Remove special case logic for disabling all queues in ice_vc_dis_qs_msg().
There were no actual speedup from it, the only difference was in saved
bitmap checks, but the HW operations take the majority of time anyway.
ice_vsi_stop_all_rx_rings() used (in the removed code) loops over rings
anyway.

With a message added just before removed code, in the "remove VF" scenario
there were no noticeable difference with the "speedup" and without, and it
takes ~0.06s on my machine from this point to the whole iavf removed, so
really no big deal anyway.

Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/ice/virt/queues.c | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/virt/queues.c b/drivers/net/ethernet/intel/ice/virt/queues.c
index 431c9c546b04..ac7f98479b13 100644
--- a/drivers/net/ethernet/intel/ice/virt/queues.c
+++ b/drivers/net/ethernet/intel/ice/virt/queues.c
@@ -375,6 +375,8 @@ int ice_vf_vsi_dis_single_txq(struct ice_vf *vf, struct ice_vsi *vsi, u16 q_id)
  * @msg: pointer to the msg buffer
  *
  * called from the VF to disable all or specific queue(s)
+ *
+ * Return: exit code of sending the virtchnl response.
  */
 int ice_vc_dis_qs_msg(struct ice_vf *vf, u8 *msg)
 {
@@ -424,20 +426,7 @@ int ice_vc_dis_qs_msg(struct ice_vf *vf, u8 *msg)
 	}
 
 	q_map = vqs->rx_queues;
-	/* speed up Rx queue disable by batching them if possible */
-	if (q_map &&
-	    bitmap_equal(&q_map, vf->rxq_ena, ICE_MAX_RSS_QS_PER_VF)) {
-		if (ice_vsi_stop_all_rx_rings(vsi)) {
-			dev_err(ice_pf_to_dev(vsi->back), "Failed to stop all Rx rings on VSI %d\n",
-				vsi->vsi_num);
-			v_ret = VIRTCHNL_STATUS_ERR_PARAM;
-			goto error_param;
-		}
-
-		for_each_set_bit(vf_q_id, &q_map, ICE_MAX_RSS_QS_PER_VF)
-			ice_vf_dis_rxq_interrupt(vsi, vf_q_id);
-		bitmap_zero(vf->rxq_ena, ICE_MAX_RSS_QS_PER_VF);
-	} else if (q_map) {
+	if (q_map) {
 		for_each_set_bit(vf_q_id, &q_map, ICE_MAX_RSS_QS_PER_VF) {
 			if (!ice_vc_isvalid_q_id(vsi, vf_q_id)) {
 				v_ret = VIRTCHNL_STATUS_ERR_PARAM;
-- 
2.47.1

Re: [PATCH net-next 10/10] ice: simplify ice_vc_dis_qs_msg() a little

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The commit message misdescribes the code it removes.

--

ice: simplify ice_vc_dis_qs_msg() a little

This commit removes a special case in ice_vc_dis_qs_msg(). When the
requested rx_queues bitmap matched vf->rxq_ena, that case disabled all Rx
queues as a batch through ice_vsi_stop_all_rx_rings(). All Rx queues now go
through the per-queue ice_vsi_ctrl_one_rx_ring() path.

> diff --git a/drivers/net/ethernet/intel/ice/virt/queues.c b/drivers/net/ethernet/intel/ice/virt/queues.c
> index 431c9c546b04f..ac7f98479b130 100644
> --- a/drivers/net/ethernet/intel/ice/virt/queues.c
> +++ b/drivers/net/ethernet/intel/ice/virt/queues.c

[ ... ]

> @@ -424,20 +426,7 @@ int ice_vc_dis_qs_msg(struct ice_vf *vf, u8 *msg)
>  	}
>  
>  	q_map = vqs->rx_queues;
> -	/* speed up Rx queue disable by batching them if possible */
> -	if (q_map &&
> -	    bitmap_equal(&q_map, vf->rxq_ena, ICE_MAX_RSS_QS_PER_VF)) {
> -		if (ice_vsi_stop_all_rx_rings(vsi)) {
> -			dev_err(ice_pf_to_dev(vsi->back), "Failed to stop all Rx rings on VSI %d\n",
> -				vsi->vsi_num);
> -			v_ret = VIRTCHNL_STATUS_ERR_PARAM;
> -			goto error_param;
> -		}
> -
> -		for_each_set_bit(vf_q_id, &q_map, ICE_MAX_RSS_QS_PER_VF)
> -			ice_vf_dis_rxq_interrupt(vsi, vf_q_id);
> -		bitmap_zero(vf->rxq_ena, ICE_MAX_RSS_QS_PER_VF);
> -	} else if (q_map) {
> +	if (q_map) {

[Severity: Low]
Does the commit message describe the removed path correctly? It says:

  There were no actual speedup from it, the only difference was in saved
  bitmap checks, but the HW operations take the majority of time anyway.
  ice_vsi_stop_all_rx_rings() used (in the removed code) loops over rings
  anyway.

ice_vsi_stop_all_rx_rings() ends up in ice_vsi_ctrl_all_rx_rings(). That
function sends the disable request to every ring without waiting, flushes
once, and only then polls each ring:

drivers/net/ethernet/intel/ice/ice_lib.c:ice_vsi_ctrl_all_rx_rings() {
    ...
	ice_for_each_rxq(vsi, i)
		ice_vsi_ctrl_one_rx_ring(vsi, ena, i, false);

	ice_flush(&vsi->back->hw);

	ice_for_each_rxq(vsi, i) {
		ret = ice_vsi_wait_one_rx_ring(vsi, ena, i);
    ...
}

Its kernel-doc says this is on purpose: "This will let all of the register
writes complete when enabling/disabling the Rx rings before waiting for
the change in hardware to complete."

The path that remains calls ice_vsi_ctrl_one_rx_ring() with wait set to
true for each queue. Each call does its own ice_flush() and
ice_pf_rxq_wait() poll before the next queue starts:

drivers/net/ethernet/intel/ice/ice_base.c:ice_vsi_ctrl_one_rx_ring() {
    ...
	if (!wait)
		return 0;

	ice_flush(hw);
	return ice_pf_rxq_wait(pf, pf_q, ena);
}

So the removed code seems to have saved overlapped hardware wait time, not
bitmap checks.

ICE_MAX_RSS_QS_PER_VF is 16, and ice_pf_rxq_wait() is bounded by
ICE_Q_WAIT_MAX_RETRY polls of usleep_range(20, 40). That puts the worst
case at about 32ms instead of about 2ms. This is small and fits the
measurement in the commit message.

Could the justification be reworded to match what the code does?

The commit message also leaves out two small behaviour differences:

- The old path stopped every ring the VSI owns through ice_for_each_rxq(),
  not only the bits set in vf->rxq_ena.

- On a partial failure, the old path left vf->rxq_ena and the queue
  interrupts untouched. The per-queue path will already have cleared the
  rxq_ena bits and called ice_vf_dis_rxq_interrupt() for every queue it
  finished before the one that failed.

Should these be mentioned?

>  		for_each_set_bit(vf_q_id, &q_map, ICE_MAX_RSS_QS_PER_VF) {
>  			if (!ice_vc_isvalid_q_id(vsi, vf_q_id)) {
>  				v_ret = VIRTCHNL_STATUS_ERR_PARAM;

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260929224153.1455466-1-anthony.l.nguyen%40intel.com

Re: [PATCH net-next 00/10][pull request] Intel Wired LAN Driver Updates 2026-09-29 (ice)

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Tony Nguyen <anthony.l.nguyen@intel.com>:

On Tue, 29 Sep 2026 15:41:40 -0700 you wrote:
> Grzegorz reduces DSCP message from error to debug when FW DCB
> management is active since it's an expected condition.
> 
> Marcin utilizes, existing, ice_fill_eth_hdr() call to set ethernet
> header value.
> 
> Jake reduces padding in ice_flash_info struct by moving sr_words
> location.
> 
> [...]

Here is the summary with links:
  - [net-next,01/10] ice: reduce loglevel to debug for 'Can't delete DSCP' message
    https://git.kernel.org/netdev/net-next/c/ecf7e8b5c39d
  - [net-next,02/10] ice: use ice_fill_eth_hdr() in ice_fill_sw_rule()
    https://git.kernel.org/netdev/net-next/c/c160960c7f7e
  - [net-next,03/10] ice: reorder ice_flash_info fields to eliminate padding
    https://git.kernel.org/netdev/net-next/c/74a4378ee5b9
  - [net-next,04/10] ice: increase OICR interrupt moderation rate to 20K interrupts/sec
    https://git.kernel.org/netdev/net-next/c/0b1419908406
  - [net-next,05/10] ice: use inline helpers instead of memcmp() for IPv6 mask checks in ice_ethtool_fdir
    https://git.kernel.org/netdev/net-next/c/49a4ae7adead
  - [net-next,06/10] ice: add rx timestamp tracepoint for debugging
    https://git.kernel.org/netdev/net-next/c/5443362bae71
  - [net-next,07/10] ice: parser: use kcalloc for table allocation
    https://git.kernel.org/netdev/net-next/c/ef1c1106e178
  - [net-next,08/10] ice: simplify ice_pf_state_is_nominal()
    https://git.kernel.org/netdev/net-next/c/f93a165c9bc3
  - [net-next,09/10] ice: drop pf == NULL check in ice_pf_state_is_nominal()
    https://git.kernel.org/netdev/net-next/c/2270d2bf1606
  - [net-next,10/10] ice: simplify ice_vc_dis_qs_msg() a little
    https://git.kernel.org/netdev/net-next/c/ce0e3e4b98c2

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html