> 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? I am not sure too. In order to prove it is the same issue, I would say you can try to run the test applying my poc patch or setting sysctl_skb_defer_max to 0. Regards, Lorenzo > > Gerhard
Attachment:
signature.asc
Description: PGP signature
