* [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26
@ 2021-01-26 22:10 Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 1/7] ice: fix FDir IPv6 flexbyte Tony Nguyen
` (8 more replies)
0 siblings, 9 replies; 12+ messages in thread
From: Tony Nguyen @ 2021-01-26 22:10 UTC (permalink / raw)
To: davem, kuba; +Cc: Tony Nguyen, netdev, sassmann
This series contains updates to the ice, i40e, and igc driver.
Henry corrects setting an unspecified protocol to IPPROTO_NONE instead of
0 for IPv6 flexbytes filters for ice.
Nick fixes the IPv6 extension header being processed incorrectly and
updates the netdev->dev_addr if it exists in hardware as it may have been
modified outside the ice driver.
Brett ensures a user cannot request more channels than available LAN MSI-X
and fixes the minimum allocation logic as it was incorrectly trying to use
more MSI-X than allocated for ice.
Stefan Assmann minimizes the delay between getting and using the VSI
pointer to prevent a possible crash for i40e.
Corinna Vinschen fixes link speed advertising for igc.
v2: Dropped patch 4 (ice XDP). Added igc link speed advertisement patch
(patch 7).
The following are changes since commit 07d46d93c9acdfe0614071d73c415dd5f745cc6e:
uapi: fix big endian definition of ipv6_rpl_sr_hdr
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue 100GbE
Brett Creeley (2):
ice: Don't allow more channels than LAN MSI-X available
ice: Fix MSI-X vector fallback logic
Corinna Vinschen (1):
igc: fix link speed advertising
Henry Tieman (1):
ice: fix FDir IPv6 flexbyte
Nick Nunley (2):
ice: Implement flow for IPv6 next header (extension header)
ice: update dev_addr in ice_set_mac_address even if HW filter exists
Stefan Assmann (1):
i40e: acquire VSI pointer only after VF is initialized
.../ethernet/intel/i40e/i40e_virtchnl_pf.c | 11 ++++-----
drivers/net/ethernet/intel/ice/ice.h | 4 +++-
drivers/net/ethernet/intel/ice/ice_ethtool.c | 8 +++----
.../net/ethernet/intel/ice/ice_ethtool_fdir.c | 8 ++++++-
drivers/net/ethernet/intel/ice/ice_lib.c | 14 +++++++----
drivers/net/ethernet/intel/ice/ice_main.c | 16 +++++++------
drivers/net/ethernet/intel/ice/ice_txrx.c | 9 ++++---
drivers/net/ethernet/intel/igc/igc_ethtool.c | 24 ++++++++++++++-----
8 files changed, 60 insertions(+), 34 deletions(-)
--
2.26.2
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH net v2 1/7] ice: fix FDir IPv6 flexbyte
2021-01-26 22:10 [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Tony Nguyen
@ 2021-01-26 22:10 ` Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 2/7] ice: Implement flow for IPv6 next header (extension header) Tony Nguyen
` (7 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Tony Nguyen @ 2021-01-26 22:10 UTC (permalink / raw)
To: davem, kuba
Cc: Henry Tieman, netdev, sassmann, anthony.l.nguyen, Paul Menzel,
Tony Brelinski
From: Henry Tieman <henry.w.tieman@intel.com>
The packet classifier would occasionally misrecognize an IPv6 training
packet when the next protocol field was 0. The correct value for
unspecified protocol is IPPROTO_NONE.
Fixes: 165d80d6adab ("ice: Support IPv6 Flow Director filters")
Signed-off-by: Henry Tieman <henry.w.tieman@intel.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c b/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
index 2d27f66ac853..192729546bbf 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
@@ -1576,7 +1576,13 @@ ice_set_fdir_input_set(struct ice_vsi *vsi, struct ethtool_rx_flow_spec *fsp,
sizeof(struct in6_addr));
input->ip.v6.l4_header = fsp->h_u.usr_ip6_spec.l4_4_bytes;
input->ip.v6.tc = fsp->h_u.usr_ip6_spec.tclass;
- input->ip.v6.proto = fsp->h_u.usr_ip6_spec.l4_proto;
+
+ /* if no protocol requested, use IPPROTO_NONE */
+ if (!fsp->m_u.usr_ip6_spec.l4_proto)
+ input->ip.v6.proto = IPPROTO_NONE;
+ else
+ input->ip.v6.proto = fsp->h_u.usr_ip6_spec.l4_proto;
+
memcpy(input->mask.v6.dst_ip, fsp->m_u.usr_ip6_spec.ip6dst,
sizeof(struct in6_addr));
memcpy(input->mask.v6.src_ip, fsp->m_u.usr_ip6_spec.ip6src,
--
2.26.2
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH net v2 2/7] ice: Implement flow for IPv6 next header (extension header)
2021-01-26 22:10 [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 1/7] ice: fix FDir IPv6 flexbyte Tony Nguyen
@ 2021-01-26 22:10 ` Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 3/7] ice: update dev_addr in ice_set_mac_address even if HW filter exists Tony Nguyen
` (6 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Tony Nguyen @ 2021-01-26 22:10 UTC (permalink / raw)
To: davem, kuba
Cc: Nick Nunley, netdev, sassmann, anthony.l.nguyen, Tony Brelinski
From: Nick Nunley <nicholas.d.nunley@intel.com>
This patch is based on a similar change to i40e by Slawomir Laba:
"i40e: Implement flow for IPv6 next header (extension header)".
When a packet contains an IPv6 header with next header which is
an extension header and not a protocol one, the kernel function
skb_transport_header called with such sk_buff will return a
pointer to the extension header and not to the TCP one.
The above explained call caused a problem with packet processing
for skb with encapsulation for tunnel with ICE_TX_CTX_EIPT_IPV6.
The extension header was not skipped at all.
The ipv6_skip_exthdr function does check if next header of the IPV6
header is an extension header and doesn't modify the l4_proto pointer
if it points to a protocol header value so its safe to omit the
comparison of exthdr and l4.hdr pointers. The ipv6_skip_exthdr can
return value -1. This means that the skipping process failed
and there is something wrong with the packet so it will be dropped.
Fixes: a4e82a81f573 ("ice: Add support for tunnel offloads")
Signed-off-by: Nick Nunley <nicholas.d.nunley@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/ice/ice_txrx.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c
index a2d0aad8cfdd..b6fa83c619dd 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c
@@ -1923,12 +1923,15 @@ int ice_tx_csum(struct ice_tx_buf *first, struct ice_tx_offload_params *off)
ICE_TX_CTX_EIPT_IPV4_NO_CSUM;
l4_proto = ip.v4->protocol;
} else if (first->tx_flags & ICE_TX_FLAGS_IPV6) {
+ int ret;
+
tunnel |= ICE_TX_CTX_EIPT_IPV6;
exthdr = ip.hdr + sizeof(*ip.v6);
l4_proto = ip.v6->nexthdr;
- if (l4.hdr != exthdr)
- ipv6_skip_exthdr(skb, exthdr - skb->data,
- &l4_proto, &frag_off);
+ ret = ipv6_skip_exthdr(skb, exthdr - skb->data,
+ &l4_proto, &frag_off);
+ if (ret < 0)
+ return -1;
}
/* define outer transport */
--
2.26.2
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH net v2 3/7] ice: update dev_addr in ice_set_mac_address even if HW filter exists
2021-01-26 22:10 [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 1/7] ice: fix FDir IPv6 flexbyte Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 2/7] ice: Implement flow for IPv6 next header (extension header) Tony Nguyen
@ 2021-01-26 22:10 ` Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 4/7] ice: Don't allow more channels than LAN MSI-X available Tony Nguyen
` (5 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Tony Nguyen @ 2021-01-26 22:10 UTC (permalink / raw)
To: davem, kuba
Cc: Nick Nunley, netdev, sassmann, anthony.l.nguyen, Tony Brelinski
From: Nick Nunley <nicholas.d.nunley@intel.com>
Fix the driver to copy the MAC address configured in ndo_set_mac_address
into dev_addr, even if the MAC filter already exists in HW. In some
situations (e.g. bonding) the netdev's dev_addr could have been modified
outside of the driver, with no change to the HW filter, so the driver
cannot assume that they match.
Fixes: 757976ab16be ("ice: Fix check for removing/adding mac filters")
Signed-off-by: Nick Nunley <nicholas.d.nunley@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/ice/ice_main.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index c52b9bb0e3ab..fb81aa5979e3 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -4884,9 +4884,15 @@ static int ice_set_mac_address(struct net_device *netdev, void *pi)
goto err_update_filters;
}
- /* Add filter for new MAC. If filter exists, just return success */
+ /* Add filter for new MAC. If filter exists, return success */
status = ice_fltr_add_mac(vsi, mac, ICE_FWD_TO_VSI);
if (status == ICE_ERR_ALREADY_EXISTS) {
+ /* Although this MAC filter is already present in hardware it's
+ * possible in some cases (e.g. bonding) that dev_addr was
+ * modified outside of the driver and needs to be restored back
+ * to this value.
+ */
+ memcpy(netdev->dev_addr, mac, netdev->addr_len);
netdev_dbg(netdev, "filter for MAC %pM already exists\n", mac);
return 0;
}
--
2.26.2
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH net v2 4/7] ice: Don't allow more channels than LAN MSI-X available
2021-01-26 22:10 [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Tony Nguyen
` (2 preceding siblings ...)
2021-01-26 22:10 ` [PATCH net v2 3/7] ice: update dev_addr in ice_set_mac_address even if HW filter exists Tony Nguyen
@ 2021-01-26 22:10 ` Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 5/7] ice: Fix MSI-X vector fallback logic Tony Nguyen
` (4 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Tony Nguyen @ 2021-01-26 22:10 UTC (permalink / raw)
To: davem, kuba
Cc: Brett Creeley, netdev, sassmann, anthony.l.nguyen, Tony Brelinski
From: Brett Creeley <brett.creeley@intel.com>
Currently users could create more channels than LAN MSI-X available.
This is happening because there is no check against pf->num_lan_msix
when checking the max allowed channels and will cause performance issues
if multiple Tx and Rx queues are tied to a single MSI-X. Fix this by not
allowing more channels than LAN MSI-X available in pf->num_lan_msix.
Fixes: 87324e747fde ("ice: Implement ethtool ops for channels")
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/ice/ice_ethtool.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
index 9e8e9531cd87..69c113a4de7e 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -3258,8 +3258,8 @@ ice_set_rxfh(struct net_device *netdev, const u32 *indir, const u8 *key,
*/
static int ice_get_max_txq(struct ice_pf *pf)
{
- return min_t(int, num_online_cpus(),
- pf->hw.func_caps.common_cap.num_txq);
+ return min3(pf->num_lan_msix, (u16)num_online_cpus(),
+ (u16)pf->hw.func_caps.common_cap.num_txq);
}
/**
@@ -3268,8 +3268,8 @@ static int ice_get_max_txq(struct ice_pf *pf)
*/
static int ice_get_max_rxq(struct ice_pf *pf)
{
- return min_t(int, num_online_cpus(),
- pf->hw.func_caps.common_cap.num_rxq);
+ return min3(pf->num_lan_msix, (u16)num_online_cpus(),
+ (u16)pf->hw.func_caps.common_cap.num_rxq);
}
/**
--
2.26.2
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH net v2 5/7] ice: Fix MSI-X vector fallback logic
2021-01-26 22:10 [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Tony Nguyen
` (3 preceding siblings ...)
2021-01-26 22:10 ` [PATCH net v2 4/7] ice: Don't allow more channels than LAN MSI-X available Tony Nguyen
@ 2021-01-26 22:10 ` Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 6/7] i40e: acquire VSI pointer only after VF is initialized Tony Nguyen
` (3 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Tony Nguyen @ 2021-01-26 22:10 UTC (permalink / raw)
To: davem, kuba
Cc: Brett Creeley, netdev, sassmann, anthony.l.nguyen, Tony Brelinski
From: Brett Creeley <brett.creeley@intel.com>
The current MSI-X enablement logic tries to enable best-case MSI-X
vectors and if that fails we only support a bare-minimum set. This
includes a single MSI-X for 1 Tx and 1 Rx queue and a single MSI-X
for the OICR interrupt. Unfortunately, the driver fails to load when we
don't get as many MSI-X as requested for a couple reasons.
First, the code to allocate MSI-X in the driver tries to allocate
num_online_cpus() MSI-X for LAN traffic without caring about the number
of MSI-X actually enabled/requested from the kernel for LAN traffic.
So, when calling ice_get_res() for the PF VSI, it returns failure
because the number of available vectors is less than requested. Fix
this by not allowing the PF VSI to allocation more than
pf->num_lan_msix MSI-X vectors and pf->num_lan_msix Rx/Tx queues.
Limiting the number of queues is done because we don't want more than
1 Tx/Rx queue per interrupt due to performance conerns.
Second, the driver assigns pf->num_lan_msix = 2, to account for LAN
traffic and the OICR. However, pf->num_lan_msix is only meant for LAN
MSI-X. This is causing a failure when the PF VSI tries to
allocate/reserve the minimum pf->num_lan_msix because the OICR MSI-X has
already been reserved, so there may not be enough MSI-X vectors left.
Fix this by setting pf->num_lan_msix = 1 for the failure case. Then the
ICE_MIN_MSIX accounts for the LAN MSI-X and the OICR MSI-X needed for
the failure case.
Update the related defines used in ice_ena_msix_range() to align with
the above behavior and remove the unused RDMA defines because RDMA is
currently not supported. Also, remove the now incorrect comment.
Fixes: 152b978a1f90 ("ice: Rework ice_ena_msix_range")
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/ice/ice.h | 4 +++-
drivers/net/ethernet/intel/ice/ice_lib.c | 14 +++++++++-----
drivers/net/ethernet/intel/ice/ice_main.c | 8 ++------
3 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
index 56725356a17b..fa1e128c24ec 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -68,7 +68,9 @@
#define ICE_INT_NAME_STR_LEN (IFNAMSIZ + 16)
#define ICE_AQ_LEN 64
#define ICE_MBXSQ_LEN 64
-#define ICE_MIN_MSIX 2
+#define ICE_MIN_LAN_TXRX_MSIX 1
+#define ICE_MIN_LAN_OICR_MSIX 1
+#define ICE_MIN_MSIX (ICE_MIN_LAN_TXRX_MSIX + ICE_MIN_LAN_OICR_MSIX)
#define ICE_FDIR_MSIX 1
#define ICE_NO_VSI 0xffff
#define ICE_VSI_MAP_CONTIG 0
diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
index 3df67486d42d..ad9c22a1b97a 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -161,8 +161,9 @@ static void ice_vsi_set_num_qs(struct ice_vsi *vsi, u16 vf_id)
switch (vsi->type) {
case ICE_VSI_PF:
- vsi->alloc_txq = min_t(int, ice_get_avail_txq_count(pf),
- num_online_cpus());
+ vsi->alloc_txq = min3(pf->num_lan_msix,
+ ice_get_avail_txq_count(pf),
+ (u16)num_online_cpus());
if (vsi->req_txq) {
vsi->alloc_txq = vsi->req_txq;
vsi->num_txq = vsi->req_txq;
@@ -174,8 +175,9 @@ static void ice_vsi_set_num_qs(struct ice_vsi *vsi, u16 vf_id)
if (!test_bit(ICE_FLAG_RSS_ENA, pf->flags)) {
vsi->alloc_rxq = 1;
} else {
- vsi->alloc_rxq = min_t(int, ice_get_avail_rxq_count(pf),
- num_online_cpus());
+ vsi->alloc_rxq = min3(pf->num_lan_msix,
+ ice_get_avail_rxq_count(pf),
+ (u16)num_online_cpus());
if (vsi->req_rxq) {
vsi->alloc_rxq = vsi->req_rxq;
vsi->num_rxq = vsi->req_rxq;
@@ -184,7 +186,9 @@ static void ice_vsi_set_num_qs(struct ice_vsi *vsi, u16 vf_id)
pf->num_lan_rx = vsi->alloc_rxq;
- vsi->num_q_vectors = max_t(int, vsi->alloc_rxq, vsi->alloc_txq);
+ vsi->num_q_vectors = min_t(int, pf->num_lan_msix,
+ max_t(int, vsi->alloc_rxq,
+ vsi->alloc_txq));
break;
case ICE_VSI_VF:
vf = &pf->vf[vsi->vf_id];
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index fb81aa5979e3..e10ca8929f85 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3430,18 +3430,14 @@ static int ice_ena_msix_range(struct ice_pf *pf)
if (v_actual < v_budget) {
dev_warn(dev, "not enough OS MSI-X vectors. requested = %d, obtained = %d\n",
v_budget, v_actual);
-/* 2 vectors each for LAN and RDMA (traffic + OICR), one for flow director */
-#define ICE_MIN_LAN_VECS 2
-#define ICE_MIN_RDMA_VECS 2
-#define ICE_MIN_VECS (ICE_MIN_LAN_VECS + ICE_MIN_RDMA_VECS + 1)
- if (v_actual < ICE_MIN_LAN_VECS) {
+ if (v_actual < ICE_MIN_MSIX) {
/* error if we can't get minimum vectors */
pci_disable_msix(pf->pdev);
err = -ERANGE;
goto msix_err;
} else {
- pf->num_lan_msix = ICE_MIN_LAN_VECS;
+ pf->num_lan_msix = ICE_MIN_LAN_TXRX_MSIX;
}
}
--
2.26.2
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH net v2 6/7] i40e: acquire VSI pointer only after VF is initialized
2021-01-26 22:10 [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Tony Nguyen
` (4 preceding siblings ...)
2021-01-26 22:10 ` [PATCH net v2 5/7] ice: Fix MSI-X vector fallback logic Tony Nguyen
@ 2021-01-26 22:10 ` Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 7/7] igc: fix link speed advertising Tony Nguyen
` (2 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Tony Nguyen @ 2021-01-26 22:10 UTC (permalink / raw)
To: davem, kuba
Cc: Stefan Assmann, netdev, sassmann, anthony.l.nguyen, Jacob Keller,
Konrad Jankowski
From: Stefan Assmann <sassmann@kpanic.de>
This change simplifies the VF initialization check and also minimizes
the delay between acquiring the VSI pointer and using it. As known by
the commit being fixed, there is a risk of the VSI pointer getting
changed. Therefore minimize the delay between getting and using the
pointer.
Fixes: 9889707b06ac ("i40e: Fix crash caused by stress setting of VF MAC addresses")
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 21ee56420c3a..7efc61aacb0a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -4046,20 +4046,16 @@ int i40e_ndo_set_vf_mac(struct net_device *netdev, int vf_id, u8 *mac)
goto error_param;
vf = &pf->vf[vf_id];
- vsi = pf->vsi[vf->lan_vsi_idx];
/* When the VF is resetting wait until it is done.
* It can take up to 200 milliseconds,
* but wait for up to 300 milliseconds to be safe.
- * If the VF is indeed in reset, the vsi pointer has
- * to show on the newly loaded vsi under pf->vsi[id].
+ * Acquire the VSI pointer only after the VF has been
+ * properly initialized.
*/
for (i = 0; i < 15; i++) {
- if (test_bit(I40E_VF_STATE_INIT, &vf->vf_states)) {
- if (i > 0)
- vsi = pf->vsi[vf->lan_vsi_idx];
+ if (test_bit(I40E_VF_STATE_INIT, &vf->vf_states))
break;
- }
msleep(20);
}
if (!test_bit(I40E_VF_STATE_INIT, &vf->vf_states)) {
@@ -4068,6 +4064,7 @@ int i40e_ndo_set_vf_mac(struct net_device *netdev, int vf_id, u8 *mac)
ret = -EAGAIN;
goto error_param;
}
+ vsi = pf->vsi[vf->lan_vsi_idx];
if (is_multicast_ether_addr(mac)) {
dev_err(&pf->pdev->dev,
--
2.26.2
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH net v2 7/7] igc: fix link speed advertising
2021-01-26 22:10 [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Tony Nguyen
` (5 preceding siblings ...)
2021-01-26 22:10 ` [PATCH net v2 6/7] i40e: acquire VSI pointer only after VF is initialized Tony Nguyen
@ 2021-01-26 22:10 ` Tony Nguyen
2021-01-27 7:04 ` Heiner Kallweit
2021-01-27 18:25 ` [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Willem de Bruijn
2021-01-28 1:50 ` patchwork-bot+netdevbpf
8 siblings, 1 reply; 12+ messages in thread
From: Tony Nguyen @ 2021-01-26 22:10 UTC (permalink / raw)
To: davem, kuba; +Cc: Corinna Vinschen, netdev, sassmann, anthony.l.nguyen
From: Corinna Vinschen <vinschen@redhat.com>
Link speed advertising in igc has two problems:
- When setting the advertisement via ethtool, the link speed is converted
to the legacy 32 bit representation for the intel PHY code.
This inadvertently drops ETHTOOL_LINK_MODE_2500baseT_Full_BIT (being
beyond bit 31). As a result, any call to `ethtool -s ...' drops the
2500Mbit/s link speed from the PHY settings. Only reloading the driver
alleviates that problem.
Fix this by converting the ETHTOOL_LINK_MODE_2500baseT_Full_BIT to the
Intel PHY ADVERTISE_2500_FULL bit explicitly.
- Rather than checking the actual PHY setting, the .get_link_ksettings
function always fills link_modes.advertising with all link speeds
the device is capable of.
Fix this by checking the PHY autoneg_advertised settings and report
only the actually advertised speeds up to ethtool.
Fixes: 8c5ad0dae93c ("igc: Add ethtool support")
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/igc/igc_ethtool.c | 24 +++++++++++++++-----
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_ethtool.c b/drivers/net/ethernet/intel/igc/igc_ethtool.c
index 61d331ce38cd..831f2f09de5f 100644
--- a/drivers/net/ethernet/intel/igc/igc_ethtool.c
+++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c
@@ -1675,12 +1675,18 @@ static int igc_ethtool_get_link_ksettings(struct net_device *netdev,
cmd->base.phy_address = hw->phy.addr;
/* advertising link modes */
- ethtool_link_ksettings_add_link_mode(cmd, advertising, 10baseT_Half);
- ethtool_link_ksettings_add_link_mode(cmd, advertising, 10baseT_Full);
- ethtool_link_ksettings_add_link_mode(cmd, advertising, 100baseT_Half);
- ethtool_link_ksettings_add_link_mode(cmd, advertising, 100baseT_Full);
- ethtool_link_ksettings_add_link_mode(cmd, advertising, 1000baseT_Full);
- ethtool_link_ksettings_add_link_mode(cmd, advertising, 2500baseT_Full);
+ if (hw->phy.autoneg_advertised & ADVERTISE_10_HALF)
+ ethtool_link_ksettings_add_link_mode(cmd, advertising, 10baseT_Half);
+ if (hw->phy.autoneg_advertised & ADVERTISE_10_FULL)
+ ethtool_link_ksettings_add_link_mode(cmd, advertising, 10baseT_Full);
+ if (hw->phy.autoneg_advertised & ADVERTISE_100_HALF)
+ ethtool_link_ksettings_add_link_mode(cmd, advertising, 100baseT_Half);
+ if (hw->phy.autoneg_advertised & ADVERTISE_100_FULL)
+ ethtool_link_ksettings_add_link_mode(cmd, advertising, 100baseT_Full);
+ if (hw->phy.autoneg_advertised & ADVERTISE_1000_FULL)
+ ethtool_link_ksettings_add_link_mode(cmd, advertising, 1000baseT_Full);
+ if (hw->phy.autoneg_advertised & ADVERTISE_2500_FULL)
+ ethtool_link_ksettings_add_link_mode(cmd, advertising, 2500baseT_Full);
/* set autoneg settings */
if (hw->mac.autoneg == 1) {
@@ -1792,6 +1798,12 @@ igc_ethtool_set_link_ksettings(struct net_device *netdev,
ethtool_convert_link_mode_to_legacy_u32(&advertising,
cmd->link_modes.advertising);
+ /* Converting to legacy u32 drops ETHTOOL_LINK_MODE_2500baseT_Full_BIT.
+ * We have to check this and convert it to ADVERTISE_2500_FULL
+ * (aka ETHTOOL_LINK_MODE_2500baseX_Full_BIT) explicitly.
+ */
+ if (ethtool_link_ksettings_test_link_mode(cmd, advertising, 2500baseT_Full))
+ advertising |= ADVERTISE_2500_FULL;
if (cmd->base.autoneg == AUTONEG_ENABLE) {
hw->mac.autoneg = 1;
--
2.26.2
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH net v2 7/7] igc: fix link speed advertising
2021-01-26 22:10 ` [PATCH net v2 7/7] igc: fix link speed advertising Tony Nguyen
@ 2021-01-27 7:04 ` Heiner Kallweit
2021-01-27 23:34 ` Nguyen, Anthony L
0 siblings, 1 reply; 12+ messages in thread
From: Heiner Kallweit @ 2021-01-27 7:04 UTC (permalink / raw)
To: Tony Nguyen, davem, kuba; +Cc: Corinna Vinschen, netdev, sassmann
On 26.01.2021 23:10, Tony Nguyen wrote:
> From: Corinna Vinschen <vinschen@redhat.com>
>
> Link speed advertising in igc has two problems:
>
> - When setting the advertisement via ethtool, the link speed is converted
> to the legacy 32 bit representation for the intel PHY code.
> This inadvertently drops ETHTOOL_LINK_MODE_2500baseT_Full_BIT (being
> beyond bit 31). As a result, any call to `ethtool -s ...' drops the
> 2500Mbit/s link speed from the PHY settings. Only reloading the driver
> alleviates that problem.
>
> Fix this by converting the ETHTOOL_LINK_MODE_2500baseT_Full_BIT to the
> Intel PHY ADVERTISE_2500_FULL bit explicitly.
>
> - Rather than checking the actual PHY setting, the .get_link_ksettings
> function always fills link_modes.advertising with all link speeds
> the device is capable of.
>
> Fix this by checking the PHY autoneg_advertised settings and report
> only the actually advertised speeds up to ethtool.
>
> Fixes: 8c5ad0dae93c ("igc: Add ethtool support")
> Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> drivers/net/ethernet/intel/igc/igc_ethtool.c | 24 +++++++++++++++-----
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
Would switching to phylib be a mid-term option for you?
This could save quite some code and you'd get things like proper 2.5Gbps
handling out of the box. Or is there anything that prevents using phylib?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26
2021-01-26 22:10 [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Tony Nguyen
` (6 preceding siblings ...)
2021-01-26 22:10 ` [PATCH net v2 7/7] igc: fix link speed advertising Tony Nguyen
@ 2021-01-27 18:25 ` Willem de Bruijn
2021-01-28 1:50 ` patchwork-bot+netdevbpf
8 siblings, 0 replies; 12+ messages in thread
From: Willem de Bruijn @ 2021-01-27 18:25 UTC (permalink / raw)
To: Tony Nguyen; +Cc: David Miller, Jakub Kicinski, Network Development, sassmann
On Wed, Jan 27, 2021 at 4:15 AM Tony Nguyen <anthony.l.nguyen@intel.com> wrote:
>
> This series contains updates to the ice, i40e, and igc driver.
>
> Henry corrects setting an unspecified protocol to IPPROTO_NONE instead of
> 0 for IPv6 flexbytes filters for ice.
>
> Nick fixes the IPv6 extension header being processed incorrectly and
> updates the netdev->dev_addr if it exists in hardware as it may have been
> modified outside the ice driver.
>
> Brett ensures a user cannot request more channels than available LAN MSI-X
> and fixes the minimum allocation logic as it was incorrectly trying to use
> more MSI-X than allocated for ice.
>
> Stefan Assmann minimizes the delay between getting and using the VSI
> pointer to prevent a possible crash for i40e.
>
> Corinna Vinschen fixes link speed advertising for igc.
>
> v2: Dropped patch 4 (ice XDP). Added igc link speed advertisement patch
> (patch 7).
>
> The following are changes since commit 07d46d93c9acdfe0614071d73c415dd5f745cc6e:
> uapi: fix big endian definition of ipv6_rpl_sr_hdr
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue 100GbE
>
> Brett Creeley (2):
> ice: Don't allow more channels than LAN MSI-X available
> ice: Fix MSI-X vector fallback logic
>
> Corinna Vinschen (1):
> igc: fix link speed advertising
>
> Henry Tieman (1):
> ice: fix FDir IPv6 flexbyte
>
> Nick Nunley (2):
> ice: Implement flow for IPv6 next header (extension header)
> ice: update dev_addr in ice_set_mac_address even if HW filter exists
>
> Stefan Assmann (1):
> i40e: acquire VSI pointer only after VF is initialized
>
> .../ethernet/intel/i40e/i40e_virtchnl_pf.c | 11 ++++-----
> drivers/net/ethernet/intel/ice/ice.h | 4 +++-
> drivers/net/ethernet/intel/ice/ice_ethtool.c | 8 +++----
> .../net/ethernet/intel/ice/ice_ethtool_fdir.c | 8 ++++++-
> drivers/net/ethernet/intel/ice/ice_lib.c | 14 +++++++----
> drivers/net/ethernet/intel/ice/ice_main.c | 16 +++++++------
> drivers/net/ethernet/intel/ice/ice_txrx.c | 9 ++++---
> drivers/net/ethernet/intel/igc/igc_ethtool.c | 24 ++++++++++++++-----
> 8 files changed, 60 insertions(+), 34 deletions(-)
>
> --
> 2.26.2
>
For netdrv
Acked-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net v2 7/7] igc: fix link speed advertising
2021-01-27 7:04 ` Heiner Kallweit
@ 2021-01-27 23:34 ` Nguyen, Anthony L
0 siblings, 0 replies; 12+ messages in thread
From: Nguyen, Anthony L @ 2021-01-27 23:34 UTC (permalink / raw)
To: hkallweit1, davem, kuba; +Cc: netdev, sassmann, vinschen
On Wed, 2021-01-27 at 08:04 +0100, Heiner Kallweit wrote:
> On 26.01.2021 23:10, Tony Nguyen wrote:
> > From: Corinna Vinschen <vinschen@redhat.com>
> >
> > Link speed advertising in igc has two problems:
> >
> > - When setting the advertisement via ethtool, the link speed is
> > converted
> > to the legacy 32 bit representation for the intel PHY code.
> > This inadvertently drops ETHTOOL_LINK_MODE_2500baseT_Full_BIT
> > (being
> > beyond bit 31). As a result, any call to `ethtool -s ...' drops
> > the
> > 2500Mbit/s link speed from the PHY settings. Only reloading the
> > driver
> > alleviates that problem.
> >
> > Fix this by converting the ETHTOOL_LINK_MODE_2500baseT_Full_BIT
> > to the
> > Intel PHY ADVERTISE_2500_FULL bit explicitly.
> >
> > - Rather than checking the actual PHY setting, the
> > .get_link_ksettings
> > function always fills link_modes.advertising with all link speeds
> > the device is capable of.
> >
> > Fix this by checking the PHY autoneg_advertised settings and
> > report
> > only the actually advertised speeds up to ethtool.
> >
> > Fixes: 8c5ad0dae93c ("igc: Add ethtool support")
> > Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
> > Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> > ---
> > drivers/net/ethernet/intel/igc/igc_ethtool.c | 24 +++++++++++++++-
> > ----
> > 1 file changed, 18 insertions(+), 6 deletions(-)
> >
>
> Would switching to phylib be a mid-term option for you?
> This could save quite some code and you'd get things like proper
> 2.5Gbps
> handling out of the box. Or is there anything that prevents using
> phylib?
Phylib is something we can look into though we have some device
specific quirks that we would need to see how it could be handled.
Since this is fixing a current problem and any transition to phylib
would not be immediate, I think this patch should be accepted while we
investigate phylib.
Thanks,
Tony
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26
2021-01-26 22:10 [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Tony Nguyen
` (7 preceding siblings ...)
2021-01-27 18:25 ` [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Willem de Bruijn
@ 2021-01-28 1:50 ` patchwork-bot+netdevbpf
8 siblings, 0 replies; 12+ messages in thread
From: patchwork-bot+netdevbpf @ 2021-01-28 1:50 UTC (permalink / raw)
To: Nguyen, Anthony L; +Cc: davem, kuba, netdev, sassmann
Hello:
This series was applied to netdev/net.git (refs/heads/master):
On Tue, 26 Jan 2021 14:10:28 -0800 you wrote:
> This series contains updates to the ice, i40e, and igc driver.
>
> Henry corrects setting an unspecified protocol to IPPROTO_NONE instead of
> 0 for IPv6 flexbytes filters for ice.
>
> Nick fixes the IPv6 extension header being processed incorrectly and
> updates the netdev->dev_addr if it exists in hardware as it may have been
> modified outside the ice driver.
>
> [...]
Here is the summary with links:
- [net,v2,1/7] ice: fix FDir IPv6 flexbyte
https://git.kernel.org/netdev/net/c/29e2d9eb8264
- [net,v2,2/7] ice: Implement flow for IPv6 next header (extension header)
https://git.kernel.org/netdev/net/c/1b0b0b581b94
- [net,v2,3/7] ice: update dev_addr in ice_set_mac_address even if HW filter exists
https://git.kernel.org/netdev/net/c/13ed5e8a9b9c
- [net,v2,4/7] ice: Don't allow more channels than LAN MSI-X available
https://git.kernel.org/netdev/net/c/943b881e3582
- [net,v2,5/7] ice: Fix MSI-X vector fallback logic
https://git.kernel.org/netdev/net/c/f3fe97f64384
- [net,v2,6/7] i40e: acquire VSI pointer only after VF is initialized
https://git.kernel.org/netdev/net/c/67a3c6b3cc40
- [net,v2,7/7] igc: fix link speed advertising
https://git.kernel.org/netdev/net/c/329a3678ec69
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-01-28 1:51 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-26 22:10 [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 1/7] ice: fix FDir IPv6 flexbyte Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 2/7] ice: Implement flow for IPv6 next header (extension header) Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 3/7] ice: update dev_addr in ice_set_mac_address even if HW filter exists Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 4/7] ice: Don't allow more channels than LAN MSI-X available Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 5/7] ice: Fix MSI-X vector fallback logic Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 6/7] i40e: acquire VSI pointer only after VF is initialized Tony Nguyen
2021-01-26 22:10 ` [PATCH net v2 7/7] igc: fix link speed advertising Tony Nguyen
2021-01-27 7:04 ` Heiner Kallweit
2021-01-27 23:34 ` Nguyen, Anthony L
2021-01-27 18:25 ` [PATCH net v2 0/7][pull request] Intel Wired LAN Driver Updates 2021-01-26 Willem de Bruijn
2021-01-28 1:50 ` patchwork-bot+netdevbpf
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.