On Tue, Mar 21, 2017 at 2:23 PM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > On Tue, 2017-03-21 at 13:49 -0700, Kees Cook wrote: > >> Yeah, this is exactly what I'd like to find as well. Just comparing >> cycles between refcount implementations, while interesting, doesn't >> show us real-world performance changes, which is what we need to >> measure. >> >> Is Eric's "20 concurrent 'netperf -t UDP_STREAM'" example (from >> elsewhere in this email thread) real-world meaningful enough? > > Not at all ;) > > This was targeting the specific change I had in mind for > ip_idents_reserve(), which is not used by TCP flows. Okay, I just wanted to check. I didn't think so, but it was the only example in the thread. > Unfortunately there is no good test simulating real-world workloads, > which are mostly using TCP flows. Sure, but there has to be _something_ that can be used to test to measure the effects. Without a meaningful test, it's weird to reject a change for performance reasons. > Most synthetic tools you can find are not using epoll(), and very often > hit bottlenecks in other layers. > > > It looks like our suggestion to get kernel builds with atomic_inc() > being exactly an atomic_inc() is not even discussed or implemented. So, FWIW, I originally tried to make this a CONFIG in the first couple passes at getting a refcount defense. I would be fine with this, but I was not able to convince Peter. :) However, things have evolved a lot since then, so perhaps there are things do be done here. > Coding this would require less time than running a typical Google kernel > qualification (roughly one month, thousands of hosts..., days of SWE). It wasn't the issue of coding time; just that it had been specifically not wanted. :) Am I understanding you correctly that you'd want something like: refcount.h: #ifdef UNPROTECTED_REFCOUNT #define refcount_inc(x) atomic_inc(x) ... #else void refcount_inc(... ... #endif some/net.c: #define UNPROTECTED_REFCOUNT #include <refcount.h> or similar? -Kees -- Kees Cook Pixel Security
