Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 May 2017 07:46:29 -0700
From:      Adrian Chadd <adrian@freebsd.org>
To:        Emeric POUPON <emeric.poupon@stormshield.eu>
Cc:        freebsd-arch <freebsd-arch@freebsd.org>
Subject:   Re: numa and taskqueues
Message-ID:  <CAJ-Vmo=h3ASXiFWYT1E=xHQ%2BzZ_5%2B027dXibbPezj2CcHvGxVg@mail.gmail.com>
In-Reply-To: <816581118.55670987.1496141816904.JavaMail.zimbra@stormshield.eu>
References:  <1914359731.54283525.1495178031163.JavaMail.zimbra@stormshield.eu> <CAJ-Vmo=6bpo1Yu6XosN3BiYOakjeXS8J7wenfubzkWz2SxXR1g@mail.gmail.com> <816581118.55670987.1496141816904.JavaMail.zimbra@stormshield.eu>

next in thread | previous in thread | raw e-mail | index | archive | help
On 30 May 2017 at 03:56, Emeric POUPON <emeric.poupon@stormshield.eu> wrote:
> Hi,
>
>> Anyway - I think it'd be nice to have domain aware and pcpu aware
>> taskqueues so we can eventually migrate to a taskqueue group model of
>> "one top level things for net processing" for devices to share, etc,
>> etc. But for the short term just prototype it with some thin API in
>> crypto that wraps the taskqueue / kproc work so it gets done, then
>> push that work out for review/evaluation. if it does indeed work the
>> way you intend, we can try to use it as a template for a higher level,
>> shared taskqueue thing.
>
> It looks like it is somewhat mandatory to modify the taskqueue API to pin threads to the
> correct CPUs. The logic to define which CPU need to be set is another story that indeed can first
> be implemented in crypto(9).
>
> By the way:
> 1/ do you have some pointers on domain enumeration and other numa related code?

Sorry, I'm a bit too busy with other things to dive in right now :(

> 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,




-adrian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=h3ASXiFWYT1E=xHQ%2BzZ_5%2B027dXibbPezj2CcHvGxVg>