Hi, Using EM_NONE for the bpf backend e_machine value is less than optimal. With a unique value we can interact with other tools, e.g. objdump for disassembly. As a bonus, I noticed a few missing patt

Hi, I'm running test_maps under net-next/samples/bpf/, commit 601009780635. The code logic all make sense but I got the assertion errors / coredump for some unknown reason under different compiler opt

Using EM_NONE for the bpf backend e_machine value is less than optimal. With a unique value we can interact with other tools, e.g. objdump for disassembly. As a bonus, I noticed a few missing patterns

This same value for EM_BPF is being propagated to glibc, elfutils, and binutils. Signed-off-by: Richard Henderson <rth@...> --- include/llvm/Object/ELFObjectFile.h | 5 +++++ include/llvm/Support/ELF.h

Signed-off-by: Richard Henderson <rth@...> --- lib/Target/BPF/BPFInstrInfo.td | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/lib/Target/BPF/BPFInstrInfo.td b/lib/Target/BPF/BPFInstrIn

Since all 32-bit operations zero-extend, the move operations are immediately usable for loading unsigned constants and zero-extension. Signed-off-by: Richard Henderson <rth@...> --- lib/Target/BPF/BPF

We can represent a 64-bit AND with unsigned immediate with a 32-bit AND opcode. Signed-off-by: Richard Henderson <rth@...> --- lib/Target/BPF/BPFInstrInfo.td | 15 +++++++++++++++ 1 file changed, 15 in

Avoid duplicating lots of field definitions. Signed-off-by: Richard Henderson <rth@...> --- lib/Target/BPF/BPFInstrFormats.td | 39 ++- lib/Target/BPF/BPFInstrInfo.td | 536 +++++++++++++++-------------

Hi all, I know that some folks are busy this week at the Netfilter Workshop in Amsterdam, and as well we just had the meetup last week for XDP, so I think it makes sense to cancel the call this week.

Hi When using direct packet access I noticed that the verifier cannot cary the packet length validation check across tail calls. This is mainly a burden for L4 where L3 may require some more expensive

How easy is it to extend the XDP/eBPF program with a new input parameter? I see the need for providing the input "source-port" to the eBPF program. E.g. needed when implementing a basic learning bridg

Hi, Here is my proposal for an "XDP workshop" for netdev 1.2 (Oct. 5-7 in Tokyo). Please review and let me know if this is missing anything before I submit it. Once this is accepted, we'll be recruiti

Hi All, Please join us for our bi-weekly call. This meeting is open to everybody and completely optional. It's been a while since our last meeting, so I expect that we'll have a lively discussion. IOV

just pushed Richard's patch https://github.com/llvm-mirror/llvm/commit/36b9c09330bfb5e771914cfe307588f30d5510d2 tested with bcc and different bpf loaders. Thankfully none of them rely on old and argua

Add support for the BPF_PROG_TYPE_PHYS_DEV ook in mlx5e driver. This is relevant for CX4Lx, with striding RQ, non fragmented wqes. For fast RX drop, single RX core, we get 32M PPS, while early drop (w

Hi everyone, Thanks for todays phone call; it was my first time calling in and was informative and helpful. I just wanted to follow up on my question about filtering on string arguments of USDT probes

All, I’m Wendy Cartee, a board member for IO Visor Project. IO Visor will be at LinuxCon August 22-24th, in Toronto. We plan to host an appreciation lunch and would like to meet the contributors to IO

Would it make sense from a hardware point of view, to split the XDP eBPF program into two stages. Stage-1: Filter (restricted eBPF / no-helper calls) Stage-2: Program Then the HW can choose to offload

Hi All, Please join us for our bi-weekly call. This meeting is open to everybody and completely optional. IOVisor TSC/Dev MeetingEvery 2 weeks on Wednesday, from Wednesday, May 18, 2016, to no end dat

Hi all, Thanks for joining the call today. Below is the summary of the topics discussed. If you are in the Bay Area tomorrow, PLUMgrid will be hosting a meetup to discuss XDP, feel free to join if you