[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190911225252.GA5710@lunn.ch>
Date: Thu, 12 Sep 2019 00:52:52 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Robert Beckett <bob.beckett@...labora.com>
Cc: Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org,
Vivien Didelot <vivien.didelot@...il.com>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 1/7] net/dsa: configure autoneg for CPU port
> It is not just for broadcast storm protection. The original issue that
> made me look in to all of this turned out to be rx descritor ring
> buffer exhaustion due to the CPU not being able to keep up with packet
> reception.
Pause frames does not really solve this problem. The switch will at
some point fill its buffers, and start throwing packets away. Or it
needs to send pause packets it its peers. And then your whole switch
throughput goes down. Packets will always get thrown away, so you need
QoS in your network to give the network hints about which frames is
should throw away first.
..
> Fundamentally, with a phy to phy CPU connection, the CPU MAC may well
> wish to enable pause frames for various reasons, so we should strive to
> handle that I think.
It actually has nothing to do with PHY to PHY connections. You can use
pause frames with direct MAC to MAC connections. PHY auto-negotiation
is one way to indicate both ends support it, but there are also other
ways. e.g.
ethtool -A|--pause devname [autoneg on|off] [rx on|off] [tx on|off]
on the SoC you could do
ethtool --pause eth0 autoneg off rx on tx on
to force the SoC to send and process pause frames. Ideally i would
prefer a solution like this, since it is not a change of behaviour for
everybody else.
Andrew
Powered by blists - more mailing lists