G'Day all,

I have colleagues working on BCC Python tools (e.g., the recent
enhancement of tcpconnect.py) and I'm wondering, given libbpf tools,
what our advice should be.

- Should we keep both Python and libbpf tools in sync?
- Should we focus on libbpf only, and leave Python versions for legacy systems?

Should we keep libbpf-tools and py-bcc tools in sync?

Does the LLVM version used by bcc matter, for packaging purposes?

I assume bcc includes some static libraries from LLVM, so I'm curious if the older versions are acceptable. For instance, on ubuntu 16.04, we use LLVM 3.7, but on ubuntu 18.04 and 20.04 it uses LLVM 6.0, based on the current debian control file.

Are there features of newer LLVM releases that we need? For example, does BTF require a specific minimum version of LLVM? If this is the case, perhaps we should update the dependency descriptions in the debian control file to reflect this.

Thanks a lot, Yonghong. From your response:

In your case, the bpf program is to influence io scheduling decisions.
You could implement in a way to do kernel data structure write in
kernel but have a hook to a bpf program to make decision and based on
bpf program return value, kernel can decide what to schedule.

1. How can I make a kernel function use the return value of a eBPF program/function?

2. An KProbes related question: from an old article https://lwn.net/Articles/132196/ which was written in 2005, it said:
```
The current KProbes implementation, however, introduces some latency of its own in handling probes. The cause behind this latency is the single kprobe_lock which serializes the execution of probes across all CPUs on a SMP machine.
```
I read it as "functions (e.g., eBPF functions) attached to KProbes are executed in serial, i.e., the same eBPF function can not be run by multiple threads at the same time". As eBPF programs frequently use KProbes to hook to kernel functions, do you know if it's true currently that the calling of a eBPF function/program is single-threaded?

Hello BPF community,

I am looking for a way to move a user space program's disk I/O scheduling related logic down to kernel space, and then have the new kernel logic communicate with the user space program to make better I/O scheduling decisions. The reason that the user space program itself has I/O scheduling logic is because it needs to prioritize certain read or write requests.

I started looking at eBPF for that purpose. After doing some research, I learned that eBPF is very good at kernel profiling and tracing, but I didn't find much information about modifying kernel functions / data-structure using eBPF.

I am wondering:

1. Instead of calling eBPF function before / after calling a kernel function and then returning back to that kernel function, is it possible for eBPF programs to totally replace a kernel function or module logic?

2. Is it possible for eBPF programs to tamper the parameter and return value of a kernel function, or eBPF program can only read kernel data-structure but can not modify them? (some search indicates that it can not few years ago, but I am not sure if it is changed recently)

Thank you!
Jiada

[Edited Message Follows]

Nice, thanks Song. I am actually looking to track it till it is closed, so might have to remove that tag when the socket goes to closed state.
And once I have the concurrent connections info, say in a map, I am using XDP to drop the connections after they reach a threshold

So also wanted to ask if there is any way I can read the concurrent connections in XDP since the kernel already keeps track of them at /proc/net/tcp*?
That would help me avoid placing another tracepoint to track the connection count.

Appreciate your help!

Thanks,
Kanthi

On Thu, Oct 1, 2020 at 11:26 AM Y Song <ys114321@...> wrote:

On Tue, Sep 29, 2020 at 4:14 AM Kanthi P <Pavuluri.kanthi@...> wrote:

Hi,

I am looking for tracking inbound connections on a system using tracepoints/kprobes.

I was checking "trace_inet_sock_set_state", with which we can track the state changes during connection establishment and closure. It seems straightforward to track total connections, but since we only want inbound, one way would be to look at what are the ip addresses/ports on which a node listens to and while tracking the state changes, I can see if the local address/port matches to the one this system listens on and based on that make a decision whether its an inbound connection or not. This looks a bit roundabout way for me, so thought of reaching for suggestions to do it simpler.

Another way is to store the socker address when TCP_SYN_RECV to TCP_ESTABLISHED state change happens and during closure we can check if it is for this socket, so we know its inbound connection. But this would make the map size grow too high as we have about 50k concurrent connections.

Can you suggest a better way to do this?

Maybe you can use sk_local_storage? You can attach a piece of
information to the socket during TCP_SYN_RECV and later on during
TCP_ESTABLISHED to check that data, and you can delete that data from
the socket if you do not need it any more,
all in bpf program.

Thanks,
Kanthi

Hi,

Observing established connection counter discrepancy as 20% (30-40 connections mismatch out of 200) in one day that builds to 30% by day-2 and so on.

This observation is with this code

if (args->newstate == TCP_ESTABLISHED) 

                 __sync_fetch_and_add(val, 1); 

       if (args->oldstate == TCP_ESTABLISHED)       

                 __sync_fetch_and_add(val, -1);  

 } 

There was a typo in my first message.

Regards,
Ragalahari

I have to create a test-environment (based on vagrant) the last couple of days and i've done this with ubuntu 20.04 as base image.

Is the repository https://github.com/iovisor/vagrant still active?
If yes i would create a PR to update this Repository.