Patch "Revert "mlx5: move affinity hints assignments to generic code"" has been added to the 4.14-stable tree

Patch "Revert "mlx5: move affinity hints assignments to generic code"" has been added to the 4.14-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    Revert "mlx5: move affinity hints assignments to generic code"

to the 4.14-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     revert-mlx5-move-affinity-hints-assignments-to-generic-code.patch
and it can be found in the queue-4.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From foo@baz Sun Dec 31 11:12:48 CET 2017
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Fri, 10 Nov 2017 15:59:52 +0900
Subject: Revert "mlx5: move affinity hints assignments to generic code"

From: Saeed Mahameed <saeedm@mellanox.com>


[ Upstream commit 231243c82793428467524227ae02ca451e6a98e7 ]

Before the offending commit, mlx5 core did the IRQ affinity itself,
and it seems that the new generic code have some drawbacks and one
of them is the lack for user ability to modify irq affinity after
the initial affinity values got assigned.

The issue is still being discussed and a solution in the new generic code
is required, until then we need to revert this patch.

This fixes the following issue:
echo <new affinity> > /proc/irq/<x>/smp_affinity
fails with  -EIO

This reverts commit a435393acafbf0ecff4deb3e3cb554b34f0d0664.
Note: kept mlx5_get_vector_affinity in include/linux/mlx5/driver.h since
it is used in mlx5_ib driver.

Fixes: a435393acafb ("mlx5: move affinity hints assignments to generic code")
Cc: Sagi Grimberg <sagi@grimberg.me>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jes Sorensen <jsorensen@fb.com>
Reported-by: Jes Sorensen <jsorensen@fb.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/mellanox/mlx5/core/en.h      |    1 
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c |   45 ++++++-------
 drivers/net/ethernet/mellanox/mlx5/core/main.c    |   75 ++++++++++++++++++++--
 include/linux/mlx5/driver.h                       |    1 
 4 files changed, 93 insertions(+), 29 deletions(-)

--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -590,6 +590,7 @@ struct mlx5e_channel {
 	struct mlx5_core_dev      *mdev;
 	struct mlx5e_tstamp       *tstamp;
 	int                        ix;
+	int                        cpu;
 };
 
 struct mlx5e_channels {
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -71,11 +71,6 @@ struct mlx5e_channel_param {
 	struct mlx5e_cq_param      icosq_cq;
 };
 
-static int mlx5e_get_node(struct mlx5e_priv *priv, int ix)
-{
-	return pci_irq_get_node(priv->mdev->pdev, MLX5_EQ_VEC_COMP_BASE + ix);
-}
-
 static bool mlx5e_check_fragmented_striding_rq_cap(struct mlx5_core_dev *mdev)
 {
 	return MLX5_CAP_GEN(mdev, striding_rq) &&
@@ -452,17 +447,16 @@ static int mlx5e_rq_alloc_mpwqe_info(str
 	int wq_sz = mlx5_wq_ll_get_size(&rq->wq);
 	int mtt_sz = mlx5e_get_wqe_mtt_sz();
 	int mtt_alloc = mtt_sz + MLX5_UMR_ALIGN - 1;
-	int node = mlx5e_get_node(c->priv, c->ix);
 	int i;
 
 	rq->mpwqe.info = kzalloc_node(wq_sz * sizeof(*rq->mpwqe.info),
-					GFP_KERNEL, node);
+				      GFP_KERNEL, cpu_to_node(c->cpu));
 	if (!rq->mpwqe.info)
 		goto err_out;
 
 	/* We allocate more than mtt_sz as we will align the pointer */
-	rq->mpwqe.mtt_no_align = kzalloc_node(mtt_alloc * wq_sz,
-					GFP_KERNEL, node);
+	rq->mpwqe.mtt_no_align = kzalloc_node(mtt_alloc * wq_sz, GFP_KERNEL,
+					cpu_to_node(c->cpu));
 	if (unlikely(!rq->mpwqe.mtt_no_align))
 		goto err_free_wqe_info;
 
@@ -570,7 +564,7 @@ static int mlx5e_alloc_rq(struct mlx5e_c
 	int err;
 	int i;
 
-	rqp->wq.db_numa_node = mlx5e_get_node(c->priv, c->ix);
+	rqp->wq.db_numa_node = cpu_to_node(c->cpu);
 
 	err = mlx5_wq_ll_create(mdev, &rqp->wq, rqc_wq, &rq->wq,
 				&rq->wq_ctrl);
@@ -636,8 +630,7 @@ static int mlx5e_alloc_rq(struct mlx5e_c
 	default: /* MLX5_WQ_TYPE_LINKED_LIST */
 		rq->wqe.frag_info =
 			kzalloc_node(wq_sz * sizeof(*rq->wqe.frag_info),
-				     GFP_KERNEL,
-				     mlx5e_get_node(c->priv, c->ix));
+				     GFP_KERNEL, cpu_to_node(c->cpu));
 		if (!rq->wqe.frag_info) {
 			err = -ENOMEM;
 			goto err_rq_wq_destroy;
@@ -1007,13 +1000,13 @@ static int mlx5e_alloc_xdpsq(struct mlx5
 	sq->uar_map   = mdev->mlx5e_res.bfreg.map;
 	sq->min_inline_mode = params->tx_min_inline_mode;
 
-	param->wq.db_numa_node = mlx5e_get_node(c->priv, c->ix);
+	param->wq.db_numa_node = cpu_to_node(c->cpu);
 	err = mlx5_wq_cyc_create(mdev, &param->wq, sqc_wq, &sq->wq, &sq->wq_ctrl);
 	if (err)
 		return err;
 	sq->wq.db = &sq->wq.db[MLX5_SND_DBR];
 
-	err = mlx5e_alloc_xdpsq_db(sq, mlx5e_get_node(c->priv, c->ix));
+	err = mlx5e_alloc_xdpsq_db(sq, cpu_to_node(c->cpu));
 	if (err)
 		goto err_sq_wq_destroy;
 
@@ -1060,13 +1053,13 @@ static int mlx5e_alloc_icosq(struct mlx5
 	sq->channel   = c;
 	sq->uar_map   = mdev->mlx5e_res.bfreg.map;
 
-	param->wq.db_numa_node = mlx5e_get_node(c->priv, c->ix);
+	param->wq.db_numa_node = cpu_to_node(c->cpu);
 	err = mlx5_wq_cyc_create(mdev, &param->wq, sqc_wq, &sq->wq, &sq->wq_ctrl);
 	if (err)
 		return err;
 	sq->wq.db = &sq->wq.db[MLX5_SND_DBR];
 
-	err = mlx5e_alloc_icosq_db(sq, mlx5e_get_node(c->priv, c->ix));
+	err = mlx5e_alloc_icosq_db(sq, cpu_to_node(c->cpu));
 	if (err)
 		goto err_sq_wq_destroy;
 
@@ -1132,13 +1125,13 @@ static int mlx5e_alloc_txqsq(struct mlx5
 	if (MLX5_IPSEC_DEV(c->priv->mdev))
 		set_bit(MLX5E_SQ_STATE_IPSEC, &sq->state);
 
-	param->wq.db_numa_node = mlx5e_get_node(c->priv, c->ix);
+	param->wq.db_numa_node = cpu_to_node(c->cpu);
 	err = mlx5_wq_cyc_create(mdev, &param->wq, sqc_wq, &sq->wq, &sq->wq_ctrl);
 	if (err)
 		return err;
 	sq->wq.db    = &sq->wq.db[MLX5_SND_DBR];
 
-	err = mlx5e_alloc_txqsq_db(sq, mlx5e_get_node(c->priv, c->ix));
+	err = mlx5e_alloc_txqsq_db(sq, cpu_to_node(c->cpu));
 	if (err)
 		goto err_sq_wq_destroy;
 
@@ -1510,8 +1503,8 @@ static int mlx5e_alloc_cq(struct mlx5e_c
 	struct mlx5_core_dev *mdev = c->priv->mdev;
 	int err;
 
-	param->wq.buf_numa_node = mlx5e_get_node(c->priv, c->ix);
-	param->wq.db_numa_node  = mlx5e_get_node(c->priv, c->ix);
+	param->wq.buf_numa_node = cpu_to_node(c->cpu);
+	param->wq.db_numa_node  = cpu_to_node(c->cpu);
 	param->eq_ix   = c->ix;
 
 	err = mlx5e_alloc_cq_common(mdev, param, cq);
@@ -1610,6 +1603,11 @@ static void mlx5e_close_cq(struct mlx5e_
 	mlx5e_free_cq(cq);
 }
 
+static int mlx5e_get_cpu(struct mlx5e_priv *priv, int ix)
+{
+	return cpumask_first(priv->mdev->priv.irq_info[ix].mask);
+}
+
 static int mlx5e_open_tx_cqs(struct mlx5e_channel *c,
 			     struct mlx5e_params *params,
 			     struct mlx5e_channel_param *cparam)
@@ -1758,12 +1756,13 @@ static int mlx5e_open_channel(struct mlx
 {
 	struct mlx5e_cq_moder icocq_moder = {0, 0};
 	struct net_device *netdev = priv->netdev;
+	int cpu = mlx5e_get_cpu(priv, ix);
 	struct mlx5e_channel *c;
 	unsigned int irq;
 	int err;
 	int eqn;
 
-	c = kzalloc_node(sizeof(*c), GFP_KERNEL, mlx5e_get_node(priv, ix));
+	c = kzalloc_node(sizeof(*c), GFP_KERNEL, cpu_to_node(cpu));
 	if (!c)
 		return -ENOMEM;
 
@@ -1771,6 +1770,7 @@ static int mlx5e_open_channel(struct mlx
 	c->mdev     = priv->mdev;
 	c->tstamp   = &priv->tstamp;
 	c->ix       = ix;
+	c->cpu      = cpu;
 	c->pdev     = &priv->mdev->pdev->dev;
 	c->netdev   = priv->netdev;
 	c->mkey_be  = cpu_to_be32(priv->mdev->mlx5e_res.mkey.key);
@@ -1859,8 +1859,7 @@ static void mlx5e_activate_channel(struc
 	for (tc = 0; tc < c->num_tc; tc++)
 		mlx5e_activate_txqsq(&c->sq[tc]);
 	mlx5e_activate_rq(&c->rq);
-	netif_set_xps_queue(c->netdev,
-		mlx5_get_vector_affinity(c->priv->mdev, c->ix), c->ix);
+	netif_set_xps_queue(c->netdev, get_cpu_mask(c->cpu), c->ix);
 }
 
 static void mlx5e_deactivate_channel(struct mlx5e_channel *c)
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -316,9 +316,6 @@ static int mlx5_alloc_irq_vectors(struct
 {
 	struct mlx5_priv *priv = &dev->priv;
 	struct mlx5_eq_table *table = &priv->eq_table;
-	struct irq_affinity irqdesc = {
-		.pre_vectors = MLX5_EQ_VEC_COMP_BASE,
-	};
 	int num_eqs = 1 << MLX5_CAP_GEN(dev, log_max_eq);
 	int nvec;
 
@@ -332,10 +329,9 @@ static int mlx5_alloc_irq_vectors(struct
 	if (!priv->irq_info)
 		goto err_free_msix;
 
-	nvec = pci_alloc_irq_vectors_affinity(dev->pdev,
+	nvec = pci_alloc_irq_vectors(dev->pdev,
 			MLX5_EQ_VEC_COMP_BASE + 1, nvec,
-			PCI_IRQ_MSIX | PCI_IRQ_AFFINITY,
-			&irqdesc);
+			PCI_IRQ_MSIX);
 	if (nvec < 0)
 		return nvec;
 
@@ -621,6 +617,63 @@ u64 mlx5_read_internal_timer(struct mlx5
 	return (u64)timer_l | (u64)timer_h1 << 32;
 }
 
+static int mlx5_irq_set_affinity_hint(struct mlx5_core_dev *mdev, int i)
+{
+	struct mlx5_priv *priv  = &mdev->priv;
+	int irq = pci_irq_vector(mdev->pdev, MLX5_EQ_VEC_COMP_BASE + i);
+
+	if (!zalloc_cpumask_var(&priv->irq_info[i].mask, GFP_KERNEL)) {
+		mlx5_core_warn(mdev, "zalloc_cpumask_var failed");
+		return -ENOMEM;
+	}
+
+	cpumask_set_cpu(cpumask_local_spread(i, priv->numa_node),
+			priv->irq_info[i].mask);
+
+	if (IS_ENABLED(CONFIG_SMP) &&
+	    irq_set_affinity_hint(irq, priv->irq_info[i].mask))
+		mlx5_core_warn(mdev, "irq_set_affinity_hint failed, irq 0x%.4x", irq);
+
+	return 0;
+}
+
+static void mlx5_irq_clear_affinity_hint(struct mlx5_core_dev *mdev, int i)
+{
+	struct mlx5_priv *priv  = &mdev->priv;
+	int irq = pci_irq_vector(mdev->pdev, MLX5_EQ_VEC_COMP_BASE + i);
+
+	irq_set_affinity_hint(irq, NULL);
+	free_cpumask_var(priv->irq_info[i].mask);
+}
+
+static int mlx5_irq_set_affinity_hints(struct mlx5_core_dev *mdev)
+{
+	int err;
+	int i;
+
+	for (i = 0; i < mdev->priv.eq_table.num_comp_vectors; i++) {
+		err = mlx5_irq_set_affinity_hint(mdev, i);
+		if (err)
+			goto err_out;
+	}
+
+	return 0;
+
+err_out:
+	for (i--; i >= 0; i--)
+		mlx5_irq_clear_affinity_hint(mdev, i);
+
+	return err;
+}
+
+static void mlx5_irq_clear_affinity_hints(struct mlx5_core_dev *mdev)
+{
+	int i;
+
+	for (i = 0; i < mdev->priv.eq_table.num_comp_vectors; i++)
+		mlx5_irq_clear_affinity_hint(mdev, i);
+}
+
 int mlx5_vector2eqn(struct mlx5_core_dev *dev, int vector, int *eqn,
 		    unsigned int *irqn)
 {
@@ -1093,6 +1146,12 @@ static int mlx5_load_one(struct mlx5_cor
 		goto err_stop_eqs;
 	}
 
+	err = mlx5_irq_set_affinity_hints(dev);
+	if (err) {
+		dev_err(&pdev->dev, "Failed to alloc affinity hint cpumask\n");
+		goto err_affinity_hints;
+	}
+
 	err = mlx5_init_fs(dev);
 	if (err) {
 		dev_err(&pdev->dev, "Failed to init flow steering\n");
@@ -1150,6 +1209,9 @@ err_sriov:
 	mlx5_cleanup_fs(dev);
 
 err_fs:
+	mlx5_irq_clear_affinity_hints(dev);
+
+err_affinity_hints:
 	free_comp_eqs(dev);
 
 err_stop_eqs:
@@ -1218,6 +1280,7 @@ static int mlx5_unload_one(struct mlx5_c
 
 	mlx5_sriov_detach(dev);
 	mlx5_cleanup_fs(dev);
+	mlx5_irq_clear_affinity_hints(dev);
 	free_comp_eqs(dev);
 	mlx5_stop_eqs(dev);
 	mlx5_put_uars_page(dev, priv->uar);
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -546,6 +546,7 @@ struct mlx5_core_sriov {
 };
 
 struct mlx5_irq_info {
+	cpumask_var_t mask;
 	char name[MLX5_MAX_IRQ_NAME];
 };
 


Patches currently in stable-queue which might be from saeedm@mellanox.com are

queue-4.14/net-mlx5-fix-rate-limit-packet-pacing-naming-and-struct.patch
queue-4.14/revert-mlx5-move-affinity-hints-assignments-to-generic-code.patch
queue-4.14/net-mlx5-fpga-return-einval-if-size-is-zero.patch
queue-4.14/net-mlx5e-fix-possible-deadlock-of-vxlan-lock.patch
queue-4.14/net-mlx5e-prevent-possible-races-in-vxlan-control-flow.patch
queue-4.14/net-mlx5-fix-error-flow-in-create_qp-command.patch
queue-4.14/net-mlx5e-add-refcount-to-vxlan-structure.patch
queue-4.14/net-mlx5e-fix-features-check-of-ipv6-traffic.patch

Re: Patch "Revert "mlx5: move affinity hints assignments to generic code"" has been added to the 4.14-stable tree

[Sagi Grimberg]

> This is a note to let you know that I've just added the patch titled
> 
>      Revert "mlx5: move affinity hints assignments to generic code"
> 
> to the 4.14-stable tree which can be found at:
>      http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> 
> The filename of the patch is:
>       revert-mlx5-move-affinity-hints-assignments-to-generic-code.patch
> and it can be found in the queue-4.14 subdirectory.
> 
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.

This patch in its current form, breaks nvme-rdma affinity settings. I've
mentioned that in the patch review and Saeed promised to send a fix for
it (which I haven't seen so far).

Saeed?

Re: Patch "Revert "mlx5: move affinity hints assignments to generic code"" has been added to the 4.14-stable tree

[Greg KH]

On Sun, Dec 31, 2017 at 12:47:57PM +0200, Sagi Grimberg wrote:
> 
> > This is a note to let you know that I've just added the patch titled
> > 
> >      Revert "mlx5: move affinity hints assignments to generic code"
> > 
> > to the 4.14-stable tree which can be found at:
> >      http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> > 
> > The filename of the patch is:
> >       revert-mlx5-move-affinity-hints-assignments-to-generic-code.patch
> > and it can be found in the queue-4.14 subdirectory.
> > 
> > If you, or anyone else, feels it should not be added to the stable tree,
> > please let <stable@vger.kernel.org> know about it.
> 
> This patch in its current form, breaks nvme-rdma affinity settings. I've
> mentioned that in the patch review and Saeed promised to send a fix for
> it (which I haven't seen so far).

So things are broken in Linus's tree?

Usually reverting is the safe thing to do, we should just be now back at
the state the code was in before the patch, or has something else
changed here?

thanks,

greg k-h

Re: Patch "Revert "mlx5: move affinity hints assignments to generic code"" has been added to the 4.14-stable tree

[Sagi Grimberg]

> So things are broken in Linus's tree?

I wasn't aware that this landed in Linus tree.

CC'ing DaveM.

> Usually reverting is the safe thing to do, we should just be now back at
> the state the code was in before the patch, or has something else
> changed here?

The patch title is misleading, its not a revert, but rather a partial
unwind of code addition. The breakage lives on the RDMA interface of
the driver (which has interfaces to net and infiniband) as some RDMA
kernel consumers are relying on the affinity assignments done when
passing PCI_IRQ_AFFINITY to pci_alloc_irq_vectors(). The fix is pretty
simple, but as said, wasn't submitted yet.

I assume that this went in because the review came a after dave took it.

Re: Patch "Revert "mlx5: move affinity hints assignments to generic code"" has been added to the 4.14-stable tree

[Greg KH]

On Sun, Dec 31, 2017 at 01:37:53PM +0200, Sagi Grimberg wrote:
> 
> > So things are broken in Linus's tree?
> 
> I wasn't aware that this landed in Linus tree.

That's the only way it would show up in the stable tree :)

Please work on resolving this upstream and I will be glad to take
whatever patch happens there in the stable tree afterward.

thanks,

greg k-h

Re: Patch "Revert "mlx5: move affinity hints assignments to generic code"" has been added to the 4.14-stable tree

[Sagi Grimberg]

>>> So things are broken in Linus's tree?
>>
>> I wasn't aware that this landed in Linus tree.
> 
> That's the only way it would show up in the stable tree :)

I know, was just expressing my surprise..

> Please work on resolving this upstream and I will be glad to take
> whatever patch happens there in the stable tree afterward.

Saeed, are you submitting a patch for this or should I?

Re: Patch "Revert "mlx5: move affinity hints assignments to generic code"" has been added to the 4.14-stable tree

[Saeed Mahameed]

On 12/31/2017 3:37 AM, Sagi Grimberg wrote:
> 
>> So things are broken in Linus's tree?
> 
> I wasn't aware that this landed in Linus tree.
> 
> CC'ing DaveM.
> 
>> Usually reverting is the safe thing to do, we should just be now back at
>> the state the code was in before the patch, or has something else
>> changed here?
> 
> The patch title is misleading, its not a revert, but rather a partial
> unwind of code addition. The breakage lives on the RDMA interface of

Hi Sagi,

The commit message perfectly states that this revert is slightly 
modified to keep compilation work, it is not partial.

> the driver (which has interfaces to net and infiniband) as some RDMA
> kernel consumers are relying on the affinity assignments done when
> passing PCI_IRQ_AFFINITY to pci_alloc_irq_vectors(). The fix is pretty
> simple, but as said, wasn't submitted yet.
> 
> I assume that this went in because the review came a after dave took it.


We had two options here
1. revert the whole series that introduced the vector affinity 
infrastructure for RDMA.
2. revert only mlx5 core patch "mlx5: move affinity hints assignments to 
generic code" with a little change to make it compile with the RDMA 
infrastructure.

I believe the required fix on top of this revert is to remove the RDMA 
get_vector_affinity callback from mlx5_ib ib_dev structurem, see below.

I can send it, All i need to know is to where ?
It should go through rdma-rc tree, if there is such thing ?

diff --git a/drivers/infiniband/hw/mlx5/main.c 
b/drivers/infiniband/hw/mlx5/main.c
index 5d6fba986fa5..ddd0b881a4be 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -4256,14 +4256,6 @@ static void init_delay_drop(struct mlx5_ib_dev *dev)
                 mlx5_ib_warn(dev, "Failed to init delay drop debugfs\n");
  }

-static const struct cpumask *
-mlx5_ib_get_vector_affinity(struct ib_device *ibdev, int comp_vector)
-{
-       struct mlx5_ib_dev *dev = to_mdev(ibdev);
-
-       return mlx5_get_vector_affinity(dev->mdev, comp_vector);
-}
-
  /* The mlx5_ib_multiport_mutex should be held when calling this 
function */
  static void mlx5_ib_unbind_slave_port(struct mlx5_ib_dev *ibdev,
                                       struct mlx5_ib_multiport_info *mpi)
@@ -4632,7 +4624,6 @@ static int mlx5_ib_stage_caps_init(struct 
mlx5_ib_dev *dev)
         dev->ib_dev.check_mr_status     = mlx5_ib_check_mr_status;
         dev->ib_dev.get_port_immutable  = mlx5_port_immutable;
         dev->ib_dev.get_dev_fw_str      = get_dev_fw_str;
-       dev->ib_dev.get_vector_affinity = mlx5_ib_get_vector_affinity;
         if (MLX5_CAP_GEN(mdev, ipoib_enhanced_offloads))
                 dev->ib_dev.alloc_rdma_netdev   = 
mlx5_ib_alloc_rdma_netdev;

Re: Patch "Revert "mlx5: move affinity hints assignments to generic code"" has been added to the 4.14-stable tree

[Saeed Mahameed]

On 12/31/2017 4:00 AM, Sagi Grimberg wrote:
> 
>>>> So things are broken in Linus's tree?
>>>
>>> I wasn't aware that this landed in Linus tree.
>>
>> That's the only way it would show up in the stable tree :)
> 
> I know, was just expressing my surprise..
> 
>> Please work on resolving this upstream and I will be glad to take
>> whatever patch happens there in the stable tree afterward.
> 
> Saeed, are you submitting a patch for this or should I?

Yes, I will submit the fix this week I will CC you and Greg, so you will 
ack it.

Thanks,
Saeed.

Re: Patch "Revert "mlx5: move affinity hints assignments to generic code"" has been added to the 4.14-stable tree

[Saeed Mahameed]

On 1/3/2018 1:59 PM, Saeed Mahameed wrote:
> 
> 
> On 12/31/2017 3:37 AM, Sagi Grimberg wrote:
>>
>>> So things are broken in Linus's tree?
>>
>> I wasn't aware that this landed in Linus tree.
>>
>> CC'ing DaveM.
>>
>>> Usually reverting is the safe thing to do, we should just be now back at
>>> the state the code was in before the patch, or has something else
>>> changed here?
>>
>> The patch title is misleading, its not a revert, but rather a partial
>> unwind of code addition. The breakage lives on the RDMA interface of
> 
> Hi Sagi,
> 
> The commit message perfectly states that this revert is slightly 
> modified to keep compilation work, it is not partial.
> 
>> the driver (which has interfaces to net and infiniband) as some RDMA
>> kernel consumers are relying on the affinity assignments done when
>> passing PCI_IRQ_AFFINITY to pci_alloc_irq_vectors(). The fix is pretty
>> simple, but as said, wasn't submitted yet.
>>
>> I assume that this went in because the review came a after dave took it.
> 
> 
> We had two options here
> 1. revert the whole series that introduced the vector affinity 
> infrastructure for RDMA.
> 2. revert only mlx5 core patch "mlx5: move affinity hints assignments to 
> generic code" with a little change to make it compile with the RDMA 
> infrastructure.
> 
> I believe the required fix on top of this revert is to remove the RDMA 
> get_vector_affinity callback from mlx5_ib ib_dev structurem, see below.
> 
> I can send it, All i need to know is to where ?
> It should go through rdma-rc tree, if there is such thing ?
> 
> diff --git a/drivers/infiniband/hw/mlx5/main.c 
> b/drivers/infiniband/hw/mlx5/main.c
> index 5d6fba986fa5..ddd0b881a4be 100644
> --- a/drivers/infiniband/hw/mlx5/main.c
> +++ b/drivers/infiniband/hw/mlx5/main.c
> @@ -4256,14 +4256,6 @@ static void init_delay_drop(struct mlx5_ib_dev *dev)
>                  mlx5_ib_warn(dev, "Failed to init delay drop debugfs\n");
>   }
> 
> -static const struct cpumask *
> -mlx5_ib_get_vector_affinity(struct ib_device *ibdev, int comp_vector)
> -{
> -       struct mlx5_ib_dev *dev = to_mdev(ibdev);
> -
> -       return mlx5_get_vector_affinity(dev->mdev, comp_vector);
> -}
> -

Oh, I just remembered that I had suggested to use
cpumask_first(mdev->priv.irq_info[vector].mask);
instead of the current broken implementation in mlx5,
I see that you agreed to test it in another email thread.

I will send a patch very soon, but someone has to test it ASAP so we 
don't miss 4.15.

>   /* The mlx5_ib_multiport_mutex should be held when calling this 
> function */
>   static void mlx5_ib_unbind_slave_port(struct mlx5_ib_dev *ibdev,
>                                        struct mlx5_ib_multiport_info *mpi)
> @@ -4632,7 +4624,6 @@ static int mlx5_ib_stage_caps_init(struct 
> mlx5_ib_dev *dev)
>          dev->ib_dev.check_mr_status     = mlx5_ib_check_mr_status;
>          dev->ib_dev.get_port_immutable  = mlx5_port_immutable;
>          dev->ib_dev.get_dev_fw_str      = get_dev_fw_str;
> -       dev->ib_dev.get_vector_affinity = mlx5_ib_get_vector_affinity;
>          if (MLX5_CAP_GEN(mdev, ipoib_enhanced_offloads))
>                  dev->ib_dev.alloc_rdma_netdev   = 
> mlx5_ib_alloc_rdma_netdev;
>