From: Tony Nguyen <anthony.l.nguyen@intel.com> Date: 2021-01-27 08:20:19
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
From: Tony Nguyen <anthony.l.nguyen@intel.com> Date: 2021-01-26 23:17:37
From: Nick Nunley <redacted>
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 <redacted>
Tested-by: Tony Brelinski <redacted>
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(-)
From: Tony Nguyen <anthony.l.nguyen@intel.com> Date: 2021-01-26 23:17:37
From: Henry Tieman <redacted>
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 <redacted>
Reviewed-by: Paul Menzel <redacted>
Tested-by: Tony Brelinski <redacted>
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(-)
From: Tony Nguyen <anthony.l.nguyen@intel.com> Date: 2021-01-26 23:17:37
From: Brett Creeley <redacted>
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 <redacted>
Tested-by: Tony Brelinski <redacted>
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(-)
From: Tony Nguyen <anthony.l.nguyen@intel.com> Date: 2021-01-26 23:17:38
From: Nick Nunley <redacted>
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 <redacted>
Tested-by: Tony Brelinski <redacted>
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(-)
@@ -4884,9 +4884,15 @@ static int ice_set_mac_address(struct net_device *netdev, void *pi)gotoerr_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+*possibleinsomecases(e.g.bonding)thatdev_addrwas+*modifiedoutsideofthedriverandneedstoberestoredback+*tothisvalue.+*/+memcpy(netdev->dev_addr,mac,netdev->addr_len);netdev_dbg(netdev,"filter for MAC %pM already exists\n",mac);return0;}
From: Tony Nguyen <anthony.l.nguyen@intel.com> Date: 2021-01-26 23:17:39
From: Corinna Vinschen <redacted>
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 <redacted>
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(-)
From: Tony Nguyen <anthony.l.nguyen@intel.com> Date: 2021-01-26 23:17:39
From: Brett Creeley <redacted>
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 <redacted>
Tested-by: Tony Brelinski <redacted>
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(-)
@@ -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;gotomsix_err;}else{-pf->num_lan_msix=ICE_MIN_LAN_VECS;+pf->num_lan_msix=ICE_MIN_LAN_TXRX_MSIX;}}
From: Tony Nguyen <anthony.l.nguyen@intel.com> Date: 2021-01-26 23:19:02
From: Stefan Assmann <redacted>
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 <redacted>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Konrad Jankowski <redacted>
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(-)
@@ -4046,20 +4046,16 @@ int i40e_ndo_set_vf_mac(struct net_device *netdev, int vf_id, u8 *mac)gotoerror_param;vf=&pf->vf[vf_id];-vsi=pf->vsi[vf->lan_vsi_idx];/* When the VF is resetting wait until it is done.*Itcantakeupto200milliseconds,*butwaitforupto300millisecondstobesafe.-*IftheVFisindeedinreset,thevsipointerhas-*toshowonthenewlyloadedvsiunderpf->vsi[id].+*AcquiretheVSIpointeronlyaftertheVFhasbeen+*properlyinitialized.*/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;gotoerror_param;}+vsi=pf->vsi[vf->lan_vsi_idx];if(is_multicast_ether_addr(mac)){dev_err(&pf->pdev->dev,
From: Corinna Vinschen <redacted>
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 <redacted>
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?
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Date: 2021-01-27 18:26:51
On Wed, Jan 27, 2021 at 4:15 AM Tony Nguyen [off-list ref] 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>
From: "Nguyen, Anthony L" <anthony.l.nguyen@intel.com> Date: 2021-01-27 23:36:42
On Wed, 2021-01-27 at 08:04 +0100, Heiner Kallweit wrote:
On 26.01.2021 23:10, Tony Nguyen wrote:
quoted
From: Corinna Vinschen <redacted>
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 <redacted>
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
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.
[...]