[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <71cb13b9-fe81-c338-68dc-4d432360a0fb@redhat.com>
Date: Mon, 2 Dec 2019 10:56:00 +0800
From: Jason Wang <jasowang@...hat.com>
To: David Miller <davem@...emloft.net>, mst@...hat.com
Cc: dsahern@...il.com, prashantbhole.linux@...il.com, ast@...nel.org,
daniel@...earbox.net, jakub.kicinski@...ronome.com,
hawk@...nel.org, john.fastabend@...il.com, kafai@...com,
songliubraving@...com, yhs@...com, andriin@...com,
netdev@...r.kernel.org, qemu-devel@...gnu.org, kvm@...r.kernel.org
Subject: Re: [RFC net-next 08/18] tun: run offloaded XDP program in Tx path
On 2019/12/2 上午5:54, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@...hat.com>
> Date: Sun, 1 Dec 2019 16:40:22 -0500
>
>> Right. But it is helpful to expose the supported functionality
>> to guest in some way, if nothing else then so that
>> guests can be moved between different hosts.
>>
>> Also, we need a way to report this kind of event to guest
>> so it's possible to figure out what went wrong.
> On the contrary, this is why it is of utmost importance that all
> XDP implementations support the full suite of XDP facilities from
> the very beginning.
>
> This is why we keep giving people a hard time when they add support
> only for some of the XDP return values and semantics. Users will get
> killed by this, and it makes XDP a poor technology to use because
> behavior is not consistent across device types.
>
> That's not acceptable and I'll push back on anything that continues
> this trend.
>
> If you can't HW offload it, kick it to software.
We can try to work out a solution for XDP_REDIRECT.
Thanks
Powered by blists - more mailing lists