Separate UDP GSO and GRO controls for Linux (--gso and --gro options) #2037

[roaoliver]

PLEASE NOTE the following text from the iperf3 license. Submitting a
pull request to the iperf3 repository constitutes "[making]
Enhancements available...publicly":

You are under no obligation whatsoever to provide any bug fixes, patches, or
upgrades to the features, functionality or performance of the source code
("Enhancements") to anyone; however, if you choose to make your Enhancements
available either publicly, or directly to Lawrence Berkeley National
Laboratory, without imposing a separate written license agreement for such
Enhancements, then you hereby grant the following license: a non-exclusive,
royalty-free perpetual license to install, use, modify, prepare derivative
works, incorporate into other computer software, distribute, and sublicense
such enhancements or derivative works thereof, in binary and source code form.

The complete iperf3 license is available in the LICENSE file in the
top directory of the iperf3 source tree.

• Version of iperf3 (or development branch, such as master or
  3.1-STABLE) to which this pull request applies:
  3.21
• Issues fixed (if any):
  Separate UDP GSO and GRO controls for Linux (--gso and --gro options) #2037
• Brief description of code changes (suitable for use as a commit message):
  Separate UDP GSO and GRO controls for Linux (--gso and --gro options)

[davidBar-On]

Suggest to set only gso, so --gso --gro will be equivalent to --gsro.

[davidBar-On]

Suggest to set only gro, so --gso --gro will be equivalent to --gsro.

[davidBar-On]

To reduce number of iperf3 options, instead of adding --gso and --gro it may be better to add a flag to --gsro. E.g --gsro/s will set only gso and --gsro/r will set only gro.

[roaoliver]

Suggestion implemented in the code.

[biergaizi]

For your information, the high CPU usage was caused by busy-polling via MSG_DONTWAIT, this has been root-caused by @kvasana in #2069, once #2069 is merged this workaround is no longer necessary in your use case (high CPU usage at receiver).

That being said, I still support supporting separate GSO and GRO options. In some test setups the server and client processing speeds are not symmetric, so it's still useful to isolate a sender or receiver side bottleneck.