On 19/09/2024 13.15, Yunsheng Lin wrote:
On 2024/9/19 17:42, Jesper Dangaard Brouer wrote:
On 18/09/2024 19.06, Ilias Apalodimas wrote:
In order not to do the dma unmmapping after driver has already
unbound and stall the unloading of the networking driver, add
the pool->items array to record all the pages including the ones
which are handed over to network stack, so the page_pool can
do the dma unmmapping for those pages when page_pool_destroy()
is called.
So, I was thinking of a very similar idea. But what do you mean by
"all"? The pages that are still in caches (slow or fast) of the pool
will be unmapped during page_pool_destroy().
I really dislike this idea of having to keep track of all outstanding pages.
I liked Jakub's idea of keeping the netdev around for longer.
This is all related to destroying the struct device that have points to
the DMA engine, right?
Yes, the problem seems to be that when device_del() is called, there is
no guarantee hw behind the 'struct device ' will be usable even if we
call get_device() on it.
Why don't we add an API that allow netdev to "give" struct device to
page_pool. And then the page_poll will take over when we can safely
free the stuct device?
By 'allow netdev to "give" struct device to page_pool', does it mean
page_pool become the driver for the device?
If yes, it seems that is similar to jakub's idea, as both seems to stall
the calling of device_del() by not returning when the driver unloading.
Yes, this is what I mean. (That is why I mentioned Jakub's idea).
If no, it seems that the problem is still existed when the driver for
the device has unbound after device_del() is called.
