macvlan offload fixes

PATCH In review Alexander Duyck 5 participants 19 messages Nov 2, 2017 – Nov 10, 2017

Subsystems (3)

Networking Network drivers Intel Ethernet

lore

Share & tools

lore

Alexander Duyck

author

2017-11-02 23:33 UTC #0 lore raw

cover macvlan offload fixes

I'm looking at performing a refactor of the macvlan offload code. However before I started I wanted to at least get things into a running state. The patches in this set are needed to address a number of issues that were preventing things from working as they were supposed to.

With these changes in place I seem to be able to receive traffic as I am supposed to in the case of ixgbe and fm10k with the offload enabled, and I am now transmitting to the correct Tx ring in the case of ixgbe.

The last two patches in the set are what I consider to be minor clean-ups to address the fact that we don't want packets to somehow stray and end up being transmitted on a queue that is supposed to be in use by a macvlan instead of the lowerdev itself.

---

Alexander Duyck (5):
ixgbe: Fix interaction between SR-IOV and macvlan offload
fm10k: Fix VLAN configuration for macvlan offload
ixgbe: Fix handling of macvlan Tx offload
dev: Clean-up __skb_tx_hash to match up with traffic class based configs
dev: Cap number of queues even with accel_priv

 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c |    4 ++--
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c   |   22 ++++++++++++++++++----
 net/core/dev.c                                  |   21 ++++++++++-----------
 3 files changed, 30 insertions(+), 17 deletions(-)

Alexander Duyck

author

2017-11-02 23:33 UTC #1 lore raw

PATCH 1/5 ixgbe: Fix interaction between SR-IOV and macvlan offload

From: Alexander Duyck <[email protected]>

When SR-IOV was enabled the macvlan offload was configuring several filters with the wrong pool value. This would result in the macvlan interfaces not being able to receive traffic that had to pass over the physical interface.

To fix it wrap the pool argument in the VMDQ_P macro which will add the necessary offset to get to the actual VMDq pool

Signed-off-by Alexander Duyck <[email protected]>

---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +3 -2

index 2d0232254a7a..69ef35d13c36 100644
@@ -5426,10 +5426,11 @@ static int ixgbe_fwd_ring_up(struct net_device *vdev,
 		goto fwd_queue_err;
 
 	if (is_valid_ether_addr(vdev->dev_addr))
-		ixgbe_add_mac_filter(adapter, vdev->dev_addr, accel->pool);
+		ixgbe_add_mac_filter(adapter, vdev->dev_addr,
+				     VMDQ_P(accel->pool));
 
 	ixgbe_fwd_psrtype(accel);
-	ixgbe_macvlan_set_rx_mode(vdev, accel->pool, adapter);
+	ixgbe_macvlan_set_rx_mode(vdev, VMDQ_P(accel->pool), adapter);
 	return err;
 fwd_queue_err:
 	ixgbe_fwd_ring_down(vdev, accel);

Jesse Brandeburg

2017-11-03 17:05 UTC #2 lore raw

PATCH 1/5 ixgbe: Fix interaction between SR-IOV and macvlan offload

Quoted 10 lines · On Thu, 2 Nov 2017 16:33:30 -0700 Alexander Duyck <[email protected]>…

From: Alexander Duyck <[email protected]>
When SR-IOV was enabled the macvlan offload was configuring several filters with the wrong pool value. This would result in the macvlan interfaces not being able to receive traffic that had to pass over the physical interface.
To fix it wrap the pool argument in the VMDQ_P macro which will add the necessary offset to get to the actual VMDq pool
Signed-off-by Alexander Duyck <[email protected]>

Reviewed-by Jesse Brandeburg <[email protected]>

Bowers

2017-11-09 22:39 UTC #3 lore raw

PATCH 1/5 ixgbe: Fix interaction between SR-IOV and macvlan offload

In reply to Alexander Duyck

Quoted 14 lines

-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf Of Alexander Duyck
Sent: Thursday, November 2, 2017 4:34 PM
To: netdev at vger.kernel.org; intel-wired-lan at lists.osuosl.org
Subject: [Intel-wired-lan] [jkirsher/next-queue PATCH 1/5] ixgbe: Fix interaction between SR-IOV and macvlan offload
From: Alexander Duyck <[email protected]>
When SR-IOV was enabled the macvlan offload was configuring several filters with the wrong pool value. This would result in the macvlan interfaces not being able to receive traffic that had to pass over the physical interface.

Quoted 7 lines

To fix it wrap the pool argument in the VMDQ_P macro which will add the necessary offset to get to the actual VMDq pool
Signed-off-by Alexander Duyck <[email protected]>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Tested-by Andrew Bowers <[email protected]>

Duyck

2017-11-10 17:37 UTC #4 lore raw

PATCH 1/5 ixgbe: Fix interaction between SR-IOV and macvlan offload

Quoted 17 lines · AndrewX

Quoted 17 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf Of Alexander Duyck
Sent: Thursday, November 2, 2017 4:34 PM
To: netdev at vger.kernel.org; intel-wired-lan at lists.osuosl.org
Subject: [Intel-wired-lan] [jkirsher/next-queue PATCH 1/5] ixgbe: Fix interaction between SR-IOV and macvlan offload
From: Alexander Duyck <[email protected]>
When SR-IOV was enabled the macvlan offload was configuring several filters with the wrong pool value. This would result in the macvlan interfaces not being able to receive traffic that had to pass over the physical interface.
To fix it wrap the pool argument in the VMDQ_P macro which will add the necessary offset to get to the actual VMDq pool

Quoted 6 lines

Quoted 4 lines
Signed-off-by Alexander Duyck <[email protected]>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
Tested-by Andrew Bowers <[email protected]>

Actually I think I want to NAK this patch and the fm10k one that came after it. I need to redo both of them anyway so I might as well just re-submit the whole set.

- Alex

Alexander Duyck

author

2017-11-02 23:33 UTC #5 lore raw

PATCH 2/5 fm10k: Fix VLAN configuration for macvlan offload

In reply to Alexander Duyck

From: Alexander Duyck <[email protected]>

The fm10k driver didn't work correctly when macvlan offload was enabled. Specifically what would occur is that we would see no unicast packets being received. This was traced down to us not correctly configuring the default VLAN ID for the port and defaulting to 0.

To correct this we either use the default ID provided by the switch or simply use 1. With that we are able to pass and receive traffic without any issues.

Signed-off-by Alexander Duyck <[email protected]>

---
 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +2 -2

index 81e4425f0529..1280127077de 100644
@@ -1490,7 +1490,7 @@ static void *fm10k_dfwd_add_station(struct net_device *dev,
 		hw->mac.ops.update_xcast_mode(hw, glort,
 					      FM10K_XCAST_MODE_MULTI);
 		fm10k_queue_mac_request(interface, glort, sdev->dev_addr,
-					0, true);
+					hw->mac.default_vid ? : 1, true);
 	}
 
 	fm10k_mbx_unlock(interface);

@@ -1530,7 +1530,7 @@ static void fm10k_dfwd_del_station(struct net_device *dev, void *priv)
 		hw->mac.ops.update_xcast_mode(hw, glort,
 					      FM10K_XCAST_MODE_NONE);
 		fm10k_queue_mac_request(interface, glort, sdev->dev_addr,
-					0, false);
+					hw->mac.default_vid ? : 1, false);
 	}
 
 	fm10k_mbx_unlock(interface);

Jesse Brandeburg

Reviewed-by on v1 2/5

2017-11-03 17:05 UTC #6 lore raw

Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN configuration for macvlan offload

Quoted 10 lines · On Thu, 2 Nov 2017 16:33:45 -0700 Alexander Duyck <[email protected]>…

From: Alexander Duyck <[email protected]>
The fm10k driver didn't work correctly when macvlan offload was enabled. Specifically what would occur is that we would see no unicast packets being received. This was traced down to us not correctly configuring the default VLAN ID for the port and defaulting to 0.
To correct this we either use the default ID provided by the switch or simply use 1. With that we are able to pass and receive traffic without any issues.

Reviewed-by Jesse Brandeburg <[email protected]>

Keller, Jacob E

2017-11-08 22:05 UTC #7 lore raw

RE: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN configuration for macvlan offload

Quoted 19 lines

-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf Of Jesse Brandeburg
Sent: Friday, November 03, 2017 10:06 AM
To: Alexander Duyck <[email protected]>
Cc: netdev at vger.kernel.org; intel-wired-lan at lists.osuosl.org
Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN configuration for macvlan offload
Quoted 7 lines · On Thu, 2 Nov 2017 16:33:45 -0700 Alexander Duyck <[email protected]>…
From: Alexander Duyck <[email protected]>
The fm10k driver didn't work correctly when macvlan offload was enabled. Specifically what would occur is that we would see no unicast packets being received. This was traced down to us not correctly configuring the default VLAN ID for the port and defaulting to 0.

Quoted 6 lines

Quoted 3 lines
To correct this we either use the default ID provided by the switch or simply use 1. With that we are able to pass and receive traffic without any issues.
Reviewed-by Jesse Brandeburg <[email protected]>

Hi,

I think this isn't quite right, since we recently made changes to the fm10k code to stop assuming VLAN 1 in these cases. I believe it should just pass the default_vid

Thanks,
Jake

_______________________________________________

Quoted 3 lines

Intel-wired-lan mailing list
Intel-wired-lan at osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Alexander Duyck

author

2017-11-08 23:03 UTC #8 lore raw

Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN configuration for macvlan offload

Quoted 26 lines · Jacob E

Quoted 19 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf Of Jesse Brandeburg
Sent: Friday, November 03, 2017 10:06 AM
To: Alexander Duyck <[email protected]>
Cc: netdev at vger.kernel.org; intel-wired-lan at lists.osuosl.org
Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN configuration for macvlan offload
Quoted 7 lines · On Thu, 2 Nov 2017 16:33:45 -0700 Alexander Duyck <[email protected]>…
From: Alexander Duyck <[email protected]>
The fm10k driver didn't work correctly when macvlan offload was enabled. Specifically what would occur is that we would see no unicast packets being received. This was traced down to us not correctly configuring the default VLAN ID for the port and defaulting to 0.
Quoted 6 lines
Quoted 3 lines
To correct this we either use the default ID provided by the switch or simply use 1. With that we are able to pass and receive traffic without any issues.
Reviewed-by Jesse Brandeburg <[email protected]>

Quoted 7 lines

Hi,
I think this isn't quite right, since we recently made changes to the fm10k code to stop assuming VLAN 1 in these cases. I believe it should just pass the default_vid
Thanks,
Jake

I kind of figured that might be the case. We can probably drop this patch for now and if you want you can work this from our end as the out-of-tree code doesn't make the upstream and I would imagine you guys are planning to upstream that patch at some point.

- Alex

Keller, Jacob E

2017-11-09 00:21 UTC #9 lore raw

RE: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN configuration for macvlan offload

Quoted 51 lines

-----Original Message-----
From: Alexander Duyck [mailto:alexander.duyck at gmail.com]
Sent: Wednesday, November 08, 2017 3:04 PM
To: Keller, Jacob E <[email protected]>
Cc: Brandeburg, Jesse <[email protected]>; netdev at vger.kernel.org; intel-wired-lan at lists.osuosl.org
Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN configuration for macvlan offload
Quoted 2 lines · Jacob E
Quoted 2 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf
Of
Quoted 5 lines
Quoted 5 lines
Jesse Brandeburg
Sent: Friday, November 03, 2017 10:06 AM
To: Alexander Duyck <[email protected]>
Cc: netdev at vger.kernel.org; intel-wired-lan at lists.osuosl.org
Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix
VLAN
Quoted 16 lines
Quoted 16 lines
configuration for macvlan offload
Quoted 10 lines · On Thu, 2 Nov 2017 16:33:45 -0700 Alexander Duyck <[email protected]>…
From: Alexander Duyck <[email protected]>
The fm10k driver didn't work correctly when macvlan offload was enabled. Specifically what would occur is that we would see no unicast packets being received. This was traced down to us not correctly configuring the default VLAN ID for the port and defaulting to 0.
To correct this we either use the default ID provided by the switch or simply use 1. With that we are able to pass and receive traffic without any issues.
Quoted 6 lines
Quoted 2 lines
Reviewed-by Jesse Brandeburg <[email protected]>
Hi,
I think this isn't quite right, since we recently made changes to the fm10k code
to stop assuming VLAN 1 in these cases. I believe it should just pass the default_vid
Quoted 4 lines
Thanks,
Jake

Quoted 6 lines

I kind of figured that might be the case. We can probably drop this patch for now and if you want you can work this from our end as the out-of-tree code doesn't make the upstream and I would imagine you guys are planning to upstream that patch at some point.
- Alex

I think the patch should just be changed from using

hw->mac.default_vid ? : 1

to just using hw->mac.default_vid directly.

Otherwise, I think the patch is necessary.

Thanks,
Jake

Alexander Duyck

author

2017-11-09 00:32 UTC #10 lore raw

Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN configuration for macvlan offload

Quoted 60 lines · Jacob E

Quoted 51 lines
-----Original Message-----
From: Alexander Duyck [mailto:alexander.duyck at gmail.com]
Sent: Wednesday, November 08, 2017 3:04 PM
To: Keller, Jacob E <[email protected]>
Cc: Brandeburg, Jesse <[email protected]>; netdev at vger.kernel.org; intel-wired-lan at lists.osuosl.org
Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN configuration for macvlan offload
Quoted 2 lines · Jacob E
Quoted 2 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf
Of
Quoted 5 lines
Quoted 5 lines
Jesse Brandeburg
Sent: Friday, November 03, 2017 10:06 AM
To: Alexander Duyck <[email protected]>
Cc: netdev at vger.kernel.org; intel-wired-lan at lists.osuosl.org
Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix
VLAN
Quoted 16 lines
Quoted 16 lines
configuration for macvlan offload
Quoted 10 lines · On Thu, 2 Nov 2017 16:33:45 -0700 Alexander Duyck <[email protected]>…
From: Alexander Duyck <[email protected]>
The fm10k driver didn't work correctly when macvlan offload was enabled. Specifically what would occur is that we would see no unicast packets being received. This was traced down to us not correctly configuring the default VLAN ID for the port and defaulting to 0.
To correct this we either use the default ID provided by the switch or simply use 1. With that we are able to pass and receive traffic without any issues.
Quoted 6 lines
Quoted 2 lines
Reviewed-by Jesse Brandeburg <[email protected]>
Hi,
I think this isn't quite right, since we recently made changes to the fm10k code
to stop assuming VLAN 1 in these cases. I believe it should just pass the default_vid
Quoted 4 lines
Thanks,
Jake
Quoted 6 lines
I kind of figured that might be the case. We can probably drop this patch for now and if you want you can work this from our end as the out-of-tree code doesn't make the upstream and I would imagine you guys are planning to upstream that patch at some point.
- Alex
I think the patch should just be changed from using

Quoted 8 lines

hw->mac.default_vid ? : 1
to just using hw->mac.default_vid directly.
Otherwise, I think the patch is necessary.
Thanks,
Jake

Doesn't passing a 0 in the case of the value not being populated cause issues? If I understand the problem I thought passing a 0 in the vlan ID field caused some sort of error.

- Alex

Keller, Jacob E

2017-11-09 01:26 UTC #11 lore raw

RE: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN configuration for macvlan offload

Quoted 83 lines

-----Original Message-----
From: Alexander Duyck [mailto:alexander.duyck at gmail.com]
Sent: Wednesday, November 08, 2017 4:32 PM
To: Keller, Jacob E <[email protected]>
Cc: Brandeburg, Jesse <[email protected]>; netdev at vger.kernel.org; intel-wired-lan at lists.osuosl.org
Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN configuration for macvlan offload
Quoted 7 lines · Jacob E
Quoted 7 lines
-----Original Message-----
From: Alexander Duyck [mailto:alexander.duyck at gmail.com]
Sent: Wednesday, November 08, 2017 3:04 PM
To: Keller, Jacob E <[email protected]>
Cc: Brandeburg, Jesse <[email protected]>;
netdev at vger.kernel.org;
Quoted 2 lines
Quoted 2 lines
intel-wired-lan at lists.osuosl.org
Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix
VLAN
Quoted 6 lines
Quoted 6 lines
configuration for macvlan offload
Quoted 2 lines · Jacob E
Quoted 2 lines
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On
Behalf
Quoted 7 lines
Quoted 7 lines
Of
Quoted 5 lines
Quoted 5 lines
Jesse Brandeburg
Sent: Friday, November 03, 2017 10:06 AM
To: Alexander Duyck <[email protected]>
Cc: netdev at vger.kernel.org; intel-wired-lan at lists.osuosl.org
Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix
VLAN
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
configuration for macvlan offload
Quoted 3 lines · On Thu, 2 Nov 2017 16:33:45 -0700 Alexander Duyck <[email protected]>…
From: Alexander Duyck <[email protected]>
The fm10k driver didn't work correctly when macvlan offload was
enabled.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Specifically what would occur is that we would see no unicast packets
being
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
received. This was traced down to us not correctly configuring the default VLAN ID for the port and defaulting to 0.
To correct this we either use the default ID provided by the switch or simply use 1. With that we are able to pass and receive traffic without any issues.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Reviewed-by Jesse Brandeburg <[email protected]>
Hi,
I think this isn't quite right, since we recently made changes to the fm10k
code
Quoted 22 lines
Quoted 7 lines
to stop assuming VLAN 1 in these cases. I believe it should just pass the default_vid
Quoted 4 lines
Thanks,
Jake
Quoted 6 lines
I kind of figured that might be the case. We can probably drop this patch for now and if you want you can work this from our end as the out-of-tree code doesn't make the upstream and I would imagine you guys are planning to upstream that patch at some point.
- Alex
I think the patch should just be changed from using
hw->mac.default_vid ? : 1
to just using hw->mac.default_vid directly.
Otherwise, I think the patch is necessary.

Quoted 8 lines

Quoted 2 lines
Thanks,
Jake
Doesn't passing a 0 in the case of the value not being populated cause issues? If I understand the problem I thought passing a 0 in the vlan ID field caused some sort of error.
- Alex

No, it just doesn't really do anything useful. But it doesn't harm anything either.

Using 0 on the switch side causes problems for the switch manager, but in this case, if we don't have a default_vid, then we aren't talking to the switch anyways.

Thanks,
Jake

Alexander Duyck

author

2017-11-02 23:34 UTC #12 lore raw

PATCH 3/5 ixgbe: Fix handling of macvlan Tx offload

In reply to Alexander Duyck

From: Alexander Duyck <[email protected]>

This update makes it so that we report the actual number of Tx queues via real_num_tx_queues but are still restricted to RSS on only the first pool by setting num_tc equal to 1. Doing this locks us into only having the ability to setup XPS on the queues in that pool, and only those queues should be used for transmitting anything other than macvlan traffic.

Signed-off-by Alexander Duyck <[email protected]>

---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +15 -2

index 69ef35d13c36..b22ec4b9d02c 100644
@@ -6638,8 +6638,9 @@ int ixgbe_open(struct net_device *netdev)
 		goto err_req_irq;
 
 	/* Notify the stack of the actual queue counts. */
-	if (adapter->num_rx_pools > 1)
-		queues = adapter->num_rx_queues_per_pool;
+	if (adapter->num_rx_pools > 1 &&
+	    adapter->num_tx_queues > IXGBE_MAX_L2A_QUEUES)
+		queues = IXGBE_MAX_L2A_QUEUES;
 	else
 		queues = adapter->num_tx_queues;

@@ -8901,6 +8902,18 @@ int ixgbe_setup_tc(struct net_device *dev, u8 tc)
 		if (adapter->hw.mac.type == ixgbe_mac_82598EB)
 			adapter->hw.fc.requested_mode = adapter->last_lfc_mode;
 
+		/* To support macvlan offload we have to use num_tc to
+		 * restrict the queues that can be used by the device.
+		 * By doing this we can avoid reporing a false number of
+		 * queues.
+		 */
+		if (adapter->num_rx_pools > 1) {
+			u16 qpp = adapter->num_rx_queues_per_pool;
+
+			netdev_set_num_tc(dev, 1);
+			netdev_set_tc_queue(dev, 0, qpp, 0);
+		}
+
 		adapter->flags &= ~IXGBE_FLAG_DCB_ENABLED;
 
 		adapter->temp_dcb_cfg.pfc_mode_enable = false;

Shannon Nelson

2017-11-03 16:30 UTC #13 lore raw

Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 3/5] ixgbe: Fix handling of macvlan Tx offload

Quoted 30 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>
This update makes it so that we report the actual number of Tx queues via real_num_tx_queues but are still restricted to RSS on only the first pool by setting num_tc equal to 1. Doing this locks us into only having the ability to setup XPS on the queues in that pool, and only those queues should be used for transmitting anything other than macvlan traffic.
Signed-off-by Alexander Duyck <[email protected]>
---
  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   17 +++++++++++++++--
  1 file changed, 15 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +3 -2
index 69ef35d13c36..b22ec4b9d02c 100644
@@ -6638,8 +6638,9 @@ int ixgbe_open(struct net_device *netdev)
  		goto err_req_irq;
 
  	/* Notify the stack of the actual queue counts. */
-	if (adapter->num_rx_pools > 1)
-		queues = adapter->num_rx_queues_per_pool;
+	if (adapter->num_rx_pools > 1 &&
+	    adapter->num_tx_queues > IXGBE_MAX_L2A_QUEUES)
+		queues = IXGBE_MAX_L2A_QUEUES;
  	else
  		queues = adapter->num_tx_queues;
 

drivers/net/ethernet/intel/ixgbe/ixgbe_main.c int ixgbe_setup_tc(struct net_device *dev, u8 tc) · line 8907

Quoted 6 lines

drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +3 -0

@@ -8901,6 +8902,18 @@ int ixgbe_setup_tc(struct net_device *dev, u8 tc)
  		if (adapter->hw.mac.type == ixgbe_mac_82598EB)
  			adapter->hw.fc.requested_mode = adapter->last_lfc_mode;
 
+		/* To support macvlan offload we have to use num_tc to
+		 * restrict the queues that can be used by the device.
+		 * By doing this we can avoid reporing a false number of

s/reporing/reporting/

Quoted 18 lines

drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +9 -0
+		 * queues.
+		 */
+		if (adapter->num_rx_pools > 1) {
+			u16 qpp = adapter->num_rx_queues_per_pool;
+
+			netdev_set_num_tc(dev, 1);
+			netdev_set_tc_queue(dev, 0, qpp, 0);
+		}
+
  		adapter->flags &= ~IXGBE_FLAG_DCB_ENABLED;
 
  		adapter->temp_dcb_cfg.pfc_mode_enable = false;
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan at osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Alexander Duyck

author

2017-11-03 18:18 UTC #14 lore raw

Re: [jkirsher/next-queue PATCH 3/5] ixgbe: Fix handling of macvlan Tx offload

In reply to Alexander Duyck

Quoted 19 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>
This update makes it so that we report the actual number of Tx queues via real_num_tx_queues but are still restricted to RSS on only the first pool by setting num_tc equal to 1. Doing this locks us into only having the ability to setup XPS on the queues in that pool, and only those queues should be used for transmitting anything other than macvlan traffic.
Signed-off-by Alexander Duyck <[email protected]>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +0 -0
index 69ef35d13c36..b22ec4b9d02c 100644
@@ -6638,8 +6638,9 @@ int ixgbe_open(struct net_device *netdev)
                goto err_req_irq;

drivers/net/ethernet/intel/ixgbe/ixgbe_main.c int ixgbe_open(struct net_device *netdev) · line 6646

Quoted 10 lines

drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +3 -2

 
        /* Notify the stack of the actual queue counts. */
-       if (adapter->num_rx_pools > 1)
-               queues = adapter->num_rx_queues_per_pool;
+       if (adapter->num_rx_pools > 1 &&
+           adapter->num_tx_queues > IXGBE_MAX_L2A_QUEUES)
+               queues = IXGBE_MAX_L2A_QUEUES;
        else
                queues = adapter->num_tx_queues;

I'm going to need to redo this portion of the patch anyway. It turns out I was only enabling up to 4 queues (which worked for my test case with 2 macvlan interfaces) because I didn't quite grok what this was doing.

Quoted 20 lines

drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +12 -0

@@ -8901,6 +8902,18 @@ int ixgbe_setup_tc(struct net_device *dev, u8 tc)
                if (adapter->hw.mac.type == ixgbe_mac_82598EB)
                        adapter->hw.fc.requested_mode = adapter->last_lfc_mode;
 
+               /* To support macvlan offload we have to use num_tc to
+                * restrict the queues that can be used by the device.
+                * By doing this we can avoid reporing a false number of
+                * queues.
+                */
+               if (adapter->num_rx_pools > 1) {
+                       u16 qpp = adapter->num_rx_queues_per_pool;
+
+                       netdev_set_num_tc(dev, 1);
+                       netdev_set_tc_queue(dev, 0, qpp, 0);
+               }
+
                adapter->flags &= ~IXGBE_FLAG_DCB_ENABLED;
 
                adapter->temp_dcb_cfg.pfc_mode_enable = false;

Alexander Duyck

author

2017-11-02 23:34 UTC #15 lore raw

PATCH 4/5 dev: Clean-up __skb_tx_hash to match up with traffic class based configs

In reply to Alexander Duyck

From: Alexander Duyck <[email protected]>

This patch is mostly just a minor clean-up so that we avoid letting a packet jump from one traffic class to another just based on the Rx queue. Instead we now use that queue number as an offset within the traffic class. Handling it this way allows us to operate more cleanly in a mixed environment that is doing routing over multiple interfaces that may not have the same queue configuration.

This patch includes a minor clean-up of variable declaration as well to get things into the reverse xmas tree format.

Signed-off-by Alexander Duyck <[email protected]>

---
 net/core/dev.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

net/core/dev.c +9 -9

index 24ac9083bc13..fd51b8703277 100644
@@ -2573,16 +2573,9 @@ void netif_device_attach(struct net_device *dev)
 u16 __skb_tx_hash(const struct net_device *dev, struct sk_buff *skb,
 		  unsigned int num_tx_queues)
 {
-	u32 hash;
-	u16 qoffset = 0;
 	u16 qcount = num_tx_queues;
-
-	if (skb_rx_queue_recorded(skb)) {
-		hash = skb_get_rx_queue(skb);
-		while (unlikely(hash >= num_tx_queues))
-			hash -= num_tx_queues;
-		return hash;
-	}
+	u16 qoffset = 0;
+	u32 hash;
 
 	if (dev->num_tc) {
 		u8 tc = netdev_get_prio_tc_map(dev, skb->priority);

@@ -2591,6 +2584,13 @@ u16 __skb_tx_hash(const struct net_device *dev, struct sk_buff *skb,
 		qcount = dev->tc_to_txq[tc].count;
 	}
 
+	if (skb_rx_queue_recorded(skb)) {
+		hash = skb_get_rx_queue(skb);
+		while (unlikely(hash >= qcount))
+			hash -= qcount;
+		return hash + qoffset;
+	}
+
 	return (u16) reciprocal_scale(skb_get_hash(skb), qcount) + qoffset;
 }
 EXPORT_SYMBOL(__skb_tx_hash);

Alexander Duyck

author

2017-11-02 23:34 UTC #16 lore raw

PATCH 5/5 dev: Cap number of queues even with accel_priv

In reply to Alexander Duyck

From: Alexander Duyck <[email protected]>

With the recent fix to ixgbe we can cap the number of queues always regardless of if accel_priv is being used or not since the actual number of queues are being reported via real_num_tx_queues.

Signed-off-by Alexander Duyck <[email protected]>

---
 net/core/dev.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

net/core/dev.c +1 -2

index fd51b8703277..59dcc1b26ae2 100644
@@ -3393,8 +3393,7 @@ struct netdev_queue *netdev_pick_tx(struct net_device *dev,
 		else
 			queue_index = __netdev_pick_tx(dev, skb);
 
-		if (!accel_priv)
-			queue_index = netdev_cap_txqueue(dev, queue_index);
+		queue_index = netdev_cap_txqueue(dev, queue_index);
 	}
 
 	skb_set_queue_mapping(skb, queue_index);

Jesse Brandeburg

Reviewed-by on v1 5/5

2017-11-03 17:07 UTC #17 lore raw

Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 5/5] dev: Cap number of queues even with accel_priv

Quoted 5 lines · On Thu, 2 Nov 2017 16:34:58 -0700 Alexander Duyck <[email protected]>…

From: Alexander Duyck <[email protected]>
With the recent fix to ixgbe we can cap the number of queues always regardless of if accel_priv is being used or not since the actual number of queues are being reported via real_num_tx_queues.

Makes sense.

Reviewed-by Jesse Brandeburg <[email protected]>

Shannon Nelson

Acked-by on the v1 series

2017-11-03 17:13 UTC #18 lore raw

In reply to Alexander Duyck

Quoted 5 lines · Alexander Duyck

I'm looking at performing a refactor of the macvlan offload code. However before I started I wanted to at least get things into a running state. The patches in this set are needed to address a number of issues that were preventing things from working as they were supposed to.

Quoted 8 lines

With these changes in place I seem to be able to receive traffic as I am supposed to in the case of ixgbe and fm10k with the offload enabled, and I am now transmitting to the correct Tx ring in the case of ixgbe.
The last two patches in the set are what I consider to be minor clean-ups to address the fact that we don't want packets to somehow stray and end up being transmitted on a queue that is supposed to be in use by a macvlan instead of the lowerdev itself.

Other than the little misspelling I flagged,

Acked-by Shannon Nelson <[email protected]>

Quoted 22 lines

---
Alexander Duyck (5):
ixgbe: Fix interaction between SR-IOV and macvlan offload
fm10k: Fix VLAN configuration for macvlan offload
ixgbe: Fix handling of macvlan Tx offload
dev: Clean-up __skb_tx_hash to match up with traffic class based configs
dev: Cap number of queues even with accel_priv
  drivers/net/ethernet/intel/fm10k/fm10k_netdev.c |    4 ++--
  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c   |   22 ++++++++++++++++++----
  net/core/dev.c                                  |   21 ++++++++++-----------
  3 files changed, 30 insertions(+), 17 deletions(-)
--
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan at osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan