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  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]
Date:   Tue, 28 Jan 2020 17:41:31 +0200
From:   Vladimir Oltean <>
To:     Andrew Lunn <>
Cc:, "David S. Miller" <>,
        Florian Fainelli <>,
        Heiner Kallweit <>,
        netdev <>,
Subject: Re: [PATCH v2 2/2] dpaa_eth: support all modes with rate adapting PHYs

Hi Andrew,

On Mon, 27 Jan 2020 at 18:04, Andrew Lunn <> wrote:
> > Is this sufficient?
> > I suppose this works because you have flow control enabled by default?
> > What would happen if the user would disable flow control with ethtool?
> It will still work. Network protocols expect packets to be dropped,
> there are bottlenecks on the network, and those bottlenecks change
> dynamically. TCP will still be able to determine how much traffic it
> can send without too much packet loss, independent of if the
> bottleneck is here between the MAC and the PHY, or later when it hits
> an RFC 1149 link.

Following this logic, this patch isn't needed at all, right? The PHY
will drop frames that it can't hold in its small FIFOs when adapting a
link speed to another, and higher-level protocols will cope. And flow
control at large isn't needed.

What I was trying to see Madalin's opinion on was whether in fact we
want to keep the RX flow control as 'fixed on' if the MAC supports it
and the PHY needs it, _as a function of the current phy_mode and maybe
link speed_ (the underlined part is important IMO).

>     Andrew


Powered by blists - more mailing lists