On Thu, Sep 8, 2022 at 3:26 AM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote: > > On 9/4/22 2:24 PM, Kumar Kartikeya Dwivedi wrote: > > On Sun, 4 Sept 2022 at 20:55, Aditi Ghag <aditivghag@xxxxxxxxx> wrote: > >> > >> On Wed, Aug 31, 2022 at 4:02 PM Martin KaFai Lau <kafai@xxxxxx> wrote: > >>> > >>> On Wed, Aug 31, 2022 at 09:37:41AM -0700, Aditi Ghag wrote: >>>> [...] > >> > >> On a similar note, are there better ways as alternatives to the > >> sockets iterator approach. > >> Since we have BPF programs executed on cgroup BPF hooks (e.g., > >> connect), we already know what client > >> sockets are connected to a backend. Can we somehow store these socket > >> pointers in a regular BPF map, and > >> when a backend is deleted, use a regular map iterator to invoke > >> sock_destroy() for these sockets? Does anyone have > >> experience using the "typed pointer support in BPF maps" APIs [0]? > > > > I am not very familiar with how socket lifetime is managed, it may not > > be possible in case lifetime is managed by RCU only, > > or due to other limitations. > > Martin will probably be able to comment more on that. > sk is the usual refcnt+rcu_reader pattern. afaik, the use case here is > the sk should be removed from the map when there is a tcp_close() or > udp_lib_close(). There is sock_map and sock_hash to store sk as the > map-value. iirc the sk will be automatically removed from the map > during tcp_close() and udp_lib_close(). The sock_map and sock_hash have > bpf iterator also. Meaning a bpf-iter-prog can iterate the sock_map and > sock_hash and then do abort on each sk, so it looks like most of the > pieces are in place. > Yes, I did consider using a sock_hash type map. But for some reason I thought it would be accessible only from bpf_prog_type_sk_skb or sockops. Looks like the regular map helpers can be used for update/lookup operations on sock_hash map type. It's great to know that sock ref counting in sock map/hash types are automatically accounted for, so we don't have to add additional INET sock_release hooks.