[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130724.172926.1881479319860230451.davem@davemloft.net>
Date: Wed, 24 Jul 2013 17:29:26 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: stephen@...workplumber.org
Cc: bhutchings@...arflare.com, h.grohne@...nusnetworks.de,
netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/3] tuntap: allow changing ethtool speed (v2)
From: Stephen Hemminger <stephen@...workplumber.org>
Date: Wed, 24 Jul 2013 17:17:50 -0700
> On Thu, 25 Jul 2013 00:40:50 +0100
> Ben Hutchings <bhutchings@...arflare.com> wrote:
>
>> On Wed, 2013-07-24 at 16:11 -0700, Stephen Hemminger wrote:
>> > The data reported by the ethtool interface for tun/tap devices is
>> > artificial. The default speed is 10Mbit. Virtual interfaces are often
>> > faster than this nowadays, so the observed bandwidth may exceed the
>> > available bandwidth. This patch allows an administrator to change the
>> > available bandwidth as reported by ethtool.
>> >
>> > Signed-off-by: Helmut Grohne <h.grohne@...nusnetworks.de>
>> > Signed-off-by: Stephen Hemminger <stephen@...workplumber.org>
>> >
>> > ---
>> > v2 - allow setting duplex as well, fix patch formatting
>>
>> It's logically full duplex so this doesn't make sense to me.
>>
>> > ignore other settings in set
>> [...]
>>
>> No, please never do that in ethtool_ops::set_settings. Setting
>> unsupported values is an error.
>
> Almost every hardware driver out there allows mucking with settings
> that it doesn't care about (like transceiver and port). Why be picky now?
Those are bugs to be fixed, rather than things to emulate.
And honestly this is an unrelated thing to mention given the point Ben
is trying to make.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists