Pad final GSO segment for CPU efficiency

[mtfriesen]

Description

Describe the purpose of and changes within this Pull Request.

Reduce goodput to potentially increase CPU efficiency by padding all GSO segments, including the final segment.

Testing

Do any existing tests cover this change? Are new tests needed?

CI.

Documentation

Is there any documentation impact for this change?

No.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.06%. Comparing base (dcb20cf) to head (51347fc).
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4860      +/-   ##
==========================================
- Coverage   86.16%   86.06%   -0.10%     
==========================================
  Files          56       56              
  Lines       17634    17630       -4     
==========================================
- Hits        15195    15174      -21     
- Misses       2439     2456      +17     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mtfriesen]

Context:

1. The perf results were ambiguous, with only one comparison point on the dashboard, and three iterations deviating wildly from that comparison point. There is no statistical confidence in the perf benchmark output.
2. No VMs in Azure currently support hardware USO, so the practical benefits are limited to possibly better interaction with URO (which requires consistent datagram sizes). The costs include introducing padding bytes on the wire. In the worst case (a huge datagram followed by a 1-byte datagram) goodput is reduced by half. There could obviously be a heuristic to limit the padding loss by choosing whether to pad the final datagram based on the total send size.