On Thu, Nov 16, 2017 at 10:44 AM, Michal Kubecek <mkube...@suse.cz> wrote: > On Wed, Nov 15, 2017 at 09:00:09PM +0200, Eran Ben Elisha wrote: >> From: Inbar Karmy <inb...@mellanox.com> >> >> 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. >> Due to lack of extension ability of ethtool_ops set_pauseparam, a new >> ethtool_ops get_pfc_prevention_mode is introduced. > > I don't like adding another ethtool_ops callback tightly tied to the > structures passed via ioctl() but when I started to think what to > suggest as an alternative, I started to wonder if it is really necessary > to add a new ethtool command at all. Couldn't this be handled as > a tunable? > > Michal Kubecek
tunable seems as a good infrastructure to PHY tuning, however this feature is not a PHY feature. To me, it's looks fit to ethtool -a where pause operations are being controlled. Unfortunately set/get_pauseparam is not extensible and need a new operation. Eran.
