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-prev] [day] [month] [year] [list]
Message-ID: <f3dcda9c-2b24-a047-4a7c-0e449dc18386@cumulusnetworks.com>
Date:   Tue, 9 Apr 2019 13:09:57 +0300
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Huang Rui <huangruippp@...il.com>, davem@...emloft.net
Cc:     lirongqing@...du.com, netdev@...r.kernel.org,
        Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [PATCH] net:bridge:bridge mtu auto tuning does not always work

On 09/04/2019 12:49, Nikolay Aleksandrov wrote:
> On 09/04/2019 12:20, Nikolay Aleksandrov wrote:
>> On 09/04/2019 10:36, Huang Rui wrote:
>>> If someone setup a bridge and add a port(for example: eth0)
>>> into the bridge, but configure the bridge's mtu which is equal
>>> to eth0's mtu, the auto tuning flag will not be set true. But
[snip]
> 
> Ahh wait, looking again at the change I get why you're doing that. The commit
> message is wrong though, you're trying to disable auto-tuning always even
> when setting the same MTU, right ?
> Or IOW, I guess by the auto-tuning flag you mean BROPT_MTU_SET_BY_USER ?
> 
> I don't like device-specific hacks in the generic code, specifically this
> code will not generate an event but will affect state. I don't see a better
> approach currently though.
> 
> At the very least please add a better explanation and better subject line.
> It is not "auto tuning does not always work", but maybe something similar
> to "always disable auto-tuning when the user specified MTU" with details
> of the case where setting the same MTU doesn't disable auto-tuning currently.
> 
> Thanks
> 

One more thing - this has the potential to break setups because a lot of
the network configuration software always set the device MTU and will
disable the auto-tuning by default with this change.
IIRC that was the reason I dropped it from my original change.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ