On Tue, Feb 28, 2023 at 12:32 PM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote:
>
> On 2/24/23 2:32 PM, Stanislav Fomichev wrote:
> >> + unsigned int cur_sk;
> >> + unsigned int end_sk;
> >> + unsigned int max_sk;
> >> + struct sock **batch;
> >> + bool st_bucket_done;
> >
> > Any change we can generalize some of those across tcp & udp? I haven't
> > looked too deep, but a lot of things look like a plain copy-paste
> > from tcp batching. Or not worth it?
>
> The batching has some small but subtle differences between tcp and udp, so not
> sure if it can end up sharing enough codes.
>
> >> static int udp_prog_seq_show(struct bpf_prog *prog, struct bpf_iter_meta *meta,
> >> struct udp_sock *udp_sk, uid_t uid, int bucket)
> >> {
> >> @@ -3172,18 +3307,34 @@ static int bpf_iter_udp_seq_show(struct seq_file *seq,
> >> void *v)
> >> struct bpf_prog *prog;
> >> struct sock *sk = v;
> >> uid_t uid;
> >> + bool slow;
> >> + int rc;
> >
> >> if (v == SEQ_START_TOKEN)
> >> return 0;
> >
> >> + slow = lock_sock_fast(sk);
> >
> > Hm, I missed the fact that we're already using fast lock in the tcp batching
> > as well. Should we not use fask locks here? On a loaded system it's
> > probably fair to pay some backlog processing in the path that goes
> > over every socket (here)? Martin, WDYT?
>
> hmm... not sure if it is needed. The lock_sock_fast was borrowed from
> tcp_get_info() which is also used in inet_diag iteration. bpf iter prog should
> be doing something pretty fast also. In the future, it could allow the bpf-iter
> program to acquire the lock by itself only when it is necessary if the current
> always lock strategy is too expensive.
Cool, thx!
