lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 21 Oct 2022 13:49:21 +0200
From:   Ilya Maximets <i.maximets@....org>
To:     netdev@...r.kernel.org
Cc:     Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org,
        Ilya Maximets <i.maximets@....org>
Subject: [RFE net-next] net: tun: 1000x speed up

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@....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.

 drivers/net/tun.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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;
-- 
2.37.3

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ