Re: [RFC PATCH bpf-next 0/3] Avoid skipping sockets with socket iterators

[Martin KaFai Lau <martin.lau@linux.dev>]

On 3/31/25 10:23 AM, Jordan Rife wrote:
>> We can also consider if the same sk batch array can be reused to store cookies
>> during stop(). If the array can reuse, it would be nice but not a blocker imo.
> 
>> In term of slowness, the worst will be all the previous stored cookies cannot be
>> found in the updated bucket? Not sure how often a socket is gone and how often
>> there is a very large bucket (as mentioned at the hashtable's key earlier), so
>> should not be an issue for iteration use case? I guess it may need some rough
>> PoC code to judge if it is feasible.
> 
> I like the idea of reusing the sk batch array. Maybe create a union
> batch_item containing struct sock * and __u64. I'll explore this
> direction a bit and see if I can come up with a small PoC. Lots of

sgtm. Thanks.

I think udp should be easier to begin with for PoC.

tcp may need some thoughts. It seems it may be a good time to have some bpf 
specific implementation instead of reusing the existing tcp ones, e.g. 
tcp_seek_last_pos(). Not sure.

> array scanning could be slow, but since changes to a bucket should be
> rare, one optimization could be to only compare to the saved socket
> cookies if the bucket has changed since it was last seen. I think
> saving and checking the head, tail, and size of the bucket's linked
> list should be sufficient for this?

Not sure if head, tail, and size stay the same is enough to imply the bucket('s 
linked list) has not changed. I think tcp may be ok since I currently don't see 
a way to re-bind() a bind()-ed socket without close()-ing it. I don't know about 
the connected UDP...etc.

A quick thought is to keep it simple and scan the 1st cookie from the beginning 
of the bucket. The current saved "offset" should be no longer necessary.

Then start finding the 2nd, 3rd... cookies from the bucket's location where the 
1st cookie was found.

For the amount of work, this should be similar to the current "offset" which 
needs to walk the list till the "offset" point also. In the unlikely case a 
cookie cannot be found, it may need to scan from the beginning of the list to 
ensure it is indeed gone.