Messages in this thread | | | Date | Mon, 14 Aug 2023 22:14:53 +0200 | Subject | Re: [PATCH net-next 2/3] [PATCH 2/3] netem: allow using a seeded PRNG for generating random losses | From | François Michel <> |
| |
Hi,
Le 14/08/23 à 17:49, Stephen Hemminger a écrit : > On Mon, 14 Aug 2023 04:31:39 +0200 > Francois Michel <francois.michel@uclouvain.be> wrote: > >> +/* netem_get_random_u32 - polls a new random 32-bits integer from >> + * the prng. >> + * Uses a deterministic seeded prng if p->deterministic_rng is true. >> + * Uses get_random_u32() underneath if p is NULL or if p->deterministic_rng >> + * is false. >> + */ >> +static u32 netem_get_random_u32(struct prng *p) > > Overall I am fine with this patch, but the function name is getting excessively > long. It is a local function, so no need for netem_ prefix. > > Checking for p == NULL is redundant, all callers are passing a valid pointer. > > For logical consistency, put the new wrapper before init_crandom() and after netem_skb_cb(). > > Since this is not security related, the change could also be simplified to just > always prandom_u32_state() and initialize the state on first use with either > get_random or provided seed. This would also simplify the code around storing > original seed and boolean.
Thank you very much for your comment.
I do not use prandom_u32_state() directly in order to ensure that the original netem behaviour is preserved when no seed is specified.
But I agree that it would be cleaner to directly use prandom_u32_state() instead of get_random_u32(), if we are sure that we won't have problems (e.g. short prng cycles) with the randomly generated seeds when no seed is explicitly provided. If it is okay, then I don't see a reason to not use prandom_u32_state() directly.
I'll make an update of the patch taking these comments into account and simplifying the patch.
Thank you !
François
> > Reminds me of the quote attributed to Mark Twain: > “I apologize for such a long letter - I didn't have time to write a short one.”
| |