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

[Jason Wang <jasowang@redhat.com>]

On 2017年02月10日 10:30, Tom Herbert wrote:
> On Thu, Feb 9, 2017 at 5:48 PM, David Miller <davem@davemloft.net> wrote:
>> From: Tom Herbert <tom@herbertland.com>
>> Date: Thu, 9 Feb 2017 15:08:22 -0800
>>
>>> Okay, how about this... I'll add a configuration option like
>>> XDP_ALLOW_OTHER_HOOKS. The default will be to disallow setting any
>>> hook other than a BPF. If it is set, then we'll accept other hooks
>>> to be run. This way mostly restrict the interface by default, but
>>> still allow experimentation with other hook types like I need with
>>> TXDP or maybe the netfilter guys might want to fastpath netfilter
>>> etc. When we we bring a working robust implementation to netdev that
>>> show clear benefits then we can add those to BPF as the "allowed"
>>> hooks at that time. So this strictly controls the interfaces, but
>>> still also allows room for innovation.
>> Anyone is allowed to "innovate" in their own private kernel tree.
>>
>> But I'm not unleashing that upstream.
>>
>> The only reason I accepted XDP is entirely because it is limited
>> in scope to eBPF.  All eBPF programs execute in finite time,
>> cannot loop, cannot deadlock, cannot access arbitrary pieces
>> of kernel memory and datastructures.
>>
>> It is a well defined, constrained, and incredibly tightly controlled
>> execution environment for implementing policy, monitoring and control.
> And it's also incredibly invasive in the core data path of drivers.
> TBH it is not clear to me that the narrow use cases for XDP justifies
> adding this complexity being added to every driver.

XDP is valuable for fast userspace forwarding (e.g macvtap passthrough 
mode). I hope we can leave a window for this. Or we may need introduce 
other similar hooks.

Thanks

>
> In any case, I withdraw the patch set.
>
> Tom