From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F2BFC49ED6 for ; Wed, 11 Sep 2019 22:52:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 50F4F2087E for ; Wed, 11 Sep 2019 22:52:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="1KeepMQa" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728267AbfIKWw4 (ORCPT ); Wed, 11 Sep 2019 18:52:56 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:41348 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726735AbfIKWw4 (ORCPT ); Wed, 11 Sep 2019 18:52:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4aVgtI53MkdfEImlYuOkvkEfXNGliuEFpft7wPzwa64=; b=1KeepMQawvtTMpT8q2FWOFribO e5hLVp0W5AkYyh998EujdKRBEEuP4j18Nrdf71FJSDeK8x9nseAlpHFsbFBWofD2xAwaKtZ+4aNJM 9T1RZ24vEpTW15wtvCk2kHP+0JZ6hsgvfcyddCLe32yajx9YLSTUTNxi6ZaQITjFLDhs=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1i8BTo-0001dm-TG; Thu, 12 Sep 2019 00:52:52 +0200 Date: Thu, 12 Sep 2019 00:52:52 +0200 From: Andrew Lunn To: Robert Beckett Cc: Florian Fainelli , netdev@vger.kernel.org, Vivien Didelot , "David S. Miller" Subject: Re: [PATCH 1/7] net/dsa: configure autoneg for CPU port Message-ID: <20190911225252.GA5710@lunn.ch> References: <20190910154238.9155-1-bob.beckett@collabora.com> <20190910154238.9155-2-bob.beckett@collabora.com> <20190910182635.GA9761@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > 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