From: Simon Horman <horms@kernel.org>
To: jtornosm@redhat.com
Cc: Simon Horman <horms@kernel.org>,
stable@vger.kernel.org, davem@davemloft.net,
jesse.brandeburg@intel.com, edumazet@google.com,
przemyslaw.kitszel@intel.com, netdev@vger.kernel.org,
pabeni@redhat.com, intel-wired-lan@lists.osuosl.org,
anthony.l.nguyen@intel.com, kuba@kernel.org
Subject: Re: [PATCH net v3 4/5] ice: skip unnecessary VF reset when setting trust
Date: Thu, 16 Apr 2026 14:55:19 +0100 [thread overview]
Message-ID: <20260416135519.873936-1-horms@kernel.org> (raw)
In-Reply-To: <20260414110006.124286-5-jtornosm@redhat.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
---
ice: skip unnecessary VF reset when setting trust
Similar to the i40e fix, ice_set_vf_trust() unconditionally calls
ice_reset_vf() when the trust setting changes. The ice driver already
has logic to clean up MAC LLDP filters when removing trust, which is
the only operation that requires filter synchronization. After this
cleanup, the VF reset is only necessary if there were actually filters
to remove.
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
> @@ -1399,14 +1399,19 @@ int ice_set_vf_trust(struct net_device *netdev, int vf_id, bool trusted)
>
> mutex_lock(&vf->cfg_lock);
>
> - while (!trusted && vf->num_mac_lldp)
> - ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf), false);
> -
> vf->trusted = trusted;
> - ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
> dev_info(ice_pf_to_dev(pf), "VF %u is now %strusted\n",
> vf_id, trusted ? "" : "un");
>
> + /* Only reset VF if removing trust and there are MAC LLDP filters
> + * to clean up. Reset is needed to ensure filter removal completes.
> + */
> + if (!trusted && vf->num_mac_lldp) {
> + while (vf->num_mac_lldp)
> + ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf), false);
> + ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
> + }
> +
Does setting vf->trusted before the cleanup loop break the filter
removal? Looking at the cleanup mechanism, ice_vf_update_mac_lldp_num()
calls ice_vf_is_lldp_ena() which checks both num_mac_lldp AND
vf->trusted:
ice_vf_lib.h:ice_vf_is_lldp_ena():
return vf->num_mac_lldp && vf->trusted;
With the new ordering where vf->trusted is set to false before the loop:
ice_vf_update_mac_lldp_num() logic:
was_ena = ice_vf_is_lldp_ena(vf); // evaluates to (num > 0 && FALSE) = FALSE
vf->num_mac_lldp--;
is_ena = ice_vf_is_lldp_ena(vf); // evaluates to FALSE
if (was_ena != is_ena) // FALSE != FALSE is FALSE
ice_vsi_cfg_sw_lldp(vsi, false, false); // NEVER called
But in the old code, vf->trusted was still TRUE during the loop:
was_ena = (num > 0 && TRUE) = TRUE
vf->num_mac_lldp--;
is_ena = (0 && TRUE) = FALSE // when last filter removed
if (was_ena != is_ena) // TRUE != FALSE is TRUE
ice_vsi_cfg_sw_lldp(...) // called to remove LLDP filters
So the ETH_P_LLDP packet filters are not removed from the hardware
switch, leaving stale filter rules. Should vf->trusted be set after the
cleanup loop instead?
> mutex_unlock(&vf->cfg_lock);
>
> out_put_vf:
next prev parent reply other threads:[~2026-04-16 13:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 11:00 [PATCH net v3 0/5] Fix i40e/ice/iavf VF bonding after netdev lock changes Jose Ignacio Tornos Martinez
2026-04-14 11:00 ` [PATCH net v3 1/5] iavf: return EBUSY if reset in progress or not ready during MAC change Jose Ignacio Tornos Martinez
2026-04-17 14:38 ` [Intel-wired-lan] " Przemek Kitszel
2026-04-14 11:00 ` [PATCH net v3 2/5] i40e: skip unnecessary VF reset when setting trust Jose Ignacio Tornos Martinez
2026-04-14 11:41 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-04-16 15:31 ` Simon Horman
2026-04-14 11:00 ` [PATCH net v3 3/5] iavf: send MAC change request synchronously Jose Ignacio Tornos Martinez
2026-04-17 9:31 ` Simon Horman
2026-04-17 13:05 ` Przemek Kitszel
2026-04-14 11:00 ` [PATCH net v3 4/5] ice: skip unnecessary VF reset when setting trust Jose Ignacio Tornos Martinez
2026-04-16 13:55 ` Simon Horman [this message]
2026-04-14 11:00 ` [PATCH net v3 5/5] iavf: refactor virtchnl polling into single function Jose Ignacio Tornos Martinez
2026-04-14 11:43 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-04-16 5:51 ` Jose Ignacio Tornos Martinez
2026-04-16 23:09 ` Jacob Keller
2026-04-17 10:30 ` Jose Ignacio Tornos Martinez
2026-04-17 11:45 ` Simon Horman
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=20260416135519.873936-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=jtornosm@redhat.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=stable@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