Skip site navigation (1)Skip section navigation (2)
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>