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
| ||
|
Message-ID: <20160409172634.GA55330@ast-mbp.thefacebook.com> Date: Sat, 9 Apr 2016 10:26:37 -0700 From: Alexei Starovoitov <alexei.starovoitov@...il.com> To: Jamal Hadi Salim <jhs@...atatu.com> Cc: Tom Herbert <tom@...bertland.com>, Jesper Dangaard Brouer <brouer@...hat.com>, Brenden Blanco <bblanco@...mgrid.com>, "David S. Miller" <davem@...emloft.net>, Linux Kernel Network Developers <netdev@...r.kernel.org>, Or Gerlitz <ogerlitz@...lanox.com>, Daniel Borkmann <daniel@...earbox.net>, Eric Dumazet <eric.dumazet@...il.com>, Edward Cree <ecree@...arflare.com>, john fastabend <john.fastabend@...il.com>, Thomas Graf <tgraf@...g.ch>, Johannes Berg <johannes@...solutions.net>, eranlinuxmellanox@...il.com, Lorenzo Colitti <lorenzo@...gle.com>, linux-mm <linux-mm@...ck.org> Subject: Re: [RFC PATCH v2 1/5] bpf: add PHYS_DEV prog type for early driver filter On Sat, Apr 09, 2016 at 11:29:18AM -0400, Jamal Hadi Salim wrote: > On 16-04-09 07:29 AM, Tom Herbert wrote: > > >+1. Forwarding which will be a common application almost always > >requires modification (decrement TTL), and header data split has > >always been a weak feature since the device has to have some arbitrary > >rules about what headers needs to be split out (either implements > >protocol specific parsing or some fixed length). > > Then this is sensible. I was cruising the threads and > confused by your earlier emails Tom because you talked > about XPS etc. It sounded like the idea evolved into putting > the whole freaking stack on bpf. yeah, no stack, no queues in bpf. > If this is _forwarding only_ it maybe useful to look at > Alexey's old code in particular the DMA bits; > he built his own lookup algorithm but sounds like bpf is > a much better fit today. a link to these old bits? Just to be clear: this rfc is not the only thing we're considering. In particular huawei guys did a monster effort to improve performance in this area as well. We'll try to blend all the code together and pick what's the best.
Powered by blists - more mailing lists