> -----Original Message-----
> From: Jose Ignacio Tornos Martinez <[email protected]>
> Sent: Friday, June 19, 2026 8:13 AM
> To: [email protected]
> Cc: [email protected]; Kitszel, Przemyslaw
> <[email protected]>; Loktionov, Aleksandr
> <[email protected]>; Keller, Jacob E
> <[email protected]>; [email protected];
> [email protected]; Nguyen, Anthony L
> <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected]; Jose Ignacio
> Tornos Martinez <[email protected]>
> Subject: [PATCH net v6 4/4] 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. While the delay is
> smaller than i40e, this reset is still unnecessary in most cases.
>
> When granting trust, no reset is needed - we can just set the
> capability flag to allow privileged operations.
>
> When revoking trust, we only need to reset (conservative approach) if
> the VF has actually configured advanced features that require cleanup
> (MAC LLDP filters, promiscuous mode). For VFs in a clean state, we can
> safely change the trust setting without the disruptive reset.
>
> When we do reset, we maintain the original ice pattern that has been
> reliable in production: cleanup LLDP filters first, then set vf-
> >trusted, then reset. This ensures the privilege capability bit is
> handled correctly during reset rebuild.
>
> When we don't reset, we manually handle the capability flag via helper
> function, eliminating the delay.
>
> Signed-off-by: Jose Ignacio Tornos Martinez <[email protected]>
> ---
> v6: AI review identified issues with v5's reset-before-cleanup
> approach. Revert
> to original reset procedure (cleanup before reset) which has
> proven reliable,
> just adding the conditional check to skip reset when VF has no
> advanced
> features configured.
> v5: https://lore.kernel.org/all/20260429102426.210750-5-
> [email protected]/
>
> drivers/net/ethernet/intel/ice/ice_sriov.c | 33 +++++++++++++++++++--
> -
> 1 file changed, 29 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index 7e00e091756d..XXXXXXXXXXXXXXXX 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
> @@ -1364,6 +1364,23 @@ int ice_set_vf_mac(struct net_device *netdev,
> int vf_id, u8 *mac)
> return __ice_set_vf_mac(ice_netdev_to_pf(netdev), vf_id, mac);
> }
>
> +/**
> + * ice_setup_vf_trust - Enable/disable VF trust mode without reset
> + * @vf: VF to configure
> + * @setting: trust setting
> + *
> + * Update VF flags when changing trust without performing a VF reset.
> + * This is only called when it's safe to skip the reset (VF has no
> +advanced
> + * features configured that need cleanup).
> + */
> +static void ice_setup_vf_trust(struct ice_vf *vf, bool setting) {
> + if (setting)
> + set_bit(ICE_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps);
> + else
> + clear_bit(ICE_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps);
> }
> +
> /**
> * ice_set_vf_trust
> * @netdev: network interface device structure @@ -1399,11 +1416,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);
> -
> + /* Reset only if revoking trust and VF has advanced features
> configured */
> + if (!trusted &&
> + (vf->num_mac_lldp > 0 ||
> + test_bit(ICE_VF_STATE_UC_PROMISC, vf->vf_states) ||
> + test_bit(ICE_VF_STATE_MC_PROMISC, vf->vf_states))) {
> + while (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);
> + } else {
> + vf->trusted = trusted;
> + ice_setup_vf_trust(vf, trusted);
> + }
> - 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");
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <[email protected]>
