From: Jordan Rife <jordan@jrife.io>
To: Kuniyuki Iwashima <kuniyu@amazon.com>
Cc: martin.lau@linux.dev, aditi.ghag@isovalent.com,
bpf@vger.kernel.org, daniel@iogearbox.net,
netdev@vger.kernel.org, willemdebruijn.kernel@gmail.com
Subject: Re: [PATCH v3 bpf-next 2/6] bpf: udp: Make sure iter->batch always contains a full bucket snapshot
Date: Thu, 17 Apr 2025 16:51:31 -0700 [thread overview]
Message-ID: <aAGUAztJqwnDQquo@t14> (raw)
In-Reply-To: <20250417233303.37489-1-kuniyu@amazon.com>
> > If I read it correctly, the last retry with GFP_ATOMIC is not because of the
> > earlier GFP_USER allocation failure but the size of the bucket has changed a lot
> > that it is doing one final attempt to get the whole bucket and this requires to
> > hold the bucket lock to ensure the size stays the same which then must use
> > GFP_ATOMIC.
>
> Ah exactly, when allocation fails, it always returned an error.
>
> Sorry, I should've read code first.
I was about to type out a response, but Martin beat me to it :). Yep,
GFP_ATOMIC is a necessary side-effect of holding onto the lock to make
sure the bucket doesn't grow anymore. It's a last resort to make sure
the batch size is big enough to grab a full bucket snapshot not a last
resort to allocate memory.
-Jordan
next prev parent reply other threads:[~2025-04-17 23:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-16 23:36 [PATCH v3 bpf-next 0/6] bpf: udp: Exactly-once socket iteration Jordan Rife
2025-04-16 23:36 ` [PATCH v3 bpf-next 1/6] bpf: udp: Make mem flags configurable through bpf_iter_udp_realloc_batch Jordan Rife
2025-04-17 23:35 ` Kuniyuki Iwashima
2025-04-16 23:36 ` [PATCH v3 bpf-next 2/6] bpf: udp: Make sure iter->batch always contains a full bucket snapshot Jordan Rife
2025-04-17 22:41 ` Kuniyuki Iwashima
2025-04-17 23:12 ` Martin KaFai Lau
2025-04-17 23:32 ` Kuniyuki Iwashima
2025-04-17 23:51 ` Jordan Rife [this message]
2025-04-17 23:45 ` Kuniyuki Iwashima
2025-04-17 23:57 ` Jordan Rife
2025-04-18 0:15 ` Kuniyuki Iwashima
2025-04-16 23:36 ` [PATCH v3 bpf-next 3/6] bpf: udp: Use bpf_udp_iter_batch_item for bpf_udp_iter_state batch items Jordan Rife
2025-04-16 23:36 ` [PATCH v3 bpf-next 4/6] bpf: udp: Avoid socket skips and repeats during iteration Jordan Rife
2025-04-16 23:36 ` [PATCH v3 bpf-next 5/6] selftests/bpf: Return socket cookies from sock_iter_batch progs Jordan Rife
2025-04-16 23:36 ` [PATCH v3 bpf-next 6/6] selftests/bpf: Add tests for bucket resume logic in UDP socket iterators Jordan Rife
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=aAGUAztJqwnDQquo@t14 \
--to=jordan@jrife.io \
--cc=aditi.ghag@isovalent.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kuniyu@amazon.com \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=willemdebruijn.kernel@gmail.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.