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]

Message-ID: <20200128162330.GN13647@lunn.ch>
Date:   Tue, 28 Jan 2020 17:23:30 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
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

On Tue, Jan 28, 2020 at 05:41:31PM +0200, Vladimir Oltean wrote:
> 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.

Hi Vladimir

It is something worth testing. It might depend on the size of the
FIFO, and offloads like GSO. If the interface is given a 64KByte skb
to send, and the hardware sends it in a 10G line rate burst, is that
going to overflow the small FIFO? If the PHY trigger flow control fast
enough to pause the MAC within this burst, the performance could be
better.

So it is not a binary works/broken, but what is performance like? Can
you get 1Gbps, or does it drop to a much lower speed with a lot of
retires?

Flow control might not be the only option. It is simple, so if it
works, great. But when the PHY reports it has link at 1G, could you
enable some traffic shaping in the MAC to limit it to 1G, even if it
is going out a 10G SERDES?

   Andrew