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: > > 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? > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1D168865-DF1B-4A08-BB42-FB26B4D88D6E>