netdev - Re: [PATCH v2 2/2] dpaa_eth: support all modes with rate adapting PHYs

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]

Date:   Tue, 28 Jan 2020 17:41:31 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     madalin.bucur@....nxp.com, "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        netdev <netdev@...r.kernel.org>, ykaukab@...e.de
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 <andrew@...n.ch> 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
>

Thanks,
-Vladimir