• Keller, Jacob E's avatar
    ethtool: correctly ensure {GS}CHANNELS doesn't conflict with GS{RXFH} · d4ab4286
    Keller, Jacob E authored
    Ethernet drivers implementing both {GS}RXFH and {GS}CHANNELS ethtool ops
    incorrectly allow SCHANNELS when it would conflict with the settings
    from SRXFH. This occurs because it is not possible for drivers to
    understand whether their Rx flow indirection table has been configured
    or is in the default state. In addition, drivers currently behave in
    various ways when increasing the number of Rx channels.
    
    Some drivers will always destroy the Rx flow indirection table when this
    occurs, whether it has been set by the user or not. Other drivers will
    attempt to preserve the table even if the user has never modified it
    from the default driver settings. Neither of these situation is
    desirable because it leads to unexpected behavior or loss of user
    configuration.
    
    The correct behavior is to simply return -EINVAL when SCHANNELS would
    conflict with the current Rx flow table settings. However, it should
    only do so if the current settings were modified by the user. If we
    required that the new settings never conflict with the current (default)
    Rx flow settings, we would force users to first reduce their Rx flow
    settings and then reduce the number of Rx channels.
    
    This patch proposes a solution implemented in net/core/ethtool.c which
    ensures that all drivers behave correctly. It checks whether the RXFH
    table has been configured to non-default settings, and stores this
    information in a private netdev flag. When the number of channels is
    requested to change, it first ensures that the current Rx flow table is
    not going to assign flows to now disabled channels.
    Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    d4ab4286
ethtool.c 51 KB