Date: Wed, 31 May 2017 15:53:21 +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: <1349284176.55940289.1496238801718.JavaMail.zimbra@stormshield.eu> In-Reply-To: <CAJ-VmomtfHb7W_4c2OGpQ%2B4CF1jzsV4jvkyi0nVQtLNvx8XyYQ@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> <608664209.55736023.1496155561181.JavaMail.zimbra@stormshield.eu> <CAJ-VmomtfHb7W_4c2OGpQ%2B4CF1jzsV4jvkyi0nVQtLNvx8XyYQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >> 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. > > Can you dig into that a bit more? Do you know exactly what's going on? > eg, is it a "lock contention" problem? Is it a "stuff is context > switching, thus latency" problem? etc, etc. > Unfortunately I cannot tell you the exact reason right now. I am sure there is no lock contention involved though (except of course when several domains are involved). Did you expect such a dev to be enabled by default? Emeric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1349284176.55940289.1496238801718.JavaMail.zimbra>