Thread (31 messages) flat view 31 messages, 8 authors, 2017-02-14

Re: [PATCH RFC v2 1/8] xdp: Infrastructure to generalize XDP

From: Tom Herbert <hidden>
Date: 2017-02-09 22:27:02

On Thu, Feb 9, 2017 at 2:17 PM, David Miller [off-list ref] wrote:
From: Tom Herbert <redacted>
Date: Wed, 8 Feb 2017 15:41:20 -0800
quoted
These hooks are also generic to allow for XDP/BPF programs as well
as non-BPF code (e.g. kernel code can be written in a module).
I don't think we should even remotely consider surrendering the XDP
hook to module code.

We restrict it to eBPF for a reason, because that framework is
restricted in what it can do, what it can access, and how it can do
so.
Kernel modules go through extensive netdev review before they are
taken into the kernel, for BPF programs we just allow what any user
gives us without any peer review even implied. For this reason, I
simply don't believe that BPF is magically more robust code than what
is in a kernel module. Or to put it another way, do you think DPDK is
going to put any restrictions on what a user can do over raw queues in
userspace? If we put on artificial limits on XDP like it can only ever
be BPF then we are just closing the door to its full potential and
given more fodder for the userpace stacks to claim superiority.
Tom if you're going to do a cleanup that makes it so that drivers
need less code to support XDP, that is awesome but please do only
that.

Don't combine it with more controversial changes.
We need this for TXDP; I have no interest in rewriting the TCP stack in BPF :-)

Tom
Thank you.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help