lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
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