All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Fomichev <stfomichev@gmail.com>
To: Jordan Rife <jordan@jrife.io>
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>
Subject: Re: [RESEND PATCH v2 bpf-next 02/12] bpf: tcp: Make sure iter->batch always contains a full bucket snapshot
Date: Mon, 23 Jun 2025 14:36:05 -0700	[thread overview]
Message-ID: <aFnIxcsROSNowexy@mini-arch> (raw)
In-Reply-To: <CABi4-ohShEVsXfNhMBHqsBFJ4NQUP9zq_Pq26WvFNohjoWFj9g@mail.gmail.com>

On 06/23, Jordan Rife wrote:
> > Untested code to illustrate the idea below. Any reason it won't work?
> 
> In theory, I like the idea of unrolling the code a bit here to make
> the flow more clear (and to make it clear what's happening to the
> locks!). IIRC there was some reason this was hard, but I will think
> about it a bit again.
> 
> I also want to make sure things stay relatively consistent between the
> UDP and TCP socket iterator code structure. The UDP socket iterators
> already do the `goto fill_batch` and `goto again` thing, which is
> where I borrowed this from. If we end up diverging here, I'd want to
> go back and update the UDP code as well.
> 
> Thanks for the suggestion. I'll take a closer look a bit later and see
> if I can work this in. In the meantime, hopefully Martin can chime in
> as well. We went back and forth on the code structure quite a bit in
> the patch series for UDP socket iterators, so he might have some
> opinions here.

Martin is OOO so you'll have to wait a bit for his feedback.
UDP iterator seems to be more low level to me (with explicit locking),
so maybe all this non-unrolled retry logic there is justified, but
I haven't looked too deep.

  reply	other threads:[~2025-06-23 21:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-18 16:25 [RESEND PATCH v2 bpf-next 00/12] bpf: tcp: Exactly-once socket iteration Jordan Rife
2025-06-18 16:25 ` [RESEND PATCH v2 bpf-next 01/12] bpf: tcp: Make mem flags configurable through bpf_iter_tcp_realloc_batch Jordan Rife
2025-06-18 16:25 ` [RESEND PATCH v2 bpf-next 02/12] bpf: tcp: Make sure iter->batch always contains a full bucket snapshot Jordan Rife
2025-06-18 18:44   ` Stanislav Fomichev
2025-06-23 18:50     ` Jordan Rife
2025-06-23 21:36       ` Stanislav Fomichev [this message]
2025-06-24 19:49     ` Jordan Rife
2025-06-18 16:25 ` [RESEND PATCH v2 bpf-next 03/12] bpf: tcp: Get rid of st_bucket_done Jordan Rife
2025-06-18 16:25 ` [RESEND PATCH v2 bpf-next 04/12] bpf: tcp: Use bpf_tcp_iter_batch_item for bpf_tcp_iter_state batch items Jordan Rife
2025-06-18 16:25 ` [RESEND PATCH v2 bpf-next 05/12] bpf: tcp: Avoid socket skips and repeats during iteration Jordan Rife
2025-06-18 16:25 ` [RESEND PATCH v2 bpf-next 06/12] selftests/bpf: Add tests for bucket resume logic in listening sockets Jordan Rife
2025-06-18 16:25 ` [RESEND PATCH v2 bpf-next 07/12] selftests/bpf: Allow for iteration over multiple ports Jordan Rife
2025-06-18 16:25 ` [RESEND PATCH v2 bpf-next 08/12] selftests/bpf: Allow for iteration over multiple states Jordan Rife
2025-06-18 16:25 ` [RESEND PATCH v2 bpf-next 09/12] selftests/bpf: Make ehash buckets configurable in socket iterator tests Jordan Rife
2025-06-18 16:25 ` [RESEND PATCH v2 bpf-next 10/12] selftests/bpf: Create established sockets " Jordan Rife
2025-06-18 16:25 ` [RESEND PATCH v2 bpf-next 11/12] selftests/bpf: Create iter_tcp_destroy test program Jordan Rife
2025-06-18 16:25 ` [RESEND PATCH v2 bpf-next 12/12] selftests/bpf: Add tests for bucket resume logic in established sockets 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=aFnIxcsROSNowexy@mini-arch \
    --to=stfomichev@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jordan@jrife.io \
    --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.