On 17.04.23 20:17, Lorenzo Bianconi wrote:
On Mon, Apr 17, 2023 at 7:53 PM Lorenzo Bianconi <lorenzo@xxxxxxxxxx> wrote:
Hi all,
I am triggering an issue with a device running the page_pool allocator.
In particular, the device is running an iperf tcp server receiving traffic
from a remote client. On the driver I loaded a simple xdp program returning
xdp_pass. When I remove the ebpf program and destroy the pool, page_pool
allocator starts complaining in page_pool_release_retry() that not all the pages
have been returned to the allocator. In fact, the pool is not really destroyed
in this case.
Debugging the code it seems the pages are stuck softnet_data defer_list and
they are never freed in skb_defer_free_flush() since I do not have any more tcp
traffic. To prove it, I tried to set sysctl_skb_defer_max to 0 and the issue
does not occur.
I developed the poc patch below and the issue seems to be fixed:
I do not see why this would be different than having buffers sitting
in some tcp receive
(or out or order) queues for a few minutes ?
The main issue in my tests (and even in mt76 I think) is the pages are not returned
to the pool for a very long time (even hours) and doing so the pool is like in a
'limbo' state where it is not actually deallocated and page_pool_release_retry
continues complaining about it. I think this is because we do not have more tcp
traffic to deallocate them, but I am not so familiar with tcp codebase :)
Regards,
Lorenzo
Or buffers transferred to another socket or pipe (splice() and friends)
I'm not absolutely sure that it is the same problem, but I also saw some
problems with page_pool destroying and page_pool_release_retry(). I did
post it, but I did not get any reply:
https://lore.kernel.org/bpf/20230311213709.42625-1-gerhard@xxxxxxxxxxxxxxxxxxxxx/T/
Could this be a similar issue?
Gerhard
