|
Message-ID: <1332212386.22737.20.camel@edumazet-glaptop> Date: Mon, 19 Mar 2012 19:59:46 -0700 From: Eric Dumazet <eric.dumazet@...il.com> To: Indan Zupancic <indan@....nu> Cc: Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org, linux-doc@...r.kernel.org, kernel-hardening@...ts.openwall.com, netdev@...r.kernel.org, x86@...nel.org, arnd@...db.de, davem@...emloft.net, hpa@...or.com, mingo@...hat.com, oleg@...hat.com, peterz@...radead.org, rdunlap@...otime.net, mcgrathr@...omium.org, tglx@...utronix.de, luto@....edu, eparis@...hat.com, serge.hallyn@...onical.com, djm@...drot.org, scarybeasts@...il.com, pmoore@...hat.com, akpm@...ux-foundation.org, corbet@....net, markus@...omium.org, coreyb@...ux.vnet.ibm.com, keescook@...omium.org Subject: Re: [PATCH] net: bpf_jit: Simplify code by always using offset8 or offset32. On Tue, 2012-03-20 at 13:24 +1100, Indan Zupancic wrote: > If it does then perhaps the fast path should be made faster by inlining > the code instead of calling a function which may not be cached. > inlining 400 times a sequence of code is waste of icache, you probably missed this. I spent a lot of time on working on this implementation, tried many different strategies before choosing the one in place. Listen, I am tired of this thread, it seems you want to push changes that have almost no value but still need lot of review. Unless you make benchmarks and can make at least 5 % improvement of the speed, or improve maintainability of this code, I am not interested. We certainly _can_ one day have sizeof(struct sk_buff) > 256, and actual code is ready for this. You want to break this for absolutely no valid reason. We _can_ change fields order anytime in struct sk_buff, even if you state "its very unlikely that those fields are ever moved to the end of sk_buff".
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.