From: Jerin Jacob <jerinjacobk@gmail.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
"dev@dpdk.org" <dev@dpdk.org>, Jerin Jacob <jerinj@marvell.com>,
"Varghese, Vipin" <vipin.varghese@intel.com>,
"mb@smartsharesystems.com" <mb@smartsharesystems.com>
Subject: Re: [dpdk-dev] BUG: eBPF missing BPF_ABS
Date: Thu, 6 Feb 2020 09:52:01 +0530 [thread overview]
Message-ID: <CALBAE1Op8A6J0GKtPYLcQRerEkV9hxFS46PPU5M8tjwZ7yRb3g@mail.gmail.com> (raw)
In-Reply-To: <DM6PR11MB25568543B04FD6F6EA77BD779A020@DM6PR11MB2556.namprd11.prod.outlook.com>
On Thu, Feb 6, 2020 at 2:46 AM Ananyev, Konstantin
<konstantin.ananyev@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
next prev parent reply other threads:[~2020-02-06 4:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-04 14:52 Stephen Hemminger
2020-02-05 21:16 ` Ananyev, Konstantin
2020-02-06 4:22 ` Jerin Jacob [this message]
2020-02-06 8:54 ` Morten Brørup
2020-02-06 9:11 ` Stephen Hemminger
2020-02-06 10:16 ` Ananyev, Konstantin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALBAE1Op8A6J0GKtPYLcQRerEkV9hxFS46PPU5M8tjwZ7yRb3g@mail.gmail.com \
--to=jerinjacobk@gmail.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=konstantin.ananyev@intel.com \
--cc=mb@smartsharesystems.com \
--cc=stephen@networkplumber.org \
--cc=vipin.varghese@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).