On Thu, Feb 6, 2020 at 2:46 AM Ananyev, Konstantin <konstantin.anan...@intel.com> wrote: > > >
> > Second question is implementation. > I can see two main options here: > a) if we plan to have our own cBPF->eBPF converter and support only it, > we can add these extra instructions generation into converter itself. > I.E. cBPF->eBPF conversion for LD_ABS/LD_IND will generate series > of generic eBPF instructions. > b) support eBPF LD_ABS/LD_IND in eBPF interpreter/jit > > (a) probably a simpler way (eBPF interpreter/jit/verifier would remain > unchanged), > but seems way too limited. So I think (b) is a better choice, even more work > implied > (interpreter seems more or less straightforward, jit would probably need some > effort). Looks like cBPF is an important use case. If we are leveraging code cBPF->eBPF code from somewhere and there is limited option to change then it is better to add our JIT. I can work on adding arm64 JIT support once base code in place. > > Any thoughts/opinions? > Konstantin > > > > > PCAP filter string: ip dst fosdem.org > > cBPF program (6 insns): > > L0: 28 00 00 00 0c 00 00 00 ldh [12] > > L1: 15 00 00 03 00 08 00 00 jeq #0x800, L2, L5 > > L2: 20 00 00 00 1e 00 00 00 ld [30] > > L3: 15 00 00 01 8c 16 16 1f jeq #0x1f16168c, L4, L5 > > L4: 06 00 00 00 ff ff ff ff ret #0xffffffff > > L5: 06 00 00 00 00 00 00 00 ret #0x0 > > eBPF program (11 insns): > > L0: af 00 00 00 00 00 00 00 xor r0, r0 > > L1: af 77 00 00 00 00 00 00 xor r7, r7 > > L2: bf 16 00 00 00 00 00 00 mov r6, r1 > > L3: 28 70 00 00 0c 00 00 00 ldh r0, [12] > > L4: 55 00 04 00 00 08 00 00 jne r0, #0x800, L9 > > L5: 20 70 00 00 1e 00 00 00 ldw r0, [30] > > L6: 55 00 02 00 8c 16 16 1f jne r0, #0x1f16168c, L9 > > L7: b4 00 00 00 01 00 00 00 mov32 r0, #0x1 > > L8: 95 00 00 00 00 00 00 00 exit > > L9: b4 00 00 00 02 00 00 00 mov32 r0, #0x2 > > L10: 95 00 00 00 00 00 00 00 exit > > validate: invalid opcode at pc: 3 > > validate: invalid opcode at pc: 5 > > rte_bpf_load failed: Invalid argument
