From: Jamal Hadi Salim <jhs@mojatatu•com>
To: Thomas Graf <tgraf@suug•ch>, Daniel Borkmann <daniel@iogearbox•net>
Cc: stephen@networkplumber•org, ast@plumgrid•com, jiri@resnulli•us,
netdev@vger•kernel.org
Subject: Re: [PATCH iproute2 -next] tc, bpf: finalize eBPF support for cls and act front-end
Date: Wed, 08 Apr 2015 07:58:26 -0400 [thread overview]
Message-ID: <552517E2.2070709@mojatatu.com> (raw)
In-Reply-To: <20150401223044.GB19425@casper.infradead.org>
Maybe i should be reading backwards;-> But i skipped a few emails
instead.
On 04/01/15 18:30, Thomas Graf wrote:
> On 04/01/15 at 04:13pm, Daniel Borkmann wrote:
>> I see it as a way to offer a generic, fast and 'safe' option for
>> classifier and action developers to have a programmable data path
>> in the traffic control subsystem in the kernel, which I think is
>> very powerful and important in various use-cases. I regard it as
>> a similar way and elegant solution as tcpdump or nftables resolve
>> their problems internally, in other words, to provide a _generic_
>> solution to address _specific, customized_ issues. Perhaps an anti
>> feature-bloat, if you will. ;) My viewpoint is that this ties well
>> together into the kernel landscape, and also makes us improve
>> various other subsystems that it makes use of, successively.
>
> Alexei will remember that I gave him a hard time with the exact
> same remarks as Jamal brought up when he presented this in New
> Orleans ;-)
>
I think you hit on my concern. The potential of another frankestein
exists here.
> What turned my viewpoint around was the knowledge that function
> calls are limited. eBPF programs can only make calls to functions
> which have been specifically whitelisted for eBPF programs. This
> policy is enforced by the kernel through the verifier. Exported
> symbols are not automatically whitelisted. So an eBPF program
> can't call into drivers or use arbitrary kernel APIs and is thus
> a lot more restricted than a kernel module.
>
I havent seen much restriction in the sample code posted by Daniel.
Dont get me wrong, I like ebpf (when ovs was being presented i didnt
say I liked it, but if you recall did protest the frankestein factor).
cheers,
jamal
next prev parent reply other threads:[~2015-04-08 11:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 22:35 [PATCH iproute2 -next] tc, bpf: finalize eBPF support for cls and act front-end Daniel Borkmann
2015-04-01 5:16 ` Alexei Starovoitov
2015-04-01 8:48 ` Daniel Borkmann
2015-04-01 12:36 ` Jamal Hadi Salim
2015-04-01 14:13 ` Daniel Borkmann
2015-04-01 22:30 ` Thomas Graf
2015-04-08 11:58 ` Jamal Hadi Salim [this message]
2015-04-02 0:13 ` Hannes Frederic Sowa
2015-04-02 0:24 ` Daniel Borkmann
2015-04-02 0:29 ` Hannes Frederic Sowa
2015-04-02 10:19 ` Daniel Borkmann
2015-04-02 11:30 ` Hannes Frederic Sowa
2015-04-02 12:08 ` Daniel Borkmann
2015-04-02 16:14 ` Alexei Starovoitov
2015-04-02 18:38 ` Daniel Borkmann
2015-04-02 12:10 ` Thomas Graf
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=552517E2.2070709@mojatatu.com \
--to=jhs@mojatatu$(echo .)com \
--cc=ast@plumgrid$(echo .)com \
--cc=daniel@iogearbox$(echo .)net \
--cc=jiri@resnulli$(echo .)us \
--cc=netdev@vger$(echo .)kernel.org \
--cc=stephen@networkplumber$(echo .)org \
--cc=tgraf@suug$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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