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

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

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

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

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

[...] 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

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

That's awesome, thanks Brenden!

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

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

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 .

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

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

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 ;))?

Yeah, sounds good!

Yeah, checks cannot be carried over in two occasions: i) calling helpers that change skb->data (and therefore prior checks become invalid) and ii) tail calls. For tail calls the verifier doesn't know

On 10/25/2016 08:00 PM, Chandrasekar Kannan via iovisor-dev wrote: [...] > But when I try to run the sample from the linux source tree under release > (v4.8), > I get some strange errors. > > "Error f

What's your specific use-case on this? Reason why I'm asking is that the helper needs to linearize skb and is thus only suitable for slow path [1]. F.e. we use it for rewriting an skb as time exceeded

On just a very quick glance, don't you need UDP length here (aka UDP header and data)?

Hi William, Can you try out the below patch? evaluate_reg_imm_alu() is invoked on ALU ops where the dst reg is CONST_IMM and the src is either a constant from the insn or a reg with type CONST_IMM. Cu