All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ratheesh Kannoth <rkannoth@marvell.com>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
	<pabeni@redhat.com>
Subject: Re: [RFC]Page pool buffers stuck in App's socket queue
Date: Tue, 17 Jun 2025 14:08:42 +0530	[thread overview]
Message-ID: <20250617083842.GA417272@maili.marvell.com> (raw)
In-Reply-To: <d152d5fa-e846-48ba-96f4-77493996d099@huawei.com>

On 2025-06-17 at 12:03:41, Yunsheng Lin (linyunsheng@huawei.com) wrote:
> > Customer was asking us for a mechanism to drain these sockets, as they dont want to kill their Apps.
> > The proposal is to have debugfs which shows "pid  last_processed_skb_time  number_of_packets  socket_fd/inode_number"
> > for each raw6/raw4 sockets created in the system. and
> > any write to the debugfs (any specific command) will drain the socket.
> >
> > 1. Could you please comment on the proposal ?
>
> I would say the above is kind of working around the problem.
> It would be good to fix the Apps or fix the page_pool.
>
> > 2. Could you suggest a better way ?
>
> For fixing the page_pool part, I would be suggesting to keep track
> of all the inflight pages and detach those pages from page_pool when
> page_pool_destroy() is called, the tracking part was [1], unfortunately
> the maintainers seemed to choose an easy way instead of a long term
> direction, see [2].
>
> 1. https://lore.kernel.org/all/20250307092356.638242-1-linyunsheng@huawei.com/
> 2. https://lore.kernel.org/all/20250409-page-pool-track-dma-v9-0-6a9ef2e0cba8@redhat.com/

i think, both issues are different. Above links, fixes late DMA unmap issue. In my case,
buffers do not return at all. So some entity should purge those socket queues which are not getting
processed. App modification would be difficult as customer may use opensource Apps/third party apps.

Buffers are stuck in socket queue. And we need to free them. Page pool infra tracking socket queue and
process information would be an over kill ? And packets in socket queue of a process, being freed from page pool wont
work well. (That app could be killed later, causing skbs to be freed. or we dont know whether App processing socket queue
is slow).

I was thinking of extending /proc/net/raw and /proc/net/raw6 OR creating similar proc entries; which
can show "pid and timestamp of first skb in the queue" etc. And a .proc_write() function to purge a
specifc socket queue. Using these, customer can decide which queue is stuck and purge manualy (thru some script) after
netdevice down/up.

  reply	other threads:[~2025-06-17  8:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-16  8:05 [RFC]Page pool buffers stuck in App's socket queue Ratheesh Kannoth
2025-06-17  6:33 ` Yunsheng Lin
2025-06-17  8:38   ` Ratheesh Kannoth [this message]
2025-06-17 21:02   ` Mina Almasry
2025-06-18  6:33     ` Yunsheng Lin
2025-06-17 21:00 ` Mina Almasry
2025-06-18  7:28   ` Ratheesh Kannoth
2025-06-17 21:56 ` Lorenzo Bianconi
2025-06-18  6:42   ` Ratheesh Kannoth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250617083842.GA417272@maili.marvell.com \
    --to=rkannoth@marvell.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linyunsheng@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.