Date: Mon, 2 Mar 2015 12:19:43 -0500 From: Alfred Perlstein <bright@mu.org> To: John-Mark Gurney <jmg@funkthat.com> 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: <1D168865-DF1B-4A08-BB42-FB26B4D88D6E@mu.org> In-Reply-To: <20150302171025.GO32329@funkthat.com> References: <20150224012026.GY46794@funkthat.com> <1824482166.23183751.1425303073196.JavaMail.zimbra@stormshield.eu> <54F47C98.2080505@freebsd.org> <20150302171025.GO32329@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mar 2, 2015, at 12:10 PM, John-Mark Gurney <jmg@funkthat.com> wrote: >=20 > 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 functio= n 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 funct= ion. >>>=20 >>> Actually randomness is required by the IV used in the forged output pack= ets. >>> However, making a separate random generator per CPU might be more compli= cated than expected. >>> The RFC 6027 (http://www.ietf.org/rfc/rfc6027.txt) reminds that the IV m= ust not be repeated : >>> --- >>> 3.7.1. Outbound SAs Using Counter Modes >>>=20 >>> 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 [...] >>> --- >>>=20 >>> What do you think? >>=20 >> If you can not have multiple random sources then what do you think of=20 >> having a thread that pre-fetches batches of random values and queues it=20= >> to each cpu? If you have the queue be pretty large then you shouldn't=20= >> bottleneck on it. >>=20 >> Sort of like UMA for random data. >>=20 >> Sorry if this is a daft idea, not sure about this code path in general,=20= >> but this struck me as a potential workaround. >=20 > 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... >=20 John, that is how you break down a lock. Do you have a lock free or per CPU s= olution? Using a strategy like this is very typical when trying to scale across CPU.=20= Do you have alternate idea? > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1D168865-DF1B-4A08-BB42-FB26B4D88D6E>