Hi Edward, Did you also have a chance in the meantime to look at reducing complexity along with your unification? I did run the cilium test suite with your latest set from here and current # worst cas

On 06/08/2017 06:45 PM, Alexei Starovoitov wrote: [...] > I think Daniel will be happy to test your next rev of the patches. > I'll test them as well. > At least 'insn_processed' from C code in tools/

On 04/05/2017 02:09 PM, Paul Chaignon via iovisor-dev wrote: [...] > Although it's not yet listed on the bcc repository, the Netronome nfp > driver does have support for XDP: > https://git.kernel.org/

Out of curiosity, why not .._SCHED_CLS program in direct-action mode (same functionality wrt BPF and would save you additional layers of indirection in tc at least), or are you required to run somethi

Hm, probably makes sense to implement a version of skb_load_bytes() for socket filter types explicitly that could also deal with such offsets.

[...] It's in bpf_jit_dump(): proglen is the len of opcode sequence generated and flen is the number of bpf insns. You can use tools/net/bpf_jit_disasm.c to disassemble that output. bpf_jit_disasm -o

Hmm, problem with C code is that we might have no control over when llvm decides to spill to stack where this workaround would then be needed. Your suggestion could work, maybe an llvm expert can jump

Right, so lines 260, 261 r5 is imm type, which in 277 is transferred to r2 and eventually in 279 spilled to stack. check_stack_write() would see that type is not spillable, so it will be stored as reg

You are generating the C files in the end, right? So the code shown is what clang gets to compile; or does this come from another llvm front end somehow? Also this below looks pretty odd, I'd have exp

Looks like a code generation issue perhaps? It seems your prog parses and fills a huge struct on the stack, f.e. eth dest is filled from direct packet acces byte by byte (inefficient, but fair enough)

Would be great if you could submit some of the missing pieces to linux-man@... for bpf(2) man-page inclusion while at it, so this doesn't need to be done twice. Thanks for documenting. Not

Depends where you look. F.e. tc has 'tc exec bpf dbg' to find the mount and dump the trace pipe. Yep, see discussion from netdev: https://www.spinics.net/lists/netdev/msg406926.html

Thanks a lot, I'll see to cook a proper patch then.

But what the compiler is doing here is still correct eventually I assume? We could also add BPF_AND, but that r5's type is UNKNOWN_VALUE doesn't seem right if I'm not mistaken. That r5 = 0xfffffff8 sh

Yes, effectively in 3) you're doing data_end -= data and that will result in marking the register as unknown value by the verifier, since it doesn't pattern match alu ops with data_end as dst reg. So

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

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

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

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