From patchwork Mon Mar 20 23:47:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kirsher, Jeffrey T" X-Patchwork-Id: 741315 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3vnCLN17wKz9s3l for ; Tue, 21 Mar 2017 10:47:56 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932165AbdCTXry (ORCPT ); Mon, 20 Mar 2017 19:47:54 -0400 Received: from mga05.intel.com ([192.55.52.43]:49349 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932103AbdCTXrV (ORCPT ); Mon, 20 Mar 2017 19:47:21 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP; 20 Mar 2017 16:47:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,196,1486454400"; d="scan'208";a="1125082676" Received: from aloteanu-mobl1.amr.corp.intel.com (HELO jtkirshe-DESK.amr.corp.intel.com.com) ([10.255.74.86]) by fmsmga001.fm.intel.com with ESMTP; 20 Mar 2017 16:47:19 -0700 From: Jeff Kirsher To: davem@davemloft.net Cc: Jacob Keller , netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com, jogreene@redhat.com, Jeff Kirsher Subject: [net-next 10/13] i40e: don't re-enable ATR when flushing filters if SB has TCP4/IPv4 rules Date: Mon, 20 Mar 2017 16:47:09 -0700 Message-Id: <20170320234712.84157-11-jeffrey.t.kirsher@intel.com> X-Mailer: git-send-email 2.12.0 In-Reply-To: <20170320234712.84157-1-jeffrey.t.kirsher@intel.com> References: <20170320234712.84157-1-jeffrey.t.kirsher@intel.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Jacob Keller When flushing and replaying FDIR filters, it is possible we would disable ATR, and then re-enable it even though we should have kept it disabled due to existing TCP/IPv4 filters. Fix this by checking whether we have TCP4/IPv4 filters before re-enabling. Alternatively, we could instead restore ATR and then replay filters, however, this would cause us to rapidly enable and then disable ATR in some cases. Change-ID: I076e4cc1e4409bce7f98f3c213295433a4ff43d8 Signed-off-by: Jacob Keller Reviewed-by: Avinash Dayanand Reviewed-by: Alan Brady Reviewed-by: Mitch Williams Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher --- drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index 437b79eeb8b5..cc33ac835181 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -6228,7 +6228,7 @@ static void i40e_fdir_flush_and_replay(struct i40e_pf *pf) } else { /* replay sideband filters */ i40e_fdir_filter_restore(pf->vsi[pf->lan_vsi]); - if (!disable_atr) + if (!disable_atr && !pf->fd_tcp_rule) pf->hw_disabled_flags &= ~I40E_FLAG_FD_ATR_ENABLED; clear_bit(__I40E_FD_FLUSH_REQUESTED, &pf->state); if (I40E_DEBUG_FD & pf->hw.debug_mask)