From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: davem@davemloft.net
Cc: Lukasz Czapnik <lukasz.czapnik@intel.com>,
netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Andrew Bowers <andrewx.bowers@intel.com>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Subject: [net-next 09/16] ice: report link down for VF when PF's queues are not enabled
Date: Thu, 5 Sep 2019 13:33:59 -0700 [thread overview]
Message-ID: <20190905203406.4152-10-jeffrey.t.kirsher@intel.com> (raw)
In-Reply-To: <20190905203406.4152-1-jeffrey.t.kirsher@intel.com>
From: Lukasz Czapnik <lukasz.czapnik@intel.com>
This is port of a fix from i40e commit 2ad1274fa35a ("i40e: don't
report link up for a VF who hasn't enabled queues")
Older VF drivers do not respond well to receiving a link
up notification before queues are enabled. This can cause their state
machine to think that it is safe to send traffic. This results in a Tx
hang on the VF.
Record whether the PF has actually enabled queues for the VF. When
reporting link status, always report link down if the queues aren't
enabled. In this way, the VF driver will never receive a link up
notification until after its queues are enabled.
Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
index 3ba6613048ef..1ec2a037a369 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
@@ -129,7 +129,10 @@ static void ice_vc_notify_vf_link_state(struct ice_vf *vf)
pfe.event = VIRTCHNL_EVENT_LINK_CHANGE;
pfe.severity = PF_EVENT_SEVERITY_INFO;
- if (vf->link_forced)
+ /* Always report link is down if the VF queues aren't enabled */
+ if (!vf->num_qs_ena)
+ ice_set_pfe_link(vf, &pfe, ICE_AQ_LINK_SPEED_UNKNOWN, false);
+ else if (vf->link_forced)
ice_set_pfe_link_forced(vf, &pfe, vf->link_up);
else
ice_set_pfe_link(vf, &pfe, ls->link_speed, ls->link_info &
--
2.21.0
next prev parent reply other threads:[~2019-09-05 20:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 20:33 [net-next 00/16][pull request] 100GbE Intel Wired LAN Driver Updates 2019-09-05 Jeff Kirsher
2019-09-05 20:33 ` [net-next 01/16] ice: Update fields in ice_vsi_set_num_qs when reconfiguring Jeff Kirsher
2019-09-05 20:33 ` [net-next 02/16] ice: Add ice_get_main_vsi to get PF/main VSI Jeff Kirsher
2019-09-05 20:33 ` [net-next 03/16] ice: Check root pointer for validity Jeff Kirsher
2019-09-05 20:33 ` [net-next 04/16] ice: clean up arguments Jeff Kirsher
2019-09-05 20:33 ` [net-next 05/16] ice: move code closer together Jeff Kirsher
2019-09-05 20:33 ` [net-next 06/16] ice: small efficiency fixes Jeff Kirsher
2019-09-05 20:33 ` [net-next 07/16] ice: change work limit to a constant Jeff Kirsher
2019-09-05 20:33 ` [net-next 08/16] ice: Reliably reset VFs Jeff Kirsher
2019-09-05 20:33 ` Jeff Kirsher [this message]
2019-09-05 20:34 ` [net-next 10/16] ice: Check for DCB capability before initializing DCB Jeff Kirsher
2019-09-05 20:34 ` [net-next 11/16] ice: Report VF link status with opcode to get resources Jeff Kirsher
2019-09-05 20:34 ` [net-next 12/16] ice: update Tx context struct Jeff Kirsher
2019-09-05 20:34 ` [net-next 13/16] ice: Allow for delayed LLDP MIB change registration Jeff Kirsher
2019-09-05 20:34 ` [net-next 14/16] ice: Minor refactor in queue management Jeff Kirsher
2019-09-05 20:34 ` [net-next 15/16] ice: change default number of receive descriptors Jeff Kirsher
2019-09-05 20:34 ` [net-next 16/16] ice: Rework around device/function capabilities Jeff Kirsher
2019-09-07 13:27 ` [net-next 00/16][pull request] 100GbE Intel Wired LAN Driver Updates 2019-09-05 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=20190905203406.4152-10-jeffrey.t.kirsher@intel.com \
--to=jeffrey.t.kirsher@intel.com \
--cc=andrewx.bowers@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=lukasz.czapnik@intel.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