Re: [PATCH] net: core: page_pool: add user refcnt and reintroduce page_pool_destroy
From: Jesper Dangaard Brouer <hidden>
Date: 2019-07-02 18:29:22
Also in:
linux-omap, lkml
On Tue, 2 Jul 2019 18:21:13 +0300 Ivan Khoronzhuk [off-list ref] wrote:
On Tue, Jul 02, 2019 at 05:10:29PM +0200, Jesper Dangaard Brouer wrote:quoted
On Tue, 2 Jul 2019 17:56:13 +0300 Ivan Khoronzhuk [off-list ref] wrote:quoted
On Tue, Jul 02, 2019 at 04:52:30PM +0200, Jesper Dangaard Brouer wrote:quoted
On Tue, 2 Jul 2019 17:44:27 +0300 Ivan Khoronzhuk [off-list ref] wrote:quoted
On Tue, Jul 02, 2019 at 04:31:39PM +0200, Jesper Dangaard Brouer wrote:quoted
From: Ivan Khoronzhuk <redacted> Jesper recently removed page_pool_destroy() (from driver invocation) and moved shutdown and free of page_pool into xdp_rxq_info_unreg(), in-order to handle in-flight packets/pages. This created an asymmetry in drivers create/destroy pairs. This patch add page_pool user refcnt and reintroduce page_pool_destroy. This serves two purposes, (1) simplify drivers error handling as driver now drivers always calls page_pool_destroy() and don't need to track if xdp_rxq_info_reg_mem_model() was unsuccessful. (2) allow special cases where a single RX-queue (with a single page_pool) provides packets for two net_device'es, and thus needs to register the same page_pool twice with two xdp_rxq_info structures.As I tend to use xdp level patch there is no more reason to mention (2) case here. XDP patch serves it better and can prevent not only obj deletion but also pool flush, so, this one patch I could better leave only for (1) case.I don't understand what you are saying. Do you approve this patch, or do you reject this patch?It's not reject, it's proposition to use both, XDP and page pool patches, each having its goal.Just to be clear, if you want this patch to get accepted you have to reply with your Signed-off-by (as I wrote). Maybe we should discuss it in another thread, about why you want two solutions to the same problem.If it solves same problem I propose to reject this one and use this: https://lkml.org/lkml/2019/7/2/651
No, I propose using this one, and rejecting the other one. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer