Max out the number of rows for OPRF step generation #823
Conversation
| let (single_user_mode, query_size) = if cfg!(feature = "step-trace") && args.oprf { | ||
| (true, usize::try_from(args.records_per_user).unwrap()) | ||
| } else { | ||
| (false, args.query_size) | ||
| }; |
There was a problem hiding this comment.
Rather than use a boolean, you can use the IpaQueryStyle enum.
There was a problem hiding this comment.
Oh wait, it looks like I misunderstood the meaning of "single_user_mode".
| pub number_of_users_in_flight: NonZeroU32, | ||
| #[cfg_attr(feature = "clap", arg(long, default_value = "false"))] | ||
| pub single_user_mode: bool, |
There was a problem hiding this comment.
Do we need both? Can we just use a single param for this?
| feature = "clap", | ||
| arg(long, default_value = "10", conflicts_with("single_user_mode")) | ||
| )] | ||
| pub number_of_users_in_flight: NonZeroU32, |
There was a problem hiding this comment.
I recommend instead an interface of just:
pub num_users
| @@ -241,8 +254,12 @@ impl<R: Rng> Iterator for EventGenerator<R> { | |||
| type Item = TestRawDataRecord; | |||
|
|
|||
| fn next(&mut self) -> Option<Self::Item> { | |||
| const USERS_IN_FLIGHT: usize = 10; | |||
There was a problem hiding this comment.
let users_in_flight = std::min(10, config.num_users);
| } else { | ||
| usize::try_from(self.config.number_of_users_in_flight.get()).unwrap() | ||
| }; | ||
| while self.users.len() < number_of_users_in_flight { |
There was a problem hiding this comment.
Maybe we move this into the constructor, and make it possible to configure it. Then this "replace" logic can just maintain self.users at a constant length.
|
#834 fixes the issue I wanted to address with this PR. Closing |
OPRF protocol step generation needed to run #822.
ipa::protocol::prf_sharding::UserNthPerStepdepends on the maximum number of rows of any users in the input. In order to generate all possible combinations of the steps, we need to generate the max allowable number of rows for a user. The max allowable number should be the number specified by#[dynamic(...)]inUserNthRowStepenum. For now, we userecords_per_userwhich can be specified when running the benchmark.Note that this is a temporary solution. If the max number of rows become too large, we need a better way to generate the steps, likely by synthesizing the steps in the
Stepderive macro.