Date: Tue, 30 May 2017 16:46:01 +0200 (CEST) From: Emeric POUPON <emeric.poupon@stormshield.eu> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: numa and taskqueues Message-ID: <608664209.55736023.1496155561181.JavaMail.zimbra@stormshield.eu> In-Reply-To: <CAJ-Vmo=h3ASXiFWYT1E=xHQ%2BzZ_5%2B027dXibbPezj2CcHvGxVg@mail.gmail.com> References: <1914359731.54283525.1495178031163.JavaMail.zimbra@stormshield.eu> <CAJ-Vmo=6bpo1Yu6XosN3BiYOakjeXS8J7wenfubzkWz2SxXR1g@mail.gmail.com> <816581118.55670987.1496141816904.JavaMail.zimbra@stormshield.eu> <CAJ-Vmo=h3ASXiFWYT1E=xHQ%2BzZ_5%2B027dXibbPezj2CcHvGxVg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > >> 2/ about https://reviews.freebsd.org/D10680, I think it would be great to have >> this commited as a first step. >> Since it seems to be stuck, maybe I can add more people on this. Any suggestion? > > Well, what's with the ~ 8% performance decrease? Do you know what's > going on? For a "we're parallelising IPSEC operations", seeing it get > slower with more flows is a bit concerning. > > Thanks, > Actually, there is a performance boost only when few flows are involved. That's why this is not activated by default and a sysctl is here to enable the feature. To sum up, the more different flows you process (both ciphered and unciphered), the more network queues are hit and the more CPU units are triggered from ipsec. In this case, we indeed notice a loss, certainly due to the extra queing/reordering performed.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?608664209.55736023.1496155561181.JavaMail.zimbra>