netdev - Re: [RFE net-next] net: tun: 1000x speed up

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>] [day] [month] [year] [list]

Message-ID: <572c2695-bf34-32b9-7d87-94e97302ac8a@ovn.org>
Date:   Wed, 26 Oct 2022 15:13:12 +0200
From:   Ilya Maximets <i.maximets@....org>
To:     Dave Taht <dave.taht@...il.com>
Cc:     i.maximets@....org,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFE net-next] net: tun: 1000x speed up

On 10/26/22 01:22, Dave Taht wrote:
> What does OVS do for automatic QoS configuration in the first place?
> Configure fq_codel? a shaper? what?

By default OVS will set up tc-htb as an egress traffic shaping when
users request QoS.  Netlink interface for it has RATE and PEAKRATE.
And these are not optional, so OVS has to come up with some values.

Link speed is a logically sane value to use as an upper limit, if
not specified.

Other types of classifiers can also be configured including hfsc,
sfq, codel, fq_codel, netem.

Best regards, Ilya Maximets.

> 
> On Fri, Oct 21, 2022 at 5:38 AM Ilya Maximets <i.maximets@....org> 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@....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
>>
> 
>