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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 23 Sep 2014 11:11:29 +0100 From: Thomas Graf <tgraf@...g.ch> To: Andy Gospodarek <gospo@...ulusnetworks.com> Cc: Tom Herbert <therbert@...gle.com>, Alexei Starovoitov <alexei.starovoitov@...il.com>, Jiri Pirko <jiri@...nulli.us>, John Fastabend <john.r.fastabend@...el.com>, Jamal Hadi Salim <jhs@...atatu.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, Neil Horman <nhorman@...driver.com>, Andy Gospodarek <andy@...yhouse.net>, Daniel Borkmann <dborkman@...hat.com>, Or Gerlitz <ogerlitz@...lanox.com>, Jesse Gross <jesse@...ira.com>, Pravin Shelar <pshelar@...ira.com>, Andy Zhou <azhou@...ira.com>, Ben Hutchings <ben@...adent.org.uk>, Stephen Hemminger <stephen@...workplumber.org>, Jeff Kirsher <jeffrey.t.kirsher@...el.com>, Vladislav Yasevich <vyasevic@...hat.com>, Cong Wang <xiyou.wangcong@...il.com>, Eric Dumazet <edumazet@...gle.com>, Scott Feldman <sfeldma@...ulusnetworks.com>, Florian Fainelli <f.fainelli@...il.com>, Roopa Prabhu <roopa@...ulusnetworks.com>, John Linville <linville@...driver.com>, "dev@...nvswitch.org" <dev@...nvswitch.org>, Jason Wang <jasowang@...hat.com>, "Eric W. Biederman" <ebiederm@...ssion.com>, Nicolas Dichtel <nicolas.dichtel@...nd.com>, ryazanov.s.a@...il.com, Lennert Buytenhek <buytenh@...tstofly.org>, aviadr@...lanox.com, Felix Fietkau <nbd@...nwrt.org>, Neil Jerram <Neil.Jerram@...aswitch.com>, ronye@...lanox.com, simon.horman@...ronome.com, Alexander Duyck <alexander.h.duyck@...el.com> Subject: Re: [patch net-next v2 8/9] switchdev: introduce Netlink API On 09/23/14 at 12:11am, Andy Gospodarek wrote: > There are clearly some that are most interested in how an eSwitch on an > SR-IOV capable NIC be controlled can provide traditional forwarding help > as well as offload the various technologies they hope to terminate > at/inside their endpoint (host/guest/container) -- Thomas's _simple_ > use-case demonstrates this. ;) This is a logical extention/increase in > functionality that is offered in many eSwitches that was previously > hidden from the user with the first generation SR-IOV capable network > devices on hosts/servers. I think we can define this more broadly and state that providing RX steering capabilities to identify a guest in the NIC allows to directly map packets into a memory region shared between host and guest. Not a new concept at all but the existing dMAC and VLAN rx filtering is just too limiting. We require a programmable API with support for encap and encryption. SR-IOV is a hardware assisted form of that which can expedite the guest to guest path on a host. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists