| Message ID | 20221031173953.614577-1-i.maximets@ovn.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 598d2982b11144e44a5beb5cb6fd899873b394e3 |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net-next] net: tun: bump the link speed from 10Mbps to 10Gbps | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/fixes_present | success | Fixes tag not required for -next series |
| netdev/subject_prefix | success | Link |
| netdev/cover_letter | success | Single patches do not need cover letters |
| netdev/patch_count | success | Link |
| netdev/header_inline | success | No static functions without inline keyword in header files |
| netdev/build_32bit | success | Errors and warnings before: 0 this patch: 0 |
| netdev/cc_maintainers | success | CCed 5 of 5 maintainers |
| netdev/build_clang | success | Errors and warnings before: 0 this patch: 0 |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Signed-off-by tag matches author and committer |
| netdev/check_selftest | success | No net selftest shell script |
| netdev/verify_fixes | success | No Fixes tag |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
| netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 8 lines checked |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/source_inline | success | Was 0 now: 0 |
Le 31/10/2022 à 18:39, Ilya Maximets a écrit : > 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. > > Alternative might be to explicitly report UNKNOWN and let the user > decide on a right value for them. And it is indeed "the right way" > of fixing the problem. However, that may cause issues with bonding > or with some userspace applications that may rely on speed value to > be reported (even though they should not). Just changing the speed > value should be a safer option. > > Users can still override the speed with ethtool, if necessary. > > RFC discussion is linked below. > > Link: https://lore.kernel.org/lkml/20221021114921.3705550-1-i.maximets@ovn.org/ > Link: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051958.html > Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Hello: This patch was applied to netdev/net-next.git (master) by Paolo Abeni <pabeni@redhat.com>: On Mon, 31 Oct 2022 18:39:53 +0100 you 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. > > [...] Here is the summary with links: - [net-next] net: tun: bump the link speed from 10Mbps to 10Gbps https://git.kernel.org/netdev/net-next/c/598d2982b111 You are awesome, thank you!
diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 27c6d235cbda..48bb4a166ad4 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -3514,7 +3514,7 @@ static void tun_default_link_ksettings(struct net_device *dev, { ethtool_link_ksettings_zero_link_mode(cmd, supported); ethtool_link_ksettings_zero_link_mode(cmd, advertising); - cmd->base.speed = SPEED_10; + cmd->base.speed = SPEED_10000; cmd->base.duplex = DUPLEX_FULL; cmd->base.port = PORT_TP; cmd->base.phy_address = 0;
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. Alternative might be to explicitly report UNKNOWN and let the user decide on a right value for them. And it is indeed "the right way" of fixing the problem. However, that may cause issues with bonding or with some userspace applications that may rely on speed value to be reported (even though they should not). Just changing the speed value should be a safer option. Users can still override the speed with ethtool, if necessary. RFC discussion is linked below. Link: https://lore.kernel.org/lkml/20221021114921.3705550-1-i.maximets@ovn.org/ Link: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051958.html Signed-off-by: Ilya Maximets <i.maximets@ovn.org> --- drivers/net/tun.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)