netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: davem@davemloft.net
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
	jogreene@redhat.com, Jacob Keller <jacob.e.keller@intel.com>
Subject: [net-next 16/25] fm10k: don't handle mailbox events in iov_event path and always process mailbox
Date: Tue, 14 Apr 2015 16:51:02 -0700	[thread overview]
Message-ID: <1429055471-401-17-git-send-email-jeffrey.t.kirsher@intel.com> (raw)
In-Reply-To: <1429055471-401-1-git-send-email-jeffrey.t.kirsher@intel.com>

Since we already schedule the service task, we can just wait for this
task to handle the mailbox events from the VF. This reduces some complex
code flow, and makes it so we have a single path for handling the VF
messages. There is a possibility that we have a slight delay in handling
VF messages, but it should be minimal.

The result of tx_complete and !rx_ready is insufficient to determine
whether we need to process the mailbox. There is a possible race
condition whereby the VF fills up the mbmem for us, but we have already
recently processed the mailboxes in the interrupt. During this time,
the interrupt is disabled. Thus, our Rx FIFO is empty, but the mbmem now
has data in it. Since we continually check whether Rx FIFO is empty, we
then never call process. This results in the possibility to prevent PF
from handling the VF mailbox messages.

Instead, just call process every time, despite the fact that we may or
may not have anything to process for the VF. There should be minimal
overhead for doing this, and it resolves an issue where the VF never
comes up due to never getting response for its SET_LPORT_STATE message.

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Matthew Vick <matthew.vick@intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
---
 drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 34 ++--------------------------
 drivers/net/ethernet/intel/fm10k/fm10k_pci.c |  3 +++
 2 files changed, 5 insertions(+), 32 deletions(-)

diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
index 69cbfde..0b37e19 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
@@ -47,7 +47,7 @@ s32 fm10k_iov_event(struct fm10k_intfc *interface)
 {
 	struct fm10k_hw *hw = &interface->hw;
 	struct fm10k_iov_data *iov_data;
-	s64 mbicr, vflre;
+	s64 vflre;
 	int i;
 
 	/* if there is no iov_data then there is no mailboxes to process */
@@ -63,7 +63,7 @@ s32 fm10k_iov_event(struct fm10k_intfc *interface)
 		goto read_unlock;
 
 	if (!(fm10k_read_reg(hw, FM10K_EICR) & FM10K_EICR_VFLR))
-		goto process_mbx;
+		goto read_unlock;
 
 	/* read VFLRE to determine if any VFs have been reset */
 	do {
@@ -86,32 +86,6 @@ s32 fm10k_iov_event(struct fm10k_intfc *interface)
 		}
 	} while (i != iov_data->num_vfs);
 
-process_mbx:
-	/* read MBICR to determine which VFs require attention */
-	mbicr = fm10k_read_reg(hw, FM10K_MBICR(1));
-	mbicr <<= 32;
-	mbicr |= fm10k_read_reg(hw, FM10K_MBICR(0));
-
-	i = iov_data->next_vf_mbx ? : iov_data->num_vfs;
-
-	for (mbicr <<= 64 - i; i--; mbicr += mbicr) {
-		struct fm10k_mbx_info *mbx = &iov_data->vf_info[i].mbx;
-
-		if (mbicr >= 0)
-			continue;
-
-		if (!hw->mbx.ops.tx_ready(&hw->mbx, FM10K_VFMBX_MSG_MTU))
-			break;
-
-		mbx->ops.process(hw, mbx);
-	}
-
-	if (i >= 0) {
-		iov_data->next_vf_mbx = i + 1;
-	} else if (iov_data->next_vf_mbx) {
-		iov_data->next_vf_mbx = 0;
-		goto process_mbx;
-	}
 read_unlock:
 	rcu_read_unlock();
 
@@ -155,10 +129,6 @@ process_mbx:
 			mbx->ops.connect(hw, mbx);
 		}
 
-		/* no work pending, then just continue */
-		if (mbx->ops.tx_complete(mbx) && !mbx->ops.rx_ready(mbx))
-			continue;
-
 		/* guarantee we have free space in the SM mailbox */
 		if (!hw->mbx.ops.tx_ready(&hw->mbx, FM10K_VFMBX_MSG_MTU))
 			break;
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
index 514f35c..32e99eb 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
@@ -1006,6 +1006,7 @@ static irqreturn_t fm10k_msix_mbx_pf(int __always_unused irq, void *data)
 	/* service mailboxes */
 	if (fm10k_mbx_trylock(interface)) {
 		mbx->ops.process(hw, mbx);
+		/* handle VFLRE events */
 		fm10k_iov_event(interface);
 		fm10k_mbx_unlock(interface);
 	}
@@ -1022,6 +1023,8 @@ static irqreturn_t fm10k_msix_mbx_pf(int __always_unused irq, void *data)
 
 	/* we should validate host state after interrupt event */
 	hw->mac.get_host_state = 1;
+
+	/* validate host state, and handle VF mailboxes in the service task */
 	fm10k_service_event_schedule(interface);
 
 	/* re-enable mailbox interrupt and indicate 20us delay */
-- 
1.9.3

  parent reply	other threads:[~2015-04-14 23:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-14 23:50 [net-next 00/25][pull request] Intel Wired LAN Driver Updates 2015-04-14 Jeff Kirsher
2015-04-14 23:50 ` [net-next 01/25] fm10k: Corrected an error in Tx statistics Jeff Kirsher
2015-04-14 23:50 ` [net-next 02/25] fm10k: Remove redundant rx_errors in ethtool Jeff Kirsher
2015-04-14 23:50 ` [net-next 03/25] fm10k: Correct spelling mistake Jeff Kirsher
2015-04-14 23:50 ` [net-next 04/25] fm10k: Have the VF get the default VLAN during init Jeff Kirsher
2015-04-14 23:50 ` [net-next 05/25] fm10k: Add netconsole support Jeff Kirsher
2015-04-14 23:50 ` [net-next 06/25] fm10k: fix unused warnings Jeff Kirsher
2015-04-14 23:50 ` [net-next 07/25] fm10k: allow creation of VLAN on default vid Jeff Kirsher
2015-04-14 23:50 ` [net-next 08/25] fm10k: only show actual queues, not the maximum in hardware Jeff Kirsher
2015-04-14 23:50 ` [net-next 09/25] fm10k: use hw->mac.max_queues for stats Jeff Kirsher
2015-04-14 23:50 ` [net-next 10/25] fm10k: separate PF only stats so that VF does not display them Jeff Kirsher
2015-04-14 23:50 ` [net-next 11/25] fm10k: remove extraneous "Reset interface" message Jeff Kirsher
2015-04-14 23:50 ` [net-next 12/25] fm10k: only increment tx_timeout_count in Tx hang path Jeff Kirsher
2015-04-14 23:50 ` [net-next 13/25] fm10k: expose tx_timeout_count as an ethtool stat Jeff Kirsher
2015-04-14 23:51 ` [net-next 14/25] fm10k: Set PF queues to unlimited bandwidth during virtualization Jeff Kirsher
2015-04-14 23:51 ` [net-next 15/25] fm10k: use separate workqueue for fm10k driver Jeff Kirsher
2015-04-14 23:51 ` Jeff Kirsher [this message]
2015-04-14 23:51 ` [net-next 17/25] fm10k: comment next_vf_mbx flow Jeff Kirsher
2015-04-14 23:51 ` [net-next 18/25] fm10k: fix function header comment Jeff Kirsher
2015-04-14 23:51 ` [net-next 19/25] fm10k: start service timer on probe Jeff Kirsher
2015-04-14 23:51 ` [net-next 20/25] fm10k: update xcast mode before synchronizing multicast addresses Jeff Kirsher
2015-04-14 23:51 ` [net-next 21/25] fm10k: renamed mbx_tx_dropped to mbx_tx_oversized Jeff Kirsher
2015-04-14 23:51 ` [net-next 22/25] fm10k: reset head instead of calling update_max_size Jeff Kirsher
2015-04-14 23:51 ` [net-next 23/25] fm10k: mbx_update_max_size does not drop all oversized messages Jeff Kirsher
2015-04-14 23:51 ` [net-next 24/25] fm10k: corrected VF multicast update Jeff Kirsher
2015-04-14 23:51 ` [net-next 25/25] fm10k: Bump driver version to 0.15.2 Jeff Kirsher
2015-04-15  2:38 ` [net-next 00/25][pull request] Intel Wired LAN Driver Updates 2015-04-14 David Miller

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=1429055471-401-17-git-send-email-jeffrey.t.kirsher@intel.com \
    --to=jeffrey.t.kirsher@intel.com \
    --cc=davem@davemloft.net \
    --cc=jacob.e.keller@intel.com \
    --cc=jogreene@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=sassmann@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).