Date: Mon, 2 Mar 2015 09:41:15 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Alfred Perlstein <bright@mu.org> Cc: Emeric POUPON <emeric.poupon@stormshield.eu>, "arch@freebsd.org" <arch@freebsd.org>, Alfred Perlstein <alfred@freebsd.org> Subject: Re: locks and kernel randomness... Message-ID: <20150302174115.GR32329@funkthat.com> In-Reply-To: <1D168865-DF1B-4A08-BB42-FB26B4D88D6E@mu.org> References: <20150224012026.GY46794@funkthat.com> <1824482166.23183751.1425303073196.JavaMail.zimbra@stormshield.eu> <54F47C98.2080505@freebsd.org> <20150302171025.GO32329@funkthat.com> <1D168865-DF1B-4A08-BB42-FB26B4D88D6E@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote this message on Mon, Mar 02, 2015 at 12:19 -0500: > > On Mar 2, 2015, at 12:10 PM, John-Mark Gurney <jmg@funkthat.com> wrote: > > > > Alfred Perlstein wrote this message on Mon, Mar 02, 2015 at 10:07 -0500: > >>> On 3/2/15 8:31 AM, Emeric POUPON wrote: > >>> About arc4random, we have noticed significant contention in that function on multi CPU systems when ciphering a lot of packets in the IPsec stack. > >>> This is indeed due to the mutex that is being used in the arc4rand function. > >>> > >>> Actually randomness is required by the IV used in the forged output packets. > >>> However, making a separate random generator per CPU might be more complicated than expected. > >>> The RFC 6027 (http://www.ietf.org/rfc/rfc6027.txt) reminds that the IV must not be repeated : > >>> --- > >>> 3.7.1. Outbound SAs Using Counter Modes > >>> > >>> For SAs involving counter mode ciphers such as Counter Mode (CTR) > >>> ([RFC3686]) or Galois/Counter Mode (GCM) ([RFC4106]) there is yet > >>> another complication. The initial vector for such modes MUST NOT be > >>> repeated, and senders use methods such as counters or linear feedback > >>> shift registers (LFSRs) to ensure this [...] > >>> --- > >>> > >>> What do you think? > >> > >> If you can not have multiple random sources then what do you think of > >> having a thread that pre-fetches batches of random values and queues it > >> to each cpu? If you have the queue be pretty large then you shouldn't > >> bottleneck on it. > >> > >> Sort of like UMA for random data. > >> > >> Sorry if this is a daft idea, not sure about this code path in general, > >> but this struck me as a potential workaround. > > > > I'd say that's needlessly complex... You'd still need a lock, or play > > w/ the scheduler (sched_bind) to serialize access to the PCPU random > > pool... > > John, that is how you break down a lock. Do you have a lock free or per CPU solution? > > Using a strategy like this is very typical when trying to scale across CPU. > > Do you have alternate idea? Did people not at ALL read the original email? I said in the original email: I already have another patch that converts arc4rand and friends over to ChaCha. This patch does use PCPU data and sched_pin to help eliminate locks, but this does need more study. Please, read the original email, and then ask questions.. If you jump into the middle of the thread, it's you're responsibility to reread the thread... Does my original email answer your questions? If not, feel free to ask additional questions... Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150302174115.GR32329>