Martin KaFai Lau wrote: > On 4/3/24 10:47 AM, John Fastabend wrote: > > on my todo list, I want > > to just remove the map notion and bind progs to socks directly. > > Run the bpf prog without the sockmap? +1, it would be nice. Part of my motivation for doing this is almost all the bugs syzbot and others find are related to removing sockets from the map. We never do this in any of our code. Once a socket is in the map (added at accept time) it stays there until TCP stack closes it. Also we have to make up some size for the map that somehow looks like max number of concurrent sessions for the application. For many server applicatoins (nginx, httpd, ...) we know this, but is a bit artifically derived. > > > but other than quick hacks I've never built such a thing nor ran it > > in production. > > How do you see the interface will look like (e.g. attaching the bpf prog to a sk) ? I would propse doing it directly with a helper/kfunc from the sockops programs. attach_sk_msg_prog(sk, sk_msg_prog) attach_sk_skb_prog(sk, sk_skb_prog) > > It will be nice if the whole function (e.g. sk->sk_data_ready or may be some of > the sk->sk_prot) can be implemented completely in bpf. I don't have a concrete > use case for now but I think it will be powerful. Perhaps a data_ready prog could also replace the ops? attach_sk_data_ready(sk, sk_msg_data_ready) The attach_sk_data_ready could use pretty much the logic we have for creating psocks but only replace the sk_data_ready callback. > > [ It is orthogonal to what Yonghong is doing, so the title changed ] >
