From owner-freebsd-arch@FreeBSD.ORG Mon Mar 2 17:19:47 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0778BD5; Mon, 2 Mar 2015 17:19:47 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0A9CF63B; Mon, 2 Mar 2015 17:19:47 +0000 (UTC) Received: from [100.94.233.168] (36.sub-70-208-89.myvzw.com [70.208.89.36]) by elvis.mu.org (Postfix) with ESMTPSA id BD89A341F910; Mon, 2 Mar 2015 09:19:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: locks and kernel randomness... From: Alfred Perlstein X-Mailer: iPhone Mail (12B440) In-Reply-To: <20150302171025.GO32329@funkthat.com> Date: Mon, 2 Mar 2015 12:19:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: John-Mark Gurney Cc: Emeric POUPON , "arch@freebsd.org" , Alfred Perlstein X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 17:19:47 -0000 > On Mar 2, 2015, at 12:10 PM, John-Mark Gurney 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