From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: [RFC PATCH net-next 0/2] Configuring PFC stall prevention via ethtool Date: Thu, 16 Nov 2017 02:07:22 +0100 Message-ID: <20171116010722.GD2130@lunn.ch> References: <1510772411-17054-1-git-send-email-eranbe@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org, "David S. Miller" , "John W. Linville" , Saeed Mahameed , Gal Pressman , Ariel Almog , Inbar Karmy To: Eran Ben Elisha Return-path: Received: from vps0.lunn.ch ([185.16.172.187]:56141 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751097AbdKPBH2 (ORCPT ); Wed, 15 Nov 2017 20:07:28 -0500 Content-Disposition: inline In-Reply-To: <1510772411-17054-1-git-send-email-eranbe@mellanox.com> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Nov 15, 2017 at 09:00:09PM +0200, Eran Ben Elisha wrote: > From: Inbar Karmy > > This RFC adds support for configuring PFC stall prevention through ethtool. > > In the event where the device unexpectedly becomes unresponsive for a long > period of time, flow control mechanism may propagate pause frames which will > cause congestion spreading to the entire network. > > To prevent this scenario, the device may implement a protection mechanism for > monitoring and resolving such state. The following patches allow the user to > control the stall prevention functionality. > > PFC stall prevention configuration is done via ethtool -a (pause). > Two modes are introduced: > Default - current behavior per driver. > Auto - protection mechanism controlled automatically by the driver. Why Auto? Down in the driver you seem to translate this to a time. And it looks like your hardware is flexible on that time, it can probably do at least 8s to 100ms. Why not specify a time? What do other vendors support? Time? Number of pause frames sent? Andrew