Oh its simply to inspect/filter/drop a compressed application packet in the kernel without incurring network stack processing.

Hi, Ashish, It seems that this has not been actively discussed before. Could you describe your use case? Thanks! Yonghong <iovisor-dev@...> wrote:

Dear developers, Is it a good idea to export kernel compression/decompression (lib/zlib_*, lib/lz*) as helper functions to enable corresponding use cases? Has this been tried before? Thanks, Ashish

Untrue. All these options can be used (and are used by big companies) with production kernels. I believe many distributions enable them by default. Quentin 2018-03-29 14:34 UTC+0000 ~ Saran Kumar

Thanks for the clarification. I assumed enabling the options specified in https://github.com/iovisor/bcc/blob/master/INSTALL.md rendered the kernel as DEBUG which is unsafe for production use.

Just to make it clear, Yonghong means that *the helper function bpf_trace_printk()* should be used mostly for debug. eBPF itself can perfectly be used in production. If you needed to stream data from

No, this can still be used. The warning just tells you this should mostly be used in debug mode. <iovisor-dev@...> wrote:

Hi - When I use bpf_trace_printk - I am getting this NOTICE. Does it mean, that eBPF shouldn't be used in the production kernel. Mar 20 12:26:44 lenovo-e565 kernel: [ 267.467518]

<alexei.starovoitov@...> wrote: Great! We can also make it Sep 26-27 but no one is required to be here both days. Cheers, Alban

Sounds great. +1 for Sep 27 Cheers, Michal

<iovisor-dev@...> wrote: I think it's a great idea. Sep 27 (the day before) is probably the best.

Hi, I’d like to suggest a BPF hackfest in Berlin in the days before the All Systems Go! Conference which will take place September 28-30. All Systems Go! is the user-space Linux conference we help

Dear all, I would like to share with you this [1] paper where we presented our experience and findings while trying to implement several network services with eBPF. We discuss the main encountered

Hi all, Thanks for joining the discussion today, as usual my notes of the discussion are included below. Cheers, Brenden === Discussion === Alexei - microkernel/umh work - see lkml Yonghong -

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

Raised a PR https://github.com/iovisor/bcc/pull/1629 for that! Regards Nirmoy -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5 D-90409

This solves the issue we have in our application. Thanks to both of you! Mauricio.

Looks like fd leakage is happening in bpf_prog_compute_tag please try with diff --git a/src/cc/libbpf.c b/src/cc/libbpf.c index d23d2bc..7b695af 100644 --- a/src/cc/libbpf.c +++ b/src/cc/libbpf.c @@

Confirmed that I could repro. I kprobed into __alloc_fd, it seems the extra socket FDs are allocated in annotate_prog_tag: 1209030 1209030 test_leak __alloc_fd 6

Dear All, One of our applications is giving errors because there are many file descriptors open. After some debugging we found that bcc appears to be leaking file descriptors. Please considerer the