On 4/3/24 6:11 PM, John Fastabend wrote:
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.
sounds a good idea. Do we need to support detach function or atomic
update function as well? Can each sk has multiple sk_msg_prog programs?
[ It is orthogonal to what Yonghong is doing, so the title changed ]
