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: Fri, 27 Feb 2015 08:41:41 +0000 From: Thomas Graf <tgraf@...g.ch> To: Neil Horman <nhorman@...driver.com> Cc: Simon Horman <simon.horman@...ronome.com>, John Fastabend <john.r.fastabend@...el.com>, Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org, davem@...emloft.net, andy@...yhouse.net, dborkman@...hat.com, ogerlitz@...lanox.com, jesse@...ira.com, jpettit@...ira.com, joestringer@...ira.com, jhs@...atatu.com, sfeldma@...il.com, f.fainelli@...il.com, roopa@...ulusnetworks.com, linville@...driver.com, shrijeet@...il.com, gospo@...ulusnetworks.com, bcrl@...ck.org Subject: Re: Flows! Offload them. On 02/26/15 at 08:22pm, Neil Horman wrote: > Yes, exactly that, for the general traditional networking use case, that is > exactly what we want, to opportunistically move traffic faster with less load on > the cpu. We don't nominally care what traffic is offloaded, as long as the > hardware does a better job than just software alone. If we get an occasional > miss and have to do stuff in software, so be it. Blind random offload of some packets is better than nothing but knowing and having control over which packets are offloaded is essential. You typically don't want to randomly give one flow priority over another ;-) Some software CPUs might not be able to handle the load. I know what you mean though and as long as we allow to disable and overwrite this behaviour we are good. > So, this is a case in which I think John F.'s low level flow API is more well > suited. OVS has implemented a user space dataplane that circumvents alot of the > kernel mechanisms for traffic forwarding. For that sort of application, the > traditional kernel offload "objects" aren't really appropriate. Instead, OVS > can use the low level flow API to construct its own custom offload pipeline > using whatever rules and policies that it wants. Maybe I'm misunderstanding your statement here but I think it's essential that the kernel is able to handle whatever we program in hardware even if the hardware tables look differrent than the software tables, no matter whether the configuration occurs through OVS or not. A punt to software should always work even if it does not happen. So while I believe that OVS needs more control over the hardware than available through the datapath cache it must program both the hardware and software in parallel even though the building blocks for doing so might look different. > Of course, using the low level flow API is incompatible with the in-kernel > object offload idea that I'm proposing, but I see the two as able to co-exist, > much like firewalld co-exists with iptables. You can use both, but you have to > be aware that using the lower layer interface might break the others higher > level oeprations. And if that happens, its on you to manage it. I think this does not have to be mutually exclusive. An example would be a well defined egress qdisc which is offloaded into it's own table. If OVS is aware of the table it can make use of it while configuring that table through the regular qdisc software API. -- 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