From: Ingo Molnar <mingo@kernel.org>
To: Jovi Zhangwei <jovi.zhangwei@gmail.com>
Cc: Alexei Starovoitov <ast@plumgrid.com>,
Ingo Molnar <mingo@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Greg KH <gregkh@linuxfoundation.org>,
Andi Kleen <andi@firstfloor.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: ktap and ebpf integration
Date: Fri, 4 Apr 2014 09:48:00 +0200 [thread overview]
Message-ID: <20140404074800.GD1637@gmail.com> (raw)
In-Reply-To: <CAGdX0WFm2wccs30q1=eduLdzjAjfxz-6oL-zGvumY6BigQ-a4g@mail.gmail.com>
* Jovi Zhangwei <jovi.zhangwei@gmail.com> wrote:
> On Fri, Apr 4, 2014 at 2:26 PM, Alexei Starovoitov <ast@plumgrid.com> wrote:
> > On Thu, Apr 3, 2014 at 6:21 PM, Jovi Zhangwei <jovi.zhangwei@gmail.com> wrote:
> >> Hi Alexei,
> >>
> >> We talked a lot on ktap and ebpf integration in these days,
> >> Now I think we can put into deeply to thinking out some
> >> technical issues in there.
> >>
> >> Firstly, I want to make sure you are support this ktap and
> >> ebpf integration direction, I aware you have ongoing 'bpf filter'
> >> patch set work, which actually overlapping with ktap integration
> >> efforts (IMO the interface should be unified and simple for user,
> >> so I think filter debugfs file is not a good interface), so please let
> >> me know your answer about this.
> >
> > I think the more choices users have the better.
> > I'll continue with C based filters and you can continue with ktap
> > syntax. That's ok. We can share all kernel pieces.
>
> Now I understand that there is no way to integrate ktap and ibpf in
> technical point of view, the kernel side and interface is completely
> different, and obviously you don't want to change current per-event
> filter file based interface and kernel part, that make impossible to
> let ktap could integrate or share with ibpf.
In my reading that's not what Alexei wrote: he just suggested that as
long as the kernel bits are largely shared, the user-space bits
(syntax, etc.) can stay completely orthogonal and independent.
It also does not mean that ktap is forced to use the per event filter
file based interface to pass BPF scripts to the kernel. BPF is already
used by various facilities in the kernel, with different user-space
APIs to interface with it.
So the main technical question is: why should ktap have its own
separate in-kernel code execution engine, if we already have the BPF
virtual machine (which is well-maintained, has excellent performance
through JIT, etc.), which could be reused and/or enhanced?
Is there any aspect of ktap's virtual machine that BPF does not have?
Thanks,
Ingo
next prev parent reply other threads:[~2014-04-04 7:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-04 1:21 ktap and ebpf integration Jovi Zhangwei
2014-04-04 6:26 ` Alexei Starovoitov
2014-04-04 7:26 ` Jovi Zhangwei
2014-04-04 7:48 ` Ingo Molnar [this message]
2014-04-04 8:46 ` Jovi Zhangwei
2014-04-04 15:57 ` Alexei Starovoitov
2014-04-04 17:28 ` Alexei Starovoitov
2014-04-05 14:23 ` Jovi Zhangwei
2014-04-05 17:22 ` Alexei Starovoitov
2014-04-05 21:26 ` Jovi Zhangwei
2014-04-05 17:50 ` Andi Kleen
2014-04-04 14:20 ` Andi Kleen
2014-04-04 7:27 ` Ingo Molnar
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=20140404074800.GD1637@gmail.com \
--to=mingo@kernel.org \
--cc=andi@firstfloor.org \
--cc=ast@plumgrid.com \
--cc=gregkh@linuxfoundation.org \
--cc=jovi.zhangwei@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
/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).