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] [thread-next>] [day] [month] [year] [list]
Message-ID: <77de100a-42b1-1e0d-6545-cadb0067eec6@codeaurora.org>
Date:   Wed, 2 Aug 2017 09:21:42 -0500
From:   Timur Tabi <timur@...eaurora.org>
To:     David Laight <David.Laight@...LAB.COM>,
        "David S. Miller" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control
 autonegotiation by default

On 8/2/17 8:48 AM, David Laight wrote:
> If the nearby switches cannot handle pause frames, then the MAC shouldn't
> be sending them at all.

There's no way for me to know whether the switches can handle the pause 
frames or not.  You would think that sending one multicast pause frame 
ever 33ms would not overload a switch, but in our lab it does.

This is why I changed the default to disable sending pause frames.

> They
> 
> I suspect that they should only ever be sent if the phy autonegotiation
> indicates that they are supported.

Or if you manually enable them.  That's why I changed to default: the 
MAC is now configured by default to accept pause frames but not send them.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ