On Thu, 28 Oct 2021 at 21:20, Shawn Heisey <hapr...@elyograg.org> wrote: > > On 10/28/21 10:02 AM, Lukas Tribus wrote: > > You seem to be trying very hard to find a problem where there is none. > > > > Definitely do NOT overwrite CPU flags in production. This is to *test* > > AES acceleration, I put the link to the blog post in there for > > context, not because I think you need to force this on. > > I wouldn't call this production. It's the server in my basement. It > runs most of my personal websites. I do my experimentation there. I'm > OK with those experiments causing the occasional problem, because for > the most part I know how to fix it if I make a mistake.
I get it. Despite this, I don't want you to make matters worse. Also other people may read this thread and try the same. > I did just think of a way that I MIGHT be able to test. Time a simple > shell script using wget to hit a tiny static web page using https 10000 > times. For that test, the run with haproxy started normally actually > took longer: No, that's not the way to test AES-NI. AES-NI doesn't help TLS handshakes at all. Testing many handshakes and downloads with small files is exactly the case where AES-NI won't improve anything. You would have to run a single request causing a large download, and run haproxy through a cpu profiler, like perf, and compare outputs. Make sure you run wget that with -O /dev/null and run it on a different box, so it won't steal CPU from haproxy. Also make sure an AES cipher is actually negotiated. Lukas
