locks and kernel randomness...

[Alfred Perlstein]

> On Mar 2, 2015, at 12:10 PM, John-Mark Gurney <jmg at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>