Add sock-rmem-alloc example

[alebsys]

I want to add an example that will display the distribution of payload volume on a TCP socket.

For this I wrote the code:

...
struct key_t {
    u16 main_port;
    u64 bucket;
};

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, (MAX_BUCKET_SLOT + 1) * MAX_PORTS);
    __type(key, struct key_t);
    __type(value, u64);
} socket_rmem_alloc SEC(".maps");
...
SEC("fentry/tcp_recvmsg")
int BPF_PROG(tcp_recvmsg, struct sock *sk)
{
    struct key_t key = {};
    key.main_port = extract_main_port(sk);
    if ( key.main_port == 0) {
        return 0;
    }
    u64 rmem_alloc = sk->sk_backlog.rmem_alloc.counter;
    increment_exp2_histogram(&socket_rmem_alloc, key, rmem_alloc, MAX_BUCKET_SLOT);
    
    return 0;
}
...

I'm concerned about the volume of calls to the tcp_recvmsg socket read function under more or less high network load.
I ran the script on a server with ~350MBit/s RX with the following results

bpftrace -e 'kprobe:tcp_recvmsg { @ = count(); } i:s:10 { exit(); }'
Attaching 2 probes...
@: 170686

How representative are such tests and if there are really a lot of events, then what methods are there for optimization?

Tnx!

[bobrik]

You can measure ebpf overhead directly:

• https://github.com/cloudflare/ebpf_exporter#ebpf_exporter_ebpf_program_run_time_seconds

One thing that comes to mind: you could use a percpu hash map and increment_exp2_histogram_nosync to reduce potential contention. This goes back to measuring overhead with metrics. Comments from #300 might be useful.

I'm not really a bpf expert. This repo is a fairly thin wrapper around kernel provided functionality, so it might be more fruitful for you to ask on bpf mailing list directly.