So looking at this holistically I think, we should maintain the default behavior as is. But we can add a config option to disable these features on the interface/bridge for troubleshooting purposes.
If someone hits nw perf issue, they can turn these in config and have TSO, GSO, GRO etc. disabled.
The perf issue with TSO, GSO enabled spans across hypervisors and Linux SKUs. /kris.io/ 2015/10/ 01/kvm- network- performance- tso-and- gso-turn- it-off/
Details can be seen https:/
Redhat has issued advisory for RHEL6 for "Network performance issues" https:/ /access. redhat. com/documentati on/en-US/ Red_Hat_ Enterprise_ Linux/6/ html/Virtualiza tion_Host_ Configuration_ and_Guest_ Installation_ Guide/ch10s04. html
https:/ /docs.fedorapro ject.org/ en-US/Fedora_ Draft_Documenta tion/0. 1/html/ Virtualization_ Deployment_ and_Administrat ion_Guide/ ch10s04. html
Related Bug: https:/ /bugs.launchpad .net/qemu/ +bug/1202289
However later RHEL docs https:/ /access. redhat. com/documentati on/en-US/ Red_Hat_ Enterprise_ Linux/6/ html/6. 5_Technical_ Notes/kernel. html mentions some fixes which 'may' address this.
Anyway this seems to be an unreliable feature to be enabled, and the folks at Qemu are not in favor of changing the defaults to "Off" for these flags, which seems fair... /lists. gnu.org/ archive/ html/qemu- devel/2016- 05/msg01165. html
https:/
So looking at this holistically I think, we should maintain the default behavior as is. But we can add a config option to disable these features on the interface/bridge for troubleshooting purposes.
If someone hits nw perf issue, they can turn these in config and have TSO, GSO, GRO etc. disabled.
I will work on this. Welcoming suggestions...