[jkirsher/next-queue PATCH 0/5] macvlan offload fixes

[jkirsher/next-queue PATCH 0/5] macvlan offload fixes

[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.

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(-)

[Intel-wired-lan] [jkirsher/next-queue PATCH 0/5] macvlan offload fixes

[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.

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(-)

--

[jkirsher/next-queue PATCH 1/5] ixgbe: Fix interaction between SR-IOV and macvlan offload

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@intel.com>

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 <alexander.h.duyck@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2d0232254a7a..69ef35d13c36 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -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);

[Intel-wired-lan] [jkirsher/next-queue PATCH 1/5] ixgbe: Fix interaction between SR-IOV and macvlan offload

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@intel.com>

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 <alexander.h.duyck@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2d0232254a7a..69ef35d13c36 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -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);

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

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@intel.com>

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 <alexander.h.duyck@intel.com>
---
 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
index 81e4425f0529..1280127077de 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
@@ -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);

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

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@intel.com>

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 <alexander.h.duyck@intel.com>
---
 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
index 81e4425f0529..1280127077de 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
@@ -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);

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

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@intel.com>

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 <alexander.h.duyck@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 69ef35d13c36..b22ec4b9d02c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -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;

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

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@intel.com>

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 <alexander.h.duyck@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 69ef35d13c36..b22ec4b9d02c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -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;

[jkirsher/next-queue PATCH 4/5] dev: Clean-up __skb_tx_hash to match up with traffic class based configs

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@intel.com>

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 <alexander.h.duyck@intel.com>
---
 net/core/dev.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 24ac9083bc13..fd51b8703277 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -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);

[Intel-wired-lan] [jkirsher/next-queue PATCH 4/5] dev: Clean-up __skb_tx_hash to match up with traffic class based configs

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@intel.com>

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 <alexander.h.duyck@intel.com>
---
 net/core/dev.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 24ac9083bc13..fd51b8703277 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -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);

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

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@intel.com>

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 <alexander.h.duyck@intel.com>
---
 net/core/dev.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index fd51b8703277..59dcc1b26ae2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -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);

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

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@intel.com>

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 <alexander.h.duyck@intel.com>
---
 net/core/dev.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index fd51b8703277..59dcc1b26ae2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -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);

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

[Shannon Nelson]

On 11/2/2017 4:34 PM, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> 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 <alexander.h.duyck@intel.com>
> ---
>   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   17 +++++++++++++++--
>   1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 69ef35d13c36..b22ec4b9d02c 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -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

s/reporing/reporting/

> +		 * 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@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> 

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

[Shannon Nelson]

On 11/2/2017 4:34 PM, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> 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 <alexander.h.duyck@intel.com>
> ---
>   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   17 +++++++++++++++--
>   1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 69ef35d13c36..b22ec4b9d02c 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -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

s/reporing/reporting/

> +		 * 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
> 

[Intel-wired-lan] [jkirsher/next-queue PATCH 1/5] ixgbe: Fix interaction between SR-IOV and macvlan offload

[Jesse Brandeburg]

On Thu, 2 Nov 2017 16:33:30 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:

> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> 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 <alexander.h.duyck@intel.com>

Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>

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

[Jesse Brandeburg]

On Thu, 2 Nov 2017 16:33:45 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:

> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> 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 <jesse.brandeburg@intel.com>

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

[Jesse Brandeburg]

On Thu, 2 Nov 2017 16:33:45 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:

> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> 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 <jesse.brandeburg@intel.com>

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

[Jesse Brandeburg]

On Thu, 2 Nov 2017 16:34:58 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:

> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> 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 <jesse.brandeburg@intel.com>

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

[Jesse Brandeburg]

On Thu, 2 Nov 2017 16:34:58 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:

> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> 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 <jesse.brandeburg@intel.com>

Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 0/5] macvlan offload fixes

[Shannon Nelson]

On 11/2/2017 4:33 PM, Alexander Duyck wrote:
> 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.

Other than the little misspelling I flagged,
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>

> 
> ---
> 
> 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@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> 

[Intel-wired-lan] [jkirsher/next-queue PATCH 0/5] macvlan offload fixes

[Shannon Nelson]

On 11/2/2017 4:33 PM, Alexander Duyck wrote:
> 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.

Other than the little misspelling I flagged,
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>

> 
> ---
> 
> 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
> 

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

[Alexander Duyck]

On Thu, Nov 2, 2017 at 4:34 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> 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 <alexander.h.duyck@intel.com>
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 69ef35d13c36..b22ec4b9d02c 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -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;
>

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.

> @@ -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;
>

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

[Alexander Duyck]

On Thu, Nov 2, 2017 at 4:34 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> 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 <alexander.h.duyck@intel.com>
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 69ef35d13c36..b22ec4b9d02c 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -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;
>

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.

> @@ -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;
>

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

[Keller, Jacob E]

> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On Behalf Of
> Jesse Brandeburg
> Sent: Friday, November 03, 2017 10:06 AM
> To: Alexander Duyck <alexander.duyck@gmail.com>
> Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org
> Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN
> configuration for macvlan offload
> 
> On Thu, 2 Nov 2017 16:33:45 -0700
> Alexander Duyck <alexander.duyck@gmail.com> wrote:
> 
> > From: Alexander Duyck <alexander.h.duyck@intel.com>
> >
> > 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 <jesse.brandeburg@intel.com>
> 

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

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

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

[Keller, Jacob E]

> -----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 <alexander.duyck@gmail.com>
> 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
> 
> On Thu, 2 Nov 2017 16:33:45 -0700
> Alexander Duyck <alexander.duyck@gmail.com> wrote:
> 
> > From: Alexander Duyck <alexander.h.duyck@intel.com>
> >
> > 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 <jesse.brandeburg@intel.com>
> 

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

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

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

[Alexander Duyck]

On Wed, Nov 8, 2017 at 2:05 PM, Keller, Jacob E
<jacob.e.keller@intel.com> wrote:
>> -----Original Message-----
>> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On Behalf Of
>> Jesse Brandeburg
>> Sent: Friday, November 03, 2017 10:06 AM
>> To: Alexander Duyck <alexander.duyck@gmail.com>
>> Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org
>> Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN
>> configuration for macvlan offload
>>
>> On Thu, 2 Nov 2017 16:33:45 -0700
>> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>>
>> > From: Alexander Duyck <alexander.h.duyck@intel.com>
>> >
>> > 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 <jesse.brandeburg@intel.com>
>>
>
> 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

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

[Alexander Duyck]

On Wed, Nov 8, 2017 at 2:05 PM, Keller, Jacob E
<jacob.e.keller@intel.com> wrote:
>> -----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 <alexander.duyck@gmail.com>
>> 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
>>
>> On Thu, 2 Nov 2017 16:33:45 -0700
>> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>>
>> > From: Alexander Duyck <alexander.h.duyck@intel.com>
>> >
>> > 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 <jesse.brandeburg@intel.com>
>>
>
> 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

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

[Keller, Jacob E]

> -----Original Message-----
> From: Alexander Duyck [mailto:alexander.duyck@gmail.com]
> Sent: Wednesday, November 08, 2017 3:04 PM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; netdev@vger.kernel.org;
> intel-wired-lan@lists.osuosl.org
> Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN
> configuration for macvlan offload
> 
> On Wed, Nov 8, 2017 at 2:05 PM, Keller, Jacob E
> <jacob.e.keller@intel.com> wrote:
> >> -----Original Message-----
> >> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On Behalf
> Of
> >> Jesse Brandeburg
> >> Sent: Friday, November 03, 2017 10:06 AM
> >> To: Alexander Duyck <alexander.duyck@gmail.com>
> >> Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org
> >> Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix
> VLAN
> >> configuration for macvlan offload
> >>
> >> On Thu, 2 Nov 2017 16:33:45 -0700
> >> Alexander Duyck <alexander.duyck@gmail.com> wrote:
> >>
> >> > From: Alexander Duyck <alexander.h.duyck@intel.com>
> >> >
> >> > 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 <jesse.brandeburg@intel.com>
> >>
> >
> > 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

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

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

[Keller, Jacob E]

> -----Original Message-----
> From: Alexander Duyck [mailto:alexander.duyck at gmail.com]
> Sent: Wednesday, November 08, 2017 3:04 PM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; 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
> 
> On Wed, Nov 8, 2017 at 2:05 PM, Keller, Jacob E
> <jacob.e.keller@intel.com> wrote:
> >> -----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 <alexander.duyck@gmail.com>
> >> 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
> >>
> >> On Thu, 2 Nov 2017 16:33:45 -0700
> >> Alexander Duyck <alexander.duyck@gmail.com> wrote:
> >>
> >> > From: Alexander Duyck <alexander.h.duyck@intel.com>
> >> >
> >> > 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 <jesse.brandeburg@intel.com>
> >>
> >
> > 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

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

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

[Alexander Duyck]

On Wed, Nov 8, 2017 at 4:21 PM, Keller, Jacob E
<jacob.e.keller@intel.com> wrote:
>
>
>> -----Original Message-----
>> From: Alexander Duyck [mailto:alexander.duyck@gmail.com]
>> Sent: Wednesday, November 08, 2017 3:04 PM
>> To: Keller, Jacob E <jacob.e.keller@intel.com>
>> Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; netdev@vger.kernel.org;
>> intel-wired-lan@lists.osuosl.org
>> Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN
>> configuration for macvlan offload
>>
>> On Wed, Nov 8, 2017 at 2:05 PM, Keller, Jacob E
>> <jacob.e.keller@intel.com> wrote:
>> >> -----Original Message-----
>> >> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On Behalf
>> Of
>> >> Jesse Brandeburg
>> >> Sent: Friday, November 03, 2017 10:06 AM
>> >> To: Alexander Duyck <alexander.duyck@gmail.com>
>> >> Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org
>> >> Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix
>> VLAN
>> >> configuration for macvlan offload
>> >>
>> >> On Thu, 2 Nov 2017 16:33:45 -0700
>> >> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>> >>
>> >> > From: Alexander Duyck <alexander.h.duyck@intel.com>
>> >> >
>> >> > 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 <jesse.brandeburg@intel.com>
>> >>
>> >
>> > 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
>
> 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

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

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

[Alexander Duyck]

On Wed, Nov 8, 2017 at 4:21 PM, Keller, Jacob E
<jacob.e.keller@intel.com> wrote:
>
>
>> -----Original Message-----
>> From: Alexander Duyck [mailto:alexander.duyck at gmail.com]
>> Sent: Wednesday, November 08, 2017 3:04 PM
>> To: Keller, Jacob E <jacob.e.keller@intel.com>
>> Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; 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
>>
>> On Wed, Nov 8, 2017 at 2:05 PM, Keller, Jacob E
>> <jacob.e.keller@intel.com> wrote:
>> >> -----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 <alexander.duyck@gmail.com>
>> >> 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
>> >>
>> >> On Thu, 2 Nov 2017 16:33:45 -0700
>> >> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>> >>
>> >> > From: Alexander Duyck <alexander.h.duyck@intel.com>
>> >> >
>> >> > 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 <jesse.brandeburg@intel.com>
>> >>
>> >
>> > 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
>
> 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

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

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

[Keller, Jacob E]

> -----Original Message-----
> From: Alexander Duyck [mailto:alexander.duyck@gmail.com]
> Sent: Wednesday, November 08, 2017 4:32 PM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; netdev@vger.kernel.org;
> intel-wired-lan@lists.osuosl.org
> Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix VLAN
> configuration for macvlan offload
> 
> On Wed, Nov 8, 2017 at 4:21 PM, Keller, Jacob E
> <jacob.e.keller@intel.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Alexander Duyck [mailto:alexander.duyck@gmail.com]
> >> Sent: Wednesday, November 08, 2017 3:04 PM
> >> To: Keller, Jacob E <jacob.e.keller@intel.com>
> >> Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>;
> netdev@vger.kernel.org;
> >> intel-wired-lan@lists.osuosl.org
> >> Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix
> VLAN
> >> configuration for macvlan offload
> >>
> >> On Wed, Nov 8, 2017 at 2:05 PM, Keller, Jacob E
> >> <jacob.e.keller@intel.com> wrote:
> >> >> -----Original Message-----
> >> >> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> Behalf
> >> Of
> >> >> Jesse Brandeburg
> >> >> Sent: Friday, November 03, 2017 10:06 AM
> >> >> To: Alexander Duyck <alexander.duyck@gmail.com>
> >> >> Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org
> >> >> Subject: Re: [Intel-wired-lan] [jkirsher/next-queue PATCH 2/5] fm10k: Fix
> >> VLAN
> >> >> configuration for macvlan offload
> >> >>
> >> >> On Thu, 2 Nov 2017 16:33:45 -0700
> >> >> Alexander Duyck <alexander.duyck@gmail.com> wrote:
> >> >>
> >> >> > From: Alexander Duyck <alexander.h.duyck@intel.com>
> >> >> >
> >> >> > 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 <jesse.brandeburg@intel.com>
> >> >>
> >> >
> >> > 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
> >
> > 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
> 
> 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

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

[Keller, Jacob E]

> -----Original Message-----
> From: Alexander Duyck [mailto:alexander.duyck at gmail.com]
> Sent: Wednesday, November 08, 2017 4:32 PM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; 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
> 
> On Wed, Nov 8, 2017 at 4:21 PM, Keller, Jacob E
> <jacob.e.keller@intel.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Alexander Duyck [mailto:alexander.duyck at gmail.com]
> >> Sent: Wednesday, November 08, 2017 3:04 PM
> >> To: Keller, Jacob E <jacob.e.keller@intel.com>
> >> Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>;
> 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
> >>
> >> On Wed, Nov 8, 2017 at 2:05 PM, Keller, Jacob E
> >> <jacob.e.keller@intel.com> wrote:
> >> >> -----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 <alexander.duyck@gmail.com>
> >> >> 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
> >> >>
> >> >> On Thu, 2 Nov 2017 16:33:45 -0700
> >> >> Alexander Duyck <alexander.duyck@gmail.com> wrote:
> >> >>
> >> >> > From: Alexander Duyck <alexander.h.duyck@intel.com>
> >> >> >
> >> >> > 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 <jesse.brandeburg@intel.com>
> >> >>
> >> >
> >> > 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
> >
> > 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
> 
> 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

[Intel-wired-lan] [jkirsher/next-queue PATCH 1/5] ixgbe: Fix interaction between SR-IOV and macvlan offload

[Bowers, AndrewX]

> -----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 <alexander.h.duyck@intel.com>
> 
> 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 <alexander.h.duyck@intel.com>
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Tested-by: Andrew Bowers <andrewx.bowers@intel.com>

[Intel-wired-lan] [jkirsher/next-queue PATCH 1/5] ixgbe: Fix interaction between SR-IOV and macvlan offload

[Duyck, Alexander H]

On Thu, 2017-11-09 at 22:39 +0000, Bowers, AndrewX wrote:
> > -----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 <alexander.h.duyck@intel.com>
> > 
> > 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 <alexander.h.duyck@intel.com>
> > ---
> >  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |    5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>

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