Both the pyroute2 and go netlink pull requests have merged, so both clsact and direct-action mode are supported as far as bcc is concerned. Billy mentioned that he wanted to stay on 4.4 kernel

If in terms of tc "overhead" you mean first going through this fake u32 match-all classifier, then, as suggested, you can simply use cls_bpf with direct action mode. Check out the

<billy.o.mahony@...> wrote: Nice! That seems contrary to my own expectations. TC is closer to the metal than SOCKET_FILTER, the ingress qdisc should already be lightweight (lockless for

Hi Brendan, Hurrah! I have packets traversing my interfaces via eBPF. Thanks for all your help. As I said at one of the iovisor calls I planned to run some basic throughput tests and share the

<billy.o.mahony@...> wrote: That's fine, it'll still work. Probably arp is failing, your generator is probably doing nothing because it can't resolve the other side. Is your iproute2 up to

Hi Daniel, Brendan, Thanks for the tips. Unless what I'm trying to do just won't work I'll stick with kernel 4.4 and the ingress qdisc for now. So I changed my bpf programs to look like this: 6

As promised, the slides are now available here: https://github.com/iovisor/bpf-docs/blob/master/Express_Data_Path.pdf

If you are looking at this you might want to check out what we have today or perhaps your already aware of it. For steering flows to specific queues we have ethtool interface and soon 'tc' will

That's awesome, thanks Brenden!

Speaking of which, I just opened https://github.com/svinota/pyroute2/pull/223 to add support in pyroute2 upstream. The docstring in that pull request shows an example usage, which I'll also add to a

Alexei Starovoitov <alexei.starovoitov@...> wrote: Yes, but we might as well start up with making the allocator hacks in mlx4 more generic, when adding recycle. But still keep them locally

On 03/03/2016 08:19 PM, Brenden Blanco via iovisor-dev wrote: [...] > On Thu, Mar 3, 2016 at 5:52 AM, O Mahony, Billy <billy.o.mahony@...> [...] >> #add a filter to accept all eth frame.

I will heartily acknowledge that the mechanism to attach bpf programs to an interface is non-intuitive. This has been a source of pain for many. The code in https://github.com/iovisor/iomodules is an

<iovisor-dev@...> wrote: awesome. that's a great baseline. I think the next step here is to make mlx4 to recycle pages and rx descriptors on its own. Later we can generalize it into

Hi Brendan, After looking at the xlate tests, I *think* have managed to get my bpf programs attached to my NICS (or rather attached to a qdisc attached to my NICS - as I now understand it).

Brenden Blanco <bblanco@...> wrote: I'm doing my usual benchmark driven development. Which means I'm currently benchmarking the lowest RX layer of the drivers and just dropping packets

Thanks all for joining today, We had a very interesting session focused entirely on XDP (express data path), a new initiative to improve packet processing performance in the linux kernel. The details

The best source of truth is in the kernel code. The whitelist of functions for networking is: net/core/filter.c: sk_filter_func_proto() tc_cls_act_func_proto() other whitelists are available around

Hi Brendan, Thanks, that’s great. I’ll have a look at that example you mention too. Whereabouts in the code should I look to see which functions are allowable in which bpf program types?