> 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
