[PATCH net 0/3][pull request] Intel Wired LAN Driver Updates 2023-03-14 (iavf)

[PATCH net 0/3][pull request] Intel Wired LAN Driver Updates 2023-03-14 (iavf)

[Tony Nguyen]

This series contains updates to iavf driver only.

Alex fixes incorrect check against Rx hash feature and corrects payload
value for IPv6 UDP packet.

Ahmed removes bookkeeping of VLAN 0 filter as it always exists and can
cause a false max filter error message.

The following are changes since commit 28e8cabe80f3e6e3c98121576eda898eeb20f1b1:
  net: hsr: Don't log netdev_err message on unknown prp dst node
and are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue 40GbE

Ahmed Zaki (1):
  iavf: do not track VLAN 0 filters

Alexander Lobakin (2):
  iavf: fix inverted Rx hash condition leading to disabled hash
  iavf: fix non-tunneled IPv6 UDP packet type and hashing

 drivers/net/ethernet/intel/iavf/iavf_common.c   | 2 +-
 drivers/net/ethernet/intel/iavf/iavf_main.c     | 4 ++++
 drivers/net/ethernet/intel/iavf/iavf_txrx.c     | 2 +-
 drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 2 --
 4 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.38.1

[PATCH net 1/3] iavf: fix inverted Rx hash condition leading to disabled hash

[Tony Nguyen]

From: Alexander Lobakin <aleksander.lobakin@intel.com>

Condition, which checks whether the netdev has hashing enabled is
inverted. Basically, the tagged commit effectively disabled passing flow
hash from descriptor to skb, unless user *disables* it via Ethtool.
Commit a876c3ba59a6 ("i40e/i40evf: properly report Rx packet hash")
fixed this problem, but only for i40e.
Invert the condition now in iavf and unblock passing hash to skbs again.

Fixes: 857942fd1aa1 ("i40e: Fix Rx hash reported to the stack by our driver")
Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/iavf/iavf_txrx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c b/drivers/net/ethernet/intel/iavf/iavf_txrx.c
index 18b6a702a1d6..e989feda133c 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c
@@ -1096,7 +1096,7 @@ static inline void iavf_rx_hash(struct iavf_ring *ring,
 		cpu_to_le64((u64)IAVF_RX_DESC_FLTSTAT_RSS_HASH <<
 			    IAVF_RX_DESC_STATUS_FLTSTAT_SHIFT);
 
-	if (ring->netdev->features & NETIF_F_RXHASH)
+	if (!(ring->netdev->features & NETIF_F_RXHASH))
 		return;
 
 	if ((rx_desc->wb.qword1.status_error_len & rss_mask) == rss_mask) {
-- 
2.38.1

[PATCH net 2/3] iavf: fix non-tunneled IPv6 UDP packet type and hashing

[Tony Nguyen]

From: Alexander Lobakin <aleksander.lobakin@intel.com>

Currently, IAVF's decode_rx_desc_ptype() correctly reports payload type
of L4 for IPv4 UDP packets and IPv{4,6} TCP, but only L3 for IPv6 UDP.
Originally, i40e, ice and iavf were affected.
Commit 73df8c9e3e3d ("i40e: Correct UDP packet header for non_tunnel-ipv6")
fixed that in i40e, then
commit 638a0c8c8861 ("ice: fix incorrect payload indicator on PTYPE")
fixed that for ice.
IPv6 UDP is L4 obviously. Fix it and make iavf report correct L4 hash
type for such packets, so that the stack won't calculate it on CPU when
needs it.

Fixes: 206812b5fccb ("i40e/i40evf: i40e implementation for skb_set_hash")
Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/iavf/iavf_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/iavf/iavf_common.c b/drivers/net/ethernet/intel/iavf/iavf_common.c
index 16c490965b61..dd11dbbd5551 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_common.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_common.c
@@ -661,7 +661,7 @@ struct iavf_rx_ptype_decoded iavf_ptype_lookup[BIT(8)] = {
 	/* Non Tunneled IPv6 */
 	IAVF_PTT(88, IP, IPV6, FRG, NONE, NONE, NOF, NONE, PAY3),
 	IAVF_PTT(89, IP, IPV6, NOF, NONE, NONE, NOF, NONE, PAY3),
-	IAVF_PTT(90, IP, IPV6, NOF, NONE, NONE, NOF, UDP,  PAY3),
+	IAVF_PTT(90, IP, IPV6, NOF, NONE, NONE, NOF, UDP,  PAY4),
 	IAVF_PTT_UNUSED_ENTRY(91),
 	IAVF_PTT(92, IP, IPV6, NOF, NONE, NONE, NOF, TCP,  PAY4),
 	IAVF_PTT(93, IP, IPV6, NOF, NONE, NONE, NOF, SCTP, PAY4),
-- 
2.38.1

[PATCH net 3/3] iavf: do not track VLAN 0 filters

[Tony Nguyen]

From: Ahmed Zaki <ahmed.zaki@intel.com>

When an interface with the maximum number of VLAN filters is brought up,
a spurious error is logged:

    [257.483082] 8021q: adding VLAN 0 to HW filter on device enp0s3
    [257.483094] iavf 0000:00:03.0 enp0s3: Max allowed VLAN filters 8. Remove existing VLANs or disable filtering via Ethtool if supported.

The VF driver complains that it cannot add the VLAN 0 filter.

On the other hand, the PF driver always adds VLAN 0 filter on VF
initialization. The VF does not need to ask the PF for that filter at
all.

Fix the error by not tracking VLAN 0 filters altogether. With that, the
check added by commit 0e710a3ffd0c ("iavf: Fix VF driver counting VLAN 0
filters") in iavf_virtchnl.c is useless and might be confusing if left as
it suggests that we track VLAN 0.

Fixes: 0e710a3ffd0c ("iavf: Fix VF driver counting VLAN 0 filters")
Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com>
Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
 drivers/net/ethernet/intel/iavf/iavf_main.c     | 4 ++++
 drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 2 --
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index 3273aeb8fa67..eb8f944276ff 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -893,6 +893,10 @@ static int iavf_vlan_rx_add_vid(struct net_device *netdev,
 {
 	struct iavf_adapter *adapter = netdev_priv(netdev);
 
+	/* Do not track VLAN 0 filter, always added by the PF on VF init */
+	if (!vid)
+		return 0;
+
 	if (!VLAN_FILTERING_ALLOWED(adapter))
 		return -EIO;
 
diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
index 6d23338604bb..4e17d006c52d 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
@@ -2446,8 +2446,6 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
 		list_for_each_entry(f, &adapter->vlan_filter_list, list) {
 			if (f->is_new_vlan) {
 				f->is_new_vlan = false;
-				if (!f->vlan.vid)
-					continue;
 				if (f->vlan.tpid == ETH_P_8021Q)
 					set_bit(f->vlan.vid,
 						adapter->vsi.active_cvlans);
-- 
2.38.1

Re: [PATCH net 3/3] iavf: do not track VLAN 0 filters

[Leon Romanovsky]

On Tue, Mar 14, 2023 at 10:44:23AM -0700, Tony Nguyen wrote:
> From: Ahmed Zaki <ahmed.zaki@intel.com>
> 
> When an interface with the maximum number of VLAN filters is brought up,
> a spurious error is logged:
> 
>     [257.483082] 8021q: adding VLAN 0 to HW filter on device enp0s3
>     [257.483094] iavf 0000:00:03.0 enp0s3: Max allowed VLAN filters 8. Remove existing VLANs or disable filtering via Ethtool if supported.
> 
> The VF driver complains that it cannot add the VLAN 0 filter.
> 
> On the other hand, the PF driver always adds VLAN 0 filter on VF
> initialization. The VF does not need to ask the PF for that filter at
> all.
> 
> Fix the error by not tracking VLAN 0 filters altogether. With that, the
> check added by commit 0e710a3ffd0c ("iavf: Fix VF driver counting VLAN 0
> filters") in iavf_virtchnl.c is useless and might be confusing if left as
> it suggests that we track VLAN 0.
> 
> Fixes: 0e710a3ffd0c ("iavf: Fix VF driver counting VLAN 0 filters")
> Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com>
> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
>  drivers/net/ethernet/intel/iavf/iavf_main.c     | 4 ++++
>  drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 2 --
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
> index 3273aeb8fa67..eb8f944276ff 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_main.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
> @@ -893,6 +893,10 @@ static int iavf_vlan_rx_add_vid(struct net_device *netdev,
>  {
>  	struct iavf_adapter *adapter = netdev_priv(netdev);
>  
> +	/* Do not track VLAN 0 filter, always added by the PF on VF init */
> +	if (!vid)
> +		return 0;

I would expect similar check in iavf_vlan_rx_kill_vid(),

Thanks

> +
>  	if (!VLAN_FILTERING_ALLOWED(adapter))
>  		return -EIO;
>  
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> index 6d23338604bb..4e17d006c52d 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> @@ -2446,8 +2446,6 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
>  		list_for_each_entry(f, &adapter->vlan_filter_list, list) {
>  			if (f->is_new_vlan) {
>  				f->is_new_vlan = false;
> -				if (!f->vlan.vid)
> -					continue;
>  				if (f->vlan.tpid == ETH_P_8021Q)
>  					set_bit(f->vlan.vid,
>  						adapter->vsi.active_cvlans);
> -- 
> 2.38.1
> 

Re: [PATCH net 1/3] iavf: fix inverted Rx hash condition leading to disabled hash

[Leon Romanovsky]

On Tue, Mar 14, 2023 at 10:44:21AM -0700, Tony Nguyen wrote:
> From: Alexander Lobakin <aleksander.lobakin@intel.com>
> 
> Condition, which checks whether the netdev has hashing enabled is
> inverted. Basically, the tagged commit effectively disabled passing flow
> hash from descriptor to skb, unless user *disables* it via Ethtool.
> Commit a876c3ba59a6 ("i40e/i40evf: properly report Rx packet hash")
> fixed this problem, but only for i40e.
> Invert the condition now in iavf and unblock passing hash to skbs again.
> 
> Fixes: 857942fd1aa1 ("i40e: Fix Rx hash reported to the stack by our driver")
> Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
>  drivers/net/ethernet/intel/iavf/iavf_txrx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Thanks,
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>

Re: [PATCH net 2/3] iavf: fix non-tunneled IPv6 UDP packet type and hashing

[Leon Romanovsky]

On Tue, Mar 14, 2023 at 10:44:22AM -0700, Tony Nguyen wrote:
> From: Alexander Lobakin <aleksander.lobakin@intel.com>
> 
> Currently, IAVF's decode_rx_desc_ptype() correctly reports payload type
> of L4 for IPv4 UDP packets and IPv{4,6} TCP, but only L3 for IPv6 UDP.
> Originally, i40e, ice and iavf were affected.
> Commit 73df8c9e3e3d ("i40e: Correct UDP packet header for non_tunnel-ipv6")
> fixed that in i40e, then
> commit 638a0c8c8861 ("ice: fix incorrect payload indicator on PTYPE")
> fixed that for ice.
> IPv6 UDP is L4 obviously. Fix it and make iavf report correct L4 hash
> type for such packets, so that the stack won't calculate it on CPU when
> needs it.
> 
> Fixes: 206812b5fccb ("i40e/i40evf: i40e implementation for skb_set_hash")
> Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
>  drivers/net/ethernet/intel/iavf/iavf_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Thanks,
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>

Re: [PATCH net 3/3] iavf: do not track VLAN 0 filters

[Ahmed Zaki]

On 2023-03-15 02:48, Leon Romanovsky wrote:
> On Tue, Mar 14, 2023 at 10:44:23AM -0700, Tony Nguyen wrote:
>> From: Ahmed Zaki <ahmed.zaki@intel.com>
>>
>> When an interface with the maximum number of VLAN filters is brought up,
>> a spurious error is logged:
>>
>>      [257.483082] 8021q: adding VLAN 0 to HW filter on device enp0s3
>>      [257.483094] iavf 0000:00:03.0 enp0s3: Max allowed VLAN filters 8. Remove existing VLANs or disable filtering via Ethtool if supported.
>>
>> The VF driver complains that it cannot add the VLAN 0 filter.
>>
>> On the other hand, the PF driver always adds VLAN 0 filter on VF
>> initialization. The VF does not need to ask the PF for that filter at
>> all.
>>
>> Fix the error by not tracking VLAN 0 filters altogether. With that, the
>> check added by commit 0e710a3ffd0c ("iavf: Fix VF driver counting VLAN 0
>> filters") in iavf_virtchnl.c is useless and might be confusing if left as
>> it suggests that we track VLAN 0.
>>
>> Fixes: 0e710a3ffd0c ("iavf: Fix VF driver counting VLAN 0 filters")
>> Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com>
>> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
>> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
>> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
>> ---
>>   drivers/net/ethernet/intel/iavf/iavf_main.c     | 4 ++++
>>   drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 2 --
>>   2 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
>> index 3273aeb8fa67..eb8f944276ff 100644
>> --- a/drivers/net/ethernet/intel/iavf/iavf_main.c
>> +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
>> @@ -893,6 +893,10 @@ static int iavf_vlan_rx_add_vid(struct net_device *netdev,
>>   {
>>   	struct iavf_adapter *adapter = netdev_priv(netdev);
>>   
>> +	/* Do not track VLAN 0 filter, always added by the PF on VF init */
>> +	if (!vid)
>> +		return 0;
> I would expect similar check in iavf_vlan_rx_kill_vid(),
>
> Thanks

Thanks for review. Next version will include the check in 
iavf_vlan_rx_kill_vid()

>
>> +
>>   	if (!VLAN_FILTERING_ALLOWED(adapter))
>>   		return -EIO;
>>   
>> diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
>> index 6d23338604bb..4e17d006c52d 100644
>> --- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
>> +++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
>> @@ -2446,8 +2446,6 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
>>   		list_for_each_entry(f, &adapter->vlan_filter_list, list) {
>>   			if (f->is_new_vlan) {
>>   				f->is_new_vlan = false;
>> -				if (!f->vlan.vid)
>> -					continue;
>>   				if (f->vlan.tpid == ETH_P_8021Q)
>>   					set_bit(f->vlan.vid,
>>   						adapter->vsi.active_cvlans);
>> -- 
>> 2.38.1
>>

Re: [PATCH net 3/3] iavf: do not track VLAN 0 filters

[Jakub Kicinski]

On Thu, 16 Mar 2023 07:15:32 -0600 Ahmed Zaki wrote:
> > I would expect similar check in iavf_vlan_rx_kill_vid(),
>
> Thanks for review. Next version will include the check in 
> iavf_vlan_rx_kill_vid()

FWIW it is okay to ask more clarifying questions / push back
a little. I had a quick look and calling iavf_vlan_rx_kill_vid()
with vid of 0 does not seem harmful. Or any vid that was not added
earlier. So it's down to personal preference. I see v2 is already 
out but just for future reference..

Re: [PATCH net 3/3] iavf: do not track VLAN 0 filters

[Ahmed Zaki]

On 2023-03-16 14:59, Jakub Kicinski wrote:
> On Thu, 16 Mar 2023 07:15:32 -0600 Ahmed Zaki wrote:
>>> I would expect similar check in iavf_vlan_rx_kill_vid(),
>> Thanks for review. Next version will include the check in
>> iavf_vlan_rx_kill_vid()
> FWIW it is okay to ask more clarifying questions / push back
> a little. I had a quick look and calling iavf_vlan_rx_kill_vid()
> with vid of 0 does not seem harmful. Or any vid that was not added
> earlier. So it's down to personal preference. I see v2 is already
> out but just for future reference..

Thanks. I had the same thoughts, but then the extra check still saves 
few cycles (the function trying to find the VID), so I added it.

Re: [PATCH net 3/3] iavf: do not track VLAN 0 filters

[Leon Romanovsky]

On Thu, Mar 16, 2023 at 01:59:24PM -0700, Jakub Kicinski wrote:
> On Thu, 16 Mar 2023 07:15:32 -0600 Ahmed Zaki wrote:
> > > I would expect similar check in iavf_vlan_rx_kill_vid(),
> >
> > Thanks for review. Next version will include the check in 
> > iavf_vlan_rx_kill_vid()
> 
> FWIW it is okay to ask more clarifying questions / push back
> a little. I had a quick look and calling iavf_vlan_rx_kill_vid()
> with vid of 0 does not seem harmful. Or any vid that was not added
> earlier. So it's down to personal preference. 

I would agree with you if they would bail immediately in case no vid is
found, however it is not the case. They continue to perform function
execution in any case, which is harmless now, but prone to errors in the
future.

Thanks