Yeah, sounds good!

Great, can that be assumed the final magic e_machine number for the ELF header that eBPF loaders can check for as well then (I do like 0xeb9f ;))?

But that would mean, that XDP programs are not portable anymore across different drivers, no? So they'd have to be rewritten when porting to a different nic or cannot be supported there due to missing

Yep, first step with opcodes 0=drop, 1=pass/stack, 2=tx/fwd defined sounds reasonable to me with rest as drop.

Can't this be done in a second step, with some per-cpu scratch data as we have for redirect? That would seem easier to use to me, and easier to extend with further data required to tx or rx to stack .

Actually for network debugging it would be nice if we could classify an skb e.g. from XDP (when passed to stack) or cls_bpf ingress, and tell the kernel that if this particular skb changes e.g. its pr

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 bpf_netdev_conferenc

That's awesome, thanks Brenden!

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. Attach

[...] Yeah, so I'll do some more testing and get it out for -net-next when it opens up next few days hopefully, keeping also Ashhad in the loop (meanwhile you can use the patch). Cheers, Daniel

I believe from the old nft ingress discussion. ;) But maybe it was just a different issue w/ other actions (or not up to date fact anymore). There's also skb_ensure_writable(), but seems to be doing m

Sure, that's fine, can do that. Yeah, I think reloading pointers via JIT should not take too many cycles. Was still thinking if we better should extend this (rather slow-path) test into handling it mo

Do you get -EFAULT error from bpf_skb_store_bytes()? What buffer size do you pass into the function (R4)? Would something like the below help? Just compile-tested for now, still needs an audit whether

On 11/12/2015 12:14 AM, O Mahony, Billy wrote: ... > One thing I notice is that immediately after I assign ip addrs to the endpoints of the veth pair I see several log messages: > > <idle>-0 [000] .Ns

Depends where you have tracefs mounted, f.e. cat /sys/kernel/debug/tracing/trace_pipe Cheers, Daniel