Messages in this thread | | | Date | Mon, 31 Oct 2022 18:09:58 +0100 | From | Ilya Maximets <> | Subject | Re: [RFE net-next] net: tun: 1000x speed up |
| |
On 10/21/22 13:49, Ilya Maximets wrote: > The 10Mbps link speed was set in 2004 when the ethtool interface was > initially added to the tun driver. It might have been a good > assumption 18 years ago, but CPUs and network stack came a long way > since then. > > Other virtual ports typically report much higher speeds. For example, > veth reports 10Gbps since its introduction in 2007. > > Some userspace applications rely on the current link speed in > certain situations. For example, Open vSwitch is using link speed > as an upper bound for QoS configuration if user didn't specify the > maximum rate. Advertised 10Mbps doesn't match reality in a modern > world, so users have to always manually override the value with > something more sensible to avoid configuration issues, e.g. limiting > the traffic too much. This also creates additional confusion among > users. > > Bump the advertised speed to at least match the veth. 10Gbps also > seems like a more or less fair assumption these days, even though > CPUs can do more. Alternative might be to explicitly report UNKNOWN > and let the application/user decide on a right value for them. > > Link: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051958.html > Signed-off-by: Ilya Maximets <i.maximets@ovn.org> > --- > > Sorry for the clickbait subject line. Can change it to something more > sensible while posting non-RFE patch. Something like: > > 'net: tun: bump the link speed from 10Mbps to 10Gbps' > > This patch is RFE just to start a conversation.
OK. There seems to be no more discussions around the topic, so I'll make a conclusion.
General understanding is that reporting UNKNOWN will cause problems with bonding (not sure why anyone will add tap into bonding outside of just for testing reasons, but that's a different topic) and will potentially cause problems with userpsace applications that do not handle that case for some reason. So, this is a risky option at the moment.
There was no strong opinion against equalizing speeds between veth and tun/tap. Sounds like a safe option in general and there are no known use cases that will be negatively affected.
So, I think, I'll go ahead and post the non-RFC version of the proposed change.
Thanks!
Best regards, Ilya Maximets.
| |