GitLab

Was trying to spin up a fast setup for support#17299 to see that a DHCP client does not exit it's renew state while changing configurations. This is not easily achieveable with the current perfdhcp which, at most, sends 1:1:1 discover:requests:renews/solicits:requests:renews. I would like to send 1:1:n messages or even 0:0:n. Solutions:

• 1:1:n
  • Don't remove from the ack_storage/reply_storage after a renew message has been sent
  • Allow renew rate to surpass rate
• As an extension to allow 0:0:n
  • Save the ack_storage/reply_storage in a file on one run. Load the ack_storage/reply_storage from file in the run that sends renews only.

This would also result in an increase of performance measurements if performance experiments are run in this mode. The assumption here is that discovers and solicits are more resource-intensive to be handled. So getting rid of them would result in more leases (fine, renews) per second.

And that is not a cheap unrealistic shortcut, but rather a scenario more closer to reality.