From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 68F4072627 for ; Mon, 6 Apr 2026 11:21:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775474490; cv=none; b=rDM7LZXlbCTP3yifwDgwYsMRb/Scb2/AgPwOpYncfrxX6GjuzlroLj4FY+qnTNPZ1BrEnrihV9O9GsjXy4u1iTb6vrjeBSUuOeIGTMc93tsKHdF2j7LJkOZI1x9bXKfX1y+eETNRwR1nYwhWvVuSmC6V+mea6K3wzGMF6Wl/lC0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775474490; c=relaxed/simple; bh=LM+/xI0ovO+0zVOlyGzsXdJ+OP9bhvrhm+hrSOEbt4U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RNsxaN2sWtVEh1OCHfngwHiqDLTijyTrij2BCjumvNK6NP7O2UPWPr7vQ3lK1MwMett7DGwXhfiT8+IShbuUXNAOrGKBEKTIjg2yGePc8MKZRyxGCfqbxa5rnf5jRoDD1HX1wMvRntE6CL0jvwksbIRBAF1IAI52coVVyMPoPd4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=AZtu9fJc; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="AZtu9fJc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775474488; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9mJAFR2P64r9/LOJtwiqZN1rPSkz3fb8OpCJmbM7VKg=; b=AZtu9fJc9flSWtC6zb3S+Wx9xlYZqdNwcZ2WngTfVRawiBi1r2hE7BZwEliuAIC5wrBdRv b0pQaZGl4B6cPZjTar23XN4yOIX5D+ax0StSdqr5TQ3FwYykYrEpHDMatPlcZHYWWma0AW iX00gEgAQxL+g9QthyJs+7Zf96ZGfqQ= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-687-KSdgjjPRORm_AoLDMpOZpQ-1; Mon, 06 Apr 2026 07:21:27 -0400 X-MC-Unique: KSdgjjPRORm_AoLDMpOZpQ-1 X-Mimecast-MFC-AGG-ID: KSdgjjPRORm_AoLDMpOZpQ_1775474486 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 057D01800764; Mon, 6 Apr 2026 11:21:26 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.44.48.51]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 72126300019F; Mon, 6 Apr 2026 11:21:22 +0000 (UTC) From: Jose Ignacio Tornos Martinez To: netdev@vger.kernel.org Cc: intel-wired-lan@lists.osuosl.org, jesse.brandeburg@intel.com, anthony.l.nguyen@intel.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, Jose Ignacio Tornos Martinez Subject: [PATCH net 2/3] i40e: skip unnecessary VF reset when setting trust Date: Mon, 6 Apr 2026 13:20:56 +0200 Message-ID: <20260406112057.906685-3-jtornosm@redhat.com> In-Reply-To: <20260406112057.906685-1-jtornosm@redhat.com> References: <20260406112057.906685-1-jtornosm@redhat.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 When VF trust is changed, i40e_ndo_set_vf_trust() always calls i40e_vc_reset_vf() to sync MAC/VLAN filters. However, this reset is only necessary when trust is removed from a VF that has ADQ (advanced queue) filters, which need to be deleted In all other cases, the reset causes a ~10 second delay during which: - VF must reinitialize completely - Any in-progress operations (like bonding enslave) fail with timeouts - VF is unavailable The MAC/VLAN filter sync will happen naturally through the normal VF operations and doesn't require a forced reset. Fix by only resetting when actually needed: when removing trust from a VF that has ADQ cloud filters. For all other trust changes, just update the trust flag and let normal operation continue. Signed-off-by: Jose Ignacio Tornos Martinez --- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c index a26c3d47ec15..fea267af7afe 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c @@ -4987,16 +4987,21 @@ int i40e_ndo_set_vf_trust(struct net_device *netdev, int vf_id, bool setting) set_bit(__I40E_MACVLAN_SYNC_PENDING, pf->state); pf->vsi[vf->lan_vsi_idx]->flags |= I40E_VSI_FLAG_FILTER_CHANGED; - i40e_vc_reset_vf(vf, true); dev_info(&pf->pdev->dev, "VF %u is now %strusted\n", vf_id, setting ? "" : "un"); + /* Only reset VF if we're removing trust and it has ADQ cloud filters. + * Cloud filters can only be added when trusted, so they must be + * removed when trust is revoked. Other trust changes don't require + * reset - MAC/VLAN filter sync happens through normal operation. + */ if (vf->adq_enabled) { if (!vf->trusted) { dev_info(&pf->pdev->dev, "VF %u no longer Trusted, deleting all cloud filters\n", vf_id); i40e_del_all_cloud_filters(vf); + i40e_vc_reset_vf(vf, true); } } -- 2.53.0