>> +
>> + if (hlist_empty(&hslot->head))
>> + continue;
>> +
>> + spin_lock_bh(&hslot->lock);
>> + sk_for_each(sk, &hslot->head) {
>> + if (seq_sk_match(seq, sk)) {
>> + if (first) {
>> + first_sk = sk;
>> + first = false;
>> + }
>> + if (iter->end_sk < iter->max_sk) {
>> + sock_hold(sk);
>> + iter->batch[iter->end_sk++] = sk;
>> + }
>> + bucket_sks++;
>> + }
>> + }
>> + spin_unlock_bh(&hslot->lock);
>> + if (first_sk)
>> + break;
>> + }
>> +
>> + /* All done: no batch made. */
>> + if (!first_sk)
>> + return NULL;
>
> I think first_sk and bucket_sks need to be reset on the "again" case also?
>
> If bpf_iter_udp_seq_stop() is called before a batch has been fully processed by the bpf prog in ".show", how does the next bpf_iter_udp_seq_start() continue from where it left off? The bpf_tcp_iter remembers the bucket and the offset-in-this-bucket. I think bpf_udp_iter can do something similar.
Hmm, I suppose you are referring to the `tcp_seek_last_pos` logic? This was the [1] commit that added the optimization in v2.6, but only for TCP. Extending the same logic for UDP is out of the scope of this PR? Although reading the [1] commit description, the latency issue seems to be specific to the file based iterators, no? Of course, BPF iterators are quite new, and I'm not sure if we have the same "slowness" reported in that commit. Having said that, do we expect users to start from where they previously left off by stopping BPF iterators? Regardless, I'll do some testing to ensure that we at least don't crash.
[1] https://github.com/torvalds/linux/commit/a8b690f98baf9fb1902b8eeab801351ea603fa3a
