[RFC] net/mlx5_core/en_main: Remove deprecated create_workqueue

alloc_ordered_workqueue() with WQ_MEM_RECLAIM set replaces
deprecated create_singlethread_workqueue(). This is the identity
conversion.

A dedicated workqueue has been used since mlx5e workqueue was created to
handle all mlx5e specific tasks. This is in preparation for vxlan using
the mlx5e workqueue in order to schedule port add/remove operations.
WQ_MEM_RECLAIM has been set to guarantee forward progress under memory
pressure.

Can the workitems be executed concurrently?
Are the workitems being used on a memory reclaim path?

Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--
2.1.4

On Wed, Jul 27, 2016 at 9:12 AM, Bhaktipriya Shridhar
<bhaktipriya96@gmail.com> wrote:
> alloc_ordered_workqueue() with WQ_MEM_RECLAIM set replaces
> deprecated create_singlethread_workqueue(). This is the identity
> conversion.
>
> A dedicated workqueue has been used since mlx5e workqueue was created to
> handle all mlx5e specific tasks. This is in preparation for vxlan using
> the mlx5e workqueue in order to schedule port add/remove operations.
> WQ_MEM_RECLAIM has been set to guarantee forward progress under memory
> pressure.
>
> Can the workitems be executed concurrently?

well, the work items that currently using the mlx5e WQ are:

priv->update_carrier_work : Read hardware link state and update netdev carrier
priv->update_stats_work: a periodic task that runs once every 1/4 sec
to update netdev statistics.
priv->set_rx_mode_work: A task queued from netdev set_rx_mdoe/set_mac
NDOs and sometimes explicitly from driver to update netdev RX mode and
filters.
mlx5e_vxlan_queue_work: Queue a _dynamically_ created workitem to
add/rem vxlan port, those tasks must not be executed concurrently
-since they are dynamically- allocated to gurantee add/remove
ordering.

bottom line, I wouldn't change concurrency of the mlx5e work queue.

> Are the workitems being used on a memory reclaim path?

do you mean they need to allocate memory ?

> Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
> ---
>  drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index fd43929..1a96445 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -3042,7 +3042,7 @@ static void *mlx5e_create_netdev(struct mlx5_core_dev *mdev)
>
>         priv = netdev_priv(netdev);
>
> -       priv->wq = create_singlethread_workqueue("mlx5e");
> +       priv->wq = alloc_ordered_workqueue("mlx5e", WQ_MEM_RECLAIM);
>         if (!priv->wq)
>                 goto err_free_netdev;
>
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hello,

On Fri, Jul 29, 2016 at 01:30:05AM +0300, Saeed Mahameed wrote:
> > Are the workitems being used on a memory reclaim path?
> 
> do you mean they need to allocate memory ?

It's a bit convoluted.  A workqueue needs WQ_MEM_RECLAIM flag to be
guaranteed forward progress under memory pressure, so any workqueue
which may be depended upon during memory reclaim should have the flag
set; otherwise, the system can deadlock (try to reclaim memory, hits
the wq which can't make forward progress due to lack of memory).  For
network devices, the requirement comes from block-over-network or nfs
which can be involved in memory reclaim.

Thanks.