From: Martin KaFai Lau <martin.lau@linux.dev>
To: Aditi Ghag <aditi.ghag@isovalent.com>
Cc: kafai@fb.com, sdf@google.com, edumazet@google.com,
Martin KaFai Lau <martin.lau@kernel.org>,
bpf@vger.kernel.org
Subject: Re: [PATCH v5 bpf-next 4/7] bpf: udp: Implement batching for sockets iterator
Date: Fri, 31 Mar 2023 14:08:35 -0700 [thread overview]
Message-ID: <acdafa2f-b127-5a5a-84f7-0a046e1ce0fa@linux.dev> (raw)
In-Reply-To: <20230330151758.531170-5-aditi.ghag@isovalent.com>
On 3/30/23 8:17 AM, Aditi Ghag wrote:
> +static int bpf_iter_udp_realloc_batch(struct bpf_udp_iter_state *iter,
> + unsigned int new_batch_sz);
>
> static inline bool seq_sk_match(struct seq_file *seq, const struct sock *sk)
> {
> @@ -3151,6 +3163,149 @@ static inline bool seq_sk_match(struct seq_file *seq, const struct sock *sk)
> net_eq(sock_net(sk), seq_file_net(seq)));
> }
>
> +static struct sock *bpf_iter_udp_batch(struct seq_file *seq)
> +{
> + struct bpf_udp_iter_state *iter = seq->private;
> + struct udp_iter_state *state = &iter->state;
> + struct net *net = seq_file_net(seq);
> + struct sock *first_sk = NULL;
> + struct udp_seq_afinfo afinfo;
> + struct udp_table *udptable;
> + unsigned int batch_sks = 0;
> + bool resized = false;
> + struct sock *sk;
> + int offset = 0;
> + int new_offset;
> +
> + /* The current batch is done, so advance the bucket. */
> + if (iter->st_bucket_done) {
> + state->bucket++;
> + iter->offset = 0;
> + }
> +
> + afinfo.family = AF_UNSPEC;
> + afinfo.udp_table = NULL;
> + udptable = udp_get_table_afinfo(&afinfo, net);
> +
> + if (state->bucket > udptable->mask) {
This test looks unnecessary. The for-loop below should take care of this case?
> + state->bucket = 0;
Reset state->bucket here looks suspicious (or at least unnecessary) also. The
iterator cannot restart from the beginning. or I am missing something here? This
at least requires a comment if it is really needed.
> + iter->offset = 0;
> + return NULL;
> + }
> +
> +again:
> + /* New batch for the next bucket.
> + * Iterate over the hash table to find a bucket with sockets matching
> + * the iterator attributes, and return the first matching socket from
> + * the bucket. The remaining matched sockets from the bucket are batched
> + * before releasing the bucket lock. This allows BPF programs that are
> + * called in seq_show to acquire the bucket lock if needed.
> + */
> + iter->cur_sk = 0;
> + iter->end_sk = 0;
> + iter->st_bucket_done = false;
> + first_sk = NULL;
> + batch_sks = 0;
> + offset = iter->offset;
> +
> + for (; state->bucket <= udptable->mask; state->bucket++) {
> + struct udp_hslot *hslot2 = &udptable->hash2[state->bucket];
> +
> + if (hlist_empty(&hslot2->head)) {
> + offset = 0;
> + continue;
> + }
> + new_offset = offset;
> +
> + spin_lock_bh(&hslot2->lock);
> + udp_portaddr_for_each_entry(sk, &hslot2->head) {
> + if (seq_sk_match(seq, sk)) {
> + /* Resume from the last iterated socket at the
> + * offset in the bucket before iterator was stopped.
> + */
> + if (offset) {
> + --offset;
> + continue;
> + }
> + if (!first_sk)
> + first_sk = sk;
> + if (iter->end_sk < iter->max_sk) {
> + sock_hold(sk);
> + iter->batch[iter->end_sk++] = sk;
> + }
> + batch_sks++;
> + new_offset++;
> + }
> + }
> + spin_unlock_bh(&hslot2->lock);
> +
> + if (first_sk)
> + break;
> +
> + /* Reset the current bucket's offset before moving to the next bucket. */
> + offset = 0;
> + }
> +
> + /* All done: no batch made. */
> + if (!first_sk)
Testing !iter->end_sk should be the same?
> + goto ret;
> +
> + if (iter->end_sk == batch_sks) {
> + /* Batching is done for the current bucket; return the first
> + * socket to be iterated from the batch.
> + */
> + iter->st_bucket_done = true;
> + goto ret;
> + }
> + if (!resized && !bpf_iter_udp_realloc_batch(iter, batch_sks * 3 / 2)) {
> + resized = true;
> + /* Go back to the previous bucket to resize its batch. */
> + state->bucket--;
> + goto again;
> + }
> +ret:
> + iter->offset = new_offset;
hmm... updating iter->offset looks not right and,
does it need a new_offset?
afaict, either
a) it can resume at the old bucket. In this case, the iter->offset should not
change.
or
b) it moved to the next bucket and iter->offset should be 0.
> + return first_sk;
&iter->batch[0] is the first_sk. 'first_sk' variable is not needed then.
next prev parent reply other threads:[~2023-03-31 21:08 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-30 15:17 [PATCH v5 bpf-next 0/7] bpf: Add socket destroy capability Aditi Ghag
2023-03-30 15:17 ` [PATCH v5 bpf-next 1/7] bpf: tcp: Avoid taking fast sock lock in iterator Aditi Ghag
2023-03-30 15:17 ` [PATCH v5 bpf-next 2/7] udp: seq_file: Remove bpf_seq_afinfo from udp_iter_state Aditi Ghag
2023-03-30 17:35 ` Martin KaFai Lau
2023-03-30 15:17 ` [PATCH v5 bpf-next 3/7] udp: seq_file: Helper function to match socket attributes Aditi Ghag
2023-03-30 18:40 ` kernel test robot
2023-03-30 18:51 ` kernel test robot
2023-03-31 2:52 ` kernel test robot
2023-03-31 20:09 ` Martin KaFai Lau
2023-04-03 15:27 ` Aditi Ghag
2023-04-02 6:18 ` kernel test robot
2023-03-30 15:17 ` [PATCH v5 bpf-next 4/7] bpf: udp: Implement batching for sockets iterator Aditi Ghag
2023-03-31 21:08 ` Martin KaFai Lau [this message]
2023-04-03 15:54 ` Aditi Ghag
2023-04-03 19:20 ` Martin KaFai Lau
2023-03-30 15:17 ` [PATCH v5 bpf-next 5/7] bpf: Add bpf_sock_destroy kfunc Aditi Ghag
2023-03-31 22:24 ` Martin KaFai Lau
2023-04-04 6:09 ` [RFC PATCH bpf-next] bpf: Add a kfunc filter function to 'struct btf_kfunc_id_set' Martin KaFai Lau
2023-04-05 15:05 ` Aditi Ghag
2023-04-05 17:26 ` Martin KaFai Lau
2023-04-10 23:05 ` Aditi Ghag
2023-04-12 15:21 ` Aditi Ghag
2023-03-30 15:17 ` [PATCH v5 bpf-next 6/7] selftests/bpf: Add helper to get port using getsockname Aditi Ghag
2023-03-30 18:41 ` Stanislav Fomichev
2023-03-31 21:37 ` Martin KaFai Lau
2023-03-30 15:17 ` [PATCH v5 bpf-next 7/7] selftests/bpf: Test bpf_sock_destroy Aditi Ghag
2023-03-30 18:46 ` Stanislav Fomichev
2023-03-31 22:32 ` Martin KaFai Lau
2023-04-03 15:55 ` Aditi Ghag
2023-04-03 17:35 ` Martin KaFai Lau
2023-04-04 0:15 ` Aditi Ghag
2023-04-04 1:41 ` Martin KaFai Lau
2023-04-04 14:24 ` Aditi Ghag
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=acdafa2f-b127-5a5a-84f7-0a046e1ce0fa@linux.dev \
--to=martin.lau@linux.dev \
--cc=aditi.ghag@isovalent.com \
--cc=bpf@vger.kernel.org \
--cc=edumazet@google.com \
--cc=kafai@fb.com \
--cc=martin.lau@kernel.org \
--cc=sdf@google.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.