Message-ID: <20190626123920.GG6485@khorivan>
Date:   Wed, 26 Jun 2019 15:39:22 +0300
From:   Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     davem@...emloft.net, grygorii.strashko@...com, saeedm@...lanox.com,
        leon@...nel.org, ast@...nel.org, linux-kernel@...r.kernel.org,
        linux-omap@...r.kernel.org, ilias.apalodimas@...aro.org,
        netdev@...r.kernel.org, daniel@...earbox.net,
        jakub.kicinski@...ronome.com, john.fastabend@...il.com
Subject: Re: [PATCH v4 net-next 1/4] net: core: page_pool: add user cnt
 preventing pool deletion

On Wed, Jun 26, 2019 at 01:51:28PM +0200, Jesper Dangaard Brouer wrote:
>On Wed, 26 Jun 2019 13:49:49 +0300
>Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org> wrote:
>
>> On Wed, Jun 26, 2019 at 12:42:16PM +0200, Jesper Dangaard Brouer wrote:
>> >On Tue, 25 Jun 2019 20:59:45 +0300
>> >Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org> wrote:
>> >
>> >> Add user counter allowing to delete pool only when no users.
>> >> It doesn't prevent pool from flush, only prevents freeing the
>> >> pool instance. Helps when no need to delete the pool and now
>> >> it's user responsibility to free it by calling page_pool_free()
>> >> while destroying procedure. It also makes to use page_pool_free()
>> >> explicitly, not fully hidden in xdp unreg, which looks more
>> >> correct after page pool "create" routine.
>> >
>> >No, this is wrong.
>> below.
>>
>> >
>> >> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org>
>> >> ---
>> >>  drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 8 +++++---
>> >>  include/net/page_pool.h                           | 7 +++++++
>> >>  net/core/page_pool.c                              | 7 +++++++
>> >>  net/core/xdp.c                                    | 3 +++
>> >>  4 files changed, 22 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> >> index 5e40db8f92e6..cb028de64a1d 100644
>> >> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> >> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> >> @@ -545,10 +545,8 @@ static int mlx5e_alloc_rq(struct mlx5e_channel *c,
>> >>  	}
>> >>  	err = xdp_rxq_info_reg_mem_model(&rq->xdp_rxq,
>> >>  					 MEM_TYPE_PAGE_POOL, rq->page_pool);
>> >> -	if (err) {
>> >> -		page_pool_free(rq->page_pool);
>> >> +	if (err)
>> >>  		goto err_free;
>> >> -	}
>> >>
>> >>  	for (i = 0; i < wq_sz; i++) {
>> >>  		if (rq->wq_type == MLX5_WQ_TYPE_LINKED_LIST_STRIDING_RQ) {
>> >> @@ -613,6 +611,8 @@ static int mlx5e_alloc_rq(struct mlx5e_channel *c,
>> >>  	if (rq->xdp_prog)
>> >>  		bpf_prog_put(rq->xdp_prog);
>> >>  	xdp_rxq_info_unreg(&rq->xdp_rxq);
>> >> +	if (rq->page_pool)
>> >> +		page_pool_free(rq->page_pool);
>> >>  	mlx5_wq_destroy(&rq->wq_ctrl);
>> >>
>> >>  	return err;
>> >> @@ -643,6 +643,8 @@ static void mlx5e_free_rq(struct mlx5e_rq *rq)
>> >>  	}
>> >>
>> >>  	xdp_rxq_info_unreg(&rq->xdp_rxq);
>> >> +	if (rq->page_pool)
>> >> +		page_pool_free(rq->page_pool);
>> >
>> >No, this is wrong.  The hole point with the merged page_pool fixes
>> >patchset was that page_pool_free() needs to be delayed until no-more
>> >in-flight packets exist.
>>
>> Probably it's not so obvious, but it's still delayed and deleted only
>> after no-more in-flight packets exist. Here question is only who is able
>> to do this first based on refcnt.
>
>Hmm... then I find this API is rather misleading, even the function
>name page_pool_free is misleading ("free"). (Now, I do see, below, that
>page_pool_create() take an extra reference).
In feneral "free" looks not bad after "create".
It's called after "create" if some error with registering it rxq.
and it looks logical, if it's called after no need in pool.

obj = create()
 /* a lot of different stuff */
free(obj);


>
>But it is still wrong / problematic.  As you allow
>__page_pool_request_shutdown() to be called with elevated refcnt.  Your
>use-case is to have more than 1 xdp_rxq_info struct using the same
>page_pool.  Then you have to call xdp_rxq_info_unreg_mem_model() for
>each, which will call __page_pool_request_shutdown().
>
>For this to be safe, your driver have to stop RX for all the
>xdp_rxq_info structs that share the page_pool.  The page_pool already
>have this requirement, but it comes as natural step when shutting down
>an RXQ.  With your change, you have to take care of stopping the RXQs
>first, and then call xdp_rxq_info_unreg_mem_model() for each
>xdp_rxq_info afterwards.  I assume you do this, but it is just a driver
>bug waiting to happen.
All rxq queues are stopped before this, and only after this the pools are freed,
exactly as it required for one xdp_rxq_info_unreg_mem_model(), w/o exclusions,
as it requires the API.

>
>> >> diff --git a/net/core/page_pool.c b/net/core/page_pool.c
>> >> index b366f59885c1..169b0e3c870e 100644
>> >> --- a/net/core/page_pool.c
>> >> +++ b/net/core/page_pool.c
>[...]
>> >> @@ -70,6 +71,8 @@ struct page_pool *page_pool_create(const struct page_pool_params *params)
>> >>  		kfree(pool);
>> >>  		return ERR_PTR(err);
>> >>  	}
>> >> +
>> >> +	page_pool_get(pool);
>> >>  	return pool;
>> >>  }
>> >>  EXPORT_SYMBOL(page_pool_create);
>
>The thing (perhaps) like about your API change, is that you also allow
>the driver to explicitly keep the page_pool object across/after a
>xdp_rxq_info_unreg_mem_model().  And this way possibly reuse it for
>another RXQ.
>The problem is of-cause that on driver shutdown, this
>will force drivers to implement the same shutdown logic with
>schedule_delayed_work as the core xdp.c code already does.
I see.

The cpsw dosn't re-use it, so here all is fine, but if a driver needs
to re-use it again, lets suppose, as it can happen, the pool needs to
be registered with xdp_rxq_info_reg_mem_model() again, and for that
potentially can be added verification on in-flight packets
or some register state...but better mention in some place
to not do this, frankly, I don't know where it should be at this moment.

-- 
Regards,
Ivan Khoronzhuk

Powered by blists - more mailing lists