From: Joe Stringer <joe@...> The patch add bpf installation guide and configuration for linking to libbpf library. Co-authored-by: William Tu <u9012063@...> Co-authored-by: Yifeng Sun

Today OVS has three datapath types: Linux kernel (dpif-netlink), userspace (dpif-netdev), and Windows. This series add another type of OVS datapath: the eBPF datapath (dpif-bpf). eBPF stands for

Hi All, As usual, here are my notes from the call today. -Brenden === Discussion === Brenden: - Packaging changes - have Ubuntu 18.04 buildbot tested and ready - Working on merging Fedora 28

Please join us tomorrow for our bi-weekly call. As usual, this meeting is open to everybody and completely optional. You might be interested to join if: You want to know what is going on in BPF

There's a BPF.attach_raw_socket method to help you with that. For examples, see

Hi! There is multiple options to attach a BPF program (BPF.attach_kprobe(), BPF.attach_uprobe(), etc) but currently possible to attach BPF program to socket with the BCC python frontend? In C its

Hi Paul, Thanks a lot! This is very helpful. I'm testing it now, works great so far, and saves lots of bpf stack space. Regards, William

d71962f ("bpf: allow map helpers access to map values directly") removes that limitation from the verifier and should allow you to use map values as map keys directly. 4.18-rc1 has it.

<alexei.starovoitov@...> wrote: I mean "new" rules being added at 10 rules/sec. Update rate might be much higher. When adding a new rule, do these algorithms require rebuilding the entire

is this a typo? you probably meant 10K rule updates a second ? Last time I've dealt with these algorithms we had 100K acl updates a second. It was an important metric that we were optimizing for. I'm

Firstly, note that bpf_probe_read_str adds an extra \0 to the read string. So your max should be sizeof(data.argv) - 1 instead in order for data.argv[len] = ' ' to work (from Verifier's perspective,

I'm hoping someone knows a workaround here. I have a char buf[128] and I'd like to write to arbitrary offsets, but keep hitting this error. Any workaround? I've included a sample bcc program below,

Hi Alexei, Thanks a lot for the feedback! <alexei.starovoitov@...> wrote: We did try the decision tree approach using dpdk's acl lib. The lookup speed is 6 times faster than the magaflow using

Thank you for sharing the patches. my opinion on the above two didn't change. To recap: A. Non scalable megaflow map is no go. I'd like to see packet classification algorithm like hicuts or efficuts

s/Visort/Visor/

Hi All, As usual, here are my notes from the meeting today. -Brenden === Discussion === Kenny: How is transition to groups.io mailer? - no complaints Yonghong: - rewriter improvements - lot of

Please join us tomorrow for our bi-weekly call. As usual, this meeting is open to everybody and completely optional. You might be interested to join if: You want to know what is going on in BPF

VAGRANT_VAGRANTFILE=Vagrantfile-eBPF vagrant up Signed-off-by: William Tu <u9012063@...> Signed-off-by: Yifeng Sun <pkusunyifeng@...> --- Makefile.am | 1 + Vagrantfile-eBPF | 99

Add a separate test file tests/system-bpf-traffic.at for bpf testing. The test cases are a subset of the existing system-traffic.at, and with additional bpf-specific tests. When test passes, the log

From: Joe Stringer <joe@...> This new utility is used for standalone probing of BPF datapath state. Signed-off-by: Joe Stringer <joe@...> Signed-off-by: William Tu